RE: Suites vs a-la-carte

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> Sure we can; we just can't agree to the limited number of numbers
> that we would encode.

I agree with this. One of the reasons I have endorsed GUI suites all along
is that I felt we would be much more likely to get consensus on the base
suites if it were easy to create your own private suites.

Let's say that some company (let's call them IPsecCorp) decides they don't
like the default suite and they want to roll their own. Of course they still
have the mandatory to implement suite, but the default configuration uses
the suite "IPsecCorp2002". If IPsecCorp is the market leader then everyone
is going to want to be compatible with them out of the box. In the
configuration GUI, they will want a droplist of suites where one of the
options is IPsecCorp2002.

If IPsecCorp2002 is using a private ciphersuite number, I would have to go
and figure out what this number is. Then I would probably also have to spoof
their vendor id, which might have unintended consequences. Alternatively, we
could try to create an IANA registry for private ciphersuites. But IANA
would probably deny this request (if I'm not mistaken, they denied a similar
request from the TLS WG). If this was a GUI ciphersuite then there would be
no problem.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Wednesday, November 13, 2002 11:44 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: Suites vs a-la-carte
>
>
> At 11:08 PM +0200 11/12/02, Tero Kivinen wrote:
> >I didn't receive any comments of my previous mail about this issue, I
> >think it was too long or something.
> >
> >Anyways I think the IKEv2 has way too many dimensions to negotiate
> >for suite style negotiation. For IKE SA creation there is 5 different
> >dimensions, and some of them are open ended numbers. For IPsec SA we
> >have about 6 and then at least 2 new extensions.
> >
> >We cannot realisticly encode all that informatin to one
> single number.
>
> Sure we can; we just can't agree to the limited number of numbers
> that we would encode. That is, we can easily say "If you see suite
> #1, it means phase 1 {rsa signature of at least 1024 bits, aes-128,
> sha1, d-h group 2, IKE window size of 5} and phase 2 { aes-128, sha
> auth, no ah, no compression, pfs using d-h group 2, tunnel with
> NAT-T, extended sequence numbers, ECN}". The hard question is how
> many more numbers do we need to allocate to key all IPsec scenarios
> using IKEv2.
>
> >This means that we propably need to have some of those parameters
> >negotiated as a-la-carte style negotiation (Diffie-Hellman group,
> >window size, extension options in IPsec (extended sequence numbers,
> >ECN) etc). If we are going to add the a-la-carte negotiation then I
> >think it is better to everything in same way not to mix
> them, thus use
> >the a-la-carte completely.
>
> Agree.
>
> >We can have gui-suites for the commonly used parameters, but in that
> >case too we might want to include all information to those numbers
> >(like window size).
>
> Agree. The GUI-suites would only be a short-hand for common
> scenarios, and we could probably come to agreement on a set of five
> or so.
>
> --Paul Hoffman, Director
> --VPN Consortium
>