Re: suites vs. a la carte and IPcomp in IKEv2-05

[Dan Harkins <dharkins@trpz.com>]

  Well strictly speaking there isn't (and never was) any _real_
negotiation. It was "I can do A or B or C" and a reply of "B".

  That's what is being done with IPcomp in the current draft.
Alice says, "I can do LZS with CPI of X or Deflate with CPI of Y" and
Bob says, "LZS with CPI of Z". Then two "security associations"
for IPcomp are created with CPIs X, for Bob to Alice, and Z for
Alice to Bob. That's the same as "a la carte" for the cryptographic
parameters.

  You do have to agree on something. Namely, which of the 3 possible
compression algorithms you will be using to uncompress the data
you receive and what CPI will be used in the IPcomp header that
encapsulates that compressed data.

  Dan.

On Fri, 28 Feb 2003 15:44:57 EST you wrote
> >>>>> "Dan" == Dan Harkins <dharkins@trpz.com> writes:
> 
>  Dan> It appears that IPcomp was forgotten about when the decision was
>  Dan> made to go to suites. IPcomp was later grafted into IKEv2 such
>  Dan> that it is negotiated with NOTIFY payloads in an a la carte
>  Dan> fashion.
> 
> I thought the plan was to announce (NOT negotiate) the ability to
> decode IPcomp.  You don't need negotiation, because there's no need to
> agree on anything.  All that you need is to announce the ability to
> decompress, and then the sender can compress accordingly if and when
> it chooses.
> 
> IKEv1 handled this by negotiation, but 90% of what it does for IPcomp
> is unnecessary and confusing.
> 
>    paul
>