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

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 14 Apr 2003 09:04:41 +0200

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: "Yaron Sheffer" <[email-masked]>
Date: Mon, 14 Apr 2003 16:26:17 +0300

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)

---

From: [email-masked]
Date: Mon, 14 Apr 2003 22:29:38 -0400

> In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for

I am not familiar with the details of ROHC, so these comments may be
completely out to lunch. If so, just ignore me.

Assuming ROHC is designed to compress an unreliable reorderable packet
stream, it would seem the most natural way to do this would be to define a
new IPcomp compression algorithm based on ROHC. Then the stack would look
like:

PPP | IP(1) | ESP | {IPcomp | {IP(2) | UDP | RTP | Payload}compressed
}encrypted

If ROHC compresses an unreliable but ordered packet stream, it would be
still be possible to implement it, though it would force the decompressing
end to either discard out of order packets or increase latency trying to
reconstruct the original order. If it compresses a reliable packet stream,
it seems inappropriate to use it inside ESP.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).