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

[Tore Anderson]

Hi Tobias,

* Tobias Brunner <tobias at strongswan.org>

> Hi Tore,
> 
> > - Is the strongSwan behaving correctly when it is also deleting the
> > ESP CHILD_SA when receiving the DELETE IKE_SA from the FortiGate,
> > instead of "moving" it to the other active IKE_SA as it appears the
> > FortiGate has done? RFC4306, section 2.4 says the following:
> > 
> >   «Closing the IKE_SA implicitly closes all associated CHILD_SAs.
> > 
> >   ...but this doesn't mention the corner case where there are two
> >   parallel CHILD_SAs, as was the case for us.  
> 
> I don't see any corner case.  Each of these CHILD_SAs belongs to
> exactly one IKE_SA.  If the corresponding IKE_SA is closed so is the
> CHILD_SA.

Thanks you for clarifying. I suppose this means the FortiGate isn't
implementing IKEv2 in a RFC-compliant manner. At least if it deleted the
specific IKE SA that Child SA c1f9cea7_i 104b86c3_o was created from
(and kept using it anyway). Unfortunately the log lines don't include
the SPIs of the IKE SAs, so it's hard to tell with 100% certainty, but
it does seem like the most plausible explanation to me.

> > - Why does the strongSwan rekey by first deleting the existing
> > IKE_SA and then initiating a new one, instead of the other way
> > around? This seems to me to be a violation of RFC4306, section 2.8,
> > paragraph 4:  
> 
> Because that's not a rekeying but a reauthentication.  Please read
> https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey

Thank you very much, this reference was very enlightening. I wasn't
really clear on the difference between rekeying and reauthentication
before.

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?

The Wiki page does warn that "make before break" requires the peer to
support overlapping SAs. However the text I quoted above implies that
this is a fundamental requirement of the IKEv2 standard to begin with.

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?

Tore