Re: Handling of IPcomp in IKEv2

[Henry Spencer <henry@spsystems.net>]

On Tue, 3 Dec 2002, Paul Hoffman / VPNC wrote:
> >But come to think of it, that's easy to support.  The way to do this
> >is to have each side announce what it can DEcompress (not compress).
> >In other words, what it will accept inbound.
> 
> This seems fine too, and seems to cover the situation you believe in.

A further point:  there should be the ability to express a preference
ranking (e.g., the announcement lists acceptable algorithms in preference
order), and there should be a "no compression" value so it can be ranked
too.

Back when I was with the FreeS/WAN project, when we first looked at
compression, even without the issue of algorithm choice we concluded that
there were plausible uses for all four rankings (never compress; okay to
compress but uncompressed preferred; compression preferred; compression
mandatory).  We did not implement all four, but that was mostly a matter
of a quick, simple first-cut implementation that never got revisited. 

("Compression mandatory" is a slight misnomer, since even with IPComp
negotiated, the sender may decide not to compress any particular packet. 
It should be read as "compression strongly desired".)

                                                          Henry Spencer
                                                       henry@spsystems.net