[strongSwan] charon unable to handle rekeying with multiple transforms

[gowrishankar]

Hi,
   I am looking for clarification in strongswan implementation (v4.6.4 or
above) about its proposal on encryption (ENCR) algorithms while rekeying
IKE_SA using CHILD_SA. In my test, I have configured localnode running
strongswan, with ESP as:

ESP:3DES_CBC/AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

Remote node responded for IKE_AUTH to the local node on algorithms

ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

While rekeying IKE_SA using CHILD_SA, it is found that, strongswan
places always 3DES transform in its CHILD_SA request. Is this not
wrong ? While rekeying IKE_SA (using CHILD_SA), should this not be again
sending its configuration to remote node ? (i.e 3DES and AES_CBC be sent).

I have not yet gone through any other RFCs    than 4306 to understand
anything else here. But, if someone clarifies me, that will be much helpful.

Below are ipsec.conf entries relevant to this problem.

         esp=aes128-3des-sha1!
         ike=3des-integrity_sha1-prf_sha1-modp1024!
         ikelifetime="60s"
         keylife="300s"
         rekeymargin=5s
         reauth="no"

Below are portion of charon.log for better explanation.

Sep 30 07:08:32 15[ENC] generating IKE_AUTH request 1 [ IDi 
N(INIT_CONTACT) IDr AUTH N(USE_TRANSP) SA TSi TSr N(EAP_ONLY) ]
...
..
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
...
..
Sep 30 07:08:32 15[ENC]   generating rule 5 U_INT_16
Sep 30 07:08:32 15[ENC]    => => 2 bytes @ 0x7fe92e9516ae
Sep 30 07:08:32 15[ENC]    0: 00 03                <<<< (3DES)
Sep 30 07:08:32 15[ENC]   generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:08:32 15[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished
Sep 30 07:08:32 15[ENC] generated data for this payload => 8 bytes @ 
0x7fe91000434c
Sep 30 07:08:32 15[ENC]    0: 03 00 00 08 01 00 00 
03                          ........
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
...
..
Sep 30 07:08:32 15[ENC]   generating rule 5 U_INT_16
Sep 30 07:08:32 15[ENC]    => => 2 bytes @ 0x7fe92e9516ae
Sep 30 07:08:32 15[ENC]    0: 00 0C <<<< (AES_CBC)
Sep 30 07:08:32 15[ENC]   generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_ATTRIBUTE
...
..

Now, IKE_AUTH request is initiated and charon received response from
remote node.

Sep 30 07:08:32 16[ENC] parsed IKE_AUTH response 1 [ IDr AUTH 
N(USE_TRANSP) SA TSi TSr ]
...
..
Sep 30 07:08:32 16[IKE] maximum IKE_SA lifetime 60s
Sep 30 07:08:32 16[CFG] selecting proposal:
Sep 30 07:08:32 16[CFG]   proposal matches
Sep 30 07:08:32 16[CFG] received proposals: 
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Sep 30 07:08:32 16[CFG] configured proposals: 
ESP:3DES_CBC/AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Sep 30 07:08:32 16[CFG] selected proposal: 
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
...
..
Sep 30 07:08:32 16[CHD] adding inbound ESP SA
Sep 30 07:08:32 16[CHD]   SPI 0xc126599d, src 2001:db8:f:1::1 dst 
2001:db8:1:1::1
Sep 30 07:08:32 16[KNL] adding SAD entry with SPI c126599d and reqid {1}
Sep 30 07:08:32 16[KNL]   using encryption algorithm AES_CBC with key 
size 128
Sep 30 07:08:32 16[KNL]   using integrity algorithm HMAC_SHA1_96 with 
key size 160
Sep 30 07:08:32 16[KNL] sending XFRM_MSG_UPDSA: => 420 bytes @ 
0x7fe92df505d0
...
..
Sep 30 07:08:32 16[CHD] adding outbound ESP SA
Sep 30 07:08:32 16[CHD]   SPI 0xa856a478, src 2001:db8:1:1::1 dst 
2001:db8:f:1::1
Sep 30 07:08:32 16[KNL] adding SAD entry with SPI a856a478 and reqid {1}
Sep 30 07:08:32 16[KNL]   using encryption algorithm AES_CBC with key 
size 128
Sep 30 07:08:32 16[KNL]   using integrity algorithm HMAC_SHA1_96 with 
key size 160
Sep 30 07:08:32 16[KNL] sending XFRM_MSG_NEWSA: => 420 bytes @ 
0x7fe92df505d0

So, local node SPI is updated with ENCR algorithm AES_CBC as a chosen one.
Now, rekeying IKE_SA (having set reauth=no) using CHILD_SA takes place
after ike_lifetime-rekey_margin.

Sep 30 07:09:27 11[IKE] queueing IKE_REKEY task
...
..
Sep 30 07:09:27 11[ENC] generating CREATE_CHILD_SA request 2 [ SA No KE ]
...
..
Sep 30 07:09:27 11[ENC]   generating rule 8 TRANSFORMS
Sep 30 07:09:27 11[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
Sep 30 07:09:27 11[ENC]   generating rule 0 U_INT_8
Sep 30 07:09:27 11[ENC]    => 3
Sep 30 07:09:27 11[ENC]   generating rule 1 RESERVED_BYTE
Sep 30 07:09:27 11[ENC]    => 0
Sep 30 07:09:27 11[ENC]   generating rule 2 PAYLOAD_LENGTH
Sep 30 07:09:27 11[ENC]    => => 2 bytes @ 0x7fe9311557be
Sep 30 07:09:27 11[ENC]    0: 00 
08                                            ..
Sep 30 07:09:27 11[ENC]   generating rule 3 U_INT_8
Sep 30 07:09:27 11[ENC]    => 1 <<<< (ENCR)
Sep 30 07:09:27 11[ENC]   generating rule 4 RESERVED_BYTE
Sep 30 07:09:27 11[ENC]    => 0
Sep 30 07:09:27 11[ENC]   generating rule 5 U_INT_16
Sep 30 07:09:27 11[ENC]    => => 2 bytes @ 0x7fe9311557be
Sep 30 07:09:27 11[ENC]    0: 00 03                 <<<< (3DES)
Sep 30 07:09:27 11[ENC]   generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:09:27 11[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished
Sep 30 07:09:27 11[ENC] generated data for this payload => 8 bytes @ 
0x7fe908004664
Sep 30 07:09:27 11[ENC]    0: 03 00 00 08 01 00 00 
03                          ........
...
..
Sep 30 07:09:27 11[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished
Sep 30 07:09:27 11[ENC] generated data for this payload => 8 bytes @ 
0x7fe90800466c
Sep 30 07:09:27 11[ENC]    0: 03 00 00 08 03 00 00 02 <<<< INTEG 
HMAC_SHA1_96


Should both 3DES and AEC_CBS be chosen in its rekey proposal ? Or, the
earlier acceptance (by remote node)  be chosen again in rekeying ?

I have been looking at some of the codes in libcharon/encoding/payloads
to understand, but just wanted to head up before I spend more time here.

Thanks,
Gowri Shankar