Issue #1395
Why does strongswan delete the old SAs before New SAs established during reauth, which leads to a possible traffic interruption.
Description
Hello there,
Recently, i found an unreasonable behavior of strongswan during IKE reauthentication. Please help me and check.
When reauth happened, strongswan will delete the old IKE_SA, SAD and policy as well as sending delete INFORMATIONAL message before new SA being created and established successfully. This can be observed by charon log and the IKE packets captured by wireshark.
However, in RFC5996, it is said that "Reauthentication is done by creating a new IKE SA from scratch, creating new Child SAs within the new IKE SA, and finally deleting the old IKE SA (which
deletes the old Child SAs as well)."
It can be inferred from the statement above that old SAs (including both IKE and Child SAs) should be deleted after new SAs created. The word “finally” gives the proper order between the actions “delete and create”.
As a result, I think it seems that the implementation may not conform to the RFC protocol very well. Besides, it is not reasonable to delete the old SAs before new SAs established which may lead to a traffic interruption since old SAs are deleted when there is not any new SA ready yet.
The abstract log is given below. The detailed log and packets captured are given as attachments.
Mar 30 22:04:03 ubuntu charon: 11[NET] received packet: from 172.16.1.3[4500] to 172.16.254.254[4500] (76 bytes) Mar 30 22:04:03 ubuntu charon: 11[ENC] parsed INFORMATIONAL request 2 [ D ] Mar 30 22:04:03 ubuntu charon: 11[IKE] received DELETE for IKE_SA spa2[2210] Mar 30 22:04:03 ubuntu charon: 11[IKE] deleting IKE_SA spa2[2210] between 172.16.254.254[172.16.254.254]...172.16.1.3[172.16.1.3] Mar 30 22:04:03 ubuntu charon: 11[IKE] IKE_SA deleted-----------*-here you delete IKE and policy first*----------------- Mar 30 22:04:03 ubuntu vpn: - 172.16.1.3 172.16.1.3 -- 172.16.254.254 == 172.17.0.0/16 Mar 30 22:04:03 ubuntu charon: 11[ENC] generating INFORMATIONAL response 2 [ ] Mar 30 22:04:03 ubuntu charon: 11[NET] sending packet: from 172.16.254.254[4500] to 172.16.1.3[4500] (76 bytes) Mar 30 22:04:03 ubuntu charon: 11[KNL] deleting policy 172.17.0.0/16 === 172.16.1.3/32 out (mark 0/0x00000000) ……. Mar 30 22:04:04 ubuntu charon: 08[NET] received packet: from 172.16.1.3[500] to 172.16.254.254[500] (724 bytes) Mar 30 22:04:04 ubuntu charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ] Mar 30 22:04:04 ubuntu charon: 08[IKE] 172.16.1.3 is initiating an IKE_SA-------*here you try to create new after delete*-------------- Mar 30 22:04:04 ubuntu charon: 08[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024 Mar 30 22:04:04 ubuntu charon: 08[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] ……. Mar 30 22:04:04 ubuntu charon: 09[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH) ] Mar 30 22:04:04 ubuntu charon: 09[NET] sending packet: from 172.16.254.254[500] to 172.16.1.3[500] (328 bytes) Mar 30 22:04:04 ubuntu charon: 11[KNL] 172.16.254.254 is on interface eth5 Mar 30 22:04:04 ubuntu charon: 11[KNL] deleting policy 172.17.0.0/16 === 172.16.1.3/32 out (mark 0/0x00000000)--------*here you try to delete policy and SAD immediately after INIT message before any SAs established and ready.* Mar 30 22:04:04 ubuntu charon: 11[KNL] sending XFRM_MSG_DELPOLICY 41325: => 80 bytes @ 0x7ff6eade37a0
I am looking forward to your reply and explanations. Thanks.
Best wishes!
Related issues
History
#1 Updated by Tobias Brunner over 9 years ago
- Is duplicate of Issue #857: Is IKE-SA reauthentication without data packet drops possible? added
#2 Updated by Tobias Brunner over 9 years ago
- Description updated (diff)
- Status changed from New to Feedback
Check the charon.make_before_break setting in strongswan.conf. Note that enabling it requires a recent release on both sides (read the notes in the wiki/man page).
#3 Updated by Bin Liu over 9 years ago
Is charon.make_before_break only for initiator?
if my device is only a responder, there is no need to change this config and strongswan can adapt to the behavior of initiator automatically, am i right?
Thanks.
#4 Updated by Tobias Brunner over 9 years ago
Is charon.make_before_break only for initiator?
if my device is only a responder, there is no need to change this config and strongswan can adapt to the behavior of initiator automatically, am i right?
Yes, it has only an effect on initiators of reauthentications. Depending on the configuration both peers may initiate reauthentications, but if e.g. virtual IPs or asymmetric authentication methods like EAP are used then only the original initiator may initiate reauthentications.
#5 Updated by Tobias Brunner over 9 years ago
- Category set to configuration
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to No change required