Кратко

  • Редакция 08 draft-nir-ipsecme-big-payload опубликована 10 сентября 2026 года. Официальный diff с редакцией 07 показывает обновление дат и ссылки Classic McEliece, а также одну словесную правку, но не изменение конструкции.
  • Проект превращает резервный бит в признак L: после уведомления LARGE_PAYLOAD_SUPPORTED в IKE_SA_INIT длина отдельного payload может занимать 32 бита вместо 16.
  • Уведомление не содержит максимального размера, области применения, лимита памяти, вычислительной квоты или допустимой параллельности. Текст прямо разрешает реализациям разумные ограничения.
  • В Datatracker документ остаётся активным кандидатом IPSECME со статусом «Call For Adoption By WG Issued», без shepherd и одобрения IESG. Запрошенного значения пока нет в реестре IANA.

У логического признака нет единицы измерения

В RFC 7296 поле Length всего сообщения IKE занимает четыре октета. Поле Payload Length в заголовке каждого отдельного payload — только два. Поэтому внешний контейнер умеет описать большую общую длину, а один вложенный объект не может достигнуть 65 536 октетов.

Проект предлагает обозначить прежний резервный бит буквой L. При нуле структура остаётся старой, при единице длина читается из четырёх октетов. До отправки такого заголовка другая сторона должна объявить LARGE_PAYLOAD_SUPPORTED. Уведомление однозначно выбирает способ разбора.

Но в нём нет количественного обещания. Оно не сообщает, допустимы ли 200 килобайт или несколько мегабайт, не перечисляет обмены и типы payload, не резервирует память для сборки, не ограничивает криптографическую работу и не задаёт число крупных запросов одновременно. Если истолковать «поддерживает» как обязанность принять любое 32-битное значение, контроль над ресурсом окажется у отправителя без явного согласия владельца.

Возможность согласуется отдельно для каждого направления

Уведомление передаётся во время IKE_SA_INIT, хотя большой payload в самом начальном обмене запрещён. Для крупного материала первоначального обмена ключами проект рекомендует IKE Intermediate Exchange из RFC 9242.

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

Получатель сверяет обещанную длину с оставшимися октетами внутри сообщения IKE. При нехватке данных предусмотрен INVALID_SYNTAX. Если данные присутствуют, payload обрабатывается как остальные; отклонять его только потому, что конкретная длина поместилась бы в коротком поле, нельзя.

Это правило защищает единое толкование байтов. После синтаксической проверки всё ещё возможен отдельный отказ по документированной локальной норме ресурсов.

Полный DELETE показывает лишь предел представления

В качестве примера проект разбирает DELETE payload со списком IPsec SPI. Каждое значение SPI занимает четыре октета, а счётчик допускает 65 535 элементов. Короткого поля длины на полный список не хватает. В расширенной форме такой payload занял бы 262 150 октетов.

Число объясняет, зачем нужен новый формат, но не устанавливает универсальный минимум памяти. Авторы отдельно разрешают реализации ограничить число SPI в DELETE разумной величиной. Способность прочитать длинный заголовок и готовность обработать максимальный список остаются разными решениями.

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

Фрагменты и TCP меняют доставку, а не бюджет

RFC 7383 делит зашифрованное сообщение IKE, чтобы оно прошло по тракту, где один большой IP-пакет теряется. RFC 9329 описывает IKEv2 и IPsec поверх TCP для сетей, блокирующих или ухудшающих UDP. Оба механизма помогают доставке, но не выделяют прикладное состояние на удалённом узле.

Фрагменты всё равно нужно принять, собрать, проверить и обработать. Надёжный поток TCP может подать больше работы, чем система согласна выполнять одновременно. Формат длины, способ переноса и допуск по ресурсам — три независимых элемента управления.

Редакционная правка не меняет процессуальный статус

Официальное сравнение редакций 07 и 08 показывает новые даты и срок действия, исправление than на that и обновлённую ссылку Classic McEliece. Поле с числовым лимитом или механизм согласования бюджета не появились. Публикация 10 сентября — обслуживание текста, а не новая архитектура.

Статус следует описывать по нескольким записям. Datatracker связывает проект с IPSECME и показывает «Call For Adoption By WG Issued». В истории указано, что 22 июля были назначены рабочая группа и поток IETF, а также выпущен призыв к принятию. Сообщение в рассылке устанавливало срок комментариев до 15 августа. Автоматический анонс редакции 08 называет документ “work item” IPSECME.

Одновременно текущая страница по-прежнему маркирует его Candidate. Shepherd отсутствует, состояние IESG — «I-D Exists», ответственный Area Director и telechat не указаны. Имя draft-nir согласуется с индивидуальной схемой наименования, но имя файла не является решением рабочей группы. Эти факты нужно приводить вместе, не объявляя принятие или отказ вместо IPSECME.

В теле сказано о намерении Standards Track и об обновлении RFC 7296 в случае одобрения. Метаданные Datatracker сейчас показывают intended status «(None)». Это расхождение описаний, не одобрение. В реестре IANA для IKEv2 Notify Message Status Types также нет LARGE_PAYLOAD_SUPPORTED: запрос номера не равен выделенному номеру. Просмотренные источники не подтверждают консенсус IETF, одобрение IESG, публикацию RFC, реализацию, тесты совместимости, внедрение или инцидент.

Источники