[strongSwan-dev] Understanding IKEv1 rekey

[Tobias Brunner]

Hi Noam,

> Strongswan does not send a DELETE.

Yeah, according to the message of the commit that added that break
statement (3a0b67bce5) the idea was to just wait for the SA to expire
(it doesn't really explain why the break was added and the peer is not
notified about the deletion).  The duplicate check that was added later
kills the SA after 10 seconds now.  Perhaps the break was added to avoid
the alert if the SA expired, or the ike_updown() event (which has since
been added) - with strongSwan a notification wasn't required anyway as
it automatically deletes the old IKE_SA as responder of a rekeying.
But I think notifying the peer that the SA was deleted makes definitely
sense.  If deleting it after 10 seconds is a problem (e.g. because the
DELETE is regularly dropped) we could probably also change that so SAs
are not killed until they actually expire (as responder or initiator of
the rekeying).  But since strongSwan does not negotiate SA lifetimes and
always uses its own configuration that deletion will not be synced with
the peer, which could cause problems later if a peer did not receive the
delete and has a longer lifetime and still uses the SA.

I pushed a change that removes the break statement to the
ikev1-rekey-deletion branch.

Regards,
Tobias