Re: some questions about IPComp

[Avram Shacham <[e-mail]>]

Xuechen,

At 01:54 PM 3/22/98 -0600, Xuechen Yang wrote:
>Hello all,
>
>I'm a software engineer from Ashley Laurent. I'm working on IPSec and IPComp
>software solution based on NT and Unix.
>
>I got a few questions about IPComp:
>
>(1) Why IPComp can only work in transport mode?
>
>Although the draft doesn't say anything about "Tunnel mode" or "Transport
>mode", it implies that IPComp cannot be applied in tunnel mode. I understand
>working in tunnel mode will introduce more overhead for compression, which
>is not the good for IPComp. But IPComp will face the same problem that AH
>and ESP (transport mode) have. You cannot use it for the communication
>between IPComp gateways, or between remote host and IPComp gateway; unless
>combine IPComp with tunnel mode AH or ESP.

rfc-2003 "IP Encapsulation within IP" clearly defines how to "tunnel."  To
implement IPComp "tunnel", first apply rfc-2003 and then IPComp. The steps are

original datagram    IP ULP
rfc-2003             IP IP ULP
IPComp               IP IPCOMP IP ULP

>(2) Why compression must be applied before encryption?
>
>Well, I understand this rule makes the architecture more clean and easy to
>implement. (From my viewpoint, it will be more flexible if the
>implementation can process IPSec and IPComp in any order. ) But is that
>possible that under certain situation, applying compression after encryption
>may gain higher compression ratio? 

<draft-ietf-ippcp-protocol-05.txt> states:

1. Introduction

[...]

   IP payload compression is especially useful when encryption is
   applied to IP datagrams.  Encrypting the IP datagram causes the data
   to be random in nature, rendering compression at lower protocol
   layers (e.g., PPP Compression Control Protocol [RFC-1962])
   ineffective.  If both compression and encryption are required,
   compression MUST be applied before encryption.

>Let's say the upper transport sends down
>a non-compressible payload (could have been compressed already, or might be
>a JPG image or MPEG clip), it won't do any good if applying compression
>again. Then skip compression and do encryption according to local security
>policy. So how about compressing the data after encryption since the
>encryption makes the data more random? Maybe even worse, since every byte
>becomes more independent and unpredictable. Just a thought.
>I'm not an expert on encryption and compression, I just thought it's
>interesting.

As for previously compressed payloads, compression at L3 will fail. The
document provides a recommendation to avoid the performance hit by applying
an adaptive algorithm:

2.2. Non-Expansion Policy

[...]
   An IP datagram with payload that has been previously compressed
   tends not to compress any further.  The previously compressed payload
   may be the result of external processes, such as compression applied
   by an upper layer in the communication stack, or by an off-line
   compression utility.  An adaptive algorithm should be implemented to
   avoid the performance hit.  For example, if the compression of i
   consecutive IP datagrams of an IPCA fails, the next k IP datagrams
   are sent without attempting compression.  If the next j datagrams
   are also failing to compress, the next k+n datagrams are sent without
   attempting compression.  Once a datagram is compressed successfully,
   the normal process of IPComp restarts.  Such an adaptive algorithm,
   including all the related thresholds, is implementation dependent.

avram