Re: Handling of IPcomp in IKEv2 - Summary

[Henry Spencer <henry@spsystems.net>]

On Sat, 7 Dec 2002 Charlie_Kaufman@notesdev.ibm.com wrote:
> ...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?

The whole point of having the list in preference order is that some
choices are *better* than others, even if they are all supported.  "No
compression" is a choice; hardwiring it to always be at the end of the
list seems dubious.  A host with plenty of network bandwidth but rather
limited CPU power might well be willing to support compression, but prefer
that it not be used.  Putting "no compression" first, for example, means
"compress only if it's really important on your end". 

While it has been suggested that the CPU savings on encryption/decryption
more than make up for CPU expended on compression/decompression, I've seen
test results showing that this is not necessarily true.

Faced with a difference between the far end's preferences and its own
preferences, of course, an implementation just has to make a decision. 

                                                          Henry Spencer
                                                       henry@spsystems.net