[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(in)security of ESP with header compression



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

At 09:30 AM 4/15/2003 +0800, Wang Haiguang wrote:
>To: <Lars-Erik.Jonsson@epl.ericsson.se>, <yaronf@gmx.net>, <rohc@ietf.org>,
>         <ipsec@lists.tislabs.com>
>Subject: Re: [rohc] FW: ESP and header compression (ROHC)
>
>Hi,
>
>I have also considered this scheme before, that is, compress the header
>behind the ESP before encryption and decompress it after decription in the
>end-to-end scenario.
>
>What I am not clear is the effect of header compression to security.
>If I am not wrong, the IPSec has add some padding bytes at the
>end of the packet in order to hide the length of packet.
>
>If we compress the padding bytes, will it endanger the security of the 
>connection?
>
>Best regards.
>
>Haiguang