Segurança e VPN : Negociação IPSec/Protocolos IKE

Erros do IPsec %RECVD_PKT_INV_SPI e informação dos recursos de recuperação do SPI inválido

13 Agosto 2013 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (20 Março 2013) | Feedback


Índice


Introdução

Este documento descreve a edição do IPsec quando as associações de segurança (SA) se tornam fora da sincronização entre os dispositivos de peer.

Nota: Contribuído por Atri Basu, por Anu M Chacko, e por Wen Zhang, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problema

Uma da maioria de edições do IPSec comum é que os SA podem se tornar fora da sincronização entre os dispositivos de peer. Em consequência, um dispositivo de criptografia cifrará o tráfego com SA que seu par não conhece aproximadamente. Estes pacotes são deixados cair no par com esta mensagem registrada ao 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: Com NAT-T, as mensagens RECVD_PKT_INV_SPI não foram relatadas corretamente até que a identificação de bug Cisco CSCsq59183 (clientes registrados somente) estêve fixa. (O IPsec não relata mensagens RECVD_PKT_INV_SPI com NAT-T)

Nota: Na plataforma do Roteadores dos serviços da agregação de Cisco (ASR), as mensagens %CRYPTO-4-RECVD_PKT_INV_SPI não foram executadas até a liberação 2.3.2 do ® XE do Cisco IOS (12.2(33)XNC2). Igualmente note com a plataforma ASR, esta gota particular é ambos registrados sob o poço global do contador de queda do qfp como no contador de queda da característica do IPsec segundo as indicações destes exemplos:

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

Primeiramente, é importante notar que este mensagem particular é limite de taxa no Cisco IOS a uma taxa de 1 pelo minuto para os motivos de segurança óbvios. Se esta mensagem para um fluxo particular (src/dst/spi) aparece somente uma vez no registro, a seguir poderia apenas ser uma condição transitória ao mesmo tempo que o IPsec rekey onde um par pode começar usar o SA novo quando o dispositivo de peer não for bastante pronto para uso o mesmo SA. Este não é normalmente um problema porque é somente provisório e afetaria somente alguns pacotes. Contudo, houve os erros onde este poderia ser um problema. Para exemplos, veja por favor o Bug da Cisco ID CSCsl68327leavingcisco.com (clientes registrados somente) (a perda de pacotes durante rekey) ou CSCtr14840 (clientes registrados somente) (ASR: as quedas de pacote de informação durante a fase 2 rekey sob certas condições).

Por outro lado, há um problema se mais de um exemplo das mesmas mensagens é observado para relatar o mesmo SPI para o mesmo fluxo, tal como estas mensagens:

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 é uma indicação que o tráfego blackholed, e não pode recuperar até que os SA expirem no dispositivo de envio ou até o Dead Peer Detection (DPD) retroceder dentro.

Recuperação do SPI inválido

Neste momento, Cisco recomenda que você permite os recursos de recuperação do SPI inválido. Por exemplo, incorpore o comando cripto da inválido-SPI-recuperação do isakmp. Há algumas coisas que você precisa de saber sobre o que este comando faz e não faz:

  • Primeiramente, a recuperação do SPI inválido serve somente como um mecanismo de recuperação quando os SA são fora da sincronização. Ajuda a recuperar desta circunstância, mas não endereça a causa de raiz de porque os SA são fora da sincronização no primeiro lugar. A fim compreender melhor a causa de raiz, você precisa de permitir o isakmp e o IPsec debuga em ambos os pontos finais do túnel. Se o problema ocorre frequentemente, a seguir obtenha debuga e tentam-no endereçar a causa de raiz e mascarar não apenas o problema.

  • Há uma concepção errada comum do que o comando cripto da inválido-SPI-recuperação do isakmp faz realmente. Mesmo sem este comando, o Cisco IOS já executa um tipo da funcionalidade da recuperação do SPI inválido quando envia uma SUPRESSÃO notifica para o SA recebido ao par de emissão se já tem IKE SA com esse par. Além disso, isto ocorre apesar de se o comando cripto da inválido-SPI-recuperação do isakmp está girado sobre ou não.

  • Com o comando cripto da inválido-SPI-recuperação do isakmp, tenta endereçar a circunstância onde um roteador recebe o tráfego de IPSec com SPI inválido e não tem IKE SA com esse par. Nesse caso, tentará estabelecer uma sessão de IKE nova com o par e para enviar então uma SUPRESSÃO notifique sobre IKE recém-criado SA. Contudo, este comando não trabalha sob todas as configurações de criptografia. As únicas configurações que este comando trabalhará para são os mapas estáticos de criptografia onde o par explicitamente é definido e os peer estáticos são derivados dos crypto map instantiated, tais como VTI. Está aqui um sumário de configurações de criptografia de uso geral e se a recuperação do SPI inválido trabalha com essa configuração ou não:

Configuração cripto Inválido-SPI-recuperação?
Mapa estático de criptografia Sim
Mapa cripto dinâmico Não
P2P GRE com TP Sim
mGRE TP que se usa com o mapeamento NHRP estático Sim
mGRE TP que se usa com o mapeamento NHRP dinâmico Não
sVTI Sim
Cliente ezvpn N/A

Pesquise defeitos Mensagens de Erro intermitentes do SPI inválido

Muitas vezes o Mensagem de Erro do SPI inválido ocorre intermitentemente. Isto faz difícil pesquisar defeitos enquanto se torna muito duro recolher o relevante debuga. Os scripts EEM podem ser muito úteis neste caso.

Para mais detalhes, refira os scripts EEM usados para pesquisar defeitos as aletas do túnel causadas por deslocamentos predeterminados inválidos do parâmetro de segurança.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 115801