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

[Stephen Kent <kent@bbn.com>]

At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote:
>ESP includes a 32-bit sequence number. It is mandatory for the sender to set
>and increment it correctly, but optional for the receiver to verify it. It
>is there to prevent malicious replay of messages.
>
>In the case of ROHC over ESP, if the receiver's policy is to delete packets
>with an out-of-order ESP sequence number (possibly using a small reorder
>buffer), then packets reaching the decompressor are always in order. The
>channel is not reliable of course, since entire packets may be deleted. All
>in all, this channel becomes analogous to your plain vanilla PPP.
>
>Applicability: in general, IP (and ESP) packets may be drastically
>reordered, with packets coming in many seconds out of order. For Internet
>telephony, those packets are useless and can be discarded on arrival.
>
>Under these assumptions, I don't believe any change to the operating
>assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC
>over tunnels" but only "ROHC over ESP", but it's still an interesting case.
>
>Thanks,
>	Yaron

I may not have understood your argument, but any solution we would 
adopt for IPsec use of ROHC must be general, i.e., it cannot depend 
on specific receiver constraints re anti-replay window parameters. 
Also, your message suggests a possible misunderstanding re IPsec and 
anti-replay: I know of no IPsec implementation that reorders packets 
upon arrival and doing so is certainly outside the scope of what the 
RFCs call for.

Steve