[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling of IPcomp in IKEv2
>>>>> "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