Hi, > Are there scenarios where the 'rekeyed' check around the ike_updown() > call in ikev2/tasks/ike_delete.c build_r() is really required?
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. > 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 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). > 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. I think what you are describing here is a known bug or at least related, see [1]. Regards Martin [1]https://wiki.strongswan.org/issues/853 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
