[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2
Henry,
With your observation that packet size is not the problem, what is the
extra complexity to *announce* a 16-bit CPI and the (optional)
algorithm-related parameters, that you define as
> definitely a simplification -- not a huge one, but noticeable.
Regards,
avram
On Wed, 11 Dec 2002, Avram Shacham wrote:
>
>
> Date: Wed, 11 Dec 2002 09:17:34 -0500 (EST)
> From: Henry Spencer <henry@spsystems.net>
> To: IP Security List <ipsec@lists.tislabs.com>
> Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2
>
> 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
>
>
>