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.

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

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

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

6.4. Передача с обновлёнными ключами

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

6.5. Приём с другими ключами

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

Поскольку пакеты, защищённые ключами из следующей фазы используют то же значение Key Phase, что и пакеты из следующей фазы, необходимо их различать, если требуется обработка пакетов, защищённых со старыми ключами. Это можно сделать по номерам пакетов. Восстановленный номер, который меньше любого из номеров текущей фазы ключей, использует прежние ключи защиты, а номер, который больше номера любого из пакетов текущей фазы, требует применения ключей защиты пакетов из следующей фазы. Нужны меры предосторожности, чтобы процесс выбора между прежними, текущими и будущими ключами защиты пакетов не создавал побочного канала синхронизации, который можно использовать для снятия защиты пакетов (см. параграф 9.5).

В качестве варианта конечные точки могут сохранять лишь два набора ключей защиты пакетов, переходя с прежнего к следующему по истечении достаточно большого времени, позволяющего учесть нарушение порядка в сети. В этом случае бит Key Phase позволяет однозначно выбрать ключи. Конечная точка может внести интервал приблизительно равный интервалу зондирования (Probe Timeout или PTO, см [QUIC-RECOVERY]) после того, как следующий набор ключей становится текущим, до создания следующего набора ключей защиты пакетов. Эти обновлённые ключи могут заменить прежние ключи в любой момент. С учётом того, что PTO является субъективной мерой (т. е. у партнёра может быть иное представление о RTT), предполагается, что этого времени будет достаточно, чтобы все разупорядоченные пакеты были сочтены партнёром потерянными, даже если они были подтверждены, и интервал будет достаточно коротким, чтобы партнёр мог запустить дальнейшее обновление ключей.

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

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

6.6. Ограничения применимости AEAD

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

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

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

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

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM предел в части конфиденциальности составляет 223 зашифрованных пакетов (см. Приложение B.1), для AEAD_CHACHA20_POLY1305 предел превышает возможное число пакетов (262) и им можно пренебречь, а для AEAD_AES_128_CCM предел составляет 221,5 зашифрованных пакетов (см. Приложение B.2). Применение ограничений снижает вероятность того, что атакующий сможет определить применяемый алгоритм AEAD от случайного изменения (см. [AEBounds], [ROBUST], [GCM-MU]).

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

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM предел в части целостности составляет 252 недействительных пакетов (см. Приложение B.1), для AEAD_CHACHA20_POLY1305 – 236 недействительных пакетов (см. [AEBounds]), а для AEAD_AES_128_CCM – 221,5 недействительных пакетов (см. Приложение B.2). Применение этих ограничений снижает вероятность успешной подделки пакетов злоумышленником (см. [AEBounds], [ROBUST], [GCM-MU]).

Конечные точки, ограничивающие размер пакетов, могут устанавливать более высокие пределы в части конфиденциальности и целостности (см. Приложение B). Будущий анализ и спецификации могут смягчить требования к ограничениям для AEAD.

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

6.7. Код ошибки при обновлении ключей

Код ошибки KEY_UPDATE_ERROR (0x0e) служит для сигнализации ошибок, связанных с обновлением ключей.

7. Защита пакетов Initial

Пакеты Initial не могут быть защищены с использованием секретного ключа, поэтому атакующий способен изменить их. QUIC обеспечивает защиту от злоумышленников, не способных читать пакеты, но не пытается предоставить дополнительную защиту от атак с возможностью наблюдения и внедрения пакетов. Некоторые из форм вмешательства, такие как изменение самих сообщений TLS, могут быть замечены, но другие, например, изменение ACK, остаются не обнаруженными. Например, атакующий может внедрить пакет с кадром ACK чтобы создать впечатление о том, что кадр не был получен или представить ложное состояние соединения (например, путём изменения ACK Delay). Отметим, что такие пакеты могут вызывать отбрасывание легитимных пакетов как дубликатов. Реализациям следует проявлять осторожность, полагаясь на данные из пакетов Initial, которые не аутентифицированы иным способом.

Злоумышленник также может подделать данные в пакетах Handshake, но такое вмешательство требует изменения сообщений согласования TLS, приводящего к отказу этого согласования.

8. Связанные с QUIC настройки TLS Handshake

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

8.1. Согласование протокола

QUIC требует, чтобы криптографическое согласование обеспечивало аутентифицированное согласование протокола. TLS использует согласование протокола прикладного уровня [ALPN] для выбора протокола приложения. Если не задан иной механизм согласования такого протокола, конечные точки должны применять ALPN. При использовании ALPN конечные точки должны немедленно закрывать соединение (см. параграф 10.2 в [QUIC-TRANSPORT]) с сигналом TLS no_application_protocol (код ошибки QUIC 0x0178, см. параграф 4.8), если прикладной протокол не согласован. Хотя [ALPN] лишь указывает, что серверы используют этот сигнал, клиенты QUIC должны по коду 0x0178 прерывать соединение в случае отказа при согласовании ALPN.

Прикладной протокол может ограничивать версии QUIC, с которыми он работает. Серверы должны выбирать протокол приложений, совместимый с выбранной клиентом версией QUIC. Сервер должен считать неспособность выбрать совместимый протокол ошибкой соединения типа 0x0178 (no_application_protocol). Клиент должен считать выбор серверов несовместимого прикладного протокола ошибкой соединения типа 0x0178.

8.2. Расширение для транспортных параметров QUIC

Транспортные параметры QUIC передаются в расширении TLS. Разные версии QUIC могут определять различные методы согласования транспортной конфигурации. Включение параметров транспорта в согласование TLS обеспечивает защиту целостности этих параметров.

      enum {
         quic_transport_parameters(0x39), (65535)
      } ExtensionType;

Поле extension_data field в расширении quic_transport_parameters содержит значение, определённое используемой версией QUIC.

Расширение quic_transport_parameters передаётся в сообщениях ClientHello и EncryptedExtensions в процессе согласования. Конечные точки должны передавать расширение quic_transport_parameters, а конечные точки, получившие сообщение ClientHello или EncryptedExtensions без quic_transport_parameters, должны закрывать соединение с ошибкой типа 0x016d (эквивалент критического сигнала TLS missing_extension, см. параграф 4.8).

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

Конечным точкам недопустимо передавать это расширение в соединениях TLS, не используемых протоколом QUIC (например, при использовании TLS с TCP [TLS13]). Поддерживающая расширение реализация должна передавать критический сигнал unsupported_extension при получении этого расширения для транспорта, отличного от QUIC.

Согласование расширения quic_transport_parameters вызывает исключение EndOfEarlyData (см. параграф 8.3).

8.3. Удаление сообщения EndOfEarlyData

Сообщение TLS EndOfEarlyData не используется с QUIC и протокол не полагается на это сообщение для маркировки завершения данных 0-RTT или сигнализации о смене ключей Handshake. Клиентам недопустимо передавать сообщение EndOfEarlyData, а сервер должен считать получение кадра CRYPTO в пакете 0-RTT ошибкой соединения типа PROTOCOL_VIOLATION.

В результате сообщение EndOfEarlyData не присутствует в согласовании TLS.

8.4. Запрет режима TLS Middlebox Compatibility

В Приложении D.4 [TLS13] описано изменение согласования TLS 1.3 для обхода ошибок некоторых промежуточных устройств. Режим совместимости с промежуточными устройствами в TLS 1.3 включает установку для поля legacy_session_id 32-байтового значения в ClientHello и ServerHello, затем передачу изменённой записи change_cipher_spec. Оба поля и запись не несут семантического содержимого и игнорируются.

Этот режим не используется в QUIC поскольку применим лишь к промежуточным устройствам, нарушающим работу TLS по протоколу TCP. QUIC также не предоставляет средств доставки записи change_cipher_spec. Клиентам недопустимо запрашивать использование режима совместимости TLS 1.3, а серверам следует считать получение TLS ClientHello с непустым полем legacy_session_id ошибкой соединения типа PROTOCOL_VIOLATION.

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

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

9.1. Связывание сессий

Использование сеансовых квитанций TLS позволяет серверами и возможно другим объектам сопоставлять соединения одного клиента (см. параграф 4.5).

9.2. Replay-атаки с 0-RTT

Как описано в разделе 8 [TLS13], использование ранних данных в TLS открывает возможность для атак с повторным использованием (replay). Использование 0-RTT в QUIC также уязвимо для replay-атак. Конечные точки должны реализовать и применять защиту от повторного использования, описанную в [TLS13], однако известно, что эта защита несовершенна, поэтому требуется дополнительное рассмотрение риска от повторного использования.

Протокол QUIC не уязвим для replay-атак за исключением данных о прикладном протоколе, которые он может нести. Управление состоянием протокола QUIC основано на типах кадров, определённых в [QUIC-TRANSPORT], и не подвержено replay-атакам. Обработка кадров QUIC идемпотентна и не может приводить к недействительным состояниям соединения в случае повторного использования, разупорядочения или потери кадров. Соединения QUIC не создают эффектов, распространяющихся за пределы срока действия соединения, за исключением тех, которые создаёт протокол приложения, обслуживаемый QUIC.

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

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

В конечном итоге ответственность за контроль рисков replay-атак с 0-RTT ложится на протокол приложения. Использующий QUIC прикладной протокол должен описывать применение 0-RTT и меры, реализуемые для защиты от replay-атак. Анализ связанных с этим рисков должен учитывать все свойства протокола QUIC, связанные с семантикой приложения.

Полное отключение 0-RTT является наиболее эффективным способом защиты от replay-атак.

Расширения QUIC должны описывать влияние replay-атак на их работу или запрещать применение расширения в 0-RTT. Прикладной протокол должен запрещать использование расширений, передающих семантику приложения в 0-RTT, или обеспечивать стратегию предотвращения повторного использования.

9.3. Ослабление атак с отражением пакетов

Небольшое сообщение ClientHello, вызывающее большой блок сообщений согласования от сервера, можно использовать для атак с отражением, усиливающих трафик от атакующего. QUIC включает три средства защиты от таких атак. Во-первых, клиент должен дополнять пакет с ClientHello до минимального размера. Во-вторых, при отклике по неизвестным адресам отправителей серверу запрещено передавать более троекратного объёма полученных данных (см. параграф 8.1 в [QUIC-TRANSPORT]). В-третьих, поскольку подтверждения пакетов Handshake аутентифицируются, при атаке вслепую их нельзя подделать. Эти меры ограничивают степень усиления трафика.

9.4. Анализ защиты заголовков

В [NAN] анализируются алгоритмы аутентифицированного шифрования, обеспечивающие конфиденциальность nonce, называемую преобразованием HN (Hide Nonce). Базовая конструкция защиты заголовков в этом документе основана на одном из таких алгоритмов (HN1). Защита заголовка применяется после защиты AEAD для пакета путём выборки набора байтов (sample) из вывода AEAD и шифрования поля заголовка с применением псевдослучайной функции PRF

   protected_field = field XOR PRF(hp_key, sample)

Варианты защиты заголовка в этом документе используют псевдослучайную перестановку (pseudorandom permutation или PRP) вместо базовой PRF. Однако, поскольку все PRP являются также PRF [IMC], эти варианты не отклоняются от конструкции HN1.

Поскольку hp_key отличается от ключа защиты пакета, защита заголовка обеспечивает уровень AE2, как определено в [NAN], и поэтому гарантирует конфиденциальность field – защищённого заголовка пакета. Будущие варианты защиты заголовка на основе этой конструкции должны использовать PRF для обеспечения эквивалентных гарантий защиты.

Использование одного ключа и выборки шифрованных данных более одного раза ставит под угрозу защиту заголовка. Защита двух разных заголовков с одним ключом и выборкой шифротекста раскрывает XOR защищённых полей. В предположении AEAD в качестве PRF и выборки L битов вероятность совпадения двух выборок шифротекста составит 2(-L/2) (birthday bound). Для алгоритмов, описанных в этом документе вероятность составляет 2-64.

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

9.5. Побочные каналы синхронизации защиты заголовка

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

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

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

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

9.6. Разнообразие ключей

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

В QUIC ключи защиты пакетов и IV выводятся с использованием иных меток, нежели для аналогичных ключей в TLS. Для сохранения такого разделения новым версиям QUIC следует задавать иные метки при создании ключей для защиты пакетов и IV, а также ключей защиты заголовков. В этой версии QUIC применяется строка quic, а другие версии могут применять взамен определяемую версией строку.

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

9.7. Случайные значения

QUIC зависит от способности конечных точек создавать безопасные случайные значения напрямую для таких параметров протокола как идентификаторы соединений и опосредованно через TLS. Рекомендации по созданию случайных чисел приведены в [RFC4086].

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

Агентство IANA зарегистрировало код 57 (0x39) для расширения quic_transport_parameters (см. параграф 8.2) в реестре TLS ExtensionType Values [TLS-REGISTRIES]. В столбце Recommended для этого расширения указано значение Yes, а столбец TLS 1.3 включает CH (ClientHello) и EE (EncryptedExtensions).

Таблица 2. Записи реестра TLS ExtensionType Values.

Значение

Имя расширения

TLS 1.3

Рекомендация

Документ

57

quic_transport_parameters

CH, EE

YY

Данный документ

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

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

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

[AES] “Advanced encryption standard (AES)”, National Institute of Standards and Technology report, DOI 10.6028/nist.fips.197, November 2001, <https://doi.org/10.6028/nist.fips.197>.

[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[CHACHA] Nir, Y. and A. Langley, “ChaCha20 and Poly1305 for IETF Protocols”, RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/info/rfc8439>.

[HKDF] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., “QUIC Loss Detection and Congestion Control”, RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.

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

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

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

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

[SHA] Dang, Q., “Secure Hash Standard”, National Institute of Standards and Technology report, DOI 10.6028/nist.fips.180-4, July 2015, <https://doi.org/10.6028/nist.fips.180-4>.

[TLS-REGISTRIES] Salowey, J. and S. Turner, “IANA Registry Updates for TLS and DTLS”, RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[TLS13] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

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

[AEBounds] Luykx, A. and K. Paterson, “Limits on Authenticated Encryption Use in TLS”, 28 August 2017, <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

[ASCII] Cerf, V., “ASCII format for network interchange”, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[CCM-ANALYSIS] Jonsson, J., “On the Security of CTR + CBC-MAC”, Selected Areas in Cryptography, SAC 2002, Lecture Notes in Computer Science, vol 2595, pp. 76-93, DOI 10.1007/3-540-36492-7_7, 2003, <https://doi.org/10.1007/3-540-36492-7_7>.

[COMPRESS] Ghedini, A. and V. Vasiliev, “TLS Certificate Compression”, RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.

[GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, “The Multi-user Security of GCM, Revisited: Tight Bounds for Nonce Randomization”, CCS ’18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018, <https://doi.org/10.1145/3243734.3243816>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, “Using Early Data in HTTP”, RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.

[HTTP2-TLS13] Benjamin, D., “Using TLS 1.3 with HTTP/2”, RFC 8740, DOI 10.17487/RFC8740, February 2020, <https://www.rfc-editor.org/info/rfc8740>.

[IMC] Katz, J. and Y. Lindell, “Introduction to Modern Cryptography, Second Edition”, ISBN 978-1466570269, 6 November 2014.

[NAN] Bellare, M., Ng, R., and B. Tackmann, “Nonces Are Noticed: AEAD Revisited”, Advances in Cryptology – CRYPTO 2019, Lecture Notes in Computer Science, vol 11692, pp. 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019, <https://doi.org/10.1007/978-3-030-26948-7_9>.

[QUIC-HTTP] Bishop, M., Ed., “Hypertext Transfer Protocol Version 3 (HTTP/3)”, Work in Progress, Internet-Draft, draft-ietf-quic-http-34, 2 February 2021, <https://tools.ietf.org/html/draft-ietf-quic-http-34>.

[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[ROBUST] Fischlin, M., Günther, F., and C. Janson, “Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3”, 16 May 2020, <https://eprint.iacr.org/2020/718>.

Приложение A. Пример защиты пакета

В этом приложении даны примеры защиты пакетов для поэтапной проверки реализаций. Определены образцы пакетов Initial для клиента и сервера, а также пакета Retry. В пакетах используется выбранное клиентом значение Destination Connection ID of 0x8394c8f03e515708. Включены также некоторые промежуточные значения. Все числа представлены в шестнадцатеричном формате.

A.1. Ключи

Ниже приведены метка, создаваемые в процессе выполнения функции HKDF-Expand-Label (т. е. HkdfLabel.label) и часть значения, переданного функции HKDF-Expand.

   client in:  00200f746c73313320636c69656e7420696e00
   server in:  00200f746c7331332073657276657220696e00
   quic key:   00100e746c7331332071756963206b657900
   quic iv:    000c0d746c733133207175696320697600
   quic hp:    00100d746c733133207175696320687000

Общий исходный секрет

   initial_secret = HKDF-Extract(initial_salt, cid)
       = 7db5df06e7a69e432496adedb0085192
         3595221596ae2ae9fb8115c1e9ed0a44

Секреты для защиты пакетов клиента

   client_initial_secret
       = HKDF-Expand-Label(initial_secret, "client in", "", 32)
       = c00cf151ca5be075ed0ebfb5c80323c4
         2d6b7db67881289af4008f1f6c357aea

   key = HKDF-Expand-Label(client_initial_secret, "quic key", "", 16)
       = 1f369613dd76d5467730efcbe3b1a22d

   iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", "", 12)
       = fa044b2f42a3fd3b46fb255c

   hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", "", 16)
       = 9f50449e04a0e810283a1e9933adedd2

Секреты для защиты пакетов сервера

   server_initial_secret
       = HKDF-Expand-Label(initial_secret, "server in", "", 32)
       = 3c199828fd139efd216c155ad844cc81
         fb82fa8d7446fa7d78be803acdda951b

   key = HKDF-Expand-Label(server_initial_secret, "quic key", "", 16)
       = cf3a5331653c364c88f0f379b6067e37

   iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", "", 12)
       = 0ac1493ca1905853b0bba03e

   hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", "", 16)
       = c206b8d9b9f0f37644430b490eeaa314

A.2. Initial от клиента

В пакете Initial от клиента незащищённая часть данных (payload) содержит показанный ниже кадр CRYPTO и кадры PADDING для увеличения размера содержимого до 1162 байтов.

   060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
   04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
   616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
   04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
   baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
   0d0010000e0403050306030203080408 050806002d00020101001c0002400100
   3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
   75300901100f088394c8f03e51570806 048000ffff

Незащищённый заголовок указывает размер 1182 байта – 4-байтовый номер пакета, 1162 байта кадров и 16-байтовый тег аутентификации. Заголовок включает идентификатор соединения и номера пакета (2)

   c300000001088394c8f03e5157080000449e00000002

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

   sample = d1b1c98dd7689fb8ec11d242b123dc9b

   mask = AES-ECB(hp, sample)[0..4]
        = 437b9aec36

   header[0] ^= mask[0] & 0x0f
        = c0
   header[18..21] ^= mask[1..4]
        = 7b9aec34
   header = c000000001088394c8f03e5157080000449e7b9aec34

Полученный в результате защищённый пакет имеет вид

   c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11
   d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399
   1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c
   8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212
   30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5
   457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208
   4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec
   4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3
   485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db
   059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c
   7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8
   9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556
   be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74
   68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a
   c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00
   f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632
   291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964
   25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd
   14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff
   ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198
   e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd
   c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73
   203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f
   cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e
   fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade
   a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047
   90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2
   162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4
   40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0
   6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e
   8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0
   be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400
   54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab
   760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9
   f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4
   056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064
   7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241
   e221af44860018ab0856972e194cd934

A.3. Initial от сервера

Сервер передаёт в ответ показанный ниже пакет, включающий кадры ACK и CRYPTO без заполнения PADDING.

   02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
   88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
   0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
   020304

Заголовок от сервера включает новый идентификатор соединения и 2-байтовый номера пакета (1)

   c1000000010008f067a5502a4262b50040750001

После защиты пакета делается выборка, начиная с третьего байта

   sample = 2cd0991cd25b0aac406a5816b6394100
   mask   = 2ec0d8356a
   header = cf000000010008f067a5502a4262b5004075c0d9

Защищённый пакет в результате имеет вид

   cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a
   5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3
   dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84
   022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4
   2158407dd074ee

A.4. Пакет Retry

Ниже показан пакет Retry, который может быть передан в ответ на пакет Initial из Приложения A.2. Защита целостности включает выбранный клиентом идентификатор соединения 0x8394c8f03e515708, но это значение не включается в окончательный пакет Retry, показанный ниже.

   ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f
   0f2496ba

A.5. Пакет с коротким заголовком ChaCha20-Poly1305

В этом примере показаны некоторые шаги, требуемые для защиты пакета с коротким заголовком. Применяется шифрование AEAD_CHACHA20_POLY1305. В примере TLS создаёт для приложения секрет записи, из которого сервер с помощью HKDF-Expand-Label создаёт 4 значения – ключ, IV, ключ защиты заголовка и секрет, применяемый после обновления ключей (это значение далее в примере не используется).

   secret
       = 9ac312a7f877468ebe69422748ad00a1
         5443f18203a07d6060f688f30f21632b

   key = HKDF-Expand-Label(secret, "quic key", "", 32)
       = c6d98ff3441c3fe1b2182094f69caa2e
         d4b716b65488960a7a984979fb23e1c8

   iv  = HKDF-Expand-Label(secret, "quic iv", "", 12)
       = e0459b3474bdd0e44a41c144

   hp  = HKDF-Expand-Label(secret, "quic hp", "", 32)
       = 25a282b9e82f06f21f488917a4fc8f1b
         73573685608597d0efcb076b0ab7a7a4

   ku  = HKDF-Expand-Label(secret, "quic ku", "", 32)
       = 1223504755036d556342ee9361d25342
         1a826c9ecdf3c7148684b36b714881f9

Ниже показаны шаги, требуемые для защиты минимального пакета с пустым полем Destination Connection ID. Этот пакет содержит один кадр PING (содержимое 0x01) и имеет номер 654360564. В примере использование номера пакета размером 3 (кодируется в 49140) позволяет избежать дополнения содержимого пакета, если же использовать более короткое представление номера, потребуются кадры PADDING.

   pn                 = 654360564 (десятичное)
   nonce              = e0459b3474bdd0e46d417eb0
   unprotected header = 4200bff4
   payload plaintext  = 01
   payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb

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

   sample = 5e5cd55c41f69080575d7999c25a5bfb
   mask   = aefefe7d03
   header = 4cfe4189

Защищённый пакет имеет минимальный возможный размер 21 байт.

   packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb

Приложение B. Анализ алгоритмов AEAD

В этом приложении описан анализ, используемый при выводе ограничений AEAD для алгоритмов AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM. В описаниях используются символы умножения (*), деления (/), возведения в степень (^) и скобки для указания порядка действий. Описания символов приведены ниже.

t

Размер тега аутентификации с битах. Для рассматриваемых шифров это 128.

n

Размер блока в битах. Для рассматриваемых шифров это 128.

k

Размер ключа в битах. Это 128 для AEAD_AES_128_GCM и AEAD_AES_128_CCM, 256 для AEAD_AES_256_GCM.

l

Число блоков в каждом пакете (см. ниже).

q

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

v

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

o

Число автономных (offline) запросов шифрования, предпринимаемых злоумышленником.

Последующий анализ основан на подсчете числа операций с блоками при создании каждого сообщения. Этот анализ выполняется для пакетов размером до 211 (l = 27) и 216 (l = 212) байтов. Предполагается, что размер 211 будет пределом для базовых вариантов развёртывания, а 216 задаёт максимальный размер пакета QUIC. Лишь точки, строго ограничивающие размер пакетов, могут использовать более высокие пределы в части целостности и конфиденциальности, выведенные для меньших размеров.

Для AEAD_AES_128_GCM и AEAD_AES_256_GCM размером сообщения (l) считается размер связанных данных в блоках с добавлением размера нешифрованных данных (plaintext) в блоках.

Для AEAD_AES_128_CCM общее число блочных операций шифрования является суммой размера связанных данных в блоках, размера шифротекста в блоках, размера открытых данных в блоках и 1. В этом анализе принимается упрощения до удвоенного размера пакета в блоках (т. е. 2l = 28 для пакетов до 211 байтов и 2l = 213 в остальных случаях). Это упрощение основано на пакетах, содержащих все связанные данные и шифротекст, что ведёт к завышению оценки числа операций для пакета на 1-3 блока.

B.1. Анализ применимости AEAD_AES_128_GCM и AEAD_AES_256_GCM

[GCM-MU] определяет конкретные границы применимости AEAD_AES_128_GCM и AEAD_AES_256_GCM при использовании в TLS 1.3 и QUIC. В этом параграфе приведён анализ в некоторыми упрощениями.

  • Число шифрованных блоков, используемых атакующим в попытках подделки, ограничено произведением v * l (число попыток подделки, умноженное на размер каждого пакета в блоках).

  • Объем работы, автономно выполняемой злоумышленником, не преобладает над другими факторами.

Ограничения в [GCM-MU] являются более жёсткими и полными по сравнению с [AEBounds], где разрешены пределы выше описанных в [TLS13].

B.1.1. Ограничение в части конфиденциальности

В части конфиденциальности теорема 4.3 в [GCM-MU] показывает, что для одного пользователя, не повторяющего значения nonce, доминирующим членом, определяющим сравнительные преимущества реального и случайного алгоритма AEAD, получаемые злоумышленником, составляют

   2 * (q * l)^2 / 2^n

Для целевого преимущества 2-57 это даёт

   q <= 2^35 / l

Таким образом, конечные точки, не передающие пакетов размером более 211 байтов, не могут защитить более 228 пакетов в одном соединении, не предоставляя атакующему преимущества выше 2-57. Для конечных точек, поддерживающих размер пакетов до 216 байтов, предел составляет 223.

B.1.2. Ограничение в части целостности

В части целостности теорема 4.3 в [GCM-MU] показывает, что атакующий получит преимущество в подделке пакетов не позднее указанного ниже числа пакетов.

   (1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n))
           + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)

Цель состоит в ограничении этого преимущества значением 2-57. Для AEAD_AES_128_GCM четвёртый член выражения доминирует над остальными, поэтому их можно исключить без существенного влияния на результат. Это даёт приближение

   v <= 2^64 / l

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

Для AEAD_AES_256_GCM в выражении доминирует тот же член, но большее значение k даёт приближение

   v <= 2^192 / l

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

B.2. Анализ применимости AEAD_AES_128_CCM

TLS [TLS13] и [AEBounds] не задают ограничений на использование AEAD_AES_128_CCM. Однако любой алгоритм AEAD, используемый с QUIC, требует ограничений, обеспечивающих сохранение конфиденциальности и целостности. В этом разделе приведён анализ этих ограничений, основанный на [CCM-ANALYSIS]. Результаты этого анализа применяются для вывода пределов применимости в соответствии с ограничениями, заданными в [TLS13].

В части конфиденциальности теорема 2 из [CCM-ANALYSIS] указывает, что атакующий получает заметное преимущество над идеальной псевдослучайной перестановкой (pseudorandom permutation или PRP) после не более чем (2l * q)2/2n пакетов.

В части целостности теорема 1 из [CCM-ANALYSIS] указывает, что атакующий получает строго большее преимуществу при том же числе пакетов. Поскольку цели получения преимуществ в части конфиденциальности и целостности совпадают, достаточно рассмотреть лишь теорему 1. Эта теорема показывает, что атакующий получает преимущество перед идеальной PRP при числе пакетов не более

   v / 2^t + (2l * (v + q))^2 / 2^n

Поскольку t и n имеют значение 128, первый член пренебрежимо мал по сравнению со вторым и его можно искл