Sécurité et VPN : Négociation IPSec/protocoles IKE

Les erreurs d'IPsec %RECVD_PKT_INV_SPI et la reprise non valide SPI comportent les informations

13 août 2013 - Traduction automatique
Autres versions: PDFpdf | Anglais (20 mars 2013) | Commentaires


Contenu


Introduction

Ce document décrit la question d'IPsec quand les associations de sécurité (SAS) deviennent hors du sync entre les périphériques de pair.

Remarque: Contribué par Atri Basu, Anu M Chacko, et Wen Zhang, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Une des questions d'IPsec les plus communes est que SAS peut devenir hors du sync entre les périphériques de pair. En conséquence, un périphérique chiffrant chiffrera le trafic avec SAS que son pair ne connaît pas. Ces paquets sont lâchés sur le pair avec ce message connecté au 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

Remarque: Avec NAT-T, des messages RECVD_PKT_INV_SPI n'ont pas été correctement signalés jusqu'à ce que l'ID de bogue Cisco CSCsq59183 (clients enregistrés seulement) ait été réparé. (IPsec ne signale pas des messages RECVD_PKT_INV_SPI avec NAT-T)

Remarque: Sur la plate-forme des Routeurs de services d'agrégation de Cisco (ASR), les messages %CRYPTO-4-RECVD_PKT_INV_SPI n'ont pas été mis en application jusqu'à ce que la version 2.3.2 (12.2(33)XNC2) du Cisco IOS® XE. Également la note avec la plate-forme ASR, cette baisse particulière est deux enregistrés sous le puits global de compteur de baisse de qfp comme dans la baisse de caractéristique d'IPsec contre- suivant les indications de ces exemples :

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

D'abord, il est important de noter que ce message particulier est débit-limité dans le Cisco IOS à un taux de 1 par minute pour les raisons de sécurité évidentes. Si ce message pour un flux particulier (src/dst/spi) apparaît seulement une fois dans le log, alors ce pourrait juste être un état passager en même temps que le rekey d'IPsec où un pair peut commencer à utiliser nouvelle SA alors que le périphérique de pair n'est pas tout à fait prêt à employer même SA. Ce n'est normalement pas un problème car il est seulement provisoire et affecterait seulement quelques paquets. Cependant, il y a eu des bogues où ceci pourrait être un problème. Pour des exemples, voir s'il vous plaît les id de bogue Cisco CSCsl68327leavingcisco.com (clients enregistrés seulement) (perte de paquets pendant le rekey) ou CSCtr14840 (clients enregistrés seulement) (ASR : pertes de paquets pendant le rekey de la phase 2 dans certaines conditions).

D'autre part, il y a un problème si on observe plus d'un exemple des mêmes messages pour signaler le même SPI pour le même écoulement, tel que ces messages :

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

C'est une indication que le trafic blackholed, et peut ne pas récupérer jusqu'à ce que SAS expirent sur le périphérique de envoi ou jusqu'à Dead Peer Detection (DPD) donne un coup de pied dedans.

Reprise non valide SPI

En ce moment, Cisco recommande que vous activiez la caractéristique non valide de reprise de spi. Par exemple, sélectionnez la commande de crypto isakmp invalid-spi-recovery. Il y a quelques choses que vous devez connaître ce que cette commande fait et ne fait pas :

  • D'abord, la reprise non valide de spi sert seulement de mécanisme de reprise quand SAS sont hors de sync. Il aide à récupérer de cette condition, mais n'adresse pas la cause principale de pourquoi SAS sont hors de sync en premier lieu. Afin de comprendre mieux la cause principale, vous devez permettre à l'ISAKMP et l'ipsec mettent au point sur les deux points d'extrémité de tunnel. Si le problème se pose souvent, alors obtenez met au point et essai pour adresser la cause principale et pour masquer pas simplement le problème.

  • Il y a une fausse idée commune de ce que la commande de crypto isakmp invalid-spi-recovery fait réellement. Même sans cette commande, le Cisco IOS exécute déjà un genre de fonctionnalité non valide de reprise SPI quand il envoie un EFFACEMENT annoncent pour SA reçue au pair de envoi s'il a déjà IKE SA avec ce pair. De nouveau, ceci se produit indépendamment de, que la commande de crypto isakmp invalid-spi-recovery soit activée ou pas.

  • Avec la commande de crypto isakmp invalid-spi-recovery, il essaye d'adresser la condition où un routeur reçoit le trafic d'IPsec avec le SPI non valide et il n'a pas IKE SA avec ce pair. Dans ce cas, il essayera d'établir une nouvelle session d'IKE avec le pair et envoyer alors un EFFACEMENT annoncez au-dessus d'IKE de création récente SA. Cependant, cette commande ne fonctionne pas sous toutes les cryptos configurations. Les seules configurations pour lesquelles cette commande fonctionnera sont les crypto map statiques où le pair est explicitement défini et des pairs statiques est dérivés des crypto map instanciés, tels que VTI. Voici un résumé de cryptos configurations utilisées généralement et, que la reprise non valide de spi fonctionne avec cette configuration ou pas :

Crypto config Non valide-SPI-reprise ?
Crypto map statique Oui
Crypto-carte dynamique Non
P2P GRE avec le TP Oui
mGRE TP qui l'utilise avec le mappage statique de NHRP Oui
mGRE TP qui l'utilise avec le mappage dynamique de NHRP Non
sVTI Oui
Client d'EzVPN S/O

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

Beaucoup de fois le message d'erreur non valide SPI se produit par intermittence. Ceci le rend difficile à dépanner pendant qu'il devient très difficile de collecter l'approprié met au point. Les scripts EEM peuvent être très utiles dans ce cas.

Pour plus de détails, référez-vous aux scripts EEM utilisés pour dépanner des instabilités de tunnel provoquées par les index non valides de paramètre de Sécurité.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 115801