FW: ESP and header compression (ROHC)

["Yaron Sheffer" <yaronf@gmx.net>]

(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