RFC 9063 Host Identity Protocol Architecture

image_print
Internet Engineering Task Force (IETF)                 R. Moskowitz, Ed.
Request for Comments: 9063                                HTT Consulting
Obsoletes: 4423                                                  M. Komu
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                July 2021

Host Identity Protocol Architecture

Архитектура протокола отождествления хостов

PDF

Аннотация

В этом документе описано пространство имён отождествления хостов (Host Identity), которое обеспечивает криптографическое пространство имён для приложений, протокол отождествления хоста (Host Identity Protocol или HIP), размещаемый между сетевым1 и транспортным уровнем, который поддерживает мобильность конечных хостов, многодомность и работу через NAT. В документе рассмотрены основы используемых в настоящее время пространств имён с их преимуществами и недостатками, а также их дополнение пространством HI. Определены роли пространства имён отождествления хостов в протоколах.

Этот документ отменяет RFC 4423 и решает проблемы, отмеченные IESG, в частности, вопрос гибкости шифрования. В разделе 11. Вопросы безопасности рассмотрены меры предотвращения лавинных атак (flooding), применение идентификаторов в списках контроля доступа, слабые типы идентификаторов и доверие при первом применении. Документ включает в себя уроки, извлечённые из реализации RFC 7401, и идёт дальше в разъяснении работы HIP как защищённого сигнального канала.

Статус документа

Документ относится к категории информационных и не задаёт стандартов Internet.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9063.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в варианте HTML.

1. Введение

В Internet имеется два важных пространства имён – адреса IP и доменные имена DNS. Эти пространства включают набор функций и абстракций, обеспечивающих современное состояние Internet. Пространства также имеют ряд слабостей. По сути, эти пространства являются основой сети и мы пытаемся все делать в них. Семантическая перегрузка и функциональные расширения существенно усложнили эти пространства имён.

Предлагаемое пространство имён отождествления хостов также является глобальными занимает место между пространствами IP и DNS. Концептуально это пространство имён. относится к вычислительной платформе и такая платформа может иметь несколько идентификаторов (поскольку платформа может по разному идентифицировать себя разным партнёрам). Пространство имён. отождествления хостов состоит из идентификаторов хостов (Host Identifier или HI). Для каждого отождествления применяется в точности один идентификатор HI (хотя могут возникать переходные периоды, например, в момент замены ключей, когда могут быть активны несколько идентификаторов). Хотя далее в тексте обсуждаются некриптографические идентификаторы, архитектура фокусируется на криптографических идентификаторах хостов (HI). В частности, HI является открытым ключом асимметричной пары. Каждое отождествление хоста однозначно указывает один хост, т. е. два хоста не могут иметь совпадающие Host Identity. Если идентификаторы HI совпадают у двух или более вычислительных платформ, эти платформы являются экземплярами распределенного хоста. Идентификатор HI может быть публичным (например, доступным через DNS) или непубликуемым. В клиентских системах будут применяться оба типа HI.

Имеется незначительное но важное различие между отождествлением (Host Identity) и идентификатором (HI). Отождествление указывает абстрактную сущность, которая идентифицируется, а идентификатор – конкретную последовательность битов, используемую в процессе идентификации.

Хотя HI могут применяться во многих системах проверки подлинности (аутентификации), таких как IKEv2 [RFC7296], представленная архитектура задаёт новый протокол, названный протоколом отождествления хоста (Host Identity Protocol или HIP), и криптографический обмен, названный базовым обменом HIP (см. 6. Плоскость управления. HIP обеспечивает ограниченные варианты доверия между системами, повышает уровни мобильности, многодомности и динамической смены адресов IP, помогая в трансляции и изменении протоколов, а также снижая возможности организации некоторых DoS4-атак.

При использовании HIP фактический трафик данных между двумя хостами HIP обычно (но не обязательно) защищается с помощью ESP5 [RFC7402]. Отождествления хостов применяются для создания защищённых связей ESP (Security Association или SA) и аутентификации хостов. При использовании ESP фактические данные пакетов IP не отличаются от передаваемых в обычных пакетах IP с защитой ESP.

С момента публикации [RFC4423] было получено много информации о HIP [RFC6538]. Этот документ расширяет отождествление хоста за пределы первоначального применения для обеспечения связности IP и защиты, с целью предоставления общей защищённой сигнализации между хостами на уровне любого протокола. Сигналы могут организовать защищённую связь между хостами или просто передавать информацию внутри канала.

2. Терминология

2.1. Общие с другими документами термины

Таблица 1.

Термин

Определение

Public key
Открытый ключ

Открытый ключ асимметричной криптографической пары ключей. Применяется в качестве доступного идентификатора для криптографической проверки подлинности. Открытость в данном случае трактуется в диапазоне от «известно партнёру» до «известно всем».

Private key
Секретный ключ

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

Public key pair
Пара с открытым ключом

Асимметричная пара криптографических ключей, содержащая открытый и секретный ключ. Например, это может быть пара ключей Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA).

Endpoint
Конечная точка

Взаимодействующая сущность (элемент). В силу исторических причин в этом документе в качестве (близкого) синонима используется термин «вычислительная платформа».

2.2. Термины, относящиеся к документам HIP

Следует отметить, что многие термины в этом документе являются тавтологическими, самоопределяющими или содержащими циклические ссылки на другие термины. Это связано с лаконичностью определений. Более подробные объяснения приведены в тексте документа и базовой спецификации [RFC7401].

Таблица 2.

Термин

Определение

Computing platform
Вычислительная платформа

Элемент, способный к взаимодействию и расчётам, например, компьютер. См. определение Endpoint выше.

HIP base exchange
Базовый обмен HIP

Криптографический протокол (см. также раздел 6).

HIP packet
Пакет HIP

Пакет IP, содержащий сообщение HIP.

Host Identity
Отождествление хоста

Абстрактная концепция, связанная с вычислительной платформе. См. Host Identifier ниже.

Host Identifier
Идентификатор хоста

Открытый ключ, служащий именем для отождествления хоста (Host Identity).

Host Identity namespace
Пространство имён отождествления хостов

Пространство имён, содержащее все возможные HI.

Host Identity Protocol
Протокол отождествления хоста

Протокол, используемый для передачи и аутентификации HI и другой информации.

Host Identity Hash
Хэш отождествления хоста

Криптографический хэш, применяемый для создания HIT из HI.

Host Identity Tag
Тег отождествления хоста

128-битовый блок данных, создаваемый применением криптографического хэширования к HI, с битами идентификации метода хэширования.

Local Scope Identifier
Локальный идентификатор

32-битовый блок данных, обозначающий отождествление хоста.

Public Host Identifier and Identity
Публичный идентификатор и отождествление хоста

Опубликованный или общедоступный идентификатор HI, служащий публичным именем для отождествления хоста, и соответствующее отождествление.

Unpublished Host Identifier and Identity
Неопубликованный идентификатор и отождествление хоста

Идентификатор HI, не размещаемый в общедоступном репозитории, и соответствующее отождествление хоста. Неопубликованные отождествления хостов обычно будут иметь короткий срок действия с частой заменой и возможно однократным применением.

Rendezvous Mechanism
Механизм встречи (рандеву)

Механизм, используемый для нахождения мобильных хостов по их HIT.

3. Основы

Тремя основными компонентами Internet являются вычислительные платформы (конечные системы), инфраструктура транспортировки пакетов (межсетевое взаимодействие) и службы (приложения). Internet служит для предоставления услуг людям и роботизированным системам («кремниевым людям», если угодно). Все упомянутые компоненты нужно именовать для обеспечения между ними расширяемого взаимодействия. В этом документе рассматривается именование вычислительных платформ и элементов доставки пакетов.

Для этих элементов (платформ) в Internet применяется два основных пространства имён – IP-адреса и доменные имена. Система доменных имён обеспечивает иерархическое выделение имён для некоторых вычислительных платформ и служб. Каждый уровень иерархии получает полномочия от вышележащего уровня и в доменных именах нет анонимности. Примерами доменных имён являются адреса Email, HTTP, SIP.

Пространство адресов IP перегружено их применением для интерфейсов (L3) и конечных точек (связанная с конечной точкой часть L3 и уровень L4). В части именования интерфейсов адреса IP иногда называют «локаторами» (locator) и они служат конечными точками в топологии маршрутизации.

IP-адреса являются числами, назначаемыми сетевым интерфейсам, и обычно применяются лишь при подключении интерфейса к сети. Изначально адреса IP служили для долгосрочной идентификации. Сегодня огромное число интерфейсов используют временные и/или неуникальные адреса IP, т. е. интерфейс получает адрес IP при подключении к сети.

В современной сети Internet транспортные уровни неразрывно связаны с адресами IP и не могут развиваться отдельно. На разработку IPng существенно повлиял отказ от создания соответствующего транспорта TCPng.

Используемым пространствам имён присущи три крупных недостатка. Во-первых, организация начального контакта и поддержка потока данных между двумя хостами могут осложняться при использовании временных и частных адресов. Во-вторых, не обеспечивается согласованной и доверенной защиты конфиденциальности. В-третьих, не обеспечивается проверка подлинности систем и дейтаграмм. Все эти недостатки обусловлены используемым сегодня именованием вычислительных платформ.

3.1. Пространство имён для вычислительных платформ

Независимое пространство имён для вычислительных платформ может применяться для сквозных (end-to-end) операций независимо от развития сетевого уровня и между разными сетевыми уровнями. Это позволит быстро менять адреса на сетевом уровне при перемещении, переносе или переадресации.

Если пространство имён вычислительных платформ организовать на основе криптографии с открытым ключом, его можно будет применять также для услуг аутентификации. При локальном создании пространств имён без регистрации они могут обеспечивать анонимность.

Ниже приведены характеристики пространства имён (для вычислительных платформ) и имён в них.

  • Пространство имён следует применять на уровне «ядра» или стека IP. Стек IP размещается между приложениями и инфраструктурой доставки пакетов.

  • Пространству следует полностью отделять (меж)сетевой уровень от вышележащих уровней. Именам следует заменять собой все вхождения адресов IP внутри приложений (как в блоке управления транспортом Transport Control Block или TCB). Замена может быть выполнена незаметно для унаследованных приложений с помощью локальных идентификаторов (Local Scope Identifier или LSI) и HIT, совместимых с адресами IPv4 и IPv6 [RFC5338]. Однако понимающие HIP приложения потребуется несколько изменить, например, в расширениях API для HIP [RFC6317].

  • Для введения пространства имён не следует требовать какой-либо административной инфраструктуры. Развёртывание должно выполняться снизу вверх попарно.

  • Для имён следует использовать представление фиксированного размера для простоты включения в заголовки дейтаграмм и имеющиеся программные интерфейсы (например, TCB).

  • Пространству имён следует быть доступным при использовании в протоколах. Это связано в основном с размером пакетов, а также вычислениями.

  • По возможности следует избегать конфликтов имён. Можно использовать математический «парадокс дней рождения» для оценки вероятности конфликта в данной популяции и хэш-пространстве. В общем случае для случайного хэш-пространства размером n битов конфликт предполагается после примерно 1,2*sqrt(2n) хэш-значений. Для 64 это составит около 4 миллиардов. Размер 64 бита может оказаться слишком малым для крупных популяций, например вероятность конфликта составит 1% для популяции 640M. Для 100 битов (или более) возникновение конфликта ожидается после расчёта 250 (1 квадриллион) значений. При используемом в настоящее время размере 96 битов [RFC7343] можно рассчитать без конфликтов 248 (281 триллион) значений.

  • Именам следует иметь локализованную абстракцию, чтобы их можно было применять в имеющихся протоколах и API.

  • Должна обеспечиваться возможность локального создания имён. Когда имена не публикуются, это может обеспечивать анонимность за счёт сложности предсказания.

  • Пространству имён следует поддерживать услуги проверки подлинности.

  • Именам следует быть долгоживущими, но с возможностью замены в любой момент. Это влияет на списки управления доступом – короткий срок действия повышает трудоёмкость поддержки списков или потребует в пространстве имён инфраструктуры для централизованного управления списками доступа.

В этом документе пространство имён, соответствующее приведённым выше характеристикам, называется пространством отождествления хостов – Host Identity. Использование идентификаторов HI требует своего протокольного уровня (Host Identity Protocol) между (меж)сетевым и транспортным уровнем. Имена создаются на основе криптографии с открытым ключом для предоставления услуг аутентификации. При корректной реализации можно обеспечить соответствие всем требованиям, приведённым выше.

4. Пространство имён отождествления хостов

Имя в пространстве Host Identity – идентификатор хоста (HI) представляет статистически уникальное значение для указания любой системы со стеком IP. Это отождествление обычно связано со стеком IP, но не ограничивается такой связью. Система может иметь множество идентификаторов, некоторые могут быть общеизвестными (well known), а другие – анонимными. Система может самостоятельно отождествлять себя или использовать сторонний аутентификатор, например DNSSEC [RFC4033], Pretty Good Privacy (PGP) или X.509 для «нотариального заверения» своего отождествления в другом пространстве имён.

Теоретически, любое имя, статистически уникальное в глобальном масштабе, может служить в качестве HI. В архитектуре HIP в качестве такого имени выбран открытый ключ пары асимметричных ключей, поскольку им можно управлять самостоятельно и такой ключ сложно подделать. Как указано в спецификации протокола HIP [RFC7401], HI на основе открытых ключей позволяет аутентифицировать пакеты HIP и защитить их от MitM6-атак. Поскольку аутентифицированные дейтаграммы обязательны для обеспечения основной защиты HIP от DoS-атак, обмен Diffie-Hellman в базовом обмене HIP использует аутентификацию. Таким образом, на практике поддерживаются лишь HI на базе открытых ключей и аутентифицированные сообщения HIP.

В этом документе упоминаются некриптографические формы HI и HIP, но следует предпочитать криптографические варианты, поскольку они более защищены. В прошлом исследовались варианты применения некриптографических HI для радио-меток (Radio Frequency IDentification или RFID) в обмене HIP, адаптированном для работы с такими задачами ([urien-rfid], [urien-rfid-draft]).

4.1. Идентификаторы хостов

Отождествление хостов добавляет в протоколы Internet два основных свойства. Первое заключается в развязывании (меж)сетевого и транспортного уровня (5. Новая архитектура стека), которое обеспечивает этим уровням возможность независимого развития, а также может обеспечить сквозные услуги через множество областей межсетевого взаимодействия. Вторым свойством является аутентификация хостов. Поскольку HI является открытым ключом, он может применяться для проверки подлинности в таких протоколах защиты как ESP.

Отождествление в HIP основано на парах из секретного и открытого ключа и представляется открытым ключом. Таким образом, имя, представляющее отождествление хоста в пространстве Host Identity, т. е. HI, является открытым ключом. В некотором смысле отождествление определяется владением секретным ключом. Если секретным ключом владеет несколько узлов, отождествление может считаться распределенным.

Архитектурно в качестве HI можно использовать любое другое соглашение от именовании в Internet, однако некриптографичекие имена следует применять лишь в средах с высоким уровнем доверия и/или малыми рисками. Это могут быть места, где не требуется аутентификация (нет риска подмены хоста) или не нужна защита ESP. Однако для соединённых между собой сетей, охватывающих несколько операционных доменов и сред, где существует риск подмены хостов, использование некриптографических HI вносит существенный риск. Поэтому в текущих документах HIP не задано использование HI, не основанных на открытых ключах. Например, служба Back to My Mac [RFC6281] от Apple очень близка по функциональности к HIP, но основана на некриптографических идентификаторах.

Реальные HI не применяются напрямую на транспортном или сетевом уровне. Соответствующие HI (открытые ключи) могут храниться в DNS или иных каталогах, как указано в этом документе, и могут передаваться в базовом обмене HIP. Другие протоколы применяют тег отождествления хоста (Host Identity Tag или HIT) для представления Host Identity. Другое представления отождествлений хостов – локальный идентификатор (Local Scope Identifier или LSI) также можно применять в протоколах и API.

4.2. Хэш отождествления хоста (HIH)

Хэш отождествления хоста (Host Identity Hash или HIH) – это криптографических алгоритм, служащий для создания HIT из HI, а также применяемый в HIP для простоты и единообразия. Два хоста в обмене HIP могут применять разные алгоритмы.

Требуется несколько HIH внутри HIP для решения вопросов создания перемещающихся целей и разрешения возможных конфликтов хэш-значений. Это существенно усложняет протокол HIP и ослабляет возможность атак на понижение в HIP [RFC7401].

4.3. Тег отождествления хоста (HIT)

Тег отождествления хоста (Host Identity Tag или HIT) – это 128-битовое представление Host Identity. Благодаря размеру, тег подходит для использования в имеющихся API сокетов вместо адреса IPv6 (например, sin6_addr в структуре sockaddr_in6) без внесения изменений в приложения. Тег создаётся из HIH, префикса IPv6 [RFC7343] и идентификатора хэш-функции. Имеется два преимущества использования в протоколах HIT вместо HI. Первым является фиксированный размер, что упрощает кодирование протоколов и более эффективное управление размером пакетов. Во-вторых, тег представляет отождествление протоколу в согласованном формате независимо от используемых криптоалгоритмов.

По сути, HIT представляет собой хэш открытого ключа, поэтому не его создание влияют два алгоритма, используемые для открытого ключа HI и HIH. Эти алгоритмы кодируются в битовом представлении HIT. Поскольку две взаимодействующих стороны могут поддерживать разные алгоритмы, в [RFC7401] определён минимальный набор для надёжного взаимодействия. Для расширения возможностей взаимодействия отвечающая сторона (Responder) может сохранять свои ключи в записях DNS и инициатор может связать HIT адресата с соответствующими HIT источника по совпадению HIH.

В пакетах HIP идентификаторы HIT указывают отправителя и получателя пакетов, поэтому значениям HIT следуют быть уникальными во всем пространстве IP, где они применяются. В очень редких случаях, когда одно значение HIT сопоставляется с несколькими Host Identity, идентификаторы HI (открытые ключи) будут обеспечивать различие. Если для данного узла имеется несколько открытых ключей, HIT служит подсказкой для выбора нужного ключа.

Хотя случайные конфликты, когда одно значение HIT сопоставляется с несколькими Host Identity, могут возникать редко, атакующий может с помощью перебора или использования слабости алгоритма, найти второй хэш Host Identity с тем же HIT. Этот тип атак называют атаками на прообраз (preimage attack) и устойчивость к нахождению второго идентификатора HI (открытого ключа), который хэшируется в то же значение HIT называется устойчивостью ко второму прообразу. Такая устойчивость в HIP основана на силе алгоритма хэширования и выходном размере хэш-функции. Для HIPv2 [RFC7401] устойчивость составляет 96 битов (меньше 128-битового размера адреса IPv6 по причине наличия префикса ORCHID7 [RFC7343]). Такая устойчивость сочтена достаточной на момент разработки HIP, но её может не хватить для модели угроз предполагаемого развёртывания. Одним из возможных решений может быть расширение использования HIT в развёртывании за счёт идентификаторов HI (и механизмов защищённой привязки HI к HIT) так, что HI становится окончательным основанием. Можно также усложнить атаки с перебором за счёт увеличения сложности расчёта HI, например, с помощью защищенного обнаружения криптографически созданных адресов соседей (Secure Neighbor Discovery Cryptographically Generated Addres) [RFC3972], хотя спецификации HIP до HIPv2 не предоставляют такого механизма. Если при развёртывании не применяются идентификаторы ORCHID (например, в некоторых типах наложенных сетей), можно использовать полный размер 128 битовых адресов IPv6 для HIT.

4.4. Идентификатор с локальной областью действия (LSI)

LSI – это 32-битовое локализованное представление Host Identity, которое, благодаря его размеру, можно применять в имеющихся API сокетов вместо адресов IPv4 (например, sin_addr в структуре sockaddr_in), не изменяя приложений. Назначение LSI состоит в облегчении использования HI в имеющихся API для приложений IPv4. Значения LSI не передаются в линию и при передаче приложением данных с использованием пары LSI уровень HIP (или обработчик сокетов) транслирует LSI в соответствующие HIT (и обратно в случае приёма данных). Кроме упрощения связности на основе HIP для традиционных приложений IPv4, идентификаторы LSI полезны в 2 других сценариях [RFC6538].

В первом случае два приложения, поддерживающих лишь IPv4, размещены на двух разных хостах, соединённых через сеть с поддержкой только IPv6. Связность на основе HIP позволяет этим приложениям взаимодействовать, несмотря на различие семейств протоколов приложений и базовой сети. Это обусловлено тем, что уровень HIP транслирует LSI от вышележащих уровней в маршрутизируемые локаторы (адреса) IPv6 перед отправкой пакетов в линию.

Второй случай похож на описанный, но одно из приложений поддерживает лишь IPv6. Здесь имеется два препятствия взаимодействию приложений – разные семейства адресов, используемые двумя приложениями, и невозможность приложения IPv4 обмениваться данными с сетью IPv6. Связность на основе HIP решает эту проблему, транслируя локатор (адрес) входящего пакета в LSI или HIT.

Фактически LSI расширяет возможности взаимодействия IPv6 на сетевом уровне, как описано для первого случая, и на прикладном, как описано для второго. Механизм расширения возможностей взаимодействия не следует применять для отказа от перехода на IPv6, авторы твердо верят в принятие IPv6 и призывают разработчиков переводить имеющиеся приложения с поддержкой лишь IPv4 на использование IPv6. Однако некоторые фирменные приложения с закрытым кодом, поддерживающие лишь IPv4, могут не увидеть света IPv6 и здесь механизм LSI поможет продлить их жизнь даже в сетях, поддерживающих лишь IPv6.

Основным недостатком LSI является локальная значимость идентификаторов. Приложения могут нарушать принципы уровней и передавать между собой LSI в протоколах прикладного уровня. Поскольку LSI действительны лишь в контексте локального хоста, они могут представлять совершенно иной хост при передаче идентификатора другому хосту. Однако следует подчеркнуть, что контекст LSI фактически представляет собой NAT на хосте и не создаёт проблем больше, чем NAT в промежуточных устройствам для IPv4. Иными словами, приложениям, нарушающим принципы уровней, уже препятствуют устройства NAT, развёрнутые повсеместно.

4.5. Сохранение HI в каталогах

Общедоступные HI следует сохранять в DNS, а неопубликованные не следует сохранять нигде, кроме самих взаимодействующих хостов. Для хранения (общедоступных) HI вместе с поддерживаемыми HIH имеется новый тип записи о ресурсах (Resource Record или RR), определённый в расширении HIP DNS [RFC8005].

В дополнение к сохранению HI в DNS их можно хранить в других каталогах, например, LDAP (Lightweight Directory Access Protocol) или PKI (Public Key Infrastructure) [RFC8002]. Кроме того, были успешно использованы [RFC6538] распределенные таблицы хэшей (Distributed Hash Table или DHT) [RFC6537]. Такая практика позволяет применять идентификаторы не только для распознавания хостов.

Некоторые типы приложений могут кэшировать и использовать HI напрямую, а другие опосредованно находить идентификаторы по символьным именам хостов, таким как полные доменные имена (Fully Qualified Domain Name или FQDN), путём просмотра каталогов. Хотя HI могут действовать существенно дольше связанных с ними маршрутизируемых адресов IP, каталоги могут оказаться лучшим подходом для управления сроком действия HI. Например, каталог на основе LDAP или DHT можно применять для опубликованных локально идентификаторов, а DNS лучше подходит для общедоступных.

5. Новая архитектура стека

Одним из способов охарактеризовать Host Identity является сравнение предложенной архитектуры на основе HI с используемой в настоящее время. Как отмечено в отчёте IRTF Name Space Research Group Report [nsrg-report] и, например, документе «Endpoints and Endpoint Names» [chiappa-endpoints], адреса IP в настоящее время играют двойную роль – «локаторов» и идентификаторов конечных точек, т. е. каждый адрес IP указывает топологическое местоположение в Internet, действуя как вектор направления маршрутизации или «локатор», и в то же время именует физический сетевой интерфейс, размещённый в данный момент в точке подключения, выступая как имя конечной точки.

В архитектуре HIP имена конечных точек и «локаторы» отделены одно от другого. Идентификаторы HI указывают конечные точки. Важно понимать, что имена конечных точек, основанные на HI несколько отличаются от имён интерфейсов и доступ к Host Identity может одновременно обеспечиваться через несколько интерфейсов. Различия в привязках логических объектов показаны на рисунке 1, где слева показана текущая архитектура TCP/IP, а справа – архитектура на основе HIP

Транспортная --- Сокет                 Транспортная --- Сокет
ассоциация       |                     ассоциация       |
                 |                                      |
                 |                                      |
                 |                                      |
Конечная         |                     Конечная --- Host Identity
точка    \       |                     точка            |
           \     |                                      |
             \   |                                      |
               \ |                                      |
Место    --- IP-адрес                  Место    --- IP-адрес

Рисунок 1.


Архитектурно HIP обеспечивает разную привязку протоколов транспортного уровня, т. е. ассоциации транспортного уровня (например, соединения TCP и ассоциации UDP) связаны не с адресами IP. А с идентификаторами HI. На практике отождествление хостов раскрывается через LSI и HIT для унаследованных приложений и транспортного уровня, чтобы повысить уровень совместимости с имеющимися сетевыми API и стеками протоколов.

Уровень HIP логически размещён как L3,5 между транспортным и сетевым уровнем сетевого стека и действует как «прокладка», использующая LSI или HIT, но не затрагивающая другие данные. Уровень HIP выполняет преобразование двух форм идентификаторов HIP, приходящих от транспортного уровня, в маршрутизируемые адреса IPv4 или IPv6 для сетевого уровня и обратно.

5.1. Множественное отождествление

Хост может иметь множество отождествлений как на клиентской, так и на серверной стороне. Это вызывает некоторые дополнительные проблемы, рассматриваемые в этом параграфе.

Из соображений безопасности идея дублирования Host Identity на нескольких хостах может быть неудачной, поскольку компрометация одного хоста портит отождествление других. Управления машинами с одинаковыми Host Identity тоже может вызывать сложности, поэтому каждому хосту рекомендуется применять уникальное отождествление.

На стороне сервера для распределения нагрузки лучше применять DNS, нежели общее отождествление Host Identity. Можно настроить одну запись FQDN указывающую разные Host Identity. Каждую запись FQDN можно связать с соответствующими «локаторами» или общим «локатором», если серверы используют общий сервер HIP rendezvous (6.3. Механизм встречи) или ретранслятор HIP (6.4. Механизм ретрансляции).

Вместо дублирования отождествлений в HIP реализован специальный (opportunistic) режим, в котором инициатор (Initiator) не учитывает идентификатор отвечающего (Responder) при инициировании обмена ключами и узнает его по завершении обмена. Этот компромисс имеет слабые гарантии защиты, но позволяет избежать публикации HI [komu-leap]. Поскольку многие общедоступные серверы уже используют DNS в качестве каталога, такой подход может оказаться более подходящим, например, для соединений «точка-точка». Следует также отметить, что этот режим нужен на практике при использовании в качестве «локаторов» anycast-адресов IP. Этот режим может применяться вместе с серверами HIP rendezvous или ретрансляторами HIP [komu-diss]. В таких случаях инициатор передаёт сообщение I1 с шаблонным HIT адресата «локатору» сервера HIP rendezvous или ретранслятора. Когда такой сервер обслуживает множество зарегистрированных Responder, он может выбирать HIT адресата, выступая балансировщиком на основе HIP. Однако этот подход остаётся экспериментальным и требует дополнительных исследований.

На стороне клиента хост может иметь несколько Host Identity, например, из соображений приватности или при работе пользователя хоста с разными административными доменами в качестве дополнительной меры защиты. Если на пути между клиентом и сервером имеется понимающее HIP промежуточное устройство, например, межсетевой экран (МСЭ) на основе HIP, пользователю или базовой системе следует аккуратно выбирать нужное отождествление, чтобы предотвратить ненужные препятствия со стороны МСЭ на основе HIP [komu-diss].

Сервер также может иметь несколько Host Identity, например, web-сервер может обслуживать несколько административных доменов. Обычно различия реализуются на основе имени DNS, но для этого может служить и Host Identity. Однако более веской причиной использования нескольких отождествлений являются понимающие HIP МСЭ, которые не способны видеть трафик HTTP внутри шифрованных туннелей IPsec. В этом случае для каждой службы можно настроить своё отождествление, позволяя МСЭ разделять службы одного web-сервера [lindqvist-enterprise].

6. Плоскость управления

HIP разделяет плоскости данных и управления. Два конечных хоста инициализируют плоскость управления с помощью обмена ключами, называемого базовым обменом. В этой процедуре могут помогать инфраструктурные посредники HIP, называемые серверами встреч (rendezvous) или ретрансляторами. При смене адреса IP конечные точки сохраняют связь с плоскостью управления с помощью расширений для мобильности и множественной адресации (multihoming). По завершении работы конечные хосты удаляют плоскость управления и связанные с ней состояния.

6.1. Базовый обмен

Базовым обменом называется процедура обмена ключами, где Initiator и Responder проверяют подлинность друг друга, используя свои открытые ключи. Обычно инициатором является клиентский хост, а отвечающим (Responder) – сервер. Роли используются конечным автоматом реализации HIP и отбрасываются по завершении.

Обмен включает 4 сообщения и создание симметричных ключей для защиты плоскости управления с помощью хэшированных кодов аутентификации сообщений (Hash-based Message Authentication Code или HMAC). Эти ключи могут также служить для защиты плоскости данных, где обычно применяется IPsec ESP [RFC7402], хотя HIP поддерживает и другие протоколы. Плоскости данных и управления удаляются с помощью процедуры закрытия, включающей 2 сообщения.

Кроме того, базовый обмен включает вычислительную задачу (puzzle) [RFC7401], которую должен решить инициатор. Отвечающий выбирает уровень сложности этой задачи, что позволяет ему задерживать запросы новых инициаторов в соответствии с локальной политикой, например, при высокой нагрузке. Задача-головоломка может обеспечивать некоторую защиту от DoS-атак, поскольку механизм позволяет отвечающему не создавать состояния (stateless) до завершений базового обмена [aura-dos]. Головоломки HIP изучались для установившихся атак DDoS [beal-dos] на множестве моделей злоумышленников с изменением сложности задачи (puzzle) [tritilanunt-dos] и эфемерными отождествлениями хостов [komu-mitigation].

6.2. Мобильные и многоадресные хосты

HIP отделяет транспортный уровень от (меж)сетевого и связывает транспортные ассоциации с отождествлением хоста (через HIT или LSI). После начального обмена ключами уровень HIP поддерживает связность на транспортном уровне и потоки данных с использованием расширений для мобильности [RFC8046] и множественных адресов [RFC8047]. Таким образом, HIP может обеспечить некоторый уровень мобильности и поддержки множественных адресов без больших затрат на инфраструктуру. Поддержка мобильности в HIP включает смену адресов IP (любым способом) у любой из сторон. Система считается мобильной, если её адрес IP может меняться динамически по любой причине, такой как переназначение префикса PPP, DHCP, IPv6 или изменение трансляции NAT. Многодомной (многоадресной) считается система, имеющая одновременно несколько глобально маршрутизируемых адресов IP. HIP связывает адреса IP, если несколько адресов соответствует одному отождествлению хоста. Если один из адресов становится не применимым или появляется более предпочтительный адрес, имеющиеся транспортные ассоциации легко переносятся на другой адрес.

Когда мобильный узел перемещается в процессе обмена данными, смена адреса выполняется достаточно просто – узел передаёт пакет HIP UPDATE для информирования партнёра о новом адресе, а партнёр проверяет доступность мобильного узла по этому адресу. Это позволяет партнёру избежать лавинных атак, описанных в параграфе 11.2.

6.3. Механизм встречи

Организация контакта с перемещающимся мобильным узлом несколько сложней. Для начала обмена HIP узлу-инициатору нужно узнать, как связаться с мобильным узлом. Например, мобильный узел может реализовать Dynamic DNS [RFC2136] для обновления сведений о своей доступности в DNS. Чтобы избежать зависимости от DNS, в HIP имеется своё решение – механизм встречи HIP rendezvous, определённый в [RFC8004].

С помощью расширений HIP rendezvous мобильный узел постоянно обновляет инфраструктуру встреч, используя текущий адрес(а) IP. Мобильные узлы доверяют механизму встречи HIP для должной поддержки сопоставления их HIT с адресом IP. Механизм встречи особенно полезен в случаях, когда предполагается возможность изменения адресов одновременно обоими партнёрами. В этом случае пакеты HIP UPDATE будут «пересекаться» в сети и не попадут к партнёру.

6.4. Механизм ретрансляции

Механизм ретрансляции HIP [RFC9028] является альтернативой HIP rendezvous и более подходит для сетей IPv4 с NAT, поскольку способен пересылать все коммуникации управления и данных для гарантированного прохождения NAT.

6.5. Завершение плоскости управления

Плоскость управления между парой хостов удаляется с использованием защищённого обмена двумя сообщениями, описанного в базовой спецификации [RFC7401]. При удалении плоскости следует удалять и связанные с ней состояния (т. е., ассоциации между хостами).

7. Плоскость данных

Формат инкапсуляции для плоскости данных, служащей для переноса трафика прикладного уровня, может согласовываться динамически в процессе обмена ключами. Например, расширения HICCUPS [RFC6078] определяют один из способов доставки дейтаграмм прикладного уровня непосредственно через плоскость управления HIP с защитой на основе асимметричных ключей. Защищённый транспорт в реальном масштабе времени (Secure Real-time Transport Protocol или SRTP) также рассматривался в качестве протокола инкапсуляции данных [hip-srtp]. Однако более широкое распространение получил метод инкапсуляции защищённых данных (Encapsulated Security Payload или ESP) [RFC7402], использующий симметричные ключи, выведенные в процессе обмена ключами. Защищённые связи ESP (Security Association или SA) обеспечивают защиту конфиденциальности и целостности, причём первую можно отключить в процессе обмена ключами. В будущем могут быть определены иные способы доставки данных прикладного уровня.

ESP SA организуются и завершаются между инициатором и отвечающим хостом. Обычно хосты создают не менее 2 SA, по одной в каждом направлении (от инициатора к отвечающему и обратно). При смене IP-адреса любого из хостов можно использовать расширение HIP для повторного согласования соответствующих SA.

В линии разница при использовании идентификаторов между плоскостями управления и данных HIP состоит в том, что теги HIT включаются во все пакеты управления, но не включаются в пакеты данных при использовании ESP. Вместо этого применяются индексы параметров защиты ESP (Security Parameter Index или SPI), которые действуют как сжатые HIT. Любым промежуточным устройствам с поддержкой HIP (например, HIP МСЭ), заинтересованным в трафике данных на основе ESP, нужно отслеживать идентификаторы плоскостей данных и управления, чтобы связать их между собой.

Поскольку HIP не согласует срок действия SA, этот срок определяется локальными правилами. Реализация HIP должна поддерживать ограничение срока действия лишь на основе достижения максимального порядкового номера (защита от повторов) и тайм-аута SA, возникающего при отсутствии пакетов, принимаемых через SA. Реализации могут поддерживать сроки действия для разных преобразований ESP и других протоколов плоскости данных.

8. HIP и NAT

Передача пакетов между разными областями адресации IP требует изменения адресов в заголовках пакетов IP. Это может происходить, например, при передаче пакета между Internet и приватным пространством адресов или между сетями IPv4 и IPv6. Трансляция адресов обычно обеспечивается устройствами NAT (Network Address Translation) [RFC3022] или NAT-PT (NAT Protocol Translation) [RFC2766].

В среде с идентификацией хостов по адресам IP указание взаимодействующих узлов осложняется при использовании NAT, поскольку пространства приватных адресов перекрываются. Иными словами, два хоста невозможно отличить друг от друга на основе лишь адресов IP. В HIP конечные точки транспортного уровня (приложения) связаны с уникальными отождествлениями хостов вместо перекрывающихся приватных адресов. Это позволяет различать две конечные точки при их размещении в разных приватных областях адресации. В результате адреса IP применяются лишь для маршрутизации и могут свободно меняться устройствами NAT при прохождении пакетов между парой поддерживающих HIP хостов через области с разной приватной адресацией.

Расширения для прохождения NAT в протоколе HIP [RFC9028] могут служить для организации сквозной связности через устройства NAT. Для поддержки базовой совместимости с унаследованными устройствами NAT расширения инкапсулируют плоскости управления и данных HIP в протокол UDP. Расширения определяют механизмы для пересылки двух плоскостей через промежуточный хост, называемый ретранслятором HIP (relay) и процедуры для организации прямой сквозной связности через NAT. Поскольку это «естественный» режим прохождения через NAT для HIP, можно использовать и другие механизмы работы через NAT, например, Teredo [RFC4380] (см. [varjonen-split]).

Помимо традиционных NAT была разработана и реализована система NAT с поддержкой протокола HIP [ylitalo-spinat]. Для потоков на основе HIP поддерживающий HIP транслятор NAT или NAT-PT отслеживает сопоставления HIT и соответствующих ESP SPI с адресами IP. Система NAT узнает сопоставления HIT и SPI с адресами IP. Множество HIT (и SPI) может отображаться на один адрес IP в системе NAT, что упрощает соединения на интерфейсах NAT с недостаточным числом адресов. NAT может получать большую часть сведений из самих пакетов HIP, однако может потребоваться некоторая настройка конфигурации NAT.

8.1. HIP и контрольная сумма вышележащего уровня

Хост не может узнать, применялись ли адреса из заголовка IP при расчёте контрольной суммы TCP, т. е. невозможно рассчитать корректную контрольную сумму TCP, используя фактические адреса IP из псевдозаголовка, поскольку адрес в принятом пакете может отличаться от указанного передающим хостом. Кроме того, невозможно пересчитать контрольную сумму вышележащего уровня в системах NAT/NAT-PT, поскольку трафик защищён ESP. Поэтому контрольные суммы TCP и UDP рассчитываются с использованием HIT вместо адресов IP в псевдозаголовке. Используется лишь формат псевдозаголовков IPv6. Это обеспечивает трансляцию протоколов IPv4 и IPv6.

9. Групповая адресация

Был опубликован ряд исследований групповой адресации на основе HIP, включая [shields-hip], [zhu-hip], [amir-hip], [kovacshazi-host], [zhu-secure]. В частности, так называемые фильтры Блума, позволяющие сжимать несколько меток в небольшие структуры данных, могут быть многообещающим шагом вперёд [sarela-bloom]. Однако разные схемы не были приняты рабочей группой HIP (и исследовательской группой HIP в IRTF), поэтому детали здесь не приведены.

10. Правила HIP

Каждый хост должен поддерживать множество переменных, влияющих на обмен HIP. Всем реализациям HIP следует поддерживать по меньшей мере 2 HI, один из которых публикуется в DNS или иной службе каталогов, а второй не публикуется и служит для анонимного использования (предполагается его частая смена для предотвращения сопоставлений и отслеживания). Хотя неопубликованные HI редко применяются в качестве Responder HI, их часто используют инициаторы. Как указано в [RFC7401], «все реализации HIP должны поддерживать одновременно более одного HI, и по меньшей мере один идентификатор следует резервировать для анонимного использования» и «рекомендуется поддерживать более двух HI». Это ставит перед системами и пользователями вопрос выбора HI, раскрываемого при организации новой сессии.

Специальный (Opportunistic) режим, где инициатор начинает обмен HIP, не зная Responder HI, является компромиссом в части безопасности. Этот режим позволяет инициатору узнать отождествление отвечающего в процессе взаимодействия, а не из внешнего каталога, но это делает его уязвимым для MitM-атак. Этот режим можно применять для регистрации основанных на HIP служб [RFC8003] (т. е. использующих HIP для внутренних целей) или на уровне приложений [komu-leap]. Соображения безопасности, особенно во втором случае, требуют вовлечения пользователя в решение вопроса о восприятии отождествления отвечающего, подобно приглашению в протоколе SSH (Secure Shell) при первом подключении к серверу [pham-leap]. На практике этом может быть реализовано в МСЭ на конечных хостах в случае унаследованных приложений [karvonen-usable] или в естественных API для HIP [RFC6317] в приложениях с поддержкой HIP.

В [RFC7401] сказано: «Инициаторы могут использовать разные HI для разных отвечающих, чтобы обеспечить базовую приватность. Применение таких приватных HI повторно для одного отвечающего и срок действия HI определяется локальными правилами и зависит от требований приватности инициатора». Согласно [RFC7401]: «Responder, отвечающий лишь выбранным инициаторам, требует наличия списка управления доступом (Access Control List или ACL), представляющего хосты, от которых он воспринимает базовый обмен HIP, предпочтительный формат транспорта и локальные сроки действия. Следует поддерживать шаблонные записи в таких ACL, а также для отвечающих, которые предоставляют общедоступные или анонимные услуги.

11. Вопросы безопасности

В этом разделе рассматриваются некоторые вопросы и решения, связанные с безопасностью архитектуры HIP.

11.1. MitM-атаки

Протокол HIP использует парадигму отождествления хоста для защищённой аутентификации хостов и обеспечения быстрого обмена ключами для ESP. HIP также пытается ограничить раскрытие хоста для различных DoS и MitM-атак. При этом сам протокол HIP подвержен атакам DoS и MitM, которые могут нанести большой ущерб работе хоста.

DoS-атаки с истощением ресурсов используют «дороговизну» установки состояния протокола на отвечающей стороне по сравнению с «дешевизной» у инициатора. HIP позволяет отвечающему повысить стоимость запуска состояния на стороне инициатора и пытается снизить расходы отвечающего. Это делается за счёт запуска обмена Diffie-Hellman отвечающим вместо инициатора, что ведёт к базовому обмену HIP из 4 пакетов. Первый пакет, отправленный отвечающим, может быть создан заранее для дополнительного снижения затрат. Этот пакет также включает вычислительную задачу (puzzle), которая может служить для дополнительной задержки инициатора, например, при перегрузке отвечающего. Детали процесса приведены в спецификации базового обмена [RFC7401].

Защититься от MitM-атак сложно без сторонней аутентификации. Опытный атакующий может легко обработать все части базового обмена HIP, но протокол HIP опосредованно обеспечивает дополнительную защиту от MitM-атак. Если значение Responder HI получено из подписанной зоны DNS или иным защищённым способом, инициатор может применить это для аутентификации подписанных пакетов HIP. Если Initiator HI хранится в защищённой зоне DNS, отвечающий может найти идентификатор и проверить подписанные пакеты HIP. Однако инициатор может применять неопубликованный HI, осознанно принимая риск MitM-атаки. Responder может отказаться воспринимать обмен HIP с инициаторами, использующими неизвестный идентификатор HI.

Другие типы MitM-атак на HIP могут быть организованы с использованием сообщений ICMP, сообщающих о проблемах. В качестве общей рекомендации можно указать рассмотрение сообщений ICMP как ненадёжных «советов» и реагирование на них лишь после некоторой паузы (тайм-аут). Точные сценарии атак и меры противодействия описаны более подробно в спецификации базового обмена [RFC7401].

В MitM-атаке может быть предпринята попытка использования старых сообщений I1 или R1 с более слабыми криптографическими алгоритмами, как указано в параграфе 4.1.4 [RFC7401]. Базовый обмен был усилен для борьбы с такими атаками путём перезапуска при обнаружении атаки. В худшем случае это приведёт лишь к бесконечному повтору базового обмена или его прерыванию после некоторого числа попыток. Недостатком этого является 6-этапный базовый обмен, который может показаться неудачным решением. Однако такое возможно лишь при атаке, которая может быть обработана (чтобы повторять её не было смысла), поэтому предполагается, что последующие сообщения не представляют угрозы безопасности. Поскольку MitM-атаки не позволяют снизить версию, их можно считать лишь помехой. Таким образом, базовый обмен будет включать обычно лишь 4 пакета даже при готовности реализации к защите от понижения версии.

В протоколе HIP защищённые связи SA для ESP индексируются по SPI, адрес отправителя всегда игнорируется, а адрес получателя также можно проигнорировать. Поэтому при включённом HIP работа ESP не зависит от адресов IP. Это может показаться упрощением для организации атак, но ESP с защитой от повторного использования (replay) уже обеспечивает высокий уровень безопасности и удаление адреса IP из проверки не увеличивает раскрытие ESP для DoS-атак.

11.2. Защита от лавинных атак

Хотя идея информирования о смене адреса путём простой отправки пакетов с новым адресом источника кажется привлекательной, она недостаточно безопасна. Даже если HIP ни в чем не полагается на адрес отправителя (после завершения базового обмена), представляется необходимой проверка доступности мобильного узла по новому адресу до отправки туда большего объёма данных.

Восприятие новых адресов вслепую (без проверки) открывает возможность для организации лавинных DoS-атак против третьей стороны [RFC4225]. В распределенной лавинной атаке злоумышленник может создать соединения HIP с большим объёмом трафика и множеством хостов (неопубликованные HI) а затем объявить всем этим хостам о своём переходе на другой адрес IP. Если партнерские хосты будут просто воспринимать такой перенос, жертва с указанным адресом может получить лавину пакетов. Для предотвращения таких атак расширения HIP mobility включают процедуру проверки маршрута по обратному пути, где доступность узла проверяется независимо для каждого адреса до отправки по этому адресу большего объёма трафика.

До завершения проверки адреса для передачи данных между хостами можно воспользоваться основанном на кредите подходе «Host Mobility with the Host Identity Protocol» [RFC8046]. При использовании HIP между доверяющими один другому хостами можно отказаться от проверки адресов, однако такое решение следует принимать лишь в случаях, когда узлы заведомо заслуживают доверия и способны защитить себя от вредоносных программ.

11.3. Применение HIT в ACL

На конечных точках теги HIT могут применяться в списках контроля доступа на основе IP для прикладного или сетевого уровня. На промежуточных устройствах понимающие HIP МСЭ [lindqvist-enterprise] могут использовать HIT или открытые ключи для входного или выходного контроля на уровне сети или отдельных хостов даже в присутствии мобильных устройств, поскольку теги HIT и открытые ключи не связаны с топологией. Как отмечено в разделе 7, после организации сессии HIP значение SPI в пакете ESP может служить индексом, указывающим HIT. На практике МСЭ могут проверять пакеты HIP для изучения привязок между HIT, SPI и адресами IP. Можно даже явно контролировать использование ESP, динамически открывая ESP лишь для конкретных SPI и адресов IP. Подписи в пакетах HIP позволяют соответствующему МСЭ гарантировать, что обмен HIP действительно происходит между двумя известными хостами. Это может повысить уровень безопасности МСЭ.

Возможным недостатком HIT в ACL является их «плоская» природа, не позволяющая агрегировать теги, что может приводить к большому размеру таблиц поиска в МСЭ с поддержкой HIP. Способом оптимизации может служить применение фильтров Блума (Bloom) для группировки HIT [sarela-bloom]. Однако следует отметить, что правила для отдельных HIT, а не групп позволяют легко исключить хосты с некорректным поведением, не затрагивая других.

Имеется заметный негативный опыт работы с распределенными ACL, содержащими материал, относящийся к открытым ключам, например, для SSH. Если владельцу ключа нужно отозвать его по той или иной причине, задача поиска всех мест хранения ключа в ACL может оказаться непосильной. Если причина отзыва связана с кражей секретного ключа, это может привести к серьёзным проблемам.

Хост может отслеживать всех своих партнёров, которые могут применять его HIT в ACL, регистрируя все удалённые HIT достаточно регистрировать отвечающие хосты). На основе этой информации хост может уведомить другие хосты о смене HIT. Были попытки разработать защищённый метод выдачи уведомлений об отзыве HIT [zhang-revocation].

Некоторые промежуточные устройства с поддержкой HIP, такие как МСЭ [lindqvist-enterprise] или NAT [ylitalo-spinat], могут пассивно просматривать трафик в пути. Такие устройства по своей природе прозрачны и не могут получать уведомлений о переходе хоста в другую сеть. В результате от таких устройств требуется поддержка состояния и тайм-аутов для слишком долгого простоя плоскостей управления и данных между парой конечных хостов HIP. Соответственно, два конечных хоста могут периодически передавать пакеты сохранения (keepalive), такие как UPDATE или сообщения ICMP в туннеле ESP, для поддержки статуса в промежуточном устройстве.

Одним из общих ограничений для сквозного шифрования является неспособность промежуточных устройств участвовать в защите потоков данных. Хотя эта проблема может влиять и на другие протоколы, Heer и др. [heer-end-host] проанализировали её в контексте HIP. В частности, при использовании ESP в качестве протокола плоскости данных для HIP связь между плоскостями данных и управления слаба и может использоваться при некоторых допущениях. Предположим, что злоумышленник получил доступ к целевой сети, защищённой МСЭ с поддержкой HIP, но хочет обойти HIP МСЭ. Для этого атакующий пассивно наблюдает базовый обмен между двумя хостами HIP, а затем воспроизводит его. Таким образом злоумышленнику удаётся преодолеть МСЭ и он может использовать туннель ESP для доставки своих данных. Эта возможность обусловлена тем, что МСЭ не может проверить действительность туннеля ESP. Для решения проблемы промежуточные устройства с поддержкой HIP могут участвовать во взаимодействии с плоскостью управления путём добавления в трафик управления одноразовых параметров (nonce), которые конечные хосты должны подписывать для обеспечения свежести трафика управления [heer-midauth]. Как вариант можно использовать расширения для доставки трафика плоскости данных напрямую через плоскость управления [RFC6078].

11.4. Варианты для HI

В определении идентификатора хоста сказано, что HI не обязательно является открытым ключом. Это означает, что HI может быть любым значением, например, FQDN. Этот документ не описывает поддержку некриптографических HI, но примеры таких вариантов протокола имеются ([urien-rfid], [urien-rfid-draft]). Некриптографические HI по-прежнему будут предоставлять услуги HIT или LSI для прохождения через NAT. Можно переносить теги HIT в пакетах HIP без защиты приватности и конфиденциальности. Такие схемы могут быть пригодны для устройств с ограниченными ресурсами, таких как небольшие датчики с батарейным питанием, но здесь подобные устройства не рассматриваются.

Если желательно использовать HIP в ситуации с низким уровнем защиты, где расчёт открытых ключей считается избыточным, HIP можно применять с очень короткими ключами Diffie-Hellman и Host Identity. Это делает участвующие хосты уязвимыми для MitM-атак и захвата соединений, однако не вызывает опасности лавинных атак, поскольку механизм проверки адресов полагается на систему маршрутизации, а не криптостойкость.

11.5. Доверие при первом применении

В [RFC7435] выделено 4 принципа разработки для принятия на веру (Leap of Faith) или доверия при первом использовании (Trust On First Use или TOFU) для протоколов, применимые также к opportunistic HIP.

  1. Сосуществование с явной политикой.

  2. Приоритизация коммуникаций.

  3. Максимальная защита партнёров.

  4. Отсутствие ложного представления о безопасности.

Согласно первому принципу TOFU: «Защита с использованием обстоятельств (Opportunistic security) никогда не заменит и не вытеснит явные правила.» некоторые данные приложений могут быть слишком конфиденциальными (sensitive), поэтому соответствующая политика может требовать проверки подлинности (т. е. открытого ключа или сертификата) вместо защиты по обстоятельствам без аутентификации. На практике это реализовано в HIP в соответствии с [RFC6538].

OpenHIP позволяет инициатору применять режим Opportunistic лишь с явно заданным IP-адресом отвечающего, когда Responder HIT неизвестен. У отвечающего реализация OpenHIP позволяет включить режим Opportunistic для любого инициатора (доверие к любому инициатору).

Разработчики HIP for Linux (HIPL) экспериментировали с более детализированными правилами на уровне приложения. Реализация HIPL использует так называемую ловушку LD_PRELOAD на уровне приложения, которая позволяет динамически подключаемой библиотеке перехватывать связанные с сокетом вызовы без пересборки соответствующих двоичных файлов приложения. Библиотека выступает промежуточным уровнем между приложениям и транспортом, транслируя не связанные с HIP вызовы сокета из приложения в вызовы на основе HIP. Хотя такая библиотека вносит определённые сложности, описанные в [komu-leap], она достигает цели применения режима Opportunistic на уровне детализации отдельных приложений.

Второй принцип TOFU по сути провозглашает приоритет коммуникаций над безопасностью. Поэтому в общем случае режим Opportunistic следует разрешать даже при отсутствии аутентификации и возможности отката к нешифрованной связи (если правила позволяют) вместо блокировки. На практике это можно реализовать в три этапа. Сначала инициатор HIP может выполнить поиск Responder HI в каталоге (например, DNS). При нахождении инициатором HI он может применить идентификатор для аутентификации и пропустить следующие шаги. При отказе в поиске HI инициатор может попробовать режим Opportunistic с отвечающим. На третьем шаге инициатор может отказаться от коммуникаций на базе HIP после отказа режима Opportunistic, если политика разрешает это. Эта трехступенчатая модель была реализована и описана более подробно в [komu-leap].

Третий принцип TOFU предлагает максимизировать защиту для использования по меньшей мере защиты по обстоятельствам (opportunistic security). Описанная выше трехэтапная модель предпочитает по возможности применять аутентификацию, например, через записи DNS (а при доступности – через DNSSEC) и возвращается в режим Opportunistic при недоступности свидетельств по отдельному каналу (out-of-band credentials). В крайнем случае может происходить отказ от коммуникаций на основе HIP, если правила разрешают это. Поскольку в третьем принципе явно упоминается совершенная защита (perfect forward secrecy или PFS), следует упомянуть её поддержку в HIP.

Четвёртый принцип TOFU гласит, что пользователей и неинтерактивные приложения следует должным образом информировать о применяемом уровне защиты. На практике не поддерживающие HIP приложения будут предполагать отсутствие дополнительной защиты, поэтому ложное представление, по крайней мере у неинтерактивных приложений, возникать не должно. В случае интерактивных desktop-приложений в ранних экспериментах с HIP [karvonen-usable] [RFC6538] использовались приглашения системного уровня для выбора пользователем базовой защиты на основе HIP. Обычно в этих экспериментах пользователи понимали, когда применяется защита на основе HIP. Однако пользователи не замечали разницы между Opportunistic HIP без аутентификации и HIP с аутентификацией но без режима Opportunistic. Причина заключалась в том, что режим Opportunistic HIP (пониженный уровень защиты) не был чётко указан в системном приложении. Это стало уроком в части улучшения пользовательского интерфейса.

В случае понимающих HIP приложений можно использовать естественные API сокетов для HIP, описанные в [RFC6317], для разработки зависящей от приложения логики вместо базового системного приглашения. Здесь приложение само может спросить пользователя или иным способом управлять ситуацией. В этом случае неинтерактивные приложения также могут должным образом осознать уровень защиты, поскольку разработчик может явно задать использование HIP с аутентификацией, Opportunistic HIP или обмен открытыми данными (plain-text).

Следует упомянуть несколько дополнительных пунктов, отмеченных в [RFC7435]. Для активных атак в HIP имеется встроенная защита против понижения версии шифра, как описано в [RFC7401]. Кроме того, могут применяться заранее установленные сертификаты для ослабления атак в случае режима Opportunistic, как отмечено в [RFC6538].

Обнаружение возможностей партнёра также упоминается в контексте TOFU и для этого может применяться трехэтапная модель, отмеченная выше. Хост может выполнить первый этап аутентификации, т. е. обнаружить открытый ключ, например, через DNS. Если хост не находит ключей, он может в качестве второго шага проверить режим Opportunistic. При возникновении тайм-аута хост может перейти к третьему шагу, возвращаясь к взаимодействию без HIP, если политика разрешает это. Последний этап основан на неявном тайм-ауте вместо явного (негативного) подтверждения как в случае DNS, поэтому пользователь может сделать вывод об отказе преждевременно. Для ускорения фазы обнаружения путём явной проверки, поддерживает ли партнёр режим Opportunistic HIP, исследователи предложили расширения для TCP [RFC6538] [komu-leap]. Инициатор передаёт партнёру одновременно пакет (opportunistic) I1 и соответствующую дейтаграмму TCP SYN со специальной опцией TCP. Если партнёр поддерживает HIP, он отбросит пакет SYN и ответит пакетом R1. Если же партнёр не понимает HIP, он отбросит пакет HIP (и неизвестную опцию TCP) и передаст в ответ TCP SYN-ACK. Преимуществом предложенной схемы является быстрый отказ от попытки взаимодействия на основе HIP за один период кругового обхода. Недостаток заключается в привязке к TCP (опции IP также рассматривались, но они плохо работают через МСЭ и NAT). Такой подход не работает против активных атак, но режим Opportunistic в любом случае не предназначен для этого.

Следует отметить, что, несмотря на некоторые преимущества режима Opportunistic, связанные с постепенным развёртыванием, он уступает HIP с аутентификацией [komu-diss], поскольку тот поддерживает постоянные идентификаторы (хост указывается одним HI независимо от перемещений). Opportunistic HIP решает эту задачу лишь частично – после первого контакта между хостами HIP может поддерживать соединение с помощью расширений для мобильности, но возникают проблемы, когда хосты разрывают ассоциацию HIP и пытаются связаться снова. Хост может сменить своё местоположение и нет гарантии привязки адреса IP к хосту, поскольку один адрес может временно выделяться разным хостам (например, сервером DHCP), области адресации могут перекрываться (см. Приложение A.1) или из-за попытки организации атаки.

12. Взаимодействие с IANA

Этот документ не требует действий IANA.

13. Отличия от RFC 4423

Отличия от RFC 4423 [RFC4423] являются в основном редакторскими правками, включая разъяснения сложно описанных тем и исключение не относящихся к архитектуре деталей, уже описанных в других документах. Добавлен ряд пропущенных. Включено рассмотрение недостатков HIP, а также безопасности 802.15.4 и MAC, вариантов HIP для IoT, вопросов развёртывания и описание базового обмена.

14. Литература

14.1. Нормативные документы

[RFC5482] Eggert, L. and F. Gont, “TCP User Timeout Option”, RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.

[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, “HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)”, RFC 6079, DOI 10.17487/RFC6079, January 2011, <https://www.rfc-editor.org/info/rfc6079>.

[RFC7086] Keranen, A., Camarillo, G., and J. Maenpaa, “Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)”, RFC 7086, DOI 10.17487/RFC7086, January 2014, <https://www.rfc-editor.org/info/rfc7086>.

[RFC7343] Laganier, J. and F. Dupont, “An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)”, RFC 7343, DOI 10.17487/RFC7343, September 2014, <https://www.rfc-editor.org/info/rfc7343>.

[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, “Host Identity Protocol Version 2 (HIPv2)”, RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.

[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, “Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)”, RFC 7402, DOI 10.17487/RFC7402, April 2015, <https://www.rfc-editor.org/info/rfc7402>.

[RFC8002] Heer, T. and S. Varjonen, “Host Identity Protocol Certificates”, RFC 8002, DOI 10.17487/RFC8002, October 2016, <https://www.rfc-editor.org/info/rfc8002>.

[RFC8003] Laganier, J. and L. Eggert, “Host Identity Protocol (HIP) Registration Extension”, RFC 8003, DOI 10.17487/RFC8003, October 2016, <https://www.rfc-editor.org/info/rfc8003>.

[RFC8004] Laganier, J. and L. Eggert, “Host Identity Protocol (HIP) Rendezvous Extension”, RFC 8004, DOI 10.17487/RFC8004, October 2016, <https://www.rfc-editor.org/info/rfc8004>.

[RFC8005] Laganier, J., “Host Identity Protocol (HIP) Domain Name System (DNS) Extension”, RFC 8005, DOI 10.17487/RFC8005, October 2016, <https://www.rfc-editor.org/info/rfc8005>.

[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, “Host Mobility with the Host Identity Protocol”, RFC 8046, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-editor.org/info/rfc8046>.

[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, “Host Multihoming with the Host Identity Protocol”, RFC 8047, DOI 10.17487/RFC8047, February 2017, <https://www.rfc-editor.org/info/rfc8047>.

[RFC9028] Keränen, A., Melén, J., and M. Komu, Ed., “Native NAT Traversal Mode for the Host Identity Protocol”, RFC 9028, DOI 10.17487/RFC9028, July 2021, <https://www.rfc-editor.org/info/rfc9028>.

14.2. Дополнительная литература

[amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Pulkkis, “Security and Trust of Public Key Cryptography for HIP and HIP Multicast”, International Journal of Dependable and Trustworthy Information Systems (IJDTIS), Vol. 2, Issue 3, pp. 17-35, DOI 10.4018/jdtis.2011070102, 2013, <https://doi.org/10.4018/jdtis.2011070102>.

[aura-dos] Aura, T., Nikander, P., and J. Leiwo, “DOS-Resistant Authentication with Client Puzzles”, 8th International Workshop on Security Protocols, Security Protocols 2000, Lecture Notes in Computer Science, Vol. 2133, pp. 170-177, Springer, DOI 10.1007/3-540-44810-1_22, September 2001, <https://doi.org/10.1007/3-540-44810-1_22>.

[beal-dos] Beal, J. and T. Shepard, “Deamplification of DoS Attacks via Puzzles”, October 2004.

[camarillo-p2psip] Camarillo, G., Mäenpää, J., Keränen, A., and V. Anderson, “Reducing delays related to NAT traversal in P2PSIP session establishments”, IEEE Consumer Communications and Networking Conference (CCNC), pp. 549-553, DOI 10.1109/CCNC.2011.5766540, 2011, <https://doi.org/10.1109/CCNC.2011.5766540>.

[chiappa-endpoints] Chiappa, J., “Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture”, 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

[heer-end-host] Heer, T., Hummen, R., Komu, M., Gotz, S., and K. Wehrle, “End-Host Authentication and Authorization for Middleboxes Based on a Cryptographic Namespace”, 2009 IEEE International Conference on Communications, DOI 10.1109/ICC.2009.5198984, 2009, <https://doi.org/10.1109/ICC.2009.5198984>.

[heer-midauth] Heer, T., Ed., Hummen, R., Wehrle, K., and M. Komu, “End-Host Authentication for HIP Middleboxes”, Work in Progress, Internet-Draft, draft-heer-hip-middle-auth-04, 31 October 2011, <https://datatracker.ietf.org/doc/html/draft-heer-hip-middle-auth-04>.

[henderson-vpls] Henderson, T. R., Venema, S. C., and D. Mattes, “HIP-based Virtual Private LAN Service (HIPLS)”, Work in Progress, Internet-Draft, draft-henderson-hip-vpls-11, 3 August 2016, <https://datatracker.ietf.org/doc/html/draft-henderson-hip-vpls-11>.

[hip-dex] Moskowitz, R., Ed., Hummen, R., and M. Komu, “HIP Diet EXchange (DEX)”, Work in Progress, Internet-Draft, draft-ietf-hip-dex-24, 19 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-24>.

[hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov, “Novel secure VPN architectures for LTE backhaul networks”, Security and Communication Networks, Vol. 9, pp. 1198-1215, DOI 10.1002/sec.1411, January 2016, <https://doi.org/10.1002/sec.1411>.

[hip-srtp] Tschofenig, H., Shanmugam, M., and F. Muenz, “Using SRTP transport format with HIP”, Work in Progress, Internet-Draft, draft-tschofenig-hiprg-hip-srtp-02, 25 October 2006, <https://datatracker.ietf.org/doc/html/draft-tschofenig-hiprg-hip-srtp-02>.

[hummen] Hummen, R., Hiller, J., Henze, M., and K. Wehrle, “Slimfit – A HIP DEX compression layer for the IP-based Internet of Things”, 2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), pp. 259-266, DOI 10.1109/WiMOB.2013.6673370, October 2013, <https://doi.org/10.1109/WiMOB.2013.6673370>.

[IEEE.802.15.4] IEEE, “IEEE Standard for Low-Rate Wireless Networks”, IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2020.9144691, July 2020, <https://ieeexplore.ieee.org/document/9144691>.

[IEEE.802.15.9] IEEE, “IEEE Draft Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams”, IEEE P802.15.9/D04, May 2015.

[karvonen-usable] Karvonen, K., Komu, M., and A. Gurtov, “Usable security management with host identity protocol”, 2009 IEEE/ACS International Conference on Computer Systems and Applications, pp. 279-286, DOI 10.1109/AICCSA.2009.5069337, 2009, <https://doi.org/10.1109/AICCSA.2009.5069337>.

[komu-cloud] Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan, R., and S. Tarkoma, “Secure Networking for Virtual Machines in the Cloud”, 2012 IEEE International Conference on Cluster Computing Workshops, pp. 88-96, DOI 10.1109/ClusterW.2012.29, 2012, <https://doi.org/10.1109/ClusterW.2012.29>.

[komu-diss] Komu, M., “A Consolidated Namespace for Network Applications, Developers, Administrators and Users”, Dissertation, Aalto University, Espoo, Finland, ISBN 978-952-60-4904-5 (printed), ISBN 978-952-60-4905-2 (electronic), December 2012.

[komu-leap] Komu, M. and J. Lindqvist, “Leap-of-Faith Security is Enough for IP Mobility”, 2009 6th IEEE Consumer Communications and Networking Conference, Las Vegas, NV, USA, pp. 1-5, DOI 10.1109/CCNC.2009.4784729, January 2009, <https://doi.org/10.1109/CCNC.2009.4784729>.

[komu-mitigation] Komu, M., Tarkoma, S., and A. Lukyanenko, “Mitigation of Unsolicited Traffic Across Domains with Host Identities and Puzzles”, 15th Nordic Conference on Secure IT Systems, NordSec 2010, Lecture Notes in Computer Science, Vol. 7127, pp. 33-48, Springer, ISBN 978-3-642-27936-2, DOI 10.1007/978-3-642-27937-9_3, October 2010, <https://doi.org/10.1007/978-3-642-27937-9_3>.

[kovacshazi-host] Kovacshazi, Z. and R. Vida, “Host Identity Specific Multicast”, International Conference on Networking and Services (ICNS ’07), Athens, Greece, pp. 1-1, DOI 10.1109/ICNS.2007.66, 2007, <https://doi.org/10.1109/ICNS.2007.66>.

[levae-barriers] Levä, T., Komu, M., and S. Luukkainen, “Adoption barriers of network layer protocols: the case of host identity protocol”, Computer Networks, Vol. 57, Issue 10, pp. 2218-2232, ISSN 1389-1286, DOI 10.1016/j.comnet.2012.11.024, March 2013, <https://doi.org/10.1016/j.comnet.2012.11.024>.

[lindqvist-enterprise] Lindqvist, J., Vehmersalo, E., Komu, M., and J. Manner, “Enterprise Network Packet Filtering for Mobile Cryptographic Identities”, International Journal of Handheld Computing Research (IJHCR), Vol. 1, Issue 1, pp. 79-94, DOI 10.4018/jhcr.2010090905, 2010, <https://doi.org/10.4018/jhcr.2010090905>.

[Nik2001] Nikander, P., “Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World”, 9th International Workshop on Security Protocols, Security Protocols 2001, Lecture Notes in Computer Science, Vol. 2467, pp. 12-21, Springer, DOI 10.1007/3-540-45807-7_3, 2002, <https://doi.org/10.1007/3-540-45807-7_3>.

[nsrg-report] Lear, E. and R. Droms, “What’s In A Name: Thoughts from the NSRG”, Work in Progress, Internet-Draft, draft-irtf-nsrg-report-10, 22 September 2003, <https://datatracker.ietf.org/doc/html/draft-irtf-nsrg-report-10>.

[paine-hip] Paine, R. H., “Beyond HIP: The End to Hacking As We Know It”, BookSurge Publishing, ISBN-10 1439256047, ISBN-13 978-1439256046, 2009.

[pham-leap] Pham, V. and T. Aura, “Security Analysis of Leap-of-Faith Protocols”, 7th International ICST Conference, Security and Privacy for Communication Networks, SecureComm 2011, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Vol. 96, DOI 10.1007/978-3-642-31909-9_19, 2012, <https://doi.org/10.1007/978-3-642-31909-9_19>.

[ranjbar-synaptic] Ranjbar, A., Komu, M., Salmela, P., and T. Aura, “SynAPTIC: Secure and Persistent Connectivity for Containers”, 2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), Madrid, 2017, pp. 262-267, DOI 10.1109/CCGRID.2017.62, 2017, <https://doi.org/10.1109/CCGRID.2017.62>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE)”, RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.

[RFC2766] Tsirtsis, G. and P. Srisuresh, “Network Address Translation – Protocol Translation (NAT-PT)”, RFC 2766, DOI 10.17487/RFC2766, February 2000, <https://www.rfc-editor.org/info/rfc2766>.

[RFC3022] Srisuresh, P. and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT)”, RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.

[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, “Realm Specific IP: Framework”, RFC 3102, DOI 10.17487/RFC3102, October 2001, <https://www.rfc-editor.org/info/rfc3102>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., “Extensible Authentication Protocol (EAP)”, RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.

[RFC3972] Aura, T., “Cryptographically Generated Addresses (CGA)”, RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, “Mobile IP Version 6 Route Optimization Security Design Background”, RFC 4225, DOI 10.17487/RFC4225, December 2005, <https://www.rfc-editor.org/info/rfc4225>.

[RFC4380] Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”, RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.

[RFC4423] Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture”, RFC 4423, DOI 10.17487/RFC4423, May 2006, <https://www.rfc-editor.org/info/rfc4423>.

[RFC5218] Thaler, D. and B. Aboba, “What Makes for a Successful Protocol?”, RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.

[RFC5338] Henderson, T., Nikander, P., and M. Komu, “Using the Host Identity Protocol with Legacy Applications”, RFC 5338, DOI 10.17487/RFC5338, September 2008, <https://www.rfc-editor.org/info/rfc5338>.

[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, “Renumbering Still Needs Work”, RFC 5887, DOI 10.17487/RFC5887, May 2010, <https://www.rfc-editor.org/info/rfc5887>.

[RFC6078] Camarillo, G. and J. Melen, “Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)”, RFC 6078, DOI 10.17487/RFC6078, January 2011, <https://www.rfc-editor.org/info/rfc6078>.

[RFC6250] Thaler, D., “Evolution of the IP Model”, RFC 6250, DOI 10.17487/RFC6250, May 2011, <https://www.rfc-editor.org/info/rfc6250>.

[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, “Understanding Apple’s Back to My Mac (BTMM) Service”, RFC 6281, DOI 10.17487/RFC6281, June 2011, <https://www.rfc-editor.org/info/rfc6281>.

[RFC6317] Komu, M. and T. Henderson, “Basic Socket Interface Extensions for the Host Identity Protocol (HIP)”, RFC 6317, DOI 10.17487/RFC6317, July 2011, <https://www.rfc-editor.org/info/rfc6317>.

[RFC6537] Ahrenholz, J., “Host Identity Protocol Distributed Hash Table Interface”, RFC 6537, DOI 10.17487/RFC6537, February 2012, <https://www.rfc-editor.org/info/rfc6537>.

[RFC6538] Henderson, T. and A. Gurtov, “The Host Identity Protocol (HIP) Experiment Report”, RFC 6538, DOI 10.17487/RFC6538, March 2012, <https://www.rfc-editor.org/info/rfc6538>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, “Internet Key Exchange Protocol Version 2 (IKEv2)”, STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7435] Dukhovni, V., “Opportunistic Security: Some Protection Most of the Time”, RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.

[sarela-bloom] Särelä, M., Esteve Rothenberg, C., Zahemszky, A., Nikander, P., and J. Ott, “BloomCasting: Security in Bloom Filter Based Multicast”, Information Security Technology for Applications, NordSec 2010, Lecture Notes in Computer Science, Vol. 7127, pages 1-16, Springer, DOI 10.1007/978-3-642-27937-9_1, 2012, <https://doi.org/10.1007/978-3-642-27937-9_1>.

[schuetz-intermittent] Schütz, S., Eggert, L., Schmid, S., and M. Brunner, “Protocol enhancements for intermittently connected hosts”, ACM SIGCOMM Computer Communication Review, Vol. 35, Issue 3, pp. 5-18, DOI 10.1145/1070873.1070875, July 2005, <https://doi.org/10.1145/1070873.1070875>.

[shields-hip] Shields, C. and J. J. Garcia-Luna-Aceves, “The HIP protocol for hierarchical multicast routing”, Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, pp. 257-266, ISBN 0-89791-977-7, DOI 10.1145/277697.277744, 1998, <https://doi.org/10.1145/277697.277744>.

[tempered-networks] Tempered Networks, “Identity-Defined Network (IDN) Architecture: Unified, Secure Networking Made Simple”, White Paper, 2016.

[tritilanunt-dos] Tritilanunt, S., Boyd, C., Foo, E., and J.M.G. Nieto, “Examining the DoS Resistance of HIP”, On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Lecture Notes in Computer Science, Vol. 4277, pp. 616-625, Springer, DOI 10.1007/11915034_85, 2006, <https://doi.org/10.1007/11915034_85>.

[urien-rfid] Urien, P., Chabanne, H., Pepin, C., Orga, S., Bouet, M., de Cunha, D.O., Guyot, V., Pujolle, G., Paradinas, P., Gressier, E., and J.-F. Susini, “HIP-based RFID Networking Architecture”, 2007 IFIP International Conference on Wireless and Optical Communications Networks, pp. 1-5, DOI 10.1109/WOCN.2007.4284140, 2007, <https://doi.org/10.1109/WOCN.2007.4284140>.

[urien-rfid-draft] Urien, P., Lee, G. M., and G. Pujolle, “HIP support for RFIDs”, Work in Progress, Internet-Draft, draft-irtf-hiprg-rfid-07, 23 April 2013, <https://datatracker.ietf.org/doc/html/draft-irtf-hiprg-rfid-07>.

[varjonen-split] Varjonen, S., Komu, M., and A. Gurtov, “Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-Location Split”, Journal of Communications Software and Systems, Vol. 6, Issue 1, ISSN 18456421, DOI 10.24138/jcomss.v6i1.193, 2010, <https://doi.org/10.24138/jcomss.v6i1.193>.

[xin-hip-lib] Xin, G., “Host Identity Protocol Version 2.5”, Master’s Thesis, Aalto University, Espoo, Finland, June 2012.

[ylitalo-diss] Ylitalo, J., “Secure Mobility at Multiple Granularity Levels over Heterogeneous Datacom Networks”, Dissertation, Helsinki University of Technology, Espoo, Finland, ISBN 978-951-22-9531-9, 2008.

[ylitalo-spinat] Ylitalo, J., Salmela, P., and H. Tschofenig, “SPINAT: Integrating IPsec into Overlay Routing”, First International Conference on Security and Privacy for Emerging Areas in Communication Networks, SECURECOMM’05, Athens, Greece, pp. 315-326, ISBN 0-7695-2369-2, DOI 10.1109/SECURECOMM.2005.53, 2005, <https://doi.org/10.1109/SECURECOMM.2005.53>.

[zhang-revocation] Zhang, D., Kuptsov, D., and S. Shen, “Host Identifier Revocation in HIP”, Work in Progress, Internet-Draft, draft-irtf-hiprg-revocation-05, 9 March 2012, <https://datatracker.ietf.org/doc/html/draft-irtf-hiprg-revocation-05>.

[zhu-hip] Zhu, X., Ding, Z., and X. Wang, “A Multicast Routing Algorithm Applied to HIP-Multicast Model”, 2011 International Conference on Network Computing and Information Security, Guilin, China, pp. 169-174, DOI 10.1109/NCIS.2011.42, 2011, <https://doi.org/10.1109/NCIS.2011.42>.

[zhu-secure] Zhu, X. and J. W. Atwood, “A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol”, 2007 4th IEEE Consumer Communications and Networking Conference, Las Vegas, NV, USA, pages 1098-1102, DOI 10.1109/CCNC.2007.221, 2007, <https://doi.org/10.1109/CCNC.2007.221>.

Приложение A. Соображения по устройству

A.1. Преимущества HIP

Изначально протокол сетевого уровня (IP) имел 4 «классических» инварианта:

  1. неизменность – переданный адрес совпадал с принятым;

  2. отсутствие мобильности – адрес не менялся в процессе взаимодействия;

  3. обратимость – адрес возврата всегда определялся перестановкой адресов отправителя и получателя;

  4. всеведение – каждый хост знал, какой адрес можно использовать для передачи пакетов партнёру.

Четвёртый инвариант можно вывести из 1 и 3, но он упомянут явно по причинам, рассмотренным ниже.

В современном «постклассическом» мире предпринимаются попытки исключить п. 2 (для мобильности и применения нескольких адресов), а также произошёл отказ от пп. 1 и 4. Попыткой сохранить п. 4 без п. 1, был документ Realm Specific IP [RFC3102], а IPv6 пытается восстановить п. 1.

Значимые имена DNS имеют немногие клиентские системы в Internet. Т. е. при наличии у клиентской системы имени FQDN это имя обычно относится к устройству NAT или серверу доступа (dial-up), а не указывает реально подключающуюся систему. FQDN (и их расширения в форме почтовых адресов) относятся к уровню приложений (чаще именуются службы, а не отдельные системы). Поэтому многие системы в Internet не зарегистрированы в DNS – у них просто нет служб, интересных другим хостам Internet.

Имена DNS являются ссылками на адреса IP и это лишь демонстрирует связь между сетевым и прикладным уровнем. DNS, как единственная и распределенная база данных Internet, является также хранилищем для других пространств имён, отчасти благодаря DNSSEC и записям ключей для приложений. Хотя каждое пространство имён можно растянуть (IP с помощью v6, DNS с помощью записей KEY), ни одно из них не может адекватно обеспечить аутентификацию хостов или послужить разделом между прикладным и сетевым уровнем.

Пространство имён HI заполняет важный пробел между пространствами IP и DNS. Интересным в HI является возможность отказа хоста от всего, кроме п. 3 для сетевого уровня. Иными словами, пока адреса отправителя и получателя в протоколе сетевого уровня обратимы, HIP заботится об идентификации хоста, а обратимость позволяет локальному хосту получать пакеты от удалённого. Смена адресов в результате прохождения через NAT (изменяемость) или перемещения хоста (мобильность и отсутствие всеведения) может обрабатываться уровнем HIP.

За исключением высокопроизводительных расчётных приложений, API сокетов являются наиболее общим вариантом разработки сетевых приложений, которые используют API напрямую или опосредованно через те или иные библиотеки или модели. Однако API сокетов основаны на допущении о статических адресах IP, а DNS со сроками действия записей придумали позже в процессе развития Internet. Поэтому API сокетов не работают со сроками действия адресов [RFC6250]. Сегодня большая часть пользовательского оборудования стала мобильной, а его адреса эфемерными, но API сокетов по-прежнему создают иллюзию постоянства адресов IP для неосторожных разработчиков. Протокол HIP может служить для укрепления этой иллюзии, поскольку HIP обеспечивает постоянные суррогатные адреса в форме LSI и HIT.

Постоянные идентификаторы, предоставляемые HIP, полезны во многих случаях (см. [ylitalo-diss] [komu-diss]).

  • При перемещении мобильного хоста между WLAN со сменой адреса использующее идентификаторы приложение не зависит от изменений топологии, а нижележащий уровень HIP восстанавливает связность (передача обслуживания по горизонтали).

  • При переходе мобильного устройства из сети WLAN в сотовую сеть использующему идентификаторы приложению не нужно знать о смене технологии (передача обслуживания по вертикали).

  • При размещении хостов в разных сетях с приватными адресами приложение может однозначно распознавать хосты по их идентификаторам. Иными словами, HIP улучшает прозрачность Internet для уровня приложений [komu-diss].

  • При смене адресов сайта для служб в результате раздела или слияния компаний, а также при смене Internet-провайдера может полностью измениться сетевой префикс организации, что может создавать проблемы для трафика из-за жёсткого задания адресов в файлах конфигурации служб или кэширования адресов IP на стороне клиентов [RFC5887]. С учётом возможных человеческих ошибок использование независимых от местоположения идентификаторов, предоставляемых HIP, может смягчить проблему смены адресов.

  • Может быть повышена гибкость взаимодействия с IPv6, как отмечено в параграфе 4.4. Приложения на основе IPv6 могут взаимодействовать с помощью HIT с приложениями IPv4, использующими идентификаторы LSI. Кроме того, семейство адресов в приложении становится независимым от типа базовой сети (IPv4 или IPv6).

  • Можно применять HIT (или LSI) в списках доступа на основе IP как более защищённую замену адресов IPv6. Помимо защиты, контроль доступа на основе HIT обеспечивает два других преимущества. Во-первых, применение HIT может вдвое сократить размер списков, поскольку не будут нужны отдельные правила для IPv4 [komu-diss]. Во-вторых, правила конфигурации на основе HIT в промежуточных устройствах с поддержкой HIP остаются статическими и не зависят от смены топологии, что упрощает администрирование, особенно для сред с мобильными устройствами. Например, преимущества списков управления доступом на основе HIT применимы в HIP МСЭ, но могут использоваться также непосредственно на конечных хостах [RFC6538].

Хотя некоторые из этих преимуществ могут быть и были реализованы в отдельных приложениях, обеспечение такой базовой функциональности на более низком уровне полезно, поскольку снижает объем работы при создании приложений и число ошибок в сетевых программах (поскольку уровень тестируется с разными приложениями). Это также позволяет разработчикам сосредоточиться на приложении, а не вникать в тонкости работы мобильных сетей, тем самым облегчая разделение задач.

HIP можно объединять с разными протоколами, но сложность получаемых в результате программ может существенно возрасти, а взаимодействие между разными (возможно многоуровневыми) протоколами может негативно повлиять на задержку и пропускную способность. Следует также отметить, что практически нет помех в реализации архитектуры HIP в форме, например, библиотеки прикладного уровня, которая уже фактически была реализована в [xin-hip-lib]. Однако при переносе HIP на уровень приложений могут не поддерживаться унаследованные приложения.

A.2. Недостатки HIP

В информатике многие проблемы можно решить с помощью дополнительного уровня опосредованности. Однако косвенные обращения всегда связаны с определёнными расходами и «бесплатных обедов» не бывает. Издержки для случая HIP перечислены ниже.

  • В общем случае дополнительный уровень и пространство имён всегда требуют начальных усилий в плане разработки, развёртывания и обслуживания. Может потребоваться также некоторое обучение для разработчиков и администраторов. Сообщество HIP в IETF потратило годы на эксперименты, исследования, тестирование, документирование и реализацию HIP для снижения расходов на внедрение.

  • HIP требует управления идентификаторами HI и централизованного подхода к масштабному управлению конечными точками с поддержкой HIP. Прежние ACL на основе адресов IP сейчас стали списками на основе доверенных HIT и сопоставление HIT с IP, а также правила доступа нужно администрировать. Конечные точки с поддержкой HIP должны также быть способны работать автономно для обеспечения мобильности и доступности (конечная точка должна сохранять работоспособность в отсутствие постоянного управляющего соединения). Пользователи, которым нужна повышенная защищенность и мобильность на основе HI вместо ACL по адресам IP, должны затем поддерживать этот дополнительный «уровень отождествления». Как показано в Приложении A.3.5, эти задачи уже решены в настройке инфраструктуры распространения политики и управления отображениями и отношениями доверия между конечными точками HIP.

  • HIP разделяет роли IP адресов как идентификаторов и «локаторов», поэтому требуется механизм сопоставления, чтобы связать их между собой. Неспособность сопоставить HIT с соответствующим «локатором» может приводить к отказам связности, поскольку идентификаторы HIT являются «плоскими» по своей природе и не поддерживают поиска через иерархическую систему DNS. Плоское пространство HIT обусловлено компромиссом в части защиты. Увеличение размера хэша в HIT снижает вероятность (злонамеренных) конфликтов (совпадений).

  • С точки зрения производительности обработка плоскостей данных и управления в HIP вносит некоторые издержки в части пропускной способности и задержки, как описано ниже.

Из-за недостатков развёртывания для контроля доступа к различным службам и устройствам в современной сети Internet обычно применяются МСЭ. Поскольку HIP вносит дополнительное пространство имён, предполагается что для него также будет применяться фильтрация на предмет нежелательных подключений. Хотя это может быть достигнуто с помощью имеющихся средств непосредственно на конечных хостах, фильтры промежуточных устройств потребуется менять с внесением правок в программы имеющихся МСЭ или дополнительных промежуточных устройств [RFC6538].

Обмен ключами вносит дополнительную задержку *2 периода кругового обхода) в организацию транспортного соединения между парой конечных хостов. В TCP дополнительная задержка возникает, если реализация базового сетевого стека отбрасывает пакет SYN в процессе обмена ключами. Такие же издержки могут добавляться процедурами передачи обслуживания в HIP. Однако последующие сеансы TCP с той же ассоциацией HIP не будут добавлять издержек (в течение срока действия ключа). Издержки при обмене ключами и передаче обслуживания можно минимизировать за счёт кэширования пакетов TCP, а передачу обслуживания можно дополнительно оптимизировать с помощью расширений для пользовательского тайм-аута TCP [RFC5482], как подробно описал Schütz с соавторами [schuetz-intermittent].

Наиболее загружающие CPU операции связаны с использованием асимметричных ключей и вывода ключей методом Diffie-Hellman в плоскости управления, но это происходит при обмене ключами, их обслуживании (передача обслуживания и обновление ключевого материала) и завершении ассоциаций HIP. Плоскость данных обычно реализуется с помощью ESP, поскольку это снижает издержки за счёт применения симметричных ключей. Однако и с ESP связаны дополнительные издержки в части задержек (обработка) и пропускной способности (туннелирование), как отмечено в [ylitalo-diss] для оценки производительности.

A.3. Вопросы развёртывания и адаптации

В этом разделе рассмотрены некоторые соображения по развёртыванию и адаптации HIP с технической точки зрения.

A.3.1. Анализ развёртывания

Протокол HIP был адаптирован и развернут в промышленной сети управления производственного предприятия, где строгая идентификация HIP на сетевом уровне поддерживала безопасное сосуществование множества незащищённых сетевых устройств разных производителей [paine-hip]. Протокол HIP был также включён в продукцию защиты для поддержки L2 VPN [henderson-vpls] с целью поддержки зон безопасности в сети диспетчерского контроля и сбора данных (supervisory control and data acquisition или SCADA). Однако HIP не получил «большого успеха» [RFC5218] в Internet, как отмечено Levä и др. [levae-barriers]. Здесь кратко освещены некоторые выводы, основанные на общении с 19 специалистами из сферы промышленности и академических кругов.

С точки зрения маркетинга потребность в HIP была невелика и предпочтение отдавалось другим технологиям. Другая выявленная причина заключалась в сохранении некоторых технических заблуждений, связанных с ранними спецификациями HIP. Два обнаруженных заблуждения состояли в том, что HIP не поддерживает работу через NAT и требует реализации в ядре OS. Оба этих утверждения не соответствуют действительности – HIP включает расширения для работы через NAT [RFC9028], а изменения ядра можно избежать в современных ОС перенаправляя пакеты для обработки в пользовательское пространство.

В анализе Levä и др. приведены инфраструктурные требования для HIP. В минимальном варианте на машинах клиента и сервера должны работать программы HIP. Однако для предотвращения настройки вручную для HIP обычно создаются записи в DNS. Например, популярных DNS-сервер Bind9 не требует каких-либо изменений для размещения записей, связанных с HIP, поскольку он поддерживает двоичный формат в файлах конфигурации [RFC6538]. Серверы HIP rendezvous и МСЭ не являются обязательными. Не требуется вносить изменения в сетевые адреса, NAT, граничные маршрутизаторы и сети ядра.

Анализ также проясняет требования к компонентам хоста, состоящие из трёх частей. Во-первых, требуется плоскость управления HIP, обычно реализуемая в виде демона в пользовательском пространстве. Во-вторых, нужна плоскость данных и большинство реализаций HIP использует режим туннеля со сквозной привязкой (Bound End-to-End Tunnel или BEET) для ESP, доступный в Linux, начиная с ядра 2.6.27, и включенный также в нескольких реализациях в форме программы в пользовательском пространстве. В-третьих, системы HIP обычно обеспечивают DNS-прокси для локального хоста, транслирующий записи HIP DNS в LSI или HIT и передающий соответствующие «локаторы» демону HIP в пользовательском пространстве. Хотя третья часть не является обязательной, она очень полезна для предотвращения настройки вручную. Дополнительное описание этих модулей приведено в отчёте [RFC6538].

На основе обсуждения со специалистами в работе Levä и др. предложены дальнейшие направления для упрощения развёртывания HIP. Перенос ряда спецификаций HIP в IETF Standards Track уже произошёл, но авторы предлагают дополнительные меры, в частности, реализацию HIP в виде библиотеки прикладного уровня [xin-hip-lib] или иной промежуточной программы (middleware). С другой стороны, более осторожные меры включают сосредоточение на частных развёртываниях, контролируемых одной заинтересованной стороной. В качестве более конкретного примера такого сценария HIP может применяться одним сервис-провайдером для организации защищённых соединений между его серверами [komu-cloud].

A.3.2. HIP в сетях 802.15.4

Стандарты IEEE 802 определяют защиту на уровне MAC и многие из них используют расширяемый протокол аутентификации (Extensible Authentication Protocol или EAP) [RFC3748] в качестве системы управления ключами (Key Management System или KMS), но некоторые стандарты, такие как IEEE 802.15.4 [IEEE.802.15.4], оставляют систему KMS и её транспорт вне «области действия». HIP хорошо подходит для таких сред в качестве KMS.

  • HIP не зависит от адресации IP и может транспортироваться напрямую по любому сетевому протоколу.

  • Первичные ключи в протоколах 802 обычно являются парными и групповые ключи доставляются из группового контроллера с помощью парных ключей.

  • Одноранговая KMS может лучше обслуживать специализированные (Ad-hoc) сети 802, чем модель «клиент-сервер» в EAP.

  • Память в некоторых устройствах может быть сильно ограничена, а общая система KMS для защиты MAC и IP даёт существенную экономию кода.

A.3.3. HIP и IoT

HIP требует на устройстве наличия вычислительных ресурсов для криптографической обработки. Протокол может работать в телефонах и небольших устройствах system-on-chip (таких как Raspberry Pi, Intel Edison), но мелкие датчики со слабыми батареями остаются проблематичными. Были разработаны расширения HIP для переноса на мелкие устройства обычно со снижением уровня защиты. Например, были предложены некриптографические идентификаторы для RFID. Подход Slimfit [hummen] предлагает уровень сжатия для HIP, делающий протокол более подходящим для сетей с ограничениями. Этот подход применён в облегчённой версии HIP (Diet HIP) для мелких датчиков.

Обмен HIP Diet EXchange (DEX) [hip-dex] нацелен на снижение издержек, связанных с криптографическими примитивами, за чет отказа от подписей открытых ключей и хэш-функций. При этом сохраняется цель обеспечить свойства защиты, аналогичные базовому обмену (Base Exchange или BEX). Обмен DEX разработан прежде всего для устройств и датчиков с оганиченной памятью и вычислительными ресурсами. Предполагается, что он будет применяться с подходящим протоколом защиты данных вышележащего протокола, таким как ESP. Кроме того, DEX может служить механизмом ввода ключей для примитивов защиты на уровне MAC, например, для сетей IEEE 802.15.9 [IEEE.802.15.9]. Основные отличия между BEX от DEX указаны ниже.

  1. Минимальный набор криптографических примитивов для снижения протокольных издержек:

    • статические пары ключей Elliptic Curve Diffie-Hellman (ECDH) для аутентификации и шифрования сеансового ключа;

    • AES-CTR для симметричного шифрования и AES-CMAC для функции MACing;

    • простая функций свёртки (fold) для генерации HIT.

  2. Отказ совершенной защиты (PFS) с отменой эфемерного согласования ключей Diffie-Hellman.

  3. Отказ от цифровых подписей с исключением хэш-функции. Использование выведенного из ECDH ключа в HIP_MAC для подтверждения владения секретным ключом.

  4. Выводимый с помощью Diffie-Hellman ключ применяется лишь для защиты пакетов HIP. Для создания сеансовых ключей применяется отдельный обмен секретами в пакетах HIP.

  5. Необязательная стратегия повтора передачи адаптирована для потенциально длительного выполнения криптографических на устройствах с ограниченными вычислительными ресурсами.

A.3.4. Инфраструктурные приложения

В отчёте об экспериментах с HIP [RFC6538] указан ряд реализаций клиентских и серверных приложений, опробованных с HIP. На основе этого отчёта ниже рассматриваются и дополняются некоторые возможные способы применения HIP в имеющейся инфраструктуре (маршрутизаторы, шлюзы, прокси).

HIP успешно применялся в пересылающих web-прокси (прокси у клиента) между хостом клиента (web-браузер) и пересылающим прокси (сервер Apache), завершающим туннель HIP/ESP. Пересылающий web-прокси транслировал основанный на HIP трафик от клиента в обычный (не HIP) трафик с направлении web-сервера в Internet. Поддерживающий HIP клиент мог взаимодействовать с не понимающими HIP серверами. Таким способом клиент мог использовать поддержку мобильности в HIP при использовании фиксированного IP-адреса на web-прокси, например, для доступа к услугам, которые разрешены лишь для адресов IP из диапазона прокси.

В случае с обратным web-прокси (на стороне сервера), который также был исследован [komu-cloud], не поддерживающий HIP клиент обращался к понимающему HIP сервису web через промежуточный балансировщик нагрузки (HAProxy). Балансировщик транслировал обычный (не HIP) трафик от клиента в трафик на основе HIP для web-сервиса (серверы front-end и back-end). Балансировщик и web-сервис размещались в ЦОД. Одним из ключевых преимуществ шифрования web-трафика с помощью HIP в этом случае была поддержка частного и публичного (гибридного) облака, где балансировщик и серверы front-end и back-end размещаются в разных ЦОД и трафик нужно защищать при передаче через потенциально незащищённые сети между границами частного и публичного облака.

Хотя HIP можно применять для защиты доступа к промежуточным устройствам (например, доступа к коммутаторам по протоколу telnet), он использовался также для защиты соединений в инфраструктуре промежуточных устройств. Например, в более ранним исследовании [komu-mitigation] HIP применялся между почтовыми серверами (Simple Mail Transport Protocol или SMTP) для применения вычислительной головоломки (puzzle) HIP в качестве механизма снижения спама. Достаточно очевидной проблемой в этом случае было отсутствие адаптации HIP на серверах SMTP.

Чтобы избежать проблем развёртывания в имеющейся инфраструктуре, HIP можно использовать в контексте новых протоколов с минимальным развёртыванием. HIP был изучен в контексте некого протокола peer-to-peer SIP [camarillo-p2psip], результатом чего стал набор связанных RFC [RFC6078], [RFC6079], [RFC7086]. Основная идея исследования состояла в предотвращении избыточных трудоёмких процедур ICE путём группировки разных соединений (т. е. SIP и медиапотоки) вместе с использованием низкоуровневого HIP, выполняющего процедуру прохождения NAT лишь один раз на хост. Интересным аспектом было применение инфраструктуры P2P-SIP в качестве серверов встречи для плоскости управления HIP вместо использования традиционных служб HIP rendezvous [RFC8004].

Исследователи предложили применять HIP в сотовых сетях как решение для мобильности, множества адресов и защиты. В [hip-lte] приведён анализ защиты и моделирование применения HIP в транспортных сетях LTE.

HIP изучали в части защиты внутриоблачных соединений сначала с виртуальными машинами [komu-cloud], затем между контейнерами Linux [ranjbar-synaptic]. В обоих случаях HIP предоставлял решение для работы через NAT, которое подходило как внутри облака, так и между разными облаками. В частности, для первого случая HIP обеспечивал постоянную связность с виртуальной машиной при её переносе в другое место, а во втором контроллер программно-определяемой сети (Software-Defined Networking или SDN) служил сервером встреч для поддерживающих HIP контейнеров, обеспечивая надёжную защиту от повторного использования путём добавления middlebox nonce [heer-end-host] для базового обмена HIP и сообщений UPDATE.

A.3.5. Поддержка отождествлений в коммерческих системах

Tempered Networks выпускает продукцию на основе HIP, называя свою платформу сетью на основе отождествлений (Identity-Defined Networking или IDN) [tempered-networks] из за ориентированной на идентификацию архитектуры HIP. Задача заключалась в упрощении и бесперебойном развёртывании служб с поддержкой HIP в рабочих средах для обеспечения прозрачной аутентификации и проверки полномочий устройств, сокрытия, сегментации и сквозного взаимодействия в сети. Цель состоит в устранении большого числа циклических зависимостей, эксплойтов и сложности традиционных сетей на основе адресов, которые препятствуют мобильности и проверяемому контролю доступа к устройствам. Продукция Tempered Networks представляет HIP в нескольких типах устройств.

Коммутаторы и шлюзы HIP

Физические и виртуальные устройства, служащие шлюзами HIP и точками применения правил для приложений без поддержки HIP и расположенных за ними устройств. Для подключения, маскировки и защиты устройств без поддержки HIP не нужно менять IP или инфраструктуру. В настоящее время шлюзы HIP поддерживаются на устройствах x86 и ARM, а также в облаках ESXi, Hyper-V, KVM, AWS, Azure, Google.

Трансляторы и серверы встречи HIP

Физические и виртуальные устройства, служащие маршрутизаторами на основе отождествлений для проверки полномочий и соединения конечных точек HIP без шифрования сессий HIP. Ретранслятор HIP можно развернуть как автономное устройство или в кластере для горизонтальной расширяемости. Все конечные точки с поддержкой HIP, соединяемые и защищаемые ими устройства могут иметь приватные адреса. Платформы предотвращают конфликты IP, поддерживают туннели через NAT (включая NAT операторского класса) и не требуют менять базовую инфраструктуру. Единственным требованием является наличие у конечной точки HIP исходящего доступа в Internet а у ретранслятора HIP – публичного адреса.

Клиенты и серверы с поддержкой HIP

программы, устанавливаемые в сетевой стек хоста и обеспечивающие выполнение правил на хосте. Клиенты HIP поддерживают раздельное туннелирование. Клиенты и серверы HIP могут взаимодействовать с МСЭ на локальном хосте, а сервер можно заблокировать для прослушивания лишь применяемого для HIP порта, что делает его невидимым для неуполномоченных устройств. В настоящее время поддерживаются платформы Windows, OS X, iOS, Android, Ubuntu, CentOS и другие дистрибутивы Linux.

Менеджеры оркестровки правил

Физические и виртуальные устройства для задания и распространения правил сети и защиты (сопоставления HI и IP, наложенные сети, «белые» списки и т. п.) в конечные точки с поддержкой HIP. Оркестровка не требует сохранения в конечных точках HIP и наоборот, что позволяет создавать автономные сети и обеспечивать защиту.

A.4. Ответы на вопросы NSRG

Исследовательская группа IRTF Name Space задала в своём оценочном отчёте ряд вопросов [nsrg-report], ответы на которые представлены ниже.

  1. Как имя стека улучшит общую функциональность Internet?

    HIP отделяет (меж)сетевой уровень от транспортного, позволяя им развиваться независимо. Разделение упрощает мобильность и многоадресность конечных хостов, а также позволяет работать через сети IPv4 и IPv6. HI упрощает смену адресов и миграцию процессов, а также реализацию кластеризованных серверов. Кроме того, криптографическая природа идентификаторов обеспечивает базу для решения вопросов безопасности, связанных с мобильностью и многоадресностью конечных хостов.

  2. Как выглядит имя стека?

    HI является криптографическим открытым ключом, однако вместо непосредственного использования ключа многие протоколы применяют хэш открытого ключа с фиксированным размером.

  3. Каков срок действия идентификатора?

    HIP поддерживает стабильные и временные HI. Стабильные HI обычно имеют длительный срок действия (годы), а для временных срок определяют соединения и приложения вышележащего уровня (от секунд до лет).

  4. Где HI размещаются в стеке?

    Идентификаторы HI находятся между транспортным и (меж)сетевым уровнем.

  5. Как HI используются конечными точками?

    Идентификаторы HI могут применяться приложениями напрямую или опосредовано (в форме HIT или LSI) при обращении к сетевым службам. Кроме того, HI как открытые ключи используются во встроенном протоколе согласования ключей, называемом базовым обменом HIP, для взаимной аутентификации хостов.

  6. Какая административная инфраструктура требуется для поддержки?

    В некоторых средах возможно применение HIP без какой-либо инфраструктуры, однако для полного использования преимуществ HIP идентификаторы HI должны храниться в DNS или PKI, а также нужен «механизм встречи (rendezvous) [RFC8005].

  7. Не делает ли дополнительный уровень ненужным список адресов в SCTP?

    Да, список не нужен.

  8. Какие дополнительные преимущества обеспечивает новая схема именования в части безопасности?

    HIP снижает зависимость от адресов IP, упрощая решение проблемы владения адресами [Nik2001]. На практике HIP обеспечивает защиту для мобильности и многоадресности конечных хостов. Кроме того, идентификаторы HI являются открытыми ключами и поверх HIP может применяться стандартная инфраструктура открытых ключей.

  9. Каким может быть механизм распознавания и какие характеристики требуются от него?

    Для большинства случаев достаточно модели с преобразованием имён DNS сразу в HI и адреса IP. Однако, если требуется преобразование HI в адреса IP или их обратное преобразование в имена DNS, нужна инфраструктура плоского распознавания, которая может быть реализована на основе распределенных хэш-таблиц, но это потребует новых разработок и развёртывания.

Благодарности

Люди, участвовавшие в ранних этапах разработки HIP, перечислены в разделе благодарностей спецификации HIP. На финальных этапах подготовки этого документа, когда редактором стал Pekka Nikander, бесценны были комментарии ранних разработчиков и других людей, включая Jari Arkko, Jeff Ahrenholz, Tom Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, Sasu Tarkoma, Jorma Wall. Спасибо также Lars Eggert, Spencer Dawkins, Dave Crocker, Erik Giesa за полезные комментарии.

Авторы выражают особую благодарность Tom Henderson, взявшему на себя задачи редактирования документа в ответ на комментарии IESG, когда оба автора были заняты другими делами. Без его настойчивости документ не достиг бы уровня RFC 4423.

Основная работа по обновлению и продвижению HIP в рамках процесса IETF была проделана несколькими командами разработчиков HIP. Авторы признательны компании Boeing, Helsinki Institute for Information Technology (HIIT), NomadicLab из Ericsson и трём университетам – RWTH Aachen, Aalto, University of Helsinki за их усилия. Без коллективной работы протокол HIP засох бы на лозе IETF как прекрасная концепция.

Спасибо также Suvi Koskinen за помощь в корректуре и джунглях ссылок.

Адреса авторов

Robert Moskowitz (editor)

HTT Consulting

Oak Park, Michigan

United States of America

Email: rgm@labs.htt-consult.com

Miika Komu

Ericsson

Hirsalantie 11

FI-02420 Jorvas

Finland

Email: miika.komu@ericsson.com


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1В оригинале применяется термин internetworking – межсетевой.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Denial-of-service – отказ в обслуживании.

5Encapsulating Security Payload – инкапсуляция данных защиты.

6Man-in-the-middle – перехват и изменение пакетов в пути с участием человека.

7Overlay Routable Cryptographic Hash Identifier – идентификатор наложенного маршрутизируемого криптографического хэша.

Рубрика: RFC | Оставить комментарий

RFC 8999 Version-Independent Properties of QUIC

image_print
Internet Engineering Task Force (IETF)                        M. Thomson
Request for Comments: 8999                                       Mozilla
Category: Standards Track                                       May 2021
ISSN: 2070-1721

Version-Independent Properties of QUIC

Независимые от версии свойства QUIC

PDF

Аннотация

Этот документ определяет свойства транспортного протокола QUIC, общие для всех версий протокола.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8999.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Абстрактное описание QUIC

QUIC – это ориентированный на соединения протокол взаимодействия двух конечных точек. Эти точки обмениваются дейтаграммами UDP. дейтаграммы UDP содержат пакеты QUIC. Конечные точки QUIC используют пакеты QUIC для организации соединения QUIC, которое является общим состоянием для этих конечных точек.

2. Фиксированные свойства всех версий QUIC

В дополнение к защищённому мультиплексируемому транспорту QUIC [QUIC-TRANSPORT] протокол позволяет согласовать версию. Это позволяет протоколу меняться с течением времени в соответствии с новыми требованиями. Многие характеристики протокола могут меняться в разных версиях. В этом документе описано подмножество QUIC, которое предназначено оставаться стабильным в новых версиях по мере их разработки и развёртывания. Все эти инварианты не зависят от версии IP. Основной целью этого документа является обеспечение возможности развёртывания новых версий QUIC. Описывая неизменные свойства, этот документ направлен на сохранение возможности ключевых точек QUIC согласовать изменения любого другого аспекта протокола. В результате это гарантирует минимальный объем информации, доступной кому-либо кроме конечных точек. Если это явно не запрещено данным документом, любые аспекты протокола могут меняться в разных версиях.

В Приложении A приведён список некоторых некорректных допущения, которые могут быть сделаны на основе сведений о QUIC версии. Это не относится к другим версиям QUIC.

3. Соглашения и определения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Этот документ определяет требования к будущим версиям QUIC, хотя нормативный язык здесь не применяется. В документе используются термины и соглашения о нотации из [QUIC-TRANSPORT].

4. Соглашения о нотации

Формат пакетов описывается с использованием определённой здесь нотации, которая совпадает с применяемой в [QUIC-TRANSPORT].

Составные поля указываются именем, а затем следует список полей в фигурных скобках через запятые. Отдельные поля включают сведения о размере, а также указания о фиксированном значении, необязательности или повторах. Для полей применяются указанные ниже обозначения (размеры задаются в битах).

x (A)

Поле x размером A битов.

x (A..B)

Указывает, что x может иметь любой размер от A до B, если A не указано, поле может иметь размер 0, отсутствие B говорит, что размер поля не ограничен. Значения в этом формате всегда завершаются на границе байта.

x (L) = C

Указывает, что x имеет фиксированное значение C, размером L в одной из приведённых выше форм.

x (L) …

Указывает повторение x (возможно пустой набор), где каждый экземпляр имеет размер L.

В документе применяется сетевой порядок байтов (big endian), поля указываются со старшего бита в каждом байте.

Отдельные поля составного поля указываются с именем составного поля. На рисунке 1 представлен пример.

   Example Structure {
     One-bit Field (1),
     7-bit Field with Fixed Value (7) = 61,
     Arbitrary-Length Field (..),
     Variable-Length Field (8..24),
     Repeated Field (8) ...,
   }

Рисунок 1. Пример формата.


5. Пакеты QUIC

Конечные точки QUIC обмениваются дейтаграммами UDP, содержащими один или несколько пакетов QUIC. В этом разделе описаны инвариантные характеристики пакетов QUIC. Версия QUIC может разрешать включение множества пакетов QUIC в одну дейтаграмму UDP, но инвариантные свойства описывают лишь первый пакет в дейтаграмме.

QUIC определяет два типа заголовка в пакетах – длинный и короткий. Пакеты с длинным заголовком указываются установкой (1) старшего бита в первом байте пакета, в коротких заголовках этот бит сброшен (0).

В пакетах QUIC может применяться защита целостности пакета, включая заголовок. Однако для пакетов QUIC Version Negotiation защита целостности не применяется (см. раздел 6).

Помимо описанных здесь значений содержимое (payload) пакетов QUIC зависит от версии и имеет произвольный размер.

5.1. Длинный заголовок

Формат длинного заголовка показан на рисунке 2.

   Long Header Packet {
     Header Form (1) = 1,
     Version-Specific Bits (7),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
     Version-Specific Data (..),
   }

Рисунок 2. Длинный заголовок QUIC.


В пакете QUIC с длинным заголовком старший бит первого байта имеет значение 1. Остальные биты этого байта зависят от версии. Следующие 4 байта образуют 32-битовое поле Version, описанное в параграфе 5.4. Следующий байт указывает размер следующего за ним поля Destination Connection ID (в байтах). Размер представлен 8-битовым целым числом без знака. Поле Destination Connection ID следует за Destination Connection ID Length и имеет размер от 0 до 255 байтов. Идентификаторы соединений описаны в параграфе 5.3. В следующем байте указан размер поля Source Connection ID, расположенного вслед за ним. Размер представлен 8-битовым целым числом без знака. Поле Source Connection ID следует за Source Connection ID Length и имеет размер от 0 до 255 байтов.

Остальная часть пакета зависит от версии.

5.2. Короткий заголовок

Формат короткого заголовка показан на рисунке 3.

   Short Header Packet {
     Header Form (1) = 0,
     Version-Specific Bits (7),
     Destination Connection ID (..),
     Version-Specific Data (..),
   }

Рисунок 3. Короткий заголовок QUIC.


В пакетах QUIC с коротким заголовком старший бит первого байта имеет значение 0. Пакет QUIC с коротким заголовком включает Destination Connection ID сразу за первым байтом. Короткий заголовок не содержит полей Destination Connection ID Length, Source Connection ID Length, Source Connection ID, Version. Размер Destination Connection ID не указывается в пакетах с коротким заголовком и не ограничивается этой спецификацией.

Остальная часть пакета зависит от версии.

5.3. Идентификатор соединения

Идентификатор соединения представляет собой неанализируемое (opaque) поле произвольного размера. Основным назначением идентификаторов соединения является предотвращение доставки пакетов в соединении QUIC не той конечной точке в случае смены адреса на нижележащих уровнях (UDP, IP и ниже). Идентификаторы соединения используются конечными точками и промежуточными узлами для гарантированной доставки каждого пакета QUIC корректному экземпляру конечной точки. В конечной точке идентификатор соединения служит для указания соединения QUIC, которому предназначен пакет.

Каждая конечная точка выбирает идентификаторы соединения с использованием зависящих от версии методов. Пакеты одного соединения QUIC могут использовать разные значения идентификаторов соединения.

5.4. Версия

Поле Version содержит 4-байтовый идентификатор, который может применяться конечными точками для указания версии QUIC. Поле Version = 0x00000000 зарезервировано для согласования версии (см. раздел 6), все остальные значения могут быть действительными.

Описанные в этом документе свойства применимы ко всем версиям QUIC. Протокол, не соответствующий описанным в этом документе свойствам, не является QUIC. В будущих документах могут описываться другие свойства, применимые к конкретной версии или диапазону версий QUIC.

6. Согласование версий

Конечная точка QUIC, получившая пакет с длинным заголовком и версией, которую она не понимает или не поддерживает, может передать в ответ пакет Version Negotiation. Пакеты с коротким заголовком не вызывают согласования версии.

В пакете Version Negotiation установлен (1) старший бит первого байта, задающий длинный заголовок, как описано в параграфе 5.1. Пакет Version Negotiation идентифицируется в качестве такового по полю Version = 0x00000000.

   Version Negotiation Packet {
     Header Form (1) = 1,
     Unused (7),
     Version (32) = 0,
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
     Supported Version (32) ...,
   }

Рисунок 4. Пакет согласования версии.


В первом байте пакета Version Negotiation определено значение лишь старшего бита (1), а остальные 7 битов, помеченные как Unused, могут иметь любые значения при передаче и должны игнорироваться получателем.

После поля Source Connection ID в пакете Version Negotiation содержатся пола Supported Version, каждое из которых указывает версию, поддерживаемую отправившей пакет конечной точкой. Других полей пакет Version Negotiation не содержит. Конечная точка должна игнорировать пакет без поля Supported Version или с усечённым полем. Для пакетов Version Negotiation не обеспечивается защиты целостности и конфиденциальности. Конкретные версии QUIC могут включать элементы протокола, позволяющие конечным точкам обнаруживать изменение или повреждения списка поддерживаемых версий.

Конечная точка должна включать значение Source Connection ID из полученного пакета в поле Destination Connection ID. Значение Source Connection ID должно копироваться из поля Destination Connection ID в полученном пакете, которое исходно клиент задаёт случайным. Указание обоих идентификаторов соединения даёт клиенту некоторую уверенность в том, что сервер получил пакет, а пакет Version Negotiation не создан злоумышленником, способным наблюдать пакеты.

Получившая пакет Version Negotiation конечная точка может сменить версию для последующих пакетов. Условия смены конечной точкой версии QUIC зависят от выбираемой версии.

В документе [QUIC-TRANSPORT] приведено более подробное описание генерации и использования пакетов Version Negotiation конечной точкой, поддерживающей QUIC версии 1.

7. Вопросы безопасности и приватности

Возможны ситуации, когда промежуточные устройства способны видеть черты конкретной версии QUIC и предполагать ту же семантику, когда другая версия QUIC демонстрирует аналогичные черты. Таких черт может быть много, см. Приложение A. Были предприняты попытки устранить или скрыть наблюдаемые черты в QUIC версии 1, но многие из них остались. В других версиях QUIC могут применяться иные решения и проявляться другие черты.

Номер версии QUIC не указывается в пакетах QUIC, что означает необходимость сохранение на промежуточных устройствах состояния для каждого видимого идентификатора соединения, чтобы надёжно извлечь информацию из потока на основе наблюдаемых черт версии.

Описанный в этом документе пакет Version Negotiation не имеет защиты целостности и лишь слегка защищён от злоумышленников. Конечная точка должна проверять подлинность смыслового содержимого Version Negotiation, если она пытается в результате сменить версию QUIC.

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Дополнительная литература

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., “Using TLS to Secure QUIC”, RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC5116] McGrew, D., “An Interface and Algorithms for Authenticated Encryption”, RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.

Приложение A. Некорректные допущения

Имеются некоторые черты QUIC версии 1 [QUIC-TRANSPORT], не защищённые от наблюдения, но тем не менее, считающиеся изменяемыми в новых версиях. В этом приложении приведены примеры некорректных допущений, которые могут быть приняты на основе сведений о QUIC версии 1. Некоторые из приведённый утверждений неверны даже для QUIC версии 1. Список не является полным и служит лишь иллюстрацией. Любое из приведённых ниже утверждений может быть ошибочным для конкретной версии QUIC.

  • QUIC использует TLS [QUIC-TLS] и некоторые сообщения TLS видимы в линии.

  • Длинные заголовки QUIC передаются лишь при организации соединения.

  • Каждый поток данного квинтета (5-tuple) включает фазу организации соединения.

  • Первые пакеты в потоке используют длинный заголовок.

  • Можно предположить, что последний поток перед долгим бездействием содержит лишь подтверждение.

  • QUIC использует функцию аутентифицированного шифрования со связанными данными (Authenticated Encryption with Associated Data или AEAD) AEAD_AES_128_GCM [RFC5116] для защиты пакетов в процессе организации соединения.

  • Номера пакетов QUIC шифруются и указываются в первых шифрованных байтах.

  • Номера пакетов QUIC увеличиваются на 1 в каждом передаваемом пакете.

  • QUIC устанавливает минимальный размер для первого пакета согласования, передаваемого клиентом.

  • QUIC требует, чтобы соединение инициировал (начинал «говорить») клиент.

  • В пакетах QUIC второй бит первого байта (0x40) всегда установлен (1).

  • Пакеты QUIC Version Negotiation передаёт только сервер.

  • Идентификаторы соединения QUIC меняются нечасто.

  • Конечные точки QUIC меняют применяемую версию, если передан пакет Version Negotiation.

  • Поле Version в пакетах QUIC с длинным заголовком одинаково для обоих направлений.

  • Пакет QUIC с определенным значением поля Version означает использование соответствующей версии QUIC.

  • Между парой взаимодействующих конечных точек QUIC в каждый момент имеется лишь одно соединение.

Адрес автора

Martin Thomson

Mozilla

Email: mt@lowentropy.net


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

Рубрика: RFC | Оставить комментарий

RFC 9002 QUIC Loss Detection and Congestion Control

image_print
Internet Engineering Task Force (IETF)                   J. Iyengar, Ed.
Request for Comments: 9002                                        Fastly
Category: Standards Track                                  I. Swett, Ed.
ISSN: 2070-1721                                                   Google
                                                                May 2021

QUIC Loss Detection and Congestion Control

Обнаружение потерь и контроль перегрузок в QUIC

PDF

Аннотация

Этот документ описывает механизмы обнаружения потерь и контроля перегрузки для QUIC.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9002.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

QUIC является защищенным транспортным протоколом общего назначения, описанным в [QUIC-TRANSPORT]. Этот документ описывает механизмы обнаружения потерь и контроля перегрузок в QUIC.

2. Соглашения и определения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Ниже приведены определения используемых в документе терминов.

Ack-eliciting frames – кадры с запросом подтверждения

Все кадры, кроме ACK, PADDING, CONNECTION_CLOSE, считаются запрашивающими подтверждение.

Ack-eliciting packets – пакеты с запросом подтверждения

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

In-flight packets – пакеты в пути

Пакеты считаются находящимися в пути (на лету – in flight), когда они запрашивают подтверждение или содержат кадр PADDING и были переданы, но ещё не подтверждены, не объявлены потерянными и не отброшены со старыми ключами.

3. Устройство машины передачи QUIC

Во всех передачах QUIC используется заголовок на уровне пакета, указывающий уровень шифрования и включающий порядковый номер пакета. Уровень шифрования указывает пространство порядковых номеров, как описано в параграфе 12.3 [QUIC-TRANSPORT]. Номера пакетов в одном пространстве не повторяются в течение работы соединения. Номера передаваемых пакетов монотонно увеличиваются для предотвращения неоднозначности. Допускается пропуск некоторых номеров.

Такой подход избавляет от неоднозначностей при повторной передаче пакета и устраняет в QUIC сложности обнаружения потери пакетов, присущие механизмам TCP.

Пакеты QUIC могут содержать несколько кадров различных типов. Механизмы восстановления обеспечивают для кадров и данных, требующих гарантированной доставки, подтверждение или обнаружение потери с повтором передачи в новом пакете. Типы кадров в пакете влияют на логику восстановления и контроля перегрузок.

  • Все пакеты подтверждаются, хотя пакеты с кадрами, не запрашивающими подтверждения, подтверждаются лишь вместе с запросившими подтверждение пакетами.

  • Пакеты с длинным заголовком, содержащие кадры CRYPTO, критически важны для производительности согласования QUIC и для них заданы короткие таймеры подтверждения.

  • Пакеты, содержащие кадры помимо ACK или CONNECTION_CLOSE, учитываются в ограничениях контроля перегрузки и считаются находящимися в пути.

  • Кадры PADDING заставляют учитывать пакеты в числе находящихся в пути, не вызывая напрямую отправки подтверждений.

4. Важные различия между QUIC и TCP

Читатели, знакомые с алгоритмами обнаружения потерь и контроля перегрузок в TCP, найдут здесь похожие функции. Однако между QUIC и TCP вносят свой вклад и в различия алгоритмов, кратко описанные в этом разделе.

4.1. Раздельные пространства порядковых номеров

QUIC использует своё пространство порядковых номеров для каждого уровня шифрования, за исключением того, что 0-RTT и все варианты ключей 1-RTT находятся в одном пространстве номеров. Раздельные пространства номеров гарантируют, что подтверждения пакетов с одним уровнем шифрования не вызовут ложных повторов пакетов с другим уровнем шифрования. Контроль перегрузок и измерение времени кругового обхода (round-trip time или RTT) являются одинаковыми во всех пространствах номеров.

4.2. Монотонный рост порядковых номеров

TCP объединяет порядок передачи отправителем с порядком приёма получателем, что ведёт к неоднозначности повтора передачи [RETRANSMISSION]. QUIC отделяет порядок передачи от порядка доставки. Номера пакетов указывают порядок передачи а порядок доставки определяется смещением потока в кадрах STREAM.

Номера пакетов QUIC строго возрастают в пространстве номеров и напрямую кодируют порядок отправки. Больший номер означает более позднюю передачу пакета, а меньший – более раннюю. При обнаружении потери пакета с запрашивающими подтверждение кадрами QUIC включает требуемые кадры в новый пакет с новым порядковым номером, устраняя неоднозначность в отношении подтверждаемых пакетов при получении ACK. Это позволяет более точно измерить RTT, легко обнаруживать ложные повторы передачи и возможность повсеместного применения таких механизмов, как Fast Retransmit (ускоренный повтор), на основе лишь номеров пакетов.

Такой подход существенно упрощает механизмы обнаружения потерь в QUIC. Большинство механизмов TCP неявно пытаются определить порядок передачи на основе порядковых номеров TCP, что является нетривиальной задачей особенно при недоступности временных меток TCP.

4.3. Более чёткая эпоха потерь

QUIC начинает эпоху потерь при обнаружении потери и завершает её при подтверждении любого пакета, переданного после начала эпохи. TCP ожидает заполнения пропуска в пространстве порядковых номеров, поэтому при потере нескольких сегментов подряд эпоха потерь может не завершиться в течение нескольких интервалов кругового обхода. Поскольку обоим протоколам следует уменьшать окно перегрузки лишь 1 раз в течение эпохи потерь, QUIC будет делать это один раз в течение кругового обхода, в котором были потери, а TCP может делать это 1 раз за несколько RTT.

4.4. Неотказуемость подтверждений

Кадры QUIC ACK содержат сведения, аналогичные содержащимся в селективных подтверждениях TCP (Selective Acknowledgment или SACK) [RFC2018]. Однако QUIC не позволяет отозвать подтверждение пакета, что существенно упрощает реализацию обеих сторон и расход памяти у отправителя.

4.5. Больше диапазонов ACK

QUIC поддерживает множество диапазонов ACK в отличие от трёх диапазонов SACK в TCP. В среде с высокими потерями это ускоряет восстановление, предотвращает ложные повторы и гарантирует «продвижение вперёд» без опоры на тайм-ауты.

4.6. Явная корректировка для задержанных подтверждений

Конечные точки QUIC измеряют задержку между приёмом пакета и отправкой соответствующего подтверждения, что позволяет партнёру более точно оценить RTT (см. параграф 13.2 в [QUIC-TRANSPORT]).

4.7. Тайм-аут зондов взамен RTO и TLP

QUIC использует тайм-аут проб (probe timeout или PTO, см. параграф 6.2) с таймером на основе расчёта тайм-аута повтора TCP (retransmission timeout или RTO, см. [RFC6298]). QUIC PTO включает максимальную ожидаемую задержку у партнёра вместо фиксированного минимального тайм-аута.

Как алгоритм обнаружения потерь RACK-TLP для TCP [RFC8985], QUIC не сокращает окно перегрузки по истечении PTO, поскольку потеря одного пакета в конце не указывает на постоянную перегрузку. Взамен QUIC сжимает окно перегрузки, когда объявляется сохраняющаяся перегрузка (см. параграф 7.6). Таким способом QUIC предотвращает неоправданное сужение окна перегрузки, избавляясь от потребности в механизмах корректировки, таких как F-RTO (Forward RTO-Recovery) [RFC5682]. Поскольку QUIC не сокращает окно перегрузки по истечении PTO, отправитель QUIC не ограничен в передаче дополнительных пакетов, остающихся в пути по истечении PTO, если окно перегрузки не препятствует. Это происходит, когда отправитель ограничен приложением и PTO истекает. Это более энергичное поведение по сравнению с TCP RTO, когда приложение ограничено, но идентично ему, если нет ограничения.

QUIC позволяет пакетам зондирования временно выходить за пределы окна перегрузки по завершении таймера.

4.8. Минимальное окно перегрузки в 2 пакета

TCP использует минимальное окно перегрузки в 1 пакет. Однако потеря единственного пакета означает, что для восстановления отправитель должен ждать в течение PTO (параграф 6.2), что может быть много больше RTT. Отправка одного пакета с запросом подтверждения также повышает шансы дополнительной задержки при задержке подтверждения получателем.

Поэтому QUIC рекомендует окно перегрузки в 2 пакета. Хотя это повышает нагрузку на сеть, такой выбор считается безопасным, поскольку отправитель будет экспоненциально снижать скорость передачи при возникновении перегрузки (параграф 6.2).

4.9. Пакеты согласования не являются особыми

TCP считает потерю пакета SYN или SYN-ACK сохраняющейся перегрузкой и снижает размер окна перегрузки до одного пакета [RFC5681]. QUIC считает потерю пакета с данными согласования обычной потерей.

5. Оценка RTT

На высоком уровне конечная точка измеряет время между отправкой пакета и его подтверждением как выборку RTT. Конечная точка использует выборки RTT и полученные от партнёра задержки на хосте (см. параграф 13.2 в [QUIC-TRANSPORT]) для статистического описания RTT на сетевом пути. Конечная точка рассчитывает для каждого пути минимальное значение RTT за период времени (min_rtt), экспоненциально взвешенное среднее значение (smoothed_rtt) и среднее отклонение (variation) наблюдаемых выборок RTT (rttvar).

5.1. Генерация выборок RTT

Конечная точка создаёт выбору RTT при получении кадра ACK, соответствующего двум условиям:

  • наибольший подтверждённый порядковый номер недавно подтверждён;

  • хотя бы один из недавно подтверждённых пакетов запрашивал подтверждение (ack-eliciting).

Выборка RTT (latest_rtt) определяется временем с момента отправки подтверждённого пакета с наибольшим номером

   latest_rtt = ack_time - send_time_of_largest_acked

Выборка RTT создаётся с использованием лишь подтверждённого пакета с наибольшим номером в полученном кадре ACK. Это обусловлено тем, что партнёр сообщает задержку подтверждения в кадре ACK лишь для пакета с наибольшим номером. Хотя сообщённая задержка не применяется при измерении RTT, она используется для корректировки выборки RTT в последующих расчётах smoothed_rtt и rttvar (параграф 5.3).

Для предотвращения множественной выборки RTT на один пакет кадр ACK не следует использовать для обновления оценок RTT, если он не является новым подтверждением подтверждённого пакета с наибольшим номером.

Выборку RTT недопустимо создавать при получении кадра ACK который не подтверждает хотя бы один пакет ack-eliciting. Партнёр обычно не передаёт кадр ACK, пока приняты лишь пакеты не требующие подтверждения. Поэтому кадр ACK с подтверждениями лишь не запрашивающих подтверждения пакетов может включать произвольно большое значение ACK Delay. Игнорирование таких кадров ACK предотвращает усложнение последующих расчётов smoothed_rtt и rttvar.

Отправитель может создавать несколько выборок RTT в течение RTT, когда получает в течение этого интервала несколько кадров ACK. Как отмечено в [RFC6298], это может приводить к неадекватной истории smoothed_rtt и rttvar. Обеспечение достаточной истории оценки RTT требует дальнейшего исследования.

5.2. Оценка min_rtt

Значение min_rtt указывает оценку отправителем минимального интервала RTT, наблюдавшегося для данного пути через сеть в течение определённого времени. В этом документе min_rtt используется механизмом обнаружения потерь для отклонения неправдоподобно малых выборок RTT.

В качестве min_rtt должно устанавливаться значение latest_rtt из первой выборки RTT. Значение min_rtt должно быть меньшим из min_rtt и latest_rtt (параграф 5.1) среди всех других измерений.

Конечная точка использует лишь локально измеряемое время при расчёте min_rtt и не учитывает задержку подтверждения, сообщённую партнёром. Это позволяет конечной точке установить нижнюю границу smoothed_rtt исключительно на основе своих наблюдений (см. параграф 5.3) и ограничит возможную недооценку, связанную с ошибочными сведениями о задержках от партнёра.

RTT для пути через сеть может меняться со временем. Если фактическое значение RTT для пути уменьшается, min_rtt корректируется незамедлительно по первой меньшей выборке. Если же RTT растёт, min_rtt не корректируется, позволяя включать будущие выборки RTT, которые меньше нового RTT, в расчёт smoothed_rtt.

Конечным точкам следует устанавливать в min_rtt новейшую выборку RTT после возникновения устойчивой перегрузки. Это предотвращает периодическое объявление сохраняющейся перегрузки при увеличении RTT, а также позволяет сбрасывать оценки min_rtt и smoothed_rtt после серьёзных нарушения в сети (см. параграф 5.3).

Конечные точки могут заново установить min_rtt в другой момент соединения, например, при малом объёме трафика и получении подтверждений с малой задержкой. Реализациям не следует обновлять min_rtt слишком часто, поскольку фактический минимум RTT на пути наблюдается нечасто.

5.3. Оценка smoothed_rtt и rttvar

Значение smoothed_rtt указывает экспоненциально взвешенное скользящее среднее значение выборки RTT конечной точкой, в rttvar — вариации в выборках RTT с использованием среднего отклонения.

В расчёте smoothed_rtt используются выборки RTT после их корректировки на основе задержки подтверждения. Эти задержки извлекаются из поля ACK Delay в кадрах ACK, как описано в параграфе 19.3 [QUIC-TRANSPORT]. Партнёр может сообщать о задержках подтверждения, превышающих max_ack_delay у него при согласовании (параграф 13.2.1 в [QUIC-TRANSPORT]). Для учёта этого конечной точке следует игнорировать max_ack_delay, пока согласование не подтверждено, как указано в параграфе 4.1.2 [QUIC-TLS]. Когда это произойдёт, такие большие задержки подтверждения вероятно не будут повторяться. Следовательно, конечная точка может использовать задержки подтверждения, не ограничивая их значением max_ack_delay и избегая ненужной переоценки RTT.

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

После завершения согласования все значения задержки подтверждения от партнёра, превышающие его max_ack_delay, считаются непреднамеренными, но возможно повторяющимися задержками, такими как задержка в планировщике у партнёра или задержка предыдущих подтверждений. Избыточные задержки могут быть также связаны с несоответствием получателя. Поэтому такие задержки считаются частью задержки в пути и учитываются в RTT. При корректировке RTT с учётом полученной от партнёра задержки подтверждения конечная точка:

  • может игнорировать задержку подтверждения для пакетов Initial, поскольку эти подтверждения партнёр не задерживает (параграф 13.2.1 в [QUIC-TRANSPORT]);

  • следует игнорировать max_ack_delay у партнёра, пока согласование не подтверждено;

  • должна использовать меньшее из значений задержки подтверждения и max_ack_delay у партнёра после подтверждения согласования;

  • недопустимо вычитать задержку подтверждения из RTT , если это даёт значение меньше min_rtt (это ограничивает недооценку smoothed_rtt при ошибках партнёра.).

Кроме того, конечная точка может отложить обработку подтверждений, когда соответствующие ключи расшифровки недоступны. Например, клиент может получить подтверждение для пакета 0-RTT, которое он не может расшифровать, поскольку ключи расшифровки пакетов 1-RTT ещё недоступны. В таких случаях конечной точке следует вычитать локальную задержку из выборки RTT, пока согласование не подтверждено.

Подобно [RFC6298], значения smoothed_rtt и rttvar рассчитываются в соответствии с приведённым ниже описанием.

Конечная точка инициализирует измеритель RTT в процессе организации соединения и при его сбросе во время переноса соединения (см. параграф 9.4 в [QUIC-TRANSPORT]). До того как выборки RTT для нового пути станут доступны или при сбросе измерителя этот измеритель инициализируется с использованием начального RTT (см. параграф 6.2.2). Значения smoothed_rtt и rttvar инициализируются, как показано ниже (kInitialRtt содержит исходное значение RTT).

   smoothed_rtt = kInitialRtt
   rttvar = kInitialRtt / 2

Выборки RTT для сетевого пути записываются в latest_rtt (см. параграф 5.1). При первой выборке RTT после инициализации измеритель сбрасывается с использованием этой выборки. Это обеспечивает исключение истории прошлых измерений. Пакеты, переданные по другому пути, не учитываются в выборке RTT на текущем пути, как указано в параграфе 9.4 [QUIC-TRANSPORT]. При первой выборке RTT после инициализации значения smoothed_rtt и rttvar устанавливаются, как показано ниже.

   smoothed_rtt = latest_rtt
   rttvar = latest_rtt / 2

При последующих выборках RTT значения smoothed_rtt и rttvar вычисляются в соответствии с псевдокодом.

   ack_delay = decoded acknowledgment delay from ACK frame
   if (handshake confirmed):
     ack_delay = min(ack_delay, max_ack_delay)
   adjusted_rtt = latest_rtt
   if (latest_rtt >= min_rtt + ack_delay):
     adjusted_rtt = latest_rtt - ack_delay
   smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
   rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
   rttvar = 3/4 * rttvar + 1/4 * rttvar_sample

6. Обнаружение потерь

Отправители QUIC используют подтверждения для обнаружения потери пакетов и PTO для гарантии получения подтверждений (см. параграф 6.2). В этом разделе приведено описание алгоритмов.

Если пакет потерян транспорту QUIC требуется восстановить потерю, например, путём повторной передачи данных, отправки обновлённого кадра или отбрасывания кадра (см. параграф 13.3 в [QUIC-TRANSPORT]). Обнаружение потерь происходит раздельно в каждом пространстве номеров в отличие от измерения RTT и контроля перегрузки, поскольку те являются свойствами пути, а обнаружение потерь связано с доступностью ключей.

6.1. Обнаружение на основе подтверждений

Обнаружение потерь на основе подтверждения реализует дух механизмов TCP Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward Acknowledgment [FACK], восстановление потерь SACK [RFC6675] и RACK-TLP [RFC8985]. В этом параграфе представлен обзор реализации этих алгоритмов в QUIC.

Пакет считается потерянным при выполнении всех приведённых ниже условий.

  • Пакет не подтверждён, находится в пути и был послан до подтверждённого пакета.

  • Пакет был передан на kPacketThreshold пакетов раньше подтверждённого пакета (параграф 6.1.1) или достаточно давно (параграф 6.1.2).

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

Ложное объявление пакетов потерянными ведёт к ненужным повторам передачи и может снижать производительность в результате реакции механизма контроля перегрузок на потерю. Реализации могут обнаруживать ложные повторы и повышать пороги изменения порядка по пакетами или времени для снижения в будущем ложных повторов и фиксации потерь. Реализации с адаптивными временными порогами могут запускаться с меньшим начальным порогом нарушения порядка для минимизации задержки восстановления.

6.1.1. Порог по пакетам

Рекомендуемое для начального порога разупорядочения пакетов (kPacketThreshold) значение 3 выбрано на основе опыта обнаружения потерь TCP [RFC5681] [RFC6675]. Для сохранения сходства с TCP реализациям не следует использовать порог меньше 3 [RFC5681].

В некоторых сетях разупорядочение пакетов может быть более сильным, что ведёт к ложному обнаружению потерь отправителем. Кроме того, разупорядочение пакетов в QUIC встречается чаще, чем в TCP, поскольку элементы сети, способные наблюдать и менять порядок пакетов TCP, не могут делать этого для QUIC, так как номера пакетов QUIC зашифрованы. Алгоритмы, повышающие порог разупорядочения после ложного обнаружения потерь (такие как RACK [RFC8985]), оказались полезными в TCP и предполагается, что они будут не менее полезны в QUIC.

6.1.2. Порог по времени

Как только будет подтверждён самый поздний пакет в том же пространстве номеров, конечной точке следует объявить потерю более раннего пакета, если он был передан в течение заданного порогом интервала в прошлом. Для предотвращения слишком раннего обновления пакетов потерянными этот порог должен быть не меньше дискретности локального таймера, заданной параметром kGranularity.

   max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)

Если пакеты, переданные до подтверждённого пакета с наибольшим номером, ещё не могут быть объявлены потерянными, таймер следует установить на оставшееся время. Использование max(smoothed_rtt, latest_rtt) защищает от двух случаев:

  • последняя выборка RTT меньше сглаженного RTT (возможно из-за разупорядочения, когда подтверждение пошло по более короткому пути);

  • последняя выборка RTT больше сглаженного RTT (возможно из-за устойчивого роста фактического RTT, когда сглаженное значение RTT ещё отстаёт).

Рекомендуемый порог по времени (kTimeThreshold) составляет 9/8 RTT, рекомендуемая дискретность таймера (kGranularity) – 1 мсек.

Примечание. TCP RACK [RFC8985] задаёт несколько больший порог, эквивалентный 5/4. Опыт работы с QUIC показывает, что порог 9/8 подходит лучше.

Реализации могут экспериментировать с абсолютными порогами, порогами из прежних соединений, адаптивными порогами или включением вариаций RTT. Меньший порог снижает устойчивость к разупорядочению и увеличивает число ложных повторов передачи, а больший повышает задержку обнаружения потерь.

6.2. Тайм-аут для зондов

Тайм-аут зондирования (Probe Timeout или PTO) вызывает отправку одной или двух пробных дейтаграмм, когда запросившие подтверждение пакеты не подтверждаются в течение ожидаемого интервала или сервер не может проверить адрес клиента. PTO позволяет восстанавливать соединение после потери «хвостовых» пакетов или подтверждений.

Как и в случае обнаружения потерь, PTO определяется по пространствам номеров пакетов, т. е. рассчитывается отдельно в каждом пространстве.

Завершение отсчёта таймера PTO не говорит о потере пакета и по этому событию недопустимо считать ранее неподтвержденные пакеты потерянными. При получении повторного подтверждения обнаружение потерь продолжается в соответствии с порогами для числа пакетов и времени, как описано в параграфе 6.1.

Алгоритм PTO в QUIC реализует функции алгоритмов Tail Loss Probe [RFC8985], RTO [RFC5681] и F-RTO для протокола TCP [RFC5682]. Расчёт тайм-аута основан на интервале TCP RTO [RFC6298].

6.2.1. Расчёт PTO

При передаче запрашивающего подтверждение пакета отправитель устанавливает таймер PTO

   PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay

Интервал PTO задаёт время, в течение которого отправитель должен ждать подтверждения переданного пакета. Это время включает оценку RTT в сети (smoothed_rtt), вариации оценки (4*rttvar) и max_ack_delay для учёта максимального времени, на которое получатель может задержать отправку подтверждения.

При установке PTO для пространств номеров пакетов Initial или Handshake, для max_ack_delay при расчёте PTO принимается значение 0, поскольку ожидается немедленное подтверждение этих пакетов получателем (см. параграф 13.2.1 в [QUIC-TRANSPORT]).

Интервал PTO должен быть не меньше kGranularity во избежание немедленного завершения отсчёта.

Когда пакеты с запросом подтверждения их нескольких пространств номеров находятся в сети, таймер должен устанавливаться на более раннее значение из пространств номеров Initial и Handshake.

Конечной точке недопустимо устанавливать таймер PTO для пространства номеров данных приложения, пока согласование не подтверждено. Это предотвращает повторную передачу конечной точкой данных в пакетах, для которых у партнёра ещё нет ключей для обработки или подтверждения. Например, это может происходить, когда клиент передаёт серверу пакеты 0-RTT, не зная, может ли сервер расшифровать их. Это может происходить также при отправке сервером пакетов 1-RTT до подтверждения проверки клиентом сертификата сервера и возможности чтения пакетов 1-RTT.

Отправителю следует перезапускать таймер PTO при каждой отправке или подтверждении запросившего подтверждение пакета, а также при отбрасывании ключей Initial или Handshake (параграф 4.9 в [QUIC-TLS]). Это гарантирует установку PTO на основе последней оценки RTT и для нужного пространства номеров пакетов.

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

Такое экспоненциальное снижение скорости передачи отправителя важно, поскольку последовательные PTO могут быть вызваны потерей пакетов или подтверждений из-за серьёзной перегрузки. Даже при наличии в сети (in flight) пакетов из нескольких пространств номеров экспоненциальное увеличение PTO выполняется во всех пространствах для предотвращения чрезмерной нагрузки на сеть. Например, тайм-аут в пространстве номеров Initial удваивает продолжительность ожидания в пространстве номеров Handshake.

Общая продолжительность времени, в течение которого истекает срок последовательных PTO, ограничен тайм-аутом бездействия.

Установка таймера PTO недопустима, если установлен таймер для порога обнаружения потерь по времени (см. параграф 6.1.2). Таймер, установленный для порога обнаружения потерь по времени, будет завершаться в большинстве случаев раньше таймера PTO и вероятность ложного повтора данных будет меньше.

6.2.2. Согласование и новые пути

Возобновляемые в той же сети соединения могут использовать финальное сглаженное значение RTT из прежнего соединения в качестве начального RTT. Если прежнего значения RTT нет, в качестве начального RTT RTT следует устанавливать значение 333 мсек. Это ведёт к согласованию, начинающегося с PTO в 1 секунду, как рекомендовано для начального RTO в TCP (см. раздел 2 в [RFC6298]).

Соединение может использовать задержку между передачей PATH_CHALLENGE и приёмом PATH_RESPONSE для установки начального RTT (см. kInitialRtt в Приложении A.2) на новом пути, но не следует считать её выборкой RTT.

Когда ключи Initial и Handshake отброшены (параграф 6.4), никакие пакеты Initial и Handshake не могут быть подтверждены, поэтому они исключаются из числа байтов, находящихся в пути. При отбрасывании ключей Initial или Handshake таймеры PTO и обнаружения потерь должны сбрасываться, поскольку отбрасывание ключей указывает продвижение вперёд и таймер обнаружения потерь может быть установлен для пространства номеров, которые сейчас отброшены.

6.2.2.1. До проверки адреса

Пока сервер не проверил адрес клиента на пути, объем передаваемых им данных ограничен троекратным размером принятых данных, как указано в параграфе 8.1 [QUIC-TRANSPORT]. Если дополнительные данные не могут быть переданы, таймер PTO на сервере недопустимо активировать, пока не будут получены дейтаграммы от клиента, поскольку пакеты, передаваемые для PTO, учитываются в пороге антиусиления.

При получении сервером дейтаграммы от клиента порог антиусиления повышается и сервер сбрасывает таймер PTO. Если после этого таймер PTO будет установлен на прошлое время, он считается сработавшим сразу же. Это предотвращает передачу пакетов 1-RTT до пакетов, которые критически важны для согласования. В частности, это может происходить, когда сервер воспринимает 0-RTT, но не может подтвердить адрес клиента.

Поскольку сервер может быть заблокирован до приёма новых дейтаграмм от клиента, ответственность за отправку этих дейтаграмм ложится на клиента, пока у него не будет уверенности в том, что сервер завершил проверку его адреса (см. раздел 8 в [QUIC-TRANSPORT]). Т. е. клиент должен установить таймер PTO, если он не получил подтверждения какого-либо из своих пакетов Handshake и согласование не подтверждено (см. параграф 4.1.2 в [QUIC-TLS]), даже при отсутствии находящихся в пути пакетов. При срабатывании PTO клиент должен передать пакет Handshake при наличии ключей Handshake, в противном случае он должен передать пакет Initial в дейтаграмме UDP, содержимое (payload) которой не меньше 1200 байтов.

6.2.3. Ускоренное завершение согласования

При получении пакета Initial с дубликатом данных CRYPTO сервер может предположить, что клиент не получил все данные CRYPTO, переданные в пакетах Initial, или оценка RTT клиентом слишком мала. При получении клиентом пакетов Handshake или 1-RTT до обретения ключей Handshake он может предположить, что некоторые или все пакеты Initial от сервера были потеряны.

Чтобы ускорить завершение согласования в таких условиях, конечная точка может ограниченное число раз за соединение передать пакет с неподтвержденными данными CRYPTO до завершения PTO с учётом ограничений проверки адреса (параграф 8.1 в [QUIC-TRANSPORT]). Выполнения этого не более 1 раза для каждого соединения достаточно для быстрого восстановления при потере одного пакета. Конечная точка, всегда повторяющая пакеты в ответ на получение пакета, который она не может обработать, рискует создать бесконечный обмен пакетами.

Конечные точки могут также объединять пакеты (см. параграф 12.2 в [QUIC-TRANSPORT]), чтобы каждая дейтаграмма запрашивала хотя бы одно подтверждение. Например, клиент может объединить пакет Initial, содержащий кадры PING и PADDING, с пакетом данных 0-RTT, а сервер может объединить пакет Initial, содержащий кадр PING, с одним или несколькими пакетами в своей первой отправке.

6.2.4. Отправка пакетов зондирования

При завершении отсчёта таймера PTO отправитель должен передать в качестве зонда по меньшей мере один пакет с запросом подтверждения в пространстве номеров. Конечная точка может передать до 2 полноразмерных дейтаграмм с запрашивающими подтверждение пакетами для предотвращения дорогостоящих последовательных PTO в результате потери одной дейтаграммы или для передачи данных из нескольких пространств номеров. Все пробные пакеты, переданные в течение PTO должны запрашивать подтверждение.

В дополнение к передаче данных в пространстве номеров, для которого завершился отсчёт таймера, отправителю следует передать запрашивающие подтверждение пакеты из других пространств номеров с находящимися в пути данными, объединяя пакеты по возможности. Это особенно ценно при наличии у сервера находящихся в пути данных Initial и Handshake сразу или при наличии у клиента находящихся в пути данных Handshake и Application Data сразу, поскольку партнёр может иметь ключи приёма лишь для одного из двух пространств номеров.

Если отправитель хочет запросить быстрое подтверждение в интервале PTO, он может пропустить номер пакета для предотвращения задержки подтверждения.

Конечной точке следует включать новые данные в пакеты, передаваемые по истечении PTO. При отсутствии новых данных можно передать отправленные ранее. Реализации могут использовать дополнительную стратегию определения содержимого тестовых пакетов, включая отправку новых или повторных данных на основе приоритетов приложения.

У отправителя может не быть новых или уже отправленных данных для передачи. Рассмотрим в качестве примера последовательность событий: новые данные приложения переданы в кадре STREAM, эти данные сочтены потерянными, повторены в новом пакете, а затем исходна передача была подтверждена. Когда нет данных для передачи, отправителю следует передать PING или другой кадр с запросом подтверждения в одном пакете, снова запуская таймер PTO.

Вместо отправки запрашивающего подтверждение пакета отправитель может пометить любые остающиеся в пути пакеты как потерянные. Это позволяет избежать отправки дополнительного пакета, но повышает риск слишком активного объявления потерь, приводящего к неоправданному снижению скорости контроллером перегрузки.

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

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

6.3. Обработка пакетов Retry

Пакет Retry заставляет клиента передать новый пакет Initial, фактически запуская процесс соединения снова. Пакет Retry указывает, что пакет Initial был получен, но не обработан. Пакет Retry не может считаться подтверждением, поскольку он не говорит об обработке пакета и не задаёт порядковый номер.

Клиент, получающий пакет Retry, сбрасывает статус контроля перегрузок и восстановления потерь, включая сброс ожидающих таймеров. Другие состояния соединения, в частности, сообщения криптографического согласования, сохраняются (см. параграф 17.2.5 в [QUIC-TRANSPORT]).

Клиент может рассчитать RTT до сервера как интервал между отправкой первого пакета Initial и получением пакета Retry или Version Negotiation. Клиент может установить это значение вместо принятого по умолчанию начального RTT.

6.4. Отбрасывание ключей и состояние пакета

Когда ключи защиты пакетов Initial и Handshake отброшены (см. параграф 4.9 в [QUIC-TLS]), переданные с этими ключами пакеты не могут быть подтверждены, поскольку обработать подтверждения невозможно. Отправитель должен отбросить все состояния восстановления, связанные с этими пакетами, и должен исключить пакеты из числа находящихся в пути байтов.

Конечные точки останавливают передачу и приём пакетов Initial после начала обмена пакетами Handshake (см. параграф 17.2.2.1 в [QUIC-TRANSPORT]). В этот момент отбрасывается состояние восстановления для находящихся в пути пакетов Initial.

Когда данные 0-RTT отвергаются, состояния восстановления для находящихся в пути пакетов 0-RTT отбрасываются. Если сервер воспринимает 0-RTT, но не буферизует пакеты 0-RTT, прибывшие до пакетов Initial, ранние пакеты 0-RTT будут объявлены потерянными, но предполагается, что это будет происходить нечасто.

Предполагается, что ключи будут отброшены в течение некоторого времени после того, как все зашифрованным с ними пакеты будут подтверждены или объявлены потерянными. Однако секреты Initial и Handshake отбрасываются как только станут доступны ключи Handshake и 1-RTT для клиента и сервера (см. параграф 4.9.1 в [QUIC-TLS]).

7. Контроль перегрузки

В этом документе описано контроллер перегрузок на стороне отправителя QUIC, похожий на TCP NewReno [RFC6582]. Сигналы, предоставляемые протоколом QUIC для контроля перегрузок являются базовыми и предназначены для разных механизмов на стороне отправителя, который в одностороннем порядке может выбрать другой механизм, например CUBIC [RFC8312]. При использовании отправителем иного механизма, выбранный контроллер должен соответствовать рекомендациям параграфа 3.1 в [RFC8085].

Подобно TCP, пакеты, содержащие лишь кадры ACK не учитываются в числе находящихся в пути байтов и для них не применяется контроль перегрузки. Однако в отличие от TCP, QUIC может обнаруживать потери таких кадров и может использовать эти сведения для настройки контроллера перегрузки или скорости передачи пакетов, содержащих только ACK, но данный документ не описывает механизмов для этого.

Контроллер перегрузки работает на уровне пути, поэтому передаваемые по другому пути пакеты не влияют на контроллер текущего пути, как описано в параграфе 9.4 [QUIC-TRANSPORT]. Описанный в документе алгоритм задаёт и применяет окно перегрузки в контроллере, выраженное в байтах. Конечной точке недопустимо передавать пакеты, если это сделает значение bytes_in_flight (см. Приложение B.2) больше окна перегрузки, за исключением случаев отправки пакета по тайм-ауту PTO (см. параграф 6.2) или при входе в режим восстановления (см. параграф 7.3.2).

7.1. Явное указание перегрузки

Если для пути подтверждено явное уведомление о перегрузке (Explicit Congestion Notification или ECN) [RFC3168] [RFC8311], QUIC считает код CE3 в заголовке IP сигналом перегрузки. Этот документ задаёт реакцию конечных точек на увеличение полученного от партнёра значения ECN-CE (см. параграф 13.4.2 в [QUIC-TRANSPORT]).

7.2. Начальное и минимальное окно перегрузки

QUIC начинает каждое соединение в режиме замедленного старта с установкой начального значения окна перегрузки. Конечным точкам следует устанавливать начальное окно перегрузки в 10 максимальных размеров дейтаграмм (max_datagram_size), при этом ограничивая окно значением 14720 байтов или удвоенным размером максимальной дейтаграммы. Это соответствует анализу и рекомендациям [RFC6928], увеличивая предельный размер с учётом 8-байтового заголовка UDP вместо 20-байтового заголовка TCP. Если максимальный размер дейтаграмм меняется в процессе работы соединения, начальное окно перегрузки следует пересчитать в соответствии с изменением. Если максимальный размер дейтаграмм уменьшается для завершения согласования, окно перегрузки следует установить в соответствии с новым значением начального окна перегрузки.

До проверки адреса клиента сервер может быть дополнительно ограничен пределом антиусиления, как описано в параграфе 8.1 [QUIC-TRANSPORT]. Хотя предел антиусиления может препятствовать полному использованию окна перегрузки и замедлять расширение этого окна, он не влияет на окно перегрузки напрямую.

Минимальным окном перегрузки является меньшее из значений окна перегрузки, которое может быть установлено в ответ на потерю, рост полученного от партнёра значения ECN-CE или сохраняющуюся перегрузку. Рекомендуется удвоенное значение max_datagram_size.

7.3. Состояния контроля перегрузки

Контроллер перегрузок NewReno, описанный в этом документе, имеет 3 состояния, показанных на рисунке 1.

             Новый путь или      +------------+
        сохраняющаяся перегрузка |Замедленный |
       (O)---------------------->|   старт    |
                                 +------------+
                                       |
                            Потеря или |
                           рост ECN-CE |
                                       v
+------------+    Потеря или     +------------+
| Предотвращ.|    рост ECN-CE    |   Период   |
| перегрузки |------------------>| восстановл.|
+------------+                   +------------+
          ^                            |
          |                            |
          +----------------------------+
           Подтверждение пакета передано
             в процессе восстановления

Рисунок 1. Смена состояний контроля перегрузок.


Эти состояния и переходы между ними описаны в последующих параграфах.

7.3.1. Замедленный старт

Отправитель NewReno находится в режиме замедленного старта каждый раз, когда окно перегрузки ниже порога замедленного старта. Отправитель начинает в этом режиме, поскольку пород замедленного старта инициализируется бесконечным значением. Когда отправитель находится в режиме замедленного старта, окно перегрузки увеличивается на число подтверждённых байтов при обработке каждого подтверждения. Это ведёт к экспоненциальному росту окна перегрузки.

Отправитель должен выходить из режима замедленного старта при потере пакета или росте полученного от партнёра значения ECN-CE. Отправитель возвращается в режим замедленного старта всякий раз, когда окно перегрузки становится меньше порога замедленного старта, что происходит лишь при возникновении сохраняющейся перегрузки.

7.3.2. Восстановление

Отправитель NewReno входит в период восстановления при обнаружении потери пакета или росте полученного от партнёра значения ECN-CE. Отправитель, уже находящийся в периоде восстановления, остаётся в нем без входа заново. При входе в период восстановления отправитель должен установить для порога замедленного старта половину размера окна перегрузки при обнаружении потери. Для окна перегрузки должно быть установлено сниженное значение порога замедленного старта при выходе из периода восстановления.

Реализация может сократить окно перегрузки сразу после входа в период восстановления или с помощью других механизмов, таких как пропорциональное снижение скорости (Proportional Rate Reduction [PRR]), для более постепенного сокращения. Если окно перегрузки сокращается сразу же, перед сокращением может быть передан 1 пакет. Это ускоряет восстановление, если потерянный пакет передаётся повторно, и похоже на TCP, как описано в разделе 5 [RFC6675].

Период восстановления направлен на ограничение сокращения окна перегрузки один раз за период кругового обхода. Поэтому в период восстановления окно перегрузки не сокращается в ответ на новые потери и рост ECN-CE. Период восстановления заканчивается и отправитель переходит в режим предотвращения перегрузки, когда подтверждаются пакеты, переданные в период восстановления. Это несколько отличается от определения восстановления в TCP, которое завершается при подтверждении сегмента, с потери которого восстановления началось [RFC5681].

7.3.3. Предотвращение перегрузки

Отправитель NewReno находится в режиме предотвращения перегрузки все время, когда окно перегрузки не меньше порога замедленного старта и нет периода восстановления. Отправитель в этом режиме использует аддитивное увеличение и мультипликативное сокращение (Additive Increase Multiplicative Decrease или AIMD), которое должно ограничить расширение окна перегрузки величиной не более размера одной максимальной дейтаграммы для каждого подтверждённого окна перегрузки. Отправитель переходит из режима предотвращения перегрузки в период восстановления при потере пакета или росте полученного от партнёра значения ECN-CE.

7.4. Игнорирование потери нерасшифровываемых пакетов

В процессе согласования некоторые ключи защиты пакетов могут быть недоступны в момент прибытия пакета и получатель может принять решение об отбрасывании пакета. В частности, пакеты Handshake и 0-RTT невозможно обработать до получения пакетов Initial, а 1-RTT – до завершения согласования. Конечные точки могут игнорировать потерю пакетов Handshake, 0-RTT, 1-RTT, которые приходят к партнёру до обретения ключей для их обработки. Конечным точкам недопустимо игнорировать потерю пакетов, переданных после наиболее раннего подтверждённого пакета из того же пространства номеров.

7.5. Тайм-аут зондирования

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

7.6. Сохраняющаяся перегрузка

Когда отправитель констатирует потерю всех пакетов в течение достаточно долгого интервала, считается, что в сети наблюдается сохраняющаяся (постоянная) перегрузка.

7.6.1. Продолжительность

Продолжительность сохраняющейся перегрузки рассчитывается как

   (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
       kPersistentCongestionThreshold

В отличие от расчёта PTO в параграфе 6.2, эта продолжительность включает max_ack_delay безотносительно к пространству номеров, где были отмечены потери. Эта продолжительность позволяет отправителю передать до фиксации сохраняющейся перегрузки (включая отклик на завершение PTO) столько пакетов, сколько разрешено для TCP с Tail Loss Probes [RFC8985] и RTO [RFC5681].

Большее значение kPersistentCongestionThreshold делает отправителя менее восприимчивым к сохраняющейся перегрузке в сети, что может привести к избыточной передаче в перегруженную сеть. Слишком малое значение может приводить к неоправданному решению о сохраняющейся перегрузке, снижающему скорость передачи у отправителя. Для kPersistentCongestionThreshold рекомендуется значение 3, обеспечивающее поведение, близкое к поведению отправителя TCP, объявляющего RTO после двух TLP.

В этой схеме не применяются последовательные события PTO для фиксации сохраняющейся перегрузки, поскольку на PTO влияет картина трафика приложения. Например, отправитель, передающий небольшой объем данных, перезапускает таймер PTO при каждой передаче, что может приводить к тому, что таймер PTO будет срабатывать редко даже при отсутствии подтверждений. Использование продолжительности позволяет отправителю фиксировать сохраняющуюся перегрузку без учёта таймера PTO.

7.6.2. Фиксация сохраняющейся перегрузки

Отправитель констатирует сохраняющуюся перегрузку после приёма подтверждения, если объявлены потерянными 2 пакета с запросом подтверждения и выполняются указанные ниже условия:

  • во всех пространствах номеров не подтверждён ни один из пакетов, переданных между этими 2 пакетами;

  • время между отправкой этих 2 пакетов больше продолжительности постоянной перегрузки (параграф 7.6.1);

  • при отправке этих двух пакетов имелась предыдущая выборка RTT.

Эти 2 пакета должны быть запрашивающими подтверждение, поскольку получатель обязан подтверждать лишь такие пакеты в интервале максимальной задержки подтверждения (см. параграф 13.2 в [QUIC-TRANSPORT]).

Период постоянной перегрузки недопустимо начинать, пока не сделана хотя бы одна выборка RTT. До первой выборки RTT отправитель активирует таймер PTO на основе начального значения RTT (параграф 6.2.2), которое может быть существенно больше фактического RTT. Требование предшествующей выборки RTT предотвращает фиксацию сохраняющейся перегрузки отправителем на основании слишком малого числа пакетов.

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

Когда объявлена сохраняющаяся перегрузка, окно перегрузки у отправителя должно сокращаться до минимального размера (kMinimumWindow), как в реакции отправителя TCP на RTO [RFC5681].

7.6.3. Пример

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

   smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
   kPersistentCongestionThreshold = 3

Рассмотрим приведённую в таблице 1 последовательность событий

Таблица 1.

Время

Действие

t=0

Передан пакет 1 (данные приложения)

t=1

Передан пакет 2 (данные приложения)

t=1,2

Получено подтверждение пакета 1

t=2

Передан пакет 3 (данные приложения)

t=3

Передан пакет 4 (данные приложения)

t=4

Передан пакет 5 (данные приложения)

t=5

Передан пакет 6 (данные приложения)

t=6

Передан пакет 7 (данные приложения)

t=8

Передан пакет 8 (PTO 1)

t=12

Передан пакет 9 (PTO 2)

t=12,2

Получено подтверждение пакета 9

Пакеты 2 – 8 объявляются потерянными, когда приходит подтверждение пакета 9 в момент t = 12,2. Период перегрузки рассчитывается как время между самым старым и самым новым потерянными пакетами 8 – 1 = 7. Продолжительность сохраняющейся перегрузки составляет 2 * 3 = 6. Поскольку порог был достигнут и ни один пакет между самым старым и самым новым потерянными пакетами не был подтверждён, считается, что в сети сохраняется перегрузка.

Хотя в примере показан тайм-аут PTO, он не требуется для обнаружения сохраняющейся перегрузки.

7.7. Темп передачи

Отправителю следует управлять передачей пакетов на основе входных данных контроллера перегрузки. Отправка нескольких пакетов в сеть без задержки между ними создаёт пик пакетов, который может вызвать кратковременную перегрузку и потери. Отправитель должен контролировать такие пики и ему следует ограничивать их начальным окном перегрузки (см. параграф 7.2). Отправитель, знающий, что путь к получателю способен принимать большие пики, может установить более высокое значение.

Реализации следует обеспечивать контроллеру перегрузки поведение, похожее на задание темпа (pacer). Например, можно дополнять контроллер перегрузок и управлять доступностью окна перегрузки или ускоренно передавать пакеты от контроллера перегрузки.

Для эффективного восстановления потерь важна своевременная доставка кадров ACK. Для предотвращения задержки их доставки партнёру следует передавать пакеты, содержащие только кадры ACK без управления темпом. Конечные точки могут реализовать управление темпом передачи по своему усмотрению. Идеальный отправитель передаёт пакеты строго равномерно по времени. Для контроллера перегрузки на основе окна, подобного рассмотренному здесь, эту скорость можно рассчитать, усредняя окно перегрузки в интервале RTT. Скорость в байтах за единицу времени при congestion_window, заданном в байтах, будет определяться выражением

   rate = N * congestion_window / smoothed_rtt

Можно также задать скорость межпакетным интервалом в единицах времени

   interval = ( smoothed_rtt * packet_size / congestion_window ) / N

Использование небольшого (но не меньше 1) значения N (например, 1,25) гарантирует, что изменения RTT не будут приводить к неполному использованию окна перегрузки.

Практические соображения, такие как пакетизация, задержки планирования и вычислительная эффективность, могут вынудить сервер отклониться от этой скорости в течение интервалов много меньше RTT.

Одной из возможных стратегий управления темпом является применение алгоритма «текущего ведра» (leaky bucket), объем которого ограничен максимальным размером пиков, а скорость вытекания задаётся приведённой функцией.

7.8. Неполное использование окна перегрузки

Когда число находящихся в пути байтов меньше окна перегрузки и скорость отправки не задаётся стимулятором, возможно неполное использование окна перегрузки. Это может быть результатом неверно выбранных ограничений данных приложением или управления потоком данных. В таких случаях не следует увеличивать окно перегрузки в режиме замедленного старта или предотвращения перегрузки.

Отправитель, управляющий темпом передачи (параграф 7.7) может задерживать отправку пакетов и в результате не использовать полностью окно перегрузки. Отправителю не следует считать себя ограниченным приложением, если он может полностью использовать окно перегрузки без вносимой управлением темпом задержки. Отправитель может реализовать дополнительные механизмы для обновления окна перегрузки после периодов неполного использования, такие как предложены для TCP в [RFC7661].

8. Вопросы безопасности

8.1. Сигналы потерь и перегрузки

Обнаружение потерь и контроль перегрузки основаны на сигналах, таких как задержка, потери, маркировка ECN, от неаутентифицированных объектов. Злоумышленник может заставить конечные точки снизить скорость передачи, манипулируя этими сигналами путём отбрасывания пакетов, изменения задержки на пути или подмены кодов ECN.

8.2. Анализ трафика

Пакеты, содержащие лишь кадры ACK, можно определить эвристически по их размеру. Картины подтверждений могут раскрывать информацию о характеристиках канала и поведении приложения. Для снижения утечки сведений конечная точка может объединять подтверждения с другими кадрами или добавлять кадры PADDING ценой снижения производительности.

8.3. Неверная маркировка ECN

Получатель может передавать некорректную маркировку ECN для изменения реакции отправителя на перегрузку. Подавление сведений о маркировке ECN-CE может вынудить отправителя к увеличению скорости передачи, что может приводить к перегрузке и потерям.

Отправитель может обнаружить подавление сведений, случайно помечая передаваемые пакеты маркером ECN-CE. Если для пакета, переданного с маркировкой ECN-CE, не сообщается о наличии маркера CE при его подтверждении, отправитель может отключить ECN для пути, не устанавливая коды ECT в последующих пакетах для этого пути [RFC3168].

Сообщение о дополнительных маркерах ECN-CE вынудит отправителя снизить скорость передачи, что похоже на эффект анонсирования сниженного порога управления потоком данных, поэтому не даёт каких-либо преимуществ.

Конечные точки сами выбирают контроллер перегрузки. Контроллеры реагируют на сведения о ECN-CE снижением скорости, но отклики могут различаться. Маркировку можно считать эквивалентом потери [RFC3168], но возможны и другие отклики, например, [RFC8511] или [RFC8311].

9. Литература

9.1. Нормативные документы

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., “Using TLS to Secure QUIC”, RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Дополнительная литература

[FACK] Mathis, M. and J. Mahdavi, “Forward acknowledgement: Refining TCP Congestion Control”, ACM SIGCOMM Computer Communication Review, DOI 10.1145/248157.248181, August 1996, <https://doi.org/10.1145/248157.248181>.

[PRR] Mathis, M., Dukkipati, N., and Y. Cheng, “Proportional Rate Reduction for TCP”, RFC 6937, DOI 10.17487/RFC6937, May 2013, <https://www.rfc-editor.org/info/rfc6937>.

[RETRANSMISSION] Karn, P. and C. Partridge, “Improving Round-Trip Time Estimates in Reliable Transport Protocols”, ACM Transactions on Computer Systems, DOI 10.1145/118544.118549, November 1991, <https://doi.org/10.1145/118544.118549>.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, “TCP Selective Acknowledgment Options”, RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[RFC3465] Allman, M., “TCP Congestion Control with Appropriate Byte Counting (ABC)”, RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, “TCP Congestion Control”, RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, “Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP”, RFC 5682, DOI 10.17487/RFC5682, September 2009, <https://www.rfc-editor.org/info/rfc5682>.

[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and P. Hurtig, “Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)”, RFC 5827, DOI 10.17487/RFC5827, May 2010, <https://www.rfc-editor.org/info/rfc5827>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, “Computing TCP’s Retransmission Timer”, RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, “The NewReno Modification to TCP’s Fast Recovery Algorithm”, RFC 6582, DOI 10.17487/RFC6582, April 2012, <https://www.rfc-editor.org/info/rfc6582>.

[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, “A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP”, RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.

[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, “Increasing TCP’s Initial Window”, RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.

[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, “Updating TCP to Support Rate-Limited Traffic”, RFC 7661, DOI 10.17487/RFC7661, October 2015, <https://www.rfc-editor.org/info/rfc7661>.

[RFC8311] Black, D., “Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation”, RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, “CUBIC for Fast Long-Distance Networks”, RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

[RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, “TCP Alternative Backoff with ECN (ABE)”, RFC 8511, DOI 10.17487/RFC8511, December 2018, <https://www.rfc-editor.org/info/rfc8511>.

[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, “The RACK-TLP Loss Detection Algorithm for TCP”, RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.

Приложение A. Псевдокод обнаружения потерь

Здесь рассматривается пример реализации механизмов обнаружения потерь, описанных в разделе 6. Приведённый псевдокод лицензируется как компоненты кода (см. «Авторские права»).

A.1. Отслеживание переданных пакетов

Для корректной реализации контроля перегрузок отправитель QUIC отслеживает все пакеты с запросом подтверждения, пока пакет не будет потерян или подтверждён. Предполагается, что реализация будет иметь доступ к этим сведениям по номеру пакета или криптографическому контексту и будет сохранять для каждого пакета поля (Приложение A.1.1), служащие для восстановления потерь и контроля перегрузки.

Когда пакет объявлен потерянным, конечная точка может некоторое время сохранять его состояние, чтобы учесть нарушение порядка пакетов (см. параграф 13.3 в [QUIC-TRANSPORT]). Это позволит отправителю обнаружить ложные повторы передачи. Передача отслеживается для каждого пространства номеров, а обработка ACK выполняется лишь в одном пространстве.

A.1.1. Поля переданных пакетов

packet_number

Номер передаваемого пакета.

ack_eliciting

Логический параметр, указывающий для пакета запрос подтверждения. Значение true указывает, что отправитель ждёт подтверждения, хотя партнёр может задержать отправку кадра ACK с этим подтверждением на время до max_ack_delay.

in_flight

Логический параметр, указывающий учёт пакета в числе находящихся в пути байтов.

sent_bytes

Число переданных в пакете байтов без учёта заголовков UDP и IP, но с учётом кадрирования QUIC.

time_sent

Время передачи пакета.

A.2. Константы

Используемые для восстановления потерь константы основаны на комбинации RFC, статей и опыта.

kPacketThreshold

Максимальное разупорядочение пакетов для фиксации потери пакета по достижению этого порога. В параграфе 6.1.1 рекомендовано значение 3.

kTimeThreshold

Максимальное время разупорядочения пакетов по достижению которого пакет считается потерянным. Задаётся в интервалах RTT. В параграфе 6.1.2 рекомендовано значение 9/8.

kGranularity

Дискретность таймера, зависящая от системы. В параграфе 6.1.2 рекомендовано значение 1 мсек.

kInitialRtt

Значение RTT, использованное перед выборкой RTT. В параграфе 6.2.2 рекомендовано значение 333 мсек.

kPacketNumberSpace

Перечисляемый тип для трёх пространств номеров пакетов.

   enum kPacketNumberSpace {
     Initial,
     Handshake,
     ApplicationData,
   }

A.3. Переменные

Ниже приведены переменные, используемые для восстановления потерь.

latest_rtt

Наиболее свежее измерение RTT выполненное при получении подтверждения ранее не подтверждённого пакета.

smoothed_rtt

Сглаженное значение RTT для соединения, рассчитанное в соответствии с параграфом 5.3.

rttvar

Вариации RTT, рассчитанные в соответствии с параграфом 5.3.

min_rtt

Минимальное значение RTT за период времени без учёта задержки подтверждения, как указано в параграфе 5.2.

first_rtt_sample

Время первой выборки RTT.

max_ack_delay

Максимальное время, на которое получатель намерен задерживать подтверждения для пакетов из пространства номеров Application Data, определяемое одноимённым транспортным параметром (параграф 18.2 в [QUIC-TRANSPORT]). Отметим, что фактическое значение ack_delay в полученном кадре ACK может быть больше из-за запаздывания таймеров, нарушения порядка и потери пакетов.

loss_detection_timer

Многорежимный таймер, используемый для обнаружения потерь.

pto_count

Число фактов передачи PTO без получения подтверждения.

time_of_last_ack_eliciting_packet[kPacketNumberSpace]

Время передачи последнего пакета с запросом подтверждения.

largest_acked_packet[kPacketNumberSpace]

Наибольший номер, подтверждённый на данный момент в пространстве номеров пакетов.

loss_time[kPacketNumberSpace]

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

sent_packets[kPacketNumberSpace]

Привязка номеров пакетов в определённом пространстве к информации о них (см. Приложение A.1).

A.4. Инициализация

В начале соединения инициализируются переменные обнаружения потерь, как показано ниже.

   loss_detection_timer.reset()
   pto_count = 0
   latest_rtt = 0
   smoothed_rtt = kInitialRtt
   rttvar = kInitialRtt / 2
   min_rtt = 0
   first_rtt_sample = 0
   for pn_space in [ Initial, Handshake, ApplicationData ]:
     largest_acked_packet[pn_space] = infinite
     time_of_last_ack_eliciting_packet[pn_space] = 0
     loss_time[pn_space] = 0

A.5. Отправка пакета

Информация о пакете сохраняется после его передачи. Параметры OnPacketSent подробно описаны в Приложении A.1.1, а псевдокод приведён ниже.

   OnPacketSent(packet_number, pn_space, ack_eliciting,
                in_flight, sent_bytes):
     sent_packets[pn_space][packet_number].packet_number =
                                              packet_number
     sent_packets[pn_space][packet_number].time_sent = now()
     sent_packets[pn_space][packet_number].ack_eliciting =
                                              ack_eliciting
     sent_packets[pn_space][packet_number].in_flight = in_flight
     sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
     if (in_flight):
       if (ack_eliciting):
         time_of_last_ack_eliciting_packet[pn_space] = now()
       OnPacketSentCC(sent_bytes)
       SetLossDetectionTimer()

A.6. Приём дейтаграммы

Когда сервер блокируется пределом антиусиления, приём дейтаграммы снимает блокировку, даже если ни один из пакетов в этой дейтаграмме не был успешно обработан. В таком случае не требуется повторно активировать таймер PTO. Псевдокод OnDatagramReceived представлен ниже.

   OnDatagramReceived(datagram):
     // Если эта дейтаграмма снимает блокировку сервер, 
     // активируется таймер PTO для предотвращения блокировки.
     if (server was at anti-amplification limit):
       SetLossDetectionTimer()
       if loss_detection_timer.timeout < now():
         // Выполняется PTO, если отсчёт таймера завершился, 
         // пока применялся порог антиусиления.
         OnLossDetectionTimeout()

A.7. Приём подтверждения

При получении кадра ACK он может заново подтверждать любое число пакетов. Псевдокод OnAckReceived и UpdateRtt приведён ниже.

   IncludesAckEliciting(packets):
     for packet in packets:
       if (packet.ack_eliciting):
         return true
     return false

   OnAckReceived(ack, pn_space):
     if (largest_acked_packet[pn_space] == infinite):
       largest_acked_packet[pn_space] = ack.largest_acked
     else:
       largest_acked_packet[pn_space] =
           max(largest_acked_packet[pn_space], ack.largest_acked)

     // DetectAndRemoveAckedPackets находит пакеты, которые недавно
     // подтверждены и удаляет их из sent_packets.
     newly_acked_packets =
         DetectAndRemoveAckedPackets(ack, pn_space)
     // Нечего делать при отсутствии недавно подтверждённых пакетов.
     if (newly_acked_packets.empty()):
       return

     // Обновление RTT при недавнем подтверждении наибольшего номера,
     // если недавно получено хотя бы одно запрошенное подтверждение.
     if (newly_acked_packets.largest().packet_number ==
             ack.largest_acked &&
         IncludesAckEliciting(newly_acked_packets)):
       latest_rtt =
         now() - newly_acked_packets.largest().time_sent
       UpdateRtt(ack.ack_delay)

     // Обработка сведений ECN (при наличии).
     if (ACK frame contains ECN information):
         ProcessECN(ack, pn_space)

     lost_packets = DetectAndRemoveLostPackets(pn_space)
     if (!lost_packets.empty()):
       OnPacketsLost(lost_packets)
     OnPacketsAcked(newly_acked_packets)

     // Сброс pto_count, пока клиент не уверен, что сервер
     // проверил его адрес.
     if (PeerCompletedAddressValidation()):
       pto_count = 0
     SetLossDetectionTimer()

   UpdateRtt(ack_delay):
     if (first_rtt_sample == 0):
       min_rtt = latest_rtt
       smoothed_rtt = latest_rtt
       rttvar = latest_rtt / 2
       first_rtt_sample = now()
       return

     // min_rtt игнорирует задержку подтверждения.
     min_rtt = min(min_rtt, latest_rtt)
     // Ограничивает ack_delay значением max_ack_delay после 
     // подтверждения согласования.
     if (handshake confirmed):
       ack_delay = min(ack_delay, max_ack_delay)

     // Настройка задержки подтверждения при возможности.
     adjusted_rtt = latest_rtt
     if (latest_rtt >= min_rtt + ack_delay):
       adjusted_rtt = latest_rtt - ack_delay

     rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
     smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt

A.8. Установка таймера обнаружения потерь

Для обнаружения потерь в QUIC применяется один таймер. Продолжительность отсчёта зависит от режима таймера, который установлен в пакете, и описанных ниже событий. Определённая ниже функция SetLossDetectionTimer показывает, как устанавливается один таймер. Этот алгоритм может устанавливать для таймера время в прошлом, особенно при позднем пробуждении таймера. В таком случае таймер срабатывает сразу же. Псевдокод SetLossDetectionTimer приведён ниже (^ обозначает возведение в степень).

   GetLossTimeAndSpace():
     time = loss_time[Initial]
     space = Initial
     for pn_space in [ Handshake, ApplicationData ]:
       if (time == 0 || loss_time[pn_space] < time):
         time = loss_time[pn_space];
         space = pn_space
     return time, space

   GetPtoTimeAndSpace():
     duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
         * (2 ^ pto_count)
     // Антиблокировочный тайм-аут PTO запускается с текущего момента
     if (no ack-eliciting packets in flight):
       assert(!PeerCompletedAddressValidation())
       if (has handshake keys):
         return (now() + duration), Handshake
       else:
         return (now() + duration), Initial
     pto_timeout = infinite
     pto_space = Initial
     for space in [ Initial, Handshake, ApplicationData ]:
       if (no ack-eliciting packets in flight in space):
           continue;
       if (space == ApplicationData):
         // Пропуск Application Data, пока согласование не подтверждено.
         if (handshake is not confirmed):
           return pto_timeout, pto_space
         // Включение max_ack_delay и отсрочки для Application Data.
         duration += max_ack_delay * (2 ^ pto_count)

       t = time_of_last_ack_eliciting_packet[space] + duration
       if (t < pto_timeout):
         pto_timeout = t
         pto_space = space
     return pto_timeout, pto_space

   PeerCompletedAddressValidation():
     // Предположим, что клиент проверяет адрес сервера неявно.
     if (endpoint is server):
       return true
     // Сервер завершает проверку адреса при получении 
     // защищённого пакета.
     return has received Handshake ACK ||
          handshake confirmed

   SetLossDetectionTimer():
     earliest_loss_time, _ = GetLossTimeAndSpace()
     if (earliest_loss_time != 0):
       // Временной порог обнаружения потерь.
       loss_detection_timer.update(earliest_loss_time)
       return

     if (server is at anti-amplification limit):
       // Таймер сервера не устанавливается, если нечего передать.
       loss_detection_timer.cancel()
       return

     if (no ack-eliciting packets in flight &&
         PeerCompletedAddressValidation()):
       // Нет ничего для обнаружения потерь и таймер не устанавливается.
       // Однако клиент должен активировать таймер, если сервер может
       // быть заблокирован пределом антиусиления.
       loss_detection_timer.cancel()
       return

     timeout, _ = GetPtoTimeAndSpace()
     loss_detection_timer.update(timeout)

A.9. Тайм-аут

При завершении отсчёта таймера обнаружения потерь выполняемые действия определяются режимом таймера. Псевдокод OnLossDetectionTimeout приведён ниже

   OnLossDetectionTimeout():
     earliest_loss_time, pn_space = GetLossTimeAndSpace()
     if (earliest_loss_time != 0):
       // Временной порог обнаружения потерь
       lost_packets = DetectAndRemoveLostPackets(pn_space)
       assert(!lost_packets.empty())
       OnPacketsLost(lost_packets)
       SetLossDetectionTimer()
       return

     if (no ack-eliciting packets in flight):
       assert(!PeerCompletedAddressValidation())
       // Клиент передал противоблокироваочный пакет: пакет Initial 
       // дополнен для увеличения предела антиусиления,
       // пакет Handshake подтверждает владение адресом.
       if (has Handshake keys):
         SendOneAckElicitingHandshakePacket()
       else:
         SendOneAckElicitingPaddedInitialPacket()
     else:
       // PTO. При наличии передаются новые данные или повторяются прежние.
       // Если ничего не доступно, передаётся один кадр PING.
       _, pn_space = GetPtoTimeAndSpace()
       SendOneOrTwoAckElicitingPackets(pn_space)

     pto_count++
     SetLossDetectionTimer()

A.10. Обнаружение потери пакетов

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

   DetectAndRemoveLostPackets(pn_space):
     assert(largest_acked_packet[pn_space] != infinite)
     loss_time[pn_space] = 0
     lost_packets = []
     loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)

     // Минимальное время kGranularity перед тем как пакет 
     // будет сочтён потерянным.
     loss_delay = max(loss_delay, kGranularity)

     // Пакеты, переданные до этого времени, считаются потерянными.
     lost_send_time = now() - loss_delay

     foreach unacked in sent_packets[pn_space]:
       if (unacked.packet_number > largest_acked_packet[pn_space]):
         continue

       // Маркировка пакета как потерянного или установка времени, когда
       // его следует пометить. Отметим, что kPacketThreshold здесь
       // предполагает отсутствие заданных отправителем пропусков номеров.
       if (unacked.time_sent <= lost_send_time ||
           largest_acked_packet[pn_space] >=
             unacked.packet_number + kPacketThreshold):
         sent_packets[pn_space].remove(unacked.packet_number)
         lost_packets.insert(unacked)
       else:
         if (loss_time[pn_space] == 0):
           loss_time[pn_space] = unacked.time_sent + loss_delay
         else:
           loss_time[pn_space] = min(loss_time[pn_space],
                                     unacked.time_sent + loss_delay)
     return lost_packets

A.11. Отбрасывание ключей Initial или Handshake

При отбрасывании ключей Initial или Handshake пакеты из этого пространства отбрасываются и обновляется статус обнаружения потерь. Псевдокод OnPacketNumberSpaceDiscarded приведён ниже.

   OnPacketNumberSpaceDiscarded(pn_space):
     assert(pn_space != ApplicationData)
     RemoveFromBytesInFlight(sent_packets[pn_space])
     sent_packets[pn_space].clear()
     // Сброс обнаружения потерь и таймера PTO.
     time_of_last_ack_eliciting_packet[pn_space] = 0
     loss_time[pn_space] = 0
     pto_count = 0
     SetLossDetectionTimer()

Приложение B. Псевдокод контроля перегрузки

Здесь рассматривается пример реализации контроллера перегрузок, описанного в разделе 7. Приведённый псевдокод лицензируется как компоненты кода (см. «Авторские права»).

B.1. Константы

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

kInitialWindow

Используемый по умолчанию предел находящихся в пути (in flight) байтов, как описано в параграфе 7.2.

kMinimumWindow

Минимальное окно перегрузки (в байтах), как описано в параграфе 7.2.

kLossReductionFactor

Фактор масштабирования, применяемый для сужения окна перегрузки при обнаружении новой потери. Раздел 7 рекомендует значение 0,5.

kPersistentCongestionThreshold

Интервал времени фиксации сохраняющейся перегрузки, задаваемый коэффициентом для PTO. Параграф 7.6 рекомендует значение 3.

B.2. Переменные

Ниже приведены переменные, требуемые для реализации механизмов контроля перегрузки, описанных здесь.

max_datagram_size

Текущий максимальный размер содержимого (payload) для отправителя без учёта заголовков UDP и IP. Значение max_datagram_size применяется при расчёте окна перегрузки. Конечная точка устанавливает значение этой переменной на основе максимального блока данных для пути (Path Maximum Transmission Unit или PMTU, см. параграф 14.2 в [QUIC-TRANSPORT]), но не менее 1200 байтов.

ecn_ce_counters[kPacketNumberSpace]

Наибольшее значение счётчика ECN-CE в пространстве номеров пакета, сообщённое партнёром в кадре ACK. Это значение применяется для обнаружения роста сообщённых счётчиков ECN-CE.

bytes_in_flight

Суммарное число байтов во всех переданных пакетах, содержащих кадр с запросом подтверждения или PADDING, которые ещё не были подтверждены или объявлены потерянными. Заголовки IP и UDP не учитываются, но включается заголовок QUIC и данные аутентифицированного шифрования со связанными данными (Authenticated Encryption with Associated Data или AEAD). Пакеты, содержащие лишь кадры ACK, не учитываются в bytes_in_flight, чтобы контроль перегрузок не препятствовал обратной связи в случае насыщения.

congestion_window

Максимальное число байтов, которые могут находиться в пути.

congestion_recovery_start_time

Время начала текущего периода восстановления в ответ на потерю или ECN. Когда подтверждается отправленный после этого момента пакет, QUIC выходит из режима восстановления при перегрузке.

ssthresh

Порог замедленного старта (в байтах). Когда окно перегрузок меньше ssthresh, используется режим замедленного старта и окно увеличивается на число подтверждённых байтов.

Псевдокод контроля перегрузок использует также некоторые переменные псевдокода восстановления потерь.

B.3. Инициализация

В начале соединения инициализируются переменные контроля перегрузок, как показано ниже.

   congestion_window = kInitialWindow
   bytes_in_flight = 0
   congestion_recovery_start_time = 0
   ssthresh = infinite
   for pn_space in [ Initial, Handshake, ApplicationData ]:
     ecn_ce_counters[pn_space] = 0

B.4. Передача пакета

При каждой отправке пакета, содержащего кадры, отличные от ACK, увеличивается значение bytes_in_flight.

   OnPacketSentCC(sent_bytes):
     bytes_in_flight += sent_bytes

B.5. Подтверждение пакета

Приведённый ниже псевдокод вызывается из OnAckReceived для обнаружения потерь с недавними acked_packets из числа sent_packets. В механизмах предотвращения перегрузки разработчикам, применяющим целочисленное представление congestion_window, следует быть осторожными с делением и можно применять другой подход, предложенный в параграфе 2.1 [RFC3465].

   InCongestionRecovery(sent_time):
     return sent_time <= congestion_recovery_start_time

   OnPacketsAcked(acked_packets):
     for acked_packet in acked_packets:
       OnPacketAcked(acked_packet)

   OnPacketAcked(acked_packet):
     if (!acked_packet.in_flight):
       return;
     // Исключение из bytes_in_flight.
     bytes_in_flight -= acked_packet.sent_bytes
     // Не увеличивать congestion_window, если ограничено
     // приложением или контролем потока данных.
     if (IsAppOrFlowControlLimited())
       return
     // Не увеличивать congestion_window в период восстановления.
     if (InCongestionRecovery(acked_packet.time_sent)):
       return
     if (congestion_window < ssthresh):
       // Замедленный старт.
       congestion_window += acked_packet.sent_bytes
     else:
       // Предотвращение перегрузки.
       congestion_window +=
         max_datagram_size * acked_packet.sent_bytes
         / congestion_window

B.6. Событие перегрузки

Приведённый ниже псевдокод вызывается из ProcessECN и OnPacketsLost при обнаружении нового факта перегрузки. Если восстановления ещё не происходит, это запускает период восстановления и сразу же уменьшает порог замедленного старта и окно перегрузки.

   OnCongestionEvent(sent_time):
     // Нет реакции, если период восстановления уже начат.
     if (InCongestionRecovery(sent_time)):
       return

     // Вход в период восстановления.
     congestion_recovery_start_time = now()
     ssthresh = congestion_window * kLossReductionFactor
     congestion_window = max(ssthresh, kMinimumWindow)
     // Можно передать пакет для ускорения восстановления.
     MaybeSendOnePacket()

B.7. Обработка сведений ECN

Приведённый ниже псевдокод вызывается при получении от партнёра кадра ACK с разделом ECN.

   ProcessECN(ack, pn_space):
     // Если сообщённое партнёром значение ECN-CE увеличивается,
     // это может быть новым фактом перегрузки.
     if (ack.ce_counter > ecn_ce_counters[pn_space]):
       ecn_ce_counters[pn_space] = ack.ce_counter
       sent_time = sent_packets[ack.largest_acked].time_sent
       OnCongestionEvent(sent_time)

B.8. Потеря пакета

Приведённый ниже псевдокод вызывается, когда DetectAndRemoveLostPackets считает пакеты потерянными.

   OnPacketsLost(lost_packets):
     sent_time_of_last_loss = 0
     // Исключение потерянных пакетов из bytes_in_flight.
     for lost_packet in lost_packets:
       if lost_packet.in_flight:
         bytes_in_flight -= lost_packet.sent_bytes
         sent_time_of_last_loss =
           max(sent_time_of_last_loss, lost_packet.time_sent)
     // Перегрузка, если находящиеся в пути пакеты потеряны
     if (sent_time_of_last_loss != 0):
       OnCongestionEvent(sent_time_of_last_loss)

     // Сброс окна перегрузки, если потеря этих пакетов указывает
     // продолжающуюся перегрузку. Учитываются лишь пакеты,
     // переданные после выборки RTT.
     if (first_rtt_sample == 0):
       return
     pc_lost = []
     for lost in lost_packets:
       if lost.time_sent > first_rtt_sample:
         pc_lost.insert(lost)
     if (InPersistentCongestion(pc_lost)):
       congestion_window = kMinimumWindow
       congestion_recovery_start_time = 0

B.9. Исключение отброшенных пакетов из числа байтов в пути

Когда ключи Initial или Handshake отбрасываются, переданные пакеты из этого пространства номеров больше не учитываются в числе байтов, находящихся в пути. Псевдокод функции RemoveFromBytesInFlight приведён ниже.

   RemoveFromBytesInFlight(discarded_packets):
     // Исключение неподтвержденных пакетов 
     // из числа находящихся в пути.
     foreach packet in discarded_packets:
       if packet.in_flight
         bytes_in_flight -= size

Участники работы

Рабочая группа IETF QUIC получила огромную поддержку от многих людей. Ниже перечислены те, кто внёс существенный вклад в этот документ.

Alessandro Ghedini

Benjamin Saunders

Gorry Fairhurst

山本和彦 (Kazu Yamamoto)

奥 一穂 (Kazuho Oku)

Lars Eggert

Magnus Westerlund

Marten Seemann

Martin Duke

Martin Thomson

Mirja Kühlewind

Nick Banks

Praveen Balasubramanian

Адреса авторов

Jana Iyengar (editor)

Fastly

Email: jri.ietf@gmail.com

Ian Swett (editor)

Google

Email: ianswett@google.com


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Congestion Experienced – наступила перегрузка.

Рубрика: RFC | Оставить комментарий

RFC 9001 Using TLS to Secure QUIC

image_print
Internet Engineering Task Force (IETF)                   M. Thomson, Ed.
Request for Comments: 9001                                       Mozilla
Category: Standards Track                                 S. Turner, Ed.
ISSN: 2070-1721                                                    sn3rd
                                                                May 2021

Using TLS to Secure QUIC

Использование TLS для защиты QUIC

PDF

Аннотация

Этот документ описывает применение защиты на транспортном уровне (Transport Layer Security или TLS) для QUIC.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9001.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

В этом документе описан способ защиты QUIC [QUIC-TRANSPORT] с использованием TLS [TLS13].

TLS 1.3 обеспечивает значительное снижение задержки при организации соединений по сравнению с предыдущими версиями. При отсутствии потери пакетов большинство новых соединений может быть организовано и защищено за один круговой обход, а в последующих соединениях между теми же клиентом и сервером клиент зачастую может передавать данные приложения сразу же, используя соединение без кругового обхода (zero round-trip setup).

Этот документ описывает использование TLS для защиты QUIC.

2. Соглашения о нотации

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

В этом документе используются термины, определённые в [QUIC-TRANSPORT].

Для краткости аббревиатура TLS обозначает TLS 1.3, хотя могут применяться и более новые версии (параграф 4.2).

2.1. Обзор TLS

TLS обеспечивает паре конечных точек способ организации связи через среду без доверия (например, Internet). TLS обеспечивает проверку подлинности партнёров, а также защиту конфиденциальности и целостности сообщений, передаваемых между партнёрами.

TLS представляет собой многоуровневый протокол, структура которого показана на рисунке 1.

            +------------+-----------+--------------+---------+
Уровень     |            |           |    Данные    |         |
содержимого |Согласование|  Сигналы  |  приложения  |   ...   |
            |            |           |              |         |
            +------------+-----------+--------------+---------+
Уровень     |                                                 |
записи      |                    Записи                       |
            |                                                 |
            +-------------------------------------------------+

Рисунок 1. Уровни TLS.


Каждое сообщение уровня содержимого (например, согласование – handshake, сигналы, данные приложения) передаётся в серии типизованных записей уровня записи TLS. Каждая запись защищена криптографически и передаётся через транспорт с гарантией доставки (обычно TCP) и сохранением порядка.

Между конечными точками (клиент и сервер) выполняется аутентифицированный обмен ключами. Обмен инициирует клиент, а сервер отвечает ему. При успешном обмене ключами клиент и сервер согласуют секрет. TLS поддерживает заранее распространённые общие ключи (pre-shared key или PSK) и обмен Diffie-Hellman по конечным полям или эллиптическим кривым ((EC)DHE). PSK служит основой для начальных данных (Early Data, 0-RTT), а обмен – совершенную защиту (forward secrecy или FS) при уничтожении ключей (EC)DHE. Режимы можно комбинировать для обеспечения совершенной защиты при аутентификации PSK.

По завершении согласования TLS клиент узнает и подтвердит отождествление сервера, а сервер сможет узнать и отождествить клиента. TLS поддерживает аутентификацию на основе сертификатов X.509 [RFC5280] для клиента и сервера. При использовании обмена ключами PSK (как при возобновлении) знание PSK служит для аутентификации партнёра.

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

TLS обеспечивает два основных режима согласования для QUIC.

  • Полное согласование 1-RTT, в котором клиент может передавать данные после одного кругового обхода, а сервер отвечает сразу после получения от клиента согласующего сообщения.

  • Согласование 0-RTT, где клиент использует полученные ранее от сервера сведения для немедленной отправки данных приложения. Эти данные могут быть воспроизведены (replay) атакующим, поэтому 0-RTT не подходит для передачи инструкций, способных вызвать какие-либо действия с нежелательными последствиями.

Упрощённая схема согласования TLS с данными приложения 0-RTT показана на рисунке 2.

 Клиент                                             Сервер

 ClientHello
(0-RTT Application Data)  -------->
                                               ServerHello
                                      {EncryptedExtensions}
                                                 {Finished}
                          <-------- [Application Data] {Finished} -------->

[Application Data]        <------->      [Application Data]

 () Сообщения, защищенные ключами Early Data (0-RTT)
 {} Сообщения, защищенные ключами Handshake 
 [] Сообщения, защищенные ключами Application Data (1-RTT)

Рисунок 2. TLS Handshake с 0-RTT.


На рисунке 2 не показано сообщение EndOfEarlyData, которое не применяется в QUIC (см. параграф 8.3), как и сообщения ChangeCipherSpec и KeyUpdate. Сообщение ChangeCipherSpec избыточно в TLS 1.3 (параграф 8.4). В QUIC имеется свой механизм обновления ключей, описанный в разделе 6. Обновление ключей.

Данные защищаются с использованием нескольких уровней шифрования:

  • ключи Initial;

  • ключи 0-RTT;

  • ключи Handshake;

  • ключи 1-RTT.

Данные приложений могут присутствовать на уровнях 0-RTT и 1-RTT, сообщения согласования и сигналов – на любом.

Согласование 0-RTT может применяться, если между клиентом и сервером уже было взаимодействие. В согласовании 1-RTT клиент не может передавать защищённые данные приложения, пока сервер не передаст сообщения Handshake.

3. Обзор протокола

QUIC [QUIC-TRANSPORT] предполагает ответственность за защиту конфиденциальности и целостности пакетов. Для этого протокол использует ключи, выведенные из согласования TLS [TLS13], но вместо передачи записей TLS по протоколу QUIC (как в TCP) сообщения согласования и сигналы TLS передаются напрямую через транспорт QUIC, принимающий на себя обязанности уровня записи TLS, как показано на рисунке 3.

+--------------+--------------+ +-------------+
| Согласование |   Сигналы    | | Приложения  |
|     TLS      |     TLS      | |    QUIC     |
|              |              | | (h3 и т. п.)|
+--------------+--------------+-+-------------+
|                                             |
|                Транспорт QUIC               |
|   (потоки, надежность, перегрузки и пр.)    |
|                                             |
+---------------------------------------------+
|                                             |
|           Защита пакетов QUIC               |
|                                             |
+---------------------------------------------+

Рисунок 3. Уровни QUIC.


QUIC также полагается на TLS для проверки подлинности и согласования параметров, важных для конфиденциальности и производительности. Вместо строго деления по уровням эти два протокола взаимодействуют – QUIC использует согласование TLS, а TLS – гарантированную упорядоченную доставку и уровень записи, предоставляемые протоколом QUIC. На высоком уровне происходят два основных взаимодействия между TLS и QUIC:

  • TLS передаёт и принимает сообщения через QUIC с обеспечением абстракции надёжного потока для TLS;

  • TLS обеспечивает серию обновлений для QUIC, включая (a) новые ключи защиты пакетов и (b) смену состояний, таких как завершения согласования, сертификат сервера и т. п.

На рисунке 4 более подробно показаны эти взаимодействия, где защита пакетов QUIC вызывается отдельно.

+------------+                               +------------+
|            |<-- Сообщения согласования --->|            |
|            |<- Проверка параметров 0-RTT ->|            |
|            |<-------- Ключи 0-RTT ---------|            |
|    QUIC    |<------ Ключи Handshake -------|    TLS     |
|            |<-------- Ключи 1-RTT ---------|            |
|            |<--- Согласование завершено ---|            |
+------------+                               +------------+
 |         ^
 | Защита  | Защищенный
 v         | паекет
+------------+
|  Защита    |
|  пакета    |
|   QUIC     |
+------------+

Рисунок 4. Взаимодействие QUIC и TLS.


В отличие от TLS по протоколу TCP, приложения QUIC, желающие передавать данные, не шлют их с использованием записей TLS Application Data, а просто передают кадры QUIC STREAM или иных типов, которые доставляются в пакетах QUIC.

4. Передача сообщений TLS

QUIC передаёт данные согласования TLS в кадрах CRYPTO, каждый из которых содержит непрерывный блок данных согласования, указанных смещением и размером. Эти кадры помещаются в пакеты QUIC и шифруются с текущим уровнем. Как и в TLS по протоколу TCP, после доставки данных согласования TLS протоколу QUIC, тот принимает на себя ответственность за их доставку. Каждый блок данных, созданный TLS, связывается с набором ключей, которые TLS применяет в данный момент. Если протоколу QUIC требуется повторно передать данные, он должен использовать те же ключи даже в случае перехода TLS на новые ключи.

Каждый уровень шифрования соответствует пространству номеров пакетов. Используемое пространство номеров определяет семантика кадра. Некоторые кадры запрещены в разных пространствах номеров (см. параграф 12.5 в [QUIC-TRANSPORT]).

Поскольку порядок пакетов может меняться при передаче, QUIC использует тип пакета для указания ключей, использованных для защиты данного пакета, как показано в таблице 1. Когда нужно передать пакеты разных типов, конечным точкам следует объединять их для отправки в одной дейтаграмме UDP.

Таблица 1. Ключи шифрования по типам пакетов.

Тип пакета

Ключи шифрования

Пространство номеров

Initial

Initial secrets

Initial

0-RTT Protected

0-RTT

Application data

Handshake

Handshake

Handshake

Retry

Retry

N/A

Version Negotiation

N/A

N/A

Short Header

1-RTT

Application data

В разделе 17 [QUIC-TRANSPORT] показано использование пакетов с разным уровнем шифрования при согласовании.

4.1. Интерфейс с TLS

Как показано на рисунке 4, интерфейс из QUIC в TLS поддерживает четыре основных функции:

  • передача и приём сообщений в процессе согласования;

  • обработка сохранённого состояния транспорта и приложения из возобновляемой сессии и определение их пригодности для генерации или восприятия данных 0-RTT;

  • смена ключей (отправка и приём);

  • обновление статуса согласования.

Для настройки TLS могут потребоваться дополнительные функции. В частности, QUIC и TLS нужно согласовать ответственность за проверку свидетельств партнёра, такую как проверка сертификатов [RFC5280].

4.1.1. Завершение согласования

В этом документе согласование TLS считается завершённым, когда об этом сообщает стек TLS. Это происходит, когда стек TLS передал сообщение Finished и проверил сообщение Finished от партнёра. Проверка партнерского сообщения Finished обеспечивает конечной точке гарантию неизменности предшествующих сообщения согласования. Отметим, что точки не завершают согласование одновременно, поэтому любые требования, основанные на завершении согласования, зависят от соответствующей конечной точки.

4.1.2. Подтверждение согласования

В этом документе согласование TLS считается подтверждённым на сервере после его завершения. Сервер должен передать кадр HANDSHAKE_DONE, как только согласование завершится. Клиент считает согласование завершённым после получения кадра HANDSHAKE_DONE.

Кроме того, клиент может считать согласование завершённым, получив подтверждение для пакета 1-RTT. Это может быть реализовано путём записи наименьшего порядкового номера пакета, переданного с ключами 1-RTT, и сравнения его с Largest Acknowledged в любом принятом кадре 1-RTT ACK – большее значение последнего подтверждает согласование.

4.1.3. Отправка и получение сообщений Handshake

При управлении согласованием TLS зависит способности передавать и принимать сообщения Handshake. На этом интерфейсе имеются две основных функции – запрос сообщений от QUIC и предоставление протоколом QUIC байтов, образующих сообщения Handshake.

Перед началом согласования QUIC предоставляет протоколу TLS транспортные параметры (см. параграф 8.2), которе он хочет передать. Клиент QUIC запускает TLS, запрашивая байты согласования TLS у протокола TLS, которые он получает до отправки своего первого пакета. Сервер QUIC запускает процесс, предоставляя протоколу TLS байты согласования от клиента.

Стек TLS на конечной точке в любой момент будет иметь текущий уровень шифрования передачи и приёма. Уровни шифрования TLS определяют тип пакета QUIC и применяемые для защиты данных ключи. Каждый уровень шифрования связан со своей последовательностью байтов, которая гарантированно передаётся партнёру в кадрах CRYPTO. Когда TLS предоставляет байты согласования для передачи, они добавляются в конец байтов согласования для текущего уровня шифрования. После этого уровень шифрования определяет тип пакета, в котором будет передаваться кадр CRYPTO (см. таблицу 1).

Применяются 4 уровня шифрования, создающих ключи для пакетов Initial, 0-RTT, Handshake и 1-RTT. Кадры CRYPTO передаются только на трёх уровнях (без 0-RTT). Этим 4 уровням соответствуют три пространства номеров пакетов – пакеты Initial используют отдельные пространства, а 0-RTT и 1-RTT – пространство данных приложения.

QUIC принимает незащищённое содержимое записей согласования TLS как содержимое кадров CRYPTO. Защита записей TLS не используется в QUIC. Кадры CRYPTO протокол QUIC собирает в пакеты QUIC, для которых применяется защита пакетов QUIC.

Кадры QUIC CRYPTO передают лишь сообщения согласования TLS. Сигналы TLS преобразуются в коды ошибок QUIC CONNECTION_CLOSE (см. параграф 4.8). Данные приложения TLS и другие типы содержимого не могут транспортироваться протоколом QUIC на любом из уровней шифрования и получение их от стека TLS является ошибкой.

При получении пакета QUIC с кадром CRYPTO из сети конечная точка выполняет указанные ниже действия.

  • Если пакет использует текущий уровень шифрования приёма TLS, данные во входном потоке упорядочиваются как обычно. Как и в кадрах STREAM, смещение служит для нахождения конкретного места последовательности данных. Если в результате этого процесса становятся доступными новые данные, они доставляются TLS по порядку.

  • Если пакет относится к установленному ранее уровню шифрования, ему недопустимо содержать данные, которые выходят за пределы полученных ранее в этом потоке. Реализация должна считать нарушение этого требования ошибкой соединения типа PROTOCOL_VIOLATION.

  • Если пакет относится к новому уровню шифрования, но сохраняется для последующей обработки в TLS. Как только TLS перейдёт к приёму с этого уровня шифрования, сохранённые данные могут быть представлены TLS. Когда TLS предоставляет ключи для более высокого уровня шифрования наличие данных от предыдущего уровня шифрования, не потреблённых TLS, доено считаться ошибкой соединения PROTOCOL_VIOLATION.

Каждый раз, когда TLS предоставляет новые данные, запрашиваются новые байты согласования от TLS. Протокол TLS может не предоставить байтов, если полученные сообщения согласования неполны или нет данных для передачи.

Содержимое кадров CRYPTO может обрабатываться TLS постепенно или буферизоваться до полного приёма сообщений. TLS отвечает за буферизацию байтов согласования, полученных с соблюдением порядка. QUIC отвечает за буферизацию байтов согласования, полученных с нарушением порядка или для уровня шифрования, который ещё не готов. QUIC не предоставляет средств управления потоком кадров CRYPTO (см. параграф 7.5 [QUIC-TRANSPORT]).

Завершение согласования TLS указывается протоколу QUIC вместе с финальными байтами согласования, которые TLS требуется передать. На этом этапе проверяется подлинность транспортных параметров, анонсированных партнёром при согласовании (см. параграф 8.2).

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

По завершении согласования протоколу QUIC нужно лишь представить в TLS любые данные, прибывшие в потоках CRYPTO. Таким же способом, который применялся при согласовании, новые данные запрашиваются у TLS после предоставления принятых данных.

4.1.4. Смена уровня шифрования

Когда ключи данного уровня шифрования становятся доступными TLS, протокол TLS указывает QUIC, что ключи чтения и записи данного режима шифрования доступны. Доступность новых ключей всегда является результатом ввода данных в TLS. Протокол TLS предоставляет новые ключи лишь после инициализации (клиентом) или при предоставлении новых данных согласования.

Однако реализация TLS может выполнять часть обработки асинхронно. В частности, процесс проверки сертификата может занимать некоторое время. В ожидании завершения обработки TLS конечной точке следует буферизовать полученные пакеты, если они могут быть обработаны с ключами, которые пока ещё не доступны. Эти пакеты можно будет обработать после предоставления ключей протоколом TLS. Конечной точке следует продолжать отвечать на пакеты, которые могут быть обработаны в это время.

После обработки входных данных TLS может создавать байты согласования, ключи для новых уровней шифрования или то и другое вместе. TLS предоставляет протоколу QUIC 3 элемента, когда новый уровень шифрования становится доступным:

  • секрет;

  • функция аутентифицированного шифрования со связанными данными (Authenticated Encryption with Associated Data или AEAD);

  • функция вывода ключа (Key Derivation Function или KDF).

Эти значения основаны на согласуемых TLS значениях и применяются QUIC в Handshake Confirmed для генерации ключей защиты пакета и заголовков (см. раздел 5 и параграф 5.4).

0-RTT (при возможности) готов к использованию после того, как клиент передаст сообщение TLS ClientHello или сервер получит его. После предоставления клиенту QUIC первых байтов согласования стек TLS может сигнализировать смену ключей 0-RTT. На сервере после получения байтов согласования с сообщением ClientHello сервер TLS может сигнализировать доступность ключей 0-RTT.

Хотя TLS в каждый момент использует лишь один уровень шифрования, QUIC может использовать несколько. Например, после отправки сообщения Finished (с использованием кадра CRYPTO на уровне шифрования Handshake) конечная точка может передать данные STREAM (шифрование 1-RTT). Если сообщение Finished теряется, конечная точка использует уровень шифрования Handshake для повторной передачи потерянного сообщения. Нарушение порядка или потеря пакетов могут означать для QUIC необходимость обрабатывать пакеты с разными уровнями шифрования. В процессе согласования это означает возможность обработки пакетов с более высоким и более низким уровнем шифрования по сравнению с текущим уровнем, используемым TLS.

В частности, реализациям сервер нужна возможность чтения пакетов с уровнем шифрования Handshake одновременно с уровнем 0-RTT. Клиент может чередовать кадры ACK, защищённые ключами Handshake и данных 0-RTT, а серверу нужно обрабатывать эти подтверждения для обнаружения потери пакетов Handshake.

Для QUIC нужен также доступ к ключам, которые обычно могут быть недоступны реализации TLS. Например, клиенту может потребоваться подтвердить пакеты Handshake, прежде чем он будет готов передать кадры CRYPTO с этим уровнем шифрования. Поэтому TLS нужно предоставить эти ключи протоколу QUIC, прежде чем он создаст их для своего использования.

4.1.5. Сводка по интерфейсу TLS

На рисунке 5 показан обмен между QUIC и TLS для клиента и сервера. Сплошные стрелки указывают пакеты с данными согласования, пунктирные – пакеты с данными приложения. Каждая стрелка помечена применяемым уровнем шифрования.

На рисунке показано несколько пакетов, образующих одну отправку (flight) сообщений, которые обрабатываются по отдельности, для демонстрации разных действий, вызываемых входящими сообщениями. Это показано несколькими вызовами Get Handshake для извлечения сообщений с разными уровнями шифрования. Новые сообщения согласования запрашиваются после обработки входящих пакетов.

Клиент                                                    Сервер
======                                                    ======
Get Handshake
                     Initial ------------->
Install tx 0-RTT keys
                     0-RTT - - - - - - - ->

                                              Handshake Received
                                                   Get Handshake
                     <------------- Initial
                                           Install rx 0-RTT keys
                                          Install Handshake keys
                                                   Get Handshake
                     <----------- Handshake
                                           Install tx 1-RTT keys
                     <- - - - - - - - 1-RTT Handshake Received (Initial) Install Handshake keys Handshake Received (Handshake) Get Handshake Handshake ----------->
Handshake Complete
Install 1-RTT keys
                     1-RTT - - - - - - - ->

                                              Handshake Received
                                              Handshake Complete
                                             Handshake Confirmed
                                           Install rx 1-RTT keys
                     <--------------- 1-RTT
                           (HANDSHAKE_DONE)
Handshake Confirmed

Рисунок 5. Сводка взаимодействия между QUIC и TLS.


Рисунок 5 иллюстрирует одну из простых структур для одного обмена при согласовании. Точный процесс зависит от структуры реализации конечных точек и порядка прибытия пакетов. Реализации могут использовать иное число операций или выполнять их в другом порядке.

4.2. Версия TLS

Этот документ описывает использование TLS 1.3 [TLS13] с QUIC. На практике согласование TLS выбирает версию протокола TLS для применения. Это может приводит к выбору версии новее TLS 1.3, если обе конечных точки поддерживают её. Это приемлемо, если функции TLS 1.3, используемые QUIC, поддерживаются новой версией.

Клиентам недопустимо предлагать версии TLS до 1.3. некорректно настроенная реализация TLS может согласовать TLS 1.2 или другую старую версию. Конечная точка должна прервать соединение при согласовании версии TLS до 1.3.

4.3. Размер ClientHello

Первый пакет Initial от клиента содержит начало или все первое сообщение криптографического согласования, которым для TLS является ClientHello. Серверам может потребоваться синтаксический анали всего ClientHello (например, для доступа к таким расширениям, как SNI3 или ALPN4) для принятия решения о восприятии нового входящего соединения QUIC. Если сообщение ClientHello разделено между несколькими пакетами Initial, серверу придётся буферизовать полученные в начале фрагменты, что может потребовать избыточных ресурсов, если адрес клиента ещё не проверен. Для предотвращения этого серверы могут использовать свойство Retry (см. параграф 8.1 в [QUIC-TRANSPORT]) для буферизации частичных сообщений ClientHello лишь от клиентов с проверенным адресом.

Пакет QUIC и кадрирование добавляют по меньшей мере 36 байтов к размеру сообщения ClientHello. Эти издержки возрастают при выборе клиентом непустого поля Source Connection ID. Издержки не включают маркер и Destination Connection ID длиннее 8 байтов, которые могут потребоваться, если сервер передал пакет Retry.

Типичное сообщение TLS ClientHello может легко поместиться в пакет размером 1200 байтов, однако в дополнение к издержкам QUIC имеется несколько переменных, которые могут вызвать превышение этого размера. Большие сеансовые квитанции, большие или многочисленные общие ключи, длинные списки поддерживаемых шифров, алгоритмов подписи, версий, транспортных параметров QUIC и другие согласуемые параметры и расширения ведут к росту сообщения.

Для серверов, помимо идентификаторов соединения и маркеров, на способность клиента подключиться может влиять размер сеансовых квитанций TLS. Минимизация размера этих параметров повышает вероятность применимости их для клиента и размещения всего сообщения ClientHello в первом пакете Initial.

Реализация TLS не обязана гарантировать, что сообщение ClientHello достаточно велико в соответствии с требованиями QUIC для дейтаграмм с пакетом Initial (см. параграф 14.1 в [QUIC-TRANSPORT]). Реализации QUIC используют кадры PADDING или объединение пакетов для увеличения размера дейтаграмм.

4.4. Проверка подлинности партнёра.

Требования к аутентификации зависят от применяемого прикладного протокола. TLS обеспечивает проверку подлинности сервера и позволяет серверам проверить подлинность клиентов. Клиент должен проверять подлинность сервера. Обычно это включает проверку включения идентификации сервера в сертификат и выпуск сертификата доверенной организацией (см. пример в [RFC2818]).

Примечание. Если сервер предоставляет сертификаты для аутентификации, размер цепочки сертификатов может быть достаточно большим. Контролирование размера цепочек сертификатов очень важно для производительности QUIC, поскольку серверы могут передавать не более 3 байтов в ответ на каждый полученный байт, пока адрес клиента не проверен (см. параграф 8.1 в [QUIC-TRANSPORT]). Размер цепочки сертификатов можно сократить, ограничивая число имён или расширений, используя компактное представление открытых ключей, подобное ECDSA, или сжимая сертификаты [COMPRESS].

Сервер может запросить проверку подлинности клиента в процессе согласования. Сервер может отвергать клиентов, которых невозможно аутентифицировать по запросу. Требования к аутентификации клиента зависят от прикладного протокола и развёртывания.

Серверу недопустимо проверять подлинность клиента после согласования (как указано в параграфе 4.6.2 [TLS13]), поскольку мультиплексирование в QUIC не позволяет клиентам сопоставить запрос сертификата с вызвавшим его событием на уровне приложения (см. [HTTP2-TLS13]). Более конкретно, серверам недопустимо передавать сообщения TLS CertificateRequest после согласования, а клиенты должны считать получение такого сообщения ошибкой соединения типа PROTOCOL_VIOLATION.

4.5. Возобновление сессии

QUIC может использовать функцию восстановления сессии TLS 1.3. Это делается путём передачи сообщений NewSessionTicket в кадрах CRYPTO после завершения согласования. Возобновление сессии моно использовать для обеспечения 0-RTT даже при отключённом 0-RTT.

Конечным точкам, возобновляющим сессию, может потребоваться запомнить некую информацию о текущем соединении при создании возобновлённого соединения. TLS требует сохранения некой информации (см. параграф 4.6.1 в [TLS13]). Протокол QUIC не зависит от сохранения какого-либо состояния при возобновлении соединения, пока не применяется 0-RTT (см. параграф 7.4.1 в [QUIC-TRANSPORT] и параграф 4.6.1). Протокол приложения может зависеть от состояния, сохраняемого между соединениями.

Клиенты могут сохранять состояние, требуемое для возобновления, вместе с сеансовой квитанцией, а серверы могут использовать такую квитанцию для переноса состояния.

Возобновление сессии помогает серверам связывать действия в исходном соединении с возобновляемым, что может создавать для клиентов проблемы приватности. Клиенты могут отказаться от возобновления сессий для предотвращения такого сопоставления. Клиентам не следует повторно применять квитанции, поскольку это может помочь сторонним объектам сопоставить соединения (см. Приложение C.4 к [TLS13]).

4.6. 0-RTT

0-RTT в QUIC позволяет клиенту передать данные приложения до того, как будет завершено согласование. Это позволяет повторно использовать согласованные параметры из предыдущего соединения. Для поддержки этого 0-RTT зависит от запоминания клиентом важных параметров и предоставления серверу сеансовой квитанции TLS, позволяющей тому восстановить информацию. Эти сведения включают параметры, определяющие состояние TLS в соответствии с [TLS13], транспортные параметры QUIC, выбранный протокол приложения и любые данные, которые могут быть нужны приложению (см. параграф 4.6.3). Эта информация определяет формирование и содержимое пакетов 0-RTT.

Для обеспечения доступности одних сведений обеим конечным точкам вся информация, используемая для организации 0-RTT, берётся из одного соединения. Конечные точки не могут выборочно игнорировать данные, которые могут влиять на передачу или обработку 0-RTT.

[TLS13] устанавливает 7-дневное ограничение между исходным соединением и попыткой использования 0-RTT. Имеются и другие ограничения для применения 0-RTT, в частности связанные с возможностью replay-атак (см. параграф 9.2).

4.6.1. Включение 0-RTT

Определено расширение TLS early_data в сообщении NewSessionTicket для передачи (в параметре max_early_data_size) объема данных TLS 0-RTT, которые сервер готов воспринять. QUIC не использует ранние данные TLS, применяя для передачи таких данных пакеты 0-RTT. Соответственно, параметр max_early_data_size переназначен для контрольного значения 0xffffffff, указывающего, что сервер готов воспринимать данные QUIC 0-RTT. Отсутствие расширения early_data в NewSessionTicket говорит о нежелании сервера принимать данные 0-RTT. Объем данных, которые клиент может передать в QUIC 0-RTT, задаёт переданный сервером параметр initial_max_data.

Серверам недопустимо передавать расширение early_data с полем max_early_data_size, отличным от 0xffffffff. Клиент должен считать получение NewSessionTicket с расширением early_data, содержащим иное значение, ошибкой соединения типа PROTOCOL_VIOLATION.

Клиент, желающий передавать пакеты 0-RTT, использует расширение early_data в сообщении ClientHello последующего согласования (см. параграф 4.2.10 в [TLS13]) и затем передаёт данные в пакетах 0-RTT.

Клиент, пытающийся передать 0-RTT, может также предоставить маркер проверки адреса, если сервер передал ему пакет NEW_TOKEN (см. параграф 8.1 в [QUIC-TRANSPORT]).

4.6.2. Восприятие и отклонение 0-RTT

Сервер воспринимает 0-RTT, отправляя расширение early_data в EncrypteEncryptedExtensions (см. параграф 4.2.10 в [TLS13]). После этого сервер обрабатывает и подтверждает получаемые пакеты 0-RTT. Чтобы отвергнуть 0-RTT, сервер передаёт EncryptedExtensions без расширения early_data. Сервер всегда будет отвергать 0-RTT, если он передал TLS HelloRetryRequest. Отвергающему 0-RTT серверу недопустимо обрабатывать пакеты 0-RTT, даже когда он способен делать это. Если пакеты 0-RTT отвергнуты, клиенту следует считать приём подтверждения пакета 0-RTT ошибкой соединения PROTOCOL_VIOLATION, если он может обнаруживать это условие.

Когда 0-RTT отвергается, все характеристики соединения, предполагаемые клиентом, могут быть некорректными. Это включает выбор прикладного протокола, транспортные параметры и конфигурацию приложения. Поэтому клиент должен сбросить состояния всех потоков и связанные с потоками состояния соединений.

Клиент может повторить попытку 0-RTT при получении пакета Retry или Version Negotiation. Эти пакеты не означают отказа от 0-RTT.

4.6.3. Проверка конфигурации 0-RTT

При получении сервером ClientHello с расширением early_data он должен принять решение о восприятии или отклонении 0-RTT от клиента. Отчасти решение определяет стек TLS (например, проверка наличия возобновляемого шифра в ClientHello, см. параграф 4.2.10 в [TLS13]). Даже при отсутствии у стека TLS причин отвергать 0-RTT, стек QUIC или прикладной протокол, использующий QUIC, может отклонить данные 0-RTT по причине несовместимости конфигурации транспорта или приложения, связанной с возобновляемым соединением, с текущей настройкой сервера.

QUIC требует связывания дополнительного состояния транспорта с сеансовой квитанцией 0-RTT. Одним из основных способов реализации этого является использование сеансовых квитанций без учёта состояния и сохранение состояния в этой квитанции. Прикладной протокол, использующий QUIC, может иметь похожие требования в части связывания или сохранения статуса. Это связанное состояние применяется при решении вопроса об отклонении 0-RTT. Например, настройки HTTP/3 [QUIC-HTTP] могут определять интерпретацию клиентских данных 0-RTT. Другие приложения, использующие QUIC, могут иметь свои требования в части восприятия или отклонения данных 0-RTT.

4.7. HelloRetryRequest

Сообщение HelloRetryRequest (см. параграф 4.1.4 в [TLS13]) может служить для запроса у клиента новых сведений, таких как общий ключ, или для проверки некоторых характеристик клиента. С точки зрения QUIC сообщение HelloRetryRequest не отличается от других сообщений криптографического согласования, передаваемых в пакетах Initial. Хотя это свойство можно применять для проверки адреса, реализациям QUIC следует использовать для этого Retry (см. параграф 8.1 в [QUIC-TRANSPORT]).

4.8. Ошибки TLS

При возникновении ошибки TLS генерирует сигнал в соответствии с разделом 6 в [TLS13], который преобразуется в ошибку соединения QUIC. Значение AlertDescription добавляется к 0x0100 для создания кода ошибки QUIC из диапазона для CRYPTO_ERROR (параграф 20.1 в [QUIC-TRANSPORT]) и полученное значение передаётся в кадре QUIC CONNECTION_CLOSE типа 0x1c.

QUIC может передавать лишь сигналы критического уровня (fatal). В TLS 1.3 единственным применением уровня предупреждения (warning) является сигнализация о закрытии соединения (параграф 6.1 в [TLS13]). QUIC поддерживает другие механизмы прерывания соединений, а соединение TLS закрывается лишь при ошибке и конечная точка QUIC должна считать любой сигнал от TLS, как сигнал уровня fatal.

QUIC позволяет использовать созданный код вместо конкретного кода ошибки (см. раздел 11 в [QUIC-TRANSPORT]). Для сигналов TLS это включает замену любого сигнала базовым, таким как handshake_failure (0x0128 в QUIC). Конечные точки могут использовать базовый код ошибки для предотвращения возможного раскрытия конфиденциальных сведений.

4.9. Отбрасывание неиспользуемых ключей

После перехода QUIC на новый уровень шифрования ключи предыдущего уровня можно отбросить. Это происходит несколько раз в процессе согласования, а также при обновлении ключей (6. Обновление ключей).

Ключи защиты пакетов не отбрасываются сразу же при появлении новых ключей. Если пакеты из прежнего уровня шифрования содержат кадры CRYPTO, кадры с повтором данных должны передаваться с тем же уровнем шифрования. Точно также конечная точка генерирует подтверждения пакетов на том же уровне, что и в подтверждаемых пакетах. Таким образом, ключи более низкого уровня шифрования могут быть нужны в течение короткого времени после появления ключей для более нового уровня шифрования.

Конечная точка не может отбросить ключи для данного уровня шифрования, пока она не получит от партнёра все сообщения криптографического согласования на данном уровне от своего партнёра и партнёр не сделает то же самое. Для ключей Initial (параграф 4.9.1) и Handshake (параграф 4.9.2) предусмотрены другие методы контроля отбрасывания. Эти методы не препятствуют приёму или отправке пакетов на данном уровне шифрования, поскольку партнёр мог не получить все требуемые подтверждения.

Хотя конечная точка может сохранять старые ключи, новые данные должны передаваться с наивысшим доступным уровнем шифрования, а прежний уровень можно применять лишь для кадров ACK и данных, повторяемых в кадрах CRYPTO. Такие пакеты могут также включать кадры PADDING.

4.9.1. Отбрасывание ключей Initial

Пакеты, защищённые секретами Initial (параграф 5.2), не аутентифицируются, что позволяет злоумышленнику подделать пакеты с намерением нарушить соединение. Для ограничения таких атак ключи защиты пакетов Initial отбрасываются более активно, чем другие ключи.

Успешное использование пакетов Handshake показывает, что обмен пакетами Initial больше не требуется, поскольку нужные для этого ключи могут создаваться лишь после получения всех кадров CRYPTO из пакетов Initial. Поэтому клиент должен отбросить ключи Initial при первой отправке пакета Handshake, а сервер должен отбросить эти ключи при первой успешной обработке пакета Handshake. После этого конечным точкам недопустимо передавать пакеты Initial.

Это ведёт к отказу от состояния восстановления потерь для уровня шифрования Initial и игнорированию оставшихся пакетов Initial.

4.9.2. Отбрасывание ключей Handshake

Конечная точка должна отбросить ключи Handshake после подтверждения согласования TLS (параграф 4.1.2).

4.9.3. Отбрасывание ключей 0-RTT

Пакеты 0-RTT и 1-RTT используют общее пространство номеров и клиенты не передают пакеты 0-RTT после отправки 1-RTT (параграф 5.6). Поэтому клиенту следует отбрасывать ключи 0-RTT, как только он установит ключи 1-RTT.

Кроме того, сервер может отбросить ключи 0-RTT, как только получит пакет 1-RTT. Однако в результате нарушения порядка пакеты 0-RTT могут приходить после 1-RTT. Сервер может временно сохранить ключи 0-RTT для обработки доставленных с нарушением порядка пакетов без необходимости повторять их содержимое с ключами 1-RTT. После приёма пакета 1-RTT сервер должен отбрасывать пакеты 0-RTT по истечении короткого времени, для которого рекомендуется устанавливать утроенное значение тайм-аута зондирования (Probe Timeout или PTO, см. [QUIC-RECOVERY]). Сервер может начать отбрасывание 0-RTT раньше, если он понимает, что все пакеты 0-RTT получены, что можно определить путём отслеживания пропущенных номеров.

5. Защита пакета

Как и TLS про протоколу TCP, QUIC защищает пакеты с помощью ключей, выведенных из согласования TLS с использованием алгоритма AEAD [AEAD] согласованного TLS. Защита пакетов QUIC зависит от их типа:

  • для пакетов Version Negotiation криптографическая защита не применяется;

  • пакеты Retry используют AEAD_AES_128_GCM для защиты от случайного изменения и ограничения числа объектов, которые могут создавать действительные пакеты Retry (см. параграф 5.8);

  • пакеты Initial применяют AEAD_AES_128_GCM с ключами, выведенными из поля Destination Connection ID в первом пакете Initial от клиента (см. параграф 5.2);

  • для всех остальных пакетов используется строгая криптографическая защита конфиденциальности и целостности с использованием ключей и алгоритмов, согласованных TLS.

В этом разделе описано применение защиты к пакетам Handshake, 0-RTT и 1-RTT. Такая же защита используется для пакетов Initial. Однако определить ключи защиты пакетов Initial несложно, поэтому конфиденциальность и целостность их не считается защищённой. Пакеты Retry используют фиксированный ключ и также не защищены в части конфиденциальности и целостности.

5.1. Ключи защиты пакета

QUIC выводит ключи защиты пакетов таким же способом, как TLS выводит ключи защиты записей.

Каждый уровень шифрования имеет свои секретные значения для защиты пакетов в каждом направлении. Эти секреты трафика выводятся TLS (см. параграф 7.1 и [TLS13]) и применяются QUIC для всех уровней шифрования кроме уровня Initial. Секреты для уровня шифрования Initial рассчитываются на основе исходного значения Destination Connection ID, полученного от клиента, как описано в параграфе 5.2.

Ключи защиты пакетов рассчитываются из секретов TLS с использованием функции KDF, предоставляемой TLS. В TLS 1.3 применяется функция HKDF-Expand-Label, описанная в параграфе 7.1 [TLS13], с хэш-функцией из согласованного шифронабора. При любом применении HKDF-Expand-Label в QUIC используется Context нулевого размера (пустой). Отметим, что метки, описываемые строками, кодируются как байты с использованием кодировки ASCII [ASCII] без кавычек и NUL-байта в конце.

Другие версии TLS должны предоставлять похожую функцию для использования в QUIC.

Секрет текущего уровня шифрования и метка quic key служат входными данными KDF для создания ключа AEAD, а метка quic iv служит для вывода вектора инициализации (Initialization Vector или IV, см. параграф 5.3). Ключ защиты заголовка использует метку quic hp (см. параграф 5.4). Применение меток обеспечивает разделение ключей QUIC и TLS (см. параграф 9.6).

Метки quic key и quic hp применяются для создания ключей, поэтому размер Length, предоставляемый HKDF-Expand-Label, вместе с этими метками определяется размером ключей в AEAD или алгоритме защиты заголовка. Length для quic iv является минимальным размером AEAD nonce или составляет 8 байтов, если тот больше [AEAD].

KDF, используемой для начальных секретов, всегда служит функция HKDF-Expand-Label из TLS 1.3 (см. параграф 5.2).

5.2. Секреты Initial

Пакеты Initial используют защиту, но секрет выводится из поля Destination Connection ID в первом пакете Initial от клиента. Этот секрет определяется использованием HKDF-Extract (см. параграф 2.2 в [HKDF]) с затравкой (salt) 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a и входным ключевым материалом (input keying material или IKM) из поля Destination Connection ID. В результате создаётся промежуточный псевдослучайный ключ (pseudorandom key или PRK), применяемый для создания двух секретов, используемых при передаче и приёме.

Секрет, применяемый клиентами при создании пакетов Initial, использует PRK и метку client in как входные данные функции HKDF-Expand-Label из TLS [TLS13] для создания 32-байтового секрета. В создаваемых сервером пакетах применяется тот же процесс с меткой server in. Хэш-функцией для HKDF при создании начальных секретов служит SHA-256 [SHA]. Псевдокод процесса приведён ниже.

   initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
   initial_secret = HKDF-Extract(initial_salt, client_dst_connection_id)

   client_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "client in", "",
                                             Hash.length)
   server_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "server in", "",
                                             Hash.length)

Идентификатор соединения, используемый с HKDF-Expand-Label, – это Destination Connection ID из пакета Initial, переданного клиентом. Это поле содержит случайное значение, если клиент не создаёт пакет Initial после получения пакета Retry, где значение Destination Connection ID выбрано сервером.

Будущим версиям QUIC следует применять новое значение затравки, чтобы ключи отличались в разных версиях QUIC. Это не позволит промежуточному устройству, распознающему лишь одну версию QUIC, просматривать или изменять содержимое пакетов будущих версий. Функция HKDF-Expand-Label из TLS 1.3 должна применяться для пакетов Initial даже при отсутствии TLS 1.3 среди предлагаемых версий TLS.

Секреты, применяемые для создания последующих пакетов Initial, меняются, когда сервер передает пакет Retry с выбранным им идентификатором соединения. Секреты не меняются при изменении клиентом значения Destination Connection ID, используемого им в ответ на пакет Initial от сервера.

Примечание. Поле Destination Connection ID может иметь любой размер до 20 байтов, включая 0, если сервер передал пакет Retry с пустым полем Source Connection ID. После Retry ключи Initial не обеспечивают клиенту гарантии получения его пакета сервером, поэтому клиенту приходиться полагаться на обмен, включающий пакет Retry, для проверки адреса сервера (см. параграф 8.1 в [QUIC-TRANSPORT]).

Примеры пакетов Initial представлены в Приложении A.

5.3. Применение AEAD

Функция AEAD [AEAD], применяемая для защиты пакетов QUIC, является AEAD, согласованной для использования в соединении TLS. Например, если TLS использует шифр TLS_AES_128_GCM_SHA256, будет применяться функция AEAD_AES_128_GCM.

QUIC может применять любой шифронабор, заданный в [TLS13], за исключением TLS_AES_128_CCM_8_SHA256. Недопустимо согласовывать шифр, для которого не определена схема защиты заголовков. Этот документ определяет схему защиты заголовков для всех шифров, заданных в [TLS13], кроме TLS_AES_128_CCM_8_SHA256. Эти шифры имеют 16-байтовый тег аутентификации и дают на выходе рост на 16 байтов по сравнению со входными данными.

Конечной точке недопустимо отвергать сообщение ClientHello, предлагающее неподдерживаемый шифр, поскольку это не позволит развёртывать новые шифронаборы. Это применимо и к шифру TLS_AES_128_CCM_8_SHA256.

При создании пакетов функция AEAD применяется до защиты заголовка (см. параграф 5.4). Незащищённый заголовок является частью связанных данных (associated data или A). При обработке пакетов конечная точка сначала снимает защиту заголовка.

Ключ и IV для пакета рассчитываются в соответствии с параграфом 5.1. Значение nonce (N) формируется путём объединения IV защиты пакета с номером пакета. 62 бита восстановленного номера пакета QUIC в сетевом порядке байтов дополняются слева нулями до размера IV. После этого применяется операция «исключительное ИЛИ» (XOR) к дополненному номеру пакета и IV для создания AEAD.

Связанными данными (A) для AEAD является содержимое заголовка QUIC, начиная с первого байта короткого или длинного заголовка и заканчивая незащищённым номером пакета (включительно). Входными открытыми данными (plaintext или P) для AEAD служит содержимое (payload) пакета QUIC, как описано в [QUIC-TRANSPORT]. Выходной шифротекст (ciphertext или C) функции AEAD передаётся в пакете вместо P.

Некоторые функции AEAD имеют ограничения на число пакетов, шифруемых с одним ключом и IV (см. параграф 6.6). Этот предел может быть меньше предельного числа пакетов. Конечная точка должна запустить обновление ключей (раздел 6) до достижения предела, установленного для используемой функции AEAD.

5.4. Защита заголовка

Поля заголовка пакетов QUIC, в частности, Packet Number, защищаются с использованием ключа, выведенного отдельно от ключа защиты пакета и IV. Ключ выводится с использованием метки quic hp и применяется для защиты конфиденциальности полей, не раскрываемых элементам пути доставки.

Эта защита применяется для младших битов первого байта и полю Packet Number. Для пакетов с длинным заголовком защищаются 4 младших бита первого байта, для пакетов с коротким заголовком – 5. Для обоих вариантов заголовка это включает резервные биты и поле Packet Number Length, а для короткого заголовка – бит Key Phase.

В течение срока соединения применяется один ключ защиты заголовков без смены при обновлении ключей (раздел 6). Это позволяет защитить заголовок в Key Phase. Процесс защиты не применяется для пакетов Retry и Version Negotiation, которые не включают защищаемых данных или полей заголовков.

5.4.1. Применение защиты заголовка

Защита заголовка применяется после защиты пакета (см. параграф 5.3). Делается выборка шифрованного содержимого пакета, которая служит вводом для алгоритма шифрования. Алгоритм зависит от согласования AEAD. Выходом алгоритма является 5-байтовая маска, применяемая к защищаемым полям заголовка в операции «исключительное ИЛИ» (XOR). Младшие биты первого байта пакета маскируются младшими битами первого байта маски, а порядковый номер – её. оставшимися байтами. Лишние биты маски (если номер короткий) не применяются.

На рисунке 6 показан пример алгоритма для защиты заголовка. Снятие защиты заголовка отличается лишь порядком определения размера номера пакета (pn_length), ^ представляет операцию XOR.

   mask = header_protection(hp_key, sample)

   pn_length = (packet[0] & 0x03) + 1
   if (packet[0] & 0x80) == 0x80:
      # Long header: 4 bits masked
      packet[0] ^= mask[0] & 0x0f
   else:
      # Short header: 5 bits masked
      packet[0] ^= mask[0] & 0x1f

   # pn_offset – начало поля Packet Number.
   packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]

Рисунок 6. Псевдокод защиты заголовка.


Конкретные функции защиты заголовка определяются на основе выбранного шифра (см. параграфы 5.4.3 и 5.4.4).

На рисунке 7 показан пример пакетов с длинным (Initial) и коротким (1-RTT) заголовком и указаны поля в каждом заголовке, охватываемые защитой, а также выбираемые части защищённого пакета.

   Initial Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 0,
     Reserved Bits (2),         # Защищено
     Packet Number Length (2),  # Защищено
     Version (32),
     DCID Len (8),
     Destination Connection ID (0..160),
     SCID Len (8),
     Source Connection ID (0..160),
     Token Length (i),
     Token (..),
     Length (i),
     Packet Number (8..32),     # Защищено
     Protected Payload (0..24), # Пропускается
     Protected Payload (128),   # Выбирается
     Protected Payload (..)     # Остальное
   }

   1-RTT Packet {
     Header Form (1) = 0,
     Fixed Bit (1) = 1,
     Spin Bit (1),
     Reserved Bits (2),         # Защищено
     Key Phase (1),             # Защищено
     Packet Number Length (2),  # Защищено
     Destination Connection ID (0..160),
     Packet Number (8..32),     # Защищено
     Protected Payload (0..24), # Пропускается
     Protected Payload (128),   # Выбирается
     Protected Payload (..),    # Остальное
   }

Рисунок 7. Пример защиты заголовка и шифротекста.


До того, как шифр TLS можно будет применять в QUIC, должен быть задан алгоритм защиты заголовка и AEAD, используемый с этим шифром. Этот документ задаёт алгоритмы AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM (AES AEAD, определённые в [AEAD]) и AEAD_CHACHA20_POLY1305 (определён в [CHACHA]). До выбора шифронабора TLS применяется защита заголовка AES (параграф 5.4.3), соответствующая защите пакета AEAD_AES_128_GCM.

5.4.2. Пример защиты заголовка

Алгоритм защиты заголовка использует ключ защиты заголовка и выборку шифротекста из поля Payload в пакете. Отбирается всегда одинаковое количество данных, но необходимо учитывать снятие защиты на приёмной стороне, которая не знает размер поля Packet Number. Выборка шифрованных данных начинается со смещением 4 байта от начала поля Packet Number, т. е. при выборке предполагается 4-байтовое поле Packet Number (максимальный размер).

Конечная точка должна отбрасывать пакеты, размера которых недостаточно для полной выборки. Для обеспечения достаточного размера выборки пакеты дополняются так, суммарный размер кодированного номера пакета и шифрованного содержимого по меньшей мере на 4 байта превышает размер требуемой для защиты заголовка выборки. Шифры, заданные в [TLS13] (кроме TLS_AES_128_CCM_8_SHA256, не применяемого в схеме защиты заголовка) имеют 16-байтовые расширения и 16-байтовую выборку для защиты заголовка. Это требует по меньшей мере 3 байтов в кадрах незащищённого содержимого, если номер пакета кодируется одним байтом или 2 байтов в кадрах при 2-байтовом кодировании номера пакета. Выборку шифротекста можно реализовать приведённым ниже псевдокодом.

   # pn_offset начало поля Packet Number.
   sample_offset = pn_offset + 4

   sample = packet[sample_offset..sample_offset+sample_length]

Смещение номера пакета в коротком заголовке определяется как

   pn_offset = 1 + len(connection_id)

В пакете с длинным заголовком смещение порядкового номера рассчитывается как

   pn_offset = 7 + len(destination_connection_id) +
                   len(source_connection_id) +
                   len(payload_length)
   if packet_type == Initial:
       pn_offset += len(token_length) +
                    len(token)

Например, для пакета с коротким заголовком, 8-байтовым идентификатором соединения и защитой AEAD_AES_128_GCM, выборка будет включать байты с 13 по 28 (отсчёт от 0). В одну дейтаграмму UDP может включаться несколько пакетов QUIC, каждый из которых обрабатывается отдельно.

5.4.3. Защита заголовка на основе AES

В этом параграфе определён алгоритм защиты пакетов для AEAD_AES_128_GCM, AEAD_AES_128_CCM и AEAD_AES_256_GCM. AEAD_AES_128_GCM и AEAD_AES_128_CCM используют 128-битовый шифр AES в режиме ECB (Electronic Codebook — электронный шифровальный блокнот). AEAD_AES_256_GCM использует 256-битовый шифр AES в режиме ECB. Протокол AES определён в [AES].

Этот алгоритм извлекает 16 шифрованного содержимого и использует в AES-ECB. Псевдокод функции защиты заголовков имеет вид

   header_protection(hp_key, sample):
     mask = AES-ECB(hp_key, sample)

5.4.4. Защита заголовка на основе ChaCha20

При использовании AEAD_CHACHA20_POLY1305 для защиты заголовков применяется raw-функция ChaCha20, определённая в параграфе 2.4 [CHACHA]. Она использует 256-битовый ключ 16-байтовую выборку из защищённой части пакета. Первые 4 байта выборки служат счётчиком блоков. Реализация ChaCha20 может принимать 32-битовое целое число вместо последовательности байтов и в этом случае последовательность байтов интерпретируется как значение little-endian. Оставшиеся 12 используются как nonce. реализация ChaCha20 может принимать массив из трёх 32-битовых целых чисел вместо последовательности байтов и в этом случае байты nonce интерпретируются как последовательность 32-битовых целых чисел little-endian.

Маска шифрования создаётся вызовом ChaCha20 для защиты 5 байтов со значением 0. Псевдокод защиты заголовка имеет вид

   header_protection(hp_key, sample):
     counter = sample[0..3]
     nonce = sample[4..15]
     mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})

5.5. Приём защищённых пакетов

При успешной получении конечной точкой пакета с данным номером она должна отбрасывать все пакеты из того же пространства с большими номерами, если не может снять их защиту с тем же (или новым в случае обновления) ключом (см. раздел 6). Точно так же должны отбрасываться пакеты, представляющиеся триггерами обновления ключей, если для них не удаётся снять защиту.

Отказ при снятии защиты пакета не обязательно указывает наличие протокольной ошибки или атаки. Отсечка кодирования порядкового номера в QUIC может приводить к некорректному декодированию номеров в случае значительной задержки.

5.6. Использование ключей 0-RTT

Если доступны ключи 0-RTT (см. параграф 4.6.1), отсутствие защиты от повторного использования (replay) означает, что ограничения на применение ключей требуются для защиты от replay-атак на протокол. Среди определённых в [QUIC-TRANSPORT] кадров, для кадров STREAM, RESET_STREAM, STOP_SENDING, CONNECTION_CLOSE использование с 0-RTT может быть небезопасным, поскольку эти кадры содержат данные приложения. Полученные в 0-RTT данные могут заставить приложение на сервере обрабатывать данные несколько раз вместо одного. Предпринимаемые в результате сервером дополнительные действия по обработке повторно использованных данных приложения могут приводить к нежелательным последствиям. Поэтому клиенту недопустимо использовать 0-RTT для данных приложения, если это не запрашивается приложением специально.

Использующий QUIC прикладной протокол должен включать профиль, определяющий допустимость использования 0-RTT, иначе 0-RTT можно применять лишь для кадров QUIC, не содержащих данных приложения. Например, профиль для HTTP описан в [HTTP-REPLAY] и применяется для HTTP/3 (см. параграф 10.9 в [QUIC-HTTP]).

Хотя повторное использование пакетов может приводить к дополнительным попыткам соединения, влияние обработки воспроизводимых пакетов без данных приложения ограничено сменой состояния затронутого соединения. Согласование TLS не может быть завершено успешно с использованием воспроизводимых пакетов.

Клиент может внести дополнительные ограничения для передачи данных до завершения согласования TLS.

В остальном клиент считает ключи 0-RTT эквивалентом ключей 1-RTT, за исключением невозможности передачи некоторых кадров с ключами 0-RTT (см. параграф 12.5 в [QUIC-TRANSPORT]).

Клиент, получивший индикацию восприятия его данных 0-RTT сервером может передавать такие данные, пока не получит от сервера все сообщения процесса согласования (handshake). Клиенту следует прекратить передачу данных 0-RTT при получении сведений о том, что данные 0-RTT были отвергнуты.

Серверу недопустимо использовать ключи 0-RTT для защиты пакетов и для защиты подтверждений пакетов 0-RTT он использует ключи 1-RTT. Клиенту недопустимо пытаться расшифровывать полученные пакеты 0-RTT, он просто должен отбрасывать их. После установки клиентом ключей 1-RTT ему недопустимо передавать пакеты 0-RTT.

Примечание. Данные 0-RTT могут быть подтверждены сервером при их получении, но для пакетов с подтверждениями данных 0-RTT клиент не сможет снять защиту до завершения согласования TLS. Для снятия защиты нужны ключи 1-RTT, которые не могут быть получены раньше приёма от сервера всех сообщений процедуры согласования.

5.7. Получение разупорядоченных защищённых пакетов

В результате нарушения порядка и потерь защищённые пакеты могут быть получены конечной точкой до приёма финальных сообщений согласования TLS. Клиент не сможет расшифровать пакеты 1-RTT от сервера, тогда как сервер может расшифровать пакеты 1-RTT от клиента. Конечным точкам в любой роли недопустимо расшифровывать пакеты 1-RTT от партнёра до завершения согласования. Хотя ключи 1-RTT доступны серверу после приёма первых сообщений согласования от клиента, у него нет гарантии состояния клиента.

  • Подлинность клиента не проверена, пока сервер не решил использовать распространённый заранее ключ и не проверил привязку заранее распространенного ключа клиента (см. параграф 4.2.11 в [TLS13]).

  • Клиент не продемонстрировал работоспособность, пока сервер не проверил адрес клиента с помощью пакета Retry или иным способом (см. параграф 8.1 в [QUIC-TRANSPORT]).

  • Все полученные данные 0-RTT, на которые сервер отвечает, могут быть использованными повторно (replay).

Поэтому использование сервером ключей 1-RTT до завершения согласования ограничено отправкой данных. Серверу недопустимо обрабатывать входящие пакеты с защитой 1-RTT до завершения согласования TLS. Поскольку отправка подтверждения указывает, что все кадры из пакета обработаны, сервер не может передавать подтверждения для пакетов 1-RTT, пока согласование TLS не завершено. Полученные пакеты с защитой 1-RTT могут сохраняться и расшифровываться по завершении согласования.

Примечание. Реализации TLS могут предоставлять все секреты 1-RTT до завершения согласования. Даже при наличии у реализации QUIC ключей чтения 1-RTT эти ключи не применяются до завершения согласования.

Требование к серверу ждать сообщения Finished от клиента создаёт зависимость от доставки этого сообщения. Клиент может предотвратить возможную блокировку head-of-line, которую это подразумевает, передавая свои пакеты 1-RTT объединёнными с пакетом Handshake, содержащим копию кадра CRYPTO с сообщением Finished, пока один из пакетов Handshake не будет подтверждён. Это позволяет серверу незамедлительно обработать такие пакеты.

Сервер может получить пакеты, защищённые ключами 0-RTT, до приёма сообщения TLS ClientHello. Сервер может сохранить эти пакеты для расшифровки после приёма ClientHello.

Клиент обычно получает ключи 1-RTT одновременно с завершением согласования. Даже при наличии секретов 1-RTT клиенту недопустимо обрабатывать пакеты с защитой 1-RTT, пока согласование TLS не завершено.

5.8. Целостность пакета Retry

Пакеты Retry (см. параграф 17.2.5 в [QUIC-TRANSPORT]) переносят Retry Integrity Tag, позволяющий отбрасывать пакеты, случайно повреждённые в сети и разрешающий передачу пакета Retry лишь объекту, имеющему доступ к пакету Initial.

Retry Integrity Tag – это 128-битовое поле, возвращаемое функцией AEAD_AES_128_GCM [AEAD], по входным данным:

  • секретный ключ K – 128 битов со значением 0xbe0c690b9f66575a1d766b54e368c84e;

  • одноразовое значение (nonce) N – 96 битов со значением 0x461599d35d632bf2239825bb;

  • нешифрованные данные (plaintext) P с пустым значением;

  • связанные данные A, содержащие Retry Pseudo-Packet, как показано на рисунке 8.

Секретный ключ и nonce выводятся вызовом HKDF-Expand-Label с использованием секрета 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e и метками quic key и quic iv (параграф 5.1).

   Retry Pseudo-Packet {
     ODCID Length (8),
     Original Destination Connection ID (0..160),
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 3,
     Unused (4),
     Version (32),
     DCID Len (8),
     Destination Connection ID (0..160),
     SCID Len (8),
     Source Connection ID (0..160),
     Retry Token (..),
   }

Рисунок 8. Псевдопакет Retry.


Псевдопакет Retry не передаётся в линию. Он рассчитывается по принятому пакету Retry путём удаления Retry Integrity Tag и добавления в начало двух полей.

ODCID Length

Размер поля Original Destination Connection ID (в байтах), представленный 8-битовым целым числом без знака.

Original Destination Connection ID

Значение поля Destination Connection ID из пакета Initial, вызвавшего данный пакет Retry. Размер этого поля указан в ODCID Length. Наличие этого поля гарантирует возможность передачи действительного пакета Retry лишь объектом, которому доступен пакет Initial.

6. Обновление ключей

Когда согласование подтверждено (см. параграф 4.1.2), конечная точка может инициировать обновление ключей.

Бит Key Phase указывает ключи, применяемые для защиты пакетов. Бит Key Phase исходно сброшен (0) для первого набора пакетов 1-RTT и переключается для сигнализации каждого последующего обновления ключей.

Бит Key Phase позволяет получателю обнаружить смену ключевого материала без необходимости получения первого пакета, инициировавшего смену. Конечная точка, заметившая изменение бита Key Phase, обновляет ключи и расшифровывает пакет с измененным значением.

Инициирование обновления ключей ведёт к обновлению ключей в обеих конечных точках. Это отличается от TLS, где конечные точки могут обновляться независимо. Этот механизм заменяет механизм обновления ключей TLS, основанный на сообщениях KeyUpdate, передаваемых с использованием ключей шифрования 1-RTT. Конечным точкам недопустимо передавать сообщения TLS KeyUpdate и они должны считать получение такого сообщения ошибкой соединения типа 0x010a, эквивалентной сигналы TLS unexpected_message (см. параграф 4.8).

На рисунке 9 показан процесс обмена ключами, где исходные ключи (@M) заменяются новыми (@N). Значение бита Key Phase указано в квадратных скобках.

Партнер-инициатор                       Отвечающий партнер

@M [0] Пакеты QUIC

... Обновление до @N
@N [1] Пакеты QUIC 
                      -------->
                                      Обновление до @N ...
                                      Пакеты QUIC [1] @N
                      <--------
                                      Пакеты QUIC [1] @N,
                                      содержащие ACK
                      <-------- 
... Обновление ключей разрешено 

@N [1] Пакеты QUIC, 
       содержащие ACK для @N пакетов 
                      -------->
                           Обновление ключей разрешено ...

Рисунок 9. Обновление ключа.


6.1. Запуск обновления ключей

Конечные точки поддерживают разные секреты чтения и записи для защиты пакетов. Конечная точка запускает обновление ключей, обновляя свой секрет записи для защиты пакетов и используя его с новыми пакетами. Новый секрет записи создаётся из имеющегося в соответствии с параграфом 7.2 в [TLS13]. При этом используется функция KDF, обеспечиваемая TLS, с меткой quic ku. Соответствующий ключ и IV создаются из этого секрета, как указано в параграфе 5.1. Ключ защиты заголовков не обновляется.

Например, для обновления ключей записи с TLS 1.3 применяется HKDF-Expand-Label

   secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku", "", Hash.length)

Конечная точка меняет бит Key Phase и использует обновленный ключ и IV для защиты последующих пакетов.

Конечной точке недопустимо запускать обновление ключа до подтверждения согласования (параграф 4.1.2). Конечной точке недопустимо инициировать последующие обновления ключа, пока она не получила подтверждения пакетов, защищённых с ключом из текущей фазы. Это гарантирует доступность ключей обоим партнёрам, прежде чем будет начато обновление. Это можно реализовать путём отслеживания наименьшего номера пакета, переданного с каждой фазой ключа, и наибольшего номера подтверждения в пространстве 1-RTT – как только номер подтверждения станет не меньше наименьшего номера переданного пакета, можно запускать обновления ключа.

Примечание. Ключи для пакетов, отличных от 1-RTT, не обновляются и выводятся исключительно из статуса согласования TLS.

Конечная точка, запустившая обновление ключей, обновляет также ключи, применяемые для полученных пакетов. Эти ключи будут нужны для обработки пакетов, которые партнёр передаст после обновления.

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

6.2. Отклик на обновление ключей

Партнёру разрешено запускать обновление ключей после подтверждения пакета а текущей фазе ключей. Конечная точка обнаруживает обновление ключей, когда обрабатывает пакет с фазой ключа, отличающейся от значения, использованного для защиты последнего пакета, который она передала. Для обработки такого пакета конечная точка применяет следующий ключ защиты пакета и IV. Генерация ключей описана в параграфе 6.3.

если пакет успешно обработан с использованием следующего ключа и IV, партнёр запускает обновление ключей. Конечная точка должна обновить свои ключи передачи до соответствующей фазы ключей в отклике, как описано в параграфе 6.1. Ключи передачи должны быть обновлены до отправки подтверждения для пакета, принятого с обновлёнными ключами. Подтверждая пакет, вызвавший обновление ключей с защитой обновлёнными ключами, конечная точка сообщает о завершении обновления ключей.

Конечная точка может отложить передачу пакета или подтверждения в соответствии со своим обычным поведением и нет необходимости незамедлительно создавать пакет в ответ на обновление ключа. Следующий пакет, переданный конечной точкой, будет использовать обновлённые ключи. Следующий пакет с подтверждением вызовет завершение обновления ключей. Если конечная точка обнаруживает второе обновление до передачи ею какого-либо пакета с обновлёнными ключами, это указывает, что партнёр обновил ключи дважды, не дожидаясь подтверждения. Конечная точка может считать такое обновление ошибкой соединения типа KEY_UPDATE_ERROR.

Конечная точка, получившая подтверждение в пакете, защищённом старыми ключами, для пакетов, защищённых новыми ключами, может считать это ошибкой соединения типа KEY_UPDATE_ERROR. Это показывает, что партнёр получил и подтвердил пакет, вызывающий обновление ключей, но не обновил свои ключи.

6.3. Синхронизация создания ключа приёма

Конечным точкам, отвечающим на кажущееся обновление ключа, недопустимо создавать сигнал побочного канала синхронизации, который может указать, что бит Key Phase был недействителен (см. параграф 9.5). Конечные точки могут использовать случайные ключи защиты пакетов вместо отброшенных ключей, когда обновление ключей ещё не разрешено. Применение случайных ключей гарантирует, что попытки снять защиту пакетов не приведут к изменению синхронизации, а обеспечат отклонение пакетов с недействительным битом Key Phase.

Процесс создания новых ключей защиты пакетов для принимаемых пакетов может показать, что произошло обновление ключей. Конечная точка может создать новые ключи в процессе обработки пакета, но это открывает сигнал синхронизации, которым злоумышленник может воспользоваться для определения момента смены ключей и утечки значения бита Key Phase.

Обычно считается, что конечные точки имеют текущие и следующие ключи защиты для принимаемых пакетов. В течение короткого времени после обновления ключей (вплоть до PTO) конечные точки могут отложить создание нового набора ключей защиты для принимаемых пакетов. Это позволяет конечным точкам сохранять лишь два комплекта приёмных ключей (см. параграф 6.5).

После генерации следующий набор ключей защиты пакетов следует сохранить, даже если полученный пакет был потом отброшен. Пакеты, представляющиеся триггером обновления ключей, легко подделать и хотя процесс обновления ключей не требует значительных усилий, запуск этого процесса можно использовать для DoS-атак. По этой причине конечные точки должны быть способны сохранять два набора ключей защиты для принимаемых пакетов (текущий и следующий). Сохранение предыдущего набора ключей не требуется, но может поднять производительность.

6.4. Передача с обновлёнными ключами

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

6.5. Приём с другими ключами

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

Поскольку пакеты, защищённые ключами из следующей фазы используют то же значение Key Phase, что и пакеты из следующей фазы, необходимо их различать, если требуется обработка пакетов, защищённых со старыми ключами. Это можно сделать по номерам пакетов. Восстановленный номер, который меньше любого из номеров текущей фазы ключей, использует прежние ключи защиты, а номер, который больше номера любого из пакетов текущей фазы, требует применения ключей защиты пакетов из следующей фазы. Нужны меры предосторожности, чтобы процесс выбора между прежними, текущими и будущими ключами защиты пакетов не создавал побочного канала синхронизации, который можно использовать для снятия защиты пакетов (см. параграф 9.5).

В качестве варианта конечные точки могут сохранять лишь два набора ключей защиты пакетов, переходя с прежнего к следующему по истечении достаточно большого времени, позволяющего учесть нарушение порядка в сети. В этом случае бит Key Phase позволяет однозначно выбрать ключи. Конечная точка может внести интервал приблизительно равный интервалу зондирования (Probe Timeout или PTO, см [QUIC-RECOVERY]) после того, как следующий набор ключей становится текущим, до создания следующего набора ключей защиты пакетов. Эти обновлённые ключи могут заменить прежние ключи в любой момент. С учётом того, что PTO является субъективной мерой (т. е. у партнёра может быть иное представление о RTT), предполагается, что этого времени будет достаточно, чтобы все разупорядоченные пакеты были сочтены партнёром потерянными, даже если они были подтверждены, и интервал будет достаточно коротким, чтобы партнёр мог запустить дальнейшее обновление ключей.

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

Конечной точке следует сохранять старые ключи не более трёх интервалов PTO после приёма пакета, защищённого с использованием новых ключей. По истечении этого времени старые ключи и соответствующие секреты следует отбросить.

6.6. Ограничения применимости AEAD

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

Пределы использования, заданные в TLS 1.3, применяются для защиты от атак на конфиденциальность при использовании защиты AEAD. Защита целостности при аутентифицированном шифровании также зависит от ограничения числа попыток подделки пакетов. TLS обеспечивает это путём закрытия соединений, если какая-либо запись не прошла проверку подлинности. QUIC игнорирует не прошедшие аутентификацию пакеты, разрешая множество попыток подделки.

В QUIC ограничения для AEAD в части конфиденциальности и целостности применяются раздельно. Ограничение в части конфиденциальности применяется к числу пакетов, шифруемых с данным ключом. Для целостности ограничение применяется к числу пакетов, расшифрованных в данном соединении. Детали применения этих ограничений для каждого алгоритма AEAD рассмотрены ниже.

Конечные точки должны считать число зашифрованных пакетов для каждого набора ключей. Если число пакетов, зашифрованных с одним ключом, превышает предел конфиденциальности для выбранного алгоритма AEAD, конечная точка должна прекратить применение этих ключей. Конечные точки должны запускать обновление ключей до передачи числа пакетов, превышающего установленный для AEAD предел. Если обновление ключей невозможно или достигнут предел в части целостности, конечная точка должна прекратить использование соединения и передавать лишь сброс без учёта состояния в ответ на получение пакетов. Конечным точкам рекомендуется незамедлительно закрывать соединение с ошибкой типа AEAD_LIMIT_REACHED до достижения состояния, в котором невозможно обновить ключи.

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM предел в части конфиденциальности составляет 223 зашифрованных пакетов (см. Приложение B.1), для AEAD_CHACHA20_POLY1305 предел превышает возможное число пакетов (262) и им можно пренебречь, а для AEAD_AES_128_CCM предел составляет 221,5 зашифрованных пакетов (см. Приложение B.2). Применение ограничений снижает вероятность того, что атакующий сможет определить применяемый алгоритм AEAD от случайного изменения (см. [AEBounds], [ROBUST], [GCM-MU]).

В дополнение к учёту переданных пакетов конечные точки должны считать число принятых пакетов, которые не прошли аутентификацию в течение работы соединения. Если общее число принятых пакетов, не прошедших проверку подлинности (для всех ключей) превышает предел, заданный в части целостности для применяемого алгоритма AEAD, конечная точка должна незамедлительно закрыть соединение с ошибкой типа AEAD_LIMIT_REACHED и прекратить обработку последующих пакетов.

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM предел в части целостности составляет 252 недействительных пакетов (см. Приложение B.1), для AEAD_CHACHA20_POLY1305 – 236 недействительных пакетов (см. [AEBounds]), а для AEAD_AES_128_CCM – 221,5 недействительных пакетов (см. Приложение B.2). Применение этих ограничений снижает вероятность успешной подделки пакетов злоумышленником (см. [AEBounds], [ROBUST], [GCM-MU]).

Конечные точки, ограничивающие размер пакетов, могут устанавливать более высокие пределы в части конфиденциальности и целостности (см. Приложение B). Будущий анализ и спецификации могут смягчить требования к ограничениям для AEAD.

Любой шифронабор TLS, указанный для применения с QUIC, должен задавать пределы использования соответствующей функции AEAD для сохранения конфиденциальности и целостности. Т. е. должны быть заданы пределы для числа пакетов, которые могут быть аутентифицированы, и числа пакетов с отказом при аутентификации. Предоставление ссылки на анализ, обосновывающий представленные значения и использованные при этом анализе допущения, позволяет приспособить ограничения к изменяющимся условиям применения.

6.7. Код ошибки при обновлении ключей

Код ошибки KEY_UPDATE_ERROR (0x0e) служит для сигнализации ошибок, связанных с обновлением ключей.

7. Защита пакетов Initial

Пакеты Initial не могут быть защищены с использованием секретного ключа, поэтому атакующий способен изменить их. QUIC обеспечивает защиту от злоумышленников, не способных читать пакеты, но не пытается предоставить дополнительную защиту от атак с возможностью наблюдения и внедрения пакетов. Некоторые из форм вмешательства, такие как изменение самих сообщений TLS, могут быть замечены, но другие, например, изменение ACK, остаются не обнаруженными. Например, атакующий может внедрить пакет с кадром ACK чтобы создать впечатление о том, что кадр не был получен или представить ложное состояние соединения (например, путём изменения ACK Delay). Отметим, что такие пакеты могут вызывать отбрасывание легитимных пакетов как дубликатов. Реализациям следует проявлять осторожность, полагаясь на данные из пакетов Initial, которые не аутентифицированы иным способом.

Злоумышленник также может подделать данные в пакетах Handshake, но такое вмешательство требует изменения сообщений согласования TLS, приводящего к отказу этого согласования.

8. Связанные с QUIC настройки TLS Handshake

Некоторые аспекты согласования TLS меняются при использовании с QUIC. Кроме криптографических параметров в процессе согласования передаются и аутентифицируются параметры транспорта QUIC.

8.1. Согласование протокола

QUIC требует, чтобы криптографическое согласование обеспечивало аутентифицированное согласование протокола. TLS использует согласование протокола прикладного уровня [ALPN] для выбора протокола приложения. Если не задан иной механизм согласования такого протокола, конечные точки должны применять ALPN. При использовании ALPN конечные точки должны немедленно закрывать соединение (см. параграф 10.2 в [QUIC-TRANSPORT]) с сигналом TLS no_application_protocol (код ошибки QUIC 0x0178, см. параграф 4.8), если прикладной протокол не согласован. Хотя [ALPN] лишь указывает, что серверы используют этот сигнал, клиенты QUIC должны по коду 0x0178 прерывать соединение в случае отказа при согласовании ALPN.

Прикладной протокол может ограничивать версии QUIC, с которыми он работает. Серверы должны выбирать протокол приложений, совместимый с выбранной клиентом версией QUIC. Сервер должен считать неспособность выбрать совместимый протокол ошибкой соединения типа 0x0178 (no_application_protocol). Клиент должен считать выбор серверов несовместимого прикладного протокола ошибкой соединения типа 0x0178.

8.2. Расширение для транспортных параметров QUIC

Транспортные параметры QUIC передаются в расширении TLS. Разные версии QUIC могут определять различные методы согласования транспортной конфигурации. Включение параметров транспорта в согласование TLS обеспечивает защиту целостности этих параметров.

      enum {
         quic_transport_parameters(0x39), (65535)
      } ExtensionType;

Поле extension_data field в расширении quic_transport_parameters содержит значение, определённое используемой версией QUIC.

Расширение quic_transport_parameters передаётся в сообщениях ClientHello и EncryptedExtensions в процессе согласования. Конечные точки должны передавать расширение quic_transport_parameters, а конечные точки, получившие сообщение ClientHello или EncryptedExtensions без quic_transport_parameters, должны закрывать соединение с ошибкой типа 0x016d (эквивалент критического сигнала TLS missing_extension, см. параграф 4.8).

Транспортные параметры становятся доступными до завершения согласования и сервер может использовать эти значения. Однако транспортные параметры не будут аутентифицированы до завершения согласования, поэтому на их подлинность полагаться нельзя. Любое вмешательство в параметры транспорта приведёт к отказу согласования.

Конечным точкам недопустимо передавать это расширение в соединениях TLS, не используемых протоколом QUIC (например, при использовании TLS с TCP [TLS13]). Поддерживающая расширение реализация должна передавать критический сигнал unsupported_extension при получении этого расширения для транспорта, отличного от QUIC.

Согласование расширения quic_transport_parameters вызывает исключение EndOfEarlyData (см. параграф 8.3).

8.3. Удаление сообщения EndOfEarlyData

Сообщение TLS EndOfEarlyData не используется с QUIC и протокол не полагается на это сообщение для маркировки завершения данных 0-RTT или сигнализации о смене ключей Handshake. Клиентам недопустимо передавать сообщение EndOfEarlyData, а сервер должен считать получение кадра CRYPTO в пакете 0-RTT ошибкой соединения типа PROTOCOL_VIOLATION.

В результате сообщение EndOfEarlyData не присутствует в согласовании TLS.

8.4. Запрет режима TLS Middlebox Compatibility

В Приложении D.4 [TLS13] описано изменение согласования TLS 1.3 для обхода ошибок некоторых промежуточных устройств. Режим совместимости с промежуточными устройствами в TLS 1.3 включает установку для поля legacy_session_id 32-байтового значения в ClientHello и ServerHello, затем передачу изменённой записи change_cipher_spec. Оба поля и запись не несут семантического содержимого и игнорируются.

Этот режим не используется в QUIC поскольку применим лишь к промежуточным устройствам, нарушающим работу TLS по протоколу TCP. QUIC также не предоставляет средств доставки записи change_cipher_spec. Клиентам недопустимо запрашивать использование режима совместимости TLS 1.3, а серверам следует считать получение TLS ClientHello с непустым полем legacy_session_id ошибкой соединения типа PROTOCOL_VIOLATION.

9. Вопросы безопасности

Все вопросы безопасности, связанные с TLS применимы и к использованию TLS в QUIC. Чтение [TLS13] и приложений к нему обеспечивает наилучший способ разобраться с вопросами безопасности QUIC. В этом разделе приведена сводка некоторых важных аспектов безопасности, относящихся к интеграции TLS, хотя многие детали, связанные с безопасностью рассмотрены в оставшейся части документа.

9.1. Связывание сессий

Использование сеансовых квитанций TLS позволяет серверами и возможно другим объектам сопоставлять соединения одного клиента (см. параграф 4.5).

9.2. Replay-атаки с 0-RTT

Как описано в разделе 8 [TLS13], использование ранних данных в TLS открывает возможность для атак с повторным использованием (replay). Использование 0-RTT в QUIC также уязвимо для replay-атак. Конечные точки должны реализовать и применять защиту от повторного использования, описанную в [TLS13], однако известно, что эта защита несовершенна, поэтому требуется дополнительное рассмотрение риска от повторного использования.

Протокол QUIC не уязвим для replay-атак за исключением данных о прикладном протоколе, которые он может нести. Управление состоянием протокола QUIC основано на типах кадров, определённых в [QUIC-TRANSPORT], и не подвержено replay-атакам. Обработка кадров QUIC идемпотентна и не может приводить к недействительным состояниям соединения в случае повторного использования, разупорядочения или потери кадров. Соединения QUIC не создают эффектов, распространяющихся за пределы срока действия соединения, за исключением тех, которые создаёт протокол приложения, обслуживаемый QUIC.

Сеансовые квитанции TLS и маркеры проверки адресов служат для передачи конфигурационных данных QUIC между соединениями, в частности, чтобы позволить серверу эффективно восстанавливать состояние, используемое при организации соединения и проверке адреса. Это недопустимо применять для передачи семантики приложения между взаимодействующими конечными точками и клиенты должны считать эти параметры необрабатываемыми (opaque) значениями. Возможность повторного использования маркеров означает требование строгой защиты для них.

На сервере, воспринимающем 0-RTT в соединении требуется больше затрат, чем в соединениях без 0-RTT. Это включает большие расходы на обработку и вычисления. Серверам, воспринимающим 0-RTT, необходимо учитывать вероятность повторного использования и связанные с этим расходы.

В конечном итоге ответственность за контроль рисков replay-атак с 0-RTT ложится на протокол приложения. Использующий QUIC прикладной протокол должен описывать применение 0-RTT и меры, реализуемые для защиты от replay-атак. Анализ связанных с этим рисков должен учитывать все свойства протокола QUIC, связанные с семантикой приложения.

Полное отключение 0-RTT является наиболее эффективным способом защиты от replay-атак.

Расширения QUIC должны описывать влияние replay-атак на их работу или запрещать применение расширения в 0-RTT. Прикладной протокол должен запрещать использование расширений, передающих семантику приложения в 0-RTT, или обеспечивать стратегию предотвращения повторного использования.

9.3. Ослабление атак с отражением пакетов

Небольшое сообщение ClientHello, вызывающее большой блок сообщений согласования от сервера, можно использовать для атак с отражением, усиливающих трафик от атакующего. QUIC включает три средства защиты от таких атак. Во-первых, клиент должен дополнять пакет с ClientHello до минимального размера. Во-вторых, при отклике по неизвестным адресам отправителей серверу запрещено передавать более троекратного объёма полученных данных (см. параграф 8.1 в [QUIC-TRANSPORT]). В-третьих, поскольку подтверждения пакетов Handshake аутентифицируются, при атаке вслепую их нельзя подделать. Эти меры ограничивают степень усиления трафика.

9.4. Анализ защиты заголовков

В [NAN] анализируются алгоритмы аутентифицированного шифрования, обеспечивающие конфиденциальность nonce, называемую преобразованием HN (Hide Nonce). Базовая конструкция защиты заголовков в этом документе основана на одном из таких алгоритмов (HN1). Защита заголовка применяется после защиты AEAD для пакета путём выборки набора байтов (sample) из вывода AEAD и шифрования поля заголовка с применением псевдослучайной функции PRF

   protected_field = field XOR PRF(hp_key, sample)

Варианты защиты заголовка в этом документе используют псевдослучайную перестановку (pseudorandom permutation или PRP) вместо базовой PRF. Однако, поскольку все PRP являются также PRF [IMC], эти варианты не отклоняются от конструкции HN1.

Поскольку hp_key отличается от ключа защиты пакета, защита заголовка обеспечивает уровень AE2, как определено в [NAN], и поэтому гарантирует конфиденциальность field – защищённого заголовка пакета. Будущие варианты защиты заголовка на основе этой конструкции должны использовать PRF для обеспечения эквивалентных гарантий защиты.

Использование одного ключа и выборки шифрованных данных более одного раза ставит под угрозу защиту заголовка. Защита двух разных заголовков с одним ключом и выборкой шифротекста раскрывает XOR защищённых полей. В предположении AEAD в качестве PRF и выборки L битов вероятность совпадения двух выборок шифротекста составит 2(-L/2) (birthday bound). Для алгоритмов, описанных в этом документе вероятность составляет 2-64.

Чтобы злоумышленник не могу изменить заголовки пакетов, для них применяется транзитивная проверка подлинности с использованием защиты пакета, весь заголовок является частью дополнительных аутентифицируемых данных. Фальсифицированные или изменённые поля, которые были защищены, могут быть обнаружены лишь после снятия защиты пакета.

9.5. Побочные каналы синхронизации защиты заголовка

Атакующий может угадать значения номеров пакетов или Key Phase и получить от конечной точки подтверждение догадки через побочный канал синхронизации. Точно так же можно попытаться угадать и раскрыть номер пакета. Если получатель отбрасывает пакеты с дубликатами номеров, не пытаясь снять защиту пакета, он может раскрыть через побочный канал синхронизации совпадение номера с принятым пакетом. Для устранения побочных каналов при аутентификации процессы снятия защиты заголовка, восстановления порядкового номера и снятия защиты пакета должны применяться совместно без синхронизации и других побочных каналов.

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

В процессе обновления ключей время генерации новых ключей может раскрывать через побочные каналы синхронизации факт обновления ключей. При внедрении пакетов атакующим этот сторонний канал может дополнительно раскрывать значение Key Phase на внедрённых пакетах. После получения обновления ключей конечной точке следует создать и сохранить набор ключей защиты приёма, как описано в параграфе 6.3. За счёт генерации новых ключей до получения обновления ключей приём пакетов не будет создавать сигналов синхронизации, через которые возможна утечка Key Phase.

Это зависит от того, генерируются ли ключи в процессе обработки пакета и может потребовать от конечной точки поддержки трёх наборов ключей защиты пакета на приёме для предыдущей, текущей и будущей Key Phase. Конечные точки могут отложить создание следующих ключей защиты пакета на приёме до момента отбрасывания старых ключей, чтобы хранить лишь два набора.

9.6. Разнообразие ключей

При использовании TLS применяется центральное планирование ключей TLS. В результате вовлечения сообщений согласования TLS в расчёт секретов, включение расширения для транспортных параметров QUIC гарантирует, что ключи согласования и 1-RTT не совпадут с ключами, которые может создать сервер, использующий TLS с протоколом TCP. Для предотвращения возможности межпротокольной синхронизации ключей применяются дополнительные меры, улучшающие разделение ключей.

В QUIC ключи защиты пакетов и IV выводятся с использованием иных меток, нежели для аналогичных ключей в TLS. Для сохранения такого разделения новым версиям QUIC следует задавать иные метки при создании ключей для защиты пакетов и IV, а также ключей защиты заголовков. В этой версии QUIC применяется строка quic, а другие версии могут применять взамен определяемую версией строку.

Для начальных секретов применяется ключ, зависящий от согласованной версии QUIC. Новым версиям QUIC следует задавать иную затравку (salt) для расчёта начальных секретов.

9.7. Случайные значения

QUIC зависит от способности конечных точек создавать безопасные случайные значения напрямую для таких параметров протокола как идентификаторы соединений и опосредованно через TLS. Рекомендации по созданию случайных чисел приведены в [RFC4086].

10. Взаимодействие с IANA

Агентство IANA зарегистрировало код 57 (0x39) для расширения quic_transport_parameters (см. параграф 8.2) в реестре TLS ExtensionType Values [TLS-REGISTRIES]. В столбце Recommended для этого расширения указано значение Yes, а столбец TLS 1.3 включает CH (ClientHello) и EE (EncryptedExtensions).

Таблица 2. Записи реестра TLS ExtensionType Values.

Значение

Имя расширения

TLS 1.3

Рекомендация

Документ

57

quic_transport_parameters

CH, EE

YY

Данный документ

11. Литература

11.1. Нормативные документы

[AEAD] McGrew, D., “An Interface and Algorithms for Authenticated Encryption”, RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.

[AES] “Advanced encryption standard (AES)”, National Institute of Standards and Technology report, DOI 10.6028/nist.fips.197, November 2001, <https://doi.org/10.6028/nist.fips.197>.

[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[CHACHA] Nir, Y. and A. Langley, “ChaCha20 and Poly1305 for IETF Protocols”, RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/info/rfc8439>.

[HKDF] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., “QUIC Loss Detection and Congestion Control”, RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.

[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[SHA] Dang, Q., “Secure Hash Standard”, National Institute of Standards and Technology report, DOI 10.6028/nist.fips.180-4, July 2015, <https://doi.org/10.6028/nist.fips.180-4>.

[TLS-REGISTRIES] Salowey, J. and S. Turner, “IANA Registry Updates for TLS and DTLS”, RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[TLS13] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

11.2. Дополнительная литература

[AEBounds] Luykx, A. and K. Paterson, “Limits on Authenticated Encryption Use in TLS”, 28 August 2017, <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

[ASCII] Cerf, V., “ASCII format for network interchange”, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[CCM-ANALYSIS] Jonsson, J., “On the Security of CTR + CBC-MAC”, Selected Areas in Cryptography, SAC 2002, Lecture Notes in Computer Science, vol 2595, pp. 76-93, DOI 10.1007/3-540-36492-7_7, 2003, <https://doi.org/10.1007/3-540-36492-7_7>.

[COMPRESS] Ghedini, A. and V. Vasiliev, “TLS Certificate Compression”, RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.

[GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, “The Multi-user Security of GCM, Revisited: Tight Bounds for Nonce Randomization”, CCS ’18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018, <https://doi.org/10.1145/3243734.3243816>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, “Using Early Data in HTTP”, RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.

[HTTP2-TLS13] Benjamin, D., “Using TLS 1.3 with HTTP/2”, RFC 8740, DOI 10.17487/RFC8740, February 2020, <https://www.rfc-editor.org/info/rfc8740>.

[IMC] Katz, J. and Y. Lindell, “Introduction to Modern Cryptography, Second Edition”, ISBN 978-1466570269, 6 November 2014.

[NAN] Bellare, M., Ng, R., and B. Tackmann, “Nonces Are Noticed: AEAD Revisited”, Advances in Cryptology – CRYPTO 2019, Lecture Notes in Computer Science, vol 11692, pp. 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019, <https://doi.org/10.1007/978-3-030-26948-7_9>.

[QUIC-HTTP] Bishop, M., Ed., “Hypertext Transfer Protocol Version 3 (HTTP/3)”, Work in Progress, Internet-Draft, draft-ietf-quic-http-34, 2 February 2021, <https://tools.ietf.org/html/draft-ietf-quic-http-34>.

[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[ROBUST] Fischlin, M., Günther, F., and C. Janson, “Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3”, 16 May 2020, <https://eprint.iacr.org/2020/718>.

Приложение A. Пример защиты пакета

В этом приложении даны примеры защиты пакетов для поэтапной проверки реализаций. Определены образцы пакетов Initial для клиента и сервера, а также пакета Retry. В пакетах используется выбранное клиентом значение Destination Connection ID of 0x8394c8f03e515708. Включены также некоторые промежуточные значения. Все числа представлены в шестнадцатеричном формате.

A.1. Ключи

Ниже приведены метка, создаваемые в процессе выполнения функции HKDF-Expand-Label (т. е. HkdfLabel.label) и часть значения, переданного функции HKDF-Expand.

   client in:  00200f746c73313320636c69656e7420696e00
   server in:  00200f746c7331332073657276657220696e00
   quic key:   00100e746c7331332071756963206b657900
   quic iv:    000c0d746c733133207175696320697600
   quic hp:    00100d746c733133207175696320687000

Общий исходный секрет

   initial_secret = HKDF-Extract(initial_salt, cid)
       = 7db5df06e7a69e432496adedb0085192
         3595221596ae2ae9fb8115c1e9ed0a44

Секреты для защиты пакетов клиента

   client_initial_secret
       = HKDF-Expand-Label(initial_secret, "client in", "", 32)
       = c00cf151ca5be075ed0ebfb5c80323c4
         2d6b7db67881289af4008f1f6c357aea

   key = HKDF-Expand-Label(client_initial_secret, "quic key", "", 16)
       = 1f369613dd76d5467730efcbe3b1a22d

   iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", "", 12)
       = fa044b2f42a3fd3b46fb255c

   hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", "", 16)
       = 9f50449e04a0e810283a1e9933adedd2

Секреты для защиты пакетов сервера

   server_initial_secret
       = HKDF-Expand-Label(initial_secret, "server in", "", 32)
       = 3c199828fd139efd216c155ad844cc81
         fb82fa8d7446fa7d78be803acdda951b

   key = HKDF-Expand-Label(server_initial_secret, "quic key", "", 16)
       = cf3a5331653c364c88f0f379b6067e37

   iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", "", 12)
       = 0ac1493ca1905853b0bba03e

   hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", "", 16)
       = c206b8d9b9f0f37644430b490eeaa314

A.2. Initial от клиента

В пакете Initial от клиента незащищённая часть данных (payload) содержит показанный ниже кадр CRYPTO и кадры PADDING для увеличения размера содержимого до 1162 байтов.

   060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
   04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
   616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
   04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
   baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
   0d0010000e0403050306030203080408 050806002d00020101001c0002400100
   3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
   75300901100f088394c8f03e51570806 048000ffff

Незащищённый заголовок указывает размер 1182 байта – 4-байтовый номер пакета, 1162 байта кадров и 16-байтовый тег аутентификации. Заголовок включает идентификатор соединения и номера пакета (2)

   c300000001088394c8f03e5157080000449e00000002

Из вывода защиты данных делается выборка для защиты заголовка. Поскольку в заголовке используется 4-байтовое кодирование порядкового номера, выбираются первые 16 байтов защищённых данных и применяются к заголовку, как показано ниже.

   sample = d1b1c98dd7689fb8ec11d242b123dc9b

   mask = AES-ECB(hp, sample)[0..4]
        = 437b9aec36

   header[0] ^= mask[0] & 0x0f
        = c0
   header[18..21] ^= mask[1..4]
        = 7b9aec34
   header = c000000001088394c8f03e5157080000449e7b9aec34

Полученный в результате защищённый пакет имеет вид

   c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11
   d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399
   1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c
   8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212
   30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5
   457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208
   4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec
   4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3
   485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db
   059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c
   7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8
   9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556
   be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74
   68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a
   c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00
   f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632
   291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964
   25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd
   14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff
   ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198
   e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd
   c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73
   203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f
   cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e
   fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade
   a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047
   90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2
   162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4
   40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0
   6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e
   8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0
   be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400
   54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab
   760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9
   f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4
   056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064
   7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241
   e221af44860018ab0856972e194cd934

A.3. Initial от сервера

Сервер передаёт в ответ показанный ниже пакет, включающий кадры ACK и CRYPTO без заполнения PADDING.

   02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
   88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
   0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
   020304

Заголовок от сервера включает новый идентификатор соединения и 2-байтовый номера пакета (1)

   c1000000010008f067a5502a4262b50040750001

После защиты пакета делается выборка, начиная с третьего байта

   sample = 2cd0991cd25b0aac406a5816b6394100
   mask   = 2ec0d8356a
   header = cf000000010008f067a5502a4262b5004075c0d9

Защищённый пакет в результате имеет вид

   cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a
   5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3
   dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84
   022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4
   2158407dd074ee

A.4. Пакет Retry

Ниже показан пакет Retry, который может быть передан в ответ на пакет Initial из Приложения A.2. Защита целостности включает выбранный клиентом идентификатор соединения 0x8394c8f03e515708, но это значение не включается в окончательный пакет Retry, показанный ниже.

   ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f
   0f2496ba

A.5. Пакет с коротким заголовком ChaCha20-Poly1305

В этом примере показаны некоторые шаги, требуемые для защиты пакета с коротким заголовком. Применяется шифрование AEAD_CHACHA20_POLY1305. В примере TLS создаёт для приложения секрет записи, из которого сервер с помощью HKDF-Expand-Label создаёт 4 значения – ключ, IV, ключ защиты заголовка и секрет, применяемый после обновления ключей (это значение далее в примере не используется).

   secret
       = 9ac312a7f877468ebe69422748ad00a1
         5443f18203a07d6060f688f30f21632b

   key = HKDF-Expand-Label(secret, "quic key", "", 32)
       = c6d98ff3441c3fe1b2182094f69caa2e
         d4b716b65488960a7a984979fb23e1c8

   iv  = HKDF-Expand-Label(secret, "quic iv", "", 12)
       = e0459b3474bdd0e44a41c144

   hp  = HKDF-Expand-Label(secret, "quic hp", "", 32)
       = 25a282b9e82f06f21f488917a4fc8f1b
         73573685608597d0efcb076b0ab7a7a4

   ku  = HKDF-Expand-Label(secret, "quic ku", "", 32)
       = 1223504755036d556342ee9361d25342
         1a826c9ecdf3c7148684b36b714881f9

Ниже показаны шаги, требуемые для защиты минимального пакета с пустым полем Destination Connection ID. Этот пакет содержит один кадр PING (содержимое 0x01) и имеет номер 654360564. В примере использование номера пакета размером 3 (кодируется в 49140) позволяет избежать дополнения содержимого пакета, если же использовать более короткое представление номера, потребуются кадры PADDING.

   pn                 = 654360564 (десятичное)
   nonce              = e0459b3474bdd0e46d417eb0
   unprotected header = 4200bff4
   payload plaintext  = 01
   payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb

Полученный шифротекст имеет минимальный размер. При выборке для защиты заголовка первый байт шифротекста пропускается.

   sample = 5e5cd55c41f69080575d7999c25a5bfb
   mask   = aefefe7d03
   header = 4cfe4189

Защищённый пакет имеет минимальный возможный размер 21 байт.

   packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb

Приложение B. Анализ алгоритмов AEAD

В этом приложении описан анализ, используемый при выводе ограничений AEAD для алгоритмов AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM. В описаниях используются символы умножения (*), деления (/), возведения в степень (^) и скобки для указания порядка действий. Описания символов приведены ниже.

t

Размер тега аутентификации с битах. Для рассматриваемых шифров это 128.

n

Размер блока в битах. Для рассматриваемых шифров это 128.

k

Размер ключа в битах. Это 128 для AEAD_AES_128_GCM и AEAD_AES_128_CCM, 256 для AEAD_AES_256_GCM.

l

Число блоков в каждом пакете (см. ниже).

q

Число подлинных пакетов, созданных и защищённых конечными точками. Это значение ограничивает число пакетов, которые можно защитить без смены ключей.

v

Число поддельных пакетов, которые будут принимать конечные точки. Это значение ограничивает число поддельных пакетов, которые конечная точка может отбросить до смены ключей.

o

Число автономных (offline) запросов шифрования, предпринимаемых злоумышленником.

Последующий анализ основан на подсчете числа операций с блоками при создании каждого сообщения. Этот анализ выполняется для пакетов размером до 211 (l = 27) и 216 (l = 212) байтов. Предполагается, что размер 211 будет пределом для базовых вариантов развёртывания, а 216 задаёт максимальный размер пакета QUIC. Лишь точки, строго ограничивающие размер пакетов, могут использовать более высокие пределы в части целостности и конфиденциальности, выведенные для меньших размеров.

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM размером сообщения (l) считается размер связанных данных в блоках с добавлением размера нешифрованных данных (plaintext) в блоках.

Для AEAD_AES_128_CCM общее число блочных операций шифрования является суммой размера связанных данных в блоках, размера шифротекста в блоках, размера открытых данных в блоках и 1. В этом анализе принимается упрощения до удвоенного размера пакета в блоках (т. е. 2l = 28 для пакетов до 211 байтов и 2l = 213 в остальных случаях). Это упрощение основано на пакетах, содержащих все связанные данные и шифротекст, что ведёт к завышению оценки числа операций для пакета на 1-3 блока.

B.1. Анализ применимости AEAD_AES_128_GCM и AEAD_AES_256_GCM

[GCM-MU] определяет конкретные границы применимости AEAD_AES_128_GCM и AEAD_AES_256_GCM при использовании в TLS 1.3 и QUIC. В этом параграфе приведён анализ в некоторыми упрощениями.

  • Число шифрованных блоков, используемых атакующим в попытках подделки, ограничено произведением v * l (число попыток подделки, умноженное на размер каждого пакета в блоках).

  • Объем работы, автономно выполняемой злоумышленником, не преобладает над другими факторами.

Ограничения в [GCM-MU] являются более жёсткими и полными по сравнению с [AEBounds], где разрешены пределы выше описанных в [TLS13].

B.1.1. Ограничение в части конфиденциальности

В части конфиденциальности теорема 4.3 в [GCM-MU] показывает, что для одного пользователя, не повторяющего значения nonce, доминирующим членом, определяющим сравнительные преимущества реального и случайного алгоритма AEAD, получаемые злоумышленником, составляют

   2 * (q * l)^2 / 2^n

Для целевого преимущества 2-57 это даёт

   q <= 2^35 / l

Таким образом, конечные точки, не передающие пакетов размером более 211 байтов, не могут защитить более 228 пакетов в одном соединении, не предоставляя атакующему преимущества выше 2-57. Для конечных точек, поддерживающих размер пакетов до 216 байтов, предел составляет 223.

B.1.2. Ограничение в части целостности

В части целостности теорема 4.3 в [GCM-MU] показывает, что атакующий получит преимущество в подделке пакетов не позднее указанного ниже числа пакетов.

   (1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n))
           + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)

Цель состоит в ограничении этого преимущества значением 2-57. Для AEAD_AES_128_GCM четвёртый член выражения доминирует над остальными, поэтому их можно исключить без существенного влияния на результат. Это даёт приближение

   v <= 2^64 / l

Конечные точки, не пытающиеся снимать защиту с пакетов размером более 211 байтов, могут снимать защиту не более чем с 257 пакетов. Конечные точки, не ограничивающие размер обрабатываемых пакетов, могут снять защиту не более чем с 252 пакетов.

Для AEAD_AES_256_GCM в выражении доминирует тот же член, но большее значение k даёт приближение

   v <= 2^192 / l

Это существенно выше предела для AEAD_AES_128_GCM, однако этот документ рекомендует одинаковый предел для обеих функций, поскольку оба из значений достаточно велики. .

B.2. Анализ применимости AEAD_AES_128_CCM

TLS [TLS13] и [AEBounds] не задают ограничений на использование AEAD_AES_128_CCM. Однако любой алгоритм AEAD, используемый с QUIC, требует ограничений, обеспечивающих сохранение конфиденциальности и целостности. В этом разделе приведён анализ этих ограничений, основанный на [CCM-ANALYSIS]. Результаты этого анализа применяются для вывода пределов применимости в соответствии с ограничениями, заданными в [TLS13].

В части конфиденциальности теорема 2 из [CCM-ANALYSIS] указывает, что атакующий получает заметное преимущество над идеальной псевдослучайной перестановкой (pseudorandom permutation или PRP) после не более чем (2l * q)2/2n пакетов.

В части целостности теорема 1 из [CCM-ANALYSIS] указывает, что атакующий получает строго большее преимуществу при том же числе пакетов. Поскольку цели получения преимуществ в части конфиденциальности и целостности совпадают, достаточно рассмотреть лишь теорему 1. Эта теорема показывает, что атакующий получает преимущество перед идеальной PRP при числе пакетов не более

   v / 2^t + (2l * (v + q))^2 / 2^n

Поскольку t и n имеют значение 128, первый член пренебрежимо мал по сравнению со вторым и его можно исключить без существенного влияния на результат. Это порождает отношение, объединяющее попытки шифрования и дешифровки с одинаковым пределом, который определяется лишь теоремой для конфиденциальности. Для целевого преимущества 2-57 это даёт

   v + q <= 2^34,5 / l

Установив q = v, можно получить значения для целостности и конфиденциальности. Конечные точки, ограничивающие размер пакетов значением 211 байтов, будут иметь в части целостности и конфиденциальность ограничение 226,5 пакетов. Конечные точки, не ограничивающие размер пакетов, будут иметь предел 221,5 пакетов.

Участники работы

Рабочая группа IETF QUIC получила поддержку от многих людей. Ниже перечислены те, кто внёс существенных вклад в работу.

Adam Langley

Alessandro Ghedini

Christian Huitema

Christopher Wood

David Schinazi

Dragana Damjanovic

Eric Rescorla

Felix Günther

Ian Swett

Jana Iyengar

奥 一穂 (Kazuho Oku)

Marten Seemann

Martin Duke

Mike Bishop

Mikkel Fahnøe Jørgensen

Nick Banks

Nick Harper

Roberto Peon

Rui Paulo

Ryan Hamilton

Victor Vasiliev

Адреса авторов

Martin Thomson (editor)

Mozilla

Email: mt@lowentropy.net

Sean Turner (editor)

sn3rd

Email: sean@sn3rd.com


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Server Name Identification – идентификация имени сервера.

4Application-Layer Protocol Negotiation – согласование протокола прикладного уровня.

Рубрика: RFC | Оставить комментарий

RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport (часть 2)

image_print

Часть 1

13. Пакетизация и надёжность доставки

Отправитель передаёт один или несколько кадров в пакете QUIC (см. параграф 12.4). Отправитель может минимизировать расход пропускной способности и вычислительные затраты на уровне пакета путём включения максимально возможного числа кадров в каждый пакет QUIC. Отправитель может ждать в течение короткого времени сбора нескольких кадров перед отправкой пакета, который не заполнен до максимума, чтобы избежать отправки большого числа мелких пакетов. Реализация может использовать сведения о поведении или эвристику для определения времени ожидания. Этот период определяется реализацией и следует быть осторожным при выборе задержки, поскольку она будет влиять на задержку, с которой сталкивается приложение.

Мультиплексирование потоков обеспечивается чередованием кадров STREAM из разных пакетов в одном или нескольких пакетах QUIC. Пакет QUIC может включать множество кадров STREAM из одного или разных потоков.

Одним из преимуществ QUIC является предотвращение блокировки head-of-line между разными потоками. При наличии потерь пакетов блокируются лишь потоки с данными из потерянного пакета в ожидании повторной передачи, а другие потоки продолжают работать нормально. Отметим, что при включении данных из нескольких потоков в один пакет QUIC потеря такого пакета блокирует обработку всех этих потоков. Разработчикам рекомендуется включать в исходящие пакеты минимальное число потоков без потери эффективности в результате передачи мелких пакетов.

13.1. Обработка пакета

Пакет недопустимо подтверждать до снятия защиты и обработки всех содержащихся в нем кадров. Для кадров STREAM это означает, что данные помещены в очередь для отправки протоколу приложения, но не требуется их фактическая доставка и потребление.

После полной обработки пакета получатель подтверждает приём отправкой одного или нескольких кадров ACK с номером полученного пакета.

Конечной точке следует считать подтверждение пакета, который она не передавала, ошибкой соединения типа PROTOCOL_VIOLATION, если она может это обнаружить. Дополнительное обсуждение приведено в параграфе 21.4.

13.2. Генерация подтверждений

Конечные точки подтверждают все пакеты, которые они получили и обработали. Однако лишь пакеты с запросом подтверждения (ack-eliciting) вызывают отправку кадра ACK в интервале максимально разрешённой задержки подтверждения. Остальные пакеты подтверждаются лишь при отправке кадра ACK по иным причинам.

При любой отправке пакета конечной точке следует попытаться включить в него кадр ACK, если он ещё не передан. Это помогает партнёру своевременно обнаруживать потери пакетов.

В общем случае частые отклики от получателя улучшают реакцию на потери и перегрузку, но следует принимать во внимание нагрузку на получателя, связанную с генерацией кадра ACK в ответ на каждый принятый пакет с запросом подтверждения. Ниже приведены рекомендации, позволяющие обеспечить баланс.

13.2.1. Передача кадров ACK

Каждый пакет следует подтверждать по меньшей мере один раз, а пакеты с запросом подтверждения должны подтверждаться не менее 1 раза в интервале максимальной задержки, указанного конечной точкой в транспортном параметре max_ack_delay (см. раздел 18.2). Параметр max_ack_delay задаёт явное требование – конечная точка обещает никогда не задерживать преднамеренно подтверждения пакетов ack-eliciting более указанного времени. Если задержка происходит, любое превышение учитывается при оценке RTT и может приводить к ложным или задержанным повторам передачи партнёром. Отправитель использует значение max_ack_delay, заданное получателем, при определении тайм-аутов для повтора по времени, как описано в параграфе 6.2 [QUIC-RECOVERY].

Конечная точка должна подтверждать все пакеты Initial и Handshake с запросом подтверждения незамедлительно, а все пакеты 0-RTT и 1-RTT с запросом подтверждения в анонсированном интервале max_ack_delay, с одним исключением. До подтверждения согласования (handshake) у конечной точки может не быть ключей для расшифровки принимаемых пакетов Handshake, 0-RTT, 1-RTT, поэтому она может буферизовать их и подтверждать после обретения ключей.

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

Конечной точке недопустимо передавать пакет без запроса подтверждения в ответ на пакет без запроса подтверждения, даже при наличии пропуска перед полученным пакетом. Это позволяет избежать зацикливания откликов с подтверждениями, который может препятствовать переходу соединения в режим бездействия (idle). Пакеты без запроса подтверждения в конечном итоге подтверждаются отправкой кадра ACK в ответ на другие события.

Конечная точка, передающая лишь кадры ACK, не будет получать подтверждений от партнёра, пока эти подтверждения не будут включены в пакеты с кадрами, запрашивающими подтверждение. Конечной точке следует передавать кадр ACK с другими кадрами, когда имеются новые пакеты с запросом подтверждения. Когда нужно подтверждать лишь пакеты, не запрашивающие подтверждения, конечная точка может не передавать кадр ACK, пока не будет получен пакет с запросом подтверждения.

Конечная точка, передающая лишь пакеты без запроса подтверждения, может иногда добавлять в пакеты кадр с запросом подтверждения, чтобы получить подтверждение своих пакетов (см. параграф 13.2.4). В таких случаях конечной точке недопустимо передавать кадр с запросом подтверждения во всех пакетах, которые без этого не запрашивали подтверждения, чтобы избежать бесконечного зацикливания подтверждений.

Для оказания помощи в обнаружении потерь отправителем конечной точке следует создавать и отправлять кадр ACK без задержки при получении пакета с запросом подтверждения, а также:

  • при получении пакета с номером меньше чем в другом полученном пакете с запросом подтверждения;

  • при получении пакета с номером больше максимального среди полученных пакетов с запросом подтверждения, когда имеется пропуск номером между этими пакетами.

Точно так же пакеты с кодом ECN CE1 в заголовке IP следует подтверждать незамедлительно для снижения времени отклика партнёра на перегрузку.

Предполагается, что алгоритмы [QUIC-RECOVERY] будут устойчивы к получателям, которые не следуют приведённым выше рекомендациям. Однако реализациям следует отходить от этих требований лишь при внимательном рассмотрении влияния на производительность для соединений данной конечной точки и других пользователей сети.

13.2.2. Частота подтверждений

Получатель определяет частоту отправки подтверждений в ответ на пакеты с запросом подтверждения с учётом рассмотренных ниже компромиссов.

Конечные точки полагаются на своевременные подтверждения при обнаружении потерь (см. раздел 6 в [QUIC-RECOVERY]). Контроллеры перегрузки на основе окна, такие как описано в разделе 7 [QUIC-RECOVERY], используют подтверждения для управления окном перегрузки. В обоих случаях задержка подтверждений может существенно влиять на производительность. С другой стороны, снижение частоты передачи пакетов, содержащих лишь подтверждения, уменьшает издержки на передачу и обработку в обеих конечных точках. Это может значительно повысить пропускную способность на ассиметричных каналах и снизить объем трафика подтверждений на пути возврата (см. раздел 3 в [RFC3449]).

Получателю следует передавать кадр ACK после приёма по меньшей мере двух пакетов с запросом подтверждения. Эта рекомендация имеет общий характер и согласуется с рекомендациями для конечных точек TCP [RFC5681]. Знание условий в сети и сведения о контроллере перегрузок у партнёра, а также дополнительные исследования и эксперименты могут предложить иную стратегию подтверждения с лучшими показателями производительности.

Получатель может обработать несколько доступных пакетов до решения вопроса об отправке в ответ кадра ACK.

13.2.3. Поддержка диапазонов ACK

При отправке кадра ACK включается один или несколько диапазонов подтверждаемых пакетов. Подтверждение более старых пакетов снижает вероятность ненужных повторов, вызванных потерей кадров ACK за счёт роста размера ACK.

Кадрам ACK всегда следует подтверждать полученные недавно пакеты и чем больше разупорядоченных пакетов, тем более важна быстрая отправка обновлённого кадра ACK, чтобы партнёр не счёл пакеты потерянными и не повторил их. Предполагается, что кадр ACK поместится в один пакет QUIC. Если это не так, более старые пакеты (с меньшими номерами) исключаются из подтверждения.

Получатель ограничивает число диапазонов ACK (параграф 19.3.1), которые он запоминает и передаёт в кадрах ACK, как для ограничения размера кадров, так и для экономии ресурсов. После приёма подтверждений для кадра ACK получателю следует остановить отслеживание подтверждённых диапазонов ACK. Отправители могут ожидать подтверждения для большинства пакетов, но QUIC не гарантирует получение подтверждения для каждого пакета, обработанного получателем.

Сохранение множества диапазонов ACK может привести к чрезмерному росту кадра ACK. Получатель может отбросить неподтвержденные ACK Range для снижения размера кадра ACK за счёт роста числа повтором передачи отправителем. Это необходимо, если кадр ACK слишком велик для включения в пакет. Получатель может также дополнительно ограничить размер кадра ACK, чтобы сохранить место для других кадров и снизить расходуемую на подтверждения пропускную способность.

Получатель должен сохранять ACK Range, пока не может гарантировать, что позднее не воспримет пакеты из этого диапазона. Поддержка минимального номера пакета, возрастающего по мере отбрасывания диапазонов является одним из способов решения задачи с минимальным состоянием. Получатель может отбросить все ACK Range, но он должен хранить максимальный номер успешно обработанного пакета, поскольку он служит для восстановления номеров из последующих пакетов (см. параграф 17.1). Получателю следует включать ACK Range с наибольшим полученным номером пакета в каждый кадр ACK. Поле Largest Acknowledged применяется при проверке ECN у отправителя и включение значения меньше указанного в предыдущем кадре ACK может приводить к ненужному отключению ECN (см. параграф 13.4.2).

В параграфе 13.2.4 описан примерный подход к определению пакетов, подтверждаемых в каждом кадре ACK. Хотя цель алгоритма состоит в генерации подтверждения для каждого обработанного пакета, это не препятствует потере подтверждений.

13.2.4. Ограничение диапазонов путём отслеживания кадров ACK

При отправке пакета с кадром ACK поле Largest Acknowledged из этого кадра может быть сохранено. При подтверждении пакета с кадром ACK получатель может остановить подтверждение пакетов, в которых номера не больше Largest Acknowledged в переданном кадре ACK.

Получатель, который передаёт лишь пакеты без запроса подтверждения, такие как кадры ACK, может долго не получать подтверждений. Это может вынудить его поддерживать состояние для большого числа кадров ACK в течение длительного времени, а передаваемые кадра ACK могут стать чересчур большими. В таком случае получатель может передать PING или другой мелкий кадр с запросом подтверждения, например, один раз за интервал кругового обхода, для запроса у партнёра подтверждения ACK.

При отсутствии потерь ACK этот алгоритм допускает как минимум один интервал RTT с разупорядочением. При потере и нарушении порядка ACK этот подход не гарантирует, что каждое подтверждение отправитель увидит до того, как оно перестанет включаться в кадр ACK. Пакеты могут приниматься с нарушением порядка, а все последующие кадры ACK, содержащие подтверждение, могут быть потеряны. В этом случае алгоритм восстановления потерь может вызывать ложные повторы, но отправитель продолжит «двигаться вперёд».

13.2.5. Измерение и передача задержки на хосте

Конечная точка измеряет задержки, намеренно внесённые между приёмом пакета с наибольшим порядковым номером и отправкой подтверждения. Конечная точка представляет эту задержку подтверждения в поле ACK Delay кадра ACK (см. параграф 19.3), что позволяет получателю кадра ACK уточнить преднамеренные задержки, важные для более точной оценки RTT на пути при задержке подтверждений.

Пакет может перед обработкой храниться в ядре OS или ином месте. Конечной точке недопустимо включать не контролируемую ею задержку в поле ACK Delay кадра ACK. Однако конечным точкам следует включать задержки на буферизацию, вызванные недоступностью ключей расшифровки, поскольку такие задержки могут быть большими и обычно не повторяются.

Когда измеренная задержка подтверждения превышает max_ack_delay, конечной точке следует сообщить об измеренной задержке. Эта информация особенно полезна при согласовании, когда задержки могут быть велики (см. параграф 13.2.1).

13.2.6. Кадры ACK и защита пакета

Кадры ACK должны передаваться лишь в пакетах из одного пространства номеров с подтверждаемым пакетом (см. параграф 12.1). Например, пакеты, защищённые ключами 1-RTT, должны подтверждаться в пакетах, также защищённых ключами 1-RTT.

Пакеты, которые клиент передаёт с защитой 0-RTT, должны подтверждаться сервером в пакетах, защищённых ключами 1-RTT. Это означает, что клиент не может использовать эти подтверждения, если пакеты криптографического согласования от сервера задержаны или потеряны. Отметим, что такое же ограничение применимо и к другим данным, которые сервер защищает с помощью ключей 1-RTT.

13.2.7. Кадры PADDING, занимающие окно перегрузки

Пакеты с кадрами PADDING считаются находящимися в пути для контроля перегрузок [QUIC-RECOVERY]. Поэтому пакеты, содержащие лишь кадры PADDING, занимают окно перегрузки, не не создают подтверждений, открывающих окно перегрузки. Для предотвращения блокировки отправителю следует обеспечивать периодическую передачу других кадров в дополнение к кадрам PADDING, чтобы запросить подтверждения у получателя.

13.3. Повторная передача информации

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

  • Данные из кадров CRYPTO передаются повторно в соответствии с правилами [QUIC-RECOVERY], пока все данные не будут подтверждены. Данные в кадрах CRYPTO пакетов Initial и Handshake отбрасываются при отбрасывании ключей для соответствующего пространства номеров.

  • Прикладные данные из кадров STREAM передаются снова в других кадрах STREAM, пока конечная точка не передала RESET_STREAM для этого потока. После передачи передачи конечной точкой кадра RESET_STREAM, кадры STREAM передавать не требуется.

  • Кадры ACK содержат набор наиболее свежих подтверждений и задержку подтверждения из самого большого подтверждённого пакета, как описано в параграфе 13.2.1. Задержка передачи пакетов с кадрами ACK или повторная передача ACK может вынудить партнёра генерировать завышенную выборку RTT или неоправданный запрет ECN.

  • Отмена передачи потока в кадре RESET_STREAM передаётся, пока не будет подтверждена или пока партнёр не подтвердит все данные потока (т. е. будет достигнуто состояние Reset Recvd или Data Recvd на передающей стороне потока). Содержимое RESET_STREAM недопустимо менять при повторе передачи.

  • Аналогично, запрос на отмену передачи потока в кадре STOP_SENDING, отправляется пока принимающая сторона потока не перейдёт в состояние Data Recvd или Reset Recvd (см. параграф 3.5).

  • Сигналы закрытия соединения, включая пакеты с кадрами CONNECTION_CLOSE, не повторяются при обнаружении потери пакета. Повторная отправка этих сигналов описана в разделе 10.

  • Максимальный объем данных текущего соединения передаётся в кадрах MAX_DATA. Обновлённое значение передаётся в кадре MAX_DATA, если пакет с наиболее свежим переданным кадром MAX_DATA был объявлен потерянным или конечная точка решила обновить предел. Нужна осторожность, чтобы избежать слишком частой отправки этого кадра, поскольку предел может увеличиваться часто и это вызовет передачу слишком большого числа кадров MAX_DATA (см. параграф 4.2).

  • Текущее максимальное смещение данных потока передаётся в кадрах MAX_STREAM_DATA. Подобно MAX_DATA, обновлённое значение передаётся, если наиболее свежий кадр MAX_STREAM_DATA для потока потерян или предел обновлён, с мерами предосторожности для предотвращения отправки кадров слишком часто. Конечной точке следует останавливать передачу кадров MAX_STREAM_DATA, когда принимающая сторона потока переходит в состояние Size Known или Reset Recvd.

  • Ограничение числа потоков данного типа передаётся в кадрах MAX_STREAMS. Подобно MAX_DATA, обновлённое значение передаётся, когда пакет с наиболее свежим MAX_STREAMS для этого типа потока объявлен потерянным или при обновлении предела, с мерами предосторожности для предотвращения слишком частой отправки.

  • Сигналы блокировки передаются в кадрах DATA_BLOCKED, STREAM_DATA_BLOCKED и STREAMS_BLOCKED. Областью действия DATA_BLOCKED является соединение, STREAM_DATA_BLOCKED – поток, STREAMS_BLOCKED – конкретный тип потока. Новый кадр передаётся, если пакет с наиболее свежим кадром для области действия считается потерянным при условии блокировки конечной точки по соответствующему пределу. Эти кадры всегда включают предел, вызвавший блокировку на момент передачи.

  • Проверка живучести или пути использует кадры PATH_CHALLENGE, передаваемые периодически, пока не будет получен соответствующий кадр PATH_RESPONSE или не отпадёт необходимость в проверке. Кадры PATH_CHALLENGE включают при каждой отправке разные данные.

  • Отклики при проверке пути с использованием кадров PATH_RESPONSE передаются однократно. Предполагается, что партнёр передаст при необходимости дополнительные кадры PATH_CHALLENGE для отправки новых кадров PATH_RESPONSE.

  • Новые идентификаторы соединения передаются в кадрах NEW_CONNECTION_ID и повторяются при потере пакета с сохранением порядкового номера. Отозванные идентификаторы соединения передаются в кадрах RETIRE_CONNECTION_ID и повторяются при потере пакета.

  • Кадры NEW_TOKEN передаются повторно при потере пакета с кадром. Для этих кадров не выполняется обнаружения разупорядочения или дублирования сверх прямого сравнения содержимого кадров.

  • Кадры PING и PADDING не содержат информации, поэтому их потеря не требует восстановления.

  • Кадр HANDSHAKE_DONE должен передаваться повторно, пока не будет получено подтверждение.

Конечным точкам следует отдавать приоритет повторной передаче перед отправкой новых данных, пока заданные приложением приоритеты не требуют иного (см. параграф 2.3).

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

Отправителю следует избегать повторной передачи информации из пакетов после их подтверждения. Это включает пакеты, подтверждённые после того, как были сочтены потерянными, что может происходить при нарушении порядка пакетов в сети. Это требует от отправителя сохранять сведения о пакетах, которые объявлены потерянными. Отправитель может отбросить эти сведения по истечении времени, достаточного для переупорядочения, например, PTO (параграф 6.2 в [QUIC-RECOVERY]), или по другим событиям, таким как ограничение памяти.

При обнаружении потерь отправитель должен принять меры по контролю перегрузки. Детали обнаружения потерь и контроля перегрузки описаны в [QUIC-RECOVERY].

13.4. Явное уведомление о перегрузке

Конечные точки QUIC могут использовать ECN [RFC3168] для обнаружения перегрузки в сети и реагирования на неё. ECN позволяет конечной точке установить код ECT2 в поле ECN пакета IP. Узел сети может тогда указать перегрузку, устанавливая код ECN-CE в поле ECN вместо отбрасывания пакета [RFC8087]. Конечные точки реагируют на сведения о перегрузке путём снижения скорости передачи, как описано в [QUIC-RECOVERY].

Для включения ECN передающая конечная точка QUIC сначала проверяет поддержку маркировки ECN на пути и возможность партнёра сообщать значения ECN в принятых пакетах IP (см. параграф 13.4.2).

13.4.1. Информирование о значениях ECN

Использование ECN требует от приёмной конечной точки считывать значение поля ECN из пакета IP, что возможно не на всех платформах. Если конечная точка не поддерживает ECN или не имеет доступа к полученным полям ECN, она не будет сообщать значения ECN из полученных пакетов.

Даже если конечная точка не устанавливает поле ECT в передаваемых пакетах, она должна предоставлять отклики о полученных маркерах ECN, если они доступны. Отказ от передачи этих значений вынудит отправителя отключить использование ECN в соединении.

При получении пакета IP с кодом ECT(0), ECT(1) или ECN-CE конечная точка с поддержкой ECN обращается к полю ECN и увеличивает соответствующее значение ECT(0), ECT(1) или ECN-CE. Значения ECN включаются в последующие кадры ACK (см. параграфы 13.2 и 19.3).

В каждом пространстве номеров пакетов поддерживаются отдельные состояния подтверждений и значения ECN. Объединённые пакеты QUIC (см. параграф 12.2) используют общий заголовок IP, поэтому счётчики ECN инкрементируются 1 раз для каждого объединённого пакета QUIC. Например, если пакеты Initial, Handshake и 1-RTT объединяются в одну дейтаграмму UDP, счётчики ECN для всех трёх пространств номеров будут инкрементироваться на 1.

Счётчики ECN инкрементируются лишь в том случае, когда пакеты QUIC из полученного пакета IP обработаны. Таким образом, дубликаты пакетов QUIC не увеличивают счётчики ECN (см. параграф 21.10 в части безопасности).

13.4.2. Проверка ECN

Неисправные устройства в сети могут повреждать или ошибочно отбрасывать пакеты с ненулевым кодом ECN. Для обеспечения связности при наличии таких устройств конечная точка проверяет значения ECN для каждого пути через сеть и отключает ECN на путях с ошибками. Для проверки ECN на новом пути:

  • конечная точка устанавливает код ECT(0) в заголовке IP ранних исходящих пакетов на новом пути к партнёру [RFC8311];

  • конечная точка отслеживает, все ли пакеты, переданные с кодом ECT, в конечном итоге будут потеряны (параграф 6 в [QUIC-RECOVERY]), что говорит об отказе при проверке ECN.

Если у конечной точки есть основания ожидать отбрасывания пакетов IP с кодом ECT неисправными элементами сети, она может устанавливать код ECT лишь для первого десятка исходящих пакетов на этом пути или в течении трёх PTO (см. параграф 6.2 в [QUIC-RECOVERY]). Если все пакеты с ненулевым кодом ECN будут потеряны, она может отключить маркировку в предположении, что та вызывает потерю пакетов. Таким образом, конечная точка пытается использовать ECN и проверяет это для каждого нового соединения при переключении на предпочтительный адрес сервера или активном переходе соединения на новый путь. Возможный алгоритм представлен в Приложении A.4. Возможны и другие методы проверки ECN на пути, а также иная стратегия маркировки. Реализации могут применять другие методы, определённые в RFC, см. [RFC8311].Реализациям, использующим код ECT(1) нужно выполнять проверку ECN с использованием сообщаемых значений ECT(1).

13.4.2.1. Прием кадров ACK со значениями ECN

Ошибочная маркировка ECN-CE в сети может снижать производительность соединения. Конечная точка, получившая кадр ACK со значением ECN, проверяет полученное значение до его использования. Эта проверка выполняется путём сравнения недавно полученного значения со значениями из последнего успешно обработанного кадра ACK. Любое увеличение счётчика ECN проверяется на основе маркировки ECN, которая применялась для пакетов, которые недавно подтверждены в кадре ACK.

Если кадр ACK снова подтверждает пакет, переданный конечной точкой с кодом ECT(0) или ECT(1), это говорит о неудачной проверке ECN при отсутствии соответствующих счётчиков ECN в кадре ACK. Такая проверка обнаруживает элементы сети, которые обнуляют поле ECN, или партнёра, не сообщающего маркировку ECN. Проверка ECN также будет неудачной, если сумма роста счётчиков ECT(0) и ECN-CE меньше числа недавно подтверждённых пакетов, которые были переданы с маркировкой ECT(0). Точно так же проверка ECN будет неудачной, если сумма увеличения счётчиков ECT(1) и ECN-CE будет меньше числа недавно подтверждённых пакетов, которые были переданы с маркировкой ECT(1). Это позволяет обнаружить перемаркировку ECN-CE в сети.

Конечная точка может пропустить подтверждения для пакета при потере кадров ACK, поэтому общее увеличение счётчиков ECT(0), ECT(1) и ECN-CE может быть больше числа пакетов, недавно подтверждённых в кадре ACK. По этой причине счётчикам ECN разрешено превышать общее число подтверждённых пакетов.

Проверка счётчиков ECN из разупорядоченных кадров ACK может завершаться отказом. Конечной точке недопустимо учитывать отказ при проверке ECN в результате обработки кадра ACK, не увеличивающего максимальный подтверждённый порядковый номер.

Проверка ECN может быть неудачно если полученное общее значение счётчика для ECT(0) или ECT(1) превышает общее число пакетов, переданных с соответствующим кодом ECT. В частности, проверка будет неудачной, когда конечная точка получит отличный от 0 счётчик ECN, соответствующий не применявшемуся коду ECT. Такая проверка обнаруживает перемаркировку в ECT(0) или ECT(1) внутри сети.

13.4.2.2. Результаты проверки ECN

При неудачной проверке конечная точка должна отключить ECN и прекратить установку кода ECT в передаваемых пакетах IP, предполагая, что путь через сеть или партнёр не поддерживают ECN. Даже после неудачной проверки конечная точка может снова проверить ECN для того же пути позднее в процессе работы соединения. Конечная точка может периодически выполнять такие проверки.

После успешной проверки конечная точка может продолжать установку кода ECT в передаваемых пакетах, предполагая, что путь поддерживает ECN. Маршрутизация и элементы пути могут меняться при работе соединения и конечная точка должна отключить ECN, если проверка завершается отказом.

14. Размер дейтаграмм

Дейтаграмма UDP может содержать один или несколько пакетов QUIC. Размер дейтаграммы определяется общим размером данных UDP в одной дейтаграмме, переносящей пакеты QUIC. В размере дейтаграммы учитываются заголовки одного или нескольких пакетов QUIC и защищённые данные, но не учитываются заголовки UDP и IP.

Максимальный размер дейтаграммы определяется как наибольший размер данных UDP (payload), которые могут быть переданы через сетевой путь в одной дейтаграмме UDP. Недопустимо использование QUIC, если путь через сеть не поддерживает дейтаграммы размером по меньшей мере 1200 байтов.

В QUIC предполагается минимальный размер пакета IP не менее 1280 байтов. Эти минимальный размер для IPv6 [IPv6] и он поддерживается в большинстве современных сетей IPv4. В предположении заголовка IP размером 40 байтов для IPv6 и 20 для IPv4, а также размера заголовка UDP 8 байтов максимальный размер дейтаграммы будет 1232 байта для IPv6 и 1252 для IPv4. Таким образом, пути через современные сети IPv4 и все сети IPv6 предполагаются пригодными для QUIC.

Примечание. Требование поддержки данных UDP размером 1200 байтов ограничивает пространство для заголовков расширения IPv6 значением 32 байта и опций IPv4 – значением 52 байта, если путь поддерживает лишь минимальное для IPv6 значение MTU в 1280 байтов. Это влияет на пакеты Initial и проверку пути.

Превышение значения 1200 байтов для максимального размера в можно обнаружить с помощью механизма PMTUD3 (см. параграф 14.2.1) или DPLPMTUD4 (см. параграф 14.3).

Применение транспортного параметра max_udp_payload_size (параграф 18.2) может служить дополнительным ограничением максимального размера дейтаграмм. Отправитель может избежать превышения этого предела, если значение известно. Однако до получения транспортного параметра конечные точки рискуют терять слишком большие дейтаграммы при передаче с превышением наименьшего разрешённого максимума в 1200 байтов.

Дейтаграммы UDP недопустимо фрагментировать на уровне IP. В IPv4 [IPv4] должен устанавливаться флаг запрета фрагментирования (Don’t Fragment или DF), если это возможно.

QUIC иногда требует, чтобы дейтаграммы были не меньше определённого размера (см., например, параграф 8.1). Однако размер дейтаграмм не аутентифицируется, т. е. при получении конечной точкой дейтаграммы она не может знать, что отправитель передал дейтаграмму того же размера. Поэтому конечным точкам недопустимо закрывать соединение при получении дейтаграммы, не соответствующей ограничениям размера, но можно отбрасывать такие дейтаграммы.

14.1. Размер дейтаграмм Initial

Клиент должен расширять данные в дейтаграммах UDP с пакетом Initial по меньшей мере до наименьшего максимального размера дейтаграмм в 1200 байтов, добавляя кадры PADDING к пакету Initial или объединяя пакет Initial с другими (см. параграф 12.2). Пакет Initial можно объединить даже с недействительным пакетом, который получатель отбросит. Сервер также должен расширять данные всех дейтаграмм UDP с пакетом Initial, запрашивающим подтверждение, до наименьшего максимального размера дейтаграмм в 1200 байтов.

Передача дейтаграмм UDP такого размера гарантирует поддержку на пути через сеть приемлемого значения PMTU в обоих направлениях. Кроме того, расширение клиентом пакетов Initial помогает снизить амплитуду атак с усилением, вызываемых ответами сервера по непроверенным адресам клиентов (см. раздел 8).

Дейтаграммы с пакетом Initial могут иметь размер больше 1200 байтов, если отправитель считает, что путь в сети и партнёр поддерживают такой размер.

Сервер должен отбрасывать пакет Initial, переданный в дейтаграмме UDP с объёмом данных меньше наименьшего максимума в 1200 байтов. Сервер может также незамедлительно закрыть соединение, передав кадр CONNECTION_CLOSE с кодом ошибки PROTOCOL_VIOLATION (см. параграф 10.2.3).

Сервер также должен ограничивать число байтов, передаваемых до проверки адреса клиента (см. раздел 8).

14.2. MTU на пути

PMTU определяет максимальный размер пакета IP с учётом заголовков IP и UDP, а также данных UDP, включая один или несколько заголовков пакетов QUIC и защищённые данные. PMTU может зависеть от характеристик пути и меняться с течением времени. Максимальный размер данных UDP (payload), которые конечная точка может передать в данный момент называется максимальным размером дейтаграммы для конечной точки.

Конечной точке следует применять механизм DPLPMTUD (параграф 14.3) или PMTUD (параграф 14.2.1) для определения максимального размера (без фрагментации) дейтаграмм на пути к получателю. При отсутствии этих механизмов конечным точкам QUIC не следует передавать дейтаграммы размером больше наименьшего максимума.

DPLPMTUD и PMTUD передают дейтаграммы размером больше текущего максимума, называемые зондами PMTU. Всем пакетам QUIC, передаваемым не в зондах PMTU, следует ограничивать размер для размещения в дейтаграммах максимального размера, чтобы избежать фрагментации или отбрасывания [RFC8085].

Если конечная точка QUIC определяет, что PMTU между локальным и удаленным адресом IP не позволяет передать дейтаграммы с наименьшим максимальным размером в 1200 байтов, она должна незамедлительно прекратить передачу пакетов QUIC, за исключением пакетов в зондах PMTU, а также пакетов с кадрами CONNECTION_CLOSE по соответствующему пути. Конечная точка может прервать соединение при отсутствии других путей.

Каждая пара из локального и удалённого адреса может иметь своё значение PMTU. Реализациям QUIC, использующим какой-либо механизм определения PMTU, следует поддерживать максимальный размер дейтаграмм для каждой пары адресов IP (локальный и удалённый).

Реализация QUIC может быть более консервативной при расчёте максимального размера дейтаграмм, чтобы учесть неизвестные издержки туннелирования и/или опций (расширений) в заголовках IP.

14.2.1. Обработка сообщений ICMP в PMTUD

PMTUD [RFC1191] [RFC8201] полагается на приём сообщений ICMP (т. е. IPv6 Packet Too Big), указывающий, что пакет IP отброшен из-за превышения MTU на маршрутизаторе. DPLPMTUD также может использовать такие сообщения. Этот подход имеет уязвимость для атак со стороны объектов, не способных наблюдать за пакетами, но могущим угадать используемые на пути адреса. Такие атаки позволяют снизить значение PMTU для уменьшения пропускной способности. Конечная точка должна игнорировать сообщения ICMP, заявляющие о снижении PMTU ниже наименьшего для QUIC максимума размера дейтаграмм.

В требованиях к генерации ICMP [RFC1812] [RFC4443] сказано, что в пакет следует включать максимально возможную часть исходного пакета без превышения минимального MTU для версии IP. Размер включаемой в сообщение части пакета может быть меньше или информация может быть непонятной, как указано в параграфе 1.1 [DPLPMTUD].

Конечным точкам QUIC, использующим PMTUD, следует проверять сообщения ICMP для защиты от вставки пакетов, как указано в [RFC8201] и параграфе 5.2 [RFC8085]. Для этой проверки следует использовать включённую в сообщение часть пакета для сопоставления сообщения ICMP с соответствующим транспортным соединением (см. параграф 4.6.1 в [DPLPMTUD]). Проверка сообщения ICMP должна включать сопоставление адреса IP и порта UDP [RFC8085], а по возможности идентификатор соединения для активной сессии QUIC. Конечное точке следует игнорировать сообщения ICMP, не прошедшие проверку.

Конечной точке недопустимо увеличивать PMTU на основе сообщений ICMP (см. п. 6 в разделе 3 [DPLPMTUD]). Снижение максимального размера дейтаграмм QUIC в ответ на сообщения ICMP может быть предварительным, пока алгоритм обнаружения потерь QUIC не укажет, что пакет был действительно потерян.

14.3. Определение PMTU для уровня пакетизации дейтаграмм

DPLPMTUD [DPLPMTUD] полагается на отслеживание потерь или подтверждений пакетов QUIC, переданных в зондах PMTU. Зонды PMTU для DPLPMTUD, использующие кадр PADDING, реализуют «Зондирование с использованием заполнения», описанное в параграфе 4.1 [DPLPMTUD].

Конечным точкам следует устанавливать исходное значение BASE_PLPMTU (параграф 5.1 в [DPLPMTUD]) в соответствии с наименьшим максимальным размером дейтаграмм QUIC. MIN_PLPMTU совпадает с BASE_PLPMTU.

Конечные точки QUIC, реализующие DPLPMTUD, поддерживают максимальный размер пакета DPLPMTUD (Maximum Packet Size или MPS) (параграф 4.4 в [DPLPMTUD]) для каждой пары из локального и удалённого адреса IP. Это соответствует максимальному размеру дейтаграмм.

14.3.1. DPLPMTUD и связность для Initial

С точки зрения DPLPMTUD протокол QUIC является уровнем пакетизации (Packetization Layer или PL) с подтверждениями. Поэтому отправитель QUIC может перейти в состояние DPLPMTUD BASE (параграф 5.2 в [DPLPMTUD]) по завершении согласования QUIC.

14.3.2. Проверка сетевого пути с DPLPMTUD

QUIC является PL с подтверждениями, поэтому отправитель QUIC не реализует DPLPMTUD CONFIRMATION_TIMER в состоянии SEARCH_COMPLETE (см. параграф 5.2 в [DPLPMTUD]).

14.3.3. Обработка сообщений ICMP в DPLPMTUD

Конечная точка, применяющая DPLPMTUD, требует проверки любого полученного сообщения ICMP PTB до использования сведений PTB, как указано в параграфе 4.6 [DPLPMTUD]. В дополнение к проверке порта UDP протокол QUIC проверяет сообщение ICMP путём использования других сведений PL (например, проверку идентификатора соединения во включённой в сообщение ICMP части исходного пакета).

Рассмотренные в параграфе 14.2.1 вопросы обработки сообщений ICMP применимы и к сообщениям, используемым DPLPMTUD.

14.4. Отправка зондов QUIC PMTU

Зонды PMTU являются пакетами с запросом подтверждения.

Конечные точки могут ограничивать содержимое зондов PMTU кадрами PING и PADDING, поскольку пакеты с размером, превышающий текущий максимум для дейтаграмм, с большой вероятностью будут отброшены сетью. Поэтому потеря пакета QUIC в зонде PMTU не является надёжной индикацией перегрузки и ей не следует вызывать реакцию механизма контроля перегрузок (см. п. 7 в разделе 3 [DPLPMTUD]). Однако зонды PMTU занимают окно перегрузки, что может задерживать последующую передачу данных приложения.

14.4.1. Зонды PMTU с Source Connection ID

Конечные точки, полагающиеся на поле Destination Connection ID при маршрутизации входящих пакетов QUIC, вероятно потребуют включения идентификатора соединения в зонды PMTU для корректной маршрутизации возвращаемых сообщений ICMP (параграф 14.2.1). Однако поле Source Connection ID содержат лишь длинные заголовки (параграф 17.2), а пакеты с таким заголовком не шифруются и не подтверждаются партнёром после завершения согласования.

Одним из способов создания зонда PMTU является объединение (см. параграф 12.2) пакета с длинным заголовком, такого как Handshake или 0-RTT (параграф 17.2) и пакета с коротким заголовком в одну дейтаграмму UDP. Если полученный зонд PMTU достигает конечной точки, пакет с длинным заголовком она проигнорирует, но подтвердит пакет с коротким заголовком. Если зонд PMTU вызывает отправку сообщения ICMP, в это сообщение будет включена первая часть пробного пакета. Если поле Source Connection ID попадает в эту часть, оно может служить для маршрутизации или проверки сообщения ICMP.

Примечание. Цель использования пакета с длинным заголовком заключается лишь в попытке включить поле Source Connection ID в часть пакета, возвращаемую в сообщении ICMP. Этот пакет не обязан быть действительным и его можно передавать даже в том случае, когда пакеты данного типа не используются.

15. Версии

Версия QUIC указывается 32-битовым целым числом без знака. Значение 0x00000000 зарезервировано для согласования версий, а текущая версия протокола имеет номер 0x00000001.

Другие версии QUIC могут отличаться свойствами. Набор свойств QUIC, гарантированных в любой версии, описан в [QUIC-INVARIANTS].

Версия 0x00000001 протокола QUIC применяет TLS в качестве протокола криптографического согласования, как указано в [QUIC-TLS].

Версии, где 16 старших битов имеют значение 0, зарезервированы для использования в согласованных IETF документах.

Версии, соответствующие шаблону 0x?a?a?a?a, зарезервированы для использования в принудительном согласовании версии, когда принимается любой номер версии, где 4 младших бита каждого байта имеют двоичное значение 1010. Клиент или сервер может анонсировать поддержку любой из этих зарезервированных версий.

Резервные номера версий не представляют реальный протокол. Клиент может использовать такую версию в ожидании того, что сервер инициирует согласование версии. Сервер может анонсировать поддержку одной из таких версий, ожидая, что клиент проигнорирует это значение.

16. Представление целочисленных полей переменного размера

В пакетах и кадрах QUIC широко применяется представление неотрицательных целых чисел с переменным размером. Такое представление обеспечивает меньший размер для небольших целых чисел.

QUIC резервирует 2 старших бита для представления размера числа двоичным логарифмом. Остальные биты служат для значения числа с использованием сетевого порядка байтов. Это означает представление целых чисел 1, 2, 4 или 8 байтами и значения этих чисел выражаются 6, 14, 30 или 62 байтами, соответственно (таблица 4).

Таблица 4. Сводка представления целых чисел.

2 старших бита

Число байтов

Число битов значения

Диапазон

00

1

6

0-63

01

2

14

0-16383

10

4

30

0-1073741823

11

8

62

0-4611686018427387903

Пример алгоритма декодирования и образцы кодирования приведены в Приложении A.1.

Значения не требуется кодировать с минимально возможным размером за исключением поля Frame Type (параграф 12.4).

Версии (раздел 15), номера пакетов в заголовках (раздел 17.1) и размер идентификатора соединения в длинном заголовке (параграф 17.2) задаются целыми числами, но не используют описанного здесь кодирования.

17. Формат пакетов

Все численные значения используют сетевой порядок байтов (big endian), размеры полей указываются в битах, значения полей указаны в шестнадцатеричном формате.

17.1. Кодирование и декодирование номера пакетов

Номера пакетов указываются числами от 0 до 262-1 (параграф 12.3). При указании в заголовке они имеют размер от 1 до 4 байтов. Число используемых битов уменьшается за счёт включения лишь младших битов порядкового номера. Номер пакета защищается, как указано в параграфе 5.4 [QUIC-TLS].

До получения подтверждения пространства порядковых номеров должен указываться полный номер пакета без отсечки, описанной ниже. После подтверждения пространства номеров отправитель должен использовать для номера размер, позволяющий указать диапазон в 2 раза больше разности между наибольшим подтверждённым номером и номером передаваемого пакета. Получающий пакет партнёр сможет корректно декодировать номер пакета, если тот не был задержан при передаче так, что до него было получено много пакетов с большими номерами. Конечной точке следует использовать достаточно длинное представление номера, чтобы его можно было восстановить даже по прибытии пакета позже отправленных после него других пакетов.

В результате при кодировании номера пакета применяется по меньшей мере на 1 бит больше двоичного логарифма числа непрерывных неподтвержденных пакетов, включая новый пакет. Псевдокод и примеры кодирования номеров пакетов представлены в Приложении A.2.

На стороне получателя защита порядкового номера снимается до восстановления полного номера. Затем восстанавливается полный номер на основе числа присутствующих значимых битов, их значений и наибольшего номера, полученного в успешно аутентифицированном пакете. Восстановление полного номера требуется для полного снятия защиты пакета. После снятия защиты заголовка номер пакета декодируется путём нахождения номера, ближайшего к следующему ожидаемому пакету, которым служит пакет с номером на 1 больше максимального номера принятого пакета. Псевдокод и примеры декодирования порядкового номера представлены в Приложении A.3.

17.2. Пакеты с длинным заголовком

     Long Header Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2),
     Type-Specific Bits (4),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Type-Specific Payload (..),
   }

Рисунок 13. Формат пакета с длинным заголовком.


Длинные заголовки применяются в пакетах, передаваемых до организации ключей 1-RTT. Когда ключи 1-RTT доступны, отправитель переходит к передаче пакетов с коротким заголовком (параграф 17.3). Длинная форма позволяет представить особые пакеты, такие как Version Negotiation, в едином формате с фиксированным размером. Поля пакетов с длинным заголовком перечислены ниже.

Header Form

Старший бит (0x80) байта 0 (первый байт) устанавливается в длинном заголовке.

Fixed Bit

Следующий бит (0x40) байта 0 устанавливается (1), если пакет не относится к Version Negotiation. Пакеты со сброшенным битом считаются в этой версии недействительными и должны отбрасываться. Установка этого бита позволяет QUIC сосуществовать с другими протоколами, см. [RFC7983].

Long Packet Type

Два следующих бита (маска 0x30) байта 0 указывают тип пакета (см. таблицу 5).

Type-Specific Bits

Семантика 4 младших битов (маска 0x0f) байта 0 определяется типом пакета.

Version

QUIC Version – 32-битовое поле, следующее за первым байтом, указывающее используемую версию QUIC и определяющее интерпретацию остальных полей протокола.

Destination Connection ID Length

Байт после номера версии указывает размер (в байтах) следующего за ним поля Destination Connection ID, представляемый 8-битовым целым числом без знака. В QUIC версии 1 этому значению недопустимо превосходить 20. Конечная точка версии 1, получившая заголовок со значением больше 20 в этом поле, должна отбросить пакет. Для корректного формирования пакета Version Negotiation серверам следует поддерживать возможность чтения более длинного идентификатора соединения из других версий QUIC.

Destination Connection ID

Поле Destination Connection ID следует за полем Destination Connection ID Length, указывающим его размер. Использование этого поля описано в параграфе 7.2.

Source Connection ID Length

Байт после поля Destination Connection ID указывает размер (в байтах) следующего за ним поля Source Connection ID, представленный 8-битовым целым числом без знака. В QUIC версии 1 этому значению недопустимо превосходить 20. Конечная точка версии 1, получившая заголовок со значением больше 20 в этом поле, должна отбросить пакет. Для корректного формирования пакета Version Negotiation серверам следует поддерживать возможность чтения более длинного идентификатора соединения из других версий QUIC.

Source Connection ID

Поле Source Connection ID следует за полем Source Connection ID Length, указывающим его размер. Использование этого поля описано в параграфе 7.2.

Type-Specific Payload

Оставшаяся часть пакета (при её наличии) зависит от типа пакета.

В этой версии QUIC определены показанные в таблице 5 типы пакетов с длинным заголовком.

Таблица 5. Типы пакетов с длинным заголовком.

Тип

Имя

Параграф

0x00

Initial

17.2.2. Начальный пакет

0x01

0-RTT

17.2.3. Пакет 0-RTT

0x02

Handshake

17.2.4. Пакет согласования

0x03

Retry

17.2.5. Пакет Retry

Бит формы заголовка, поля размера идентификаторов соединения и самих идентификаторов, а также поле Version в длинном заголовке не зависят от версии. Остальные поля первого байта зависят от версии протокола. В [QUIC-INVARIANTS] описана интерпретация пакетов разных версий QUIC. Интерпретация этих полей и данных (payload) определяется версией и типом пакета. Задаваемая типом семантика для данной версии описана в следующих параграфах, однако некоторые типы пакетов с длинным заголовком в этой версии QUIC содержат дополнительные поля.

Reserved Bits

Два бита (маска 0x0c) байта 0 зарезервированы для нескольких типов пакетов. Эти биты охватывается защитой заголовка (см. параграф 5.4 в [QUIC-TLS]). До установки защиты биты должны иметь значение 0. Конечная точка должна считать получение пакета с отличными от 0 значениями этих битов после снятия защиты пакета и заголовка ошибкой соединения типа PROTOCOL_VIOLATION. Отбрасывание такого пакета после снятия лишь защиты заголовка может раскрывать конечную точку для атаки (см. параграф 9.5 в [QUIC-TLS]).

Packet Number Length

В типах пакетов с полем Packet Number два младших бита (маска 0x03) байта 0 указывают размер поля Packet Number, представленный 2-битовым целым число без знака на 1 меньше фактического размера поля Packet Number в байтах. Т. е. размер поля Packet Number определяется добавлением 1 к значению этого поля. Эти биты охватывается защитой заголовка (см. параграф 5.4 в [QUIC-TLS]).

Length

Размер оставшейся части пакета (поля Packet Number и Payload) в байтах, представленный целым числом без знака с переменным размером (раздел 16).

Packet Number

Поле размером от 1 до 4 Байтов, охватываемое защитой заголовка (см. параграф 5.4 в [QUIC-TLS]). Размер поля Packet Number представлен в поле Packet Number Length байта 0, как описано выше.

Packet Payload

Данные (содержимое) пакета, представляющие собой последовательность кадров, охватываемую защитой пакета.

17.2.1. Пакет согласования версии

Пакет Version Negotiation по своей природе не зависит от версии. При получении клиентом пакет будет идентифицирован как Version Negotiation по полю Version = 0. Пакет согласования версии служит откликом на пакет клиент, запросивший у сервера не поддерживаемую тем версию. Пакет передаётся только серверами.

   Version Negotiation Packet {
     Header Form (1) = 1,
     Unused (7),
     Version (32) = 0,
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
     Supported Version (32) ...,
   }

Рисунок 14. Пакет согласования версии.


В поле Unused сервер устанавливает произвольное значение, а клиент должен игнорировать это поле. Если QUIC может мультиплексироваться с другими протоколами (см. [RFC7983]), серверу следует установить старший бит поля (0x40), чтобы в пакетах Version Negotiation было установлено поле Fixed Bit. Отметим, что в других версиях QUIC эта рекомендация может отсутствовать.

Поле Version в пакете Version Negotiation должно иметь значение 0x00000000.

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

В будущих версиях QUIC могут смениться требования к размеру идентификаторов соединения. В частности, для них может выбран меньший минимальный размер или больший максимальный. Зависящие от версии правилам для идентификаторов соединения недопустимо учитывать при принятии решения об отправке пакета Version Negotiation.

Оставшаяся часть пакета Version Negotiation содержит список 32-битовых номеров версий, поддерживаемых сервером.

Пакеты Version Negotiation не подтверждаются и передаются лишь в ответ на пакет, указывающий неподдерживаемую версию (см. параграф 5.)2.2.

Пакет Version Negotiation не включает полей Packet Number и Length, имеющихся в других пакетах с длинным заголовком, поэтому такой пакет занимает дейтаграмму UDP целиком. Серверу недопустимо передавать более 1 пакета Version Negotiation в ответ на одну дейтаграмму UDP. Процесс согласования версии описан в разделе 6.

17.2.2. Начальный пакет

Пакет Initial использует длинный заголовок со значением типа 0x00 и передаёт первые кадры CRYPTO от клиента и сервера для обмена ключами, а также кадры ACK в любом из направлений.

   Initial Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 0,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Token Length (i),
     Token (..),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

Рисунок 15. Пакет Initial.


Пакет Initial содержит длинный заголовок с полями Length и Packet Number (см. параграф 17.2). Первый байт содержит биты Reserved и Packet Number Length (см. параграф 17.2). Между полями Source Connection ID и Length размещаются два дополнительных поля, специфических для пакетов Initial.

Token Length

Целое число переменного размера, задающее размер поля Token в байтах. Значение 0 указывает отсутствие маркера. Пакеты Initial от сервера должны содержать Token Length = 0 и клиент, получающий пакет Initial с ненулевым значением Token Length должен отбросить пакет или установить ошибку соединения типа PROTOCOL_VIOLATION.

Token

Значение маркера, представленное ранее в пакете Retry или кадре NEW_TOKEN (см. параграф 8.1).

Чтобы предотвратить вмешательство промежуточных устройств, не знающих о версии, пакеты Initial защищаются с ключами, зависящими от соединения и версии (ключи Initial), как описано в [QUIC-TLS]. Эта защита не обеспечивает конфиденциальности и целостности при атаках с возможностью наблюдения пакетов, но препятствует злоумышленникам, не способным наблюдать пакеты, организовать атаку с фиктивными пакетами Initial.

Клиент и сервер могут применять пакеты типа Initial для любых пакетов, включающих сообщение начального криптографического согласования. Сюда входят все случаи, когда нужно создавать новые пакеты начального криптографического согласования, такие как пакеты, передаваемые после пакета Retry (см. параграф 17.2.5).

Сервер передаёт свой первый пакет Initial в ответ на клиентский пакет Initial и может передать несколько пакетов Initial. Для обмена криптографическими ключами может потребоваться несколько круговых обходов или повтор передачи.

Данные в пакете Initial включают кадр(ы) CRYPTO с сообщением криптографического согласования, кадры ACK или оба типа. Разрешены также кадры PING, PADDING, CONNECTION_CLOSE типа 0x1c. Конечная точка, получившая пакет Initial с кадрами иных типов, может отбросить пакет как ложный или считать его ошибкой соединения.

Первый пакет от клиента всегда включает кадр CRYPTO, содержащий начало или все сообщение криптографического согласования. Первый кадр CRYPTO всегда начинается со смещения 0 (см. раздел 7).

Отметим, что при передаче сервером TLS HelloRetryRequest (параграф 4.7 в [QUIC-TLS]) клиент будет передавать другую серию пакетов Initial, которые будут продолжать криптографическое согласования и включать кадры CRYPTO, начинающиеся со смещения, соответствующего размеру кадров CRYPTO в первой отправке пакетов Initial.

17.2.2.1. Прекращение использования пакетов Initial

Клиент прекращает отправку и обработку пакетов Initial при отправке своего первого пакета Handshake, сервер – при получении своего первого пакета Handshake. Хотя пакеты ещё могут оставаться в сети или ждать подтверждения, дополнительные пакеты Initial больше не нужны с этого момента. Ключи защиты пакетов Initial отбрасываются (см. параграф 4.9.1 в [QUIC-TLS]) вместе с состояниями восстановления потерь и контроля перегрузки (см. параграф 6.4 в [QUIC-RECOVERY]). Данные из кадров CRYPTO отбрасываются (и не передаются повторно) после отбрасывания ключей Initial.

17.2.3. Пакет 0-RTT

Пакет 0-RTT использует длинный заголовок типа 0x01, за которым следуют поля Length и Packet Number (см. параграф 17.2). Первый байт содержит поля Reserved и Packet Number Length (см. параграф 17.2). Пакеты 0-RTT используются для передачи «ранних» данных от клиента к серверу как части первой отправки до завершения согласования. В процессе согласования TLS сервер может воспринять или отвергнуть эти данные. Обсуждение данных 0-RTT и связанных с ними ограничений приведено в параграфе 2.3 [TLS13].

   0-RTT Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 1,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

Рисунок 16. Пакет 0-RTT.


Номера пакетов с защитой 0-RTT используют то же пространство, что и защищённые пакеты 1-RTT.

Получение клиентом пакета Retry говорит, что пакеты 0-RTT вероятно были потеряны или отброшены сервером. Клиенту следует попытаться повторно передать пакеты 0-RTT после отправки нового пакета Initial. Для новых пакетов должны использоваться новые номера, как указано в параграфе 17.2.5.3, поскольку повторное использование номеров может ставить защиту пакетов под угрозу.

Клиент получает подтверждения для его пакетов 0-RTT лишь по завершении согласования, как указано в параграфе 4.1.1 [QUIC-TLS].

Клиенту недопустимо передавать пакеты 0-RTT после начала обработки пакетов 1-RTT от сервера. Это значит, что пакеты 0-RTT не могут содержать отклики на кадры из пакетов 1-RTT. Например, клиент не может передать кадр ACK в пакете 0-RTT, поскольку этот кадр может подтверждать лишь пакет 1-RTT. Подтверждение для пакета 1-RTT должно передаваться в пакете 1-RTT.

Серверу следует считать нарушение запомненных ограничений (параграф 7.4.1) ошибкой соединения подходящего типа (например, FLOW_CONTROL_ERROR при нарушении ограничения для данных потока).

17.2.4. Пакет согласования

Пакеты Handshake используют длинный заголовок типа 0x02, за которым следуют поля Length и Packet Number (см. параграф 17.2). Первый байт содержит поля Reserved и Packet Number Length (см. параграф 17.2). Пакеты служат для передачи сообщений криптографического согласования и подтверждений от сервера и клиента.

   Handshake Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 2,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

Рисунок 17. Защищенный пакет Handshake.


После получения клиентом сообщения Handshake от сервера ин использует пакеты Handshake для отправки серверу последующих сообщений криптографического согласования и подтверждений.

Поле Destination Connection ID в пакете Handshake содержит идентификатор соединения выбранный получателем пакета, Source Connection ID – идентификатор соединения, который желает использовать отправитель (параграф 7.2).

Пакеты Handshake имеют своё пространство номеров, поэтому сервер передаёт первый пакет Handshake с номером 0.

Данные (payload) этого пакета включают кадры CRYPTO и могут включать PING, PADDING или ACK. Пакеты Handshake могут содержать кадры CONNECTION_CLOSE типа 0x1c. Конечная точка должна считать получения пакета Handshake с кадрами других типов ошибкой соединения PROTOCOL_VIOLATION.

Подобно пакетам Initial (см. параграф 17.2.2.1), данные в кадрах CRYPTO пакетов Handshake отбрасываются (и не передаются повторно), когда ключи защиты Handshake отбрасываются.

17.2.5. Пакет Retry

Как показано на рисунке 18, пакет Retry использует длинный заголовок с типом 0x03 и служит для передачи маркера проверки адреса, созданного отправителем. Пакет применяется сервером, желающим выполнить повтор (см. параграф 8.1).

   Retry Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 3,
     Unused (4),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Retry Token (..),
     Retry Integrity Tag (128),
   }

Рисунок 18. Пакет Retry.


Пакет Retry не содержит защищённых полей. В поле Unused помещается произвольное значение, выбранное сервером, клиент должен игнорировать эти биты. В дополнение к полям длинного заголовка пакет содержит указанные ниже поля.

Retry Token

Неанализируемый маркер, который сервер может использовать для проверки адреса клиента.

Retry Integrity Tag

Тег, определённый в параграфе 5.8 (Целостность пакета Retry) [QUIC-TLS].

17.2.5.1. Отправка пакета Retry

Сервер указывает в поле Destination Connection ID идентификатор соединения, включенный клиентом в поле Source Connection ID пакета Initial. В поле Source Connection ID сервер помещает выбранный им идентификатор соединения. В этом поле недопустимо указывать значение Destination Connection ID из переданного клиентом пакета. Клиент должен отбрасывать пакет Retry, в котором поле Source Connection ID совпадает с полем Destination Connection ID в пакете Initial от клиента. Клиент должен использовать значение Source Connection ID из пакета Retry в полях Destination Connection ID последующих пакетов, которые он передаёт.

Сервер может передавать пакеты Retry в ответ на Initial и 0-RTT. Сервер может отбрасывать или буферизовать полученные пакеты 0-RTT и может отправлять несколько пакетов Retry при получении Initial или 0-RTT. Серверу недопустимо передавать более одного пакета Retry в ответ на одну дейтаграмму UDP.

17.2.5.2. Обработка пакета Retry

Клиент должен воспринимать и обрабатывать не более одного пакета Retry для каждой попытки соединения. После приёма и обработки клиентом сообщения Initial или Retry от сервера клиент должен отбрасывать последующие пакеты Retry.

Клиенты должны отбрасывать пакеты Retry с полем Retry Integrity Tag, которое они не могут проверить (параграф 5.8 в [QUIC-TLS]). Это препятствует внедрению пакетов Retry злоумышленниками и защищает от случайно повреждённых пакетов Retry. Клиент должен отбрасывать пакеты с пустым (размер 0) полем Retry Token.

Клиент отвечает на Retry пакетом Initial с маркером из пакета Retry для продолжения организации соединения. Клиент помещает в поле Destination Connection ID пакета Initial значение поля Source Connection ID из пакета Retry. Смена поля Destination Connection ID ведёт к изменению ключей, применяемых для защиты пакета Initial. Клиенту недопустимо менять Source Connection ID, поскольку сервер может включать идентификатор соединения в логику проверки маркера (см. параграф 8.1.4).

Пакет Retry не включает номера и не может быть явно подтверждён клиентом.

17.2.5.3. Продолжение согласов