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

[Abraham Shacham <shacham@trpz.com>]

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
>                                                        henry@spsystems.net
> 
>