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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
