[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling of IPcomp in IKEv2
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