crypto isakmp invalid-spi-recovery command on IKEv1 and IKEv2

[mhiyoshi]

Dear all,

I have two questions about invalid-spi-recovery mechanism below.

1. According to the following URL, in my understanding "crypto isakmp invalid-spi-recovery" command is just a work arround because this command itself does not resolve the invalid SPI right?

[DMVPN with Invalid SPI Recovery / DPD]
https://community.cisco.com/t5/vpn/dmvpn-with-invalid-spi-recovery-dpd/td-p/2116356

SPI Recovery basically means that the Responder router should respond to the VPN Initiator Router even if the SPI was invalid,
the reply from the responder would be a "Invalid Error" to the VPN initiator.

2. It does not seem that IKEv2 invalid-spi-recovery command however there is DPD command under ikev2 profile so this covers the crypto isakmp invalid-spi-recovery command right?

[Verify IPsec %RECVD_PKT_INV_SPI Errors and Invalid SPI Recovery Feature Information]
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115801-technote-iosvpn-00.html

There is a common misconception about the purpose and functionality of the crypto isakmp invalid-spi-recovery command.
Even without this command, Cisco IOS already performs a type of invalid SPI recovery functionality when it sends a DELETE notification to the sending peer for the SA that is received if it already has an IKE SA with that peer.
Again, this occurs regardless of whether the crypto isakmp invalid-spi-recovery command is activated.

R1(config)#crypto ikev2 profile TEST
R1(config-ikev2-profile)#?
IKEv2 profile commands:
*omit
  dpd               Enable IKE liveness check for peers

Best Regards,

Masanobu Hiyoshi

[Cisco_Virtual_Engineer]

1. The "crypto isakmp invalid-spi-recovery" command is indeed a work around. When an invalid SPI is received, this command allows the router to respond with an "Invalid Error" to the VPN initiator instead of simply ignoring the packet. So, it does not resolve the invalid SPI but gives an option to handle it.

2. As for the IKEv2 protocol, there is no direct equivalent to the "crypto isakmp invalid-spi-recovery" command. However, the "Dead Peer Detection (DPD)" mechanism under the IKEv2 profile can achieve a similar outcome. If the DPD detects a dead peer, it can initiate a new IKE negotiation, effectively recovering from any invalid SPI situations. So, while it's not a direct equivalent to the invalid-spi-recovery command, it covers a similar concept and can handle such situations.

Remember that the purpose of the crypto isakmp invalid-spi-recovery command is often misunderstood. Even without this command, the Cisco IOS already performs a type of invalid SPI recovery functionality when it sends a DELETE notification to the sending peer for the SA that is received if it already has an IKE SA with that peer. This occurs regardless of whether the crypto isakmp invalid-spi-recovery command is activated.

[tvotna]

IKEv2 does have Invalid SPI Recovery feature. It's described in RFC 7296, section 1.5. It allows sending of INVALID_SPI notifications in INFORMATIONAL exchange if a ESP packet arrives with an unrecognized SPI. There are two cases however. If the IKEv2 SA with the peer exists, it is easy to send the INVALID_SPI notification to the peer over the IKEv2 SA. Otherwise RFC suggests to send it without cryptographic protection, which opens up a DoS attack possibility and otherwise not a good idea. I don't believe Cisco routers do that.

IKEv1 Invalid SPI Recovery is different. When ESP packet with an unrecognized SPI arrives, the router initiates new IKEv1 exchange to the packet source if no IKEv1 SA exists with it (but only if "crypto isakmp invalid-spi-recovery" is configured). Then it sends Delete NOTIFY over to clear stale Phase 2 SA. The problem here is that the router must have either crypto map or crypto socket with the peer to initiate new IKEv1 exchange with it, which may not be the case on DMVPN hubs where spoke information is completely dynamic. So, the feature is only helpful for statically configured peers.

If IKEv1 SA already exists with the peer, the "crypto isakmp invalid-spi-recovery" is indeed not needed to terminate stale Phase 2 SA. The router simply sends Delete NOTIFY over.

HTH