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

["Yaron Sheffer" <yaronf@gmx.net>]

Hi Steve,

I see a trade-off here between tweaking ROHC to deal with reordering
channels (it may be easy or hard, I don't know) and tweaking the ESP
*implementation* to undo such reordering. I accept that the RFC doesn't
mandate or even suggest it, and from an architectural perspective it's not
clean. But it's a minor change to the implementation of sequence-number
handling in ESP, which can be spelled out specifically in a "Header
compression over ESP" draft. Otherwise you need to work very hard to
implement ROHC (or CRTP, or ECRTP) securely over ESP, going through
contortions like the proposed authentication-before-compression (sorry
David).

Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a
IPCOMP_SUPPORTED notification, which can be extended (and renamed to
COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that
ROHC should be an IPComp profile, only that it's negotiated in an analogous
manner. IPComp makes different assumptions regarding traffic (packet
lengths) compared to ROHC, and therefore probably doesn't do the job here.
But this is for the ROHC people to judge.

I am being somewhat simplistic, you may need to negotiate some basic
compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE,
LZS} values of this field.

Speaking about the IPSec architecture, it's a pity that compression
parameters remain an integral part of IKE v2, rather than add-ons.

Best regards,
	Yaron

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, April 18, 2003 2:42 PM
To: Yaron Sheffer
Cc: Lars-Erik Jonsson (EAB); Derek Atkins; rohc@ietf.org;
ipsec@lists.tislabs.com
Subject: RE: [rohc] RE: (in)security of ESP with header compression


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