|
Are there scenarios where
the 'rekeyed' check around the ike_updown() call in
ikev2/tasks/ike_delete.c build_r() is really required? 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 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. 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? Here's one observed error scenario: 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. Regards, Nancy |
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
