<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>