Re: Handling of IPcomp in IKEv2

[Avram Shacham <shacham@shacham.net>]

Paul,

Risking repeating an earlier reply to Radia, the (once again) attached
implementation note from RFC-3173 details scenarios where negotiated CPIs
are required. (In short, when compression sessions maintain attributes
specific to each session.) Moreover, the alternative to use a well-known
CPI is available in the current protocol, yet most implementations are
negotiating CPIs from 256-61439 range.

As for the negotiation of IPComp within a protection suite or orthogonal
to ESP/AH protocol, as Charlie suggests, both methods look okay.

Regards,
avram

      IPCAs become non-unique when two or more IPComp sessions are
      established between two nodes, and the same well-known CPI is used
      in at least two of the sessions.  Non-unique IPCAs pose problems
      in maintaining attributes specific to each IPCA, either negotiated
      (e.g., lifetime) or internal (e.g., the counters of the adaptive
      algorithm for handling previously compressed payload).  To ensure
      the uniqueness of IPCAs between two nodes, when two or more of the
      IPCAs use the same compression algorithm, the CPIs SHOULD be in
      the negotiated range.  However, when the IPCAs are not required to
      be unique, for example when no attribute is being utilized for
      these IPCAs, a well-known CPI MAY be used.



On Mon, 9 Dec 2002, Paul Koning wrote:

> >>>>> "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
>
>