rohc team mailing list archive

[X-Calibre <xcalibre0@xxxxxxxxx>]

The problem with your 1 scenario is that you can not use ROHC on the full ip udp rtp header because you need the IP header intact for ip sec to function properly.  If I compress the IP portion of the header than IPSec can not learn the ipaddress it needs to continue to send the packet along.




________________________________
 From: Didier Barvaux <didier@xxxxxxxxxxx>
To: ROHC Library <rohc@xxxxxxxxxxxxxxxxxxx> 
Sent: Friday, August 2, 2013 10:30 AM
Subject: Re: [Rohc] ROHC and IpSec
 

Hello,

> I'm working with trying to characterize the benefits of ROHC with
> IpSec.
>
> One thing I learned is that most IpSec algorithms must pad the
> payload that they encrypt so that it lies on a 16 byte block size.
> This has interesting ramifications with ROHC, one of which is that I
> can only attain reductions in packet size in discrete 16 byte
> multiples.
>
> One important thing I need to determine is what is the maximum
> compression I can achieve on just the UDP and RTP portion of the
> packet?  I'm assuming the IP portion will remain uncompressed because
> I must maintain an IP header in order for IpSec to function. 

It depends how you use IPsec and ROHC together. I see 2 ways described
below.


1/ ROHC compression, then IPsec tunnel

You got one IP/UDP/RTP/data stream as input. You compress it with ROHC.
You got one ROHC/data stream. Then, you tunnel the compressed stream in
one IPsec tunnel. You got one IP/ESP/encrypted-data, where
"encrypted-data" is the encrypted ROHC/data.

In this scenario, the IPsec padding you mention may reduce the
efficiency of the ROHC compression. Worst case: if ROHC saves a few
bytes but does not reduce the number of complete 16-byte multiples,
then you save nothing.

With ROHC, the IPv4 + UDP + RTP headers are compressed up to 1 or
2 bytes. Uncompressed IPv4 + UDP + RTP weight 40 bytes, so you
typically save 38-39 bytes. In the worst case, you will add 15 bytes of
padding for IPsec, so you win 38 - 15 = 23 bytes. Even with IPsec
padding, ROHC compression is efficient.


2/ IPsec, then ROHC

You got one IP/UDP/RTP/data stream as input. You protect it with
IPsec. You got one IP/ESP/encrypted-data, where "encrypted-data"
is the encrypted IP/UDP/RTP/data. Then you compress it with ROHC. You
got one ROHC/encrypted-data stream. Only the first IP/ESP part is
compressed by ROHC since the 2nd part is not recognizable as IP/UDP/RTP
for the ROHC compressor.

The ROHC compression is less efficient in this scenario since only the
IP and ESP headers are compressed. The padding for IPsec does not
affect the efficiency of the ROHC compression since it is performed
before the compression.


Regards,
Didier


_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to     : rohc@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~rohc
More help   : https://help.launchpad.net/ListHelp