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

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



Hi Lars-Erik,

You are right, I was considering the encrypted case. ESP is only interesting
if the inner headers (and the payload, of course) are encrypted. Which is
why you need to compress the inner part before encryption, and the outer
part after.

You'd need a special marker in the ESP header to denote a compressed packet,
just as you do in PPP. The existing ESP (RFC 2406) has a Next Header field,
which contains a "protocol number" (see
http://www.iana.org/assignments/protocol-numbers). For ESP in "tunnel mode"
this field holds the value for IP. AFAIK, there is no value for ROHC.

Best regards,

    Yaron
----- Original Message -----
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Yaron Sheffer'" <yaronf@gmx.net>; "IPSec List"
<ipsec@lists.tislabs.com>; <rohc@ietf.org>
Sent: Monday, April 14, 2003 16:46
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:yaronf@gmx.net]
> > Sent: den 14 april 2003 15:26
> > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org
> > 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)" <Lars-Erik.Jonsson@epl.ericsson.se>
> > To: "'Yaron Sheffer'" <yaronf@gmx.net>; "IPSec List"
> > <ipsec@lists.tislabs.com>; <rohc@ietf.org>
> > 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:yaronf@gmx.net]
> > > > Sent: den 13 april 2003 21:26
> > > > To: IPSec List; rohc@ietf.org
> > > > 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:kent@bbn.com]
> > > > Sent: Thursday, April 10, 2003 12:06 AM
> > > > To: Yaron Sheffer
> > > > Cc: Sara Bitan; kent@bbn.com
> > > > 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
> > > > Rohc@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/rohc
> > > >
> > >
> >
>