[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] (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
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc