> On Mar 12, 2015, at 1:38 AM, [email protected] wrote: > >> >> On Mar 11, 2015, at 5:23 PM, Yoav Nir <[email protected]> wrote: >> >> >>> On Mar 11, 2015, at 8:54 PM, Russ Housley <[email protected]> wrote: >>> >>> About two years ago, I was at a workshop where someone claimed that the >>> Vendor Identifiers that are exchanged in IKE are very useful for dealing >>> with bugs. The claim was that following the report of a bug, others could >>> adjust their behaviors to avoid the circumstances that enable the bug. In >>> the worst case, they could refuse to talk to the badly broken version, but >>> accept connections to later versions where the bug has been repaired. >>> >>> Does anyone have operation experience doing this kind of thing? I want to >>> know if is real experience or speculation about what could be done. >> >> I haven’t encountered this kind of use of a VendorID. Years ago there was a >> push by auditors for vendors to stop revealing their versions in protocols. >> As a result, our VendorID has not changed in ten years. I suspect the same >> is true for other vendors. So if a bug is fixed, the VendorID is not >> changed. I don’t believe the VendorID is a good way to identify buggy >> implementations. > > As for buggy implementations, I think that it isn’t needed for that. If > someone has a bug that breaks interoperability, we would in general take the > view of “if they fix it, it will work” — in other words, vendors normally > don’t take on the job of working around someone else’s mistakes. > > Interesting story about auditors. I haven’t run into any such thing. I > would hope that most auditors have more sense than that.
Unfortunately, it’s far easier to stop sending the version than to argue against this. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2679 Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
