<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Times New Roman, Times, serif">Martin,<br>
<br>
Would it be</font><font face="Times New Roman, Times, serif"><font
face="Times New Roman, Times, serif"> correct to invoke
ike_updown()</font> from ike_delete when rekeying was in
progress but <i>failed</i>? If so, then the problem is how
ike_delete can know if the rekeying was successful and a successor
IKE_SA was established by establish_new(). <br>
<br>
In my application, I could possibly use the presence/absence of
child SAs to determine failure/success. But I don't expect this is
a general solution.<br>
<br>
The issue you referred to in your response is for CHILD_SA
rekeying and connections remaining up but nonfunctional. Mine is
IKE_SA with connections going down and not being reported. Doesn't
seem to be the same problem.<br>
<br>
Regards,<br>
Nancy<br>
</font><br>
<div class="moz-cite-prefix">Martin Willi wrote on 4/22/2015 3:38
AM:<br>
</div>
<blockquote cite="mid:1429691893.3123.14.camel@martin" type="cite">
<pre wrap="">Hi,
</pre>
<blockquote type="cite">
<pre wrap="">Are there scenarios where the 'rekeyed' check around the ike_updown()
call in ikev2/tasks/ike_delete.c build_r() is really required?
</pre>
</blockquote>
<pre wrap="">Yes. After rekeying an IKE_SA, the old one gets deleted using this task.
We don't want to signal ike_updown() in this case, as the IKE_SA has
been rekeyed, not deleted.
</pre>
<blockquote type="cite">
<pre wrap="">In the cases where the ike_sa was rekeyed successfully, the deleting
ike_sa will have no child SAs and an ike_updown() call wouldn't
generate any reports
</pre>
</blockquote>
<pre wrap="">While the updown plugin listens for CHILD_SA events only, other plugins
are interested in up/down events for the IKE_SA itself. These events can
be used independently, and we really don't want to raise an ike_updown()
event after rekeying (but an ike_rekey() event).
</pre>
<blockquote type="cite">
<pre wrap="">My client and its peer initiated rekeys simultaneously, but my
client's request got lost along the way. The peer doesn't recognize
there's any rekey collision, and sends INFO[DELETE] for the original
ike_sa, thinking the rekeying is done successfully. My client receives
the INFO[DELETE] while it's got the original ike_sa in REKEYING state
and with its children still associated with it, and two potential
successor ike_sas in CONNECTING state. Processing of the INFO[DELETE]
results in all these being deleted in my client, with no successor
ike_sa established, and no report to the application.
</pre>
</blockquote>
<pre wrap="">I think what you are describing here is a known bug or at least related,
see [1].
Regards
Martin
[1]<a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/issues/853">https://wiki.strongswan.org/issues/853</a>
</pre>
</blockquote>
<br>
</body>
</html>