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

[Stephen Kent <kent@bbn.com>]

At 9:48 PM +0200 4/18/03, Yaron Sheffer wrote:
>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).

Well, ESP has been around for a while; RFC 2406 was published in 
November of 1998. I don't think we can reasonably ask implementors to 
change their implementations to accommodate ROHC. Also, as you note, 
it is not architecturally attractive, since IP would not reorder the 
traffic and IPsec tries to minimize the differences between what the 
IP interface does and what IPsec does. We had to impose the notion of 
a receive window as a tradeoff in this regard, to make anti-replay 
feasible yet not too hard for an IPsec implementation.

Also, as we go to higher speeds, asking an IPsec implementation to 
buffer inbound traffic places a significant burden on the 
implementation, since this would have to be done in hardware that is 
trying to operate at line rates.

>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 understand.

>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.

IKE is really  a security association management protocol and if 
compression is part of the SA processing, then we have to negotiate 
its use and parameters when we establish an SA. Key management is the 
easy part :-).  All the complexity is in the SA management part.

Steve