[strongSwan] IKEv2: IKE_SA rekey collision

[m.divya.mohan]

Hi, 
Following is the recommendation as per RFC 5996, looks like charon is not following this.
 
    2.8.2.Simultaneous IKE SA Rekeying
        The new IKE SA containing the lowest nonce SHOULD be deleted by the node that created it, and the other surviving new IKE SA MUST inherit all the Child SAs.
 
 I have a tunnel established as Node A (20.0.0.1) ==== NodeB (20.0.0.2).
Both nodes are using charon (strongSwan 4.3.6).
  
 And bothsides  have:
     ikelifetime=90s
      keylife=60s
      auto=route
      reauth=no
 
I am referring to the attachment rekey2.pcap.
 
When the tunnel is kept alive, occasionally IKE_SA rekey collision would happen.
One such collision is visible between packets 487 and 498 in the pcap file.
 
Packet #487
------------
20.0.0.1 sent CREATE_CHILD_SA, with SPI = 5eaad45efb4206f7
Nonce=
0000   0b fa 4c 44 af 49 eb a6 39 be bb 02 12 17 e4 f7
0010   e5 68 17 49 7c 68 ae 33 1f f4 a2 09 e3 51 7c 5e
 
Packet #489
-----------
20.0.0.2 sent CREATE_CHILD_SA, SPI = 0be330b30dfa35a3
Nonce=
0000   37 32 8e e5 2a dd 5a 56 19 70 cc 23 4e ef ff 8d
0010   41 75 21 d7 6c 08 59 17 18 bd bd bf c8 37 7d 89
 
Packet #491
-------------
20.0.0.2 sent CREATE_CHILD_SA, SPI  = 155e338a15be05e7 (response to #487)
Nonce=
0000   7c ea 7c 8a cb 3e 6a af 26 12 df 81 38 c3 1d dc
0010   43 bd ab c9 5f 8e 5e 68 04 63 90 f1 4d 04 df 7b
 
Packet #493
-----------
20.0.0.1 sent CREATE_CHILD_SA, SPI =  ef0e5386bdbaf2b5 (response to #489)
Nonce=
0000   5f 55 a7 4c 51 ac 28 dd 85 63 6d 1b 0c 7b 72 52
0010   d5 ff 27 b3 de e7 8b 22 67 5f b7 8a ff 30 67 a9
 
Following logs are seen:
 
    Node A: charon: 12[IKE]IKE_SA rekey collision won, deleting rekeyed IKE_SA

    Node B: charon: 07[IKE]IKE_SA rekey collision lost, deleting redundant IKE_SA
 
And in packet #495,20.0.0.2 sends delete payload with SPIs 0be330b30dfa35a3, ef0e5386bdbaf2b5.
 
However, the lowest nonce value here seems to be the one with the other IKE_SA (Initiator SPI =5eaad45efb4206f7), with first octet as "0b".
So isn't charon deleting the wrong IKE_SA here?
 
 
 Keys for decryption in wireshark are given below: 
 ------------------------------------------
 Encryption algorithm: AES-CBC-128[RFC3602]
 Integrity algorithm: HMAC_SHA1_96[RFC2404]
 
Initiator spi0be330b30dfa35a3
Responder spief0e5386bdbaf2b5
Sk_ei061D33CBC8B079B10318E680091AF8D7
Sk_er24CFF921F005A5A38AF1178E1CCE928F
Sk_ai2095C4F9AA41C65F6A42C84EFD548FFAE7284D14
Sk_ar6CD9E2FBD59CE4763CC7B91882A99E1F4FDD0894
 
 
Initiator spi 5eaad45efb4206f7
Responder spi155e338a15be05e7
Sk_ei539B42D5BF2D7F9E4C4FE244884CE714
Sk_erAA4619C9F8587D3390EBF313C7DC5EB6
Sk_aiD5617A4702E6581C963990D1503D1E1555FFFF58
Sk_arA51632A5C6B9C28AFD0DF5959DDFF67E72331C47
 
 
Initiator spi5e5808206a752d4e
Responder spic7d8cd4a5dbe380e
Sk_eiD9ADC4BD378395DEAB7AB21F9B51F055
Sk_erFE7536DB36F0123A984DD2C4726A3E0D
Sk_aiA03EA0D0F94EB1A354BFDC844D9FFE4DFB7A72E8
Sk_arE052B5A0B6FACC51290EB434FA41576081161FD9
------------------------------------------
 
 
- Divya

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rekey2.pcap
Type: application/octet-stream
Size: 99342 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140502/84efdee4/attachment-0001.obj>