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