Re: [Ipsec] Layer 2 processing inside IPsec

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Francis" == Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:

 Francis> In your previous mail you wrote: 

 >>I just skimmed rfc3095 for
 >> the first time so I might have missed something, but I can
 >> see a couple potential problems:
   
 >> - ROHC requires that the lower layer not reorder packets,
 >> whereas IPsec includes replay protection with a sequence
 >> number, it does *not* put packets back into their original
 >> order on receive.
   
 Francis> => I disagree: IPsec does not change the order (so it can't
 Francis> have a negative effect) and more, it helps the detection of
 Francis> reordering (by something else) and lost (i.e., it can have a
 Francis> positive effect).

Not true.

A typical IPsec implementation probably doesn't reorder things, but
since it's a datagram service it would be allowed to do so.

And IPsec does NOT detect reordering.  It detects replay (repeated
packets).  The typical "replay window" implementation will -- as a
side effect -- reject reordering by an amount larger than the reply
window, but that's just an artifact of the implementation, it's not
the goal of that mechanism.

The real point is that IP networks will reorder packets, as they are
allowed to, and IPsec will not stand in the way.  So if someone
expects an IPsec-protected communication scheme to offer ordered
delivery, they may get an unpleasant surprise because that's not what
you're offered.

In some cases, deploying IPsec may cause a lot of reordering.  For
example, some implementations send fragments in "reverse" order.
That's not a really good idea, but it is perfectly legal.

       paul


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec