Re: Handling of IPcomp in IKEv2

[Paul Koning <pkoning@equallogic.com>]

>>>>> "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?  

One case has been suggested: multiple compression algorithms, where
you can pick one or the other per-packet.  Radia's proposal supports
that directly, because what was the CPI is now the algorithm ID.

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

	    paul