On Wed, 11 Mar 2015, [email protected] wrote:
As for buggy implementations, I think that it isn’t needed for that.
I agree with 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.
That I don't agree with. For openswan/libreswan I have done plenty of workarounds or additional checks. It is just that usually the bugs are clear enough that you do not need a vendorid to figure it out. For instance: commit f853f44177155f75ff2910a8fe2b96d95f8050e5 Author: Paul Wouters <[email protected]> Date: Wed May 14 10:22:45 2014 -0400 DPD: openbsd isakmpd bug workaround for duplicate DPD seqno openbsd mistakenly re-uses the same DPD sequence number when its DPD probe did not receive an answer. If the probe hit the other endpoint, but got lost on the return, it means openbsd sends a duplicate DPD seqno, which according to RFC 3706 Section 7 "Security Considerations" we detect as a replayed packet that we drop. This patch introduced the same kludge openbsd uses to interop with itself. That is, we allow and answer 3 dupliates before we remain quiet and assume it is a DDOS attack. If you read this and have openbsd commit access, please do: isakmpd/dpd.c around line 350: - ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq); + ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq++); We could have done this based on VID, but why not do it directly on the bad DPD seq_no. Our IKEv1 code is full of these gems. Writing one from scratch according to spec will cause you to have to relearn years of interoperability bugs. Even today, I found a bug in whatever IKE daemon Amazon AWS is using, although in this case, there is just no practical workaround because it is just too broken: https://libreswan.org/wiki/Interoperability#Multiple_tunnels_fail_with_Amazon.27s_VPN So, while some vendors might be able to say "fix your stuff", the opensource people don't often have that luxury. Or, perhaps it is because we _do_ have the luxury of writing new code :) Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
