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

[Dan Harkins <dharkins@trpz.com>]

  It appears that IPcomp was forgotten about when the decision was
made to go to suites. IPcomp was later grafted into IKEv2 such that it
is negotiated with NOTIFY payloads in an a la carte fashion. This is
the worst possible scenario! We now have both suites AND a la carte.
And, again, this-- notify payloads after the SA payload in the 
CREATE_CHILD_EXCHANGE-- is one of those things that everyone is going
to have to support. Another mandatory option. The kind of thing we
were supposed to get rid of in IKEv2.

  If we're going to have suites then we should go full bore and
define some with and without IPcomp, and with is LZS and deflate. 
And get rid of the a la carte negotiation with NOTIFY payloads. Either
that or go completely back to a la carte. 

  Also, the suites for IPsec do not contain D-H groups. How does the
responder in the CREATE_CHILD_SA exchange know what group the KEi
payload is from? Guess from the length? That doesn't sound right. I
recommend suites with the 1536 and 2048 bit groups be added. Either
that or go back to a la carte.

  I really prefer a la carte. The argument against-- that all combinations
are not tested-- is really specious. The argument against suites is
that they multiply like rabbits. Supporting IPcomp means 6 more.
Adding 2 D-H groups to the IPsec suites means 8 more. 

  thanks,

    Dan.