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
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
