StrongSwan 6 beta 5 | Failed to generate a common proposal even though there is an acceptable choice

[AlmogJakov]

StrongSwan 6 beta 5 | Failed to generate a common proposal even though there is an acceptable choice

• The proposals of each of the two peers are printed in the output below
• The proposals in both peers (below) are configured in a somewhat challenging way to check the correctness of the calculation of the common proposal [according to the RFC, a selection must be made without duplication of algorithms in the KEs]

Logs output:
15[NET] received packet: from 172.23.43.14[500] to 172.23.43.12[500] (376 bytes) 15[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(IKE_INT_SUP) ] 15[IKE] 172.23.43.14 is initiating an IKE_SA 15[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256/MODP_1536/MODP_1024/KE1_KYBER_L5/KE1_KYBER_L3/KE1_KE_NONE/KE2_KYBER_L3/KE3_KYBER_L1/KE4_KYBER_L5/KE5_KYBER_L5/KE5_KE_NONE/KE6_MODP_6144/KE6_MODP_4096, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 15[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/MODP_1536/MODP_2048/KE1_KYBER_L5/KE1_KE_NONE/KE2_KYBER_L3/KE2_MODP_2048/KE3_KYBER_L1/KE4_KYBER_L5/KE5_KYBER_L1/KE5_KE_NONE/KE6_MODP_3072/KE6_MODP_4096/KE6_MODP_6144/KE6_MODP_8192 15[IKE] received proposals unacceptable 15[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]

Note that the following choice should be acceptable to both peers:
Encryption: AES_CBC_256
Integrity: HMAC_SHA1_96
PRF: PRF_HMAC_SHA1
KE: MODP_1536
AKE1: KE1_KE_NONE
AKE2: KE2_KYBER_L3
AKE3: KE3_KYBER_L1
AKE4: KE4_KYBER_L5
AKE5: KE5_KE_NONE
AKE6: KE6_MODP_6144

[strongX509]

The KE algorithm parser goes through the seven KE rounds in one pass only, i.e. first the algorithm of KE1 is determined, then KE2, KE3, ... up to KE7, eliminating duplicate algorithm definitions on the way. You also have to consider the setting of the prefer_configured_proposals option in strongswan.conf:

Prefer locally configured proposals for IKE/IPsec over supplied ones as responder
(disabling this can avoid keying retries due to INVALID_KE_PAYLOAD notifies)

which by default is set to yes but you assume it to be no but with either option the parsing fails in round KE4:

received proposals:
 IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/
 ECP_256/MODP_1536/MODP_1024/
 KE1_KYBER_L5/KE1_KYBER_L3/KE1_KE_NONE/
 KE2_KYBER_L3/
 KE3_KYBER_L1/
 KE4_KYBER_L5/
 KE5_KYBER_L5/KE5_KE_NONE/
 KE6_MODP_6144/KE6_MODP_4096,
 
configured proposals:
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/                      # prefer local:yes    prefer local:no
MODP_1024/MODP_1536/MODP_2048/                                   # MODP_1024           MODP_1536 
KE1_KYBER_L5/KE1_KE_NONE/                                        # KE1_KYBER_L5        KE1_KYBER_L5
KE2_KYBER_L3/KE2_MODP_2048/                                      # KE2_KYBER_L3        KE2_KYBER_L3
KE3_KYBER_L1/                                                    # KE3_KYBER_L1        KE3_KYBER_L1
KE4_KYBER_L5/                                                    # already used!!!     # already used!!!
KE5_KYBER_L1/KE5_KE_NONE/                                        # KE5_KE_NONE         KE5_KE_NONE
KE6_MODP_3072/KE6_MODP_4096/KE6_MODP_6144/KE6_MODP_8192          # KE6_MODP_4096       KE6_MODP_6144

Adding KE4_KE_NONE would lead to an acceptable proposal.

[AlmogJakov]

@strongX509 ,
I did not notice that the RFC defined selection in the form of 'one pass only'
In addition to the above, when the StrongSwan is the initiator and the peer chooses (of course, not in the form of 'one pass only') the acceptable common proposal as I mentioned above, then the StrongSwan accepts this choice and the tunnel is successfully established

Does the implementation in the form of 'one pass only' result only from a consideration of optimization?
After all, if we want to be more generic, then we can also deal with complex proposals and not choose in a greedy way that can result in 'no proposals chosen'

I assume that there are reasons for certain vendors to define proposals in different forms so that the above scenario may happen many times

[strongX509]

RFC 9370 does not specify how the proposed transform algorithms are selected, so we opted for a simpler one pass solution.