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

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 09:17:10 -0800

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.

---

From: Derek Atkins <[email-masked]>
Date: 28 Feb 2003 13:00:20 -0500

> Adding 2 D-H groups to the IPsec suites means 8 more. 

As an implementor I, too, prefer a la carte.  I agree with your
particular arguments.  I happen to disagree with Hugo on the testing
point.  If you've tested 3DES, AES, HMAC-MD5, and HMAC-SHA1 in unit
testing, I don't think you need a complete security analysis of the
full matrix of possibilities.  A block cipher is a block cipher, and
are generally interchangable.

The only argument I've heard that favors suits is from hardware
vendors.  Hardware is not as plug-and-play as software, so you can't
necessarily do any combination.  My answer to that concern is to just
advertize the list of things you support.  You can spell out the
"supported harware suites" using the a la carte methods.

I missed the Atlanta meeting where this was decided (I was chairing
IMPP at the time).  Before the meeting there was a fairly clear
concensus on this list (IMNSHO, after reading ALL the mail on this
list from May 2002 through January 2003 in one sitting) to use a la
carte on the wire but suggest named suites for the (configuration)
user interface.  Indeed, I was shocked to see the mail after the
Atlanta meeting that reversed what I thought was a clear consensus on
the list.  I still maintain that is the "best of all worlds".

>     Dan.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Fri, 28 Feb 2003 14:13:39 -0500

> the list.  I still maintain that is the "best of all worlds".

My observations were that the majority of implementors (at least those that
I recognized, and including myself) voted a-la-carte.

Unfortunately, the users and observers out-voted the implementors.

Clearly from an implementor's standpoint the explosion of a-la-carte
combinations in IKEv1 was a problem (if you wanted to be in "interop with
the world" mode), but this can be solved in better ways than limited suites.

Stephane.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 28 Feb 2003 12:06:37 -0800

I originally supported suites, but then was convinced that a-la-carte is
probably better, especially if you're not going to include the DH group.
I too thought we converged on a-la-carte here on the list, and was
surprised to see suites in the updated doc(s).

Scott

---

From: Paul Koning <[email-masked]>
Date: Fri, 28 Feb 2003 15:44:57 -0500

>>>>> "Dan" == Dan Harkins <[email-masked]> 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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Feb 2003 15:56:40 -0500

I would say me too; but that would be the case for many other items as 
well, such as 4/6 vs. 4.

However, I don't see the point in reopening all the items for yet 
another round of discussion.  If IPsec suites also need to have DH 
group, let us add it.

regards,
Lakshminath

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 28 Feb 2003 16:37:23 -0500

> Unfortunately, the users and observers out-voted the implementors.

I think the best way to accomodate this disconnect is with the old
"gui suites" proposal -- on the wire, send a la carte parameters, but
require only the suite combinations to be supported through the
management interfaces.

						- Bill

---

From: Derrell Piper <[email-masked]>
Date: Fri, 28 Feb 2003 14:04:38 -0800

Bill's suggestion is what I'd like to see: a la carte on the wire, but 
presented as a set of coherent suites.

I also agree with Stephane's recollection vis-a-vis the Atlanta "vote".

Derrell

---

From: Abraham Shacham <[email-masked]>
Date: Fri, 28 Feb 2003 15:28:18 -0800

> is unnecessary and confusing.

Could you substantiate "90%", detail what is exactly "unnecessary",
and "confusing" to whom?

Thanks,
avram

---

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 13:59:35 -0800

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

---

From: Henry Spencer <[email-masked]>
Date: Fri, 28 Feb 2003 20:12:49 -0500 (EST)

On Fri, 28 Feb 2003, Dan Harkins wrote:
> you receive...

No, there is no need for negotiated agreement on that.  It suffices that
the other end sends with an algorithm you have advertised your willingness
to uncompress with.  (Since compression is *always* at the sender's option,
the receiver can never require it.)

Only if the algorithms involve non-trivial parameters that the two ends
must agree on (and which there is no reasonable default for) is actual
negotiation more or less required.

> and what CPI will be used in the IPcomp header that

There is no need for negotiated agreement on that either, since there are
pre-assigned CPIs for the standard algorithms. 

                                                          Henry Spencer
                                                       [email-masked]