<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <font face="Times New Roman, Times, serif">Are there scenarios where

      the 'rekeyed' check around the ike_updown() call in

      ikev2/tasks/ike_delete.c build_r() is really required?<br>

      <br>

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

      <br>

      But in some error scenarios, the ike_sa may still have child SAs

      associated with it, and in my application, receiving the DOWN

      report allows us to reestablish these connections that are being

      destroyed. <br>

      <br>

      So my application seems better off if I remove the check. But are

      there other scenarios I haven't thought of where removing it would

      be harmful?<br>

      <br>

      Here's one observed error scenario:<br>

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

      <br>

      Regards,<br>

      Nancy<br>

    </font>

  </body>

</html>