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

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