Dan Harkins writes: > 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.
If we allocate new numbers and change to use them, then you DO get no proposal chosen and invalid IKE payloads. What you explaining there is what happens now when someone tries to use those ecp groups between two implementations which do not agree on errata or not. > 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. Yes, but all of those groups are marked "OBSOLETED" or "Reserved (was xxx)" in the iana-registry, and the RFC4753 is also osboleted by the new rfc. Then I would also propose all implementations out there that when they change from numbers 19, 20, 21, 25, 26 to new numbers, they will either remove the old numbers completely (as there is no way to get interoperability with them), or at least add warnings to them saying that those groups might not be interoperable. > 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! EC groups are not used right now, but the implementations we have put out in the last 2 years are going to be out there for long time, and all of those will use the wrong version. I want to make sure that new versions we push out will make fail cleanly (i.e. with no proposal chosen or invalid ke payload) when talking to those old versions. This happens, because the new versions do not support groups 19, 20, 21, 25, 26 at all, but only the new ones, and with those new numbers there is no ambiguity how they are processed. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
