[strongSwan] Broken CHILD_SA following IKE_SA re-auth with FortiGate remote

[Tobias Brunner]

Hi Tore,

> That said, it seems to me that even if we're talking specifically about
> reauthentications, strongSwan's default "break before make"
> behaviour still violates the standard:
> 
>    Reauthentication is done by creating a new IKE SA from scratch (using
>    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
>    payloads), creating new Child SAs within the new IKE SA (without
>    REKEY_SA Notify payloads), and finally deleting the old IKE SA (which
>    deletes the old Child SAs as well).
> 
>  -- https://tools.ietf.org/html/rfc7296#section-2.8.3
> 
> This text appears to me to mandate the exact behaviour that can be
> enabled with "charon.make_before_break". It makes me wonder, though:
> why isn't this the default behaviour?

Because this wasn't part of the original IKEv2 standard (RFC 4306) and
implementing it by tearing down everything and starting from scratch was
way easier to implement, in particular in specific scenarios.

> So is strongSwan here intentionally behaving in a non-compliant manner
> simply in order to better interoperate with other non-compliant IKEv2
> implementations, or is there some other reason why "make before break"
> isn't the default? That is, are there any other limitations/bugs/known
> interop problems/etc. that I should be aware of before enabling it?

There are some aspects that could make creating overlapping SAs tricky.
One of these is the use of dynamic virtual IPs and other configuration
attributes assigned when setting up the IKE_SA (assigning the same IP
twice or assigning a new one, installing the same IP and perhaps DNS
servers "twice" on the client etc.).  Another issue is caused by
duplicate checks (for a responder there is no indication that an SA is
created for a reauthentication or not - except perhaps the
INITIAL_CONTACT notify but its use is optional - so some heuristics
might have to be used to avoid destroying the old SAs as duplicates).
Some issues are strongSwan specific (or only apply to certain versions)
like sharing an IPsec policy between multiple CHILD_SAs (or more
specifically multiple reqids).  Custom updown scripts might also
struggle with this as they might have to do some explicit refcounting to
avoid something is undone when the old IKE_SA and its children are torn
down after the new ones were created.  The break-before-make approach
avoids most of this but, of course, creates other problems (like
interrupting traffic, issues with trap policies, possible race
conditions on the responder handling deletion of the old and creation of
the new SAs concurrently).

I guess for IKEv2 implementations that are based on existing IKEv1
implementations the make-before-break approach comes relatively
naturally as it was the only way to rekey an IKEv1 SA.  But there is now
that strong link between IKE and CHILD_SAs that didn't exist in IKEv1,
which might be what FortiGate is struggling with.

Regards,
Tobias