Vérifier les erreurs IPsec %RECVD_PKT_INV_SPI et les informations de fonctionnalité de récupération SPI non valides

Introduction

Ce document décrit le problème IPsec lorsque les associations de sécurité (SA) ne sont plus synchronisées entre les périphériques homologues.

Problème

L’un des problèmes les plus courants liés à IPsec est que les associations de sécurité peuvent devenir désynchronisées entre les périphériques homologues. Par conséquent, le point d'extrémité de cryptage crypte le trafic avec une SA que son homologue ne connaît pas. Ces paquets sont abandonnés par l'homologue et ce message apparaît dans le syslog :

Sep  2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for 
destaddr=10.10.1.2, prot=50, spi=0xB761863E(3076621886), srcaddr=10.1.1.1

Remarque : sur les plates-formes de routage Cisco IOS® XE, par exemple, les routeurs de services d'agrégation Cisco (ASR) et les routeurs de la gamme Cisco Catalyst 8000, cette suppression particulière est enregistrée à la fois dans le compteur de suppression QFP (Quantum Flow Processor) global et dans le compteur de suppression de fonctionnalité IPsec, comme illustré dans les exemples suivants.

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

Il est important de noter que ce message particulier est limité en débit dans Cisco IOS® à un débit d'une par minute pour des raisons évidentes de sécurité. Si ce message pour un flux particulier (SRC, DST ou SPI) n'apparaît qu'une seule fois dans le syslog, il s'agit probablement d'une condition transitoire qui est présente en même temps que la nouvelle clé IPsec, où un homologue peut commencer à utiliser la nouvelle SA alors que le périphérique homologue n'est pas tout à fait prêt à utiliser la même SA. Ce n'est normalement pas un problème, car il n'est que temporaire et n'affecterait que quelques paquets.

Toutefois, si le même message persiste pour le même flux et le même numéro SPI, cela indique que les SA IPsec ne sont plus synchronisées entre les homologues. Exemple :

Sep  2 13:36:47.287: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for 
destaddr=10.10.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=10.10.1.2, prot=50, spi=0x1DB73BBB(498547643), srcaddr=10.1.1.1

Ceci indique que le trafic est bloqué et ne peut pas être récupéré tant que les SA n'expirent pas sur le périphérique émetteur ou tant que la détection d'homologue mort (DPD) n'est pas activée.

Solution

Cette section fournit des informations que vous pouvez utiliser afin de résoudre le problème décrit dans la section précédente.

Récupération SPI non valide

Afin de résoudre ce problème, Cisco recommande que vous activiez la fonctionnalité de récupération SPI non valide. Par exemple, entrez la commande crypto isakmp invalid-spi-recovery. Voici quelques remarques importantes qui décrivent l'utilisation de cette commande :

• Tout d'abord, la récupération SPI non valide sert de mécanisme de récupération uniquement lorsque les associations de sécurité ne sont pas synchronisées. Il permet de récupérer à partir de cette condition, mais il ne résout pas le problème racine qui a causé la désynchronisation des SA en premier lieu. Afin de mieux comprendre la cause première, vous devez activer les débogages ISAKMP et IPsec sur les deux points d'extrémité du tunnel. Si le problème se produit souvent, obtenez les débogages et essayez de résoudre la cause première (et pas seulement de masquer le problème).
  
  
• Il y a une idée fausse commune sur le but et la fonctionnalité de la commande crypto isakmp invalid-spi-recovery. Même sans cette commande, Cisco IOS exécute déjà un type de fonctionnalité de récupération SPI non valide lorsqu'il envoie une notification DELETE à l'homologue expéditeur pour l'association de sécurité qui est reçue s'il a déjà une association de sécurité IKE avec cet homologue. Encore une fois, cela se produit indépendamment du fait que la commande crypto isakmp invalid-spi-recovery soit activée ou non.
  
  
• La commande crypto isakmp invalid-spi-recovery tente de résoudre la condition dans laquelle un routeur reçoit du trafic IPsec avec un SPI non valide, et il n'a pas d'association de sécurité IKE avec cet homologue. Dans ce cas, il tente d'établir une nouvelle session IKE avec l'homologue et envoie une notification DELETE sur la SA IKE nouvellement créée. Cependant, cette commande ne fonctionne pas pour toutes les configurations de chiffrement. Les seules configurations pour lesquelles cette commande fonctionne sont les crypto-cartes statiques où l'homologue est explicitement défini et les homologues statiques qui sont dérivés de crypto-cartes instanciées, telles que VTI. Voici un résumé des configurations de chiffrement couramment utilisées et si la récupération SPI non valide fonctionne avec cette configuration :
  
  

Dépanner les messages d'erreur SPI non valides intermittents

Souvent, le message d'erreur SPI non valide apparaît par intermittence. Cela rend le dépannage difficile, car il devient très difficile de collecter les débogages appropriés. Les scripts EEM (Embedded Event Manager) peuvent être très utiles dans ce cas.

Remarque : pour plus de détails, reportez-vous au document Cisco Scripts EEM utilisés pour dépanner les failles de tunnel provoquées par des index de paramètres de sécurité non valides.

Bogues connus

Cette liste montre les bogues qui peuvent provoquer la désynchronisation des SA IPsec ou qui sont liés à la récupération SPI non valide :

• ID de bogue Cisco CSCvn31824 Cisco IOS XE ISAKMP supprime le nouveau SPI si rx nouveau paquet SPI avant l'installation
• ID de bogue Cisco CSCvd4054 IKEv2 : Cisco IOS ne peut pas analyser la notification INV_SPI avec SPI taille 0 - envoie INVALID_SYNTAX
• ID de bogue Cisco CSCvp16730 Les paquets ESP entrants dont la valeur SPI commence par 0xFF sont abandonnés en raison d'une erreur SPI non valide