Безопасность и VPN : Протоколы IPSec Negotiation/IKE

IPSec %RECVD_PKT_INV_SPI ошибки и информация функции восстановления недопустимого SPI

13 августа 2013 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (20 марта 2013) | Отзыв


Содержание


Введение

Когда сопоставления безопасности (SA) становятся из синхронизования между одноранговыми устройствами, этот документ описывает проблему IPSec.

Примечание. Внесенный Atri Basu, Anu м. Чацко, и Вэнь Чжана, специалистов службы технической поддержки Cisco.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Подробные сведения об условных обозначениях см. в документе "Условное обозначение технических терминов Cisco".

Проблема:

Одна из наиболее распространенных проблем IPSec - то, что SA могут стать из синхронизования между одноранговыми устройствами. В результате устройство шифрования зашифрует трафик с SA, о которых не знает его узел. Эти пакеты отброшены на узле с этим сообщением, зарегистрированным к 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

Примечание. С NAT-T правильно не сообщили о сообщениях RECVD_PKT_INV_SPI до идентификатора ошибки Cisco был установлен CSCsq59183 (только зарегистрированные клиенты). (IPSec не сообщает о сообщениях RECVD_PKT_INV_SPI с NAT-T),

Примечание. На Маршрутизаторах Cisco Aggregation Services (ASR) платформа сообщения %CRYPTO-4-RECVD_PKT_INV_SPI не были внедрены до Cisco IOS® XE Release 2.3.2 (12.2 (33) XNC2). Также обратите внимание с платформой ASR, это определенное отбрасывание зарегистрировано оба под глобальным qfp счетчик сбросов хорошо как в счетчике сбросов функции IPSec как показано в этих примерах:

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

Во-первых, важно обратить внимание, что это конкретное сообщение находится с ограниченной скоростью в Cisco IOS на скорости 1 в минуту из очевидных соображений безопасности. Если это сообщение для отдельного потока (src/dst/spi) только обнаруживается один раз в журнале, то это могло просто быть переменное состояние в то же время, поскольку IPSec повторно вводит, где один узел может начать использовать новый SA, в то время как одноранговое устройство не совсем готово использовать тот же SA. Это обычно - не проблема, поскольку это является только временным и только влияло бы на несколько пакетов. Однако были дефекты, где это могло быть проблемой. Для примеров см. идентификаторы ошибок Cisco CSCsl68327 leavingcisco.com(только зарегистрированные клиенты) (Потеря пакета во время повторно вводят) или CSCtr14840 (только зарегистрированные клиенты) (ASR: отбрасывание пакета во время фазы 2 повторно вводит при определенных условиях).

С другой стороны, если несколько экземпляров тех же сообщений, как наблюдают, сообщают о том же SPI для того же потока, такого как эти сообщения, существует проблема:

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

Это - индикация, что трафик помещен в черный список, и может не восстановиться, пока SA не истекают на передающем устройстве или пока не умирает Dead Peer Detection (DPD).

Восстановление недопустимого SPI

На этом этапе Cisco рекомендует включить функцию восстановления недопустимого SPI. Например, введите команду crypto isakmp invalid-spi-recovery. Существует несколько вещей, которые необходимо знать о том, что эта команда делает и не делает:

  • Во-первых, когда SA испытывают недостаток синхронизования, восстановление недопустимого SPI только служит механизмом восстановления. Это помогает восстанавливаться с этого условия, но не обращается к основной причине того, почему SA испытывают недостаток синхронизования во-первых. Чтобы лучше понять основную причину, необходимо включить isakmp, и ipsec отлаживают на обеих туннельных конечных точках. Если проблема часто происходит, то получите отладки и попытку обратиться к основной причине и не только замаскировать проблему.

  • Существует общее несовпадение того, что фактически делает команда crypto isakmp invalid-spi-recovery. Даже без этой команды, Cisco IOS уже выполняет своего рода функциональность восстановления недопустимого SPI, когда это передает УДАЛЕНИЕ, уведомляют для SA, полученного к узлу передачи, если это уже имеет IKE SA с тем узлом. Снова, это происходит независимо от того, включена ли команда crypto isakmp invalid-spi-recovery или нет.

  • С командой crypto isakmp invalid-spi-recovery это пытается обратиться к условию, где маршрутизатор получает Трафик IPSec с недопустимым SPI, и это не имеет IKE SA с тем узлом. В этом случае это попытается установить новый сеанс IKE с узлом и затем передать УДАЛЕНИЕ, уведомляют по недавно созданной IKE SA. Однако эта команда не работает во всех криптах - настройках. Единственные конфигурации, для которых будет работать эта команда, являются статическими криптокартами, где узел явно определен, и статические одноранговые узлы получены из инстанцированных криптокарт, таких как VTI. Вот сводка обычно используемых крипт - настроек и работает ли восстановление недопустимого SPI с той конфигурацией или нет:

Крипто-config Восстановление недопустимого SPI?
Статическая криптокарта Да
!--- Динамическую карту шифрования. Нет
GRE P2P с TP Да
TP mGRE, который использует со статическим NHRP - маршрутизацией Да
TP mGRE, который использует с динамическим NHRP - маршрутизацией Нет
sVTI Да
Клиент EzVPN Н/Д

Устраните неполадки неустойчивых сообщений об ошибках недопустимого SPI

Много раз сообщение об ошибках недопустимого SPI происходит периодически. Это мешает устранять неполадки, поскольку становится очень трудно собрать соответствующие отладки. Сценарии EEM могут быть очень полезными в этом случае.

Для получения дополнительной информации сошлитесь на Сценарии EEM, используемые для Устранения неисправностей Туннельных Откидных створок, Вызванных Недопустимыми Security Parameter Index.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 115801