<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Hi,</div>
<div>as part of compliance test we are simulating some scenarios to test the strongswan behavior when it receives "NO_ADDITIONAL_SAS".</div>
<div>We use special device as peer security GW which can be scripted to behave as per our needs.</div>
<div> </div>
<div>1) A second IKE created by Strong Swan, even if there is only one IKE at the DUT configured.</div>
<div> </div>
<div>I have the following configuration:1 Ike + 3 Child.</div>
<div> </div>
<div>The IKE and 2 CHILDS are established together with the remote end.</div>
<div>Creation of the 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILDS stays established as expected.</div>
<div>DUT tries to reestablish the 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILDS stays established as expected.</div>
<div> </div>
<div>First CHILD_SA reached end of lifetime.</div>
<div>DUT sends an rekey CHILD_SA for the first CHILD, which is also rejected with 'NO_ADDITONAL_SAS'. </div>
<div>A REAUTH is initiated by DUT (Strong Swan) with an INFORMATIONAL message. </div>
<div>The remote end (a IKEv2 emulator) sends the response with a delay of roughly 22 s </div>
<div>In-between the Strong swan is sending a new IKE_SA_INIT request for a second IKE_SA </div>
<div>After receiving deleted response from remote end (Message 89), DUT sends a new IKE_SA_INIT.</div>
<div>Result: This means now two IKE_SA_INIT requests are active, even only one is configured.</div>
<div> </div>
<div>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 %.</div>
<div> </div>
<div>Question: Is this expected behavior, or is this a bug?</div>
<div>I know this is a very special behavior of the remote end, but I did not expect that a second IKE_SA is established.</div>
<div> </div>
<div>2) An existing CHILD is not rekeyed, if there are two CHILDS at the rekey queue.</div>
<div> </div>
<div>I have the following configuration:</div>
<div>1 Ike + 3 Child, CHILD_SA lifetime is set to 360 seconds.</div>
<div>The IKE and one CHILD is established together with the remote end.</div>
<div>Creation of the 2nd and 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILD stay established as expected.</div>
<div>DUT tries to reestablish the 2nd and 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILD stay established as expected.</div>
<div>First CHILD_SA reached end of lifetime.</div>
<div>DUT (Strong Swan) Does not send any rekey for the CHILD 1. </div>
<div>charon log indicates: creation of CHILD_SA two in progress, creation of CHILD_SA three in queue. </div>
<div> </div>
<div>IPSec statusall indicates:</div>
<div>Flexi Transport Module BL: "FTM_LD60_211.00"</div>
<div>FBM# --------------------------------------</div>
<div>Command: frsh /usr/sbin/ipsec statusall</div>
<div>Wait-Time[ms]: 10000</div>
<div>--------------------------------------</div>
<div>Output: frsh /usr/sbin/ipsec statusall</div>
<div>000 Status of IKEv1 pluto daemon (strongSwan 4.5.3):</div>
<div>000 interface lo/lo 127.0.0.1:500</div>
<div>000 interface eth0/eth0 192.168.255.97:500</div>
<div>000 interface eth2:1/eth2:1 22.22.22.22:500</div>
<div>000 interface eth2/eth2 10.58.166.15:500</div>
<div>000 %myid = '%any'</div>
<div>000 loaded plugins: aes des sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem gmp hmac xauth attr kernel-netlink resolve </div>
<div>000 debug options: none</div>
<div>000 </div>
<div>Status of IKEv2 charon daemon (strongSwan 4.5.3):</div>
<div> uptime: 16 minutes, since Mar 14 08:23:11 2013</div>
<div> malloc: sbrk 135168, mmap 0, used 99264, free 35904</div>
<div> worker threads: 19 of 26 idle, 6/1/0/0 working, job queue: 0/0/0/0, scheduled: 5</div>
<div> 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 </div>
<div>Listening IP addresses:</div>
<div> 192.168.255.97</div>
<div> 22.22.22.22</div>
<div> 10.58.166.15</div>
<div>Connections:</div>
<div> conn1: 10.58.166.15...10.58.166.18, dpddelay=360s</div>
<div> conn1: local: [10.58.166.15] uses pre-shared key authentication</div>
<div> conn1: remote: [10.58.166.18] uses any authentication</div>
<div> conn1: child: 10.58.166.0/24 === 10.10.18.0/25 TUNNEL, dpdaction=clear</div>
<div> conn2: child: 10.58.166.0/24 === 10.10.18.128/25 TUNNEL, dpdaction=clear</div>
<div> conn3: child: 10.58.166.0/24 === 10.10.19.0/25 TUNNEL, dpdaction=clear</div>
<div>Security Associations (1 up, 0 connecting):</div>
<div> conn1[1]: ESTABLISHED 13 minutes ago, 10.58.166.15[10.58.166.15]...10.58.166.18[10.58.166.18]</div>
<div> conn1[1]: IKE SPIs: 3165cfc3cbbea15f_i* 00005bb900005bb9_r, rekeying in 23 hours</div>
<div> conn1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024</div>
<div> 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 </div>
<div> conn1[1]: Tasks active: CHILD_CREATE </div>
<div> conn1{1}: INSTALLED, TUNNEL, ESP SPIs: c5c381c7_i 00007779_o</div>
<div> conn1{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying active</div>
<div> conn1{1}: 10.58.166.0/24 === 10.10.18.0/25 </div>
<div>FBM# Status: OK</div>
<div> </div>
<div>After 9 minutes I have stopped the test.</div>
<div> </div>
<div>This behavior is 100% reproducible.</div>
<div> </div>
<div>Question: Is this expected behavior, or is this a bug?</div>
<div>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.</div>
<div> </div>
<div> </div>
<div>3) An REAUTH is not immediately initiated, even an rekey of an existing CHILD is rejected with 'NO_ADDITONAL_SAS'.</div>
<div> </div>
<div>I have the following configuration:</div>
<div>1 Ike + 3 Child, CHILD_SA lifetime is set to 360 seconds.</div>
<div>The IKE and two CHILDs are established together with the remote end.</div>
<div>Creation of 3rd CHILD is rejected with 'NO_ADDITONAL_SAS' by the remote end. Existing CHILDS stays established as expected.</div>
<div>The rejection with 'NO_ADDITONAL_SAS' are every time delayed, so that the Strong Swan need every time 4 retransmit.</div>
<div>DUT tries to reestablish the 2nd and 3rd child, which is every time rejected with 'NO_ADDITONAL_SAS'. Existing CHILDS stays established as expected.</div>
<div>First CHILD_SA reached end of lifetime.</div>
<div>DUT sends an rekey CHILD_SA for the first CHILD, which is also rejected with 'NO_ADDITONAL_SAS'. </div>
<div>Afterwards the not the not expected behavior starts:</div>
<div>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).</div>
<div>Than there happens 11 seconds nothing.</div>
<div>According to the logs, the IKE_SA is deleted, but there is no informational request seen at Wireshark.</div>
<div>Afterwards a new IKE_SA_INIT is send out.</div>
<div> </div>
<div>This behavior is 100% reproducible.</div>
<div> </div>
<div>Question: Is this expected behavior, or is this a bug?</div>
<div>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.</div>
<div> </div>
<div>4)How provoke 'UNSUPPORTED_CRITICAL_PAYLOAD' from the DUT. </div>
<div>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. </div>
<div> </div>
<div>The question is : will DUT send an UNSUPPORTED_CRITICAL_PAYLOAD for one of the following payloads:</div>
<div>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. </div>
<div>47 (Configuration (CHILD_SA)): Is here also no UNSUPPORTED_CRITICAL_PAYLOAD message send like for Vendor ID?</div>
<div>48 (Extensible Authentication (IKE_AUTH)): Is here also no UNSUPPORTED_CRITICAL_PAYLOAD message send like for Vendor ID?</div>
<div>49- 127 (Reserved for IANA): Most likely these are the most potential payload area to provoke UNSUPPORTED_CRITICAL_PAYLOAD.</div>
<div>128-255 (Private use): This is from our point also a possible payload to provoke: UNSUPPORTED_CRITICAL_PAYLOAD.</div>
<div> </div>
<div>It would be nice if you could give me some hints, what is the best payload to provoke UNSUPPORTED_CRITICAL_PAYLOAD.</div>
<div> </div>
<div>BR,</div>
<div>Sshashidhjar</div>
<div> </div>
</span></font>
</body>
</html>