On Friday, August 20, 2004 08:25:10 +0200 Niels Möller <nisse%lysator.liu.se@localhost> wrote:
Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:> PS. And also "RFC3526 group 14" doesn't make much sense to me; the > motivation for the "group14" naming we've been discussing have been to > make it *easily* generalizable to new groups that appear in some well > defined (by somebody else) series. Yup. The appropriate phrase would be IKE group 14, preferably with a reference to the aforementioned registry.But then, do we mean ike-1 or ike-2? If these numbers are arbitrarily selected by the ipsec wg, as my understanding is now
They're not selected arbitrarily. There is an IANA registry. If you go look at the registry, you'll see that so far, group numbers have been assigned in sequence, though not all of the groups are MODP groups and not all are defined in the documents we're discussing.So, the problem here was that we borrowed a group defined elsewhere (good), and then gave it our own number which didn't match the number it had in the other place (bad), and did match the number that some other group had in the other place (even more bad).
The proposed solution is "don't do that"; particularly, don't make up our own numbers. As long as we are borrowing groups from that registry, we should borrow the numbers along with them.
We can include a reference to the group table in the Internet Key Exchange Attributes registry at IANA. I think that will be sufficiently non-ambiguous, especially if ikev2 reuses the registry, as it should.
-- Jeff