RE: [rohc] RE: (in)security of ESP with header compression

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Yaron" == Yaron Sheffer <yaronf@gmx.net> writes:

 Yaron> ESP includes a 32-bit sequence number. It is mandatory for the
 Yaron> sender to set and increment it correctly, but optional for the
 Yaron> receiver to verify it. It is there to prevent malicious replay
 Yaron> of messages.

 Yaron> In the case of ROHC over ESP, if the receiver's policy is to
 Yaron> delete packets with an out-of-order ESP sequence number
 Yaron> (possibly using a small reorder buffer), then packets reaching
 Yaron> the decompressor are always in order. The channel is not
 Yaron> reliable of course, since entire packets may be deleted. All
 Yaron> in all, this channel becomes analogous to your plain vanilla
 Yaron> PPP.

 Yaron> Applicability: in general, IP (and ESP) packets may be
 Yaron> drastically reordered, with packets coming in many seconds out
 Yaron> of order. For Internet telephony, those packets are useless
 Yaron> and can be discarded on arrival.

 Yaron> Under these assumptions, I don't believe any change to the
 Yaron> operating assumptions of ROHC, or a new ROHC profile, is
 Yaron> needed. This is not "ROHC over tunnels" but only "ROHC over
 Yaron> ESP", but it's still an interesting case.

Maybe.  But your assumption is questionable.  One could build ESP like
that, but I've never heard of anyone doing it.  The typical
implementation will accept packets that are out of order WITHOUT
putting them back in order, provided they are not out of order by more
than a "window" amount.  A typical window is 64, because that's the
max size of an easy to do bitmap, but it's not significantly harder to
make it bigger, and the cost is only a a bit per unit of distance.

So your assumption that ESP (with integrity) is a lossy ordered
channel is unlikely to be valid.

	paul