> 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.
paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
