Summary

  • CID находит контекст DTLS, но не подтверждает новый исходный UDP-адрес.
  • Basic RRC проверяет новый адрес, enhanced RRC сначала опрашивает старый путь.
  • Проверка, привязка, возобновлённые пакеты и результат приложения — разные факты.

Контекст знаком, адрес ещё нет

Защищённая запись приходит с другого адреса. CID приводит к верному контексту, аутентификация проходит. RFC 9853 не позволяет автоматически заменить адрес: он дополняет RFC 9146 и RFC 9147 отдельной проверкой RRC. Причина пока неизвестна: NAT rebinding, добровольная миграция и ускоренная копия подлинного пакета выглядят одинаково.

RRC использует extension 61, ContentType 27 и свежий восьмибайтовый cookie в зашифрованных и аутентифицированных сообщениях. IANA различает path_challenge, path_response и path_drop.

Basic отправляет challenge на новый адрес. Верный response до T разрешает обновить привязку; timeout запрещает. Это свидетельство одного обмена, а не симметричного или устойчивого пути, обратного PMTU либо доставки приложению.

Enhanced учитывает внешнего наблюдателя, который копирует настоящие записи и выигрывает гонку более быстрым маршрутом. Сначала проверяется старый адрес. Если старый путь предпочтителен, path_response сохраняет прежнюю привязку. Если он работает, но больше не предпочтителен, path_drop запускает basic-проверку нового адреса. Timeout делает то же, не обновляя адрес сам. При NAT rebinding инициатор видит новый путь, а ответчик всё ещё старый.

До проверки данные приложения останавливаются либо ограничиваются тройным объёмом принятых данных от непроверенного адреса. После неё отправку можно возобновить, но возможность отправить не доказывает приём. T равен 3×RTT при известном RTT активного пути или одной секунде иначе. Ещё одна смена адреса во время проверки сбрасывает поколение: ответ отбрасывается, привязка не меняется, новые данные начинают новую проверку.

Для непрерывности нужны пять квитанций: контекст и CID; режим, cookie, адреса и timer; сам акт привязки; первый принятый защищённый пакет в каждом направлении; принятый запрос приложения и связанный ответ. Советы RFC регистрировать сбои, множественные ответы и частые probes — рекомендации для SIEM, не данные о реальных атаках.

RFC Editor, Datatracker и errata подтверждают статус документа, не внедрение. Running-Code Primacy, Minimum Initial Specification и Reality Layers требуют не расширять символ «проверено» за пределы исполненного факта.

Sources