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

[Tobias Brunner]

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).

Regards,
Tobias