Subject: RE: (in)security of ESP with header compression

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 16 Apr 2003 22:17:55 +0200

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

The RFC 3095 profiles are defined with an assumption on in-order delivery
from compressor to decompressor, but modified profiles could easily be
defined to tolerate packet misordering. The ROHC WG just has not yet 
addressed this issue, but we would appreciate input on the subject,
especially motivations for us to look at it.

BR
/L-E

---

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

Lars,

> especially motivations for us to look at it.

And this thread isn't sufficient motivation?  Summerizing the thread,
it would be useful to use ROHC to compress ESP tunnels, but that
implies the potential for out-of-order reception.

> /L-E 

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "Yaron Sheffer" <[email-masked]>
Date: Fri, 18 Apr 2003 00:59:53 +0200

ESP includes a 32-bit sequence number. It is mandatory for the sender to set
and increment it correctly, but optional for the receiver to verify it. It
is there to prevent malicious replay of messages.

In the case of ROHC over ESP, if the receiver's policy is to delete packets
with an out-of-order ESP sequence number (possibly using a small reorder
buffer), then packets reaching the decompressor are always in order. The
channel is not reliable of course, since entire packets may be deleted. All
in all, this channel becomes analogous to your plain vanilla PPP.

Applicability: in general, IP (and ESP) packets may be drastically
reordered, with packets coming in many seconds out of order. For Internet
telephony, those packets are useless and can be discarded on arrival.

Under these assumptions, I don't believe any change to the operating
assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC
over tunnels" but only "ROHC over ESP", but it's still an interesting case.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Lars-Erik
Jonsson (EAB)
Sent: Wednesday, April 16, 2003 10:18 PM
To: Derek Atkins
Cc: [email-masked]; [email-masked]
Subject: [rohc] RE: (in)security of ESP with header compression

BR
/L-E
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Paul Koning <[email-masked]>
Date: Thu, 17 Apr 2003 20:08:41 -0400

>>>>> "Yaron" == Yaron Sheffer <[email-masked]> writes:

 Yaron> ESP includes a 32-bit sequence number. It is mandatory for the
 Yaron> sender to set and increment it correctly, but optional for the
 Yaron> receiver to verify it. It is there to prevent malicious replay
 Yaron> of messages.

 Yaron> In the case of ROHC over ESP, if the receiver's policy is to
 Yaron> delete packets with an out-of-order ESP sequence number
 Yaron> (possibly using a small reorder buffer), then packets reaching
 Yaron> the decompressor are always in order. The channel is not
 Yaron> reliable of course, since entire packets may be deleted. All
 Yaron> in all, this channel becomes analogous to your plain vanilla
 Yaron> PPP.

 Yaron> Applicability: in general, IP (and ESP) packets may be
 Yaron> drastically reordered, with packets coming in many seconds out
 Yaron> of order. For Internet telephony, those packets are useless
 Yaron> and can be discarded on arrival.

 Yaron> Under these assumptions, I don't believe any change to the
 Yaron> operating assumptions of ROHC, or a new ROHC profile, is
 Yaron> needed. This is not "ROHC over tunnels" but only "ROHC over
 Yaron> ESP", but it's still an interesting case.

Maybe.  But your assumption is questionable.  One could build ESP like
that, but I've never heard of anyone doing it.  The typical
implementation will accept packets that are out of order WITHOUT
putting them back in order, provided they are not out of order by more
than a "window" amount.  A typical window is 64, because that's the
max size of an easy to do bitmap, but it's not significantly harder to
make it bigger, and the cost is only a a bit per unit of distance.

So your assumption that ESP (with integrity) is a lossy ordered
channel is unlikely to be valid.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 08:41:50 -0400

>over tunnels" but only "ROHC over ESP", but it's still an interesting case.

I may not have understood your argument, but any solution we would 
adopt for IPsec use of ROHC must be general, i.e., it cannot depend 
on specific receiver constraints re anti-replay window parameters. 
Also, your message suggests a possible misunderstanding re IPsec and 
anti-replay: I know of no IPsec implementation that reorders packets 
upon arrival and doing so is certainly outside the scope of what the 
RFCs call for.

Steve

---

From: "Yaron Sheffer" <[email-masked]>
Date: Fri, 18 Apr 2003 21:48:16 +0200

Hi Steve,

I see a trade-off here between tweaking ROHC to deal with reordering
channels (it may be easy or hard, I don't know) and tweaking the ESP
*implementation* to undo such reordering. I accept that the RFC doesn't
mandate or even suggest it, and from an architectural perspective it's not
clean. But it's a minor change to the implementation of sequence-number
handling in ESP, which can be spelled out specifically in a "Header
compression over ESP" draft. Otherwise you need to work very hard to
implement ROHC (or CRTP, or ECRTP) securely over ESP, going through
contortions like the proposed authentication-before-compression (sorry
David).

Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a
IPCOMP_SUPPORTED notification, which can be extended (and renamed to
COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that
ROHC should be an IPComp profile, only that it's negotiated in an analogous
manner. IPComp makes different assumptions regarding traffic (packet
lengths) compared to ROHC, and therefore probably doesn't do the job here.
But this is for the ROHC people to judge.

I am being somewhat simplistic, you may need to negotiate some basic
compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE,
LZS} values of this field.

Speaking about the IPSec architecture, it's a pity that compression
parameters remain an integral part of IKE v2, rather than add-ons.

Best regards,
	Yaron

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, April 18, 2003 2:42 PM
To: Yaron Sheffer
Cc: Lars-Erik Jonsson (EAB); Derek Atkins; [email-masked];
[email-masked]
Subject: RE: [rohc] RE: (in)security of ESP with header compression

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 15:09:53 -0400

>contortions like the proposed authentication-before-compression (sorry

Well, ESP has been around for a while; RFC 2406 was published in 
November of 1998. I don't think we can reasonably ask implementors to 
change their implementations to accommodate ROHC. Also, as you note, 
it is not architecturally attractive, since IP would not reorder the 
traffic and IPsec tries to minimize the differences between what the 
IP interface does and what IPsec does. We had to impose the notion of 
a receive window as a tradeoff in this regard, to make anti-replay 
feasible yet not too hard for an IPsec implementation.

Also, as we go to higher speeds, asking an IPsec implementation to 
buffer inbound traffic places a significant burden on the 
implementation, since this would have to be done in hardware that is 
trying to operate at line rates.

>But this is for the ROHC people to judge.

I understand.

>parameters remain an integral part of IKE v2, rather than add-ons.

IKE is really  a security association management protocol and if 
compression is part of the SA processing, then we have to negotiate 
its use and parameters when we establish an SA. Key management is the 
easy part :-).  All the complexity is in the SA management part.

Steve

---

From: Paul Koning <[email-masked]>
Date: Fri, 18 Apr 2003 16:44:52 -0400

>>>>> "Yaron" == Yaron Sheffer <[email-masked]> writes:

 Yaron> Hi Steve, I see a trade-off here between tweaking ROHC to deal
 Yaron> with reordering channels (it may be easy or hard, I don't
 Yaron> know) and tweaking the ESP *implementation* to undo such
 Yaron> reordering. I accept that the RFC doesn't mandate or even
 Yaron> suggest it, and from an architectural perspective it's not
 Yaron> clean. But it's a minor change to the implementation of
 Yaron> sequence-number handling in ESP...

Nonsense.  It's a very major change in the implementation of ESP.

ESP processes IP packets one at a time.  It does not care whether they
are being reordered; it does not, repeat NOT, put them in any order
different from the order in which they arrived.

To do what you suggest would be a large redesign, which would also
completely ruin performance.  ("Fragmentation considered Harmful" by
Jeff Mogul explains this nicely, for a different case where the same
considerations are valid.)

Note also that there are a bunch of ESP implementations done in
silicon.  For those, what you propose is even more unreasonable than
it would be for a software implementation.  But I don't think any
implementer of either kind of implementation would consider your
proposal.

	paul

---

From: "Yaron Sheffer" <[email-masked]>
Date: Fri, 18 Apr 2003 21:48:16 +0200

Hi Steve,

Best regards,
	Yaron

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, April 18, 2003 2:42 PM
To: Yaron Sheffer
Cc: Lars-Erik Jonsson (EAB); Derek Atkins; [email-masked];
[email-masked]

Steve

---

From: Paul Koning <[email-masked]>
Date: Fri, 18 Apr 2003 16:44:52 -0400

paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 15:09:53 -0400

I understand.

Steve