[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (in)security of ESP with header compression
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