[strongSwan] Reporting Issue:Old CHILD_SA not getting cleared
Ghosh, Anurag (EXT-Aricent - IN)
anurag.ghosh.ext at nsn.com
Fri Mar 30 15:54:11 CEST 2012
Hi,
We have encountered some issues while using StrongSwan charon on our Linux server and would request you to help us out on this.
Setup:
1) We are using StrongSwan charon [Linux strongSwan 4.3.1] on our server [we call it NODE A] to establish an IKEv2 IPSec tunnel with a Cisco SAMI [Wireless Security Gateway Application version 3.0.0] router [we call it NODE B].
2) On NODE A, IKE Lifetime is set as 600 sec., SA lifetime is set as 300 sec. On NODE B, IKE Lifetime is set as 7200 sec., SA lifetime is set as 3600sec. [the same issue is observed even when the lifetimes on both ends of the tunnel match]
3) Basic ICMP Traffic is pumped continuously from NODE A to NODE B.
Scenario:
1) We observe that after the first IKE_SA_INIT/IKE_AUTH a pair of CHILD_SA is created (by CREATE_CHILD_SA) and displayed in the output of setkey -D on NODE A.
2) After around 300 sec. re-keying of CHILD_SA is initiated, new CHILD_SA is created with new SPI and old CHILD_SA is deleted.
3) After around 600 sec. from the start, IKE_SA re-keying starts, but just before that we observe that an INFORMATIONAL message (with Next Payload: Delete) is sent from NODE A to NODE B. Is this expected even before the IKE_SA re-keying starts? Moreover NODE B responds back with an INFORMATIONAL message (with Next Payload: None). This is expected only when IKE_SA re-keying happens and old IKE_SA's delete message is sent.
4) After the IKE_SA re-keying is over and new IKE_SA is created, we observe that 2 new CHILD_SA's are created even though before the re-keying period the IKE_SA had only 1 CHILD_SA. Now both these CHILD_SAs work independently and re-keying independently. So after the end of 1st IKE_SA re-keying we have 2 CHILD_SAs even though we started with 1. The output of setkey -D also confirms the same.
5) After the 2nd IKE_SA re-keying, we observe that 3 CHILD_SAs are created, and this number keeps on increasing by 1 after each subsequent IKE_SA re-keying. The output of setkey -D also confirms the same.
6) The number of CHILD_SA keeps on increasing with time.
This issue is not observed when both end of the tunnel, i.e., NODE A and NODE B have StrongSwan charon. We suspect that this could be an interoperability issue. Can you please help us in debugging this issue?
Thanks and Regards,
Anurag Ghosh
More information about the Users
mailing list