RFC: 3715
Оригинал: IPsec-Network Address Translation (NAT) Compatibility Requirements
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич
  1. Несовместимость между адресными идентификаторами IKE-протокола (Internet Key Exchange Protocol — IKE, RFC-2409) и NAT-модулями. IKE-протокол предусматривает использование IP-адресов в качестве идентификаторов виртуального соединения в первой и второй фазах установления защищенного виртуального соединения (Security Association — SA). Если выходной и входной NAT-модули вносят изменения в IP-адреса отправителя и получателя сообщения, то тогда IP-адреса в IP-заголовке и в идентификаторе соединения не совпадут, что повлечет за собой разрыв соединения, а такие IP-пакеты будут уничтожаться.

    Чтобы избежать использование IP-адресов в качестве идентификаторов виртуального соединения в первой и второй фазах установления SA-соединения, взамен можно использовать идентификаторы пользователей и полные DNS-имена. Когда необходимо проведение аутентификации пользователя, можно использовать тип идентификатора «ID_USER_FQDN» (то есть полное DNS-имя, RFC-2407). Если же необходимо проведение аутентификации сервера, то тогда также можно использовать тип идентификатора «ID_USER_FQDN». В каждом случае необходимо верифицировать, что предложенный идентификатор аутентифицирован на основе обработки электронного сертификата конечного субъекта соединения, если конечно в первой фазе установления SA-соединения был проведен обмен электронными сертификатами. Несмотря на то, что применение таких типов идентификаторов «USER_FQDN» и «FQDN» допускается IKE-протоколом, все будет зависеть от стратегии обеспечения безопасности, определяемой конкретным сетевым администратором безопасности, который может отказаться от таких типов идентификаторов.

    Так как IP-адрес источника сообщения, входящий в состав идентификатора во второй фазе установления SA-соединения, очень часто используется для формирования пятиэлементного определителя входного SA-соединения, IP-адрес получателя сообщения, протокол, ТСР/UDP-порты отправителя и получателя могут использоваться определителе SA-соединения с тем, чтобы не уменьшить точность обработки сообщений, поступающих из входного SA-соединения.

  2. Несовместимость между фиксированными номерами портов транспортного уровня источников сообщений при использовании IKE-протокола и NAPT-модулями. Например, если нескольким корпоративным IP-узлам необходимо установить SA-соединения с помощью IKE-протокола с одним и тем же внешним IP-узлом, причем все соединения проходят через один NAPT-модуль, то тогда для NAPT-модуля необходим механизм демультиплексирования входящих IKE-пакеты, источником которых является внешний IP-узел. Обычно, такая процедура сопровождается преобразованием номера UDP-порта источника сообщения в IKE-пакетах, которые направляет инициатор соединения. Следовательно, получатели этих IKE-пакетов должны иметь возможность приема IKE-трафика, в котором будет указан номер UDP-порта источника сообщения отличный от «500», а после направлять ответные сообщения на UDP-порт с этим номером. Особое внимение должно быть уделено предотвращению нештатных ситуаций при обновлении ключевой информации. Если при обмене ключевой информации не будет использоваться адаптивный (изменяющийся) UDP-порт получателя сообщения, то тогда NAT-модуль не сможет передать IP-пакеты с ключевой информацией истинному получателю.

  3. Несовместимость между совпадающими записями в специализированных базах данных (Security Policy Database — SPD, RFC-2401) взаимодействующих субъектов и NAT-модулями. Например, если несколько IP-узлов, обслуживаемых одним NAT-модулем, используют в качестве идентификаторов SA-соединений свои IP-адреса в период второй фазы IKE-протокола, они могут выбрать совпадающие SPD-записи, причем в которых будет указан один и тот же IP-адрес запрашиваемого IP-узла. А это может привести к тому, что отвечающий IP-узел может затем по ошибке передать IP-пакеты по другому SA-соединению. Это произойдет потому, что для отвечающего IP-узла все SA-соединения будут эквивалентны, так как они установлены между одинаковыми оконечными IP-узлами и могут использоваться для передачи одного и того же трафика.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.