Кратко

  • RFC 2406 определял защиту ESP по полям. Transport mode оставлял исходный IP-заголовок снаружи; tunnel mode шифровал внутреннюю IP-датаграмму, но добавлял видимый внешний заголовок. SPI и Sequence Number также передавались открыто.
  • Конфиденциальность, аутентификация и защита от повторов были разными решениями. Получатель мог не использовать обязательный счётчик, а заполнение лишь ограничивало часть выводов о длине. Защищённая нагрузка не доказывала скрытый поток, выполненную replay-проверку или приём приложением.

У туннеля есть адреса, которые он скрывает, и адреса, без которых он не работает. Внутренние корреспонденты могут уйти в шифротекст, но маршрутизаторам всё равно нужны внешние концы. Наблюдатель теряет одну связь и приобретает другую.

RFC 2406 закрепил эту архитектуру в ноябре 1998 года. Encapsulating Security Payload предлагал набор услуг: конфиденциальность, аутентификацию источника, целостность без соединения, защиту от повторов и ограниченную конфиденциальность потока. Конкретный набор зависел от Security Association и места реализации в сети.

RFC 1827 1995 года был каркасом. SPI оставался единственным обязательным полем, не зависящим от transform, а дополнительные документы определяли алгоритмы и поля. RFC 2406 объяснил, что рост числа комбинаций потребовал более полного базового формата. В него вошли Sequence Number, Padding, Pad Length, Next Header, необязательные Authentication Data и порядок обработки.

Общий формат не слил услуги. Можно было выбрать конфиденциальность без ESP-аутентификации. Можно было использовать NULL-шифрование и получить только аутентификацию. Хотя бы одна из двух функций была обязательна. Защита от повторов допускалась лишь при аутентификации и включалась получателем.

На линии сначала шёл внешний IPv4- или IPv6-заголовок с номером протокола 50. ESP начинался 32-битным SPI и 32-битным Sequence Number. За ними располагались Payload Data, Padding, Pad Length, Next Header и, если услуга выбрана, Authentication Data.

При отдельных алгоритмах шифрование охватывало Payload Data, Padding, его длину и Next Header. Внешний IP-заголовок, SPI, номер последовательности и итоговый ICV оставались вне шифрования. Явный IV мог находиться в начале Payload Data; RFC отмечал, что его часто называют частью ciphertext, хотя сам он обычно не шифруется.

Целостность имела другую границу. ICV включал SPI, Sequence Number, Payload Data, Padding, Pad Length и Next Header, исключая поле Authentication Data, где находился результат. Сначала выполнялось шифрование, поэтому нагрузка входила в расчёт в зашифрованном виде. Внешний IP-заголовок по-прежнему не был частью ESP ICV.

В transport mode ESP стоял после исходного IP-заголовка и до верхнего протокола. Исходные адреса оставались видимыми. В IPv6 расширения до ESP также были снаружи защиты, а Destination Options после ESP могли войти внутрь. Порядок заголовков определял свойство безопасности.

В tunnel mode исходная IP-датаграмма целиком становилась защищённой нагрузкой. Но новый внешний заголовок доставлял её между концами туннеля. Наблюдатель мог не видеть конечные адреса и продолжать видеть шлюзы, размеры, интервалы и объём. Туннель скрывал внутреннюю связь с помощью внешней.

Поэтому RFC 2406 называл конфиденциальность потока ограниченной. Она требовала tunnel mode и была эффективнее на шлюзе, где агрегировались многие потоки. Дополнительное заполнение могло затруднить оценку длины нагрузки ценой полосы. Оно не скрывало само по себе время, число пакетов и внешние адреса.

Номер последовательности особенно ясно отделял поле от действия. Отправитель всегда должен был вставлять и увеличивать его. Получатель мог отключить anti-replay для конкретной SA. Возрастающий счётчик в трассе доказывал передачу значения, но не решение sliding window.

При включённой защите от повторов требовалась аутентификация, иначе счётчик можно изменить. Получатель мог предварительно отсеять старый номер, но не сдвигал окно до успешного ICV. Полное свидетельство соединяло правильную SA, аутентифицированный номер и локальный вердикт окна. Сетевая копия содержала не всю цепочку.

Порядок обработки оставлял выбор политики отдельно. До ESP механизм RFC 2401 должен был определить SA, требующую такую обработку. Затем шли инкапсуляция, заполнение, шифрование и необязательная аутентификация. Фрагментация происходила после ESP. На приёме сначала выполнялась сборка; фрагмент, всё ещё предложенный ESP, подлежал отбрасыванию.

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

Без аутентификации неправильная SA или испорченный шифротекст могли дать ошибочный результат, который IPsec не обязательно распознавал; выявление переходило к следующему протоколу. Параллельная расшифровка ничего не меняла: открытый текст нельзя было выпускать до завершения проверки.

«Аудируемое событие» тоже не означало сохранённый журнал. Система с аудитом должна была включать ESP и позволять управление, но аудит требовался не от каждой системы, а его детализация оставалась локальной. Отсутствие SA, неожиданный фрагмент, переполнение счётчика и ошибка ICV могли стать записями. Их сохранность была отдельным операционным фактом.

RFC 4303 сменил RFC 2406 в 2005 году. Он сохранил различие открытых полей, шифрования, целостности, двух режимов и решения получателя о replay, добавив расширенные номера, комбинированные алгоритмы и явное TFC-заполнение. Документ 1998 года — этап истории дизайна, а не современный выбор криптографии.

Подход Lu Heng требует смотреть на выполненный механизм, а не на символическую метку. «ESP включён» не отвечает, какой режим и услуги выбраны, работало ли окно получателя, что видел внешний наблюдатель и что приняло приложение. Спецификация разделяла эти факты; краткий зелёный статус снова склеивает их.

Источники