Re: suites vs. a la carte and IPcomp in IKEv2-05

[Abraham Shacham <shacham@trpz.com>]

Henry Spencer wrote:
> On Tue, 4 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote:
> 
>>>The current IKEv2 draft has opted for a more conservative approach than
>>>what some of the list discussion indicated was possible...
>>
>>Let me make sure I understand what you're saying. At one point, I had
>>proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA...
>>Is that what you're talking about?
> 
> 
> Not quite.  The list discussion suggested 

A more accurate way to describe the discussion could be:

   *some* on the list suggested, and others disagreed.

After all, your words yesterday regarding the current content
of IKEv2-05:

    ...but I see no grave disadvantages and hence don't feel
    strongly about it.


> that there is really no need to
> *negotiate* IPComp at all.  It suffices for each end to advertise, as a
> side issue during negotiations, which *decompression* algorithms it is
> willing to use (perhaps in an order of preference, in which case there
> should be a way to signify "no compression" somewhere in the preference
> order -- it isn't necessarily always last choice).  There is no need for
> the two ends to *agree* on anything. 
> 

The current IKE and IKEv2-05 provide IPComp implementations with
a mechanism to negotiate, in other words to agree on, IPComp specific
parameters. That capability is in use in actual implementations.

As for using only the CPIs from the pre-defined range, both the current IKE
and IKEv2-05 provide implementations with a mechanism to use the well-known
CPIs or to negotiate a CPI.  The fact is, most implementations use a CPI
from the negotiated range.

Mandating using the the first over the other is not on the turf of the key
exchange protocol, imo, and IKEv2-05 should continue following that logic.

Regards,
acvram