Hi Russ,
it is not exactly as you described, but very close. When RFC is unclear
fifferent vendors treat it differently. IKEv1 had quite a lot of moot
places,
much fewer are in IKEv2. Anyway, when you try to interoperate you
sometimes encounter a situation when your peer behaves very-very strange
in some cases (from you point of view, of course). Let's not call
it a bug, but more mildly - a feature. Anyway, if interoperability
is broken, major vendors might not care, but smaller vendors have
to deal with it. And in this situation Vendor Identifiers (and any other
information that could help indentify the peer) are really used to adjust
your behaviour to get interoperability.
Regards,
Valery Smyslov.
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.
Thanks in advance,
Russ
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
