Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2

[Avram Shacham <shacham@shacham.net>]

Paul,

IKE provides a way to establish IPComp sessions with the following:

a. The actual usage of the protocol.
b. Transform Identifier (aka compression algorithm, such as
DEFLATE, LZS, ...) -- one per direction.
c. A 16-bit CPI.
d. Algorithm-related attributes.

Such negotiations are pretty straight forward, and several dozens of
interoperable implementations exist in the market place. (Which implies
extensive discussions in the ippcp and ipsec wgs/lists and bakeoffs.)

What of the above IKEv1 capabilities, if any, Charlie's suggestion plans
to omit? If so, what are the savings -- i.e. in actual bytes in IKEv2
packet? In other words, what is the cost, if any, to keep the current
functionality available in IKEv2?

(Note that nowhere I mentioned IPComp being negotiated as part of a
protocol-suite/menu/a-la carte.  Leaving that issue out was intentional.)

Regards,
avram



On Tue, 10 Dec 2002, Paul Koning wrote:

> >>>>> "Avram" == Avram Shacham <shacham@shacham.net> writes:
>
>  Avram> As long as the generic case (i.e., negotiating a CPI) is also
>  Avram> supported, all should be okay.
>
> I think the whole point of the present proposal is that it eliminates
> any purpose for negotiating a CPI.  I've read over your notes pretty
> carefully but I haven't seen anything that refutes it.  If you
> disagree, you might want to describe a (real world) usage scenario
> that can't be supported by the proposal Charlie made.
>
>      paul
>
>
>