[strongSwan-dev] destroy callback_job in strongswan

[Tobias Brunner]

Hi,

> Everything works perfectly until I notice that if the strongswan
> client and server re-authenticate each other, this solution does not
> work because the IKE_SA_ID will increase but the IKE_SA_ID in the
> callback job is not updated and if the http request returns FALSE,
> the plugin will kill the ipsec connection with IKE_SA_ID equals to 1,
> which is the id of the first ipsec connection.

What exactly do you mean with IKE_SA_ID?  Because the actual ike_sa_id_t
object that identifies an IKE_SA (get_id) is the combination of the two
SPIs and the IKE version.  So this is not increased by 1 but actually
changes completely for each new IKE_SA.  However, if you mean an
IKE_SA's unique ID (get_unique_id) then, yes, that value is increased by
1 for each new IKE_SA.  I'd recommend you use the actual ike_sa_id_t
object to identify the IKE_SA because checkout() is faster than
checkout_by_id().

During a reauthentication the authorize() callback should be called
again for the new IKE_SA, so you could theoretically schedule a new job
for the new IKE_SA then.  But if you are actually referring to rekeying
then you might have to implement the ike_rekey() callback to keep track
of the IKE_SA_ID of the SA, which probably requires you to organize your
plugin differently.  For instance, only have a single job that regularly
goes through a collection of SAs to check, which you then can update so
only the currently active SAs are contained in that collection.  Or
structure the data passed to the job in a way that allows the
ike_rekey()-listener to update the IKE_SA_ID used by the job when it
runs later on.

> In this case, I am curious if there is a way to destroy the callback
> job created in the ipsec connection first authentication phase?

No, scheduled jobs currently can't be canceled in a generic way.  But
lets say the first thing your job does is checking out the IKE_SA based
on the IKE_SA_ID, then you could just terminate the job (i.e. not
reschedule it again) if you don't find the IKE_SA anymore because it was
replaced.  Or as mentioned above, you organize your plugin a bit
differently, e.g. if there were only a single job that checks all SAs
you want to track there would be no need to cancel it (at least while
there are still active IKE_SAs).

Regards,
Tobias