No, you won't get "no proposal chosen" or "invalid KE" payload. What you'll get, if you "guess" wrong, is garbage IKEv2 messages because a different representation of the shared secret will be fed into the prf that generates the keying material. That will not be diagnosable. Things just won't work and the customer will get really mad. And if developers aren't reading errata (as you claim) then I seriously doubt that field engineers and support do either. So we're looking at an RMA of a perfectly good piece of equipment.
Your suggested fix does not actually fix the existing problem, it just makes an unambiguous way to negotiate these groups using different numbers. The same ambiguity will still exist for 19, 20, and 21. I think it would be better to fix the problem. You mentioned to Yoav that EC groups are not used that much currently. So this is an opportune time to fix the problem! Dan. On Mon, December 21, 2009 4:05 am, Tero Kivinen wrote: > Dan Harkins writes: >> The solution of allocating new numbers still doesn't really solve the >> problem because if you receive an KE payload from group 19, 20, or 21 >> "you can make your guess whether they also implemented errata or not, >> and act based on that" and that sounds like a recipe for future >> non-interoperability. > > As I just noticed we do support RFC4753 without errata in our previous > versions we need to do something on this. What my current plan would > be to make patch that will change implementations to support errata, > and also change the group numbers to new. This means you get no > proposal support or invalid ke payload notification if you try to talk > to old versions supporting groups 19-21. If the policy allows any of > the modp groups then invalid ke payload error cause both ends to move > to modp groups which means implementations can talk to each other, and > if policy only allows those new groups then you get no proposal chosen > and then you need to modify policy to support some common groups. > >> The IANA registry for these groups is used by more than just IKE(v2) >> and it would be nice if it was coherent and did not make assumption like >> that. > > ikev2-parameters IANA registry should not be used for anything else > than IKEv2. > -- > [email protected] > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
