Hello, >> Maybe we would need to flush the SP first if the last connection that uses >> it is being deleted? >> >> What do you think? >> > Emeric > >Hi Emeric, > >Right, the SP should probably be removed first (as is done in the >original code).
>The order of operations must be carefully checked. Probably first >deleting connection (starter_stroke_del_conn), to avoid immediate >renegotiation, then delete SPs (starter_stroke_unroute_conn), then >asynchronously terminate connections. > I tried this way, but unfortunately the starter_stroke_unroute_conn call has no immediate effect since the route is still used by the established CHILD SA. Therefore I still get the issue described before. I also tried to have a look at the "flush" method of the ike_sa_manager to see of the "delete" with no ack is performed: maybe we would need something similar in order to synchronously flush the connections that are no longer handled in the configuration file? >The main problem when terminating connections is to terminate the right >IKE_SAs. > >Identifying CHILD_SAs to delete is rather easy (their name is the same >as the connection name), but that is not the case of IKE_SAs: several >"connections" may have the same left/right pair, so share the same >IKE_SA, so: > >- the name of an IKE_SA used by a connection may be the name of >another connection (the IKE_SA name is the name of the first >connection that established an IKE negotiation between the same >left/right pair). >- if you find an IKE_SA named after the connection that you are >deleting, you must be sure that it is not used by other CHILD SAs >derived from another (not deleted) connection. > >That's why starter_stroke_terminate_conn then starter_stroke_purge_ike >are called in the patch (the first one terminates CHILD_SAs of deleted >connections, the second one terminates IKE_SAs with no CHILD_SA). But >in the asyncrhonous deletion case, the IKE_SAs will not be deleted >since deletion of CHILD_SAs is pending. How would you implement that? I guess using a new stroke message? BTW, configuration reloading is quite a common subject on the strongswan's mailing lists, I am wondering if one of the official developers has already some ideas about this topic and things that may be done? Best Regards, Emeric _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
