Re: Handling of IPcomp in IKEv2

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Avram" == Avram Shacham <shacham@shacham.net> writes:

 Avram> ...
 Avram> The elimination of the flexibility to establish protection
 Avram> suites, where compression is attached only to a specific
 Avram> encryption algorithm, could be a problem if those suites
 Avram> describe hardware accelerators, if such accelerators exist.

I've only seen accelerators where compression and encryption are
independent choices.

Obviously, it's possible in theory that a host might offer some
ciphers it has in hardware and some that it does in software, but it
isn't willing/able to handle decompression in software.  But I cannot
imagine that such a case would occur in practice.  The software
vs. hardware performance difference is so large that you would NEVER
offer to do both in the same box -- if you have hardware crypto
support then you will only propose those algorithms that are in
hardware. 

>>>>> "Henry" == Henry Spencer <henry@spsystems.net> writes:

 Henry> 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?

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

I think that's sensible, and the proposed way of doing it certainly is
easy.  

>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:

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

Clearly yes.  Avram quotes the current list (3 entries) which is much
less than 2^16... :-)

I think Radia's suggestion is very good, it eliminates an unnecessary
level of indirection.

      paul