RFC: 3715
Оригинал: IPsec-Network Address Translation (NAT) Compatibility Requirements
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

Аннотация

Данный стандарт определяет известные проблемы несовместимости трансляторов сетевых адресов (Network Address Translation — NAT) и протоколов IPsec-архитектуры, а также определяет требования к процедуре адресации используемой в этих системах (в данном стандарте термин «требование» носит рекомендательный характер).

Оглавление

1. Введение

Протколы IPsec-архитектуры (RFC-2401), как правило, используются для построения виртаульных корпоративных сетей (Virtual Private Network — VPN), и в частности, для обеспечения удаленного доступа в корпоративную сеть Intranet. В настоящее время NAT-модули (RFC-3022 и RFC-2663) широко используются в так называемых «домашних шлюзах» (то есть в серверах доступа в сеть (маршрутизаторах), которые обслуживают несколько домашних компьютерных систем), а также и в других локальных системах, обеспечивающих удаленный доступ в Internet, например, в отелях. Очевидно, что IPsec/NAT-несовместимость является главным барьером при использовании протоколов IPsec-архитектуры в выше упомянутых системах.

2. Известные проблемы IPsec/NAT-несовместимости

Все проблемы IPsec/NAT-несовместимости могут быть разделены на три категории:

  1. Внутренние проблемы NA(P)T-модулей. Эти проблемы напрямую связаны с функциональными свойствами NA(P)T-модулей (RFC-3022). Данные проблемы несовместимости будут и в дальнейшем иметь место в любом NA(P)T-модуле.

  2. Проблемы, связанные с внедрением (реализацией) NA(P)T-модулей. Данные проблемы никак не связаны с внутренними функциональными свойствами NA(P)T-модулей, но они имеют место во многих практических реализациях NA(P)T-модулей (то есть при их внедрении). Включенную в эту категорию проблемы связаны с обработкой входных и выходных IP-пакетов, содержащих фрагменты блоков транспортного уровня. Так как эти проблемы не связаны с внутренними функциональными свойствами NA(P)T-модулей, они могут, в принципе, быть отнесены к перспективным проблемам внедрения NA(P)T-модулей. Однако, так как проблемы внедрения NA(P)T-модулей со всей очевидностью будут распространены повсеместно, то на них необходимо обращать внимание при всестороннем рассмотрении решений по внедрению NA(P)T-модулей.

  3. Дополнительные («вспомогательные») проблемы. Данная категория (группа) проблем связана с NA(P)T-модулями, которые как раз и предназначены для решения проблемы сквозного преодоления NA(P)T-модулей сообщениями IPsec-протоколов. Это весьма иронично, когда данные проблемы называют «вспомогательными», так как дополнительная функциональность NA(P)T-модулей, обеспечивающая их совместимость с IPsec-протоколами, в конечном счете, влечет за собой дополнительные проблемы IPsec/NAT-несовместимости, которые разрешить еще более трудно. Несмотря на то, что такой дополнительной функциональностью, обеспечивающей совместимость с IPsec-протоколами, обладают не все NA(P)T-модули, такие свойства NA(P)T-модулей становятся весьма популярными и на них необходимо обращать пристальное внимание при решении проблемы сквозного преодоления NA(P)T-модулей сообщениями IPsec-протоколов.

2.1. Внутренние проблемы NA(P)T-модулей

К этой категории проблем относятся следующие проблемы:

  1. Несовместимость между IPsec/АН-протоколом (RFC-2402) и NAT-модулями. Так как АН-заголовок включает в свой состав IP-адреса источника и получателя сообщения, защищенные с помощью процедуры вычисления проверочной суммы с использованием ключевой информации, а выходной и входной NAT-модули вносят изменения адресные поля IP-заголовка, то тогда значение в поле проверочной суммы не пройдет контрольную проверку и IP-пакет будет уничтожен. Так как ESP-заголовок (RFC-2406) не включает в свой состав IP-адреса источника и получателя сообщения, защищенные с помощью процедуры вычисления проверочной суммы с использованием ключевой информации, то для IPsec/ESP-протокола такой проблемы не существует.

  2. Несовместимость между процедурой вычисления проверочных сумм и NAT-модулями. Значения проверочных сумм ТСР/UDP-протоколов зависят IP-адресов источника и получателя сообщения, так как эти IP-адреса включаются в «псевдо-заголовок» при вычислении проверочных сумм. Следовательно, если IP-пакеты транслировались через выходной и входной NAT-модули, то тогда проверочные суммы, которые будут верифицироваться в приемных модулях, не пройдут эту проверку.

    Однако, при использовании IPsec/ESP-протокола складывается противоположная ситуация, то есть когда сообщения этого протокола транслируются через NAT-модули, если конечно не используются ТСР/UDP-протоколы (то есть используется сквозной IPsec-туннель или IPsec-сообщения защищаются с помощью GRE-процедуры (generic routing encapsulation), то есть общей процедуры повторного обрамления при маршрутизации IP-пакетов) или не вычисляются проверочные суммы (как это может быть при использовании UDP-протокола и IPv4-адресации). В соответствии со стандартом RFC-793, который специфицирует ТСР-протокол, проверочная сумма должна обязательно вычисляться и верифицироваться при использовании IPv4-адресации. При использовании IPv6-адресации, проверочная сумма ТСР/UDP-протоколов должна всегда вычисляться и верифицироваться.

    В протоколе передаче данных на основе управления потоком (Stream Control Transmission Protocol — SCTP, RFC-2960 и RFC-3309) используется алгоритм вычисления контрольной суммы «CRC32C», которая рассчитывается только для SCTP-пакета (общий заголовок и блоки данных), и при этом IP-заголовок не участвует в определении «CRC32C». Следовательно, NAT-модули не влияют на значение контрольной суммы SCTP-протокола, а значит и нет проблемы несовместимости.

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

  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-узлами и могут использоваться для передачи одного и того же трафика.

  1. Несовместимость между выбором индекса параметров безопасности IPsec-протоколов (Security Parameter Index — SPI) и NAT-модулями. Так как IPsec/ESP-трафик зашифровывается, он становится не доступен для NAT-модуля, и поэтому NAT-модуль должен использовать элементы IP- и IPsec-заголовков для демультиплексирования входящего IPsec-трафика. Для этой цели обычно используется битовая последовательность, включающая IP-адрес получателя сообщения, IPsec-протокол (АН/ESP) и SPI-индекс.

    Однако, так как SPI-индексы для исходящих и входящих SA-соединений изменяются независимо, NAT-модуль не способен определить (только с помощью проверки исходящего трафика) какое входящее SA-соединение со своим SPI-индексом соответствует тому или иному IP-узлу получателю сообщения. Следовательно, если два IP-узла, обслуживаемые одним NAT-модулем, попытаются одновременно установить SA-соединения с одним и тем же внешним IP-узлом, то тогда возможна ситуация, при которой NAT-модуль будет по ошибке транслировать входящие IPsec-пакеты по другому SA-соединению.

    Замечание. По существу, в данном случае нет прямой несовместимости с IPsec-протоколами, так как это, скорее всего, связано с практической реализацией. Это относится и к AH-протоколу, и к ESP-протоколу, IP-узел, получатель сообщения, определяет SPI-индекс, который будет использоваться в данном SA-соединении, причем этот выбор имеет значение только для принимающей стороны. В настоящее время, SA-соединение однозначно идентифицируется с помощью IP-адреса получателя сообщения, SPI-индекса и IPsec-протокола (АН/ESP). Кроме этого, значения SPI-индекса могут иметь значения в диапазоне «1…255», установленном IANA, и эти значения будут использоваться в дальнейшем. Это означает, что когда проводится процедура согласования SA-параметров с одним и тем же IP-узлом или сетевым шлюзом, внутренние IP-узлы, обслуживаемые одним NAPT-модулем, могут выбрать одно и то же значение SPI-индекса, например, первый IP-узел будет иметь входное SA-соединение:

    (SPI=470, Internal Dest IP=192.168.0.4)

    а второй IP-узел будет иметь входное SA-соединение:

    (SPI=470, Internal Dest IP=192.168.0.5)

    Приемный NAPT-модуль не способен определить принадлежность входящего IPsec-пакета, так как два внутренних IP-узла присвоили свои входящим SA-соединениям одинаковый SPI-индекс «470».

    Кроме того, возможна ситуация, когда IP-узел (получатель сообщения) промаркирует каждое одноадресное SA-соединение собственным уникальным SPI-индексом. В таком случае, IP-адрес IP-узла, получателя сообщения, необходим только для проверки того, что он является разрешенным уникальным IP-адресом этого IP-узла, и не нужен для проверки того, что специфический IP-адрес IP-узла, получателя сообщения, используется передающим IP-узлом. Используя этот способ проверки, NA(P)T-модуль может обеспечить низкую (но не нулевую) вероятность ошибочной доставки IPsec-пакетов по неверному маршруту (на другой внутренний IP-узел), даже тогда, когда два IP-узла или больше сформировали SA-соединения с одним и тем же внешним IP-узлом.

    Такой подход обеспечивает полную совместимость, но при этом требуется, чтобы соответствующий приемный IP-узел сделал изменения в распределении и назначении SPI-индексов и в кодировке «IPsec_esp_input(_)». Однако, NA(P)T-модули не способны обнаружить такую ситуацию, так как могут возникнуть проблемы с синтаксическим анализом полей полезной нагрузки в IKE-сообщениях. А от IP-узла, по-прежнему, может потребоваться использование диапазона SPI-индексов, стандартизированного для этих целей IANA.

  1. Несовместимость между вставляемыми IP-адресами и NAT-модулями. Так как поле полезной нагрузки защищено от какой-либо модификации (защита целостности), любые IP-адреса, входящие в состав IPsec-пакетов, не могут транслироваться через NAT-модули. Но эта проблема решается, если в составе NAT-модулей используется специализированный шлюз/интерфейс прикладного уровня (Application Layer Gateway — ALG), который, тем не менее, снижает эффективность самих NAT-модулей. К протоколам, которые используют вставляемые IP-адреса, относятся: FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (дополнительная функция) и некоторые сетевые игры. Для преодоления такой несовместимости необходимо встраивать дополнительные ALG-субмодули в IP-узел или сетевой шлюз безопасности, который бы мог преобразовывать прикладной трафик перед IPsec-обработкой для исходящего трафика и после IPsec-обработки для входящего трафика.

  2. Скрытая функциональная направленность NA(P)T-модулей. Очень часто NA(P)T-модуль требует отправки через него первого исходящего IP-пакета до начала передачи остального трафика. Это необходимо для того, чтобы NA(P)T-модуль провел внутренние настройки и перешел в нужный режим для обработки входного трафика. Функциональная направленность запрещает формирование не востребованных IPsec/SA-соединений с IP-узлами, расположенными за NA(P)T-модулем, который их обслуживает.

  3. Верификация определителя входящего SA-соединения. Полагая, что определители были согласованы во второй фазе IKE-протокола, то тогда в процессе обработки входящего SA-трафика будут уничтожаться разобрамленные IKE-пакеты, так как стандарт RFC-2401 требует, чтобы IP-адрес отправителя сообщения сравнивался с аналогичным IP-адресом, указанным в определителе SA-соединения, а такая проверка будет отрицательной в следствие того, что NA(P)T-модули вносят изменения в IKE-пакеты.

2.2. Проблемы внедрения (реализации) NA(P)T-модулей

К этой категории проблем относятся следующие проблемы:

  1. Неспособность NA(P)T-модулей обрабатывать трафик, отличный от UDP/TCP-трафика. Некоторые NA(P)T-модули уничтожают трафик, отличный от UDP/TCP-трафика, или преобразуют только IP-адреса, когда они обслуживают в внутренней стороны только один IP-узел. Такие NA(P)T-модули не способны обрабатывать трафик, состоящий из сообщений SCTP-, ESP- («protocol 50») или AH-протоколов («protocol 51»).

  2. NA(P)T-модули изменяют свое состояние в период тайм-аутов. Состояние NA(P)T-модуля изменяется по истечении определенного интервала времени, так как в этот период осуществляется процедура отображения UDP-протокола, причем в отсутствии трафика. Следовательно, даже когда IKE-пакеты могут корректно преобразовываться NA(P)T-модулем, последний может преждевременно изменить свое функциональное состояние.

  1. NA(P)T-модули не способны обрабатывать исходящий предварительно фрагментированный трафик. Большинство NA(P)T-модулей могут корректно фрагментировать исходящие IP-пакеты в том случае, когда размер IP-пакетов превышает MTU-размер, установленный на выходном интерфейсе. Однако, корректное преобразование исходящих IP-пакетов, которые были предварительно фрагментированы, затруднительно и многие NA(P)T-модули не способны обрабатывать их корректно. Как определено в стандарте RFC-3022, возможна ситуация, при которой два IP-узла могут быть источниками заранее фрагментированных IP-пакетов, поступающих на один и тот же внешний IP-узел, при этом идентификаторы фрагментов могут совпадать. Так как IP-узел, получатель сообщения, «доверяет» значению идентификатора фрагментации и началу фрагмента, необходимым для дальнейшей сборки (дефрагментации) сообщения, то тогда результирующее сообщение может быть не корректным. Отдельные NA(P)T-модули защищены от возможных коллизий, связанных с наличием одинаковых идентификаторов фрагментов, на основе наличия дополнительной процедуры преобразования идентификаторов. Такие коллизий не возникают, если NA(P)T-модули сами реализуют процедуру фрагментации, так как идентификатор фрагмента необходим только для конкретной пары IP-адресов (отправитель/получатель сообщений).

    Так как размер фрагмента может быть меньше чем 68 октетов (RFC-791), то тогда нет гарантии, что первый фрагмент будет содержать весь ТСР-заголовок (то есть целиком). Следовательно, NA(P)T-модуль, осуществляющий повторное вычисление проверочной суммы ТСР-протокола, сможет ее вычислить только в следующем фрагменте. Так как фрагменты могут быть переупорядочены (нарушена их естественная последовательность), в них могут добавляться IP-адреса, которые могут быть даже разделены между фрагментами, NA(P)T-модуль должен первоначально дефрагментировать сообщений и только потом осуществлять процедуру преобразования адресов. Отдельные NA(P)T-модули способны на это.

  2. NA(P)T-модули не способны обрабатывать входящий фрагментированный трафик. Так как только IP-пакет с первым фрагментом сообщения содержит полный IP/UDP/SCTP/TCP-заголовок, NA(P)T-модулю необходимо иметь возможность осуществлять преобразование, основываясь только на IP-адресе отправителя/получателя и идентификаторе фрагмента сообщения. А так как фрагменты могут быть переупорядочены, то тогда идентификатор конкретного фрагмента может быть не известен, если конечно последующие фрагмент поступит раньше начального фрагмента. Кроме этого, заголовки могут также передаваться частями в разных фрагментах. И поэтому NA(P)T-модулю необходимо иметь возможность осуществлять процедуру сборки сообщения, прежде чем закончить процедуру преобразования адресной информации. Отдельные NA(P)T-модули обладают такой функцией.

    Замечание. Что касается NA(P)T-модуля, то для осуществления процедуры трансляции адресной информации ему достаточно иметь IP-адрес отправителя/получателя, и поэтому это не вызывает никаких проблем. Однако, если имеют место части IPsec-или IKE-заголовков, передаваемые в разных фрагментах, то тогда необходима дополнительная функция сборки сообщений.

2.3. Дополнительные («вспомогательные») проблемы

К этой категории проблем относятся следующие проблемы:

  1. Контроль заголовка ISAKMP-сообщения (Internet Security Association and Key Management Protocol — протокол управления защищенными виртуальными соединениями и обменом ключевой информации в Internet, RFC-2408). В настоящее время, некоторые NA(P)T-модули допускают применение специализированных IKE-меток («cookies») для демультиплексирования входящего IKE-трафика. При демультиплексировании IKE-трафика на основе специализированных меток, как и при демультиплексировании на основе номера транспортного порта источника сообщения, могут возникнуть проблемы, связанные с процедурой обновления ключевой информации, так как в первой фазе это процедуры обычно не используются идентификаторы, использовавшиеся в предыдущем трафике.

  2. Применение специализированного номера порта транспортного уровня («500»). Так как некоторые прикладные программные IKE-модули не способны обрабатывать трафик, в котором указан намер UDP-порт источника сообщения, отличный от «500», некоторые NA(P)T-модули не преобразуют IP-пакеты, содержащие UDP-порт источника сообщения с номером «500». Это означает, что функциональность таких NA(P)T-модулей ограничена, то есть они могут обслуживать одновременно только одного, а не несколько IPsec-пользователей, связывающихся с конкретным IPsec-шлюзом (одиночное SA-соединение), за исключением ситуации, когда они контролируют заголовок ISAKMP-сообщения с целью проверки специализированных меток (идентификаторов). Однако, последнее может повлечь проблемы, рассмотренные выше.

  3. Контроль поля полезной нагрузки ISAKMP-сообщения. NA(P)T-модули, которые способны анализировать поля полезной нагрузки ISAKMP-сообщения, не могут «корректно воспринимать» синтаксис всех специфических элементов (субполей) поля полезной нагрузки, или способны «воспринимать» только специфические идентификаторы фирмы-производителя программного обеспечения («vendor_id») впериод проведения IKE-процедуры согласования параметров.

3. Требования по обеспечению IPsec/NAT-совместимости

Цель обеспечения IPsec/NAT-совместимости заключается в поиске и нахождении такого решения, которое позволит шире (а может быть и повсеместно) использовать функциональные возможности IPsec-протоколов, кроме уже известного способа, в основе которого лежит применение IPsec-протоколов в режиме туннелирования (РТУ).

При поиске решений по преодолению IPsec/NAT-несовместимости необходимо иметь в виду (учитывать) следующие критерии:

  • Переход на IPv6-адресацию

    Так как IPv6-адресация идет на смену IPv4-адресации в связи с ограниченностью IPv4-адресного пространства, то очень часто в процессе смены систем адресации используются NA(P)T-модули для согласования этих двух одновременно действующих адресных систем. Поэтому проблема IPsec/NAT-совместимости является промежуточной проблемой, которую необходимо решить в течении жестких временных еще до того, как IPv6-адресация будет использоваться повсеместно. Более того, весьма полезно, чтобы проблема IPsec/NAT-совместимости должна быть разрешима в более короткие временные сроки по сравнению с распространением IPv6-адресации.

    Так как внедрение IPv6-адресации требует изменений и в маршрутизаторах, и в IP-узлах, реальное решение проблемы IPsec/NAT-совместимости, которое требует изменения в маршрутизаторах и в IP-узлах, будет распространяться по Internet приблизительно в одно и тоже время с распространением IPv6-адресации. Таким образом, решение проблемы IP-sec/NAT-совместимости должно быть таковым, чтобы оно требовало изменений только в IP-узлах, но не в маршрутизаторах.

    Среди прочего, это подразумевает, что связь между IP-узлом и NA(P)T-модулем не должна рассматриваться при решении проблемы IPsec/NAT-совместимости, так как это могло бы потребовать, в свою очередь, изменений в NA(P)T-модулях и проверку совместимости между IP-узлом и NA(P)T-модулями. Говоря коротко, чтобы осуществить переход на IPv6-адресацию, необходимо такое решение, которое работало бы с существующими маршрутизаторами и NA(P)T-модулями в рамках существующеу инфраструктуры.

  • Совместимость протоколов

    Решение, обеспечивающее прозрачность NA(P)T-модулей для сообщений IPsec-протоколов, не предусматривает решение проблем, связанных с протоколами, для сообщений которых NA(P)T-модули не могут быть прозрачны, когда не используются IPsec-протоколы. Более того, для некоторых протоколов могут понадобиться ALG-субмодули, даже и в тех случаях, когда найденное решение обеспечивает прозрачность NA(P)T-модулей для сообщений IPsec-протоколов.

  • Безопасность

    Так как функциональная направленность NA(P)T-модулей обеспечивает в некотором смысле безопасность субсети, то тогда решения, обеспечивающие IPsec/NAT-совместимость, не должны пропускать произвольный IPsec- или IKE-трафик с произвольными IP-адресами IP-узлов (отправителей сообщений), расположенных с внешней стороны NA(P)T-модулей, несмотря на то, что функциональный режим NA(P)T-модулей должен обслуживать ранее установленное двунаправленное IPsec- и IKE-соединение.

    • Обслуживание удаленного пользователя

      Так как одним из основных предназначений IPsec-архитектуры является защита удаленного доступа в корпоративную Intranet-сеть, решение, обеспечивающие прозрачность NA(P)T-модулей, должно обеспечивать функционирование IPsec-протоколов в РТУ или L2TP-протокола (RFC-3193) совместно с IPsec-протоколами в транспортном режиме (РТР). Кроме того, это решение должно гарантировать прозрачность, если на маршруте следования IPsec-пакетов между удаленным пользователем и VPN-шлюзом встречаются несколько NA(P)T-модулей.

      Удаленный пользователь может иметь переменный IP-адрес «routable address»), в зависимости от точки подключения к Internet-сети, VPN-шлюз может обслуживаться, по крайней мере, одним NA(P)T-модулем, или, с другой стороны, удаленный пользователь и VPN-шлюз могут (каждый) обслуживаться несколькими NA(P)T-модулями. Удаленные пользователи могут использовать один и тот же корпоративный IP-адрес и каждый удаленный пользователь может обслуживаться своим собственным NA(P)T-модулем, или несколько удаленных пользователей располагаются в одной корпоративной сети, обслуживаемой одним и тем же NA(P)T-модулем, каждый из которых со своим собственным уникальным корпоративным IP-адресом соединяется с одним и тем же VPN-шлюзом. Так как IKE-протокол использует UDP-порт с номером «500», то тогда нет необходимости применять несколько VPN-шлюзов, взаимодействующих с одним и тем же внешним IP-узлом, имеющим определенный IP-адрес.

    • Соединение между шлюзами безопасности

      В случае применения защищенного соединения между шлюзами безопасности, предполагается, чтосети, использующие собственную внутреннюю адресацию (DeMilitarized Zone — DMZ-сеть), могут располагаться между корпоративной сетью и сегментом глобальной Internet-сети. Следовательно, IPsec-шлюзы безопасности, соединяющие сегменты корпоративной сети, могут быть резидентами этих DMZ-сетей и иметь в качестве идентификаторов своих внешних интерфейсов внутренние адреса этих DMZ-сетей. NA(P)T-модули соединяют DMZ-сети с Internet-сетью.

    • Сквозное соединение

      Решение, обеспечивающее IPsec/NAT-совместимость, должно защищать TCP/IP-соединения между IP-узлами с помощью IPsec-протоколов, а также и соединения между IP-узлами и шлюзами безопасности. IP-узел в корпоративной сети должен иметь возможность быть конечной точкой одного или нескольких защищенных IPsec-протоколами ТСР-соединений или UDP-сеансов связи с другим конечным IP-узлом через один или несколько NA(P)T-модулей между ними. Например, NA(P)T-модули могут быть размещены в удаленных сетевых сегментах компании и иметь соединения с корпоративной сетью и с дополнительным NA(P)T-модулем, соединяющим корпоративную сеть с Internet-сетью. Более того, NA(P)T-модули могут быть размешены в пределах корпоративной LAN/WAN-сети и обеспечивать соединения с удаленными клиентами (включая беспроводные соединения), желающими получить доступ в корпоративную сеть. Такие соединения могут потребовать наличия в IP-узле специализированной обработки TCP/UDP-трафика.

    Когда IP-узел устанавливает SCTP-соединение с другим IP-узлом, и на этом маршруте доставки IP-пакетов имеет место один или несколько NA(P)T-модулей, то тогда последние могут быть причиной некоторых специфических проблем. SCTP-протокол реализует функцию многоадресного информационного обмена. Если используется несколько IP-адресов, то тогда эти IP-адреса доставляются как часть SCTP-пакета в течении установления виртуального соединения (в субблоках «INIT» и «INIT-ACK»). Если в сквозном SCTP-соединении используются только одиночные IP-адреса (получатель/отправитель), то тогда стандарт RFC-2960 гласит:

    Если в субблоках «INIT» и «INIT-ACK» не используются IP-адресные параметры, то в этом случае существует альтернатива установить виртуальное соединение, которое, скорее всего, будет функционировать и через NAT-модуль.

    Это означает, что IP-адреса не должны размещаться в SCTP-пакете до тех пор, пока это не будет необходимо. Если же на пути следования IP-пакетов имеют место NA(P)T-модули, а в SCTP-пакетах размещены несколько IP-адресов, то тогда это виртуальное соединение «потерпит провал». В настоящее время существует проект стандарта, который предусматривает модификацию IP-адреса уже после установления виртуального соединения. Однако, сообщения о проведенной модификация в составе SCTP-пакета будут также содержать IP-адреса, и поэтому NA(P)T-модули на пути доставки SCTP-пакета будут также пагубно влиять на него.

    • Совместимость с межсетевыми экранами («firewall»)

      Так как межсетевые экраны очень широко используются в Internet-сети, решение, обеспечивающее IPsec/NAT-совместимость, должно обеспечивать администратору безопасности (при настройке межсетвого экрана) возможность устанавливать простые, стационарные правила доступа для пропуска или запрета IKE- и IPsec-трафика, транспортируемого через NA(P)T-модуль. Это подразумевает, например, что динамическое назначение номеров портов транспортного уровня при использовании IKE- или IPsec-протокола не допускается.

    • Масштабирование

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

    • Обеспечение необходимого функционального режима

      Как минимум, решение, обеспечивающее IPsec/NAT-совместимость, должно обеспечивать прозрачность при доставке IKE- и IPsec-пакетов в необходимых режимах в соответствии со стандартами RFC-2409 и RFC-2401. Например, IPsec-шлюз должен обеспечивать доставку IPsec-пакетов в РТУ через NA(P)T-модуль, а IPsec-узел должен обеспечивать доставку IPsec-пакетов в РТР через NA(P)T-модуль. Целью АН-протокола является защита неизменяемых полей в IP-заголовке (включая IP-адреса), а NA(P)T-модуль преобразует эти адреса, что приводит к отрицательному результату при проверке целостности АН-заголовка. В итоге, NA(P)T-модуль и АН-протокол абсолютно несовместимы и это означает, что нет требований к решению, обеспечивающее IPsec/NAT-совместимость, чтобы оно поддерживало АН-протокол в РТР или РТУ.

    • Обратная совместимость и способность взаимодействия

      Решение, обеспечивающее IPsec/NAT-совместимость, должно быть способно взаимодействовать с существующими прикладными программными IKE/IPsec-модулями, причем так, чтобы они могли взаимодйствовать друг с другом и там, где нет NA(P)T-модуля. Это означает, что решение, обеспечивающее IPsec/NAT-совместимость, должно обеспечивать обратную совместимость IPsec- и IKE-протоколами (RFC-2401 и RFC-2409). Кроме этого, оно должно обладать способностью определять наличие NA(P)T-модулей, и поэтому обеспечение прозрачности доставки IP-пакетов через NA(P)T-модули должно использоваться только тогда, когда это необходимо. Это означает, что решение, обеспечивающее IPsec/NAT-совместимость, должно быть способно в начале определить существующие прикладные программные IKE-модули, которые не обеспечивают прозрачную передачу сообщений через NA(P)T-модули, и затем обеспечить проведение стандартных процедур согласования IKE-протокола (RFC-2407, RFC-2408 и RFC-2409).

      Замечание. Насмотря на то, что все выше сказанное означает начало процедуры согласования IKE-протокола с порта транспортного уровня с номером «500», не существует требования об обязательном использовании этого специального номера транспортного порта, и поэтому UDP-порт с номером «500» может использоваться или может не использоваться.

    • Безопасность

      Решение, обеспечивающее IPsec/NAT-совместимость, не должно снижать уровень безопасности, обеспечиваемый IPsec- и IKE-протоколами. Например, приемлемое решение должно демонстрировать, что оно не снижает уровень защищенности от атак типа «отказ в обслуживании» или «маскарад». Кроме этого, оно должно обеспечить IKE-протоколу возможность проводить процедуру обновления ключевой информацией в условиях двунаправленного соединения (RFC-2408).

    4. Существующие решения

    4.1. Туннельный режим IPsec-протоколов

    В ограниченном числе случаев, существует возможность применения IPsec-протоколов в РТУ (RFC-3456) для успешной сквозной передачи IPsec-пакетов через NA(P)T-модули. Однако, существующие требования к обеспечению надежной передачи через NA(P)T-модули весьма ограничены, и поэтому для более общего решения, обеспечивающего IPsec/NAT-совместимость, эти требования необходимо расширить:

    1. ESP-протокол

      Функционирование ESP-протокола в РТУ не защищает выходной IP-заголовок с помощью процедуры обеспечения целостности, и поэтому процедура аутентификации данных не будет «провалена» вследствие преобразования адресов. Кроме этого, функционирование IPsec-протоколов в РТУ не должно быть связано с вычислением и проверкой проверочных сумм.

    2. Не проверять достоверность IP-адресов

      Большинство современных программных IPsec-модулей, функционируя в РТУ, не проверяют достоверность IP-адреса источника IP-пакета, поэтому проблемы несовместимости между IKE-идентификаторами и IP-адресами источников IP-пакетов не будут обнаруживаться. Однако, это снижает уровень защищенности.

    3. «Любые совпадающие и несовпадающие» SPD-записи («any to any»)

      Оконечные IPsec-пользователи в РТУ могут согласовывать любые (совпадающие и несовпадающие) стратегии обеспечения безопасности и другие параметры, хранящиеся в их SPD-базах, которые не зависят от преобразования адресной информации. Это серьезное препятствие для использования SPD-баз для фильтрации разрешенного туннелированного трафика.

    4. Функционирование одиночного пользователя

      Если NA(P)T-модуль обслуживает только одного пользователя, то тогда не существует проблем несовместимости, связанных с наличием совпадающих записей в специализированных SPD-базах SA-соединений. Так как NA(P)T-модулю не надо выступать в роли «третейского судьи» между конкурирующими пользователями, то в этом случае также нет проблем несовместимости, связанных с ошибочной доставкой ключевой информацией при обновлении последней, или неправильным входящим SPI-индексом, или неправильным идентификатором (специализированная метка) демультиплексирования.

    5. Не применять фрагментацию

      Когда используется процедура аутентификации на основе электронных сертификатов, то тогда могут возникнуть проблемы с фрагментацией IKE-сообщений. Это может иметь место тогда, когда используется несколько сертификатов, следующих друг за другом, или даже когда использеутся один серитификат, но размер ключа или размер других полей сертификата (например, характеристическое имя или другие дополнения) слишком большие. Однако, если для аутентификации используются предварительно согласованные ключи, то тогда фрагментация мало вероятна.

    6. Активные сеансы связи

      Большинство VPN-соединений (сеансов связи) обычно обрабатывают непрерывный поток трафика в течении «времени жизни» этих соединение, и поэтому мало вероятно, что процедура отображения номеров UDP-портов перейдет в пассивный режим.

    4.2. RSIP-протокол

    Данный протокол (Realm Specific IP, RFC-3102, RFC-3103, RFC-3104 и RFC-3105) определяет метод назначения специфического IP-адреса внешней зоны, который заключается в использовании специализированного корпоративного IP-узла для обеспечения соединений между IP-узлами корпоративной или внешней зон, который для таких соединений выделяет IP-адреса (идентификаторы) из адресного пространства внешней зоны корпоративным IP-узлам. RSIP-протокол имеет специальные механизмы, обеспечивающие прозрачное прохождение NA(P)T-модулей для IPsec-пакетов. Если установлено соединение IP-узлом, в состав которого встроен NA(P)T-модуль, то тогда RSIP-протокол может быть источником проблем, связанных с корректным демультиплексированием IPsec-трафика на основе SPI-индексов, а также на основе совпадающих записей в специализированных SPD-базах SA-соединений. Этот протокол подходит для применения в корпоративных (домашних) сетях. Если NA(P)T-модуль будет обслуживать несколько корпоративных (домашних) IP-узлов и ему будет выделен внешний IP-адрес (то есть он будет выступать в роли RSIP-шлюза), то тогда он будет совместим со многими протоколами, включая протоколы, использующие вставку дополнительных IP-адресов.

    За счет туннелирования IKE- и IPsec-пакетов RSIP-протокол устраняет возможность вносить какие-либо изменения в сообщения IKE- и IPsec-протоколов, несмотря на то, что программные IKE- и IPsec-модули, включенные в состав программного обеспечения IP-узлов, требуют значительной модернизации с целью обеспечения их совместимости с RSIP-модулем. Такое решение полностью совместимо со всеми существующими IPsec-протоколами (АН/ESP) независимо от режима их функционирования (РТР или РТУ).

    В целях управления демультиплексированием потока IKE-пакетов во время процедуры обновления ключевой информации, RSIP-протокол требует изменяемого номера порта транспортного уровня источника IKE-пакетов, а также изменяемого номера порта транспортного уровня получателя. В результате, имеет место функциональная несовместимость с существующими программными IPsec-модулями.

    RSIP-протокол не удовлетворяет требованиям, предъявляемым к решению, обеспечивающему IPsec/NAT-совместимость, так как IP-узел со встроенным RSIP-модулем требует соответствующего шлюза со встроенным RSIP-модулем для того, чтобы сформировать IPsec/SA-соединение с другим IP-узлом. Так как RSIP-модуль требует соответствующих изменений только в программном обеспечении пользователей и маршрутизаторов, и не требует этого в программном обеспечении прикладных служб, внедрение RSIP-протокола в Internet-сети происходит менее трудно, чем IPv6-адресации.

    Однако, с точки зрения продавцов сетевого программного обеспечения, программные прикладные RSIP-модули требуют значительную долю ресурсов, необходимых для обеспечения IPv6-адресации. Поэтому, RSIP-модули являются «промежуточным» решением, что, с точки зрения долгосрочной перспективы, неприемлемо.

    4.3. Сосуществование систем IPv4- и IPv6-адресации (6to4)

    Сосуществование двух систем адресации (RFC-3056) может послужить основой для нахождения решения, обеспечивающего IPsec/NAT-совместимость (IPv6/IPv4-решение). При таком подходе, NA(P)T-модуль, обслуживающий IP-узлы с IPv6-адресацией (в IP-пакетах указывается IPv6-префикс) и имеющий IPv4-адрес внешнего NA(P)T-модуля, осуществляет процедуру повторного обрамления IPv6-пакетов и, таким образом, формирует IPv4-пакеты (IPv6/IPv4-пакетов) для передачи на другие конечные или ретрансляционные IP-узлы, которые способны обрабатывать IPv6/IPv4-пакеты. Такое технологическое решение позволяет IPv6-узлам использовать IPsec-протоколы и свободно связываться с другими IPv6-узлами или IP-узлами, которые способны обрабатывать IPv6/IPv4-пакеты.

    Несмотря на то, что IPv6/IPv4-решение является лучшим и надежным решением особенно там, где одиночный NA(P)T-модуль обслуживает с одной стороны пользователя, а с другой — VPN-шлюз, тем не менее, оно не пригодно для всеобщего применения. Очевидно, что IPv6/IPv4-решение требует назначения внешнего официально зарегистрированного (а не корпоративного адреса, RFC-1918 [?] ) IPv4-адреса для NA(P)T-модуля с целью формирования IPv6-префикса, однако это не применимо в тех случаях, когда несколько NA(P)T-модулей обслуживают с одной стороны пользователя, а с другой — VPN-шлюз. Например, NA(P)T-модуль, который имеет корпоративный IP-адрес на своем внешнем интерфейсе, не может использоваться пользователями, расположенными за ним, для применения IPv6-префикса, при передаче IP-пакета через внешний сетевой IPv6/IPv4-сегмент.

    Несмотря на то, что IPv6/IPv4-решение требует небольших дополнений в IP-узлах, которые уже работают с IPv6-адресацией, оно требует значительных изменений в NA(P)T-модулях, которые необходимо дополнить программными IPv6/IPv4-модулями. Следовательно, IPv6/IPv4-решение не является краткосрочным решением.

    5. Вопросы безопасности

    По определению, IPsec/NAT-совместимость требует, чтобы IP-узлы и маршрутизаторы, использующие IPsec-протоколы, были способны надежно обрабатывать IP-пакеты, у которых IP-заголовки не защищены с помощью криптографических методов защиты информации.

    Так как IPsec/АН-пакеты не могут транспортироваться через NA(P)T-модуль, то тогда одним из побочных эффектов внедрения решения, обеспечивающего IPsec/NAT-совместимость, может быть использование ESP-протокола в режиме «холостого» шифрования (отсутствие шифрования — «null encryption») вместо АН-протокола в тех сетевых сегментах, где между отправителем и получателем IP-пакетов имеет место NA(P)T-модуль. Однако, необходимо указать, что ESP-протокол в режиме «холостого» шифрования не обеспечивает такую же защищенность как АН-протокол. Например, наличие рисков безопасности, связанных с маршрутизацией IPv6-пакетов источника, которые устраняются при использовании АН-протокола и не устраняются при использовании ESP-протокола в режиме «холостого» шифрования.

    Кроме этого, так как ESP-протокол, в любом режиме шифрования, не защищает IP-адрес источника от атак типа «маскарад», некоторые типы IP-адресов должны проходить соответствующую проверку. Важность этой проверки не всегда понятна. Обычно, эта проверка относится к IP-адресу источника сообщения, как часть проверки «IPsec_{esp,ah}_input(_)». Она гарантирует, что IP-адрес отправителя совпадает с IP-адресом, который указывался в период проведения первой и второй фаз IKE-протокола, то есть установления SA-соединения. Когда принимающий IP-узел обслуживается NA(P)T-модулем, то тогда такая проверка может быть полностью бессмысленна для одноадресных сеансов связи, поскольку в глобальной Internet-сети такая проверка имеет смысл только для одноадресных сеансов связи в РТУ, так как она позволяет предотвращать атаки типа «маскарад». В последнем случае эта проверка может осуществляться тогда, когда доступ к приемнику контролируется на основе верификации ESP-пакетов после их разобрамления и проверки IP-адрес отправителя. Решения, обеспечивающие IPsec/NAT-совместимость, должны включать средство защиты от атак типа «маскарад», если эти решения используют систему управления доступом на основе проверки IP-адреса отправителя.

    Положим, что имеют место два IP-узла «А» и «С», которые обслуживаются разными NA(P)T-модулям, и желают согласовать IPsec/SA-соединения в РТУ с марщрутизатором «В». IP-узлы «А» и «С» могут иметь различные привилегии, например, IP-узел «А» может принадлежать штатному сотруднику компании, который авторизован для доступа ко всем информационным подсистемам корпоративной Intranet-сети, а IP-узел «С» может принадлежать временному сотруднику компании, который авторизован для доступа только к конкретному WWW-серверу.

    Если IP-узел «С» передает IP-пакет в РТУ, указывая ложный IP-адрес источника (IP-адрес IP-узла «А», атака «маскарад»), то тогда очнь важно, чтобы этот IP-пакет «не пользовался привилегиями», которые принадлежат IP-узлу «А». Если проводится процедура аутентификации и защиты целостности, но при этом не проводится проверка с целью защиты от атак типа «маскарад» (проверка того, что IP-адрес источника сообщения соответствует IP-адресу, уазанному в SPI-индексе), то тогда IP-узел «С» может проникнуть в те сегменты и подсистемы корпоративной сети, в которые доступ для него запрещен. Следовательно, Решения, обеспечивающие IPsec/NAT-совместимость, должны обеспечивать определенной аровнь защищенности от атак типа «маскарад».

    6. Литература

    6.1. Нормативные документы

    [RFC-791] Postel, J., «Протокол IP», RFC 791, STD 5, Сентябрь 1981.
    [RFC-793] Postel, J., «Протокол TCP», RFC 793, STD 7, Сентябрь 1981.
    [RFC-2119] Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», BCP 14, RFC 2119, Март 1997.
    [RFC-2401] Atkinson, R. и S. Kent, «Security Architecture for the Internet Protocol», RFC 2401, Ноябрь 1998.
    [RFC-2402] Kent, S. и R. Atkinson, «IP Authentication Header», RFC 2402, Ноябрь 1998.
    [RFC-2406] Kent,S. и R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, Ноябрь 1998.
    [RFC-2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, Ноябрь 1998.
    [RFC-2409] Harkins, D. и D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, Ноябрь 1998.
    [RFC-2663] Srisuresh, P. и M. Holdredge, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, Август 1999.
    [RFC-3022] Srisuresh, P. и K. Egevang, «Традиционная трансляция сетевых адресов IP (NAT)», RFC 3022, Январь 2001.

    6.2. Дополнительная литература

    [RFC-2408] Maughan, D., Schertler, M., Schneider, M. и J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, Ноябрь 1998.
    [RFC-2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, M. и V. Paxson, «Stream Control Transmission Protocol», RFC 2960, Октябрь 2000.
    [RFC-3056] Carpenter, B. и K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, Февраль 2001.
    [RFC-3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. и S. Booth, «Securing L2TP using IPsec», RFC 3193, Ноябрь 2001.
    [RFC-3309] Stone, J., Stewart, R. и D. Otis, «Stream Control Transmission Protocol (SCTP) Checksum Change», RFC 3309, Сентябрь 2002.
    [RSIPFrame] Borella, M., Lo, J., Grabelsky, D. и G. Montenegro, «Realm Specific IP: Framework», RFC 3102, Октябрь 2001.
    [RSIP] Borella, M., Grabelsky, D., Lo, J. и K. Taniguchi, «Realm Specific IP: Protocol Specification», RFC 3103, Октябрь 2001.
    [RSIPsec] Montenegro, G. и M. Borella, «RSIP Support for End-to-End IPsec», RFC 3104, Октябрь 2001.
    [DHCP] Patel, B., Aboba, B., Kelly, S. и V. Gupta, «Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode», RFC 3456, Январь 2003.
    [AuthSource] Kent, S., «Authenticated Source Addresses», IPsec WG Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-Id: <[email protected] [128.89.0.110]>, 5 Января, 1996.
    [AddIP] Stewart, R., et al., «Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration», Work in Progress.

    7. Благодарности

    Thanks to Steve Bellovin of AT&T; Research, Michael Tuexen of Siemens, Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel Senie for useful discussions of this problem space.

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