[strongSwan-dev] destroy callback_job in strongswan

[Baal Su]

Hi Tobias,

	Thank you for your reply.

> On 14 Sep 2015, at 15:17, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> 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().

Sorry about the confusion, here I mean IKE_SA's unique ID, which increases by
one for each new IKE_SA. 

In this plugin I use 

	charon->controller->terminate_ike(charon->controller, this->ike_sa_id, NULL, NULL, 0);

to close the ipsec connection (where this->ike_sa_id is the IKE_SA's unique id) 
if some condition value in this plugin is FALSE. 

This code runs in an infinite while loop in the callback job, so that the condition 
value is continuously checked by the plugin between each (re-)authentication.
 
> 
> 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.  

Yes, I set a flag in the plugin so this callback job is created only in the first
authentication phase. But if I schedule a new job, the previous job is still 
running, and as I mentioned, it is running in an infinite loop, so it will not 
be stopped.

> 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.

This is exactly how the plugin is organised. In the first authentication phase between 
the client and the server, the callback job is created and it keeps running in the 
background, and if the condition value changes, it will close the ipsec connection as 
I mentioned before. In the re-authentication phase, the callback job is ignored.

May I ask how to get this collection of SAs? I tried to use enumerator in the callback
job before the condition value check, then the compile fails.

Meanwhile, I already have a structure of data as one of the inputs to the callback job.
So it could be even better if there is a way to get the IKE_SA_ID which is up.
> 
>> 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).

Please give me some hint of how to track the active IKE_SAs in the callback job.
It is even better not to cancel and create the job again and again.

Thank you very much for your time and best wishes!
Tao

> 
> Regards,
> Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150915/1f034250/attachment.html>