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

[Tore Anderson]

* Tobias Brunner <tobias at strongswan.org>

> Hi Tore,
> 
> > There was one thing you mentioned above that gave me some pause
> > though:
> > 
> > «some heuristics might have to be used to avoid destroying the old
> > SAs as duplicates»
> > 
> > Could you elaborate on how this might be a problem?
> > 
> > If I understand correctly: if make-before-break reauth is being
> > performed, and strongSwan has successfully establisehed replacement
> > IKE and Child SAs, then it shouldn't be any problem with destroying
> > the old and duplicate/superfluous IKE SA (and its associated Child
> > SAs)? Why would you want to avoid that from happening - isn't
> > getting rid of the old SAs precisely the point of
> > reauthenticating?  
> 
> Yes, but the initiator of the new SA should do so.   The responder
> checks for duplicates (uniqueids=yes, identities matching) before the
> CHILD_SAs are fully established (or attributes are assigned).  So that
> might interrupt traffic and could interfere with the reauthentication
> process on the client (if the old SA is deleted while the new one is
> not fully established yet - i.e. the IKE_AUTH response has not been
> received - it might abort the reauth).  So to avoid unintentionally
> deleting the old SA as duplicate strongSwan, in addition to the
> identities, compares the remote IP and port and assumes a
> reauthentication if they match (a DELETE is then scheduled 10 seconds
> later, just in case the initiator doesn't delete the old SA after the
> new one was established).

Hi Tobias,

I'm afraid I'm not entirely sure I follow...

I was under the impression that enabling "charon.make_before_break"
would only alter how strongSwan behaves when it is the party initiating
the re-authentication procedure. In the initiator case, I wouldn't have
thought there was any need for such heuristics and assumptions, as
strongSwan should have full knowledge of which old SAs are indeed
duplicates and therefore should be deleted after the new SAs are
installed.

You appear to be talking about the responder role, however. What I'm
not clear about is how exactly does enabling "charon.make_before_break"
affect strongSwan's behaviour during a re-authentication procedure when
in the responder role?

I find it rather nonintuitive that enabling "charon.make_before_break"
would cause any change at all to strongSwan's responder role behaviour,
to be honest.

Specifically, I don't really understand how the use of the
"charon.make_before_break" method in strongSwan could possibly prevent
the remote IKE peer from initiating and performing a "break before
make" style re-authentication (or vice versa).

Tore