RFC 9119 Multicast Considerations over IEEE 802 Wireless Media

image_print
Internet Engineering Task Force (IETF)                        C. Perkins
Request for Comments: 9119                                   Lupin Lodge
Category: Informational                                       M. McBride
ISSN: 2070-1721                                                Futurewei
                                                              D. Stanley
                                                                     HPE
                                                               W. Kumari
                                                                  Google
                                                              JC. Zúñiga
                                                                  SIGFOX
                                                            October 2021

Multicast Considerations over IEEE 802 Wireless Media

Групповая передача в беспроводных средах IEEE 802

PDF

Аннотация

Хорошо известные проблемы с групповой адресацией (multicast) помешали развёртыванию группового взаимодействия в сетях 802.11 (Wi-Fi) и других беспроводных средах локального действия. В этом документе описаны известные ограничения группового обмена на канальном уровне (L2) в беспроводных сетях (в основном 802.11). Описаны также некоторые возможности улучшения, найденные IETF и IEEE 802 для беспроводных сред, а также некоторые варианты использования, способные повысить производительность сетей. Кроме того, приведены некоторые рекомендации по использованию и комбинированию этих улучшений, а также рассмотрены вопросы эксплуатации.

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

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

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

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

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

Авторские права (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).

Оглавление

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

1. Введение

Хорошо известные проблемы с групповой адресацией помешали развёртыванию группового взаимодействия в сетях 802.11 [dot11] и других локальных беспроводных средах, как описано в [mc-props] и [mc-prob-stmt]. Проблемы наблюдались при групповой адресации в протоколах IETF, использующих беспроводные среды IEEE 802. Хотя улучшения для групповой передачи были разработаны в IETF и IEEE 802, между спецификациями и реализациями, а также настройками сохраняется несовместимость.

Многие протоколы IETF зависят от широковещательной или групповой доставки управляющих сообщений множеству получателей. Групповая адресация позволяет передать данные множеству заинтересованных получателей без необходимости отправки копии каждому. При широковещательной передаче данные отправляются каждому устройству, независимо от его заинтересованности в них. Групповая передача применяется для таких целей, как обнаружение соседей (Neighbor Discovery или ND), лавинная рассылка по сети и распознавание адресов, а также для снижения нагрузки на сеть при передаче данных, предназначенных множеству адресатов. Помимо использования широковещательной и групповой передачи для пакетов управления, её применяют многие приложения, такие как Push To Talk3 в больницах, видеослужбы на предприятиях, университетах и в жилых домах, отправляя групповые пакеты IP устройствам конечных пользователей, которые все чаще применяют Wi-Fi.

Протоколы IETF обычно полагаются на многоуровневую структуру протоколов для снижения или исключения зависимости протоколов более высокого уровня от конкретной природы уровня MAC или физической среды. В случае групповой передачи протоколы верхних уровней обычно разрабатывались в предположении, что передача пакета по адресу IP равноценна в плане помех и доступа к сетевой среде, независимо от использования индивидуального, группового или широковещательного IP-адреса получателя. Эта модель подходит для сетей с передачей по кабелю, таким как Ethernet. К сожалению во многих беспроводных средах «стоимость» доступа к среде может существенно меняться. Групповая передача через сеть Wi-Fi часто имеет столь низкую производительность, что её просто не разрешают. Были разработаны некоторые усовершенствования для протоколов IETF, которые предполагалось использовать в основном в беспроводных средах. Однако эти улучшения обычно не получали широкого распространения в большинстве беспроводных сетей.

Беспроводные протоколы IEEE 802 были разработаны с некоторыми функциями для поддержки группового трафика. Например, для передачи групповых кадров применяется более низкая частота модуляции и они могут быть получены всеми станциями в ячейке, независимо от расстояния и затухания на пути от базовой станции или точки доступа (Access Point или AP). Однако такие передачи с более низкочастотной модуляцией дольше занимают среду, препятствуя эффективной передаче трафика с более высокочастотной модуляцией для расположенных близко станций. По этой и другим причинам рабочие группы IEEE 802, такие как 802.11, разработали средства повышения эффективности групповой передачи на уровне L2 [ietf_802-11]. Дополнительное улучшение работы при использовании групповой передачи может быть достигнуто с помощью некоторых эксплуатационных и конфигурационных решений (см. раздел 5).

Похоже, все уже согласились с тем, что эти проблемы не будут решены в ближайшее время в первую очередь из-за того, что это дорого и групповая передача не обеспечивает надёжности. По сравнению с индивидуальным трафиком Wi-Fi, групповой рассматривается как нечто второсортное, несмотря на наличие множества протоколов, использующих multicast-передачу. Нужны какие-то средства повышения надёжности групповой передачи. Протокол IPv6 ND, насыщающий каналы Wi-Fi является лишь частью проблемы. В решении могут помочь классы трафика Wi-Fi. Этот документ нацелен на прояснение вопроса о том, какие проблемы следует решать в IETF, а какие – в IEEE (раздел 8).

В этом документе подробно описаны проблемы, вызываемые групповой передачей в беспроводных сетях, включая высокую частоту потерь пакетов, отсутствие подтверждений и низкую скорость данных. Рассмотрены также некоторые усовершенствования, разработанные в IETF и IEEE 802.11 для улучшения влияния среды передачи на групповой трафик. Приведены рекомендации для разработчиков в части применения и комбинирования этих улучшений, а также некоторые советы по выбору режимов работы. Вполне возможно, что документ будет полезен также разработчикам будущих беспроводных спецификаций IEEE.

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

ACK

Подтверждение канального уровня 802.11 L2.

AES-CCMP

Протокол AES-Counter Mode CBC-MAC.

AP

Точка доступа IEEE 802.11.

Basic rate – базовая скорость

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

DVB-H

Digital Video Broadcasting – Handheld – переносное устройство для цифрового приёма видео.

DVB-IPDC

Digital Video Broadcasting – Internet Protocol Datacasting – передача данных IP через цифровое вещание видео.

DTIM

Delivery Traffic Indication Map (карта индикации доставки трафика) – информационный элемент, сообщающий о наличии или отсутствии у ассоциированных станций буферизованных групповых или широковещательных кадров.

MCS

Modulation and Coding Scheme – схема модуляции и кодирования.

NOC

Network Operations Center – сетевой операционный центр.

PER

Packet Error Rate – частота ошибок в пакетах.

STA

Станция 802.11 (например, переносное устройство).

TIM

Traffic Indication Map (карта индикации трафика) – информационный элемент, сообщающий о наличии или отсутствии у ассоциированных станций буферизованных индивидуальных кадров.

TKIP

Temporal Key Integrity Protocol – протокол защиты целостности временных ключей.

WiMAX

Worldwide Interoperability for Microwave Access

WPA

Wi-Fi Protected Access – защищённый доступ к Wi-Fi.

3. Известные проблемы групповой передачи

3.1. Проблемы на уровне L2 и ниже

В этом параграфе описаны некоторые проблемы, связанные с использованием групповой передачи в беспроводных сетях IEEE 802.

3.1.1. Ненадёжность групповой передачи

Надёжность группового трафика обычно значительно ниже, чем индивидуального. Поскольку для групповой передачи применяется режим «один со многими», для подтверждения доставки требуется передача множества пакетов. Однако для групповой передачи подтверждения (ACK) не применяются и точка доступа (AP) не знает, требуется ли повторная отправка. Даже в кабельной части Internet с этим зачастую связан нежелательно высокий уровень ошибок. В результате групповые приложения внедряются сравнительно медленно, хотя протоколы для них давно доступны. В беспроводных сетях ситуация значительно хуже и очень чувствительна к наличию фонового трафика. В результате может наблюдаться очень высокая частота пакетных ошибок (packet error rate или PER) из-за отсутствия повторов передачи и снижения скорости отправки. PER представляет собой долю (в процентах) пакетов, которые не были получены устройством. Нередко этот уровень превышает 5%, что особенно неприятно для видео и других данных, где нужна высокая скорость и надёжность.

3.1.2. Низкая и переменная скорость передачи данных

Групповая передача по кабелям отличается от беспроводной, поскольку кабельные каналы обычно работают на фиксированной скорости. Скорость передачи в Wi-Fi зависит от близости STA к AP. Полоса видеопотоков и пропускная способность в большой сети Wi-Fi будет меняться при перемещении устройства. Это влияет на возможности решений QoS эффективно резервировать пропускную способность и обеспечивать контроль подачи данных в сеть.

Для аутентифицированных и подключённых к AP беспроводных станций мощность, требуемая для хорошего приёма может существенно меняться от станции к станции. Для индивидуальной передачи целью является минимальное энергопотребление при максимальной скорости доставки данных получателю. Для групповой передачи цель заключается в достижении максимального числа получателей, которые могут корректно принять групповые пакеты. Обычно AP должна использовать существенно меньшую скорость передачи при высоком потреблении энергии, чтобы даже самая удалённая станция получила пакет, например, как кратко описано в разделе 4 [RFC5757]. Поэтому скорость передачи, например, видеопотока может быть ограничена окружением менее надёжного получателя, подключённого к AP.

Поскольку более отказоустойчивые схемы модуляции и кодирования (modulation and coding scheme или MCS) обеспечивают большую дальность, но меньшую скорость, широковещательный и групповой трафик обычно передаётся с наименьшей среди всех подключённых устройств скоростью. Эту скорость называют базовой. Уровень дополнительных помех зависит от конкретной беспроводной технологии. Фактически, совместимость с более старыми устройствами и многопоточные реализации позволяют передавать индивидуальный трафик со скоростью несколько Гбит/с, а разница скорости передачи группового или широковещательного трафика и оптимальной скорости индивидуального трафика может превышать 3 порядка. Некоторые методы повышения спектральной эффективности, такие как пространственное мультиплексирование в системах с несколькими входами и выходами (Multiple Input Multiple Output или MIMO) недоступны для нескольких получателей. Совместимость со старыми версиями не является единственным фактором ограничения скорости групповой передачи.

Проводная групповая передача также влияет на беспроводные LAN, когда AP служит расширением кабельного сегмента. В этом случае групповые и широковещательные кадры на проводной стороне ЛВС копируются в беспроводную сеть (Wireless Local Area Network или WLAN). Поскольку широковещательные сообщения передаются с более отказоустойчивыми схемами MCS, многие большие кадры отправляются с малой скоростью через беспроводный канал.

3.1.3. Пропускная способность и влияние на помехи

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

3.1.4. Влияние энергосбережения на групповой трафик

Одной из характеристик групповой передачи в Wi-Fi является настройка каждой станции на пробуждение по приёму группового кадра, даже если тот будет в итоге отброшен. Это оказывает сильное влияние на потребляемую станцией энергию. По этой причине были найдены некоторые обходные пути, такие как направленная групповая передача (Directed Multicast Service или DMS), описанная в разделе 4, чтобы избежать пробуждения станций.

Групповая и индивидуальная передача может плохо работать с механизмами энергосбережения IEEE 802.11e в силу перечисленных ниже причин.

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

  • Индивидуальный пакет задерживается, пока STA не проснётся и не запросит его. Задержка индивидуального трафика может также служить для экономии энергии, а также повышения эффективности и вероятности агрегирования.

  • Групповой трафик задерживается в беспроводной сети, если любая из STA в сети применяет энергосбережение. Все STA, связанные с AP, должны быть активны для получения группового трафика.

  • Пакеты могут отбрасываться из-за ограничений буферов в AP и STA без AP.

3.2. Проблемы на уровне L3 и выше

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

  • сигнализация плоскости управления;

  • обнаружение соседей;

  • распознавание адресов;

  • обнаружение служб;

  • приложения (доставка видео, данных складов и т. п.);

  • маршрутизация по запросу;

  • создание магистрали;

  • другие протоколы L3 (не IP).

Протокол пользовательских дейтаграмм (User Datagram Protocol или UDP наиболее распространён для доставки группового трафика. Сам по себе, протокол UDP не обеспечивает гарантий и сообщения могут теряться или менять порядок доставки.

3.2.1. Проблемы IPv4

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

  • ARP [RFC0826].

  • DHCP [RFC2131].

  • Multicast DNS (mDNS) [RFC6762].

  • Universal Plug and Play (uPnP) [RFC6970].

После начальной настройки ARP (см. ниже), DHCP и uPnP применяются достаточно редко, но обнаружение служб может происходить в любой момент. Некоторые широко распространённые протоколы обнаружения служб (например, для поиска принтеров) используют механизм mDNS (групповой), который операторы часто блокируют. Даже при отслеживании групповой передачи [RFC4541] (которое обеспечивает сохранение пропускной способности сегментов сети, где ни один узел не заявил интереса в получении пакетов по этому групповому адресу) одновременно может регистрироваться много устройств, существенно снижая производительность сети.

3.2.2. Проблемы IPv6

В IPv6 групповая передача применяется более широко, включая протоколы:

  • DHCPv6 [RFC8415];

  • Protocol Independent Multicast (PIM) [RFC7761];

  • IPv6 Neighbor Discovery Protocol (NDP) [RFC4861];

  • Multicast DNS (mDNS) [RFC6762];

  • Router Discovery [RFC4286].

Сообщения IPv6 NDP Neighbor Solicitation (NS) при обнаружении дубликатов адресов (Duplicate Address Detection или DAD) и поиске адресов могут использовать групповую адресацию с областью действия на локальном канале (link-scope). В отличие от IPv4, узел IPv6 обычно использует несколько адресов и может часто менять их по соображениям приватности. Влияние групповых сообщений возрастает при мобильности устройств. Анонсы маршрутизаторов (Router advertisement или RA) также периодически передаются по групповым адресам.

Сосед может считаться потерянным при отказе нескольких пакетов Neighbor Discovery подряд.

3.2.3. Проблемы MLD

Обнаружение слушателей группового трафика (Multicast Listener Discovery или MLD) [RFC4541] применяется для обнаружения членов multicast-группы, подключённых к портам коммутатора. Пересылка групповых кадров в область с поддержкой Wi-Fi может использовать поддержку коммутатором сведений о пересылке на аппаратном уровне. По причине интенсивного применения групповой передачи в IPv6 для каждой станции STA с адресом IPv6 потребуется хранить в коммутаторе состояние для нескольких (возможно многих) групповых адресов solicited-node. Это групповые адреса IPv6Ю используемые протоколом NDP для проверки занятости адресов IPv6 на локальном канале. Групповые адреса, для которых не установлено состояние пересылки (возможно по причине недостатка памяти в коммутаторе), будут вызывать лавинную рассылку во все порты коммутатора. Некоторые производители коммутаторов не поддерживают MLD для групповой передачи link-scope, по причине требований к поддержке состояний.

3.2.4. Ложное обнаружение соседей

В Internet существует фоновое сканирование трафика (люди, занимающиеся поиском уязвимых машин) и «обратное рассеяние» (отклики на обманный трафик и т. п.). Это означает, что маршрутизаторы очень часто передают пакеты по адресам IPv4, которые могут не использоваться. При назначении IP-адреса хосту маршрутизатор передаёт широковещательный запрос ARP, получает отклик ARP и кэширует его, а затем трафик может быть доставлен хосту. Когда IP-адрес не используется, маршрутизатор передаёт 1 или несколько широковещательных запросов ARP и не получает на них отклика. Это означает, что запись в кэш ARP не вносится и следующий пакет по этому адресу IP приведёт к новой широковещательной передаче запросов ARP.

Частота этих запросов ARP пропорциональна размеру подсетей, темпам сканирования и обратного рассеяния, а также времени хранения маршрутизатором состояний для отсутствия ответов ARP. Оказывается, что эта частота обратно пропорциональная заполненности подсети (действительные ARP сохраняются в кэше без широковещательных повторов, а неиспользуемые адреса IP не отвечают на запросы, что увеличивает широковещательный трафик). В зависимости от используемого пространства адресов, времени суток, заполненности сети и других (неизвестных) факторов могут наблюдаться тысячи широковещательных пакетов в секунду. Наблюдалось около 2000 широковещательных пакетов в секунду в сети IETF NOC во время конференций.

С помощью протокола Neighbor Discovery для IPv6 [RFC4861] узлы распознают адреса путём групповой передачи сообщений Neighbor Solicitation, запрашивающих у узлов адрес канального уровня. Сообщения Neighbor Solicitation передаются по групповому адресу solicited-node. Целевой узел возвращает адрес канального уровня в индивидуальном сообщении Neighbor Advertisement. Одной пары пакетов с запросом и откликом достаточно для инициатора и цели, чтобы узнать адреса канального уровня друг друга (инициатор включает его в Neighbor Solicitation).

В кабельных сетях нет большой разницы между индивидуальным, групповым и широковещательным трафиком. В результате аппаратной фильтрации (см., например, [Deri-2010]) непреднамеренный лавинный трафик (или избыточные групповые кадры Ethernet) в кабельной сети может быть значительно «дешевле» по сравнению с беспроводными сетями, где спящие устройства пробуждаются для обработки пакетов. Кабельные сети Ethernet как правило являются коммутируемыми, что дополнительно снижает помехи от группового трафика. Фактически не возникает проблем с коллизиями и планированием за исключением случаев чрезвычайно высокой загрузки порта. В беспроводных сетях это не так и оборудование зачастую неспособно передавать большие объёмы широковещательного и группового трафика, что ведёт к отбрасыванию значительной части таких пакетов. Поэтому при подключении хоста он зачастую не может завершить процедуру DHCP и пакеты IPv6 RA отбрасываются, что препятствует доступу пользователя в сеть.

4. Оптимизация группового протокола

В этом разделе описаны некоторые пути оптимизации, предложенные в IEEE 802 и IETF для смягчения или исключения проблем, отмеченных в разделе 3.

4.1. Proxy ARP в 802.11-2012

AP знает адреса L2 (Medium Access Control или MAC) и IP всех связанных с ней STA. Таким образом, AP выступает центральным «менеджером» для всех 802.11 STA в наборе базовых служб (Basic Service Set или BSS). Proxy ARP легко реализовать на AP, обеспечив указанные ниже преимущества.

  • Снижение широковещательного трафика (передаётся с низкими MCS) в беспроводной среде.

  • STA может более эффективно использовать спящий режим, поскольку запросы ARP для её адреса IP обрабатывает AP.

  • Кадры ARP не попадают в беспроводную среду.

  • Не требуется менять реализации STA.

Ниже приведён фрагмент спецификации из параграфа 10.23.13 [dot11-proxyarp].

Когда AP поддерживает Proxy ARP «[…] AP нужно поддерживать сопоставление аппаратных адресов с адресами Internet для каждой связанной станции и обновлять сопоставление при смене станцией адреса Internet. При преобразовании адреса IPv4 с помощью запроса ARP от станции STA без AP, связанной с BSS, службе Proxy ARP нужно отвечать от имени STA на запрос ARP или пакет ARP Probe.

4.2. Регистрация адресов IPv6 и Proxy ND

В этом параграфе персональной беспроводной со слабым питанием (Low-Power Wireless Personal Area Network или 6LoWPAN) считается сеть со слабым питанием и потерями (Low-Power and Lossy Network или LLN), поддерживающая сжатие заголовков 6LoWPAN (Header Compression или HC) [RFC6282]. Примером 6LoWPAN является сеть 6TiSCH [RFC9030]. Для контроля использования групповой передачи IPv6 через сети 6LoWPAN разработан стандарт 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775], определяющий механизм регистрации адресов на основе центрального реестра, контролирующего уникальность адресов вместо неэффективного механизма DAD применяемого протоколом обнаружения соседей IPv6 (Neighbor Discovery Protocol или NDP) [RFC4861] [RFC4862].

Рабочая группа 6lo подготовила обновление [RFC6775]. Беспроводное устройство может регистрировать свой адрес на магистральном маршрутизаторе (Backbone Router) [RFC8929], который служит посредником к IPv6 NDP, работающему высокоскоростной магистрали агрегирования. Обновление также включает механизм прокси-регистрации от имени зарегистрированного узла, например, через маршрутизатор 6LoWPAN, к которому подключён мобильный узел.

Общая идея концепции магистрального маршрутизатора заключается в том, что широковещательные и групповые сообщения следует строго контролировать в разных WLAN и персональных беспроводных сетях (Wireless Personal Area Network или WPAN). Связность с конкретным каналом, обеспечивающим подсеть, следует сохранить на уровне L3. Модель работы Backbone Router показана на рисунке 1.

          |
        +-----+
        |     | Принятый по умолчанию маршрутизатор
        |     |
        +-----+
           |
           |      Магистральный канал
     +--------------------+------------------+
     |                    |                  |
  +-----+             +-----+             +-----+
  |     |Магистральный|     |Магистральный|     |Магистральный
  |     |маршрутиз. 1 |     |маршрутиз. 2 |     |маршрутиз. 3
  +-----+             +-----+             +-----+
     o                o   o  o              o o
 o o   o  o       o o   o  o  o         o  o  o  o o
o  o o  o o       o   o  o  o  o        o  o  o o o
o   o  o  o          o    o  o           o  o   o
  o   o o               o  o                 o o

    LLN 1              LLN 2                LLN 3

Рисунок 1. Магистральный канал и магистральные маршрутизаторы.

Узлы LLN могут свободно перемещаться из сети LLN, привязанной к одному магистральному маршрутизатору IPv6 BR, в сеть, привязанную к другому BR на той же магистрали, сохраняя все настроенные адреса IPv6. Маршрутизаторы BR поддерживают таблицу привязки (Binding Table) своих зарегистрированных адресов, которая служит распределенной базой данных обо всех узлах LLN. Расширение протокола NDP введено для обмена данными таблиц привязки через магистральный канал (Backbone Link) для обеспечения работы IPv6 Neighbor Discovery.

В [RFC6775] и последующем документе [RFC8505] рассматриваются потребности LLN и похожих методов, которые вероятно будут полезны для каналов любого типа, где подключены спящие устройства или следует ограничить широковещательный и групповой трафик.

4.3. Буферизация для увеличения срока службы батареи

Разработаны методы, позволяющие продлить срок службы батареи. Например, устройство может не просыпаться при получении точкой доступа (AP) группового пакета. AP действует от имени STA разными способами. Для включения функций экономии энергии в STA в своём наборе BSS точка доступа AP буферизует предназначенные STA кадры до времени, когда STA планирует приём. Если AP, например, выражает сообщение индикации доставки трафика (Delivery Traffic Indication Message или DTIM) 3, AP будет передавать групповой пакет через каждые 3 пакета. Фактически, когда любая отдельная беспроводная станция STA, связанная с AP, имеет включенный режим энергосбережения 802.11, AP буферизует все групповые кадры и передаёт их лишь после следующего сигнала DTIM.

На практике большинство AP будет передавать групповые пакеты каждые 30 секунд. Для индивидуальных пакетов AP может передавать сообщение индикации трафика (Traffic Indication Message или TIM), но для группового трафика AP передаёт широковещательное сообщение всем. DTIM управляет питанием, но STA могут сами решить, нужно ли просыпаться и когда отбрасывать пакет. К сожалению без должной административной настройки такие STA могут быть не способны определить, почему их групповые операции не работают.

4.4. Ограничение глубины аппаратной очереди группового буфера

Очередь CAB (Content after Beacon) служит для передачи буферизованных групповых кадров по сигналу. Если буферизовано много групповых кадров и очередь заполнена, она «заглушает» весь обычный трафик. Для ограничения ущерба, который может нанести буферизованный трафик, некоторые драйверы ограничивают объем групповых данных в очереди до доли beacon_interval. Пример этого приведён в [CAB].

4.5. Поддержка IPv6 в 802.11-2012

IPv6 использует NDP вместо ARP. Каждый узел IPv6 подписан для этого на специальный групповой адрес. Ниже приведён фрагмент текста из параграфа 10.23.13 в [dot11-proxyarp].

При распознавании адреса IPv6 службе Proxy Neighbor Discovery нужно отвечать сообщением Neighbor Advertisement […] от имени связанной станции STA на сообщение [ICMPv6] Neighbor Solicitation […]. При смене сопоставления с MAC-адресом AP может передавать незапрошенные сообщения Neighbor Advertisement от имени STA.

Протокол NDP можно использовать для запроса дополнительных данных с использованием разных методов, включая:

  • Maximum Transmission Unit;

  • Router Solicitation;

  • Router Advertisement.

Сообщения NDP передаются как групповые (широковещательные) кадры 802.11. Использование прокси помогает сохранять сообщения NDP вне беспроводной среды.

4.6. Использование индивидуальной передачи вместо групповой

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

4.6.1. Обзор

Во многих случаях через канал Wi-Fi лучше передавать индивидуальные пакеты вместо групповых. Это избавляет от большинства проблем, связанных с групповой передачей через Wi-Fi, поскольку индивидуальные кадры подтверждаются и буферизуются для клиентов с энергосбережением. При таком подходе иногда приходится один и тот же пакет передавать несколько раз через канал Wi-Fi. Однако во многих случаях, таких как передача видео в домашней сети, это обеспечивает хороший компромисс, поскольку канал Wi-Fi имеет достаточную ёмкость для индивидуального трафика для каждой подписавшейся STA, даже если на восходящем канале в сеть доступа применяется multicast.

Имеется несколько технологий, которые можно применять для индивидуальной передачи через Wi-Fi.

4.6.2. Преобразование на уровне L2

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

Хотя пока нет стандартизованного метода преобразования, имеется по меньшей мере одна широко распространённая реализация в коде моста Linux [bridge-mc-2-uc]. Разные производители также имеют свои фирменные решения. В общем случае эти реализации выполняют прямое сопоставление для групп и каналов, обнаруженный при отслеживании IGMP и MLD, в соответствующие индивидуальные адреса MAC.

4.6.3. Направленная групповая передача DMS

DMS (Directed Multicast Service) позволяет STA запросить у AP передачу адресованных в группу кадров, предназначенных для запрашивающих STA в виде кадров с индивидуальным адресом (преобразовать в unicast). Ниже указаны некоторые характеристики DMS.

  • Требуются блоки агрегирования данных сервиса 802.11n MAC (Aggregate MAC Service Data Unit или A-MSDU).

  • Кадры с индивидуальными адресами подтверждаются и буферизуются для энергосберегающих STA.

  • Запрашивающая STA может указать характеристики для трафика DMS.

  • Служба DMS определена в IEEE Std 802.11v-2011 [v2011].

  • DMS требует изменений в реализациях AP и STA.

Служба DMS в настоящее время ещё не реализована в продукции. Дополнительная информация доступна в [Tramarin2017] и [Oliva2013].

4.6.4. Автоматическое туннелирование AMT

AMT (Automatic Multicast Tunneling) [RFC7450] обеспечивает возможность туннелирования групповых пакетов IP в индивидуальных пакетах через сеть, поддерживающую лишь unicast-передачу. Когда операционная система или приложение на станции STA имеет встроенный шлюз AMT, она может использовать индивидуальную адресацию для передачи по каналу Wi-Fi, развернув ретранслятор AMT в не относящейся к Wi-Fi части сети, соединённой с AP.

Рекомендуется в сетях с поддержкой групповой передачи, где развёрнуты ретрансляторы AMT, обеспечивать локальное обнаружение этих ретрансляторов с использованием описанных в [RFC8777] методов:

  • обнаружение служб на основе DNS (DNS-SD) [RFC6763];

  • общеизвестные адреса IP из раздела 7 в [RFC7450].

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

4.7. GroupCast с повторами (GCR)

Механизм GCR (GroupCast with Retries, [dot11aa]) повышает надёжность за счёт использования незапрошенных повторов или механизма подтверждения блока. GCR повышает вероятность получения групповых кадров, но все же не обеспечивает гарантии.

Для механизма подтверждения блоков AP использует для каждого адресованного в группу кадра обычную групповую передачу. Повторные передачи адресуются в группу, но скрыты от STA, не поддерживающих 802.11aa. Применяется схема направленного подтверждения блоков для сбора статуса приёма от получателей и на основе этого выполняется повтор передачи.

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

GCR может вносить неприемлемую задержку. После отправки группы кадров данных AP выполняет ряд действий:

  • индивидуальная передача запроса подтверждения блока (Block Ack Request или BAR) части группы;

  • ожидание соответствующего подтверждения блока (Block Ack или BA);

  • повтор пропущенных кадров;

  • восстановление других операций, которые могли быть задержаны.

Такая задержка может быть неприемлема для некоторых типов трафика.

В 802.11 разрабатываются расширения для повышения производительности GCR:

  • запросы BAR передаются с использованием нисходящего многопользовательского MIMO (MU-MIMO);

  • отклики BA передаются с использованием восходящего MU-MIMO (свойство IEEE 801.11ax-2021);

  • задержка может быть дополнительно снижена одновременным получением данных BA от нескольких STA.

5. Эксплуатационная оптимизация

В этом разделе описаны некоторые варианты эксплуатационной оптимизации, которые могут быть реализованы при развёртывании беспроводных сетей IEEE 802 для смягчения проблем, описанных в разделе 3.

5.1. Устранение проблем ложного обнаружения соседей

ARP Sponge

ARP Sponge размещаются в сети и узнают реально применяемые адреса IP. Они также прослушивают запросы ARP и, видя ARP для адреса IP, который по их мнению не используется, будут передавать в ответ свой MAC-адрес. Это значит, что маршрутизатор будет иметь сопоставление IP-MAC, которое он кэширует. Если позднее этот адрес IP будет выделен машине (например, через DHCP), ARP Sponge увидит это и прекратит отвечать для него. Беспричинные (Gratuitous) ARP (или ARP от машин к их шлюзам) будут заменять подменный адрес (sponged) в ARP-таблице маршрутизатора. Этот метод достаточно эффективен, но к сожалению демоны ARP Sponge не были предназначены для такого применения – один из наиболее распространённых ARP Sponge [arpsponge] был разработан для борьбы с исчезновением участников обмена в IXP (Internet Exchange Point) и тоже не оптимизирован для такой задачи. Для каждой подсети нужен один демон, настройка сложна (скорость сканирования, плотность заполнения, число повторов и т. п.), а иногда демон просто останавливается, что требует перезапуска, вызывающего нарушения работы.

Маршрутизаторы

Некоторые маршрутизаторы (часто на основе Linux) реализуют демон негативного кэширования ARP. Если маршрутизатор не видит откликов на ARP, можно задать сохранение этой информации в течение некоторого времени. К сожалению, часто используемые в ядре маршрутизаторы не поддерживают этого. Вместо этого при получении адреса IP подключившимся к сети хостом он передаёт запрос ARP для принятого по умолчанию шлюза (маршрутизатора). Маршрутизатор обновляет свой кэш, включая в него сопоставление IP с MAC-адресом хоста из запроса (пассивное обучение ARP).

Фильтрация неиспользуемых адресов

Распределение пользователей в беспроводных (под)сетях может меняться в различных вариантах применения, таких как конференции (например, переименовываются SSID (Service Set Identifier), некоторые SSID становятся непопулярными и т. п.). Это осложняет прогнозирование использования конкретных SSID, но его можно отслеживать по мере использования сетей. Настройка нескольких пулов DHCP в подсети и их последующее включение позволяет создавать большую подсеть, в которой используются лишь младшие части адресов. Это позволяет применять входные списки доступа по IP, блокирующие старшие адреса, которые не используются. Маршрутизатор не пытается пересылать пакеты в старшие части пространств адресов и не использует для них ARP. Этот метод показал свою эффективность, но он достаточно трудоёмкий и требует координации.

Запрет и фильтрация запросов ARP

В общем случае маршрутизатору не нужны запросы ARP для хостов, он может получить сопоставление IP-MAC из переданного хостом при подключении запроса ARP. Поэтому следует обеспечивать возможность запрета и/или фильтрации запросов ARP от маршрутизатора. К сожалению ARP является фундаментальной и низкоуровневой частью стека IP и зачастую выгружается из обычной плоскости управления. Хотя многие маршрутизаторы могут фильтровать трафик на уровне L2, обычно это реализовано в форме входного фильтра, а возможности выходной фильтрации широковещательного трафика ограничены. Это означает, что кажущееся очевидным решение просто отключить или фильтровать ARP на выходе на практике сложно выполнить или оно ограничено реализацией или архитектурой.

Трансляция NAT

Широковещательная передача часто может вызываться сканированием или обратным рассеянием извне Wi-Fi. Для снижения влияния широковещания можно применять трансляцию NAT для всей (или большей части) сети. Для неиспользуемых адресов в NAT не будет записей и маршрутизатор не будет применять ARP для них. Однако имеется много причин отказываться от применения NAT в таком режиме.

Межсетевые экраны с учётом состояния

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

5.2. Устранение ложных сообщений обнаружения служб

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

6. Групповая передача в других беспроводных средах

Многие из описанных выше случаев потери производительности наблюдались и в беспроводных сетях, отличных от 802.11. Например, проблемы с энергосбережением, избыточной загрузкой среды и малой надёжностью проявляются также в сетях 802.15.3 и 802.15.4. К сожалению спецификация среды 802.15 пока не включает механизмов, подобных разработанным для 802.11. Фактически проектирование 802.15 нацелено на минимизацию и многие функции реализуются в протоколах вышележащих уровней. Это ведёт к мешанине несовместимых и фирменных решений. В [uli] подробно рассматриваются проблемы и представлены предложения для группы задач, решающие проблемы, где объем групповых передач можно снизить.

Похожие соображения применимы и к другим беспроводным средам. В работе [RFC5757] приведено краткое рассмотрение для сред 802.16 WiMAX, 3GPP/3GPP2, DVB-H/DVB-IPDC, а также широковещательного и спутникового телевидения.

7. Рекомендации

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

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

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

8. Вопросы для обсуждения

В этом разделе предложены два вопроса для обсуждения в целях дальнейшего развития.

Во-первых, органам стандартизации (включая частные) следует создавать рекомендации, помогающие прояснить, когда лучше передавать групповые пакеты через кабельную, а не беспроводную сеть. Например, 802.1ak [IEEE802.1ak] работает с Ethernet и Wi-Fi, поэтому организации могут помочь в принятии решений о развёртывании, разработав рекомендации для групповой передачи через Wi-Fi, включая варианты передачи трафика по кабелям.

Во-вторых, надёжная регистрация в multicast-группах L2 и надёжные групповые операции L2 могут обеспечить хорошее решение для Wi-Fi. Не следует требовать поддержки 224 для групповой работы, достаточно просто выбрать число битов, имеющих смысл для данного размера сети, чтобы ограничить число нежелательных передач разумным уровнем. Рабочие группы IEEE 802.1, 802.11, 802.15 следует поощрять к пересмотру групповой передачи L2 и разработке работоспособных решений.

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

Этот документ не добавляет и не меняет механизмов защиты. Групповую передачу в кабельных и беспроводных сетях, рассматриваемую здесь, можно защитить разными способами. Например, в [RFC4601], описано применение IPsec для проверки подлинности сообщений на локальном канале (link-local) при независимой от протокола групповой маршрутизации (Protocol Independent Multicast – Sparse Mode или PIM-SM). В [RFC5796] заданы механизмы проверки подлинности локальных сообщений PIM-SM link-local с использованием IPsec ESP (Encapsulating Security Payload) или AH (Authentication Header).

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

Как отмечено в [group_key], ненадёжная по природе групповая передача через беспроводную среду может вызывать небольшие проблемы для управления и обновления групповых ключей. В [group_key] сказано, что при использовании шифрования TKIP (WPA сейчас не рекомендуется) или AES-CCMP (WPA2/WPA3) групповые пакеты от AP к клиентам (FromDS) должны шифроваться с использованием отдельного ключа, известного всем клиентам (Group Key). Далее там же сказано «… большинство клиентов могут подключаться и просматривать web0страницы, проверять почту и т. п., даже когда групповая передача FromDS не работает. Поэтому многие не осознают наличие проблем с групповой передачей в их сети …».

Этот документ рекомендует применять прокси-методы для экономии пропускной способности сети и снижения расхода батарей в устройствах с энергосбережением. С такими методами обычно связаны вопросы безопасности, требующие иметь доверенные прокси во избежание недопустимого поведения. Одним из таких методов является ARP Sponge, где прослушиваются запросы ARP и при наблюдении ARP для адреса IP, который считается неиспользуемым, прокси возвращает свой MAC-адрес. Отравление ARP (poisoning) и фальшивые анонсы могут нарушить (например, DoS) работу этого и других прокси-методов.

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

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

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

[arpsponge] Wessel, M. and N. Sijm, “Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge”, July 2009, <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692>.

[bridge-mc-2-uc] “bridge: multicast to unicast”, commit 6db6f0e, January 2017, <https://github.com/torvalds/linux/commit/6db6f0e>.

[CAB] “limit multicast buffer hardware queue depth”, commit 2687951, June 2013, <https://patchwork.kernel.org/patch/2687951/>.

[Deri-2010] Deri, L. and J. Gasparakis, “10 Gbit Hardware Packet Filtering Using Commodity Network Adapters”, RIPE 61, November 2010, <http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf>.

[dot11] IEEE, “Information Technology–Telecommunications and Information Exchange between Systems – Local and Metropolitan Area Networks–Specific Requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (includes 802.11v amendment)”, DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020, December 2020, <https://standards.ieee.org/standard/802_11-2020.html>.

[dot11-proxyarp] Hiertz, G., Mestanov, F., and B. Hart, “Proxy ARP in 802.11ax”, September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.

[dot11aa] IEEE, “Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming”, DOI 10.1109/IEEESTD.2012.6204193, IEEE Std 802.11aa-2012, March 2012, <https://standards.ieee.org/standard/802_11aa-2012.html>.

[group_key] “Subject: Why do some WiFi routers block multicast packets going from wired to wireless?”, message to the Super User Q & A community, January 2017, <https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless>.

[IEEE802.1ak] IEEE, “Local and Metropolitan Area Networks Virtual Bridged Local Area Networks – Amendment 07: Multiple Registration Protocol”, DOI 10.1109/IEEESTD.2007.380667, IEEE Std 802.1ak-2007, June 2007, <https://www.ieee802.org/1/pages/802.1ak.html>.

[ietf_802-11] Stanley, D., “IEEE 802.11 multicast capabilities”, November 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt>.

[mc-prob-stmt] Abrahamsson, M. and A. Stephens, “Multicast on 802.11”, 2013, <https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx>.

[mc-props] Stephens, A., “IEEE 802.11 multicast properties”, September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt>.

[Oliva2013] de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, “Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming”, 2013 IEEE 14th International Symposium on “A World of Wireless, Mobile and Multimedia Networks” (WoWMoM), pp. 1-9, DOI 10.1109/WoWMoM.2013.6583394, June 2013, <https://doi.org/10.1109/WoWMoM.2013.6583394>.

[RFC0826] Plummer, D., “An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware”, STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2131] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC4286] Haberman, B. and J. Martin, “Multicast Router Discovery”, RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches”, RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)”, RFC 4601, DOI 10.17487/RFC4601, August 2006, <https://www.rfc-editor.org/info/rfc4601>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration”, RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey”, RFC 5757, DOI 10.17487/RFC5757, February 2010, <https://www.rfc-editor.org/info/rfc5757>.

[RFC5796] Atwood, W., Islam, S., and M. Siami, “Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages”, RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.

[RFC6282] Hui, J., Ed. and P. Thubert, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”, RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.

[RFC6762] Cheshire, S. and M. Krochmal, “Multicast DNS”, RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC6763] Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery”, RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, “Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.

[RFC6970] Boucadair, M., Penno, R., and D. Wing, “Universal Plug and Play (UPnP) Internet Gateway Device – Port Control Protocol Interworking Function (IGD-PCP IWF)”, RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.

[RFC7450] Bumgardner, G., “Automatic Multicast Tunneling”, RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, “Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)”, STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, “Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery”, RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.

[RFC8777] Holland, J., “DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery”, RFC 8777, DOI 10.17487/RFC8777, April 2020, <https://www.rfc-editor.org/info/rfc8777>.

[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, “IPv6 Backbone Router”, RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.

[RFC9030] Thubert, P., Ed., “An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)”, RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.

[Tramarin2017] Tramarin, F., Vitturi, S., and M. Luvisotto, “IEEE 802.11n for Distributed Measurement Systems”, 2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC), pp. 1-6, May 2017.

[uli] Kinney, P., “LLC Proposal for 802.15.4”, September 2015, <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>.

[v2011] IEEE, “Information technology — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network Management”, DOI 10.1109/IEEESTD.2011.5716530, IEEE Std 802.11v-2011, February 2011, <https://ieeexplore.ieee.org/document/5716530>.

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

Этот документ выиграл в результате обсуждения с перечисленными в алфавитном порядке людьми: Mikael Abrahamsson, Bill Atwood, Stuart Cheshire, Donald Eastlake 3rd, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Thubert, Jeffrey (Zhaohui) Zhang.

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

Charles E. Perkins
Lupin Lodge
Phone: +1 408 255 9223
Email: charliep@lupinlodge.com
 
Mike McBride
Futurewei Technologies Inc.
2330 Central Expressway
Santa Clara, CA 95055
United States of America
Email: michael.mcbride@futurewei.com
 
Dorothy Stanley
Hewlett Packard Enterprise
6280 America Center Dr.
San Jose, CA 95002
United States of America
Phone: +1 630 363 1389
Email: dorothy.stanley@hpe.com
 
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
 
Juan Carlos Zúñiga
SIGFOX
Montreal
Canada
Email: j.c.zuniga@ieee.org

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Нажмите для разговора.

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

RFC 9108 YANG Types for DNS Classes and Resource Record Types

image_print
Internet Engineering Task Force (IETF)                         L. Lhotka
Request for Comments: 9108                                        CZ.NIC
Category: Standards Track                                      P. Špaček
ISSN: 2070-1721                              Internet Systems Consortium
                                                          September 2021

YANG Types for DNS Classes and Resource Record Types

Типы YANG для классов DNS и типов RR

PDF

Аннотация

Этот документ вводит модуль YANG iana-dns-class-rr-type, содержащий производные типы данных, отражающие реестры IANA DNS CLASSes и Resource Record (RR) TYPEs. Эти типы YANG служат начальной основой для будущей работы по моделированию данных.

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

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

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

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

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

Авторские права (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).

Оглавление

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

1. Введение

Язык YANG [RFC7950] стал фактическим стандартом моделирования данных конфигурации и состояния, а также задания управляющих операций и асинхронных уведомлений. Разумно ожидать, что основанный на таких моделях данных подход вместе со стандартными протоколами управления, такими как NETCONF [RFC6241] и RESTCONF [RFC8040], можно будет эффективно применять и в операциях DNS. Фактически в настоящее время уже предпринимаются попытки использовать NETCONF и RESTCONF для настройки и управления:

  • полномочными серверами;

  • распознавателями;

  • данными зон.

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

На основе опыта IETF Routing Area можно ожидать, что разработка унифицированных моделей данных для DNS окажется сложной и длительной и потребует активного сотрудничества и компромиссов между разработчиками и поставщиками основных серверных платформ DNS. Тем не менее, вполне вероятно, что любое моделирование относящихся к DNS данных потребует использования различных параметров и перечней DNS, заданных в нескольких реестрах IANA. Для использования с YANG эти параметры и перечни нужно перевести в соответствующие типы YANG или иные структуры. Такой трансляции следует быть простой и сравнительно бесспорной.

Этот документ обеспечивает трансляцию двух связанных с DNS фундаментальных реестров IANA в YANG. Документ содержит первоначальную версию модуля YANG iana-dns-class-rr-type, которая определяет производные типы для общих параметров записей DNS о ресурсах (RR) – класс и тип. Типы YANG dns-class и rr-type, отражают реестры IANA DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS].

В Приложении A приведена таблица стилей XSLT 1.0, предназначенная для использования IANA при генерации исходной версии модуля iana-dns-class-rr-type. Впоследствии при добавлении нового класса или типа RR в упомянутые реестры IANA будет также обновлять модуль iana-dns-class-rr-type, следуя инструкциям раздела 4.

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

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

Терминология для описания моделей данных YANG приведена в [RFC7950]. Используемые в документе термины DNS определены в [RFC1035] и [RFC8499].

3. Вопросы проектирования YANG

Во время написания этого документа реестр «Domain Name System (DNS) Parameters» [IANA-DNS-PARAMETERS] включал 13 субреестров. Модуль YANG iana-dns-class-rr-type определяет производные типы, соответствующие лишь 2 реестрам, которые важны для моделей данных, включающих данные зоны, а именно «DNS CLASSes» и «Resource Record (RR) TYPEs». Предполагается, что оставшиеся реестры [IANA-DNS-PARAMETERS], а также другие реестры IANA, связанные с DNS, по мере необходимости будут отражаться в последующих модулях YANG. Таким образом, можно будет выбрать подходящую комбинацию модулей YANG в зависимости от требуемых типов YANG и целей моделирования.

Реестры «DNS CLASSes» и «Resource Record (RR) TYPEs» преобразованы в перечисляемые типы YANG dns-class-name и rr-type-name, соответственно. Ниже приведён начальный фрагмент первого из них.

     typedef dns-class-name {
       type enumeration {
         enum IN {
           value 1;
           description
             "Internet (IN)";
           reference
             "RFC 1035";
         }
         ...
       }
       ...
     }

Другой производный тип rr-type-name определён аналогичным способом.

В [RFC3597] введена опция для указания класса или типа RR присвоенным ему десятичным номером вместо мнемонического имени. Например, класс IN можно указать как CLASS1, а тип AAAA – как TYPE28. В соответствии с этим производные типы dns-class и rr-type определены в модуле YANG как объединение двух типов:

  • 16-битовое десятичное значение (uint16);

  • мнемоническое имя, относящееся к перечисляемым типам dns-class-name и rr-type-name.

Например, тип rr-type определён как

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description
         "Этот тип позволяет указывать тип записи о ресурсе DNS
          с использованием мнемонического имени или числа.";
     }

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

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

В этом разделе рассматриваются действия и процессы IANA, требуемые для поддержки модуля YANG iana-dns-class-rr-type, предназначенного для отображения реестров DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS]. Свежая версия модуля YANG доступна в реестре YANG Parameters [IANA-YANG-PARAMETERS].

С публикацией этого документа агентство IANA создало и разместило начальную версию модуля iana-dns-class-rr-type путём применения таблицы стилей XSLT из Приложения A к XML-версии [IANA-DNS-PARAMETERS].

Ниже приведено примечание, добавленное IANA к записи iana-dns-class-rr-type в реестре YANG Module Names [IANA-YANG-PARAMETERS].

Классы и типы записей о ресурсах DNS недопустимо добавлять напрямую в модуль YANG iana-dns-class-rr-type, они должны добавляться в реестры DNS CLASSes и Resource Record (RR) TYPEs, соответственно.

При добавлении класса DNS или типа RR в реестр DNS CLASSes или Resource Record (RR) TYPEs нужно добавлять оператор enum к типу dns-class-name или rr-type-name, соответственно. Имени в enum нужно совпадать с мнемоническим именем нового класса или типа. В оператор enum нужно включить указанные ниже субоператоры.

value

Десятичное значение из реестра.

status

Включается лишь для классов или типов, регистрация которых отменена или устарела. Значениям deprecated и obsolete в реестре соответствуют такие же значения в модуле YANG.

description

Копия соответствующих сведений из реестра, а именно полное имя нового класса DNS или значение нового типа RR, если оно имеется.

reference

Копия ссылок из реестра.

Невыделенные и резервные значение не нужно включать в перечисляемые типы dns-class-name и rr-type-name.

При каждом обновлении модуля YANG iana-dns-class-rr-type нужно добавлять новый оператор revision перед имеющимися операторами revision.

Ниже приведено примечание, добавленное IANA в реестры DNS CLASSes и Resource Record (RR) TYPEs.

При изменении реестра должен обновляться модуль YANG iana-dns-class-rr-type, как указано в [RFC9108].

Ниже приведено обновление текста Reference в реестре DNS CLASSes.

Старый текст

[RFC6895]

Новый текст

[RFC6895][RFC9108]

Ниже приведено обновление текста Reference в реестре Resource Record (RR) TYPEs.

Старый текст

[RFC6895][RFC1035]

Новый текст

[RFC6895][RFC1035][RFC9108]

4.1. Регистрация URI

Этот документ регистрирует URI в реестре IETF XML [RFC3688], добавляя в него приведённые ниже записи.

   URI:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace3.

4.2. Регистрация модуля YANG

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020], добавляя в него приведённые ниже записи.

   Name:  iana-dns-class-rr-type
   Namespace:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Prefix:  dnsct
   Reference:  RFC 9108

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

Этот документ преобразует два реестра IANA в типы данных YANG и не задаёт новых технологий или протоколов. Определения сами по себе не влияют на безопасность Internet, но их применение в конкретных модулях YANG может оказывать такое влияние. Отмеченные в спецификации YANG [RFC7950] вопросы безопасности применимы и к этому документы.

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

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

[IANA-DNS-PARAMETERS] IANA, “Domain Name System (DNS) Parameters”, <https://www.iana.org/assignments/dns-parameters>.

[IANA-YANG-PARAMETERS] IANA, “YANG Parameters”, <https://www.iana.org/assignments/yang-parameters>.

[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>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[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>.

[W3C.REC-xslt-19991116] Clark, J., “XSL Transformations (XSLT) Version 1.0”, W3C Recommendation REC-xslt-19991116, November 1999, <https://www.w3.org/TR/1999/REC-xslt-19991116>.

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

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC3597] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types”, RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Приложение A. Таблица стилей XSLT

В этом приложении содержится таблица стилей XSLT 1.0 [W3C.REC-xslt-19991116], использованная для создания исходной версии модуля YANG iana-dns-class-rr-type. Это было выполнено путём применения таблицы стилей к XML-версии реестра IANA Domain Name System (DNS) Parameters [IANA-DNS-PARAMETERS] на момент публикации этого документа.

С помощью программы xsltproc текст модуля YANG можно создать командой

       $ xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml

   <CODE BEGINS> file "iana-dns-class-rr-type.xsl"
   <?xml version="1.0" standalone="yes"?>
   <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
               xmlns:iana="http://www.iana.org/assignments"
               version="1.0">
     <output method="text"/>
     <strip-space elements="*"/>

     <variable name="dq">"</variable>
     <variable name="sq">'</variable>

     <variable name="module-intro">
       <text>module iana-dns-class-rr-type {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type";
     prefix dnsct;

     organization
       "Internet Assigned Numbers Authority (IANA)";

     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                12025 Waterfront Drive, Suite 300
                Los Angeles, CA 90094

        Tel:    +1 424 254 5300

        &lt;mailto:iana@iana.org&gt;";

     description4
       "This YANG module translates IANA registries 'DNS CLASSes' and
        'Resource Record (RR) TYPEs' to YANG-derived types.

        Copyright (c) 2021 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module was generated from
        the corresponding IANA registries using an XSLT stylesheet
        from Appendix A of RFC 9108
        (https://www.rfc-editor.org/info/rfc9108); see the RFC itself
        for full legal notices.";

     reference
       "IANA 'Domain Name System (DNS) Parameters' registry
        https://www.iana.org/assignments/dns-parameters";</text>
        <text>&#xA;&#xA;</text>
     </variable>

     <template name="enum">
       <param name="id"/>
       <value-of select="concat('      enum ', $id)"/>
       <text> {&#xA;        value </text>
       <value-of select="concat(iana:value, ';&#xA;')"/>
       <if test="contains(iana:description, 'OBSOLETE')">
         <text>        status obsolete;&#xA;</text>
       </if>
       <apply-templates select="iana:description"/>
       <variable name="xrefs" select="iana:xref[@type!='note']"/>
       <if test="$xrefs">
         <text>        reference&#xA;          "</text>
         <if test="count($xrefs)&gt;1">- </if>
         <apply-templates select="iana:xref[@type!='note']"/>
       </if>
       <text>      }&#xA;</text>
     </template>

     <template match="/">
       <value-of select="$module-intro"/>
       <apply-templates select="iana:registry[@id='dns-parameters']"/>
       <text>}&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters']">
       <apply-templates select="iana:updated"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-2']"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-4']"/>
     </template>

     <template match="iana:updated">
       <value-of select="concat('  revision ', ., ' {')"/>
       <text>
       description
         "Initial revision.";
       reference
         "RFC 9108: YANG Types for DNS Classes and Resource Record
          Types";
     }

     /* Typedefs */&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-2']">
       <text>  typedef dns-class-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[not(iana:description='Unassigned' or
                   starts-with(iana:description,'Reserved'))]"
           mode="class"/>
       <text>    }
       description5
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS classes.";
       reference
         "RFC 6895: Domain Name System (DNS) IANA Considerations";
     }

     typedef dns-class {
       type union {
         type uint16;
         type dns-class-name;
       }
       description6
         "This type allows reference to a DNS class using either the
          assigned mnemonic name or numeric value.";
     }&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-4']">
       <text>  typedef rr-type-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[iana:type!='Unassigned' and
                   iana:type!='Private use' and iana:type!='Reserved']"
           mode="rr-type"/>
       <text>    }
       description7
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS resource record types.";
       reference
         "- RFC 6895: Domain Name System (DNS) IANA Considerations

          - RFC 1035: Domain names - implementation and specification";
     }

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description8
         "This type allows reference to a DNS resource record type
          using either the assigned mnemonic name or numeric value.";
     }&#xA;</text>
     </template>

     <template match="iana:record" mode="class">
       <call-template name="enum">
         <with-param name="id">
           <choose>
             <when test="contains(iana:description,'(')">
               <value-of select="substring-before(substring-after(
                                 iana:description, '('), ')')"/>
             </when>
             <otherwise>
               <value-of
                   select="substring-after(iana:description, ' ')"/>
             </otherwise>
           </choose>
         </with-param>
       </call-template>
     </template>

     <template match="iana:record" mode="rr-type">
       <call-template name="enum">
         <with-param name="id" select="iana:type"/>
       </call-template>
     </template>

     <template match="iana:description">
       <text>        description&#xA;          </text>
       <value-of select="concat($dq, ., $dq, ';&#xA;')"/>
     </template>

     <template match="iana:xref">
       <choose>
         <when test="@type='rfc'">
           <value-of
               select="concat('RFC ', substring-after(@data, 'rfc'))"/>
         </when>
         <when test="@type='person'">
           <apply-templates
               select="/iana:registry/iana:people/iana:person[
                       @id=current()/@data]"/>
         </when>
         <when test="@type='text'">
           <value-of select="translate(., $dq, $sq)"/>
         </when>
         <otherwise>
           <value-of select="@data"/>
         </otherwise>
       </choose>
       <choose>
         <when test="position()=last()">
           <text>";&#xA;</text>
         </when>
         <otherwise>
           <text>&#xA;           - </text>
         </otherwise>
       </choose>
     </template>

     <template match="iana:person">
       <value-of select="concat(iana:name, ' &lt;', iana:uri, '&gt;')"/>
     </template>

   </stylesheet>
   <CODE ENDS>

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

Ladislav Lhotka

CZ.NIC

Czech Republic

Email: ladislav.lhotka@nic.cz

Petr Špaček

Internet Systems Consortium

Czech Republic

Email: pspacek@isc.org


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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Не задано. Запрошенный идентификатор URI является пространством имён XML.

4Этот модуль YANG транслирует реестры IANA «DNS CLASSes» и «Resource Record (RR) TYPEs» в типы YANG.

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

Распространение и использование в текстовой или двоичной форме с изменениями или без таковых может осуществляться на условиях Simplified BSD License, как указано в параграфе 4.c документа IETF Trust Legal Provisions применительно к документам IETF (https://trustee.ietf.org/license-info).

Эта версия модуля YANG создана из соответствующих реестров IANA с использованием таблицы стилей XSLT из Приложения A к RFC 9108 (https://www.rfc-editor.org/info/rfc9108). Полная юридическая информация приведена в самом RFC.

5Этот перечисляемый тип определяет мнемонические имена и соответствующие численные значения для классов DNS.

6Этот тип позволяет указывать классы DNS мнемоническим именем или числом.

7Этот перечисляемый тип определяет мнемонические имена и соответствующие численные значения для записей о ресурсах DNS.

8Этот тип позволяет указывать записи о ресурсах DNS мнемоническим именем или числом.

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

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 8993 A Reference Model for Autonomic Networking

image_print
Internet Engineering Task Force (IETF)                 M. Behringer, Ed.
Request for Comments: 8993                                              
Category: Informational                                     B. Carpenter
ISSN: 2070-1721                                        Univ. of Auckland
                                                               T. Eckert
                                                           Futurewei USA
                                                            L. Ciavaglia
                                                                   Nokia
                                                                J. Nobre
                                                                   UFRGS
                                                                May 2021

A Reference Model for Autonomic Networking

Эталонная модель для сетей с самоуправлением

PDF

Аннотация

В этом документе описана эталонная модель для автоматической работы1 (Autonomic Networking или AN) управляемой сети. Определено поведение автоматического узла, совместная работа элементов в контексте самоуправления и использование инфраструктуры автоматическими службами.

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ не связан с другими RFC и выбран для публикации редактором (RFC Editor) по своему усмотрению без каких-либо заявлений о ценности документа для внедрения или развёртывания. Документы, одобренные для публикации RFC Editor, не претендуют на статус стандартов Internet (см. раздел 2 в RFC 7841).

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

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

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).

Оглавление

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

1. Введение

В документе «Autonomic Networking: Definitions and Design Goals» [RFC7575] описаны фундаментальные концепции, лежащие в основе автономных сетей (Autonomic Networking), определены термины и высокоуровневая эталонная модель. В [RFC7576] рассматривается «разрыв» между традиционным подходом и автономизацией.

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

Как отмечено в [RFC7575], цель работы не заключается в рассмотрении лишь полностью автоматических узлов или сетей. На деле большинство автоматических сетей будет работать с некоторыми автоматическими функциями, тогда как в остальной части сети будет применяться традиционное управление. Эталонная модель позволяет такой подход.

Например, в имеющейся неавтоматической сети можно регистрировать устройства традиционным способом для создания доверенной инфраструктуры на основе сертификатов. Эту доверенную инфраструктуру затем можно применить для активизации автоматической плоскости управления (Autonomic Control Plane или ACP) и выполнения традиционных сетевых операций через защищённую и самовосстанавливающуюся ACP (см. [RFC8368]).

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

В этом документе описана первая фаза решения для автоматических сетей (Autonomic Networking или AN), которая проста и реализуема. Предполагается, что обретённый на этом этапе опыт будет использован со временем для создания обновлённых и расширенных спецификаций. Некоторые вопросы рассматриваются в документе с архитектурной точки зрения, но ещё не отражены в спецификациях реализаций. Соответствующие параграфы документа помечены звёздочкой (*).

2. Представление сети

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

На рисунке 1 показано высокоуровневое представление сети с самоуправлением (AN). Сесть состоит из множества автоматических узлов, которые взаимодействуют между собой напрямую. Эти автоматические узлы обеспечивают в сети общий набор возможностей (свойств), который называется инфраструктурой автоматической сети (Autonomic Networking Infrastructure или ANI). Инфраструктура ANI обеспечивает такие функции, как именование, адресация, синхронизация, обнаружение и обмен сообщениями.

Автоматические функции обычно охватывают несколько узлов сети (возможно все). Неделимые элементы автоматической функции называют агентами автоматических служб (Autonomic Service Agent или ASA), их экземпляры создаются на узлах.

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:            :     Автоматическая функция 1      :                 :
: ASA 1      :      ASA 1      :      ASA 1      :          ASA 1  :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
             :                 :                 :
             :   +- - - - - - - - - - - - - - +  :
             :   :  Автоматическая функция 2  :  :
             :   :  ASA 2      :      ASA 2   :  :
             :   +- - - - - - - - - - - - - - +  :
             :                 :                 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:                Инфраструктура автоматической сети                :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+   :    +--------+   :    +--------+   :        +--------+
| Узел 1 |--------| Узел 2 |--------| Узел 3 |----...-----| Узел n |
+--------+   :    +--------+   :    +--------+   :        +--------+

Рисунок 1. Высокоуровневое представление сети с самоуправлением.


По горизонтали автоматические функции охватывают всю сеть, а также ANI. По вертикали сеть всегда реализует ANI и может включать один или несколько агентов ASA, которые могут быть автономными или включать в себя другие ASA (иерархия). Таким образом, ANI служит основой для автоматических функций.

3. Самоуправляемый элемент сети

В этом разделе описана общая архитектура элементов AN (параграф 3.1), отслеживание ими окружающей среды в таблице смежности (параграф 3.2) и конечный автомат, определяющий поведение элемента сети (параграф 3.3) на основе таблицы смежности.

3.1. Архитектура

В этом параграфе описывается элемент AN и его внутренняя архитектура. Эталонная модель из «Autonomic Networking: Definitions and Design Goals» [RFC7575] показывает источники информации, которые может использовать ASA – самообучение, изучение сети (с помощью обнаружения), Intent (см. параграф 7.2) и контуры обратной связи. Внутри автоматического узла имеется два уровня – уровень ASA и уровень ANI, причём первый использует услуги второго. Эта концепция показана на рисунке 2.

+------------------------------------------------------------+
|                                                            |
| +-----------+        +------------+        +------------+  |
| |   Агент   |        |   Агент    |        |   Агент    |  |
| | автоматич.|        | автоматич. |        | автоматич. |  |
| | службы 1  |        | службы 2   |        | службы 3   |  |
| +-----------+        +------------+        +------------+  |
|       ^                    ^                     ^         |
| -  -  | -  - Уровень API  -| -  -  -  -  -  -  - |-  -  -  |
|       V                    V                     V         |
|------------------------------------------------------------|
| Инфраструктура автоматической сети                         |
|    - структуры данных (сертификаты, сведения о партнёрах)  |
|    - обобщённая автоматическая плоскость управления (GACP) |
|    - адресация и именование автоматического узла           |
|    - функции обнаружения, согласования и синхронизации     |
|    - распространение намерений (Intent) и другой информации|
|    - агрегированные отчёты и контуры обратной связи        |
|    - маршрутизация                                         |
|------------------------------------------------------------|
|           Функции базовой операционной системы             |
+------------------------------------------------------------+

Рисунок 2. Модель автоматического узла.


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

Обобщённая плоскость управления (Generalized ACP или GACP) – это сводка всех взаимодействий ANI с другими узлами и службами. Конкретная реализация GACP в этом документе обозначается ACP и описана в [RFC8994].

Варианты использования автоматики (самоуправления, самооптимизация и т. п.) реализованы как элементы ASA. Они используют службы и структуры данных базовой инфраструктуры ANI, которой следует быть самоуправляющейся.

Функции базовой ОС (нижняя часть рисунка 2) включают обычную ОС (например, сетевой стек и функции защиты).

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

3.2. Таблица смежности

Самоуправляемые сети AN основаны на прямом взаимодействии между узлами домена. Плоскость управления ACP обычно строится на пошаговой основе (hop-by-hop), поэтому многие взаимодействия в ANI основываются на таблице смежности. Некоторые взаимодействия вносят сведения в эту таблицу, а другие используют данные из таблицы.

Таблица смежности ANI содержит по меньшей мере сведения о смежных автоматических узлах: Node-ID, IP-адрес в плоскости данных, IP-адрес в ACP, домен и сертификат. Автоматический узел поддерживает актуальность сведений в таблице. Таблица содержит сведения лишь об узлах, поддерживающих AN, а узлы без самоуправления обычно не отслеживаются в таблице. Однако информация отслеживается независимо от статуса партнёров, в частности, таблица смежности содержит сведения о незарегистрированных узлах того же или иного домена. Таблица смежности может включать сведения о действительности смежных автоматических узлов и уровне доверия к ним.

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

  • Обнаружение локальных соединений (Link-local). Это взаимодействие происходит в плоскости данных с использованием лишь адресации IPv6 link-local, поскольку этот тип адресации сам является автоматическим. Этот способ позволяет узлу изучить автоматические узлы вокруг себя. Процедуру обнаружения локальных соединений описывают документы [RFC8990], [RFC8995], [RFC8994].

  • Перенаправление от производителя. Новое устройство может получать информацию о местоположении его домашней сети через перенаправление от уполномоченного производителем удостоверяющего центра (Manufacturer Authorized Signing Authority или MASA), как указано в параграфе 5.3. Обычно это маршрутизируемый адрес.

  • Неавтоматический ввод. Узел можно настроить вручную с участием автоматического партнёра, о котором узел может узнать из опций DHCP, DNS или иных неавтоматических механизмов. Обычно такие механизмы требуют того или иного участия администратора. Основной целью является обход (bypass) неавтоматического устройства или сети. Для новых устройств этот вопрос рассматривается в Приложениях A и B к [RFC8995].

Таблица смежности определяет поведения узла с самоуправлением, как описано ниже.

  • Если узел не загрузился (bootstrap) в домен (т. е. не имеет сертификата домена), он проходит один за другим все узлы в таблице смежности, заявляющие присутствие в домене, и пытается загрузиться через них. Одним из возможных откликов является перенаправления через MASA производителя, которое будет введено в таблицу смежности (см. выше и [RFC8995]).

  • Если смежный узел относится к тому же домену, он аутентифицирует данный узел и при успешной проверке подлинности организует ACP (см. [RFC8994]).

  • Как только узел становится частью ACP в домене, он будет использовать GRASP [RFC8990] для поиска регистраторов домена и, возможно, других служб.

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

  • Возможно иное поведение, например, организация ACP с устройствами субдомена или других доменов. Это скорей всего будет контролироваться Intent, но этот вопрос выходит за рамки документа. Отметим, что Intent распространяется через ACP, поэтому узел может адаптировать управляемое Intent поведение лишь после присоединения к ACP. В настоящее время рабочая группа ANIMA не рассматривает предоставление Intent вне ACP, но это может быть рассмотрено позднее.

После присоединения узла к ACP он также узнает адреса ACP смежных узлов и добавит их в таблицу смежности для обеспечения коммуникаций внутри ACP. Последующие взаимодействия автоматических доменов будут выполняться внутри ACP. В настоящее время определены лишь согласование и синхронизация через GRASP [RFC8990]. GRASP работает в плоскости данных как источник сведений для построения таблицы смежности, а также внутри ACP.

Автоматические функции состоят из ASA. Они работают логически на базе инфраструктуры ANI и могут использовать таблицу смежности, ACP, согласование и синхронизацию через GRASP в ACP, Intent и другие функции ANI. Поскольку ANI обеспечивает лишь автоматическое взаимодействие внутри домена, автоматические функции могут также использовать любой другой контекст на узле, в частности, глобальную плоскость данных.

3.3. Конечный автомат

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

Обычно предполагается, что устройство сохраняет связанное с доменом отождествление – Local Device Identifier (LdevID, см. параграф 5.2) – в постоянном хранилище, которое будет доступно после выключения и последующего включения питания. Для устройств, не способных постоянно сохранять LDevID выключения питания равносильно сбросу к заводским настройкам.

3.3.1. Состояние 1 – заводские установки

Автоматический узел выпускается с завода в этом состоянии. Узел не имеет связанных с доменом настроек, в частности LDevID, и может использоваться в любой конкретной сети. Однако узел имеет заданный производителем идентификатор (Initial Device Identifier или IDevID) [IDevID]. Узлы без IDevID невозможно автоматически и безопасно зарегистрировать в домене, они требуют предварительной настройки вручную и в этом случае подготовка начинается из состояния 2.

Переходы

  • Загрузка. Устройство регистрируется в домене, получая при этом доменное отождествление – LDevID. При успешной регистрации следующим будет состояние 2. регистрация описана в [RFC8995].

  • Включение и выключение питания. Устройство теряет все таблицы состояний и остаётся в состоянии 1.

3.3.2. Состояние 2 – устройство зарегистрировано

Автоматический узел находится в зарегистрированном (enrolled) состоянии, если у него имеется LdevID и в настоящее время нет канала ACP. Узел может иметь дополнительную конфигурацию или состояние, если он находился, например, в состоянии 3, но потерял все свои каналы ACP. Идентификатор LDevID можно удалить с устройства только при сбросе к заводским настройкам и при этом будут удалены все прочие состояния устройства. Это гарантирует отсутствие устаревшего доменного состояния при регистрации из состояния 1.

Переходы

  • Присоединение к ACP. Устройство организует канал ACP к смежному устройству (см. [RFC8994]). Следующим будет состояние 3.

  • Сброс к заводским настройкам. Удаляются все конфигурации и доменное отождествление LdevID. Следующим будет состояние 1.

  • Включение и выключение питания. Устройство теряет все таблицы состояния, но сохраняет доменное отождествление LdevID и остаётся в состоянии 2.

3.3.3. Состояние 3 – устройство подключено к ACP

В этом состоянии автоматический узел имеет хотя бы 1 канал ACP к другому устройству. Узел теперь может участвовать в других автоматических транзакциях, таких как запуск ASA (например, он должен включить прокси-ASA для присоединения, чтобы помочь другим устройствам войти в домен). К таким взаимодействиям могут применяться другие условия, например, для работы в качестве посредника в присоединении, устройство сначала должно найти регистратор загрузки.

Переходы

  • Выход из ACP. Устройство отключает последний (единственный) канал ACP к смежному устройству. Следующим будет состояние 2.

  • Сброс к заводским настройкам. Удаляются все конфигурации и доменное отождествление LdevID. Следующим будет состояние 1.

  • Включение и выключение питания. Устройство теряет все таблицы состояния, но сохраняет доменное отождествление LdevID. Следующим будет состояние 2.

4. Инфраструктура AN

Инфраструктура ANI обеспечивает уровень общей функциональности в сети с самонастройкой AN. Она предоставляет элементарные функции и службы, а также расширения. Автоматическая функция, состоящая из агентов ASA на узлах, использует описанные в этом разделе функции.

4.1. Именование

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

При отсутствии специфической для домена схемы именования следует применять принятую по умолчанию схему, использующую такую же логику как схема адресации, описанная в [RFC8994]. Имя устройства в этом случае состоит из Registrar-ID (например, MAC-адрес регистратора) и номера устройства. Примером такого имени может служить

   0123-4567-89ab-0001

Первые 3 поля этого имени образованы MAC-адресов, а четвёртое содержит порядковый номер устройства.

4.2. Адресация

Агенты ASA должны взаимодействовать друг с другом, используя автоматическую адресацию инфраструктуры ANI узла, на котором размещается агент. В этом параграфе описан подход к адресации ANI используемой агентами ASA. Подход к адресации в плоскости данных сети выходит за рамки этого документа. Эта адресация может настраиваться и управляться традиционным способом или согласовываться как услуга ASA. Один из примеров использования такой автономной функции представлен в [RFC8992].

Автоматическая адресация является функцией ANI (нижняя часть рисунка 2) и, в частности ACP. Агенты ASA не имеют собственных адресов. Они могут использовать вызовы API или схему автоматической адресации ANI. Требования к схеме автоматической адресации перечислены ниже.

  • Адресация без вмешательства (Zero-touch) для простых сетей, которым следует иметь полное самоуправление адресацией и не требовать централизованного управления, инструментов и планирования.

  • Незначительное вмешательство для сложных сетей. Здесь требуется участие оператора для автоматического управления адресами, которое следует ограничивать высокоуровневым руководством, выраженным в Intent.

  • Гибкость. Схема адресации должна позволять узлам перемещаться по сети, а сеть должна иметь возможность расширяться, делиться и сливаться с другими сетями.

  • Устойчивость. Возможность негативного влияния администратора на адресацию (и связность) следует предотвращать в контексте сети с самоуправлением.

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

  • Поддержка виртуализации. Автоматические функции могут работать на уровне физической сети и устройств или на уровне виртуальных машин, контейнеров и сетей. В частности, автоматические узлы могут поддерживать ASA в виртуальных объектах. Инфраструктуре и схеме адресации, следует поддерживать это.

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

  • Расширяемость. Схема адресации должна работать в сетях любого размера.

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

Предлагаемая схема адресации описана в документе «An Autonomic Control Plane (ACP)» [RFC8994].

4.3. Обнаружение

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

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

Во-вторых, для сетевых служб, таких как аутентификация, проверка полномочий и учёт (Authentication, Authorization, Accounting или AAA), также следует поддерживать обнаружение без настройки. Сеть с самоуправлением (AN) может использовать имеющиеся функции обнаружения, применять новые подходы или то и другое вместе.

Таким образом, механизмы обнаружения могут быть полностью объединены с автоматической сигнализацией (см. следующий параграф) или использовать независимые механизмы, такие как обнаружение служб через DNS или Service Location Protocol. Выбор может быть независимым для каждого агента ASA, хотя инфраструктура может требовать того или иного общего минимума (например, обнаружение механизма защищённой загрузки или источника распространения информации, см. параграф 4.7).

В фазе 1 сети с самоуправлением (Autonomic Networking) используют для обнаружения протокол GRASP [RFC8990].

4.4. Сигнализация между автоматическими узлами

Автоматические узлы должны взаимодействовать между собой, например, для согласования и/или синхронизации технических целей (т. е. параметров сети) любого типа и сложности. Для этого нужна та или иная форма сигнализации между узлами. Автоматические узлы, реализующие определённый вариант, могут выбрать свой сигнальный протокол, если он соответствует общей модели безопасности. Однако в общем случае обмен данными может потребоваться любой паре узлов с самоуправлением, поэтому нужен общий протокол сигнализации. Предпосылкой для этого является возможность узлов обнаруживать друг друга без предварительной настройки, как отмечено выше. Для обеспечения общего характера обнаружение и сигнализация должны быть способны решать любые технические задачи, включая те, которым нужны сложные структуры данных. В документе «GeneRic Autonomic Signaling Protocol (GRASP)» [RFC8990] более подробно описаны требования к обнаружению, согласованию и синхронизации в AN. Документ также определяет протокол GRASP для этих целей, включающий встроенный, но необязательный процесс обнаружения.

Обычно предполагается, что GRASP работает внутри ACP (см. параграф 4.6) и зависит от ACP в плане безопасности. Возможна кратковременная работа протокола без защиты в процессе начальной загрузки (bootstrap). На автоматическом узле обычно работает один экземпляр GRASP, используемый несколькими агентами ASA. Однако не исключается использование на узле нескольких экземпляров GRASP, возможно с разными свойствами защиты.

4.5. Маршрутизация

Все автоматические узлы в домене должны быть способны взаимодействовать друг с другом, а на последующих фазах – ещё и с автоматическими узлами других доменов. Поэтому ACP полагается на функцию маршрутизации. Для взаимодействия сетей с самоуправлением они должны поддерживать общий протокол маршрутизации. В документе ACP [RFC8994] определён протокол маршрутизации для AN.

4.6. Автоматическая плоскость управления

Плоскость управления ACP поддерживает протоколы управления в автоматической сети AN. В описанной здесь архитектуре она реализована как наложенная сеть. В документе «An Autonomic Control Plane (ACP)» [RFC8994] описаны детали реализации. Данный документ использует термин «наложенная» (overlay) для обозначения набора парных смежностей с базовой топологией соединений. Это может отличаться от толкования термина overlay в контексте маршрутизации. Примеры использования ACP приведены в [RFC8368].

4.7. Распространение информации (*)

Некоторые формы информации требуют распространения через домен с самоуправлением. Такое распространение происходит в плоскости управления ACP. Например Intent распространяется по домену, как описано в [RFC7575]. Намерения (Intent) являются языком правил в сети с самоуправлением AN (см. параграф 7.2). Это правила высокого уровня и менять их следует нечасто (дни). Поэтому такую информацию, как Intent, следует рассылать в лавинном режиме всем узлам автоматического домена и в настоящее время нет ощутимой потребности использовать более направленные методы распространения. Предполагается, что Intent будет «монолитным» и рассылаться будет целиком. Один из возможных методов распространения Intent и других форм данных рассмотрен в [GRASP-DISTRIB]. Intent и распространение информации не входят в задачи рабочей группы ANIMA.

5. Инфраструктура защиты и доверия

Автоматические сети AN сами защищают себя. Все протоколы по умолчанию являются защищёнными и не требуют привлечения администратора для явной настройки защиты за исключением установки инфраструктуры PKI.

Автоматические узлы взаимодействуют напрямую и это требует защиты. Поскольку сети AN не полагаются на настройку конфигурации, здесь нет опций настройки, таких как заранее распространённые ключи и вместо этого должна применяться доверенная инфраструктура, такая как PKI. В этом разделе описаны принципы инфраструктуры доверия. На первой фазе AN устройство 1) находится в доверенном домене и само является доверенным или 2) находится за пределами домена доверия и считается недоверенным.

Принятый по умолчанию метод автоматического запуска инфраструктуры доверия определён в документе «Bootstrapping Remote Secure Key Infrastructure (BRSKI)» [RFC8995]. Агенты ASA, требуемые для регистрации, описаны в параграфе 6.3. Автоматические узлы должны реализовать агенты ASA для регистрации и посредничества в присоединении. ASA-регистратор можно реализовать на части устройств.

5.1. Инфраструктура открытых ключей

Домен с самоуправлением использует модель PKI. Конем доверия является удостоверяющий центр (Certification Authority или CA). Регистратор выступает в качестве центра регистрации (Registration Authority или RA). Минимальная реализация автоматического домена содержит один CA, один регистратор и элементы сети.

5.2. Сертификат домена

Каждое устройство в домене самоуправления использует сертификат домена (LdevID) для отождествления себя. Новое устройство использует предоставленный производителем сертификат IdevID в процессе начальной загрузки для получения сертификата LdevID. Процесс получения доменного сертификата и его формат описаны в [RFC8995].

5.3. MASA

Уполномоченный производителем орган подписания (Manufacturer Authorized Signing Authority или MASA) является доверенной службой для устройств с начальной загрузкой. MASA позволяет владельцу отслеживать устройства в домене, обеспечивая регистратору аудит, проверку полномочий и маркеры владения в процессе начальной загрузки, чтобы помочь при проверке подлинности устройств, пытающихся присоединиться к домену самоуправления и позволить присоединяющемуся устройству проверить корректность домена. Детали службы MASA, безопасности и применения описаны в [RFC8995].

5.4. Субдомены (*)

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

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

5.5. Кросс-доменная функциональность (*)

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

6. Автоматические агенты служб

В этом разделе описана работа автоматических служб в инфраструктуре ANI.

6.1. Общее описание ASA

Агент ASA определён в [RFC7575] как: «Агент, реализованный на автоматическом узле и выполняющий автоматическую функцию частично (распределенная функция) или полностью. Таким образом, это процесс, использующий функции инфраструктуры ANI для достижения своих целей, обычно путём взаимодействия с другими ASA по протоколу GRASP [RFC8990] или иным способом. Агент также взаимодействует с конкретными объектами (target) своей функции, используя любой подходящий механизм. Если функция агента не очень проста, ASA потребуется обрабатывать перекрывающиеся асинхронные операции. Поэтому агент может быть достаточно сложной частью программы, работающей на прикладном уровне над инфраструктурой ANI. Рекомендации по проектированию ASA приведены в [ASA-GUIDELINES].

Можно выделить по меньшей мере 3 класса агентов ASA:

  • простые ASA небольшого размера, которые могут работать где угодно;

  • сложные, возможно многопоточные ASA с высокими требованиями к ресурсам, которые работают лишь на некоторых узлах;

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

Автоматические узлы и их агенты ASA знают свои возможности и ограничения, связанные с оборудованием, микрокодом (firmware) и установленными программами, т. е. «осознают себя» (self-aware).

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

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

Поскольку агенты ASA будут взаимодействовать с ANI, они будут зависеть от соответствующих интерфейсов API2. Желательна переносимость ASA между разными операционными системами, поэтому от API требуется универсальность. Интерфейс API для протокола GRASP описан в [RFC8991]. В общем случае агенты ASA будут разрабатываться и кодироваться специалистами в конкретной технологии и варианте применения, а не специалистами в части инфраструктуры ANI и её компонентов. Кроме того, они могут представляться на разных языках программирования, в частности, на языках, поддерживающих объекты, а также традиционные переменные и структуры. При разработке API это следует учитывать.

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

Поскольку автоматические системы должны быть самовосстанавливающимися, очень важно кодировать ASA с использованием отказоустойчивых методов программирования. Все ошибки в процессе работы должны обнаруживаться с выполнением подобающих действий по восстановлению с минимальным нарушением работы, но также следует предусматривать полный перезапуск ASA. Такие ситуации, как отказы при обнаружении или согласовании должны считаться обычными, при этом ASA следует повторять отказавшую операцию, предпочтительно с экспоненциальным ростом интервала повтора в случае продолжающихся отказов. При запуске ASA в нескольких потоках, эти потоки должны отслеживаться на предмет отказов и зависаний с выполнением соответствующих действий. Следует обращать внимание на «сборку мусора», чтобы у ASA не возникало нехватки ресурсов. Участия оператора не предполагается и в худшем случае агент ASA должен быть способен самостоятельно перезапуститься.

Агенты ASA автоматически используют возможности защиты, обеспечиваемой инфраструктурой ANI, в частности ACP и GRASP. Однако в дополнение к этому агенты сами отвечают за свою защиту, особенно при взаимодействии с конкретными объектами (target) своей функции. Поэтому при разработке ASA должен выполняться анализ безопасности сверх использования защиты ANI.

6.2. Управление жизненным циклом ASA

Агенты ASA, работающие в данной инфраструктуре ANI, могут происходить от разных провайдеров и преследовать разные цели. Управлению агентами ASA и их взаимодействием с ANI следует придерживаться общих принципов работы и соответствовать базовой модели управления жизненным циклом, обеспечивающим стандартные процессы:

  • установки ASA, состоящей из копирования кода ASA на узел и его запуска;

  • развёртывания ASA, связывающего экземпляр ASA с управляемым сетевым устройством (устройствами) или функцией;

  • контроль исполнения ASA, задающий цикл управления ASA.

Жизненный цикл также определяет взаимодействия ASA с ANI в разных состояниях. Важные взаимодействия указаны ниже.

  • Самоописание экземпляров ASA в конце развёртывания, формат которого должен определять информацию, требуемую ждя управления агентами ASA со стороны ANI.

  • Контроль контура управления ASA в процессе исполнения. Сигнализация передаёт форматированные сообщения для управления исполнением ASA (по меньшей мере запуском и остановкой контура управления).

6.3. Конкретные ASA в инфраструктуре автоматической сети

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

Три первых агента (поручительство, посредник присоединения, регистратор присоединения) совместно поддерживают процесс регистрации, описанный в разделе 5. Более подробное описание дано в [RFC8995].

6.3.1. Регистрационные ASA

6.3.1.1. ASA-поручитель

Этот агент ASA включает функцию автоматического узла, который выполняет начальную загрузку в домен с помощью посредника в присоединении (join proxy ASA). Такой узел называют поручителем (pledge) в процессе регистрации. Он должен по умолчанию устанавливаться на всех узлах, которым нужна начальная загрузка без предварительной настройки (zero-touch bootstrap).

6.3.1.2. ASA-посредник присоединения

Этот агент ASA включает функцию автоматического узла, которая помогает незарегистрированным смежным устройствам зарегистрировать себя в домене. Этот агент ASA должен устанавливаться на всех узлах, хотя в локальной сети требуется лишь 1 активный посредник присоединения (см. также [RFC8995]).

6.3.1.3. ASA-регистратор присоединения

Этот агент ASA включает функцию регистратора присоединения (Join Registrar) к автоматической сети AN. Такой агент не требуется устанавливать на всех узлах, достаточно разместить его на узлах с функцией Join Registrar.

6.3.2. ACP ASA

Этот агент ASA включает функцию плоскости управления ACP в автоматической сети AN. В частности, он обнаруживает другие потенциальные узлы ACP и поддерживает организацию и разрыв каналов ACP. Этот агент ASA должен устанавливаться на всех узлах. Подробное описание приведено в параграфе 4.6 и [RFC8994].

6.3.3. ASA для распространения информации (*)

Этот агент ASA выходит за рамки работы группы ANIMA и здесь представлен лишь в качестве справки.

ASA включает функцию распространения информации в AN. В частности, он анонсирует доступность Intent и другой информации всем остальным автоматическим узлам. Этот агент не требуется устанавливать на всех узлах, достаточно разместить его на узлах, реализующих функции распространения информации (см. параграф 4.7).

Отметим, что распространение информации может быть реализовано как функция в любом агенте ASA. Более подробное описание распространения информации дано в [GRASP-DISTRIB].

7. Управление и программируемость

В этом разделе рассматривается управление и программирование AN.

7.1. Управление (частично) автоматической сетью

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

  • Автоматические функции могут применять традиционные методы и протоколы (например, SNMP и NETCONF) для выполнения задач управления внутри или вне ACP.

  • Автоматические функции могут вызывать конфликты с некоторыми традиционными методами и протоколами.

  • Традиционные функции могут использовать ACP, например, когда ещё нет доступности в плоскости данных.

Автоматические намерения (Intent) определяются на высоком уровне абстракции. Однако в силу необходимости обращения к отдельным управляемым элементам, автоматическому управлению нужны коммуникации на более низких уровнях (например, команды и запросы). Предполагается, что настройка конфигурации таких элементов будет выполняться, например, с использованием NETCONF и модулей YANG, а мониторинг – с помощью SNMP и MIB.

Конфликты могут возникать между принятым по умолчанию автоматическим поведением, автоматическими намерениями Intent и традиционными методами управления. Разрешение таких конфликтов достигается в автоматическом управлении с помощью приоритизации [RFC7575], где ручному управлению и управлению на уровне узла отдаётся более высокий приоритет. Таким образом, принятое по умолчанию автоматическое поведение имеет низший приоритет, затем следуют автоматические намерения (Intent), в высший приоритет имеют зависящие от узла методы управления, такие как использование командного интерфейса.

7.2. Намерения (*)

В текущих спецификациях реализаций Intent не рассматривается и в этом параграфе обсуждаются темы дальнейших исследований. Параграф содержит обзор Intent и способы управления намерениями. Intent и сетевое управление на основе правил (Policy-Based Network Management или PBNM) уже описаны в IETF (например, Policy Core Information Model или PCIM) и других органах стандартизации (Standards Development Organization или SDO), например, целевой группе по распределенному управлению (Distributed Management Task Force или DMTF).

Намерения (Intent) можно описать в абстрактной, декларативной политике высокого уровня, используемой для работы автоматического домена, такого как сеть предприятия [RFC7575]. Намерения следует ограничивать лишь высокоуровневыми рекомендациями, т. е. они не должны напрямую определять правила для каждого элемента сети в отдельности.

Intent можно уточнять до политики более низкого уровня с использованием различных подходов. Предполагается, что позволит приспособить намерения к возможностям управляемых устройств. Intent может содержать сведения о ролях и функциях, которые можно транслировать на конкретные узлы [RFC7575]. Одним из возможных уточнений Intent является применение правил «событие-условия-действие» (Event-Condition-Action или ECA).

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

Более подробное рассмотрение Intent приведено в [ANIMA-INTENT]. Для распространения Intent и других типов информации применяется протокол GRASP, см. [GRASP-DISTRIB].

7.3. Агрегированные отчёты (*)

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

Автоматическим сетям AN следует минимизировать вовлечение операторов. С точки зрения поведения сети это выполняется с помощью автоматических намерений Intent, предоставляемых оператором. Аналогичным образом отчётам с описанием рабочего состояния сети следует агрегировать информацию от разных элементов сети для представления эффективности исполнения Intent. Поэтому отчёты в AN следует предоставлять на уровне сети [RFC7575].

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

Отчётность в AN может использовать тот же уровень абстракции, что и Intent. В этом контексте агрегированное представление текущего состояния сети AN можно использовать для переключения в другие режимы управления. Несмотря на то, что автоматическому управлению следует минимизировать участие человека, некоторые события могут требовать участия (действий) администратора.

7.4. Контуры обратной связи с NOC (*)

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

Однонаправленные уведомления в центр управления сетью (Network Operations Center или NOC), которые не предлагают заданных по умолчанию действий и не допускают переопределения в рамках транзакции, рассматриваются подобно традиционным службам уведомления, таким как syslog. Предполагается их сосуществование с автономными методами, но этот вопрос в документе не рассматривается.

7.5. Контуры управления (*)

Контуры управления не рассматриваются в текущих спецификациях реализации и в этом разделе рассмотрены темы для дальнейших исследований.

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

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

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

7.6. API (*)

В [RFC8991] определена концептуальная схема API для протокола базовой автоматической сигнализации (GeneRic Autonomic Signaling Protocol или GRASP). Этот API разработан для взаимодействия между агентами ASA по протоколу GRASP. Полная спецификации Standards Track API не включены в текущий спецификации реализаций.

Большинство API являются статическими, что означает их предопределённость и использование инвариантных механизмов работы с данными. Автоматическим сетям AN следует иметь возможность использования динамических API в дополнение к статическим.

Динамические API извлекают данные с использованием базового механизма и затем позволяют клиенту просматривать полученные данные и работать с ними. Такие API обычно используют самоанализ и/или рефлексию. Самоанализ помогает программам проверять типы и свойства объектов в процессе работы, а рефлексия позволяет программе манипулировать атрибутами, методами и/или метаданными объекта.

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

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

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

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

7.7. Модели данных (*)

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

Определения модели данных и информационной модели адаптированы из [SUPA-DATA].

Информационная модель – это представление концепций, представляющих интерес для среды, в форме, независимой от репозитория, языка определения данных, языка запросов, языка реализации и протокола. Модель данных – это представление тех же концепций в форме, зависящей от хранилища, языка определения данных, языка запросов, языка реализации и протокола.

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

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

Модель данных важна для некоторых типов функций, таких как цикл адаптивного управления MRACL (Model-Reference Adaptive Control Loop. В более общем смысле модель данных может служить для определения объектов, атрибутов, методов и взаимоотношений программной системы (например, ANI, автоматического узла или агента ASA). Модель данных можно использовать при разработке API, а также любого языка для взаимодействия с сетью AN.

8. Координация между автоматическими функциями (*)

Координация между автоматическими функциями не включена в текущие спецификации реализаций и в этом разделе рассматриваются направления будущих исследований.

8.1. Проблема координации (*)

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

Между автоматическими функциями может быть несколько типов взаимодействия, например:

  • кооперация, когда автоматическая функция может улучшить поведение или производительность другой автоматической функции (например, функция предсказания трафика, используемая функцией распределения);

  • зависимость, когда одна автоматическая функция не может работать без наличия или доступности другой в сети AN;

  • конфликт метрических значений, когда метрика влияет на параметры других автоматических функций (т. е. один параметр устанавливается разными автоматическими функциями).

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

  • Во время сборки можно создать «статический план взаимодействий» на основе взаимосвязей функций и атрибутов. Этот план можно использовать для установки правил и задания приоритетов для выявленных конфликтов.

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

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

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

8.2. Функциональный блок координации (*)

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

Для общего функционального блока координации требуется:

  • общее описание автоматических функций, их атрибутов и жизненного цикла;

  • общее представление информации и знаний (например, план взаимодействий);

  • общий интерфейс команд (управления) между «агентом» координации и автоматическими функциями.

Могут также предоставляться руководства, рекомендации или BCP для аспектов, относящихся к стратегии и механизмам координации.

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

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

Если система имеет уязвимости в реализации или при работе (настройки), внешний атакующий может использовать такие уязвимости, чтобы стать внутренним (проникнуть в сеть).

9.1. Защита от внешних атак

Здесь предполагается, что все системы, вовлечённые в сеть AN, защищены и работают в в соответствии с текущей практикой (опытом). Методы защиты включают традиционные методы реализации и эксплуатации (такие как безопасный код, строгие алгоритмы случайных значений, надёжные пароль и т. п.), а также специфические механизмы AN (такие как защищённый сервис MASA).

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

  • защищённые от изменения;

  • аутентифицированные;

  • защищённые от replay-атак;

  • защищённые в части конфиденциальности (шифрованные).

Кроме того, протоколам AN следует быть стойкими к отбрасыванию пакетов и перехвату с участием человека (man-in-the-middle или MITM). Эти требования задаются в документах AN Standards Track, определяющих применяемые методы, в частности в [RFC8990], [RFC8994], [RFC8995].

Большинство сообщений AN передаётся в криптографически защищённой плоскости управления ACP. Незащищёнными сообщениями AN вне ACP являются лишь сообщения простого метода обнаружения, описанные в параграфе 2.5.2 [RFC8990], – сообщения DULL (Discovery Unsolicited Link-Local), для которых заданы детальные правила.

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

9.2. Риск внутренних атак

Сеть AN содержит автоматические устройства, формирующие распределенную систему с самоуправлением. Устройства в домене имеют свидетельства, полученные от общего доверенного центра (trust anchor) и могут применять их для организации взаимного доверия. Это значит, что любое устройство внутри домена доверия может по умолчанию использовать все распределенные функции во всем автоматическом домене злонамеренным способом.

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

  • Внедрение обманного устройства в домен доверия за счёт нарушения (обхода) методов проверки подлинности. Это зависит от корректности спецификации, реализации и работы протоколов AN.

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

  • Использование ещё неизвестных уязвимостей в AN или ином протоколе. Эта угроза относится к любой сети.

Указанные выше угрозы в принципе сравнимы с угрозами для других решений – при наличии ошибок в проектировании, реализации или эксплуатации невозможно гарантировать безопасность. Однако распределенная природа AN и особенно ACP значительно расширяет фронт атак. Например, взломанное устройство может иметь полную доступность по протоколу IP ко всем другим устройствам в ACP, а также применять все методы и протоколы AN.

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

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

Этот документ не запрашивает действий IANA.

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

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

[IDevID] IEEE, “IEEE Standard for Local and metropolitan area networks – Secure Device Identity”, IEEE 802.1AR, <https://1.ieee802.org/security/802-1ar>.

[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., “GeneRic Autonomic Signaling Protocol (GRASP)”, RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, “An Autonomic Control Plane (ACP)”, RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, “Bootstrapping Remote Secure Key Infrastructure (BRSKI)”, RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.

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

[ANIMA-INTENT] Du, Z., Jiang, S., Nobre, J. C., Ciavaglia, L., and M. Behringer, “ANIMA Intent Policy and Format”, Work in Progress, Internet-Draft, draft-du-anima-an-intent-05, 14 February 2017, <https://tools.ietf.org/html/draft-du-anima-an-intent-05>.

[ASA-GUIDELINES] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso, “Guidelines for Autonomic Service Agents”, Work in Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-00, 14 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-asa-guidelines-00>.

[GRASP-DISTRIB] Liu, B., Ed., Xiao, X., Ed., Hecker, A., Jiang, S., Despotovic, Z., and B. Carpenter, “Information Distribution over GRASP”, Work in Progress, Internet-Draft, draft-ietf-anima-grasp-distribution-02, 8 March 2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>.

[Meyer97] Meyer, B., “Object-Oriented Software Construction (2nd edition)”, Prentice Hall, ISBN 978-0136291558, 1997.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, “Autonomic Networking: Definitions and Design Goals”, RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, “General Gap Analysis for Autonomic Networking”, RFC 7576, DOI 10.17487/RFC7576, June 2015, <https://www.rfc-editor.org/info/rfc7576>.

[RFC8368] Eckert, T., Ed. and M. Behringer, “Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)”, RFC 8368, DOI 10.17487/RFC8368, May 2018, <https://www.rfc-editor.org/info/rfc8368>.

[RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, “GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)”, RFC 8991, DOI 10.17487/RFC8991, May 2021, <https://www.rfc-editor.org/info/rfc8991>.

[RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun, “Autonomic IPv6 Edge Prefix Management in Large-Scale Networks”, RFC 8992, DOI 10.17487/RFC8992, May 2021, <https://www.rfc-editor.org/info/rfc8992>.

[SUPA-DATA] Halpern, J. and J. Strassner, “Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)”, Work in Progress, Internet-Draft, draft-ietf-supa-generic-policy-data-model-04, 18 June 2017, <https://tools.ietf.org/html/draft-ietf-supa-generic-policy-data-model-04>.

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

Вклад в работу и отклики предоставили Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur Hecker. Полезные рецензии представили Joel Halpern, Radia Perlman, Tianran Zhou, Christian Hopps.

Участники работы

Значительный вклад в документ внесли John Strassner (Huawei), Bing Liu (Huawei), Pierre Peloso (Nokia).

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

Michael H. Behringer (editor)

Email: Michael.H.Behringer@gmail.com

Brian Carpenter

School of Computer Science

University of Auckland

PB 92019

Auckland 1142

New Zealand

Email: brian.e.carpenter@gmail.com

Toerless Eckert

Futurewei USA

2330 Central Expy

Santa Clara, CA 95050

United States of America

Email: tte+ietf@cs.fau.de

Laurent Ciavaglia

Nokia

Villarceaux

91460 Nozay

France

Email: laurent.ciavaglia@nokia.com

Jéferson Campos Nobre

Federal University of Rio Grande do Sul (UFRGS)

Av. Bento Gonçalves, 9500

Porto Alegre-RS

91501-970

Brazil

Email: jcnobre@inf.ufrgs.br


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

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

nmalykh@protokols.ru

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

2Application programming interface – интерфейс с прикладными программами.

Рубрика: 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.

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