RE: Suites vs a-la-carte

[Black_David@emc.com]

And Tero thought he'd listed everything ... not quite - add

9) DSCP (DiffServ Code Point) handling at tunnel egress (discard
	outer vs. copy outer-to-inner).

Explanation and rationale should be coming in a
rfc2401bis draft at some point.  I agree with Tero that
a single number to encode everything won't work, but would
like to see combination of related options into a singly
negotiable elements in order to exclude incompatible or
otherwise ridiculous combinations and simplify the
resulting negotiation.  This should also provide the
desired resistance to "vanity crypto".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, November 12, 2002 4:08 PM
> To: ipsec@lists.tislabs.com
> Subject: Suites vs a-la-carte
> 
> 
> 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.
> 
> 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.
> 
> 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).
> 
> Just for the reminder here is the list of things we need to encode as
> one single number in IKE SA:
> 
> 1) authentication algorihtm
>    - rsa signatures, dsa signatures?, pre-shared keys?
> 2) encryption algorithm
>    - 3des, aes-128, aes-192?, aes-256?
> 3) hash/prf algorithm
>    - sha1, md5?, sha2-256?, sha2-384?, sha2-512?
> 4) Diffie-Hellman group
>    - group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144,
>    8192 bit) groups
> 5) Window size fof IKE
>    - 1, 10? ???
> 
> And for the IPsec SA there would be:
> 
> 1) encryption algorithm for the ESP
>    - 3DES, AES, NULL
> 2) authentication algorithm for the ESP
>    - no auth, MD5, SHA
> 3) authentication algorithm for the AH
>    - no AH, MD5, SHA
> 4) IPComp algorithm
>    - Deflate, LZS?, OUI?
> 5) Diffie-Hellman group for PFS (if we do support PFS)
>    - group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
>    8192 bit) groups
> 6) Tunnel / transport / UDP-tunnel / UDP-transport
>    - Tunnel mode / transport mode and NAT-T udp encapsulations
> 7) Use of extended sequence numbers
>    - on/off
> 8) ECN
> -- 
> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>