<div dir="ltr">Hi Tobias,<div><br></div><div>I check this branch and there is an another issue.</div><div><br></div>ike_sa->delete queue an ISAKMP_DELETE task, while the old IKE SA is in REKEING state.<div>but the code in task_manager_v1->initiate disagree to execute the task.</div><div>The code here <a href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ikev1/task_manager_v1.c#L475" target="_blank">https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ikev1/task_manager_v1.c#L475</a> doesn't take into account that the IKE SA can be in rekeying state.</div><div><br></div><div>The logs look like this:</div><div><br></div>queueing ISAKMP_DELETE task<br>activating new tasks<br>nothing to initiate<div><br></div><div>Thanks,</div><div>Avinoam.<br><div><span style="white-space:pre-wrap"> </span><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 22, 2016 at 2:01 PM Noam Lampert <<a href="mailto:lampert@google.com" target="_blank">lampert@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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>
</blockquote></div></div></div>