Subject: [IPsec] IKEv2 protocol race condition for auto start

From: James Hulka <[email-masked]>
Date: Mon, 13 Oct 2014 11:40:05 +1100

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-masked]/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-masked] <mailto:[email-masked]>

http://www.open.ch

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Oct 2014 18:25:55 +0300

James Hulka writes:
> 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-masked]/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-masked]