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

From: David Mcgrew <[email-masked]>
Date: Tue, 15 Apr 2003 06:29:45 -0700

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: <[email-masked]>, <[email-masked]>, <[email-masked]>,
>         <[email-masked]>
>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2003 17:58:21 -0400

At 9:30 AM +0800 4/15/03, Wang Haiguang wrote:
>If we compress the padding bytes, will it endanger the security of 
>the connection?
>
>Best regards.
>
>Haiguang

I do not believe this is a concern.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2003 18:07:46 -0400

At 6:29 AM -0700 4/15/03, David Mcgrew wrote:
>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.
>
>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

---

From: David Mcgrew <[email-masked]>
Date: Wed, 16 Apr 2003 08:04:25 -0700

Steve,

At 06:07 PM 4/15/2003 -0400, Stephen Kent wrote:
>>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 
>>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 
>>protection doesn't stop this attack.  ESP was designed to be tolerant of 
>>packet reorder, so using it with a stateful decompressor is problematic.
>>
>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.
>
>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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Apr 2003 12:56:37 -0400

David,

The ESP processing order at the receiver is authenticate then 
decrypt, IF there are separate authentication and encryption 
algorithms employed, i.e., the common case today. The structure of 
the payload requires this, since the integrity check is applied to 
the ciphertext, not the plaintext, by the sender.

That says that the transmitter processing order is:
	- map to SA (the outbound access control check)
	- compress if appropriate
	- encrypt
	- integrity check

At the receiver the processing is defined as:
	- map to SA using SPI ( a demuxing operation, not a security check)
	- validate sequence number
	- integrity check
	- decrypt
	- decompress if appropriate
	- check against selectors (the inbound access control check)

Sorry for any confusion re my previous response in not spelling out 
all the steps and why they are performed in the order indicated.

Given this ordering of processing steps, it would seem that the main 
issue for a stateful compression algorithm like ROHC is to be smart 
about reacting to out of order arrival, a fact of life if it is to be 
used in the IPsec context.

Steve

---

From: Derek Atkins <[email-masked]>
Date: 16 Apr 2003 13:21:06 -0400

David Mcgrew <[email-masked]> writes:

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

It depends on your definition of "stateless."  I believe that you can
have "state" (just like you require cryptographic "state" in order to
process ESP or AH).  However, the key is that there is no inter-packet
state.  That requirements stems from 2401 (IIRC), due to the IPsec
architecture treating each packet individually.

So, I don't see why IPCOMP should be any different than ESP or AH in
terms of packet independence.  If ROHC is truly dependent on packet
ordering, then I think this is a bug in ROHC and needs to be addressed
there.  It certainly limits the types of links in which ROHC can be
used.

> 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

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: David Mcgrew <[email-masked]>
Date: Wed, 16 Apr 2003 13:08:40 -0700

Derek,

>architecture treating each packet individually.

That makes sense.   For the record, the IPCOMP definition concerns 
inter-packet state, it says that "each IP datagram is compressed and 
decompressed by itself without any relation to other datagrams".

>there.  It certainly limits the types of links in which ROHC can be

IPHC and ROHC were designed with links in mind, but there is now interest 
in adapting them for use at the internetwork layer.  The AVT WG enhanced 
compressed RTP is one of these efforts.  I think that there's similar 
interest in ROHC WG, though I am less familiar with that work and should 
let someone from that group comment.  I don't think that it's a bug that 
the compression methods assume a reliable link, since compression is much 
easier when you can make that assumption.  But certainly a more robust 
compression scheme would be more generally useful.

thanks,

David

---

From: Henry Spencer <[email-masked]>
Date: Wed, 16 Apr 2003 16:39:38 -0400 (EDT)

On Wed, 16 Apr 2003, David Mcgrew wrote:
> >...[IPComp] the key is that there is no inter-packet state...
> 

And in fact, a careful reading of the specification tells you that this is
a bit mis-stated:  compression implementations are not just permitted but
encouraged to keep inter-packet state, e.g. to decide whether it is worth
trying to compress the next packet.  It's *decompression*, and only
decompression, which must not keep inter-packet state.  (And that is both
necessary and sufficient to make IPComp robust against loss or reordering
of packets.)

                                                          Henry Spencer
                                                       [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Apr 2003 15:51:39 -0700 (PDT)

> necessary and sufficient to make IPComp robust against loss or reordering

Well, I dunno what difference it makes because ROHC is
pretty stateful on both sides...

		Mike