Subject: RE: [rohc] FW: ESP and header compression (ROHC)

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

Mark,

At 09:01 AM 4/15/2003 +0100, West, Mark wrote:

>Hi all,
>
>Taking the 'ROHC over re-ordering channels' question more generally; RFC 
>3095 does not work in such an environment.  However, we are (I believe) 
>trying to address this issue as part of ROHC for TCP...
>
>Anyway, tunnels (and especially IPsec) can simply be treated as a 
>link.  In which case, rohc can be applied on that link.
>
>In the case of IPsec/ESP it may make a great deal of sense to compress the 
>headers inside of the tunnel encapsulation.  The VPN endpoints are 
>probably disjoint from any particular physical link that benefits from 
>compression and so, to me, it makes sense to do the compression in the two 
>different places.

yes, I think that's right.  It seems to be the case that inner-tunnel 
header compression is worthwhile for telephony.  Do you think that it would 
be worth doing for wireless links as well?  I guess that the answer might 
depend on the traffic that's going over the VPN link.

There are some subtle security issues with this sort of scheme, but I don't 
think that they're insuperable.

David

>Cheers,
>
>Mark.
>
>
>--
>Mark A. West, Consultant Engineer
>Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
>Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433
>
>
>
>-----Original Message-----
>From: Lars-Erik Jonsson (EAB) [mailto:[email-masked]]
>Sent: 14 April 2003 14:47
>To: 'Yaron Sheffer'; IPSec List; [email-masked]
>Subject: RE: [rohc] FW: ESP and header compression (ROHC)
>
>
>Yaron,
>
>That clarified the scenario, just note that "ROHC over tunnels"
>has not yet been addressed in the ROHC WG. I do not say that
>that there must be problems with that, but it should be noted
>that the link assumptions made for ROHC might not match a
>tunneling case.
>
>Anyway, I am not sure you need anything special in the ESP
>header, but can do per-link compression of the whole chain. You
>would have an outer and an inner IP header, and the ESP header
>would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3).
>
>However, if the inner headers are encrypted, you can of course
>not compress all headers on a per-link basis. Is that the case
>you are considering?
>
>Cheers,
>/L-E
>
>
> > -----Original Message-----
> > From: Yaron Sheffer [mailto:[email-masked]]
> > Sent: den 14 april 2003 15:26
> > To: Lars-Erik Jonsson (EAB); IPSec List; [email-masked]
> > Subject: Re: [rohc] FW: ESP and header compression (ROHC)
> >
> >
> > Hi Lars-Erik,
> >
> > I may have been misunderstood. To clarify, I am discussing
> > the following
> > stack:
> >
> > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload
> >
> > In some cases, depending on the nature of the flows that use
> > the ESP tunnel,
> > ESP plays the role of a link. In those cases, it makes sense
> > to compress the
> > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP
> > conversation there will be a single RTP flow within the
> > tunnel, and ROHC is
> > beneficial for the internal headers.
> >
> > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for
> > IP(2)+UDP+RTP.
> >
> > Regards,
> >     Yaron
> >
> > ----- Original Message -----
> > From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
> > To: "'Yaron Sheffer'" <[email-masked]>; "IPSec List"
> > <[email-masked]>; <[email-masked]>
> > Sent: Monday, April 14, 2003 10:04
> > Subject: RE: [rohc] FW: ESP and header compression (ROHC)
> >
> >
> > > Hi all,
> > >
> > > A few notes:
> > > 1) ROHC is applied on a per-link basis, e.g. over PPP
> > > 2) Based on the above point, there are ROHC compression profiles
> > >    defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only)
> > >
> > > Compressing the network layer header is most important to gain
> > > anything, but that can only be done on a per-link basis. Header
> > > compression is thus applied per-link to compress network and
> > > transport layer headers (and by heuristics also the application
> > > layer RTP header). It is also simpler to do compression per-link,
> > > as one can optimize for certain assumed characteristics (such as
> > > in-order delivery). Further, it makes most sense as header
> > > compression is an optimization for "narrow links".
> > >
> > > Therefore, I can not see why/how one could do "ROHC over ESP".
> > >
> > > BR
> > > /Lars-Erik
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yaron Sheffer [mailto:[email-masked]]
> > > > Sent: den 13 april 2003 21:26
> > > > To: IPSec List; [email-masked]
> > > > Subject: [rohc] FW: ESP and header compression (ROHC)
> > > >
> > > >
> > > > (please reply to both lists)
> > > >
> > > > Below is my question to Steve Kent (author of the new rev
> > of ESP, and
> > > > co-author of the original RFC) and his reply. I understand
> > > > that IPCOMP is
> > > > inferior to ROHC for RTP streams, and I'd like to hear
> > other opinions
> > > > regarding the usefulness of an "ROHC" indicator in ESP.
> > > >
> > > > This might certaily add complexity to IPSec, but if you make it
> > > > non-negotiable and non-mandatory, it cannot be too terrible.
> > > >
> > > > Thanks,
> > > > Yaron
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Kent [mailto:[email-masked]]
> > > > Sent: Thursday, April 10, 2003 12:06 AM
> > > > To: Yaron Sheffer
> > > > Cc: Sara Bitan; [email-masked]
> > > > Subject: Re: ESP and header compression (ROHC)
> > > >
> > > >
> > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote:
> > > > >Hi Steve,
> > > > >
> > > > >I have lately looked at issues with IPSec encryption of RTP
> > > > streams (I am
> > > > >aware of SRTP but I think we will want RTP over IPSec for
> > > > some time to
> > > > >come). A major issue is packet overhead. You can use
> > Robust Header
> > > > >Compression (ROHC) on the external IP+ESP headers - this is
> > > > defined by the
> > > > >ROHC RFC. But if you want to header-compress the RTP packets
> > > > before it is
> > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it
> > > > because there's no
> > > > >way to detect ROHC packets in the ESP header. I'd expect ESP
> > > > to contain a
> > > > >marker for ROHC packets, similarly to PPP. Has this option
> > > > been considered
> > > > >for the new version of ESP?
> > > > >
> > > > >Thanks,
> > > > > Yaron
> > > >
> > > > No, the WG has not considered that option. The WG has
> > been striving
> > > > to make IPsec simpler and thus adding support for ROHC is
> > contrary to
> > > > that theme.  For example, ROHC would have be be implemented within
> > > > IPsec, after the SA lookup was performed, and ROHC decompression
> > > > would have to be implemented in IPsec at the receiver, since the
> > > > receiver has to check the headers against the SAD. IPsec already
> > > > supports IPCOMP as a compression method for whole
> > packets, not just
> > > > headers, and thus it might be hard to persuade the WG to add ROHC
> > > > support too.
> > > >
> > > > But, that's just my impression. You can always raise the
> > > > question on the
> > > > list.
> > > >
> > > > Steve
> > > >
> > > > _______________________________________________
> > > > Rohc mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/rohc
> > > >
> > >
> >
>_______________________________________________
>Rohc mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rohc

---

From: Derek Atkins <[email-masked]>
Date: 15 Apr 2003 12:54:33 -0400

David Mcgrew <[email-masked]> writes:

> > In the case of IPsec/ESP it may make a great deal of sense to
> > compress the headers inside of the tunnel encapsulation.  The VPN
> > endpoints are probably disjoint from any particular physical link
> > that benefits from compression and so, to me, it makes sense to do
> > the compression in the two different places.
> 
> header compression is worthwhile for telephony.  Do you think that it
> would be worth doing for wireless links as well?  I guess that the
> answer might depend on the traffic that's going over the VPN link.
> 
> There are some subtle security issues with this sort of scheme, but I
> don't think that they're insuperable.

It sounds like this is a job for a new IPCOMP algorithm type.  Define
an IPCOMP Algorithm that performs 'ROHC' operations inside the tunnel,
so you get:

        IP ESP IPCOMP IP UDP RTP ...

You could even perform ROHC on the outside packet, too.  Indeed, one
could even use the IPCOMP SA state to pre-configure known compression
points (for example, if the internal network is an IPv4 /24, you could
always reduce one address to a single 8-bit number because the other
24 bits are "understood".  Similar for port numbers, if you have a
limited SA you can put the information into the SA and then strip it
out of the actual packet.

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