Thanks, I am optimistic about this working.
On Mon, Aug 22, 2016 at 1:43 PM, Tobias Brunner <[email protected]> wrote: > 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
