James Hulka writes: > 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.
Why? It is completely valid to have two IKE SAs between the peers, and both of them should work. It will also get two IPsec SA pairs, and that is completely valid situation again, and traffic might use any of the SAs between the peers. > 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. If they somehow block traffic from the one IKE SA and keep the other one up and running, then that is not following the RFC. One of the problems might be caused by the INITIAL_CONTACT notifications, but in case of simultaneous connect, it should not be sent. I.e. when peer is sending IKE_AUTH it should already see the another half-open connection, which means this SA is no longer only IKE SA currently active between the peers, so it should not send INITIAL_CONTACT. > 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. If you try to just work against your own implementation that might work. That should not be needed, you just be able to use two IKE SAs and be done with it. It does not matter which IKE SA is used, they are same. It will consume more resources, and if this kind of simultaneous boot happen all the time, it is better to confiure only one end to create the connection, in which case this issue cannot happen. > 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. Oh, you can make very easy heuristics for that, for example the peer which have smaller IP-address will always initiate. Or just allow two IKE SAs in such situations. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
