|
Martin, Would it be correct to invoke ike_updown() from ike_delete when rekeying was in progress but failed? 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(). 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. 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. Regards, Nancy Martin Willi wrote on 4/22/2015 3:38
AM:
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 reportsWhile 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
