[strongSwan-dev] [PATCH] starter: cleanup SAs when deleting a connection

[Emeric POUPON]

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