<div dir="ltr">Thanks, I am optimistic about this working.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 1:43 PM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Noam,<br>
<span class=""><br>
> Strongswan does not send a DELETE.<br>
<br>
</span>Yeah, according to the message of the commit that added that break<br>
statement (3a0b67bce5) the idea was to just wait for the SA to expire<br>
(it doesn't really explain why the break was added and the peer is not<br>
notified about the deletion).  The duplicate check that was added later<br>
kills the SA after 10 seconds now.  Perhaps the break was added to avoid<br>
the alert if the SA expired, or the ike_updown() event (which has since<br>
been added) - with strongSwan a notification wasn't required anyway as<br>
it automatically deletes the old IKE_SA as responder of a rekeying.<br>
But I think notifying the peer that the SA was deleted makes definitely<br>
sense.  If deleting it after 10 seconds is a problem (e.g. because the<br>
DELETE is regularly dropped) we could probably also change that so SAs<br>
are not killed until they actually expire (as responder or initiator of<br>
the rekeying).  But since strongSwan does not negotiate SA lifetimes and<br>
always uses its own configuration that deletion will not be synced with<br>
the peer, which could cause problems later if a peer did not receive the<br>
delete and has a longer lifetime and still uses the SA.<br>
<br>
I pushed a change that removes the break statement to the<br>
ikev1-rekey-deletion branch.<br>
<br>
Regards,<br>
Tobias<br>
<br>
</blockquote></div><br></div>