Re: Handling of IPcomp in IKEv2

[Avram Shacham <shacham@shacham.net>]

Henry,

The difference seems only in terminology:

* The compression algorithm (LZS, DEFLATE, et al) MUST be stateless, as
defined in RFC-3173:

2. Compression Process
[...]
   Each IP datagram is compressed and decompressed by itself without any
   relation to other datagrams ("stateless compression"), as IP
   datagrams may arrive out of order or not arrive at all.  Each
   compressed IP datagram encapsulates a single IP payload.

* IPComp protocol may contain state information in order to provide better
performance, as defined in section 2.2. "Non-Expansion Policy" of
rfc-3173, and as you precisely described.

Regards,
avram


>
> Date: Mon, 9 Dec 2002 16:27:47 -0500 (EST)
> From: Henry Spencer <henry@spsystems.net>
> To: IP Security List <ipsec@lists.tislabs.com>
> Subject: Re: Handling of IPcomp in IKEv2
>
> On Mon, 9 Dec 2002, Avram Shacham wrote:
> > > local object to hold state for compression -- the compression proper is
> > > usually stateless, but choice of algorithm, intelligent decision on
> > > whether to attempt compression, etc. require local state...
> >
> > The only comment: Compression algorithms in IPComp MUST be stateless.
>
> I would phrase that slightly differently:  *decompression* algorithms in
> IPComp MUST be stateless.
>
> It is not unthinkable to have a compression algorithm which maintains
> state to decide how to *best* compress the next packet -- a generalization
> of the use of heuristics to decide whether to attempt compression --
> provided that the corresponding decompression algorithm can always
> decompress any packet.
>
>                                                           Henry Spencer
>                                                        henry@spsystems.net
>
>
>
>