Re: (in)security of ESP with header compression

[Stephen Kent <kent@bbn.com>]

At 6:29 AM -0700 4/15/03, David Mcgrew wrote:
>Wang,
>
>length-hiding is an ESP option.  If it is not used, then the traffic 
>protected by ESP might be more susceptible to traffic analysis.  For 
>some applications, this is not a big deal.  For example: no 
>adversary is going to be surprised that an IP telephone sends 50 
>voice packets a second, nor would any adversary be fooled by the 
>padding.  To my mind, length-hiding is probably incompatible with 
>header compression, though I don't see any security issues that 
>would result from using them in conjunction.
>
>There are other security issues, though.  The fact that the header 
>compression is stateful (i.e., the decompression of a packet depends 
>on the packets that have been received before) means that an 
>adversary can force the receiver into decompressing incorrectly by 
>re-ordering  packets.  The use of message authentication and replay 
>protection doesn't stop this attack.  ESP was designed to be 
>tolerant of packet reorder, so using it with a stateful decompressor 
>is problematic.
>
>There are two ways out of this bind: use a decompressor that won't 
>cause any security failures due to reorder (which requires lots of 
>careful analysis), or authenticate the message *before* it is 
>compressed, rather than after it is compressed (which requires some 
>encapsulation other than ESP).  Jan Vilhuber and I have been working 
>on both of these approaches.  If there is interest, we could bring 
>this work to the IETF, though I'm not sure that WG would be 
>appropriate.
>
>David

David,

If we provide support for ROHC within ESP, then for outbound 
processing, the security checks (matching against the traffic 
selectors) have to be performed prior to compression. This is a 
natural order of processing, since one must match against the 
selectors in order to select the right SA, and then determine that 
the SA in question calls for compression.

At the receiver, similar checks must be performed on the received 
packet, after decompression. But, these checks are performed after 
authentication anyway, so this constraint does not impose an ordering 
requirement on authentication vs. decompression.

If we stick with the IPCOMP model, as Charlie proposed, then 
authentication would occur first, then  decompression, and I think 
that is a reasonable ordering approach, which also addresses the 
concerns you cite above.

The big question for IPsec is whether ROHC can it be considered an 
IPCOMP instance and thus fit within the existing framework.

Steve