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

[David Mcgrew <mcgrew@cisco.com>]

Steve,

At 06:07 PM 4/15/2003 -0400, Stephen Kent wrote:
> 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.
agreed.


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

No, the IPCOMP model doesn't solve the problem, I fear that I've not been 
clear enough when I said 'authenticate before compression'.  The use of a 
compression algorithm that maintains state between packets is a potential 
security problem because the reordering of packets can confuse the state 
machine in the decompressor.  Since it's a design goal of ESP to tolerate 
packet reorder, there is nothing stopping an attacker from reordering 
packets in order to confuse the receiver.

One way to thwart this attack is to apply the message authentication to the 
uncompressed data, rather than the compressed data.   So the processing on 
the sender would be authenticate/compress/encrypt, while on the receiver it 
would be decrypt/decompress/authenticate.  Since the receiver performs the 
authentication check after the decompression, this check catches 
decompression errors.   This point is what I'd meant by 'auth before comp'.


> The big question for IPsec is whether ROHC can it be considered an IPCOMP 
> instance and thus fit within the existing framework.
The IPCOMP spec is only intended for stateless compression algorithms.  It 
doesn't say if this is because of the security issue due to packet reorder 
or not; this might just be an assumption of the authors.

Another point about IPCOMP is that it would be useful in exactly the same 
situations that header compression would be useful.  It is probably 
desirable to allow the use of both mechanisms simultaneously.  I am not 
sure if IPCOMP allows multiple compression methods, but I suspect that it 
does not.

IPHC is also of interest as well, though I don't think that it raises any 
issues that ROHC doesn't.

David



> Steve
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc