[strongSwan] Some queries on behavior with respect to "NO_ADDITIONAL_SAS" & "UNSUPPORTED_CRITICAL_PAYLOAD"
Patil, Shashidhar 1. (NSN - IN/Bangalore)
shashidhar.1.patil at nsn.com
Thu Mar 14 17:46:40 CET 2013
Hi,
as part of compliance test we are simulating some scenarios to test the strongswan behavior when it receives "NO_ADDITIONAL_SAS".
We use special device as peer security GW which can be scripted to behave as per our needs.
1) A second IKE created by Strong Swan, even if there is only one IKE at the DUT configured.
I have the following configuration:1 Ike + 3 Child.
The IKE and 2 CHILDS are established together with the remote end.
Creation of the 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILDS stays established as expected.
DUT tries to reestablish the 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILDS stays established as expected.
First CHILD_SA reached end of lifetime.
DUT sends an rekey CHILD_SA for the first CHILD, which is also rejected with 'NO_ADDITONAL_SAS'.
A REAUTH is initiated by DUT (Strong Swan) with an INFORMATIONAL message.
The remote end (a IKEv2 emulator) sends the response with a delay of roughly 22 s
In-between the Strong swan is sending a new IKE_SA_INIT request for a second IKE_SA
After receiving deleted response from remote end (Message 89), DUT sends a new IKE_SA_INIT.
Result: This means now two IKE_SA_INIT requests are active, even only one is configured.
There is a likelihood of roughly 50 % that this will happen. If the response is faster than 22 seconds it is going to 0, if the delay is higher, than the likelihood is going to 100 %.
Question: Is this expected behavior, or is this a bug?
I know this is a very special behavior of the remote end, but I did not expect that a second IKE_SA is established.
2) An existing CHILD is not rekeyed, if there are two CHILDS at the rekey queue.
I have the following configuration:
1 Ike + 3 Child, CHILD_SA lifetime is set to 360 seconds.
The IKE and one CHILD is established together with the remote end.
Creation of the 2nd and 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILD stay established as expected.
DUT tries to reestablish the 2nd and 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILD stay established as expected.
First CHILD_SA reached end of lifetime.
DUT (Strong Swan) Does not send any rekey for the CHILD 1.
charon log indicates: creation of CHILD_SA two in progress, creation of CHILD_SA three in queue.
IPSec statusall indicates:
Flexi Transport Module BL: "FTM_LD60_211.00"
FBM# --------------------------------------
Command: frsh /usr/sbin/ipsec statusall
Wait-Time[ms]: 10000
--------------------------------------
Output: frsh /usr/sbin/ipsec statusall
000 Status of IKEv1 pluto daemon (strongSwan 4.5.3):
000 interface lo/lo 127.0.0.1:500
000 interface eth0/eth0 192.168.255.97:500
000 interface eth2:1/eth2:1 22.22.22.22:500
000 interface eth2/eth2 10.58.166.15:500
000 %myid = '%any'
000 loaded plugins: aes des sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem gmp hmac xauth attr kernel-netlink resolve
000 debug options: none
000
Status of IKEv2 charon daemon (strongSwan 4.5.3):
uptime: 16 minutes, since Mar 14 08:23:11 2013
malloc: sbrk 135168, mmap 0, used 99264, free 35904
worker threads: 19 of 26 idle, 6/1/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: aes des sha1 sha2 md5 random x509 revocation constraints pubkey pkcs1 pgp pem fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-raw stroke updown
Listening IP addresses:
192.168.255.97
22.22.22.22
10.58.166.15
Connections:
conn1: 10.58.166.15...10.58.166.18, dpddelay=360s
conn1: local: [10.58.166.15] uses pre-shared key authentication
conn1: remote: [10.58.166.18] uses any authentication
conn1: child: 10.58.166.0/24 === 10.10.18.0/25 TUNNEL, dpdaction=clear
conn2: child: 10.58.166.0/24 === 10.10.18.128/25 TUNNEL, dpdaction=clear
conn3: child: 10.58.166.0/24 === 10.10.19.0/25 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
conn1[1]: ESTABLISHED 13 minutes ago, 10.58.166.15[10.58.166.15]...10.58.166.18[10.58.166.18]
conn1[1]: IKE SPIs: 3165cfc3cbbea15f_i* 00005bb900005bb9_r, rekeying in 23 hours
conn1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
conn1[1]: Tasks queued: CHILD_REKEY CHILD_REKEY CHILD_REKEY CHILD_REKEY CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE CHILD_CREATE
conn1[1]: Tasks active: CHILD_CREATE
conn1{1}: INSTALLED, TUNNEL, ESP SPIs: c5c381c7_i 00007779_o
conn1{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying active
conn1{1}: 10.58.166.0/24 === 10.10.18.0/25
FBM# Status: OK
After 9 minutes I have stopped the test.
This behavior is 100% reproducible.
Question: Is this expected behavior, or is this a bug?
I know this is a very special behavior of the remote end, but I did expect that rekeying of CHILD_SA one has highest priority.
3) An REAUTH is not immediately initiated, even an rekey of an existing CHILD is rejected with 'NO_ADDITONAL_SAS'.
I have the following configuration:
1 Ike + 3 Child, CHILD_SA lifetime is set to 360 seconds.
The IKE and two CHILDs are established together with the remote end.
Creation of 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILDS stays established as expected.
The rejection with 'NO_ADDITONAL_SAS' are every time delayed, so that the Strong Swan need every time 4 retransmit.
DUT tries to reestablish the 2nd and 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILDS stays established as expected.
First CHILD_SA reached end of lifetime.
DUT sends an rekey CHILD_SA for the first CHILD, which is also rejected with 'NO_ADDITONAL_SAS'.
Afterwards the not the not expected behavior starts:
I can see an additional CREAT_CHILD SA for a new CHILD (CHILD 3, which was not established beforehand). This is repeated 4 times (instead of 5 time as for normal requests).
Than there happens 11 seconds nothing.
According to the logs, the IKE_SA is deleted, but there is no informational request seen at Wireshark.
Afterwards a new IKE_SA_INIT is send out.
This behavior is 100% reproducible.
Question: Is this expected behavior, or is this a bug?
I know this is a very special behavior of the remote end, but I did expect that REAUTH is directly started after the rekey of the CHILD_SA is rejected with 'NO_ADDITONAL_SAS' with a INFORMATIONAL delete request.
4)How provoke 'UNSUPPORTED_CRITICAL_PAYLOAD' from the DUT.
I have used with the Exchange type IKE_SA_INIT a VENDOR_ID payload and set the critical payload flag. There the 'UNSUPPORTED_CRITICAL_PAYLOAD' response is not send.
The question is : will DUT send an UNSUPPORTED_CRITICAL_PAYLOAD for one of the following payloads:
1-32 (Reserved for IKEv1): here I am not sure if this is a known payload for Strong swan, as Payload 1 to 32 is reserved for IKEv1.
47 (Configuration (CHILD_SA)): Is here also no UNSUPPORTED_CRITICAL_PAYLOAD message send like for Vendor ID?
48 (Extensible Authentication (IKE_AUTH)): Is here also no UNSUPPORTED_CRITICAL_PAYLOAD message send like for Vendor ID?
49- 127 (Reserved for IANA): Most likely these are the most potential payload area to provoke UNSUPPORTED_CRITICAL_PAYLOAD.
128-255 (Private use): This is from our point also a possible payload to provoke: UNSUPPORTED_CRITICAL_PAYLOAD.
It would be nice if you could give me some hints, what is the best payload to provoke UNSUPPORTED_CRITICAL_PAYLOAD.
BR,
Sshashidhjar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130314/ff399103/attachment.html>
More information about the Users
mailing list