Re: Handling of IPcomp in IKEv2

[Avram Shacham <shacham@shacham.net>]

On Mon, 9 Dec 2002, Paul Koning wrote:

> >>>>> "Avram" == Avram Shacham <shacham@shacham.net> writes:
>
>  Avram> Paul,
>
>  Avram> Risking repeating an earlier reply to Radia, the (once again)
>  Avram> attached implementation note from RFC-3173 details scenarios
>  Avram> where negotiated CPIs are required. (In short, when
>  Avram> compression sessions maintain attributes specific to each
>  Avram> session.) Moreover, the alternative to use a well-known CPI is
>  Avram> available in the current protocol, yet most implementations
>  Avram> are negotiating CPIs from 256-61439 range.
>
> I saw that, but I don't see how it applies in the setting Charlie
> proposed.
>
> With IKEv1, it isn't clear whether the CPI numbering is local to the
> compression session "within" the encryption session negotiated as a
> set.
>
> Charlie's proposal is that with IKEv2, it is.  I.e., you are
> negotiating what compression will be used within the context of the
> IPsec SAs.
>
> The question amounts to: do you ever require more than one compression
> session within a SINGLE encryption session?

No.

>
> One case has been suggested: multiple compression algorithms, where
> you can pick one or the other per-packet.

That requirement has never been raised in ippcp wg or on the lists,
and therefore does not seem to be needed.

> Radia's proposal supports that directly, because what was the CPI is
> now the algorithm ID.

That option is already part of the protocol. Still, repeating the
observation, most implementations prefer to negotiate the CPI rather than
use the well-known algorithm numbers.

>
> That leaves the case of two different sessions with the same
> algorithm.  I don't believe that's a real case; do you disagree?
>

Hopefully, we are in agreement :)

Regards,
avram