[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] FW: ESP and header compression (ROHC)
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.
But a tunnel is a re-ordering channel
Tmima
>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
>_______________________________________________
>Rohc mailing list
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc