[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] FW: ESP and header compression (ROHC)
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.
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:Lars-Erik.Jonsson@epl.ericsson.se]
Sent: 14 April 2003 14:47
To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org
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
> > >
> >
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to Roke
Manor Research Ltd and must not be passed to any third party without permission. This
communication is for information only and shall not create or change any contractual
relationship.