Кратко

  • RFC 3948 провела IKE и инкапсулированный в UDP ESP через одно отображение NAT и обозначила IKE четырьмя нулевыми октетами, поскольку допустимый SPI ESP не мог быть нулём.
  • Маркер решал только первую задачу разбора. Поиск SA, защита от повторов, криптографическая проверка, политика внутренних адресов и результат приложения оставались отдельными решениями, а 0xFF не подтверждал жизнь соединения.

Один внешний путь для разных машин состояния

Инкапсуляция ESP в UDP давала транслятору привычные транспортные порты. Но тем же узлам требовался IKE, который согласовывал ключи и Security Associations. Если держать отдельное NAT-отображение для управления и данных, появлялись дополнительные таймеры, правила межсетевого экрана и способы отказа.

RFC 3948 сознательно выбрала общий порт. Одно отображение лучше масштабировалось, обычный трафик уменьшал необходимость в отдельных IKE keepalive, межсетевому экрану хватало одного разрешённого порта, а реализации управляли меньшим количеством внешнего состояния. RFC 3947 описала переговоры NAT-Traversal и перевод последующего IKE-трафика на UDP 4500.

Общий порт не сделал IKE и ESP одним протоколом. После UDP-заголовка получателю всё равно требовалось выбрать правильную логику. Для этого RFC 3948 использовала значение, которое корректный ESP-пакет не мог передать как обычный идентификатор.

Запрещённый ноль стал указателем

ESP начинается с 32-битного Security Parameters Index. По SPI получатель ищет состояние SA, необходимое для обработки пакета. RFC 2406 резервирует нулевое значение для локального применения и исключает его из обычной передачи. RFC 3948 прямо требует ненулевой SPI у UDP-инкапсулированного ESP.

Перед IKE-заголовком на UDP 4500, напротив, вставляются четыре нулевых октета. Non-ESP Marker занимает то место, где у ESP находился бы SPI. Нулевое первое слово направляет полезную нагрузку к IKE; ненулевое позволяет попробовать путь ESP.

Эта экономная договорённость не была средством аутентификации. Четыре нуля не являлись секретом, подписью или MAC, не называли собеседника и не указывали конкретный IKE SA. Формат, состояние и аутентификацию IKE проверял уже после классификации.

Ненулевое слово тоже не означало, что ESP принят. Требовался установленный SA в подходящем контексте, затем проверка последовательности и окна против повторов, криптографической защиты и селекторов трафика. Неизвестный SPI, повтор или ошибка целостности прекращали обработку, даже если первая развилка сработала правильно.

Один байт поддерживал NAT, а не разговор

Третий формат состоял ровно из одного байта 0xFF и использовал те же порты. Это NAT keepalive. Его единственная задача — не дать транслятору удалить отображение во время простоя; получателю рекомендовалось игнорировать пакет.

RFC 3948 запрещает считать его получение признаком живого соединения. NAT может обновить таймер, когда у узла уже нет полезного IKE SA, ESP SA удалён, защищённые данные не проходят или приложение остановлено. Память посредника не равна состоянию сквозного взаимодействия.

Исторические значения по умолчанию—двадцать секунд без иной отправки перед требуемым keepalive и настраиваемые пять минут после существования SA—не являются универсальными современными измерениями. Они подчёркивают разделение владельцев: NAT определяет срок отображения, конечный узел запускает keepalive, IKE и ESP управляют своими ассоциациями, приложение имеет собственный критерий доступности.

После выбора обработчика оставалась политика

UDP не заменял ESP. Отправитель выполнял обычную обработку ESP и добавлял UDP; получатель снимал UDP и продолжал обычную декапсуляцию ESP. Затем требовалось учесть последствия изменения адресов.

В туннельном режиме локальная политика могла сверить внутренний адрес источника с разрешённым диапазоном или адресом, назначенным партнёру, либо преобразовать его для локальной сети. В транспортном режиме смена адресов нарушала контрольные суммы TCP или UDP; документ определял ограниченные способы исправления. Четыре нуля не решали, какой внутренний адрес допустим.

Раздел безопасности показывает и конфликт идентичности. Два компьютера за разными NAT могли иметь одинаковый частный адрес, поэтому шлюз видел несколько SA к одному внешне одинаковому внутреннему назначению. Несколько клиентов за одним публичным адресом могли согласовать пересекающиеся описания трафика. Простого фильтра тогда не хватало для выбора исходящего SA. Реализация должна была назначить уникальные локальные адреса, выполнить дополнительное преобразование, отклонить конфликт или разрешить его явно.

RFC 3715 ранее собрала требования совместимости IPsec и NAT. RFC 3948 предложила применимый формат, но не превратила внешний адрес NAT в уникальную личность всех находящихся за ним систем.

Узкая граница сохранилась в IKEv2

Карточка RFC 3948 фиксирует публикацию Standards Track в январе 2005 года. Подтверждённая errata исправляет одну ссылку во введении и не меняет формат пакета.

RFC 7296 сохраняет правило для IKEv2: IKE на UDP 4500 получает префикс из четырёх нулей, а ESP следует сразу после UDP и начинается со SPI, который не может корректно быть нулевым. Инициатор может выбрать 4500 с самого начала даже без обнаруженного NAT. Следовательно, сам порт не доказывает трансляцию.

Исторический результат — не утверждение, будто четыре байта защитили IPsec. Порт координировал доставку к общему входу. Первое слово выбирало возможный разбор. IKE или ESP выносили собственный вердикт. Локальная политика допускала внутренний трафик. Приложение подтверждало итог. Малое правило оказалось долговечным именно потому, что не присвоило полномочия следующих уровней.

Источники