10-02-2023 05:41 PM - edited 10-02-2023 06:42 PM
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
10-05-2023 02:30 AM
10-05-2023 09:12 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide