Description

This article describes the issue of IKEv2 IKE_AUTH negotiation failing between SRX and another vendor device when SRX initiates the IKE negotiation with more than one IPsec proposal to the NSN eNB gateway.

Symptoms

Topology :
SRX(proposal1: AES, proposal2: 3DES)-----------NSN eNB(proposal: 3DES)
IKEv2 negotiation : 
IKE_SA_INIT-------------------------->
                                     <-------------IKE_SA_INIT
IKE_AUTH----------------------------->
SA payload:
     proposal #1: encryption algorithm: AES......
     proposal #2: encryption algorithm: 3DES......
                                          <-----------------IKE_AUTH
                                                             SA payload: 
                                                             proposal #1: encryption algorithm: 3DES......
After the negotiation, eNB has both IKE and IPsec SA; SRX has only the IKE SA. In the SRX IKE traceoption, the following error messages are generated:
ikev2_verify_sa: [11a9000/1251400] Error: No matching proposal found for type: 1
ikev2_state_error: [11a9000/1251400] Negotiation failed because of error Invalid syntax (7)
There is no issue, if eNB initiates IKEv2 negotiation or eNB configures AES as a IPsec proposal.

Solution

This issue is due to the proposal number being incorrect in the eNB IKE_AUTH packet's SA payload. In the IKE_AUTH negotiation, SRX sends all its IPSec proposals (#1 and #2) to eNB and eNB will use the selected proposal (3DES) to respond. However, the proposal number in the SA payload is 1 , which is incorrect. 

As per RFC 4306 - section 3.3.1:

"Proposal # (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be #1, and subsequent proposals MUST either be the same as the previous proposal (indicating an AND of the two proposals) or one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, all of the proposal numbers in the SA payload MUST be the same and MUST match the number on the proposal sent that was accepted. "

As 3des is the 2nd proposal on SRX, eNB should send IKE_AUTH with the proposal number as 2 . SRX checks this proposal number and logs the no matching proposal found for type 1 error. However, there is nothing the subsequent packet to inform the IKE peer; so eNB assumes that the IKE_AUTH negotiation is successful.

When eNB initiates the IKE negotiation, there is no proposal number error in SRX and IKE negotiation is successful. When eNB uses AES, the proposal number 1 is correct and the IKE negotiation is successful.

This is not an SRX bug. The workaround is to configure the proposal number as 1 .

Modification History

2020-06-12: Article reviewed for accuracy; No changes required