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

From: Abraham Shacham <[email-masked]>
Date: Mon, 03 Mar 2003 00:05:43 -0800

Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from
the pre-assigned transform ID range is mentioned, afaik.

On the other hand, IPCOMP-SUPPORTED (page 54) seems to provide all
the parameters available via IKEv1, namely 16-bit CPI, 8-bit transform ID,
and optional attributes:

         IPCOMP-SUPPORTED                         24581

             This notification may only be included in a message
             containing an SA payload negotiating a CHILD-SA and
             indicates a willingness by its sender to use IPcomp on this
             SA. The data associated with this notification includes a
             two byte IPcomp CPI followed by a one octet transform ID
             optionally followed by attributes whose length and format is
             defined by that transform ID. A message proposing an SA may
             contain multiple IPCOMP-SUPPORTED notifications to indicate
             multiple supported algorithms. A message accepting an SA may
             contain at most one.

Please note that using a CPI from the predefined range has its limitation,
as the implementation notes in RFC-3173 detail.

Regards,
avram

Henry Spencer wrote:
> On Fri, 28 Feb 2003, Dan Harkins wrote:
> 
>>  You do have to agree on something. Namely, which of the 3 possible
>>compression algorithms you will be using to uncompress the data
>>you receive...
> 
> 
> No, there is no need for negotiated agreement on that.  It suffices that
> the other end sends with an algorithm you have advertised your willingness
> to uncompress with.  (Since compression is *always* at the sender's option,
> the receiver can never require it.)
> 
> Only if the algorithms involve non-trivial parameters that the two ends
> must agree on (and which there is no reasonable default for) is actual
> negotiation more or less required.
> 
> 
>>and what CPI will be used in the IPcomp header that
>>encapsulates that compressed data.
> 
> 
> There is no need for negotiated agreement on that either, since there are
> pre-assigned CPIs for the standard algorithms. 
> 
>                                                           Henry Spencer
>                                                        [email-masked]
> 
>

---

From: Henry Spencer <[email-masked]>
Date: Tue, 4 Mar 2003 12:04:27 -0500 (EST)

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

> 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.)

                                                          Henry Spencer
                                                       [email-masked]

---

From: Abraham Shacham <[email-masked]>
Date: Tue, 04 Mar 2003 10:18:48 -0800

> bit disappointed, but I see no grave disadvantages and hence don't feel

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

> 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