Кратко

  • RFC 2410 определил NULL как тождественную функцию с нулевой длиной ключа и IV. Отказ от конфиденциальности стал явным согласуемым вариантом ESP, а не двусмысленным отсутствием настройки.
  • Сам NULL не давал защиты: требовался отдельный сильный алгоритм целостности. При этом обычный ESP-пакет не позволял промежуточному устройству детерминированно узнать, зашифрована нагрузка или только аутентифицирована.

В тесте нормального шифра выход должен отличаться от открытого текста. В тесте NULL правильный выход совпадал с входом. Формула RFC 2410 предельно коротка: NULL(b) = I(b) = b.

Юмор о древнеримском происхождении алгоритма не отменял точности требований. Для извлечения ключа IKE длина должна была составлять ноль бит. Длина вектора инициализации тоже равнялась нулю. Алгоритм не хранил состояния, а его блок имел размер один октет.

Эта строгость нужна была, чтобы отличить выбор от пропуска. Отсутствующий параметр мог означать ошибку, значение по умолчанию или частное соглашение. Именованная трансформация позволяла обеим реализациям использовать общий механизм предложений и выбора: ESP применяется, но конфиденциальность не запрашивается.

Место в списке алгоритмов шифрования описывало роль в протоколе, а не свойство результата. RFC 2410 прямо говорил, что NULL не обеспечивает конфиденциальность и сам по себе вообще не предоставляет сервис безопасности.

Защиту могла дать отдельная трансформация аутентификации. ESP_NULL с сильным алгоритмом проверял происхождение и целостность данных, оставляя содержимое видимым. Это не было равнозначно незащищённому IP.

Сравнение с AH имело границы. При одном алгоритме аутентификации отсутствие шифрования не делало ESP_NULL заведомо слабее криптографически. Но ESP_NULL не включал в вычисление заголовок IP так, как AH включал его подходящие части. Формат, область защиты и поведение в сети оставались различными.

RFC 2406 требовал, чтобы SA ESP использовала хотя бы один сильный алгоритм — шифрования или аутентификации. RFC 4303 сохранил инвариант: конфиденциальность и целостность могли быть NULL по отдельности в предусмотренных случаях, но не одновременно.

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

NULL не всегда означает downgrade. Если политика разрешала режим только с целостностью, это корректный выбор. Если политика требовала конфиденциальность, а стороны приняли NULL, та же запись может свидетельствовать об ошибке или недопустимом понижении. Ответ содержится в политике и transcript, а не в названии трансформации.

В реестре IKEv1/IPsec DOI ESP_NULL получил номер 11. Нынешний реестр IKEv2 также перечисляет ENCR_NULL под номером 11 для ESP и указывает, что его нельзя применять для защиты самого IKEv2. Число имеет смысл только внутри своего типа и протокольной таблицы.

Реестр фиксирует словарь, а не эксплуатацию. Он не доказывает, что значение было предложено, выбрано, установлено в ядре и использовано для обработки пакета. Возможность реализации и факт работающего состояния — разные уровни данных.

RFC 9395 перевёл IKEv1 и связанные документы в исторический статус и закрыл старые реестры. Он также объявил устаревшими несколько старых алгоритмов, но ENCR_NULL в этот список не вошёл. Современный ESP продолжил поддерживать режим целостности без конфиденциальности.

RFC 8221 оставил ENCR_NULL обязательным к реализации, чтобы разные системы могли согласовать аутентифицированный ESP без шифрования. Документ указывал и на практическое преимущество ESP перед AH при прохождении NAT. Требование реализации не было требованием использования.

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

Это стало проблемой для корпоративных устройств, которые хотели проверять трафик с одной целостностью. Антивирус или механизм контроля доступа мог разбирать ESP_NULL, но не настоящий шифртекст. Ошибка в одну сторону ломала анализ, в другую — создавала путь обхода.

RFC 5840 определил WESP именно потому, что обычный ESP не давал детерминированного различия. Дополнительная обёртка могла явно показать наличие конфиденциальности и сделать проверку технически возможной. Сам факт стандарта не доказывает его повсеместное внедрение.

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

Документ предполагал управляемый административный домен. Общая политика должна была мешать конечным системам выбирать настоящее шифрование для обхода проверки. За его пределами промежуточный узел не получал права требовать видимость или читать данные только потому, что они оказались читаемыми.

Даже WESP отвечал лишь на вопрос о конфиденциальности. Он не определял, кто имеет право на инспекцию, с какой целью, на какой срок и под чью ответственность. Техническая видимость и организационное полномочие — независимые квитанции.

После классификации следовали новые границы. Входящая и исходящая SA различны. Завершённое согласование не доказывает установку на обеих сторонах. Успешная проверка целостности не доказывает принятие окном anti-replay. Обработка IPsec не доказывает проход внутреннего firewall или результат приложения.

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

В терминах слоёв реальности Lu Heng реестр определяет символ, IKE — соглашение, ядро — работающий объект, пакет — наблюдение, посредник — классификацию, политика — полномочие, приложение — результат. Один слой не может без доказательств присвоить высказывание следующего.

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

RFC 2410 сделал отсутствие шифрования однозначным между сторонами. Последующая история показала: однозначность соглашения не превращает его в публичное свойство каждого пакета.

Источники