Dan Harkins writes: > > Brainpool groups do not have number in the IANA registry, which makes > > them private for IKEv1 use. There is nothing there claiming that you > > can only use new group mode to negotiate groups that are not know for > > anybody else. > > "Brainpool groups do not have a number in the IANA registry". What do you > think the topic of this thread is? Look at the subject above. > > You are arguing against doing something because it hasn't been done yet > and that is illogical.
No, I am arguing against it as Brainpool groups CAN ALREADY BE USED in IKEv1 without any changes to the specifications, or to the implementations. IKEv1 does not require every single group to be coded in to every implementation. > You know what? IKEv2 doesn't have any brainpool groups defined in its > IANA registry. Are you against such a code point allocation? If not, then > can I please ask you to be consistent in your positions? IKEv2 cannot use groups which do not have number allocated. There is no way to use brainpool groups in IKEv2 now. Thats why I do think adding them to the IKEv2 IANA registry is something that should be done. IKEv1 and IKEv2 situation is completely different because of that, i.e existing IKEv1 implementation can already use brainpool groups, IKEv2 implementations cannot. > Furthermore, not all implementations support domain parameter sets > being passed in SA payloads (do any?) or New Group Mode so what you > are advocating for causes more of the problems you are trying to use to > justify your advocacy. Our IKEv1 implemention 15 years ago did support both passing them in SA payloads and inside new group mode. I do not know about others. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
