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

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-портов перейдет в пассивный режим.

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