Project

General

Profile

Feature #1410

Deleting an IKEv1 IKE_SA can't take effect immediately when there are other tasks in the task queue

Added by Daniel Chan over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
charon
Target version:
Start date:
15.04.2016
Due date:
Estimated time:
Resolution:
Fixed

Description

Hello there,

I used the command "ipsec stroke down XXX" to delete the IKE_SA. But I found if the IKE_SA is in the state of ESTABLISHED, and with other task such as child rekey in the task queue, the command

can't get take effect immediately. The delete task will queue in the task queue and be executed after other task is done,so sometimes when I want to terminate a connection I need to wait. If I used "ipsec stroke down-nb

XXX", the command return immediately but it still can't take effect immediately.

IF I want to terminate a connection,generally I don't care about what the task the connection is doing. Is there any way can terminate the IKE_SA immediately no matter how many tasks in the task queue? Thanks


Related issues

Related to Bug #1537: IKEv1: Deleting IKE-SA during QUICK_MODE when Phase 1 is ESTABLISHED will never delete the IKE-SAClosed27.06.2016

Associated revisions

Revision 612fe541 (diff)
Added by Tobias Brunner over 4 years ago

ikev1: Activate DELETE tasks before other tasks in state ESTABLISHED

Fixes #1410.

Revision 60d0f52f (diff)
Added by Tobias Brunner about 4 years ago

ike1: Flush active queue when queueing a delete of the IKE_SA

By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.

Fixes #1537
References #429, #1410
Closes strongswan/strongswan#48

History

#1 Updated by Tobias Brunner over 4 years ago

  • Category changed from charon-cmd to charon
  • Status changed from New to Feedback

IF I want to terminate a connection,generally I don't care about what the task the connection is doing. Is there any way can terminate the IKE_SA immediately no matter how many tasks in the task queue?

For IKEv2, if there is an active task or more specifically an exchange running it has to be completed. We can't just abort an exchange and increase the message ID as the previous request might have been lost and the other peer would not accept the new message with an increased message ID, but we can't reuse the MID of the active exchange for a new exchange either as the peer could have received the request but the response might have been lost.

Once any active task is complete an IKE_DELETE task is the first one to get activated (well, after MOBIKE), so it doesn't matter if there are rekey tasks queued.

However, you didn't say whether you use IKEv1 or IKEv2. Because I just noticed that for IKEv1 the ISAKMP_DELETE tasks are not activated before QUICK_MODE tasks (used to rekey IKEv1 CHILD_SAs). I fixed that in the 1410-ikev1-task-order branch.

#2 Updated by Daniel Chan over 4 years ago

Tobias Brunner wrote:

IF I want to terminate a connection,generally I don't care about what the task the connection is doing. Is there any way can terminate the IKE_SA immediately no matter how many tasks in the task queue?

For IKEv2, if there is an active task or more specifically an exchange running it has to be completed. We can't just abort an exchange and increase the message ID as the previous request might have been lost and the other peer would not accept the new message with an increased message ID, but we can't reuse the MID of the active exchange for a new exchange either as the peer could have received the request but the response might have been lost.

Once any active task is complete an IKE_DELETE task is the first one to get activated (well, after MOBIKE), so it doesn't matter if there are rekey tasks queued.

However, you didn't say whether you use IKEv1 or IKEv2. Because I just noticed that for IKEv1 the ISAKMP_DELETE tasks are not activated before QUICK_MODE tasks (used to rekey IKEv1 CHILD_SAs). I fixed that in the 1410-ikev1-task-order branch.

Hi Tobias Brunner,
Thanks for your feedback, I forgot to say that I was using IKEv1. I don't understand the effect of your modification in 1410-ikev1-task-order quite clearly. My understanding is: if there are already many QUICK_MODE tasks in task queue of an ESTABLISHED IKE_SA, when I use "ipsec stroke down XXX",the delete task will be actived preferentially, however, if there is an atcvie task is in operation, the delete task will wait until the atcvie task is done. Is my understanding right?

#3 Updated by Tobias Brunner over 4 years ago

My understanding is: if there are already many QUICK_MODE tasks in task queue of an ESTABLISHED IKE_SA, when I use "ipsec stroke down XXX",the delete task will be actived preferentially, however, if there is an atcvie task is in operation, the delete task will wait until the atcvie task is done. Is my understanding right?

Yes, correct. But I guess for IKEv1 we could theoretically do that differently as the message IDs are not sequential (and deletes are technically no exchanges but just unconfirmed notifications that a peer deleted an SA). Not sure how peers (including strongSwan) would handle that though if a Quick Mode exchange is currently in progress.

#4 Updated by Daniel Chan over 4 years ago

Tobias Brunner wrote:

My understanding is: if there are already many QUICK_MODE tasks in task queue of an ESTABLISHED IKE_SA, when I use "ipsec stroke down XXX",the delete task will be actived preferentially, however, if there is an atcvie task is in operation, the delete task will wait until the atcvie task is done. Is my understanding right?

Yes, correct. But I guess for IKEv1 we could theoretically do that differently as the message IDs are not sequential (and deletes are technically no exchanges but just unconfirmed notifications that a peer deleted an SA). Not sure how peers (including strongSwan) would handle that though if a Quick Mode exchange is currently in progress.

OK,thank you~

#5 Updated by Tobias Brunner over 4 years ago

  • Tracker changed from Issue to Feature
  • Subject changed from Delete the IKE_SA can't take effect immediately when there are other tasks in the task queue to Deleting an IKEv1 IKE_SA can't take effect immediately when there are other tasks in the task queue
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.5.0
  • Resolution set to Fixed

#6 Updated by Tobias Brunner about 4 years ago

  • Related to Bug #1537: IKEv1: Deleting IKE-SA during QUICK_MODE when Phase 1 is ESTABLISHED will never delete the IKE-SA added

Also available in: Atom PDF