Dear IPsec Working Group, there is a race condition in the current IKEv2 protocol when 2 site peers are configured to automatically establish a IPsec tunnel.
Both peers can successfully initiate the IKE_SAs which results in each peer having 2 options available for further communication. If each peer selects a different IKE_SA, communication is blocked. We reported this as an issue in the StrongSwan mailing list in 2013 (https://www.mail-archive.com/[email protected]/msg00731.html) and although they have a mechanism to prevent this, it does not catch ALL cases. They are very strict about being RFC compliant (which is good) and therefore could not correct the issue in their IPsec daemon. Currently we handle such cases with a script that is called by a hook when an IPsec tunnel is established. In this script we check for multiple IKE_SAs for a given tunnel and if found remove the IKE_SA with the lower SA ID. It would be good if such a case could be handled in the IKE protocol itself as in the case of site to site IPsec it is often a requirement that a tunnel can be automatically re established after a long connectivity outage. In a large mesh topology this gets very complicated to keep track of which host should automatically reconnect and which host should passively wait for a connection on a per tunnel basis. Best Regards, James Hulka james hulka security engineer open systems ag raeffelstrasse 29 ch-8045 zurich t: +41 58 100 10 10 f: +41 58 100 10 11 [email protected] <mailto:[email protected]> http://www.open.ch _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
