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 _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users