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

["Wang Haiguang" <wanghg@i2r.a-star.edu.sg>]

Hi,

I have also considered this scheme before, that is, compress the header
behind the ESP before encryption and decompress it after decription in the
end-to-end scenario. 

What I am not clear is the effect of header compression to security. 
If I am not wrong, the IPSec has add some padding bytes at the 
end of the packet in order to hide the length of packet. 

If we compress the padding bytes, will it endanger the security of the connection?

Best regards.

Haiguang



>>> Yaron Sheffer <yaronf@gmx.net> 04/14/03 09:26pm >>>
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