Introducción
Este documento describe el problema de IPSec cuando las asociaciones de seguridad (SA) se quedan sin sincronizar entre los dispositivos de peer.
Problema
Uno de los problemas más comunes de IPSec es que las SA pueden estar fuera de sincronización entre los dispositivos de peer. Como resultado, un dispositivo de cifrado cifra el tráfico con SA que su par no conoce. Estos paquetes son descartados por el peer y este mensaje aparece en el syslog:
Sep 2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
has invalid spi for destaddr=20.1.1.2, prot=50, spi=0xB761863E(3076621886),
srcaddr=10.1.1.1
Nota: Con NAT-T, los mensajes RECVD_PKT_INV_SPI no se notificaron correctamente hasta que se corrigió el Id. de error de Cisco CSCsq59183. (IPSec no informa los mensajes RECVD_PKT_INV_SPI con NAT-T.)
Nota: En la plataforma Cisco Aggregation Services Routers (ASR), los mensajes %CRYPTO-4-RECVD_PKT_INV_SPI no se implementaron hasta Cisco IOS® XE versión 2.3.2 (12.2(33)XNC2). Tenga en cuenta también con la plataforma ASR que esta caída en particular se registra tanto en el contador de caídas del procesador de flujo cuántico (QFP) global como en el contador de caídas de funciones de IPSec, como se muestra en los siguientes ejemplos.
Router# show platform hardware qfp active statistics drop | inc Ipsec
IpsecDenyDrop 0 0
IpsecIkeIndicate 0 0
IpsecInput 0 0 <======
IpsecInvalidSa 0 0
IpsecOutput 0 0
IpsecTailDrop 0 0
IpsecTedIndicate 0 0
Router# show platform hardware qfp active feature ipsec datapath drops all | in SPI
4 IN_US_V4_PKT_SA_NOT_FOUND_SPI 64574 <======
7 IN_TRANS_V4_IPSEC_PKT_NOT_FOUND_SPI 0
12 IN_US_V6_PKT_SA_NOT_FOUND_SPI 0
Es importante tener en cuenta que este mensaje en particular está limitado a la velocidad en el IOS de Cisco a una velocidad de uno por minuto por las evidentes razones de seguridad. Si este mensaje para un flujo determinado (SRC, DST o SPI) sólo aparece una vez en el registro, puede ser sólo una condición transitoria que esté presente al mismo tiempo que la clave IPsec donde un par puede comenzar a utilizar la nueva SA mientras que el dispositivo de par no está preparado para utilizar la misma SA. Esto normalmente no es un problema, ya que es sólo temporal y sólo afectaría a unos cuantos paquetes. Sin embargo, ha habido errores de funcionamiento donde esto puede ser un problema.
Consejo: Para ver ejemplos, consulte Cisco bug ID CSCsl68327 (Pérdida de paquetes durante la nueva clave), Cisco bug ID CSCtr14840 (ASR: caídas de paquetes durante la reclave de fase 2 bajo ciertas condiciones), o ID de bug Cisco CSCty30063 (ASR utiliza un nuevo SPI antes de que finalice QM).
Alternativamente, hay un problema si se observa más de una instancia del mismo mensaje para informar el mismo SPI para el mismo flujo, como estos mensajes:
Sep 2 13:36:47.287: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
has invalid spi for destaddr=20.1.1.2, prot=50, spi=0x1DB73BBB(498547643),
srcaddr=10.1.1.1
Sep 2 13:37:48.039: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
has invalid spi for destaddr=20.1.1.2, prot=50, spi=0x1DB73BBB(498547643),
srcaddr=10.1.1.1
Esta es una indicación de que el tráfico está en espera negra y puede que no se recupere hasta que las SA caduquen en el dispositivo de envío o hasta que se active la Detección de Peer Muerto (DPD).
Solución
Esta sección proporciona información que puede utilizar para resolver el problema que se describe en la sección anterior.
Recuperación SPI no válida
Para resolver este problema, Cisco recomienda que habilite la función de recuperación SPI no válida. Por ejemplo, ingrese el comando crypto isakmp invalid-spi-recovery. A continuación se muestran algunas notas importantes que describen el uso de este comando:
- Primero, la recuperación SPI inválida sólo funciona como un mecanismo de recuperación cuando las SA están fuera de sincronización. Ayuda a recuperarse de esta condición, pero no aborda el problema raíz que provocó que las SA se sintieran fuera de sincronización en primer lugar. Para comprender mejor la causa raíz, debe habilitar las depuraciones ISAKMP e IPsec en ambos puntos finales del túnel. Si el problema ocurre con frecuencia, obtenga las depuraciones e intente abordar la causa raíz (y no sólo enmascarar el problema).
- Existe una idea errónea común sobre el propósito y la funcionalidad del comando crypto isakmp invalid-spi-recovery. Incluso sin este comando, Cisco IOS ya realiza un tipo de funcionalidad de recuperación SPI inválida cuando envía una notificación DELETE al par de envío para la SA que se recibe si ya tiene una SA IKE con ese par. De nuevo, esto ocurre independientemente de si el comando crypto isakmp invalid-spi-recovery está activado.
- El comando crypto isakmp invalid-spi-recovery intenta abordar la condición donde un router recibe tráfico IPsec con SPI inválido y no tiene una SA IKE con ese par. En este caso, intenta establecer una nueva sesión IKE con el par y envía una notificación DELETE sobre la SA IKE recién creada. Sin embargo, este comando no funciona para todas las configuraciones crypto. Las únicas configuraciones para las que funciona este comando son crypto-maps estáticos donde el par se define explícitamente y los pares estáticos que se derivan de crypto-maps instanciados, como VTI. A continuación se muestra un resumen de las configuraciones criptográficas más utilizadas y si la recuperación SPI no válida funciona con esa configuración:
Configuración criptográfica |
Recuperación SPI no válida? |
crypto-map estático |
Yes |
Mapa criptográfico dinámico |
No |
P2P GRE con protección de túnel |
Yes |
Protección del Túnel mGRE que utiliza con mapeo NHRP estático |
Yes |
Protección de Túnel mGRE que utiliza con mapeo NHRP dinámico |
No |
sVTI |
Yes |
cliente EzVPN |
N/A |
Solución de problemas de mensajes de error de SPI intermitentes no válidos
Muchas veces el mensaje de error SPI no válido ocurre de forma intermitente. Esto dificulta la resolución de problemas, ya que resulta muy difícil recopilar las depuraciones relevantes. Los scripts de Embedded Event Manager (EEM) pueden ser muy útiles en este caso.
Nota: Para obtener más detalles, consulte el documento Secuencias de comandos de EEM utilizadas para solucionar problemas de inestabilidad de túnel causados por índices de parámetros de seguridad no válidos de Cisco.