Handling of IPcomp in IKEv2 - Summary

[Charlie_Kaufman@notesdev.ibm.com]

I will try following Radia's lead and summarizing this thread to the list:

I proposed that instead of negotiating a single IPcomp algorithm as part of
an SA bundle, the each end specify the compression algorithms it supports
(for decompression) with the corresponding CPIs and a sender MAY for any
packet use any of the compression algorithms the recipient supports.

Many people expressed support for the idea. No one objected. Some proposed
improvements:

Bill Sommerfeld suggested that  the set of supported compression algorithms
might change dynamically over time because the code libraries that
implement them might be dynamically loaded. And that because of that it
might be better to (A1) require that the sender may only compress with
algorithms he committed to decompress (so that extraneous unmatched
algorithms could be paged out). Or alternatively (A2) to have separate
lists of compression and decompression algorithms. Paul Koning didn't like
requiring that the same algorithms be supported for compression as
decompression (A1) because there might be cases where one direction is
slower and a node might only want to support the fast transformation. Paul
Hoffman objected to the complexity of (A2).

I could live with either of the proposed changes, but both raised
objections. I find the idea of dynamically loaded libraries for IPcomp
compression algorithms farfetched (remember... this is per packet
compression with no remembered state between packets), so my preference
would be to stick with the original proposal which addresses the Pauls'
concerns but not Bill's.

Radia Perlman asked whether there might be few enough compression
algorithms that they might all have two byte CPI values statically assigned
and that nodes could simply say which CPIs they support instead of
dynamically matching algorithms to CPIs.  This would be a significant
simplification if it was true. I have no idea whether it is. Does anyone
know??

Henry Spencer requested that the algorithms be stated in order of
preference, where 'no compression' had a code so that it could be something
other than least preferred.  Order of preference seems right - it's
consistent with the other lists. I find an explicit 'no compression'
unnecessary complexity because everyone must support 'no compression' so
why would anyone want to say 'I support compression X but I'd prefer that
you didn't use it?'. Why not just not admit to supporting X? But I
certainly could live with it if it has advocates.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).