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

[Henry Spencer <henry@spsystems.net>]

On Tue, 10 Dec 2002, Avram Shacham wrote:
> IKE provides a way to establish IPComp sessions with the following:
> a. The actual usage of the protocol.
> b. Transform Identifier (aka compression algorithm...
> c. A 16-bit CPI.
> d. Algorithm-related attributes.
> What of the above IKEv1 capabilities, if any, Charlie's suggestion plans
> to omit?

It makes (c) superfluous, and omits (d) except insofar as you might be able
to do a little of it by using different predefined identifiers.

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

Bytes in the packet are surely the least of our concerns!  Not entirely
insignificant, to be sure, but they are *not* the primary measure of cost. 
If there was a protocol which could do IKEv2's job and could be described
clearly in two pages, at the cost of making the packets three times as
big, people would be trying very hard to make it work.  The primary cost
measure for IKEv2 is protocol complexity, not packet size.  Converting
negotiations into announcements, as this proposal does, is definitely a
simplification -- not a huge one, but noticeable. 

                                                          Henry Spencer
                                                       henry@spsystems.net