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

From: James Hulka <[email-masked]>
Date: Wed, 15 Oct 2014 13:21:00 +1100

Dear Tero,

thank you for your detailed explanation.

On 14/10/14 02:25 AM, Tero Kivinen wrote:
> 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-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.
So in a situation where both peers send IKE_SA_INIT and receive IKE_SA_INIT responses simultaneously they will both NOT send IKE_AUTH.

I assume with connection retries this would continue until one peer can send IKE_AUTH before the other peer gets an IKE_SA_INIT response?

>> 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.
This is true but the decision for auto start everywhere is to make the configuration easier to understand for Engineers who may be required to debug such tunnels and maintain the code configuring such tunnels. It is a practicality/scale-ability decision based on the K.I.S.S (Keep it simple ...) principal.
> Or just allow two IKE SAs in such situations.
This interests me more but of course is out of the scope of this mailing list as it is possibly a misconfiguration or vendor issue.