Кратко

  • RFC 9868 использует часть транспортной нагрузки IP после UDP Length как surplus area для транспортных опций UDP; это не пользовательские данные UDP.
  • DTLS защищает пользовательские данные, а не транспортные опции. Защищённая нагрузка, OCS или факт отправки не служат доказательством защиты, обработки или последующего эффекта опции.

Опасность нового поля обычно не в его синтаксисе, а в гарантии, которую ему незаметно приписывают. RFC 9868 использует допустимое расхождение между UDP Length и пространством транспорта, указанным IP. До границы находятся пользовательские данные, после неё — область, которую реализация с поддержкой опций может разобрать как опции. Это расширение транспорта, а не утверждение о возможностях удалённой стороны, сохранности по пути или результате приложения.

UDP при этом остаётся протоколом без состояния и без двустороннего диалога. Опции — это каркас, а не законченный протокол. За исключением обязательного набора для реализаций с UDP Options, отправитель не может принудить получателя к обработке. Получатель может проигнорировать необязательную опцию согласно локальной настройке. Запись об отправке фиксирует локальное действие, но не подтверждает поддержку партнёра, прохождение через посредника или ответ.

Граница защиты сформулирована прямо. RFC 9868 отмечает, что TLS и DTLS не защищают транспортный уровень: DTLS работает с пользовательскими данными UDP. Сам механизм опций также не даёт специальной защиты от изменения заголовка UDP, нагрузки или surplus area, если её не дают OCS, AUTH, UENC либо иной слой, например IPsec. Без применимого шифрования опции видимы на пути. Наличие DTLS нельзя превращать в вывод о конфиденциальности, подлинности или неизменности соседней опции.

OCS имеет ограниченное назначение — обнаруживать ошибки в области опций. Это не полномочие, не свидетельство маршрута и не разрешение на действие. Ради совместимости со старым UDP получатель при неуспешной применимой OCS может передать пользовательские данные вверх и проигнорировать остальные опции. Проверяемым фактом остаётся локальная реакция по названной политике, а не широкая формула «опция безопасна».

RFC 9869 показывает разрыв между форматом и наблюдением. DPLPMTUD с UDP Options требует включения у отправителя и получателя и явного подтверждения пробы. Одно определение опции не измеряет путь. RFC 9868 добавляет, что отдельные пути способны удалить surplus area или отбросить дейтаграммы с опциями. Конструкцию опции, выбранную защиту, способность партнёра, коррелированный ответ, свидетельство пути и результат приложения необходимо хранить как разные факты.

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

Sources