Кратко

  • Version Negotiation несёт криптографически незащищённый список версий, которые отправитель объявляет приемлемыми.
  • Возврат Connection ID даёт лишь ограниченное основание считать, что отправитель видел Initial, но не аутентифицирует названный сервер или его рабочую конфигурацию.
  • Полезная операционная запись связывает сырой пакет со следующим выбором и аутентифицированными сведениями о версиях из рукопожатия.

Панель совместимости показывает три версии QUIC рядом с адресом пограничного узла. Источник — один перехват: клиент предложил версию, получил Version Negotiation и прочитал три альтернативы. Панель превращает их в реестр возможностей сервера. В трассировке такого вывода нет.

RFC 9000 §6.1 предусматривает ответ, когда сервер не принимает выбранную клиентом версию. В пакете перечисляются версии, которые он готов принять; ответ можно сформировать без сохранения состояния. Сервер также вправе ограничивать число ответов. Поэтому молчание не составляет полного списка отсутствующей поддержки.

Формат создаёт узкую связь. По RFC 9000 §17.2.1 поле Version равно нулю, DCID ответа копирует SCID клиента, а SCID ответа — DCID из Initial. Спецификация говорит лишь о некоторой уверенности, что отправитель наблюдал Initial. Далее следует набор 32-битных версий.

Наблюдение Initial не равно аутентификации в качестве сервиса. RFC 9000 §12.1 прямо указывает, что Version Negotiation не имеет криптографической защиты. Узел на пути видит нужные идентификаторы. В пакете нет сертификата TLS, проверки Finished или аутентифицированных транспортных параметров.

Правила клиента снимают простые неоднозначности, но не усиливают доказательство. Согласно RFC 9000 §6.2, клиент, поддерживающий только QUIC v1, обязан прекратить текущую попытку соединения после подходящего пакета Version Negotiation. Есть два исключения: пакет следует отбросить после успешной обработки другого пакета, а также если список содержит первоначально выбранную версию. Это мешает очевидной инъекции или старому ответу, но не превращает список в подписанную политику.

Более сильный слой появляется в рукопожатии. RFC 9368 §3 определяет сведения о версиях с полями Chosen Version и Available Versions, передаваемые аутентифицированным способом. В QUIC v1 используется параметр version_information. RFC 9368 §9 прямо связывает безопасность с подлинностью этих данных, обеспечиваемой аутентифицированными транспортными параметрами v1.

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

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

В операционной записи следует хранить предложенную версию, время и пятёрку параметров сетевого потока, DCID и SCID Initial, сырые байты, возвращённые ID, исходный порядок списка, решение правил отбрасывания, следующую и согласованную версии, version_information, личность узла, подтверждённую TLS-рукопожатием, узел или релиз и итог. Более низкая последующая версия сама по себе не доказывает понижение: нужны аутентифицированная запись рукопожатия, реальные наборы версий и правило выбора.

Пакет полезен именно в своих границах: он отмечает развилку совместимости. Это не сертификат сервера, не манифест развёртывания и не обещание для всей сети.