Кратко

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

Ошибка начинается в тот момент, когда оператор видит совпавший PATH_RESPONSE и превращает его в постоянный вердикт о личности или доверии. RFC 9000 задаёт более узкий смысл. Проверка пути определяет достижимость узла по сетевому пути. Она используется при миграции соединения и может применяться для проверки нового локального адреса до миграции, но не отвечает на вопрос, кто находится за адресом.

Endpoint отправляет PATH_CHALLENGE по пути, который хочет проверить. Данные должны содержать не менее 64 бит энтропии — непредсказуемое значение длиной восемь байт. Получатель отвечает PATH_RESPONSE, повторяя те же данные. Ответ отправляется по пути, на котором пришёл challenge. При этом инициатор принимает совпавший ответ, пришедший по любому сетевому пути. Это различие существенно: отвечающая сторона демонстрирует возврат значения по пути приёма, а инициатор не фиксирует путь прибытия ответа, поскольку такое требование могло бы облегчить атаку миграции.

Проверка успешна, если полученный PATH_RESPONSE содержит данные ранее отправленного PATH_CHALLENGE. ACK пакета с challenge недостаточен: злоумышленник может подделать подтверждение. Для устойчивости к потерям разрешено отправлять несколько challenge, но не следует помещать несколько вызовов в один пакет. Другие пакеты или кадры на новом пути не заменяют требуемый совпавший ответ.

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

Проверка пути не равна проверке MTU. Успешный challenge в дейтаграмме меньше 1200 байт может подтвердить адрес или путь, но не поддержку требуемой MTU. Для этого нужен отдельный расширенный challenge. Дейтаграммы PATH_RESPONSE обычно расширяются как минимум до 1200 байт, однако не могут превышать лимит защиты от усиления. В журнале надо разделять результат проверки адреса и результат проверки MTU, а также фиксировать размер дейтаграммы и состояние защиты от усиления.

Один пропущенный ответ не означает немедленный отказ. RFC 9000 рекомендует таймер, основанный на трёхкратном большем из PTO текущего и нового пути, и допускает несколько PTO, чтобы одна потеря challenge или ответа не принимала решение. Проверка завершается неудачей только после отказа endpoint от попытки. Отказ от одного пути не обязательно завершает соединение, если другой действительный путь остаётся пригодным. Провал проверки нового пути означает, что этот путь непригоден для данного соединения.

При обнаружении изменения адреса узла, включая NAT-rebinding, путь необходимо проверить заново, если адрес не проверялся ранее. Это не превращает проверку пути QUIC в средство обхода NAT: RFC 9000 не предоставляет нужных механизмов синхронизации. После миграции могут измениться ёмкость и временные характеристики. Поэтому QUIC сбрасывает состояние управления перегрузкой и RTT, а не принимает измерения старого пути за гарантии для нового.

Практический журнал должен включать идентификатор пути в пределах соединения и безопасный для приватности digest challenge, время challenge и ответа, проверенный локальный и удалённый кортеж адресов, размер дейтаграммы, результат совпадения и путь прибытия ответа. Отдельно фиксируются проверка адреса узла и проверка MTU, состояние защиты от усиления до и после, входные данные PTO текущего и кандидатного пути, причина отказа и итог таймера. Причина NAT-rebinding или миграции, прежнее подтверждение адреса и доступные альтернативные пути также требуют собственных полей.

Безопасные digest и ограниченное хранение — это операционные рекомендации, а не требования QUIC.

Нужно сохранить и пять границ с близкими темами. TR-039 рассматривает бюджет усиления до проверки адреса. TR-033 рассматривает свидетельство обратного пути DNS Cookie. TR-043 посвящён целостности Retry. TR-040 отделяет connection ID от личности. TR-061 рассматривает доказательство проверки адреса через NEW_TOKEN в будущих соединениях. PATH_RESPONSE не заменяет ни одну из этих конструкций.