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

[Abraham Shacham <shacham@trpz.com>]

Henry Spencer wrote:
> On Mon, 3 Mar 2003, Abraham Shacham wrote:
> 
>>Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from
>>the pre-assigned transform ID range is mentioned, afaik.
> 
> 
> The current IKEv2 draft has opted for a more conservative approach than
> what some of the list discussion indicated was possible.  I'm personally a
> bit disappointed, but I see no grave disadvantages and hence don't feel
> strongly about it. 
> 

Reaching a consensus, even a rough one, is always the goal, thanks.

> 
>>Please note that using a CPI from the predefined range has its limitation,
>>as the implementation notes in RFC-3173 detail.
> 
> 
> The implementation notes describe difficulties that some implementations
> might encounter, but which careful design can entirely avoid in the
> context of IPsec.  (IPComp processing in IPsec is always associated with
> at least one IPsec SA, which eliminates any "which connection?" ambiguity
> arising from use of predefined CPIs.)

Using the IPsce SA to define the IPComp session is an approach
implementations may elect to use.  Establishing a unique IPComp CPI
per session -- as most current implementations do, afaik --
is another legitimate approach for sure.  Mandating the first over the other
is not on the turf of the key exchange protocol, imo, and IKEv2-05 in fact
follows that logic.


Thanks,
avram