On Wed, July 18, 2012 3:12 pm, Tero Kivinen wrote: > Dan Harkins writes: >> > I would be strongly against for including support for protocol which >> > has been obsoleted 7 years ago. If people want to use this kind of >> > groups in IKEv1 they can use the new group mode and negotiate groups >> > on the fly. There is no need to add them to IKEv1. >> >> In spite of this designation IKEv1 is still widely used and I would >> posit >> that it is used more than IKEv2. > > It is widely used, but that does not mean we need to keep adding > everything there. I do not think that is that much more widely > implemented anymore. I would expect most of the implementations do > support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough.
Nobody said anything about "adding everything". That is a complete straw man argument. In fact, it is decidedly not the case that "everything" is being added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick to leap to unfounded conclusions you would see this IANA update as the innocuous event that it really is. This is allowing existing implementations to have more flexibility in the ECDH operations they perform to comply with various requirements that may exist in different locales or in different circumstances or situations. >> IKE already has the way to handle new domain parameter sets that are >> publicly defined and that is through the IANA registry. Your suggestion >> to >> use New Group Mode to use brainpool ECC groups would only hamstring >> IKEv1 and make it harder to use. > > I think otherwise, as using new group mode allows using them without > changing any single line of code, provided the IKEv1 implementation do > support ECP groups at all (and support the new group mode which is > SHOULD). There is a capability in New Group Mode to accept or reject the proposal and this is to allow the recipient to verify that the group is acceptable. Enabling this in IKEv1 for the brainpool curves would be substantially more code than just using the existing code point interface that all implementation have. > This is exactly why new group mode was made a SHOULD in the IKEv1, > i.e. to allow adding new groups without need to changing the > specification or the actual code. Your recollection differs from the person who actually wrote the RFC. And when that happens one should typically defer to the author. In fact, your statement seems to differ from the RFC which says it SHOULD be supported as a mechanism to define "private groups". The brainpool groups are not private and there is no reason to treat them as such. Since groups added with New Group mode MUST be assigned private code points it would result in a case of code bi-furcation because the same domain parameter sets would be accessed using different code points. That's unnecessary code complication for implementations that support both IKEv1 and IKEv2. > I agree that there might be implementations which do not support it, > and for example I think we disabled it from our implementation when we > added IKEv2 support, as we wanted to keep the feature set provided by > our implemenation about the same regardless whether IKEv1 or IKEv2 is > used, and IKEv2 do not support such feature. > >> It would be a blunt club to force people into doing something that >> they haven't decided to do on their own (to your apparent chagrin). > > I agree on that. I do try to convince to switch to IKEv2, as it is > MUCH better protocol and works much more robustly and has standarized > features for things which IKEv1 only has multiple non-standardized > non-interoperable protocols. And bully for you! I wish you much success in your advocacy. Actively trying to make people's programmatic lives worse because your advocacy isn't as successful as you'd like is a completely different matter though and is, I think, inappropriate. The fact that you admit you want a blunt club to force compliance with your wishes speaks volumes. >> The IETF does not have a lot of success at forcing people to do things >> they do not want to do on their own and I think this sort of thing is >> somewhat inappropriate. > > We do not need to keep adding features to the old obsoleted protocoles > either. This is NOT a feature. ECDH already exists in IKEv1. This is allowing existing implementations, of which they are legion, to use certain domain parameter sets that may be required or desired in certain situations and in certain locales. >> Why there are two identical repositories to map unsigned shorts to >> complete domain parameter sets is beyond me but there are. These >> two repositories have been updated in concert in the past and and there >> is no good reason to have them diverge now. > > There is multiple repositories for diffie-hellman parameters. IKEv1, > IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories > etc. Registries are cheap, there is no point of reusing them for > completely different purposes. There is no reason for different repositories for IKEv1 and IKEv2. They are identical with the exception that the EC2N groups were removed in the IKEv2 repository. Interestingly, the number space that is EC2N in IKEv1 is "reserved" in IKEv2 and this is done, apparently, to have symmetry in group definitions. This way implementations can share the same mapping from code point to domain parameter set. The IKEv1 repository for Diffie-Hellman groups has been updated in the past after its designation as "deprecated". We should follow precedent and continue to keep these repositories in harmony. Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
