Кратко

  • RFC 9853 добавляет в DTLS 1.2 и 1.3 аутентифицированную и зашифрованную проверку обратной достижимости. Связанный с вызовом ответ может обосновать обновление адреса при CID; тайм-аут оставляет старую привязку.
  • Результат уже, чем личность, авторизация или завершённая миграция. Защищаемая квитанция разделяет триггер, модель угроз, бюджет проб, ответ, перенос контекста, прикладное принятие, наблюдение и откат.

Первая запись с адреса B действительна. CID выбирает ассоциацию, созданную при адресе A; эпоха и номер последовательности подходят; аутентифицированное расшифрование успешно. Но можно ли отправить следующий прикладной ответ на B, ещё не решено.

CID освобождает ассоциацию DTLS от постоянной зависимости от UDP-адреса и порта. Это сохраняет сеанс при NAT rebinding, смене интерфейса или движении ограниченного устройства. Та же возможность создаёт перенаправление: копия настоящей записи может прийти раньше по другому маршруту, а подменённый источник — направить крупный ответ жертве.

RFC 9146 уже требовал до замены адреса криптографически проверить запись, убедиться в её новизне по эпохе и последовательности и иметь стратегию доказательства, что новый адрес принимает и обрабатывает DTLS. Конкретная стратегия оставалась открытой.

RFC 9853, опубликованный в марте 2026 года как IETF Standards Track, закрывает пробел для DTLS 1.2 и 1.3, обновляя RFC 9146 и RFC 9147. Return Routability Check, RRC, проверяет кандидатный путь до изменения локальной связи CID с адресом.

Порядок — часть контроля. CID находит состояние, record layer подтверждает принадлежность датаграммы, RRC испытывает путь, затем получатель меняет привязку. Ни один предикат не получает молча смысл следующего.

Возможность согласуют заранее

RRC согласуется пустым расширением rrc с кодом 61. Клиент обязан также предложить connection_id, сервер подтверждает в ServerHello. Без успешного двустороннего обмена применять RRC нельзя.

Даже после согласования приложение может использовать собственную проверку. Echo для CoAP из RFC 9175 умеет требовать свежесть или достижимость по правилам ресурса, метода и политики. Достижимый транспортный путь и допустимая операция — разные условия.

Content type 27 return_routability_check переносит path_challenge, path_response и path_drop. В каждом сообщении — восьмиоктетный cookie с 64 битами энтропии, аутентифицированный и зашифрованный текущим DTLS-контекстом.

Cookie не является личностью, правом на адрес или разрешением. Он связывает ответ с конкретным вызовом. Запись «RRC пройден» теряет соединение, попытку, цель, начало и срок, в которых доказательство действительно.

Сначала ограничить объём

Обнаружив смену адреса, получатель останавливает буферизованные прикладные отправки либо удерживает весь выход на непроверенный адрес в anti-amplification лимите: не более трёх объёмов принятых оттуда данных, без отброшенных записей.

Это бюджет воздействия, а не пропускная способность. Небольшой пакет с подделанным источником не должен разрешать крупный ответ. Малый защищённый вызов не может быть расшифрован жертвой без DTLS-контекста, поэтому связанный ответ не появляется и привязка не меняется.

В базовом варианте инициатор кладёт непредсказуемый cookie в path_challenge, отправляет на новый адрес и запускает T. Партнёр проверяет сообщение и возвращает значение в path_response. Только совпадение позволяет обновить адрес. Истечение T запрещает обновление.

Потери допускают дополнительные вызовы, но в разных транспортных пакетах, с паузами и новым случайным материалом. Без специальных требований ориентир — одна проба за RTT до лимита. Ответчик без задержки посылает ровно один ответ на каждый действительный вызов и на адрес, откуда вызов пришёл. Обратный PMTU этим не измеряется.

Источник T тоже важен. При внешней оценке RTT активного пути рекомендуется 3×RTT, иначе одна секунда; профиль может выбрать другое. Тайм-аут означает отсутствие нужной связи в выбранном окне, а не вечную недоступность партнёра.

Старый путь как встречная проверка

Базовый обмен снижает усиление, но наблюдающий off-path атакующий может ускорить копии настоящих записей. Первая копия выглядит как миграция, и проверка только нового пути способна поставить атакующего на путь.

Усиленный вариант сначала проверяет прежний адрес. path_response по всё ещё предпочитаемому пути сохраняет привязку. path_drop сообщает, что старый путь работает, но не предпочитается; тогда запускается базовая проверка B. Молчание до T также ведёт к проверке нового адреса, а не к автоматическому переносу.

Так разделены молчание, явный отказ от старого пути и подтверждённое предпочтение. Защита не абсолютна. Постоянно более быстрый вредоносный маршрут может быть неотличим от улучшившейся маршрутизации. Недавние пакеты на старом пути и дубликаты полезны для местной эвристики, но не расширяют утверждение cookie.

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

Обратный путь не доказывает личность

Успешный RRC показывает, что сторона с текущим DTLS-контекстом получила защищённый вызов на проверяемом пути и своевременно вернула связанное значение. Он не показывает юридического владельца адреса, человека или устройство, полномочие на перенос, местоположение, долговечность и отсутствие наблюдения.

Приложение решает отдельно. Операции CoAP могут требовать собственной свежести; очередь могла устареть, запрос — потерять идемпотентность, полномочие — измениться. Возобновление байтов означает непрерывность транспорта. Сохранение смысла работы означает непрерывность приложения.

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

Что скрывает зелёный индикатор

RFC советует учитывать неудачи, несколько ответов на один вызов и частые пробы. Они могут означать подмену или поломку обратного пути, гонку вне пути и нестабильность связи.

DTLS 1.3 скрывает тип записи от наблюдателя. В DTLS 1.2 RRC вне tls12_cid показывает тип middlebox, поэтому CID в обоих направлениях уменьшает вмешательство. DTLS 1.3 может запросить новые CID для разных путей. DTLS 1.2 не пополняет их в сеансе и не подходит для multihoming при серьёзном риске корреляции.

On-path противник всё ещё может нарушать связь или перенаправлять проверку настоящему партнёру. Реестр IANA координирует тип 27, расширение 61 и три сообщения, но не сертифицирует реализацию, личность, полномочие или завершение услуги.

Источники и пределы

Основа: RFC 9853 и его статус с errata, RFC 9146, RFC 9147, RFC 9175, RFC 9000, IANA TLS Parameters и RFC 8126. Они задают протокол, но не охват реализаций, настройки поставщиков, производительность, инциденты и правила конкретного оператора.

Отдельный реестр errata для RFC 9853 сохраняет историю исправлений, проверенную на момент завершения исследования.