Энциклопедия сетевых протоколов

RFC 10008 The HTTP QUERY Method

Опубликовано 18.06.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        J. Reschke
Request for Comments: 10008                                   greenbytes
Category: Standards Track                                     J.M. Snell
ISSN: 2070-1721                                               Cloudflare
                                                               M. Bishop
                                                                  Akamai
                                                               June 2026

The HTTP QUERY Method

Метод HTTP QUERY

PDF

Аннотация

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

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

Документ содержит проект стандарта Internet (Standards Track).

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

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

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

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

1. Введение

Эта спецификация определяет метод HTTP QUERY как средство создания безопасного идемпотентного запроса (раздел 9.2 в [HTTP]), содержащего представление, которое описывает, как запрос должен обрабатываться целевым ресурсом. Базовый шаблон запроса имеет вид

   GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
   Host: example.org

При большом объёме передаваемых данных их трудно закодировать в URI и этот шаблон становится проблематичным:

ограничения по размеру зачастую не известны заранее, поскольку запрос может проходить через множество несогласованных систем (отметим, что в параграфе 4.1 [HTTP] отправителям и получателям рекомендуется поддерживать запросы размером по меньшей мере 8000 октетов);
представление некоторых типов данных в целевом URI неэффективно из-за издержек, связанных с правилами кодирования данных в URI;
URI запросов заносятся в журнальные файлы с большей вероятностью, чем содержимое запроса, и могут также отображаться в закладках;
при кодировании запросов напрямую в URI каждая возможная комбинация входных данных запроса преобразуется в отдельные ресурсы.

В качестве альтернативы использованию метода GET многие реализации применяют для запросов метод HTTP POST, как показано ниже. В этом случае входные данные для операции запроса передаются как содержимое запроса, а не компоненты URI. Типичное использование метода HTTP POST для запроса имеет вид

   POST /feed HTTP/1.1
   Host: example.org
   Content-Type: application/x-www-form-urlencoded

   q=foo&limit=10&sort=-published

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

Метод QUERY предоставляет решение, устраняющее разрыв между использованием GET и POST, а приведённый выше пример можно представить как

   QUERY /feed HTTP/1.1
   Host: example.org
   Content-Type: application/x-www-form-urlencoded

   q=foo&limit=10&sort=-published

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

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

Таблица 1. Сводка свойств методов.

	GET	QUERY	POST
Безопасный	да	да	потенциально нет
Идемпотентный	да	да	потенциально нет
URI самого запроса	да (по определению)	возможно (поле отклика Location)	no
URI результата запроса	возможно (поле отклика Content-Location)	возможно (поле отклика Content-Location)	возможно (поле отклика Content-Location)
Кэширование	да	да	да, но только для будущих запросов GET или HEAD
Содержимое (тело)	нет заданной семантики	ожидается (семантика для целевого ресурса)	ожидается (семантика для целевого ресурса)

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

В этом документе применяются термины, заданные в разделе 3 [HTTP]. Кроме того, применяются термины URI query parameter для параметров в компоненте query в URI (параграф 4.2.2 в [HTTP]) и query content для содержимого запроса (параграф 6.4 в [HTTP]).

1.2. Уровни требований

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

2. Метод QUERY

Метод QUERY служит для инициирования запроса на стороне сервера. В отличие от метода GET, запрашивающего представления ресурса, указанного целевым URI (см. параграф 7.1 в [HTTP]), метод QUERY применяется для запроса у целевого ресурса выполнения операции в области действия этого целевого ресурса.

Содержимое запроса и тип носителя определяют запрос. Сервер-источник определяет область действия операции на основе целевого ресурса. Серверы должны отклонять запрос, если в нем отсутствует поле Content-Type (параграф 8.3 в [HTTP]) или это поле не соответствует содержимому запроса.

Как во всех методах HTTP, компонент query в целевом URI участвует в идентификации запрашиваемого ресурса. Непосредственное влияние этого компонента на результат запроса зависит от конкретного ресурса и не рассматривается в этой спецификации.

Запросы QUERY безопасны по отношению к целевому ресурсу (параграф 9.2.1 в [HTTP]), т. е. клиент не запрашивает и не ожидает какого-либо изменения в состоянии целевого ресурса. Это не мешает серверу создавать ресурсы HTTP, с помощью которых можно получить дополнительную информацию (см. параграфы 2.3 и 2.4). Кроме того, запросы QUERY идемпотентны (параграф 9.2.2 в [HTTP]), их можно повторять или передавать снова, например, при отказе соединения.

В соответствии с параграфом 15.3 в [HTTP], коды отклика 2xx (Successful) указывают, что запрос был получен, понят и воспринят. В частности, отклик 200 (OK) показывает, что запрос был успешно обработан и результаты этой обработки помещены в содержимое отклика.

2.1. Согласование типа носителя и содержимого

Семантика запросов QUERY зависит от содержимого запроса и связанных метаданных, таких как тип носителя ([HTTP], параграф 8.3.1). Как правило, при любой проблеме, связанной с несоответствием содержимого и метаданных, запрос должен отвергаться с кодом отклика 4xx (Client Error) (параграф 15.5 в [HTTP]). В приведённом ниже списке указаны различные варианты отказов и рекомендации по выбору кодов статуса.

Запрос без указания типа носителя некорректен по определению и должен отвергаться с возвратом кода 4xx, такого как 400 (Client Error).
Если указанный тип носителя не поддерживается ресурсом, подойдёт код 415 (Unsupported Media Type). Это относится, в частности, к случаю, когда тип носителя в принципе известен, но отсутствует семантика, относящаяся к запросу QUERY для целевого ресурса. В обоих случаях поле отклика Accept-Query (раздел 3) можно использовать для информирования клиентов о поддерживаемых типах носителей.
Если тип носителя указан, но не соответствует фактическому содержимому запроса, можно возвращать код 400 (Bad Request). Т. е. серверу не разрешается определять тип носителя по содержимому запроса, а затем переопределять отсутствующее или «ошибочное» значение (например, «анализ содержимого»).
Если тип носителя указан и понятен, содержимое соответствует типу, но запрос не может быть обработан из-за фактического содержимого, можно использовать код 422 (Unprocessable Content). Примером может служить синтаксически корректный запрос SQL к отсутствующей таблице.
Если клиент запрашивает конкретный тип носителя для отклика в поле Accept (параграф 12.5.1 в [HTTP]), но этот тип не поддерживается ресурсом, подойдёт код 406 (Not Acceptable).

2.2. Эквивалентный ресурс

Для любого данного запроса QUERY эквивалентным является ресурс, который отвечает на запросы GET, представляет этот запрос QUERY и его цель, а также воспринимает и учитывает содержимое сообщения и метаданные (раздел 6 в [HTTP]). В частности, это включает метаданные представления (раздел 8 в [HTTP]), такие как тип носителя для содержимого. Иными словами, эквивалентный ресурс выводится из ресурса, реализующего QUERY, путём включения содержимого запроса.

Термин «эквивалентный ресурс» применяется как способ определения поведения для других аспектов HTTP, таких как выбранные представления. Серверы могут, но не обязаны назначать URI таким ресурсам (см. параграф 1.1 в [URI]). Если это делается, ресурс становится доступным для запросов GET.

2.3. Поле отклика Content-Location

Отклик об успехе (2xx, параграф 15.3 в [HTTP]) может включать поле заголовка Content-Location с идентификатором ресурса, соответствующего результатам операции (см. параграф 8.7 в [HTTP]). Это представляет утверждение сервера, что клиент может направить запрос GET по указанному URI для извлечения результатов только что выполненной операции. Указанный ресурс может быть временным. Пример представлен в Приложении A.4.1.

2.4. Поле отклика Location

Сервер может назначить URI эквивалентному ресурсу (параграф 2.2) запроса QUERY. Если сервер делает это, URI такого ресурса может включаться в поле заголовка Location в отклике 2xx (см. параграф 10.2.2 в [HTTP]). Это представляет утверждение сервера, что клиент может направить запрос GET по указанному URI для повторения операции из запроса без повторной отправки содержимого. URI ресурса может быть временным и при неудаче будущего запроса клиент может повторить попытку, используя цель исходного запроса QUERY и отправленное ранее содержимое. Пример представлен в Приложении A.4.2.

2.5. Перенаправление

В некоторых случаях сервер может опосредованно отвечать на запрос QUERY, перенаправляя агент пользователя на другой URI (см. параграф 15.4 в [HTTP]).

Отклики с кодами 301 (Moved Permanently, [HTTP], параграф 15.4.2) или 308 (Permanent Redirect, [HTTP], параграф 15.4.9) указывают, что целевой ресурс перемещён на постоянной основе в другой URI, указанный в поле отклика Location ([HTTP], параграф 10.2.2). Отклики с кодом 302 (Found, [HTTP], параграф 15.4.3) и 307 (Temporary Redirect, [HTTP], параграф 15.4.8) говорят о временном переносе целевого ресурса. Во всех четырёх случаях сервер считает, что агент пользователя может выполнить исходный запрос QUERY, передав аналогичное сообщение QUERY по новому URI цели, указанному в поле Location.

Отметим, что исключения для перенаправления POST как запроса GET после отклика 301 или 302 не применяются к запросам QUERY.

Отклик на QUERY с кодом 303 (See Other, параграф 15.4.4 в [HTTP]) указывает, что исходный запрос можно выполнить с помощью обычного запроса извлечения по URI из поля Location в отклике ([HTTP], параграф 10.2.2). Для HTTP это означает отправку запроса GET по новому целевому URI, как показано в примере Приложения A.4.3.

2.6. Запросы с условиями

Выбранное представление (параграф 3.2 в [HTTP]) для запроса QUERY совпадает с представлением для запроса GET к эквивалентному ресурсу (параграф 2.2). Запрос QUERY с условиями требует, чтобы выбранное представление (т. е. результаты запроса после всех согласований содержимого) возвращалось в отклике только при условиях, указанных в соответствующих полях заголовка, как указано в разделе 13 [HTTP]. Пример представлен в Приложении A.5.

2.7. Кэширование

Отклики для метода QUERY могут кэшироваться и кэш может использоваться для выполнения последующих запросов QUERY, как указано в разделе 4 [HTTP-CACHING].

Ключ кэша для запроса QUERY (раздел 2 в [HTTP-CACHING]) должен включать содержимое запроса (раздел 6 в [HTTP-CACHING]) и соответствующие метаданные (раздел 8 в [HTTP]).

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

удаляя кодировку содержимого (параграф 8.4 в [HTTP]);
выполняя нормализацию на основе знания соглашений о преобразованиях формата, на что указывает суффикс субтипа носителя в поле Content-Type (например, «+json», см. параграф 4.2.8 в [RFC6838]);
выполняя нормализацию на основе знания семантики содержимого, указанной в поле запроса Content-Type.

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

Клиенты могут указывать нежелательность таких преобразований с использованием директивы кэширования «no-transform» (параграф 5.2.1.6 в [HTTP-CACHING]), но это будет лишь рекомендацией.

Отметим, что кэширование откликов метода QUERY по своей природе сложнее кэширования откликов на запросы GET, поскольку для определения ключа кэша требуется полное прочтение содержимого. Если в отклике на QUERY имеется поле Location (параграф 2.4) для указания URI эквивалентного ресурса (параграф 2.2), клиенты могут в следующих запросах применять метод GET для упрощения обработки.

2.8. Запросы диапазона

Семантика Range Requests для QUERY идентична семантике для GET, заданной в разделе 14 [HTTP]. Однако запросы диапазона в байтах (единственный варниант, определённый на момент создания документа) не оказывают существенного влияния на результаты запросов QUERY. Форматы запросов часто задают свой способ ограничения или разбивки результатов на страницы, например, «FETCH FIRST … ROWS ONLY» в SQL. Предполагается, что такие встроенные средства будут применяться вместо HTTP Range Requests.

3. Поле заголовка Accept-Query

Поле Accept-Query в заголовке отклика может применяться ресурсом для прямого указания поддержки метода QUERY, одновременно задавая конкретный формат запроса и типы носителя, которые могут использоваться. Accept-Query содержит список диапазонов носителей (параграф 12.5.1 в [HTTP]), используя синтаксис структурированных полей [STRUCTURED-FIELDS]. Диапазоны носителей представляются полем заголовка List Structured в виде маркеров или строк, содержащих диапазоны носителей без параметров.

При наличии параметров типа носителя они отображаются в Structured Field Parameters с типом String или Token. Выбор Token или String семантически малозначителен, т. е. получатель может преобразовать Token в String, но недопустимо обрабатывать их по-разному в зависимости от полученного типа. Типы носителей не совсем соответствуют маркерам (Token), например, они могут начинаться с цифр. В подобных случаях нужно применять формат String.

Поддерживаются лишь шаблоны */* (соответствует любому типу) и xxxx/* (соответствует любому подтипу xxxx).

Порядок типов в списке не имеет значения.

Значение поля Accept-Query применяется ко всем URI на сервере, имеющим тот же путь, иными словами, компонент query игнорируется. Если запросы к одному ресурсу возвращают разные значения Accept-Query, используется наиболее свежее из них (в соответствии с параграфом 4.2 в [HTTP-CACHING]).

Пример поля дан ниже.

   Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"

Хотя синтаксис этого поля похож на синтаксис других полей, таких как Accept (параграф 12.5.1 в [HTTP]), поле является структурированным и должно обрабатываться в соответствии с разделом 4 в [STRUCTURED-FIELDS].

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

Для метода QUERY применимы те же общие соображения безопасности, что и ко всем методам HTTP, описанным в [HTTP]. Метод можно применять как альтернативу передаче информации в URI (например, в компоненте query). В некоторых случаях это предпочтительно, поскольку URI с большей вероятностью, нежели содержимое запроса, записываются и обрабатываются посредниками. Если запрос собержит деликатные сведения, возможность записи URI в файлы журналов может служить мотивом применения QUERY вместо GET. Если сервер создаёт временный ресурс для представления результатов запроса QUERY (например, для использования в поле Location или Content-Location), назначая ему URI, а запрос содержит деликатную информацию, которую нельзя регистрировать, URI следует выбирать так, чтобы не включалась конфиденциальная часть содержимого исходного запроса.

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

Запрос QUERY от пользовательского агента, реализующего совместное использование ресурсов разных источников (Cross-Origin Resource Sharing или CORS), потребует предварительного запроса, поскольку QUERY не входит в число безопасных методов CORS (см. [FETCH]).

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

5.1. Регистрация метода QUERY

Агентство IANA добавило метод QUERY в реестр Hypertext Transfer Protocol (HTTP) Method <http://www.iana.org/assignments/http-methods> (см. параграф 16.3.1 в [HTTP]).

Таблица 2. Определение метода QUERY.

Имя метода	Безопасный	Идемпотентный	Спецификация
QUERY	да	да	раздел 2 в RFC 10008

5.2. Регистрация поля Accept-Query

Агентство IANA добавило поле Accept-Query в реестр Hypertext Transfer Protocol (HTTP) Field Name <https://www.iana.org/assignments/http-fields> (см. параграф 16.1.1 в [HTTP]).

Таблица 3. Определение поля Accept-Query.

Имя поля	Статус	Структурированный тип	Документ	Комментарии
Accept-Query	Постоянное	Список	Раздел 3 в RFC 10008

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

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

[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Semantics», STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Caching», STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.

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

[STRUCTURED-FIELDS] Nottingham, M. and P. Kamp, «Structured Field Values for HTTP», RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/info/rfc9651>.

[URI] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

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

[FETCH] WHATWG, «FETCH», WHATWG Living Standard, <https://fetch.spec.whatwg.org>. Commit snapshot: <https://fetch.spec.whatwg.org/commit-snapshots/3bab31a55154bda73f25b45a23df718616f2f64e/>.

[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, «Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)», RFC 3253, DOI 10.17487/RFC3253, March 2002, <https://www.rfc-editor.org/info/rfc3253>.

[RFC4918] Dusseault, L., Ed., «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)», RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.

[RFC5323] Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, «Web Distributed Authoring and Versioning (WebDAV) SEARCH», RFC 5323, DOI 10.17487/RFC5323, November 2008, <https://www.rfc-editor.org/info/rfc5323>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC8259] Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann, Ed., «JSONPath: Query Expressions for JSON», RFC 9535, DOI 10.17487/RFC9535, February 2024, <https://www.rfc-editor.org/info/rfc9535>.

[URL] WHATWG, «URL», WHATWG Living Standard, <https://url.spec.whatwg.org>. Commit snapshot: <https://url.spec.whatwg.org/commit-snapshots/52526653e848c5a56598c84aa4bc8ac9025fb66b/>.

[XSLT] Kay, M., Ed., «XSL Transformations (XSLT) Version 3.0», W3C Recommendation, 8 June 2017, <https://www.w3.org/TR/2017/REC-xslt-30-20170608/>. Latest version available at https://www.w3.org/TR/xslt-30/.

Приложение A. Примеры

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

В большинстве примеров применяется тип носителя application/x-www-form-urlencoded, как в запросах POST от браузеров, заданных application/x-www-form-urlencoded в [URL] (https://url.spec.whatwg.org/#application/x-www-form-urlencoded). Поля Content-Length для краткости опущены.

A.1. Простой запрос

Пример простого запроса с непосредственным откликом:

   QUERY /contacts HTTP/1.1
   Host: example.org
   Content-Type: application/x-www-form-urlencoded
   Accept: application/json

   select=surname,givenname,email&limit=10&match=%22email=*@example.*%22

Отклик

   HTTP/1.1 200 OK
   Content-Type: application/json
   [
     { "surname": "Smith",
       "givenname": "John",
       "email": "smith@example.org" },
     { "surname": "Jones",
       "givenname": "Sally",
       "email": "sally.jones@example.com" },
     { "surname": "Dubois",
       "givenname": "Camille",
       "email": "camille.dubois@example.net" }
   ]

A.2. Обнаружение поддержки QUERY

Простой способ обнаружения поддержки QUERY обеспечивает метод OPTIONS (параграф 9.3.7 в [HTTP]).

   OPTIONS /contacts HTTP/1.1
   Host: example.org

Отклик

   HTTP/1.1 200 OK
   Allow: GET, QUERY, OPTIONS, HEAD

Поле Allow в отклике (параграф 10.2.1 в [HTTP]) указывает набор поддерживаемых ресурсом методов.

Имеются и другие варианты. Например, запрос QUERY можно выполнить, не зная о поддержке метода сервером. В таком случае сервер обработает запрос или ответит с кодом статуса 4xx, таким как 405 (Method Not Allowed, параграф 15.5.6 в [HTTP]), включая в отклик поле Allow.

A.3. Обнаружение форматов QUERY

Поддерживаемые в методе QUERY типы носителей можно узнать из поля Accept-Query в отклике (раздел 3).

   HEAD /contacts HTTP/1.1
   Host: example.org

Отклик

   HTTP/1.1 200 OK
   Content-Type: application/xhtml
   Accept-Query: application/x-www-form-urlencoded, application/sql

Отклики с Accept-Query зависят от ресурса, которому направлен запрос. Другим вариантом является отправка запроса QUERY, а затем — в случае получения кода 4xx, такого как 415 (Unsupported Media Type, параграф 15.5.16 в [HTTP]), — проверка поля Accept в отклике (параграф 12.5.1 в [HTTP]):

   HTTP/1.1 415 Unsupported Media Type
   Content-Type: application/xhtml
   Accept: application/x-www-form-urlencoded, application/sql

A.4. Content-Location, Location и опосредованные отклики

Как указано в параграфах 2.3 и 2.4, поля Content-Location и Location в откликах об успехе (2xx, параграф 15.3 в [HTTP]) указывают способ идентификации дополнительных ресурсов, которые будут отвечать на запросы GET, для получения результатов запроса или будущих запросов на выполнение той же операции.

   QUERY /contacts HTTP/1.1
   Host: example.org
   Content-Type: application/x-www-form-urlencoded
   Accept: application/json

   select=surname,givenname,email&limit=10&match=%22email=*@example.*%22

Отклик

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Location: /contacts/stored-results/17
   Location: /contacts/stored-queries/42
   Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
   Date: Sun, 17 Nov 2024, 16:10:24 GMT

   [
     { "surname": "Smith",
       "givenname": "John",
       "email": "smith@example.org" },
     { "surname": "Jones",
       "givenname": "Sally",
       "email": "sally.jones@example.com" },
     { "surname": "Dubois",
       "givenname": "Camille",
       "email": "camille.dubois@example.net" }
   ]

A.4.1. Использование Content-Location

Поле Content-Location в отклике на запрос QUERY указывает ресурс, содержащий результат для этого запроса.

   GET /contacts/stored-results/17 HTTP/1.1
   Host: example.org
   Accept: application/json

Отклик

   HTTP/1.1 200 OK
   Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
   Date: Sun, 17 Nov 2024, 16:10:25 GMT

   [
     { "surname": "Smith",
       "givenname": "John",
       "email": "smith@example.org" },
     { "surname": "Jones",
       "givenname": "Sally",
       "email": "sally.jones@example.com" },
     { "surname": "Dubois",
       "givenname": "Camille",
       "email": "camille.dubois@example.net" }
   ]

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

A.4.2. Использование Location

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

   GET /contacts/stored-queries/42 HTTP/1.1
   Host: example.org
   Accept: application/json

В этом примере одна запись была удалена в момент 2024-11-17T16:12:01Z (указан в поле Last-Modified), поэтому отклик содержит лишь две записи.

   HTTP/1.1 200 OK
   Content-Type: application/json
   Last-Modified: Sun, 17 November 2024, 16:12:01 GMT
   ETag: "42-1"
   Date: Sun, 17 Nov 2024, 16:13:17 GMT

   [
     { "surname": "Smith",
       "givenname": "John",
       "email": "smith@example.org" },
     { "surname": "Dubois",
       "givenname": "Camille",
       "email": "camille.dubois@example.net" }
   ]

В предположении, что сервер по-прежнему предоставляет ресурс и результат запроса не изменился, последующий запрос GET с условием

   If-None-Match: "42-1"

возвратит код 304 (Not Modified, параграф 15.4.5 в [HTTP]).

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

Серверы могут передавать «опосредованные» отклики (параграф 2.5), используя код 303 (See Other, параграф 15.4.4 в [HTTP]). На запрос в начале параграфа A.4 сервер может ответить:

   HTTP/1.1 303 See Other
   Content-Type: text/plain
   Date: Sun, 17 Nov 2024, 16:13:17 GMT
   Location: /contacts/stored-queries/42

Сохранённый ресурс находится в /contacts/stored-queries/42. Это похоже на включение Location в прямой отклик, но результат в этом случае не возвращается. Это позволяет серверу лишь создать дополнительный ресурс или повторно использовать ранее созданный. Ресурс можно использовать, как показано в параграфе A.4.2.

A.5. Запросы с условием

Рассмотрим ресурс, реализующий QUERY с поддержкой application/sql и application/xslt+xml [XSLT] в качестве типов носителя для запроса и способный создавать отклики text/csv. Запрашивается набор данных, содержащий сведения об RFC, и возвращается информация, сгруппированная по десятилетиям.

   QUERY /rfc-index.xml HTTP/1.1
   Host: example.org
   Date: Sun, 7 Sep 2025, 00:00:00 GMT
   Content-Type: application/xslt+xml
   Accept: text/csv

   ...Содержимое запроса в XSLT...

Отклик

   HTTP/1.1 200 OK
   Date: Sun, 7 Sep 2025, 00:00:00 GMT
   Location: /stored-queries/4815162342
   Content-Type: text/csv
   Accept-Query: "application/sql", "application/xslt+xml"
   Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT
   Vary: Accept-Query, Content-Encoding, Content-Type

   decade, total, with errata, % with errata, average page count
   1960, 26, 5, 19.2, 5.3
   1970, 666, 18, 2.7, 6.1
   1980, 376, 44, 11.7, 23.4
   1990, 1593, 269, 16.9, 25.5
   2000, 2888, 1048, 36.3, 27.3
   2010, 2954, 895, 30.3, 26.1
   2020, 1133, 230, 20.3, 26.2

Сервер указал путь /stored-queries/4815162342 к эквивалентному ресурсу (параграф 2.4) для последующего запроса GET. Клиент повторяет запрос, указывая, что результаты следует возвращать лишь при их изменении

   QUERY /rfc-index.xml HTTP/1.1
   Host: example.org
   Date: Mon, 8, Sep 2025, 11:00:00 GMT
   Content-Type: application/sql
   Accept: text/csv
   If-Modified-Since: Sun, 31 Aug 2025, 08:44:00 GMT
   Vary: Accept-Query, Content-Type

   ...Тот же запрос в SQL...

Запрошенные данные не изменились, поэтому сервер возвращает:

   HTTP/1.1 304 Not Modified
   Date: Mon, 8 Sep 2025, 11:00:00 GMT
   Content-Type: text/csv
   Location: /stored-queries/4815162342
   Accept-Query: "application/sql", "application/xslt+xml"
   Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT
   Vary: Accept-Query, Content-Type

Поскольку сервер указал URI эквивалентного ресурса, к этому ресурсу можно обратиться с помощью GET. Это, в частности, избавляет от повторной передачи содержимого запроса.

   GET /stored-queries/4815162342 HTTP/1.1
   Host: example.org
   Date: Sun, 21, Sep 2025, 12:08:00 GMT
   Accept: text/csv
   If-Modified-Since: Sun, 31 Aug 2025, 00:00:00 GMT

В этом случае состояние набора данных поменялось и возвращается новое содержимое:

   HTTP/1.1 200 OK
   Date: Sun, 21, Sep 2025, 12:08:00 GMT
   Content-Type: text/csv
   Last-Modified: Thu, 18 Sep 2025, 19:56:00 GMT
   Vary: Accept-Query, Content-Encoding, Content-Type

   decade, total, with errata, % with errata, average page count
   1960, 26, 5, 19.2, 5.3
   1970, 666, 18, 2.7, 6.1
   1980, 376, 44, 11.7, 23.4
   1990, 1593, 269, 16.9, 25.5
   2000, 2888, 1048, 36.3, 27.3
   2010, 2954, 895, 30.3, 26.1
   2020, 1133, 230, 20.3, 26.2

(обратите внимание на изменение строки для этого десятилетия³).

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

Клиент                               Ресурс
|                                         |
| QUERY с содержимым                      |
+---------------------------------------->|
|                                         |
|                                  200 OK |
|                          Validator: foo |
|<----------------------------------------+ 
|                                         | 
| QUERY с содержимым                      | 
| (условие для foo)                       | 
+---------------------------------------->|
|                                         |
|                        304 Not Modified |
|                          Validator: foo |
|<----------------------------------------+ | 
|                                         | 
|                                  +--------------+  
|                                  |Смена статуса |
|                                  +--------------+ 
|                                         | 
| QUERY с содержимым                      | 
| (условие для foo)                       | 
+---------------------------------------->|
|                                         |
|                                  200 OK |
|                          Validator: bar |
|<----------------------------------------+
|                                         |

Рисунок 1. Поток данных только для QUERY.

Клиент                     Ресурс
|                               |
| QUERY с содержимым            |        Эквивалентный ресурс
+------------------------------>|              (создает /xyz)
|                               +---------------------------o
|                               |                           |
|                        200 OK |                           |
|                Validator: foo |                           |
|                Location: /xyz |                           |
|<------------------------------+                           |
|                               |                           |
| GET                                                       |
| (условие для foo)                                         |
+---------------------------------------------------------->|
|                                                           |
|                                          304 Not Modified |
|                                            Validator: foo |
|<----------------------------------------------------------+
|                                                           |
|                                                    +--------------+
|                                                    |Смена статуса |
|                                                    +--------------+
| GET                                                       |
| (условие для foo)                                         |
+---------------------------------------------------------->|
|                                                           |
|                                                    200 OK |
|                                            Validator: bar |
|<----------------------------------------------------------+
|                                                           |

Рисунок 2. Поток данных с GET к эквивалентному ресурсу.

A.6. Дополнительные форматы Query

Ниже показаны запросы к базе данных RFC errata (ошибки) в формате JSON [RFC8259]. В приведённом запросе применяется формат XSLT (eXtensible Stylesheet Language Transformations) для извлечения сводных данных об ошибках по годам и определённых типах ошибок.

   QUERY /errata.json HTTP/1.1
   Host: example.org
   Content-Type: application/xslt+xml
   Accept: application/xml, text/csv

   <transform xmlns="http://www.w3.org/1999/XSL/Transform"
     xmlns:j="http://www.w3.org/2005/xpath-functions"
     version="3.0">

     <output method="text"/>

     <param name="input"/>

     <variable name="json"
       select="json-to-xml(unparsed-text($input))"/>

     <variable name="sc">errata_status_code</variable>
     <variable name="sd">submit_date</variable>

     <template match="/">
       <text>year, total, rejected, verified, hdu, reported</text>
       <text>&#10;</text>
       <variable name="en" select="$json//j:map"/>
       <for-each-group select="$en"
         group-by="substring-before(j:string[@key=$sd],'-')">
         <sort select="current-grouping-key()"/>
         <variable name="year" select="current-grouping-key()"/>
         <variable name="errata" select=
           "$en[$year=substring-before(j:string[@key=$sd],'-')]"/>
         <value-of select="concat(
           $year,
           ', ',
           count($errata),
           ', ',
           count($errata['Rejected'=j:string[@key=$sc]]),
           ', ',
           count($errata['Verified'=j:string[@key=$sc]]),
           ', ',
           count(
             $errata['Held for Document Update'=j:string[@key=$sc]]),
           ', ',
           count($errata['Reported'=j:string[@key=$sc]]),
           '&#10;')"/>
       </for-each-group>
     </template>

   </transform>

Отклик

   HTTP/1.1 200 OK
   Content-Type: text/csv
   Accept-Query: "application/jsonpath", "application/xslt+xml"
   Date: Wed, 19 Feb 2025, 17:10:01 GMT

   year, total, rejected, verified, hdu, reported
   2000, 14, 0, 14, 0, 0
   2001, 72, 1, 70, 1, 0
   2002, 124, 8, 104, 12, 0
   2003, 63, 0, 61, 2, 0
   2004, 89, 1, 83, 5, 0
   2005, 156, 10, 96, 50, 0
   2006, 444, 54, 176, 214, 0
   2007, 429, 48, 188, 193, 0
   2008, 423, 52, 165, 206, 0
   2009, 331, 39, 148, 144, 0
   2010, 538, 80, 232, 222, 4
   2011, 367, 47, 170, 150, 0
   2012, 348, 54, 149, 145, 0
   2013, 341, 61, 169, 106, 5
   2014, 342, 73, 180, 72, 17
   2015, 343, 79, 145, 89, 30
   2016, 295, 46, 122, 82, 45
   2017, 303, 46, 120, 84, 53
   2018, 350, 61, 118, 98, 73
   2019, 335, 47, 131, 94, 63
   2020, 387, 68, 117, 123, 79
   2021, 321, 44, 148, 63, 66
   2022, 358, 37, 198, 40, 83
   2023, 262, 38, 121, 33, 70
   2024, 322, 33, 125, 23, 141
   9999, 1, 0, 0, 1, 0

Отметим, что поле отклика Accept-Query указывает поддержку и другого формата запросов — JSONPath [RFC9535]. Приведённый ниже запрос возвращает все отклонённые сообщения об ошибках с 2024 года.

   QUERY /errata.json HTTP/1.1
   Host: example.org
   Content-Type: application/jsonpath
   Accept: application/json

   $..[
        ?@.errata_status_code=="Rejected"
        && @.submit_date>"2024"
      ]
      ["doc-id"]

Отклик

   HTTP/1.1 200 OK
   Content-Type: application/json
   Accept-Query: "application/jsonpath", "application/xslt+xml"
   Date: Thu, 20 Feb 2025, 09:55:42 GMT
   Last-Modified: Thu, 20 Feb 2025 06:10:01 GMT

   [
     "RFC1185","RFC8407","RFC6350","RFC8467","RFC1157","RFC9543",
     "RFC9076","RFC7656","RFC2822","RFC9460","RFC2104","RFC6797",
     "RFC9499","RFC9557","RFC2131","RFC2328","RFC9001","RFC3325",
     "RFC9438","RFC2526","RFC2985","RFC7643","RFC9132","RFC6376",
     "RFC9110","RFC9460","RFC7748","RFC9497","RFC8463","RFC4035",
     "RFC7239","RFC9083","RFC9537","RFC9537","RFC9420","RFC9000",
     "RFC9656","RFC9110","RFC2324","RFC2549","RFC6797","RFC2549",
     "RFC8894"
   ]

Приложение B. Выбор имени метода QUERY

В реестре Hypertext Transfer Protocol (HTTP) Method Registry (<http://www.iana.org/assignments/http-methods>) уже имеются три других метода со свойствами безопасности (safe) и идемпотентности (idempotent): PROPFIND [RFC4918], REPORT [RFC3253] и SEARCH [RFC5323]. Можно было бы использовать любой из них, обновив в соответствии с тем, что в данной спецификации определено как новый метод QUERY. И действительно, на ранних этапах этой спецификации использовался метод SEARCH.

Название метода QUERY в конечном счёте было выбрано по нескольким причинам:

в других вариантах применяется базовый тип носителя для содержимого запроса (application/xml), а семантика запроса зависит лишь от его содержимого;
все отмеченные выше методы основаны на действиях WebDAV, по поводу чего у многих возникают смешанные чувства;
имя QUERY чётко отражает связь с компонентом URI query.

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

Спасибо всем членам рабочей группы HTTP за их идеи, рецензии и отклики. Отдельной благодарности заслуживают Carsten Bormann, Mark Nottingham, Martin Thomson, Michael Thornburgh, Roberto Polli, Roy Fielding и Will Hawkins.

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

Ashok Malhotra участвовал в ранних обсуждениях, приведших к этой спецификации.

Ashok Malhotra

Email: malhotrasahib@gmail.com

Обсуждение этого метода HTTP было возобновлено Asbjørn Ulsberg на HTTP Workshop в 2019 году.

Asbjørn Ulsberg

Email: asbjorn@ulsberg.no

URI: https://asbjor.nu/

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

Julian Reschke

greenbytes GmbH

Hafenweg 16

48155 Münster

Germany

Email: julian.reschke@greenbytes.de

URI: https://greenbytes.de/tech/webdav/

James M Snell

Cloudflare

Email: jasnell@gmail.com

Mike Bishop

Akamai

Email: mbishop@evequefou.be

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

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

nmalykh@protokols.ru

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

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

3По видимому в оригинале допущена ошибка, т. к. наборы строк в обоих примерах не отличаются. Прим. перев.

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

RFC 9958 Post-Quantum Cryptography for Engineers

Опубликовано 12.06.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                       A. Banerjee
Request for Comments: 9958                                    T. Reddy.K
Category: Informational                                 D. Schoinianakis
ISSN: 2070-1721                                                    Nokia
                                                            T. Hollebeek
                                                                DigiCert
                                                            M. Ounsworth
                                                                 Entrust
                                                               June 2026

Post-Quantum Cryptography for Engineers

Пост-квантовая криптография для инженеров

PDF

Аннотация

Появление криптографически значимого квантового компьютера (cryptographically relevant quantum computer или CRQC) сделало бы устаревшими современные традиционные алгоритмы с открытым ключом, поскольку лежащие в их основе математические допущения утратили бы актуальность. Для решения проблемы протоколы и инфраструктура должны перейти на пост-квантовые алгоритмы, разработанные для противостояния как традиционным, так и квантовым атакам. В этом документе объясняется, почему инженерам нужно знать и понимать пост-квантовую криптографию (post-quantum cryptography или PQC), а также подробно описывается влияние CRQC на имеющиеся системы и рассматриваются задачи, связанные с переходом к пост-квантовым алгоритмам. В отличие от прежних обновлений криптографии, этот переход может потребовать существенной переработки протоколов из-за уникальных свойств пост-квантовых алгоритмов.

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

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус стандартов (см. раздел 2 в RFC 7841).

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

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

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

1. Введение

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

Один из распространённых мифов заключается в том, что квантовые компьютеры быстрее традиционных CPU и GPU во всех сферах применения. Однако это не совсем верно — как GPU превосходят традиционные CPU при решении определённых задач, так и у квантовых компьютеров есть своя ниша, где они преуспевают. К сожалению для криптографов, задачи разложения простых чисел на сомножители (факторизация) и нахождения дискретных логарифмов, лежащие в основе традиционной криптографии с отрытым ключом, попадают в ту сферу вычислений, где ожидается успех квантовых компьютеров. По мере развития квантовых технологий появляется возможность значительного влияния квантовых компьютеров на современные криптографические системы. Предсказание времени появления CRQC является сложной задачей и сохраняется неопределённость по срокам их практической доступности [CRQCThreat].

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

Криптографию PQC иногда называют квантово-стойкой (quantum-proof), квантово-безопасной (quantum-safe), или квантово-резистентной (quantum-resistant). Она включает разработку криптографических алгоритмов для защиты коммуникаций и данных в мире, где квантовые компьютеры достаточно мощны, чтобы взламывать традиционные криптосистемы, такие как RSA (Rivest-Shamir-Adleman) и ECC (Elliptic Curve Cryptography). Алгоритмы PQC предназначены для защиты от атак квантовых компьютеров, использующих квантово-механические эффекты для решения математических задач, невыполнимых для традиционных компьютеров.

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

Цель этого документа состоит в предоставлении базовых рекомендаций инженерам, связанным с криптографическими библиотеками, безопасностью сетей и развитием инфраструктуры, где долгосрочное планирование защиты имеет решающее значение. Документ охватывает такие темы, как выбор подходящих алгоритмов PQC и понимание различий между механизмами инкапсуляции ключей (Key Encapsulation Mechanism или KEM) в PQC и традиционных обменах Диффи-Хеллмана (DH) и RSA, а также приводятся сведения о предполагаемых различиях размеров ключей, шифротекстов, подписей и времени обработки в PQC и традиционных алгоритмах. Обсуждаются также угрозы со стороны CRQC для симметричной криптографии и хэш-функций.

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

Агентство национальной безопасности США (National Security Agency или NSA) опубликовало статью о будущих требованиях к алгоритму PQC для систем национальной безопасности США [CNSA2-0], основанную на необходимости защиты от внедрения в будущем CRQC. Федеральное ведомство информационной безопасности Германии (Federal Office for Information Security или BSI) также выпустило документ по переходу на PQC и рекомендации [BSI-PQC], в значительной степени соответствующие руководству Национального института стандартов и технологий США (National Institute of Standards and Technology или NIST) и NSA, но отличающиеся в конкретных профилях алгоритма PQC.

CRQC представляют угрозу как для симметричных, так и для асимметричных криптосистем. Однако угроза для асимметричной криптографии значительно выше из-за алгоритма Шора [Shors], позволяющего взломать широко применяемые системы с открытым ключом, такие как RSA и ECC. Для симметричной криптографии и хэш-функций риск из-за алгоритма Гровера [Grovers] ниже, воздействие менее серьёзно и обычно может быть смягчено за счёт удвоения размеров ключей и дайджестов там, где имеются риски. Читателю важно понимать, что упоминание в этом документе PQC относится к асимметричной криптографии (криптографии с открытым ключом), а не к каким-либо симметричным алгоритмам на основе потоковых и блочных шифров, хэш-функциям, кодам аутентификации сообщений (Message Authentication Code или MAC) и т. п., которые менее уязвимы для квантовых компьютеров. В документе не рассматриваются случаи, когда традиционные алгоритмы могут стать уязвимыми (см. [QC-DNS] и другие документы).

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

Документ не содержит подробных математических или технических спецификаций алгоритмов PQC, а скорее предоставляет инженерам обзор текущей ситуации с угрозами и алгоритмов, разработанных для предотвращения таких угроз. Криптографические и алгоритмические рекомендации этого документа не следует считать правомочными, если они противоречат новым рекомендациям исследовательской группы Crypto Forum (CFRG).

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

Quantum computer — квантовый компьютер

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

Physical qubit — физический кубит

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

Logical qubit — логический кубит

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

Post-Quantum Cryptography (PQC) — пост-квантовая криптография

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

Cryptographically Relevant Quantum Computer (CRQC) — криптографически значимый квантовый компьютер

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

Public Key Cryptography (Asymmetric Cryptography) — криптография с открытым ключом

Класс криптоалгоритмов, где применяются разные ключи для шифрования и расшифровки или подписания и проверки подписи. В этом документе термины Public Key Cryptography и Asymmetric Cryptography являются синонимами.

Продолжаются дискуссии об использовании терминов post-quantum, quantum ready, quantum resistant, quantum secure для описания алгоритмов, способных противостоять CRQC, и согласия пока не достигнуто. В NIST термин post-quantum применяется для алгоритмов, участвовавших в конкурсе на выбор кандидата. В этом контексте термин можно интерпретировать как «набор алгоритмов, разработанных так, чтобы сохранить их пригодность после появления квантовых компьютеров», а не как заявление об их безопасности. Термин quantum resistant или quantum secure, очевидно, указывает свойство алгоритмов, однако высказываются опасения, что указание класса алгоритмов как «квантово-стойкого» или «квантово-безопасного» может привести к путанице, если какой-либо из таких алгоритмов потом окажется менее стойким или безопасным, чем предсказывала теория. Термин quantum ready часто обозначает решение (устройство, комплекс, программный стек), достигшее зрелости в плане интеграции новых криптографических алгоритмов. Авторы отмечают значительную вариативность использования терминов, которые в данном документе являются взаимозаменяемыми при обсуждении алгоритмов.

Термины «текущий» (current), «современный» (state-of-the-art), «будущий» (ongoing) относятся к работам, исследованиям, внедрениям или разработкам на момент публикации документа.

3. Угроза криптографии со стороны CRQC

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

Квантовые компьютеры по своей природе являются гибридом классических и квантовых вычислительных блоков. Например, алгоритм Шора включает комбинацию квантовых и классических расчётов. Таким образом, термин «квантовый противник» (quantum adversary) следует понимать как «противник с квантовым усилением» (quantum-enhanced adversary), что означает наличие у него доступа к квантовым и классическим методам расчётов.

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

3.1. Симметричная криптография

Для неструктурированных данных, таких как зашифрованные с симметричным ключом или криптографические хэш-значения, CRQC хотя и могут искать конкретные решения для всех возможных входных комбинаций (например, алгоритм Гровера), неизвестно ни одного квантового алгоритма для нарушения базовых свойств безопасности этих классов алгоритмов. Симметричная криптография, включающая примитивы с ключами, такие как блочные шифры (например, AES) и механизмы аутентификации сообщений (например, HMAC-SHA256), основана на секретных ключах, известных отправителю и получателю и остающихся безопасными даже в пост-квантовом мире. Симметричная криптография включает также функции хэширования (например, SHA-256), применяемые для защищённого создания дайджестов сообщений без использования общего ключевого материала. Хэшированный код аутентификации сообщения (Hashed Message Authentication Code или HMAC) — это специальная конструкция, использующая для создания кода проверки подлинности сообщения криптографическую хэш-функцию и секретный ключ, известный отправителю и получателю.

Алгоритм Гровера — это квантовый алгоритм поиска, теоретически обеспечивающий квадратичное ускорение поиска в неструктурированных базах данных по сравнению с традиционными алгоритмами поиска. Он привёл к распространённому заблуждению о необходимости удвоения размера симметричных ключей для обеспечения квантовой безопасности. Если рассматривать сопоставление хэш-значений со входными данными (известными как прообраз — pre-image) или шифротекста с соответствующими блоками открытого текста как базу данных без структуры, алгоритм Гровера теоретически требует удвоения размера ключей симметричных алгоритмов по сравнению с используемыми на момент публикации, чтобы скомпенсировать квадратичное ускорение и сохранить текущий уровень безопасности. Это связано с тем, что алгоритм Гровера сокращает число операций, требуемых для взлома 128-битовой симметричной криптографии до 2^64 квантовых операций, что может казаться достижимым. Однако квантовые операции принципиально отличаются от классических и 2^64 классических операций можно выполнять параллельно, а 2^64 должны выполняться последовательно, что делает нереальной реализацию на практически доступных квантовых компьютерах.

Алгоритм Гровера слабо распараллеливается и даже при параллельном развёртывании 2^c вычислительных блоков для подбора ключа (brute-force) время выполнения будет пропорционально 2^((128-c)/2). Проще говоря, использование 256 квантовых компьютеров сократит время перебора лишь в 16 раз, а 1024 квантовых компьютеров обеспечат 32-кратное ускорение и т. д. (см. [NIST] и [Cloudflare]). По общему мнению экспертов это сохранит безопасность AES-128 на практике и удваивать размер ключей не потребуется.

Возникает естественный вопрос о возможности разработки более совершенного алгоритма, который превзойдёт алгоритм Гровера в общем случае. Christof Zalka показал, что алгоритм Гровера обеспечивает наилучшую возможную сложность для этого типа поиска, значит существенного ускорения квантового подхода не следует ожидать [Grover-Search].

NIST в критериях оценки PQC сравнивает уровни безопасности предложенных пост-квантовых алгоритмов с традиционной и квантовой безопасностью AES-128, AES-192 и AES-256. Это показывает уверенность NIST в стабильности защитных свойств AES даже при наличии классических и квантовых атак. Таким образом, 128-битовые алгоритмы можно считать квантово-безопасными в обозримом будущем. Однако в целях соблюдения требований некоторые организации, например, Французское национальное агентство по безопасности информационных систем (French National Agency for the Security of Information Systems или ANSSI) [ANSSI] и Агентство национальной безопасности США (National Security Agency или NSA) (CNSA 2.0) [CNSA2-0], рекомендуют использовать AES-256.

3.2. Асимметричная криптография

Алгоритм Шора эффективно решает задачу разложения целых чисел на сомножители (факторизация) и связанную с ней задачу дискретного логарифма, которые являются основой большинства современных криптографических методов с открытым ключом. Это означает, что в случае создания CRQC современные алгоритмы и протоколы с открытым ключом (например, RSA, Diffie-Hellman, ECC и менее известные варианты, такие как подписи ElGamal [RFC6090] и Schnorr [RFC8235]) должны быть заменены алгоритмами и протоколами, устойчивыми к криптоанализу с использованием CRQC³. Исследования показывают, что при наличии CRQC можно взломать RSA-2048 за часы или даже секунды в зависимости от допущений о коррекции ошибок [RSAShor] [RSA8HRS] [RSA10SC]. Хотя пока такие машины доступны лишь в теории, это говорит о потенциальной уязвимости RSA при появлении CRQC.

Для структурированных данных, таких как открытые ключи и подписи, CRQC могут полностью решать базовые сложные задачи традиционной криптографии (см. алгоритм Шора). Поскольку увеличение размера ключевых пар не обеспечит безопасного решения (за исключением мультигигабайтных ключей RSA [PQRSA]), потребуется полная замена алгоритмов. Поэтому пост-квантовая криптография с открытым ключом должна основываться на иных принципах, нежели применяются в традиционной криптографии с открытым ключом (разложение целых чисел на сомножители, дискретный логарифм над конечным полем и дискретный алгоритм для эллиптической кривой).

3.3. Квантовые атаки по побочным каналам

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

4. Традиционные примитивы, которые могут быть заменены PQC

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

Согласование и доставка ключей

Схемы согласования ключей по методу Диффи-Хеллмана (Diffie-Hellman или DH) или DH с эллиптической кривой (Elliptic Curve Diffie-Hellman или ECDH), а также доставка ключей (обычно с использованием шифрования RSA) служат для организации общего криптографического ключа для защищённого взаимодействия. Эти механизмы могут быть заменены PQC, поскольку они основаны на существующей асимметричной криптографии и поэтому уязвимы для алгоритма Шора. CRQC может применять алгоритм Шора для эффективного поиска простых сомножителей длинного открытого ключа (в случае RSA), который можно использовать для раскрытия общего секрета. В случае DH компьютер CRQC потенциально способен вычислить дискретный логарифм открытого ключа DH (краткосрочного или долгосрочного), что раскроет секрет, требуемый для вывода симметричного ключа шифрования.

Цифровые подписи

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

Подписи Boneh-Boyen-Shacham (BBS)

Подписи BBS обеспечивают сохранение приватности (конфиденциальности) со свойствами, подобными доказательствам без разглашения (zero-knowledge proof), что позволяет выборочно раскрывать конкретные подписанные атрибуты без раскрытия всего набора подписанных данных. Безопасность подписей BBS основана на сложности задачи дискретного логарифма, что делает их уязвимыми для алгоритма Шора. CRQC может нарушить безопасность аутентификации BBS, но не конфиденциальность данных (параграф 6.9 в [BBS-SIG-SCHEME]).

Шифрование содержимого

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

5. Алгоритмы NIST PQC

На момент написания этого документа в NIST были стандартизованы 3 алгоритма PQC и предполагается стандартизация в будущем ещё большего их числа (см. [NISTFINAL]). Эти алгоритмы не обязательно будут заменой традиционным алгоритмам асимметричной криптографии, например, RSA [RSA] и ECC [RFC6090] могут применяться как в качестве KEM, так и для подписей, тогда как в настоящее время нет пост-квантовых алгоритмов, способных выполнять сразу обе функции. При обновлении протоколов важно заменить имеющиеся традиционные алгоритмы на PQC KEM или подписи PQC в зависимости от прежнего использования традиционного алгоритма. Кроме того, KEM, как указано в разделе 9, предоставляет API, отличный от примитивов создания или доставки ключей. В результате для включения новых алгоритмов могут потребоваться изменения на уровне протоколов или приложений.

5.1. Выбранные NIST кандидаты для стандартизации

5.1.1. Механизмы инкапсуляции ключей PQC KEM

ML-KEM

Инкапсуляция ключей на основе модульной решётки (Module-Lattice-Based Key-Encapsulation), FIPS 203 [ML-KEM].

HQC

Квазициклический код Хэмминга (Hamming Quasi-Cyclic) [HQC]. Алгоритм кодирования, основанный на сложности декодирования синдрома для квазициклической конкатенации кодов Reed-Muller и Reed-Solomon (RMRS) в метрике Хэмминга. Коды Рида-Мюллера (RM) — это класс блочных кодов корректировки ошибок, широко применяемый в беспроводных и космических коммуникациях, а коды Рида-Соломона широко используются для обнаружения и корректировки многобитовых ошибок. Алгоритм HQC выбран в рамках проекта NIST по пост-квантовой криптографии, но ещё не стандартизован.

5.1.2. Подписи PQC

ML-DSA

Цифровые подписи на основе модульной решётки (Module-Lattice-Based Digital Signature), FIPS 204 [ML-DSA].

SLH-DSA

Основанный на хэшировании алгоритм цифровой подписи без учёта состояний (Stateless Hash-Based Digital Signature), FIPS 205 [SLH-DSA].

FN-DSA

Алгоритм цифровой подписи с быстрым преобразованием Фурье с использованием решётки NTRU (Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm) [FN-DSA]. Отметим, что в NIST этот алгоритм называется FN-DSA, а его спецификация — FIPS 206, но на момент публикации этого документа спецификация ещё не была выпущена.

Дополнительные сведения приведены в параграфах 8.1, 8.2 и 10.2.

6. Выбранные ISO кандидаты для стандартизации

На момент написания этого документа в ISO было выбрано 3 алгоритма PQC KEM в качестве кандидатов в стандарты.

6.1. Механизмы инкапсуляции ключей PQC (KEM)

FrodoKEM

Алгоритм KEM, основанный на сложности обучения в алгебраически неструктурированных решётках [FrodoKEM].

ClassicMcEliece

Алгоритм KEM, основанный на сложности декодирования синдрома кодов Goppa — класса кодов, способных исправить некоторое число ошибок в передаваемом сообщении. Декодирование заключается в восстановлении исходного сообщения из принятого кодового слова с шумами [ClassicMcEliece].

NTRU

Алгоритм KEM, основанный на решётках усечённых полиномиальных колец степени N (N-th degree Truncated polynomial Ring Units или NTRU). Вариантом этого алгоритма является Streamlined NTRU Prime (sntrup761), применяемый в SSH [RFC9941]. См. [NTRU].

7. Сроки перехода

Сроки и мотивы перехода несколько различаются для конфиденциальности (например, шифрование) и аутентификации (например, подписи). В части конфиденциальности данных важны атаки со сбором и последующим дешифрованием данных (harvest now, decrypt later или HNDL), где злоумышленник с достаточными ресурсами может организовать сбор конфиденциальных шифрованных данных в надежде расшифровать их при появлении CRQC. Это означает, что в любой момент зашифрованные конфиденциальные данные уязвимы для атак из-за отсутствия квантово-безопасных стратегий, поскольку эти данные могут быть расшифрованы в будущем. В части аутентификации срок между подписанием и проверкой подписи зачастую очень краток (например, время согласования TLS), но в некоторых случаях (например, подписи микрокода или программ) срок действия подписи может быть большим (десятилетия), а сроки действия подписей в юридических документах и встроенных сертификатах устройств (например, смарт-карт) могут быть ещё больше. Даже для краткосрочных подписей инфраструктура часто полагается на долгосрочные корневые ключи, которые может быть сложно обновить или заменить на устройствах в полевых условиях.

+------------------------+----------------------------+
|                        |                            |
|           y            |             x              |
+------------------------+----------+-----------------+
|                                   | <--------------->
|               z                   |   Security gap
+-----------------------------------+

Рисунок 1. Модель Mosca.

Эти проблемы прекрасно иллюстрирует так называемая модель Моска (Mosca) рассмотренная в [Threat-Report]. На рисунке 1 «x» показывает время, в течение которого системы и данные должны оставаться безопасными, «y» — число лет на полный переход к инфраструктуре PQC, а «z» — время, в течение которого появится CRQC для взлома текущей криптографии. Модель предполагает либо перехват и сохранение зашифрованных данных до перехода через y лет, либо использование подписей в течение x лет после создания. Эти данные остаются уязвимыми в течение всех x лет своего жизненного цикла, а сумма x+y даёт оценку всего интервала времени, в течение которого данные остаются незащищёнными. По сути, модель задаёт вопрос о том, как подготовить системы ИТ в течение этих y лет (иными словами, как минимизировать y) для сокращения этапа перехода к инфраструктуре PQC и минимизации рисков раскрытия данных в будущем.

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

Организациям следует тщательно и честно оценивать своё время перехода y. Если учитывать лишь время между получением исправлений от поставщика технологии и их внедрением, может показаться, что y составляет лишь несколько недель. Однако это относится лишь к достаточно редким вариантам перехода и чаще переход на PQC будет включать, как минимум, замену некоторой части оборудования. Например, чувствительным к производительности приложениям потребуются CPU с аппаратным ускорением PQC. Чувствительным к безопасности приложениям потребуются PQC TPM, среды доверенного исполнения (Trusted Execution Environment или TEE), защищённые анклавы и другие криптографические сопроцессоры. Приложениям, работающим со смарт-картами потребуется замена карт и считывателей, которые могут применяться в разных вариантах — для входных дверей и турникетов, ввода PIN-кодов, ноутбуков и т. п.

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

Организациям, отвечающим за защиту долгосрочных конфиденциальных данных или работу критической инфраструктуры, потребуется начать переход незамедлительно, особенно при уязвимости данных к HNDL-атакам. Гибридные схемы PQ/T (Post-quantum and traditional, раздел 13) или PQ для обмена ключами сравнительно самодостаточны и обычно требуют лишь замены криптобиблиотеки (например, OpenSSL). Для цифровых подписей переход на PQ или PQ/T включает значительные изменения экосистемы, в том числе обновление сертификатов, удостоверяющих центов (CA), протоколов управления сертификатами, HSM, привязок доверия. Начав заранее внедрение гибридного обмена ключами, организация сможет получить опыт работы, а прототипирование и планирование интеграции цифровых подписей PQ/T или PQ поможет выявить воздействия на всю экосистему. Такой поэтапный подход снижает долгосрочные риски при переходе и обеспечивает готовность к более сложным обновлениям.

8. Категории PQC

Стандартизованные NIST схемы пост-квантовой криптографии можно разделить на 3 основных группы: основанные на решётках, основанные на хэшировании и основанные на коде. В рамках исследований и стандартизации изучаются также схемы на основе изогении, многомерная криптография и криптография на основе MPC-in-the-Head. Кроме того, NIST принимает дополнительные предложения по цифровым подписям для расширения набора оцениваемых вариантов [AddSig].

8.1. Криптография с открытым ключом на основе решёток

В криптографии с открытым ключом на основе решётки применяется простая конструкция из регулярного набора равномерно распределенных точек в пространстве Евклида (решётка) для создания ловушек (trapdoor). Эти задачи решаются эффективно при наличии секретных данных, но требуют сложных расчётов в ином случае. Примерами таких задач являются поиск кратчайшего и ближайшего вектора, поиск короткого целочисленного решения, обучение при наличии ошибок (включая модульное), решение задачи с округлением. Для всех таких задач имеются убедительные доказательства сведения наихудшей ситуации к средней (worst-to-average), эффективно сопоставляющего сложность худшего случая со сложностью среднего.

Открытые ключи и подписи на основе решётки длиннее классических схем, таких как RSA и ECC, но обычно менее чем на порядок для открытых ключей (6-10 раз) и на 1-2 порядка (10-100 раз) для подписей, что делает их наилучшими кандидатами для общего назначения, например, в качестве замены RSA в сертификатах PKIX. Примеры алгоритмов этого класса включают ML-KEM, FN-DSA, ML-DSA, FrodoKEM.

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

В криптоанализе оракулом (oracle) называют систему, к которой злоумышленник может обратиться с вопросом, удалось ли расшифровать данные. Наличие такого оракула поможет злоумышленнику значительно понизить уровень безопасности основанных на решётках схем, имеющих сравнительно высокую частоту отказов. Однако, как показано в [LattFail1], для большинства предложений NIST PQC число запросов к оракулу, требуемых для принудительного сбоя расшифровки, превышает практические возможности. Недавние исследования улучшили результат [LattFail1], показав, что издержки поиска дополнительных сбойных шифротекстов после нахождения 1 или 2 могут быть значительно увеличены [LattFail2]. Тем не менее, на момент публикации этого документа кандидаты NIST для PQC считались защищёнными от таких атак и проводился постоянный мониторинг по мере криптоаналитических исследований.

8.2. Криптография с открытым ключом на основе хэширования

Криптография с открытым ключом на основе хэша (Hash-based Public Key Cryptography или Hash-based PKC) существует с 1970-х годов, когда она была разработана Лэмпортом (Lamport) и Мерклом (Merkle). Метод служит для создания алгоритмов цифровой подписи и основывается на безопасности базовой криптографической хэш-функции. С 1970-х годов разработано много вариантов подписей на основе хэша (hash-based signature или HBS), включая недавние схемы XMSS [RFC8391], HSS/LMS [RFC8554], BPQS [BPQS]. В отличие от многих других методов цифровой подписи, большинство подписей HBS учитывают состояние, что означает обновление и тщательное обследование секретного ключа для создания подписи. Создание нескольких подписей с одним секретным ключом ведёт к потере безопасности и может приводить к атакам с подделкой подписи.

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

Алгоритм SLH-DSA, стандартизованный NIST, использует метод HORST (Hash to Obtain Random Subset with Trees) и является единственным стандартизованным вариантом подписи на основе хэша без учёта состояния, что позволяет избежать сложностей, связанных с поддержкой состояний. SLH-DSA является усовершенствованным вариантом SPHINCS, уменьшающим размер подписей SPHINCS и делающим их более компактными.

8.3. Криптография с открытым ключом на основе кода

Это направление криптографии зародилось в 1970-80-х годах на основе фундаментальной работы Макэлиса (McEliece) и Нидеррайтера (Niederreiter), сосредоточенной на изучении криптосистем на основе кодов с корректировкой ошибок. Популярные коды с корректировкой ошибок включают коды Goppa (применяются в криптосистемах McEliece), коды синдрома кодирования и декодирования, используемые в HQC, квазициклические коды с умеренной частотой проверки ошибок чётности (quasi-cyclic moderate density parity check или QC-MDPC).

В качестве примеров можно привести все невзломанные коды, достигшие финала в четвёртом раунде NIST: Classic McEliece, HQC (выбран NIST для стандартизации), инкапсуляция ключа с обращением битов (Bit Flipping Key Encapsulation или BIKE) [BIKE].

9. KEM

Механизм инкапсуляции ключей (Key Encapsulation Mechanism или KEM) — это криптографический метод защищённого обмена симметричным ключом между двумя сторонами по незащищённому каналу. Он обычно применяется в схемах с гибридным шифрованием, где используется сочетание асимметричного (с открытым ключом) и симметричного шифрования. Операция KEM даёт в результате симметричный ключ фиксированного размера, который может применяться с симметричным алгоритмом (обычно, блочный шифр) одним из двух способов:

для получения ключа шифрования данных (data encryption key или DEK);
для получения ключа шифрования ключей (key encryption key или KEK), служащего для «оборачивания» DEK.

Эти методы часто называют гибридным шифрованием с открытым ключом (Hybrid Public Key Encryption или HPKE) [RFC9180].

Термин «инкапсуляция» выбран преднамеренно, чтобы указать поведение алгоритмов KEM на уровне API, отличающееся от согласования ключей и передачи шифрованных ключей, применяемых сегодня. Схемы согласования ключей предполагают, что обе стороны применяют пару из секретного и открытого ключа при обмене, а доставка шифрованного ключа предполагает выбор симметричного ключа одной стороной и его «шифрования» или «оборачивания» для другой стороны. Схемы KEM используют показанные ниже примитивы API [PQCAPI]:

def kemKeyGen() -> (pk, sk)
def kemEncaps(pk) -> (ss, ct)
def kemDecaps(ct, sk) -> ss

где pk обозначает открытый ключ, sk — секретный, ct — шифротекст, представляющий инкапсулированный ключ, а ss — общий секрет. На рисунке 2 показан пример обмена ключами на основе KEM.

                      +---------+ +---------+
                      | Клиент  | | Сервер  |
                      +---------+ +---------+
  +----------------------+ |           |
  | pk, sk = kemKeyGen() |-|           |
  +----------------------+ |           |
                           |           |
                           | pk        |
                           |---------->|
                           |           | +-----------------------+
                           |           |-| ss, ct = kemEncaps(pk)|
                           |           | +-----------------------+
                           |           |
                           |       ct  |
                           |<----------|
+------------------------+ |           |
| ss = kemDecaps(ct, sk) |-|           |
+------------------------+ |           |
                           |           |

Рисунок 2. Обмен ключами на основе KEM.

9.1. Обмен ключами с аутентификацией

Аутентифицированный обмен ключами (Authenticated Key Exchange или AKE) с KEM, где обе стороны вносят открытый ключ KEM в общий сеансовый ключ, является интерактивным, как описано в параграфе 9.4 [RFC9528]. Однако односторонний метод KEM, когда один партнёр имеет ключ KEM в сертификате, а другой хочет зашифровать ключ (как в почте S/MIME или OpenPGP), можно реализовать с помощью неинтерактивного HPKE [RFC9180]. На рисунке 3 показан обмен ключами DH.

                      +---------+ +---------+
                      | Клиент  | | Сервер  |
                      +---------+ +---------+
  +-----------------------+ |           |
  | Долгосрочный ключ     | |           |
  | клиента sk1, pk1      |-|           |
  +-----------------------+ |           |
                            |           |
                            | pk1       |
                            |---------->|
                            |           | +------------------------+
                            |           |-| Долгосрочный ключ      |
                            |           | | сервера sk2, pk2       |
                            |           | | ss = KeyEx(pk1, sk2)   |
                            |           | +------------------------+
                            |           |
                            |        pk2|
                            |<----------|
+-------------------------+ |           |
| ss = KeyEx(pk2, sk1)    | |           |
|  encryptContent(ss)     |-|           |
+-------------------------+ |           |
                            |шифрованное|
                            |содержимое |
                            |---------->|
                            |           | +------------------------+
                            |           | | decryptContent(ss)     |
                            |           | +------------------------+

Рисунок 3. AKE на основе DH.

Важно отметить, что в примере выше общий секрет ss выводится из ключевого материала от клиента и сервера, что относит метод к числу AKE. Имеется вариант неинтерактивного обмена ключами (Non-Interactive Key Exchange или NIKE), где отправитель может рассчитать общий секрет ss и шифровать содержимое без активного взаимодействия (обмен сообщениями через сеть) с получателем. На рисунке 3 показан обмен DH, который является AKE, поскольку обе стороны применяют долгосрочные ключи, позволяющие установить доверие (например, через сертификаты), но это не NIKE, поскольку клиент должен дождаться сетевого взаимодействия для получения открытого ключа получателя pk2, прежде чем рассчитать общий секрет ss и начать шифровать содержимое. Однако обмен DH может быть сразу AKE и NIKE, если открытый ключ получателя заранее известен отправителю (см. рисунок 4), и многие протоколы Internet полагаются на это свойство обмена ключами DH.

                    +---------+ +---------+
                    | Клиент  | | Сервер  |
                    +---------+ +---------+
+-----------------------+ |           |
| Долгосрочный ключ     | |           |
| клиента sk1, pk1      |-|           |
| Долгосрочный ключ     | |           |
| сервера pk2           | |           |
| ss = KeyEx(pk2, sk1)  | |           |
|  encryptContent(ss)   |-|           |
+-----------------------+ |           |
                          |           |
                          | pk1,      |
                          |шифрованное|
                          |содержимое |
                          |---------->|
                          |           | +------------------------+
                          |           |-|Долгосрочный ключ севера|
                          |           | |         sk2, pk2       |
                          |           | | ss = KeyEx(pk1, sk2)   |
                          |           | |  decryptContent(ss)    |
                          |           | +------------------------+

Рисунок 4. AKE на основе DH вместе с NIKE.

Сложность KEM заключается в недетерминированности функции Encaps(), которая включает случайность, выбранную отправителем сообщения. Поэтому для выполнения AKE клиент должен ждать, пока сервер сгенерирует требуемую случайность и выполнит Encaps() с ключом клиента, на что потребуется круговой обход через сеть (round-trip). Поэтому основанный на KEM протокол может быть AKE или NIKE, но не тем и другим сразу. Это требует заново проектировать некоторые протоколы Internet с учётом различия, добавлять круговые обходы или компромиссы в части безопасности.

                        +---------+ +---------+
                        | Клиент  | | Сервер  |
                        +---------+ +---------+
  +------------------------+ |           |
  | pk1, sk1 = kemKeyGen() |-|           |
  +------------------------+ |           |
                             |           |
                             |pk1        |
                             |---------->|
                             |           | +--------------------------+
                             |           |-| ss1, ct1 = kemEncaps(pk1)|
                             |           | | pk2, sk2 = kemKeyGen()   |
                             |           | +--------------------------+
                             |           |
                             |    ct1,pk2|
                             |<----------|
+--------------------------+ |           |
| ss1 = kemDecaps(ct1, sk1)| |           |
| ss2, ct2 = kemEncaps(pk2)|-|           |
| ss = Combiner(ss1, ss2)  | |           |
+--------------------------+ |           |
                             |           |
                             |ct2        |
                             |---------->|
                             |           | +--------------------------+
                             |           |-| ss2 = kemDecaps(ct2, sk2)|
                             |           | | ss = Combiner(ss1, ss2)  |
                             |           | +--------------------------+

Рисунок 5. AKE на основе KEM.

На рисунке выше Combiner(ss1, ss2), часто называемый объединителем KEM, — это криптографическая конструкция, принимающая два общих секрета, и возвращающая комбинированный общий секрет. Простейшим объединителем является конкатенация ss1 || ss2, но объединители могут быть разной сложности в зависимости от требуемых криптографических свойств. Например, если комбинации следует сохранять IND-CCA2 (см. параграф 9.2.1) для любых входных данных даже при злонамеренном выборе, потребуется более сложная конструкция. Ещё одним соображением при разработке объединителя являются так называемые свойства привязки (binding properties) из [KEEPINGUP], которые могут требовать включения шифротекста и открытого ключа получателя. Анализ безопасности объединителя KEM усложняется в гибридных вариантах, где два KEM представляют разные алгоритмы, например, ML-KEM и ECDH. Более подробное обсуждение объединителей KEM представлено в [KEEPINGUP], [KEM-COMBINER] и [PQ-KEM].

9.2. Безопасность KEM

Описываемые здесь свойства безопасности (IND-CCA2 и привязка) не охватывают все аспекты безопасности KEM. Они просто являются основополагающими для оценки пригодности KEM в протоколах и часто обсуждаются в работах PQC.

9.2.1. IND-CCA2

IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack⁴) — это новая концепция безопасности для схем шифрования. Это гарантирует конфиденциальность открытого текста и устойчивость к атакам с выбранным шифротекстом. Определение IND-CCA2 для методов KEM приведено в [CS01] и [BHK09]. ML-KEM [ML-KEM] и Classic McEliece обеспечивают безопасность IND-CCA2.

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

9.2.2. Привязка

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

Решение задачи привязки, как правило, достигается на уровне разработки протокола. Рекомендуется избегать использования выходного секрета KEM напрямую, без интеграции в соответствующий протокол. Хотя алгоритмы KEM обеспечивают секретность ключа, они по своей природе не обеспчивают подлинность источника, защиту от атак с воспроизведением и гарантию свежести. Эти защитные свойства следует обеспечивать встраиванием KEM в протокол, который проанализирован в части такой защиты. Хотя современные реализации KEM, такие как ML-KEM, обеспечивают достаточную энтропию общих секретов, из соображений привязки рекомендуется передавать общий секрет через функцию KDF, а также включать все значения, которые нужно привязать. В итоге будет получен общий секрет, который можно безопасно применять на уровне протокола.

9.3. HPKE

В современной криптографии уже давно используется термин «гибридное шифрование», где применяется асимметричный алгоритм для организации ключа и симметричный — для шифрования основного объёма содержимого. В предыдущих параграфах разъяснялись важные свойства безопасности KEM, такие как IND-CCA2 и привязка, с подчёркиванием необходимости поддержки этих свойств при разработке протоколов. Одной из широко распространённых схем реализации этого является гибридное шифрование с открытым ключом (Hybrid Public Key Encryption или HPKE) [RFC9180].

HPKE [RFC9180] работает в сочетании со схемами KEM, KDF и аутентифицированным шифрованием со связанными данными (Authenticated Encryption with Associated Data или AEAD). HPKE включает три варианта аутентификации и один из них подтверждает владение заранее распространенным ключом, а два необязательных — владение секретным ключом KEM. HPKE можно расширить для поддержки гибридных пост-квантовых KEM [PQ-HPKE]. ML-KEM не поддерживает обмен статическими эфемерными ключами, позволяющий применять HPKE на основе метода KEM DH и его необязательные режимы проверки подлинности, как описано в параграфе 1.5 [X-WING].

10. Подписи PQC

Любая схема цифровой подписи, определяющая безопасность в пост-квантовых условиях, попадает в категорию подписей PQC.

10.1. Безопасность подписей PQC

10.1.1. EUF-CMA и SUF-CMA

EUF-CMA (экзистенциальная непроницаемость при атаке на выбранное сообщение) [GMR88] — это понятие безопасности для схем цифровой подписи, гарантирующее, что злоумышленник даже при наличии доступа к оракулу подписей не сможет подделать подпись произвольного сообщения. EUF-CMA обеспечивает строгую защиту от атак с подделкой, гарантируя целостность и подлинность цифровых подписей за счёт предотвращения несанкционированных изменений и подделки. Методы ML-DSA, FN-DSA и SLH-DSA обеспечивают защиту EUF-CMA.

SUF-CMA (строгая непроницаемость при атаке на выбранное сообщение) строится на основе EUF-CMA, требуя, чтобы злоумышленник не мог создать другую действительную подпись для сообщения, которое уже подписано оракулом. Как и EUF-CMA, SUF-CMA обеспечивает надёжные гарантии для схем цифровой подписи, дополнительно повышая их безопасность. ML-DSA, FN-DSA и SLH-DSA обеспечивают защиту SUF-CMA.

Понимание защиты EUF-CMA и SUF-CMA важно для разработки и реализации криптографических схем, обеспечивающих безопасность, надёжность и отказоустойчиволсть цифровых подписей. Это позволяет принимать обоснованные решения, анализировать уязвимости, соблюдать стандарты и разрабатывать системы, обеспечивающие надёжную защиту от атак с подделками. Для разработчиков, переходящих на проверенные IETF схемы подписи PQC в рамках данного протокола или потока, глубокого понимания EUF-CMA и SUF-CMA может не потребоваться, поскольку проверенные IETF схемы уже соответствуют этим строгим стандартам безопасности.

EUF-CMA и SUF-CMA считаются строгими показателями безопасности для алгоритмов цифровой подписи с открытым ключом, делая их подходящими для большинства приложений. Авторам спецификаций IETF следует включать все вопросы безопасности в соответствующий раздел RFC, не полагаясь на уровень знания криптографии разработчиками.

10.2. Детали FN-DSA, ML-DSA, SLH-DSA

Алгоритм цифровой подписи ML-DSA [ML-DSA] основан на сложности задач решёток над модульными решётками, т. е. проблемы модульного обучения с ошибками (Module Learning with Errors или MLWE). Алгоритм основан на предложенной Любашевским модели Фиат-Шамир с прерываниями (Fiat-Shamir with Aborts) [Lyu09], где применяется выборка с отбрасыванием для обеспечения компактности и безопасности основанных на решётках схем Fiat-Shamir (FS). В ML-DSA применяются случайные выборки с однородным распределением из небольших целых чисел для расчёта коэффициентов в векторах ошибок, что упрощает реализацию схемы по сравнению с FN-DSA [FN-DSA], где применяются числа с гауссовым распределением, что требует использования при генерации подписи арифметики с плавающей запятой.

ML-DSA предлагает как детерминированные, так и рандомизированные подписи и реализован с тремя наборами параметров, обеспечивающими разные уровни безопасности. Свойства безопасности ML-DSA рассмотрены в разделе 9 [RFC9881].

Алгоритм FN-DSA [FN-DSA] основан на схеме с решётками подписи GPV (Gentry, Peikert, Vaikuntanathan), где сначала выполняется хэширование (hash-and-sign) и требуется применение некого класса решёток и метода ловушек.

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

При реализации FN-DSA требуется учитывать, что подписание FN-DSA сильно подвержено атакам по побочным каналам, если не применяются 64-битовые операции с плавающей запятой. Это требование зависит от платформы, как указано в отчёте NIST [NIST].

Параметры производительности ML-DSA и FN-DSA могут различаться в зависимости от реализации и аппаратной платформы. В общем случае для ML-DSA характерна сравнительно высокая скорость создания подписей, а для FN-DSA — более эффективная проверка подписей. Выбор может зависеть от потребности приложения в создании и проверке подписей (см. [LIBOQS]). Более подробные сведения о размерах и уровнях безопасности приведены в таблицах разделов 11 и 12.

В SLH-DSA [SLH-DSA] применяется концепция подписей на основе хэширования без учёта состояния, где каждая подпись уникальна и не связана с предшествующими подписями (см. параграф 8.2). Это избавляет от необходимости поддержки данных состояния в процессе подписания. Алгоритм SLH-DSA разработан для подписания до 2^64 сообщений с одной парой ключей и обеспечивает три уровня безопасности. Параметры каждого уровня выбраны так, чтобы обеспечивалась защита в 128, 192 и 256 битов. SLH-DSA обеспечивает меньшие размеры ключей, большие размеры подписей, более медленное создание и проверку подписей по сравнению с ML-DSA и FN-DSA. В SLH-DSA нет новых допущений о стойкости, помимо принятых для базовых хэш-функций. Алгоритм основан на устоявшейся криптографии, что делает его надёжным и отказоустойчивым решением для цифровых подписей в пост-квантовом мире.

Все эти алгоритмы (ML-DSA, FN-DSA, SLH-DSA) включают два режима подписи — чистый, где напрямую подписывается все содержимое сообщения, и режим предварительного хэширования, где подписывается не содержимое, а дайджест.

10.3. Детали XMSS и LMS

Расширенная схема подписи Меркла (eXtended Merkle Signature Scheme или XMSS) [RFC8391] и иерархическая схема (Hierarchical Signature Scheme или HSS) / подпись Лейтона-Микали (Leighton-Micali Signature или LMS) [RFC8554] — это схемы подписи на основе хэширования с учётом состояния, где состояние секретного ключа меняется со временем. В обеих схемах повторное использование состояния ключа ставит под угрозу гарантии криптографической защиты.

XMSS и LMS можно применять для подписания потенциально большого, но фиксированного числа сообщений, а число операций при подписании зависит от размера дерева. Оба метода обеспечивают криптографические цифровые подписи, не полагаясь на сложность математических задач, а используя свойства криптографических хэш-функций. XMSS и LMS с множеством деревьев (XMSS-MT и HSS, соответственно) используют иерархический подход на основе гипер-деревьев с деревом Меркла на каждом уровне иерархии. В [RFC8391] описаны варианты XMSS с одним и множеством деревьев, а в [RFC8554] описана система однократных подписей Лейтона-Микали (Leighton-Micali One-Time Signature или LM-OTS), а также системы N-кратных подписей LMS и HSS. Сравнение XMSS и LMS приведено в разделе 10 [RFC8554].

Число уровней дерева в XMSS и HSS с множеством деревьев обеспечивает компромисс между размером подписи и скоростью создания ключа и подписи. При увеличении числа уровней время генерации ключа и подписи снижается экспоненциально за счёт линейного роста размера подписи. HSS позволяет настраивать каждое субдерево, а XMSS-MT не делает этого, используя одну структуру для каждого субдерева.

Из-за описанных выше сложностей XMSS и LMS не подходят на замену традиционным алгоритмам подписи, таким как RSA или ECDSA. Типичными примерами приложений, для которых подходят эти методы, являются долгосрочные подписи, например для обновлений микрокода или безопасной загрузки.

10.3.1. Размеры ключей и подписей LMS

Схема LMS характеризуется наборами четырёх параметров: базовая хэш-функция (SHA2-256 или SHAKE-256), размер дайджеста (24 или 32 байта), высота дерева LMS, определяющая максимальное число подписей, создаваемых с секретным ключом, и ширина коэффициента Winternitz (параграф 4.1 в [RFC8554]). Эти параметры можно использовать для выбора компромисса между скоростью и размером подписи. Разные комбинации позволяют создать 80 вариантов схемы.

Размеры открытого (PK) и секретного (SK) ключа зависят от длины дайджеста (M), размер подписи зависит от дайджеста, параметра Winternitz (W), высоты дерева LMS (H) и длины дайджеста. В таблице 1 приведены размеры ключа и подписи для дайджеста с M=32.

Таблица 1.

PK	SK	W	H=5	H=10	H=15	H=20	H=25
56	52	1	8684	8844	9004	9164	9324
56	52	2	4460	4620	4780	4940	5100
56	52	4	2348	2508	2668	2828	2988
56	52	8	1292	1452	1612	1772	1932

10.4. Хэширование, затем подпись

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

Использование хэш-функции для создания дайджеста с фиксированным размером обеспечивает совместимость подписей с широким спектром систем и протоколов, независимо от размера и формата конкретного сообщения. Этот метод значительно сокращает объем данных, передаваемых и обрабатываемых аппаратными модулями защиты (Hardware Security Module или HSM). Рассмотрим сценарий, где сетевой модуль HSM вынесен в другой ЦОД по отношению к вызывающим приложениям и смарт-картам, подключённым через USB. В таких случаях потоковая передача сообщений размером в мегабайты или гигабайты может сталкиваться с большими задержками в сети, задержками при подписании на устройстве и даже нехваткой памяти на устройстве.

Отметим, что подавляющее большинство протоколов Internet с подписью больших сообщений уже применяет то или иное хэширование на уровне протокола, поэтому данный метод предназначен в основном для фирменных крипто-протоколов и протоколов, принятых другими органами стандартизации (не IETF). Такие протоколы, как TLS 1.3 и DNSSEC используют парадигму hash-then-sign. В сообщениях TLS 1.3 [RFC8446] CertificateVerify учтённое в подписи содержимое включает вывод хеша «стенограммы» (transcript) (параграф 4.4.1 в [RFC8446]), а DNSSEC [RFC4034] использует его для аутентификации источника и обеспечения целостности данных DNS. Синтаксис криптографических сообщений (Cryptographic Message Syntax или CMS) [RFC5652] включает обязательный этап создания дайджеста сообщения перед вызовом алгоритма подписи.

ML-DSA включает внутренние операции хэширования как часть алгоритма подписи. ML-DSA принимает исходное сообщение, применяет внутреннюю хэш-функцию и использует результат хэширования для процесса создания подписи. SLH-DSA выполняет внутреннее рандомизированное сжатие сообщения с применением хэш-функции с ключом, которая может обрабатывать сообщения произвольного размера. В FN-DSA применяется функция хэширования SHAKE-256 как часть процесса для создания дайджеста подписываемого сообщения.

Таким образом, ML-DSA, FN-DSA и SLH-DSA обеспечивают защиту, усиленную по сравнению с традиционной парадигмой hash-then-sign, поскольку, благодаря встраиванию динамического ключевого материала в дайджест сообщения, конфликты значений предварительного хэширования больше не приводят к поддельным подписям. Приложения, которым нужна производительность и экономия пропускной способности, могут по-прежнему применять предварительное хэширование на уровне протокола до вызова ML-DSA, FN-DSA или SLH-DSA, но разработчикам протоколов следует понимать, что это возвращает уязвимость, из-за которой конфликты хэш-значений позволяют подделать подпись. Если для приложения это подходит, рекомендуется подписывать полное сообщение, а не дайджест.

11. Рекомендации NIST в части безопасности и производительности

Здесь представлена перепечатка информации из проекта NIST PQC [NIST] на момент публикации этого документа. В таблице 2 приведены 5 уровней безопасности, предложенных NIST для алгоритмов PQC. Ни NIST, ни IETF не дают конкретных рекомендаций по выбору уровня для использования. В общем случае протоколы будут включать алгоритмы нескольких уровней, чтобы пользователи могли выбрать уровень, соответствующий их политике и степени конфиденциальности (секретности) данных, подобно тому, как сегодня выбирается размер ключей RSA. Уровни защиты определены по расчётным издержкам, сравнимым или превышающим затраты на атаки алгоритмов AES (128, 192, 256) и SHA2/SHA3, т. е. полное восстановление ключа для AES и поиск оптимальных коллизий для SHA2/SHA3.

Таблица 2.

Уровень безопасности PQ	Стойкость AES/SHA(2/3)	Алгоритм PQC
1	AES-128 (полное восстановление ключа)	ML-KEM-512, FN-DSA-512, SLH-DSA-SHA2/SHAKE-128f/s
2	SHA-256/SHA3-256 (поиск коллизий)	ML-DSA-44
3	AES-192 (полное восстановление ключа)	ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2/SHAKE-192f/s
4	SHA-384/SHA3-384 (поиск коллизий)	На этом уровне алгоритм не тестировался
5	AES-256 (полное восстановление ключа)	ML-KEM-1024, FN-DSA-1024, ML-DSA-87, SLH-DSA-SHA2/SHAKE-256f/s

Для SLH-DSA-x-yf/s значение x указывает базовую хэш-функцию (SHAKE или SHA-2), f означает быструю, а s — малую версию бита y для AES. Алгоритмы SLH-DSA подробно описаны в [RFC9814].

В таблице 3 приведено сравнение размеров подписей для разных категорий алгоритмов SLH-DSA с эквивалентным уровнем безопасности при использовании «простой» версии. Категории включают f для быстрого создания подписей и s для малого размера подписи и быстрой проверки при более медленном создании подписи. Варианты параметров SHA-256 и SHAKE-256 дают одинаковый размер подписи поэтому указаны в таблице вместе.

Таблица 3.

Уровень безопасности PQ	Алгоритм	Открытый ключ (в байтах)	Секретный ключ (в байтах)	Подпись (в байтах)
1	SLH-DSA-{SHA2,SHAKE}-128f	32	64	17088
1	SLH-DSA-{SHA2,SHAKE}-128s	32	64	7856
3	SLH-DSA-{SHA2,SHAKE}-192f	48	96	35664
3	SLH-DSA-{SHA2,SHAKE}-192s	48	96	16224
5	SLH-DSA-{SHA2,SHAKE}-256f	64	128	49856
5	SLH-DSA-{SHA2,SHAKE}-256s	64	128	29792

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

Таблица 4.

Уровень безопасности PQ	Алгоритм	Открытый ключ (в байтах)	Секретный ключ (в байтах)	Шифротекст/Подпись (в байтах)
1	ML-KEM-512	800	1632	768
1	FN-DSA-512	897	1281	666
2	ML-DSA-44	1312	2560	2420
3	ML-KEM-768	1184	2400	1088
3	ML-DSA-65	1952	4032	3309
5	FN-DSA-1024	1793	2305	1280
5	ML-KEM-1024	1568	3168	1588
5	ML-DSA-87	2592	4896	4627

12. Сравнение PQC KEM и подписей с традиционными

В этом разделе представлены две таблицы для сравнений KEM и подписей в традиционных и пост-квантовых сценариях. В таблицах приведены размеры секретных и открытых ключей, а также шифротекста/подписей для алгоритмов PQC и их традиционных аналогов с похожими уровнями безопасности.

В таблице 5 сравниваются традиционные и PQC методы KEM по уровням безопасности, размерам ключей и шифротекста.

Таблица 5.

Уровень безопасности PQ	Алгоритм	Открытый ключ (в байтах)	Секретный ключ (в байтах)	Шифротекст (в байтах)
Традиционный	P256_HKDF_SHA-256	65	32	65
Традиционный	P521_HKDF_SHA-512	133	66	133
Традиционный	X25519_HKDF_SHA-256	32	32	32
1	ML-KEM-512	800	1632	768
3	ML-KEM-768	1184	2400	1088
5	ML-KEM-1024	1568	3168	1568

В таблице 6 сравниваются традиционные и PQC схемы подписи по уровням безопасности, размерам ключей и подписи.

Таблица 6.

Уровень безопасности PQ	Алгоритм	Открытый ключ (в байтах)	Секретный ключ (в байтах)	Подпись (в байтах)
Традиционный	RSA2048	256	256	256
Традиционный	ECDSA-P256	64	32	64
1	FN-DSA-512	897	1281	666
2	ML-DSA-44	1312	2560	2420
3	ML-DSA-65	1952	4032	3309
5	FN-DSA-1024	1793	2305	1280
5	ML-DSA-87	2592	4896	4627

Как видно из приведённых таблиц, PQC KEM и схемы подписи обычно имеют существенно более длинные ключи и подписи/шифротекст по сравнению с традиционными. Этот рост размеров может создавать проблемы для протоколов. Например, протокол обмена ключами IKEv2 (Internet Key Exchange Protocol Version 2) использует для передачи сообщений транспортный протокол UDP. Одна из проблем интеграции PQC KEM в IKEv2 заключается в невозможности фрагментации IKE при начальном обмене IKE_SA_INIT. Для решения этой проблемы в [RFC9242] предложено определить новый обмен (Intermediate Exchange), который можно фрагментировать с помощью соответствующего механизма IKE. В [RFC9370] это для обмена ключами PQC после начального обмена IKEv2 и до IKE_AUTH. Другой пример из параграфа 6.3.3 в [SP-1800-38C] показывает, что рост размеров ключей и подписей вызывает разделение сообщений протокола обмена ключами на несколько пакетов, что повышает вероятность потерь в пересчёте на пакет. В сетях с высокими потерями это может увеличить длительность обмена ключами.

13. Гибридные схемы (PQ/T)

Переход на PQC является уникальным событием в истории цифровой криптографии в том смысле, что ни традиционным, ни пост-квантовым алгоритмам нельзя полностью доверять в плане защиты данных в течение требуемого срока. Традиционные алгоритмы, такие как RSA и ECDH, будут взломаны квантовым криптоанализом, а пост-квантовые столкнутся с неопределённостью лежащей в их основе математики, проблемами соответствия требованиям, неизвестными пока уязвимостями, а также оборудованием и программами, которые не вполне готовы в плане защиты от традиционных криптоаналитических атак и ошибок реализации. В процессе перехода от традиционных алгоритмов к пост-квантовым может возникнуть потребность или необходимость использования сразу обоих типов алгоритмов. Терминология для гибридных схем PQ/T описана в [RFC9794].

13.1. Конфиденциальность PQ/T

Свойство гибридной конфиденциальности PQ/T может применяться для смягчения атак «harvest now, decrypt now» (собрать и расшифровать) и HNDL, описанных в разделе 7. Если в PQ был дефект, традиционный алгоритм (T), защищённый от современных злоумышленников, предотвратит немедленную расшифровку. Если алгоритм T будет взломан CRQC, PQ (при условии сохранения защищенности) предотвратит последующую расшифровку (т. е. HNDL). Таким образом, гибридная конструкция обеспечивает конфиденциальность, пока хотя бы один из компонентов остаётся защищённым. Ниже рассматриваются две схемы согласования ключей.

Гибридное согласование ключей с конкатенацией

Финальный общий секрет, который будет служить входными данными для функции получения ключа, является конкатенацией секретов, созданных каждой из схем согласования ключей. Например, в [TLS-HYB-KEY-EXCH] клиент использует расширение поддерживаемых TLS групп для анонсирования поддержки гибридной схемы PQ/T и сервер может выбрать группу, если он поддерживает эту схему. Клиент и сервер с поддержкой гибридной схемы устанавливают общий секрет в форме конкатенации двух общих секретов и применяют его в имеющемся расписании ключей TLS 1.3.

Каскадное гибридное согласование ключей

Финальный общий секрет рассчитывается путём множества итераций функции вывода ключей, где число итераций совпадает с количеством схем согласования ключей в гибридной схеме. Например, в [RFC9370] задано расширение IKEv2, позволяющее добавить один или несколько алгоритмов PQC к традиционному алгоритму для получения финальных ключей IKE Security Association (SA) с использованием каскадирования, описанного в параграфе 2.2.2 [RFC9370].

Были исследованы различные варианты этих гибридных схем согласования ключей. При выборе гибридной схемы следует проявлять осторожность. Выбранная схема для таких протоколов, как TLS 1.3 [TLS-HYB-KEY-EXCH] обладает отказоустойчивостью IND-CCA2, т. е. безопасность IND-CCA2 гарантируется для схемы, пока хотя бы один из применяемых в ней алгоритмов сохраняет защищенность IND-CCA2.

13.2. Аутентификация PQ/T

Свойство гибридной аутентификации PQ/T обеспечивает устойчивость к катастрофическим взломам или непредвиденным уязвимостям в алгоритмах PQC, предоставляя системам дополнительное время для стабилизации перед полным переходом к работе в среде PQ.

Это свойство гарантирует работу схемы гибридной аутентификации PQ/T, пока хотя бы из алгоритмов остаётся безопасным. Например, может применяться гибридный сертификат PQ/T [ML-DSA-X.509] для упрощения протокола гибридной аутентификации PQ/T. Однако протоколу гибридной аутентификации PQ/T не обязательно использовать гибридный сертификат PQ/T и можно воспользоваться разными сертификатами для отдельных алгоритмов [RFC9763]. При использовании раздельных сертификатов злоумышленники могут отделить один от другого или собрать воедино неожиданным способом, включая кросс-протокольные атаки. Конкретные риски в таких ситуациях сильно зависят от протокола и варианта применения, поэтому нужен полный анализ безопасности. Рекомендации по обеспечению надлежащего использования пар сертификатов приведены в параграфах 13.3.2 и 13.3.3.

Требуется тщательно оценить частоту и продолжительность обновлений системы, а также время появления широкодоступных CRQC для решения вопроса о необходимости и сроках поддержки гибридной аутентификации PQ/T.

13.3. Комбинации гибридных криптоалгоритмов — вопросы и подходы

13.3.1. Комбинации гибридных криптоалгоритмов

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

13.3.2. Композитные ключи в гибридных схемах

При объединении ключей в режиме AND (И) возможно имеет смысл рассматривать их как единый ключ, а не два разных. Обычно это будет требовать меньших изменений в компонентах экосистем PKI, многие из которых не готовы работать с двумя ключами или двойными подписями. Для синтаксических анализаторов протокольного или прикладного уровня композитный алгоритм, состоящий из двух алгоритмов-компонентов, является просто новым алгоритмом и поддержка добавления новых алгоритмов, как правило, уже имеется. Трактовка множества ключей-компонентов как одного композитного ключа обеспечивает также преимущества в безопасности, такие как предотвращение кросс-протокольного неоднократного использования отдельных ключей-компонентов и гарантии отзыва или удаления всех компонентов ключа одновременно, особенно при рассмотрении композита как единого объекта на всем пути в криптомодуль.

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

Последний вопрос связан с конкретными парами алгоритмов, которые можно объединить. Недавняя тенденция в протоколах заключается в том, чтобы разрешать лишь небольшое число «хорошо известных» конфигураций, которые имеют смысл и часто называются в криптографии «наборами шифров» (ciphersuite), вместо допущения произвольных сочетаний вариантов конфигурации, которые могут взаимодействовать опасным способом. В настоящее время имеется согласие в том, что такой же подход следует применять для комбинаций криптографических алгоритмов, а «заведомо хорошие» пары следует указывать явно (explicit composite) вместо разрешения выбирать произвольные комбинации из двух криптографических алгоритмов (generic composite).

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

Предложена по меньшей мере одна схема, позволяющая паре сертификатов существовать как единый сертификат при выдаче и управлении с динамическим расщеплением на отдельные части при необходимости [ENC-PAIR-CERTS].

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

Важным вопросом безопасности, особенно при использовании гибридных ключей подписи, и в меньшей степени при использовании гибридных ключей KEM, является повторное использование ключей. В традиционной криптографии могут возникать проблемы при так называемых кросс-протокольных атаках, где один ключ может использоваться несколькими протоколами, например, для подписи в согласовании TLS и подписи почтовых сообщений S/MIME. Хотя неоднократное использование ключей в рамках одного протокола (например, в нескольких сертификатах S/MIME для одного пользователя) не рекомендуется, в общем случае это не критично для безопасности. Однако повторное использование ключей становится большой проблемой безопасности в гибридных схемах.

Рассмотрим гибридный ключ {RSA, ML-DSA}, где ключ RSA присутствует также в сертификате с одним алгоритмом. В таком случае атакующий может выполнить «атаку с вырезанием данных», где он берет часть данных, подписанных с ключом {RSA, ML-DSA}, удаляет подпись ML-DSA и представляет данные, как будто они предназначались лишь для сертификата RSA. Это ведёт к набору определений безопасности, называемых «свойствами неделимости» (non-separability properties), которые относятся к стойкости системы к атакам различной сложности с понижениям/вырезанием [HYBRID-SIG-SPECT]. Поэтому разработчикам рекомендуется либо повторно использовать гибридный ключ целиком, либо генерировать новый свежий ключ для всех ключей-компонентов при каждом использовании и не брать имеющийся ключ для повторного использования в качестве компонента гибридного ключа.

13.3.4. Направления будущих исследований

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

14. Влияние на устройства и сети с ограничениями

В алгоритмах PQC в общем случае размеры ключей, шифротекста и подписей превышают их размеры в традиционных алгоритмах с открытым ключом. Это особенно важно для устройств с ограниченными возможностями, работающих при ограниченных скоростях. В сфере IoT эти ограничения исторически приводили к значительным усилиям IETF (например, в рабочих группах LAKE и CoRE) по адаптации протоколов защиты к средам с ограниченными ресурсами.

По мере перехода на PQC эти среды столкнутся с аналогичными проблемами. Больший размер сообщений может увеличить продолжительность согласования и потребовать фрагментации. В IETF продолжается работа по исследованию возможностей внедрения PQC в устройства с ограниченными возможностями [CONSTRAIN-DEV-PCQ].

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

15.1. Криптоанализ

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

Недавние атаки по побочным каналам с анализом энергопотребления на основе глубокого обучения показали, что нужна осторожность при аппаратной реализации требуемых алгоритмов PQC. Две из последних работ включают атаки на ML-KEM [KyberSide] и Saber [SaberSide]. Развивающаяся картина угроз указывает, что криптография на основе решёток действительно более уязвима к атакам по побочным каналам, как в [SideCh] и [LatticeSide]. Поэтому были предложены методы смягчения таких атак [Mitigate1], [Mitigate2], [Mitigate3].

15.2. Гибкость криптографии

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

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

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

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

15.3. Фрагментация юрисдикций

Заслуживает внимания ещё одно возможное применение гибридных схем, хотя оно и не связано напрямую с PQC. Это применение гибридных решений при организации криптографических соединений между юрисдикциями. Традиционная криптография уже разделена по юрисдикциям. Следует отметить, что хотя в большинстве юрисдикций поддерживается ECDH, в США предпочтение отдано кривым NIST, а в Германии — кривым Brainpool. Китай, Россия и другие юрисдикции имеют свои национальные стандарты криптографии. Маловероятно, что ситуация с фрагментированием стандартов криптографии изменится с появлением PQC. Если гибридные схемы в режиме AND (И) будут стандартизованы по отмеченным выше причинам, можно будет предположить их использование для создания шифров, в которых одна криптографическая операция будет соответствовать криптографическим требованиям обеих сторон.

15.4. Гибридный обмен ключами и подписи в процессе перехода

Пост-квантовые алгоритмы, выбранные для стандартизации, являются сравнительно новыми и не изучены так же глубоко, как традиционные алгоритмы. Реализации PQC также будут новыми и вероятность ошибок в них будет больше, чем в проверенных практикой криптографических реализациях, на которые полагаются сегодня. Кроме того, при некоторых внедрениях может потребоваться сохранение традиционных алгоритмов по требованиям регуляторов, например, соответствие FIPS [SP-800-56C] или PCI (Payment Card Industry) [PCI]. Рекомендуется использовать гибридный обмен ключами для улучшения защиты от атак HNDL. Кроме того, гибридные подписи оставят время для реагирования в случае сообщений о разрушительной атаке на один из алгоритмов без полного отказа от традиционных криптосистем.

При гибридном обмене выполняется сразу (параллельно) классический и пост-квантовый обмен ключами. Это обеспечивает избыточность защиты на случай уязвимостей в алгоритмах PQC с постепенным ростом доверия к ним, а в решениях, совместимых с прежними версиями, обеспечит постепенное внедрение без потери совместимости с имеющимися системами. Например, в TLS 1.3 гибридный обмен ключами может сочетать широко распространённый классический алгоритм, такой как X25519, с пост-квантовым алгоритмом, таким как ML-KEM. Это позволит унаследованным клиентам продолжать использование классического обмена ключами, давая обновлённым клиентам возможность применять гибридный обмен. Гибридные решения с распределением издержек (overhead-spreading) нацелены на снижение издержек PQ. Например, подходы, подобные описанным в [PQ-MLS], снижают стоимость PQ за счёт селективного обновления PQ в процессах обмена ключами, позволяя системам обеспечить баланс между эффективностью и безопасностью. Такая стратегия обеспечивает защищённый пост-квантовый канал при сохранении управляемости для издержек, что делает её особо подходящей для сред с ограниченными возможностями.

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

15.5. Привязка к шифротексту для KEM и DH

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

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

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

17. Дополнительная литература и ресурсы

Хорошей книгой по современной криптографии является «Serious Cryptography, 2nd Edition» Жана-Филиппа Омассона (Jean-Philippe Aumasson) [Serious-Crypt].

Открытый проект Open Quantum Safe (OQS) [OQS] предоставляет исходный код для поддержки перехода к квантово-стойкой криптографии.

Рабочая группа IETF PQUIP [PQUIP-WG] ведёт список работ по связанным с PQC протоколам в рамках IETF.

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

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

[ClassicMcEliece] «Classic McEliece», <https://classic.mceliece.org/>.

[FN-DSA] «FALCON: Fast Fourier lattice-based compact signatures over NTRU», <https://falcon-sign.info/>.

[FrodoKEM] «FrodoKEM», <https://frodokem.org/>.

[Grovers] Grover, L. K., «A fast quantum mechanical algorithm for database search», STOC ’96: Proceedings of the twenty-eighth annual ACM symposium on Theory of Computing, pp. 212-219, DOI 10.1145/237814.237866, 1 July 1996, <https://dl.acm.org/doi/10.1145/237814.237866>.

[ML-DSA] NIST, «Module-Lattice-Based Digital Signature Standard», NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.

[ML-KEM] NIST, «Module-Lattice-Based Key-Encapsulation Mechanism Standard», NIST FIPS 203, DOI 10.6028/nist.fips.203, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>.

[NTRU] «NTRU», <https://ntru.org/index.shtml>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.

[RFC6090] McGrew, D., Igoe, K., and M. Salter, «Fundamental Elliptic Curve Cryptography Algorithms», RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.

[RFC8235] Hao, F., Ed., «Schnorr Non-interactive Zero-Knowledge Proof», RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/info/rfc8235>.

[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, «XMSS: eXtended Merkle Signature Scheme», RFC 8391, DOI 10.17487/RFC8391, May 2018, <https://www.rfc-editor.org/info/rfc8391>.

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

[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, «Leighton-Micali Hash-Based Signatures», RFC 8554, DOI 10.17487/RFC8554, April 2019, <https://www.rfc-editor.org/info/rfc8554>.

[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, «Hybrid Public Key Encryption», RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/info/rfc9180>.

[RFC9242] Smyslov, V., «Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 9242, DOI 10.17487/RFC9242, May 2022, <https://www.rfc-editor.org/info/rfc9242>.

[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, «Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 9370, DOI 10.17487/RFC9370, May 2023, <https://www.rfc-editor.org/info/rfc9370>.

[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, «Internet X.509 Public Key Infrastructure — Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)», RFC 9881, DOI 10.17487/RFC9881, October 2025, <https://www.rfc-editor.org/info/rfc9881>.

[RSA] Rivest, R. L., Shamir, A., and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM, vol. 21, no. 2, pp. 120-126, DOI 10.1145/359340.359342, February 1978, <https://dl.acm.org/doi/pdf/10.1145/359340.359342>.

[Shors] Shor, P., «Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer», arXiv:quant-ph/9508027v2, 25 January 1996, <https://arxiv.org/pdf/quant-ph/9508027>.

[SLH-DSA] NIST, «Stateless Hash-Based Digital Signature Standard», NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf>.

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

[AddSig] NIST, «Post-Quantum Cryptography: Additional Digital Signature Schemes», <https://csrc.nist.gov/Projects/pqc-dig-sig/standardization>.

[ANSSI] ANSSI, «ANSSI views on the Post-Quantum Cryptography transition (2023 follow up)», 21 December 2023, <https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf>.

[BBS-SIG-SCHEME] Looker, T., Kalos, V., Whitehead, A., and M. Lodder, «The BBS Signature Scheme», Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs-signatures-10, 8 January 2026, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bbs-signatures-10>.

[BHK09] Bellare, M., Hofheinz, D., and E. Kiltz, «Subtleties in the Definition of IND-CCA: When and How Should Challenge-Decryption be Disallowed?», Cryptology ePrint Archive, Paper 2009/418, 2009, <https://eprint.iacr.org/2009/418>.

[BIKE] «BIKE», <https://bikesuite.org/>.

[BPQS] Chalkias, K., Brown, J., Hearn, M., Lillehagen, T., Nitto, I., and T. Schroeter, «Blockchained Post-Quantum Signatures», Cryptology ePrint Archive, Paper 2018/658, <https://eprint.iacr.org/2018/658>.

[BSI-PQC] BSI, «Quantum-safe cryptography — fundamentals, current developments and recommendations», 18 May 2022, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626>.

[Cloudflare] Westerbaan, B., «NIST’s pleasant post-quantum surprise», Cloudflare Blog, 8 July 2022, <https://blog.cloudflare.com/nist-post-quantum-surprise/>.

[CNSA2-0] NSA, «Announcing the Commercial National Security Algorithm Suite 2.0», September 2022, <https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF>.

[CONSTRAIN-DEV-PCQ] Reddy.K, T., Wing, D., Salter, B., and K. Kwiatkowski, «Adapting Constrained Devices for Post-Quantum Cryptography», Work in Progress, Internet-Draft, draft-ietf-pquip-pqc-hsm-constrained-05, 1 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-hsm-constrained-05>.

[CRQCThreat] Jaques, S., «Landscape of Quantum Computing», <https://sam-jaques.appspot.com/quantum_landscape_2024>.

[CS01] Cramer, R. and V. Shoup, «Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack», Cryptology ePrint Archive, Paper 2001/108, 2001, <https://eprint.iacr.org/2001/108>.

[ENC-PAIR-CERTS] Bonnell, C., Gray, J., Hook, D., Okubo, T., and M. Ounsworth, «A Mechanism for Encoding Differences in Paired Certificates», Work in Progress, Internet-Draft, draft-bonnell-lamps-chameleon-certs-07, 18 October 2025, <https://datatracker.ietf.org/doc/html/draft-bonnell-lamps-chameleon-certs-07>.

[GMR88] Goldwasser, S., Micali, S., and R. L. Rivest, «A digital signature scheme secure against adaptive chosen-message attacks», SIAM Journal on Computing, vol. 17, no. 2, pp. 281-308, DOI 10.1137/0217017, April 1988, <https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Digital%20Signatures/A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-Message_Attack.pdf>.

[Grover-Search] Zalka, C., «Grover’s quantum searching algorithm is optimal», Physical Review A, vol. 60, no. 4, pp. 2746-2751, DOI 10.1103/PhysRevA.60.2746, October 1999, <https://link.aps.org/doi/10.1103/PhysRevA.60.2746>.

[HQC] «HQC», <http://pqc-hqc.org/>.

[HYBRID-SIG-SPECT] Bindel, N., Hale, B., Connolly, D., and F. D, «Hybrid signature spectrums», Work in Progress, Internet-Draft, draft-ietf-pquip-hybrid-signature-spectrums-07, 20 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-hybrid-signature-spectrums-07>.

[KEEPINGUP] Cremers, C., Dax, A., and N. Medinger, «Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols», Cryptology ePrint Archive, Paper 2023/1933, 2023, <https://eprint.iacr.org/2023/1933>.

[KEM-COMBINER] Ounsworth, M., Wussler, A., and S. Kousidis, «Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)», Work in Progress, Internet-Draft, draft-ounsworth-cfrg-kem-combiners-05, 31 January 2024, <https://datatracker.ietf.org/doc/html/draft-ounsworth-cfrg-kem-combiners-05>.

[KyberSide] Ji, Y., Wang, R., Ngo, K., Dubrova, E., and L. Backlund, «A Side-Channel Attack on a Hardware Implementation of CRYSTALS-Kyber», Cryptology ePrint Archive, Paper 2022/1452, 2022, <https://eprint.iacr.org/2022/1452>.

[LattFail1] D’Anvers, J., Guo, Q., Johansson, T., Nilsson, A., Vercauteren, F., and I. Verbauwhede, «Decryption Failure Attacks on IND-CCA Secure Lattice-Based Schemes», Public-Key Cryptography — PKC 2019, Lecture Notes in Computer Science, vol. 11443, pp. 565-598, DOI 10.1007/978-3-030-17259-6_19, 6 April 2019, <https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19>.

[LattFail2] D’Anvers, J., Rossi, M., and F. Virdia, «(One) Failure Is Not an Option: Bootstrapping the Search for Failures in Lattice-Based Encryption Schemes», Advances in Cryptology — EUROCRYPT 2020, Lecture Notes in Computer Science, vol. 12107, pp. 3-33, DOI 10.1007/978-3-030-45727-3_1, 1 May 2020, <https://link.springer.com/chapter/10.1007/978-3-030-45727-3_1>.

[LatticeSide] Ravi, P., Roy, S. S., Chattopadhyay, A., and S. Bhasin, «Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM schemes», Cryptology ePrint Archive, Paper 2019/948, 2019, <https://eprint.iacr.org/2019/948>.

[LIBOQS] «LibOQS — Open Quantum Safe», commit 97f6b86, November 2025, <https://github.com/open-quantum-safe/liboqs>.

[Lyu09] Lyubashevsky, V., «Fiat-Shamir With Aborts: Applications to Lattice and Factoring-Based Signatures», ASIACRYPT 2009, <https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf>.

[Mitigate1] Hoffmann, C., Libert, B., Momin, C., Peters, T., and F. Standaert, «POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Public Key Encryption», Cryptology ePrint Archive, Paper 2022/873, 2022, <https://eprint.iacr.org/2022/873>.

[Mitigate2] Tsai, T., Huang, S., Tseng, Y., Chuang, Y., and Y. Hung, «Leakage-Resilient Certificate-Based Authenticated Key Exchange Protocol», IEEE Open Journal of the Computer Society, vol. 3, pp. 137-148, DOI 10.1109/OJCS.2022.3198073, 2022, <https://ieeexplore.ieee.org/document/9855226>.

[Mitigate3] Azouaoui, M., Kuzovkova, Y., Schneider, T., and C. V. Vredendaal, «Post-Quantum Authenticated Encryption against Chosen-Ciphertext Side-Channel Attacks», Cryptology ePrint Archive, Paper 2022/916, 2022, <https://eprint.iacr.org/2022/916>.

[ML-DSA-X.509] Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, «Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure», Work in Progress, Internet-Draft, draft-ietf-lamps-pq-composite-sigs-19, 21 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19>.

[NIST] NIST, «Post-Quantum Cryptography Standardization», <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>.

[NISTFINAL] NIST, «NIST Releases First 3 Finalized Post-Quantum Encryption Standards», 13 August 2024, <https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards>.

[OQS] «Open Quantum Safe Project», <https://openquantumsafe.org/>.

[PCI] PCI Security Standards Council, «Payment Card Industry Data Security Standard», PCI DSS: v4.0.1, <https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf>.

[PQ-HPKE] Barnes, R. and D. Connolly, «Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE», Work in Progress, Internet-Draft, draft-ietf-hpke-pq-04, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-04>.

[PQ-KEM] Connolly, D., Barnes, R., and P. Grubbs, «Hybrid PQ/T Key Encapsulation Mechanisms», Work in Progress, Internet-Draft, draft-irtf-cfrg-hybrid-kems-11, 7 May 2026, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems-11>.

[PQ-MLS] Tian, X., Hale, B., Mularczyk, M., and J. Alwen, «Amortized PQ MLS Combiner», Work in Progress, Internet-Draft, draft-ietf-mls-combiner-02, 22 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02>.

[PQCAPI] NIST, «PQC — API notes», <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf>.

[PQRSA] Bernstein, D. J., Heninger, N., Lou, P., and L. Valenta, «Post-quantum RSA», 19 April 2017, <https://cr.yp.to/papers/pqrsa-20170419.pdf>.

[PQUIP-WG] IETF, «Post-Quantum Use In Protocols (pquip)», <https://datatracker.ietf.org/group/pquip/documents/>.

[QC-DNS] Hoffman, P., «Quantum Computing and the DNS», ICANN Office of the Chief Technology Officer, OCTO-031v2, 22 April 2024, <https://www.icann.org/octo-031-en.pdf>.

[QuantSide] Xu, C., Erata, F., and J. Szefer, «Exploration of Quantum Computer Power Side-Channels», arXiv:2304.03315v2, 9 May 2023, <https://arxiv.org/pdf/2304.03315>.

[RFC5652] Housley, R., «Cryptographic Message Syntax (CMS)», STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, «Ephemeral Diffie-Hellman Over COSE (EDHOC)», RFC 9528, DOI 10.17487/RFC9528, March 2024, <https://www.rfc-editor.org/info/rfc9528>.

[RFC9763] Becker, A., Guthrie, R., and M. Jenkins, «Related Certificates for Use in Multiple Authentications within a Protocol», RFC 9763, DOI 10.17487/RFC9763, June 2025, <https://www.rfc-editor.org/info/rfc9763>.

[RFC9794] Driscoll, F., Parsons, M., and B. Hale, «Terminology for Post-Quantum Traditional Hybrid Schemes», RFC 9794, DOI 10.17487/RFC9794, June 2025, <https://www.rfc-editor.org/info/rfc9794>.

[RFC9814] Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, «Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)», RFC 9814, DOI 10.17487/RFC9814, July 2025, <https://www.rfc-editor.org/info/rfc9814>.

[RFC9941] Friedl, M., Mojzis, J., and S. Josefsson, «Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512», RFC 9941, DOI 10.17487/RFC9941, April 2026, <https://www.rfc-editor.org/info/rfc9941>.

[RSA10SC] QuintessenceLabs, «Breaking RSA Encryption — an Update on the State-of-the-Art», 13 June 2019, <https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-state-art>.

[RSA8HRS] Gidney, C. and M. Ekera, «How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits», arXiv:1905.09749v3, 13 April 2021, <https://arxiv.org/abs/1905.09749>.

[RSAShor] Beauregard, S., «Circuit for Shor’s algorithm using 2n+3 qubits», arXiv:quant-ph/0205095v3, 21 February 2003, <https://arxiv.org/pdf/quant-ph/0205095.pdf>.

[SaberSide] Ngo, K., Dubrova, E., and T. Johansson, «A side-channel attack on a masked and shuffled software implementation of Saber», Journal of Cryptographic Engineering, vol. 13, pp. 443-460, DOI 10.1007/s13389-023-00315-3, 25 April 2023, <https://link.springer.com/article/10.1007/s13389-023-00315-3>.

[Serious-Crypt] Aumasson, J., «Serious Cryptography, 2nd Edition», ISBN 9781718503847, August 2024.

[SideCh] Ngo, K., Wang, R., Dubrova, E., and N. Paulsrud, «Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-Order Masking», Cryptology ePrint Archive, Paper 2022/919, 2022, <https://eprint.iacr.org/2022/919>.

[SP-1800-38C] Newhouse, W., Souppaya, M., Barke, W., Brown, C., Kampanakis, P., Goodman, J., Prat, J., Larrieu, R., Gray, J., Ounsworth, M., Viana, C., Gong, H. L. V., Kwiatkowsk, K., Hu, A., Burns, R., Paquin, C., Gilbert, J., Scinta, G., Kim, E., and V. Krumme, «Migration to Post-Quantum Cryptography Quantum Readiness: Testing Draft Standards, Volume C: Quantum-Resistant Cryptography Technology Interoperability and Performance Report», Preliminary Draft, NIST SP 1800-38C, December 2023, <https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf>.

[SP-800-56C] Barker, E., Chen, L., and R. Davis, «Recommendation for Key-Derivation Methods in Key-Establishment Schemes», NIST SP 800-56Cr2, DOI 10.6028/NIST.SP.800-56Cr2, August 2020, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf>.

[Threat-Report] Mosca, M. and M. Piani, «Quantum Threat Timeline Report 2020», Global Risk Institute, 27 January 2021, <https://globalriskinstitute.org/publications/quantum-threat-timeline-report-2020/>.

[TLS-HYB-KEY-EXCH] Stebila, D., Fluhrer, S., and S. Gueron, «Hybrid key exchange in TLS 1.3», Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-16>.

[X-WING] Connolly, D., Schwabe, P., and B. Westerbaan, «X-Wing: general-purpose hybrid post-quantum KEM», Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-10, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-10>.

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

В этом документе используется текст из более раннего Internet-Draft, созданного Paul Hoffman. Спасибо Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop, Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk Von Hugo, Daniel Van Geest за обсуждение, рецензии и комментарии.

Авторы также выражают признательность Kris Kwiatkowski за вклад в этот документ.

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

Aritra Banerjee

Nokia

London

United Kingdom

Email: aritra.banerjee@nokia.com

Tirumaleswar Reddy.K

Nokia

Bangalore

Karnataka

India

Email: k.tirumaleswar_reddy@nokia.com

Dimitrios Schoinianakis

Nokia

Athens

Greece

Email: dimitrios.schoinianakis@nokia-bell-labs.com

Timothy Hollebeek

DigiCert

Pittsburgh, PA

United States of America

Email: tim.hollebeek@digicert.com

Mike Ounsworth

Entrust Limited

2500 Solandt Road, Suite 100

Ottawa, Ontario K2K 3G5

Canada

Email: mike@ounsworth.ca

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

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

nmalykh@protokols.ru

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

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

3Отметим, что алгоритм Шора не может работать лишь на классических компьютерах и требует CRQC.

4Неразличимость при адаптивной атаке с выбранным шифротекстом.

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

RFC 9987 Secure Shell (SSH) Agent Protocol

Опубликовано 07.05.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                         D. Miller
Request for Comments: 9987                                       OpenSSH
Category: Standards Track                                       May 2026
ISSN: 2070-1721

Secure Shell (SSH) Agent Protocol

Протокол агента SSH

PDF

Аннотация

В этом документе определён протокол агента ключей для использования с протоколом Secure Shell (SSH).

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

Документ содержит проект стандарта Internet (Standards Track).

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

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

1. Введение

Протокол Secure Shell (SSH) [RFC4251] предназначен для защищённых соединений [RFC4253] и входа в систему (login) [RFC4254] через незащищённые сети. Он поддерживает множество механизмов проверки подлинности [RFC4252], включая аутентификацию с открытым ключом. Этот документ задаёт протокол взаимодействия с компонентом управления ключами (обычно называемым агентом), который хранит секретные ключи. Клиенты SSH (возможно, и серверы) могут обращаться к агенту по этому протоколу для выполнения операций с использованием открытого ключа и секретного ключа, хранящегося у агента.

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

2. Уровни требований

3. Обзор протокола

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

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

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

4. Термины и обозначения

Далее в документе термин «агент» применяется для обозначения компонента управления ключами, реализующего отвечающую сторону протокола, а термин «клиент» — запрашивающую сторону, которая взаимодействует с агентом протокола. Если рассматриваемый клиент является клиентом Secure Shell [RFC4251], он называется явно «клиентом SSH, а термин «сервер SSH» обозначает сервер Secure Shell.

Кодируемые типы данных (byte, uint32, string и т. д.) описаны в разделе 5 [RFC4251]. Тип byte[] без указания размера внутри квадратных скобок указывает последовательность байтов (возможно, пустую), размер которой определяется контекстом. Все размеры указываются в байтах, если явно не указано иное.

5. Сообщения протокола

Сообщение включает элементы (поля) length, type и contents.

       uint32            length
       byte              type
       byte[length - 1]  contents

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

5.1. Базовые отклики агента

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

       byte              SSH_AGENT_SUCCESS

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

В случае отказа агент должен отвечать однобайтовым сообщением

       byte              SSH_AGENT_FAILURE

или зависящим от запроса сообщением об отказе, которое может включать дополнительные поля. Сообщения SSH_AGENT_FAILURE должны также передаваться в ответ на непонятные или неподдерживаемые типы запросов.

5.2. Добавление ключей в агент

Ключи могут добавляться в агент с помощью сообщений SSH_AGENTC_ADD_IDENTITY или SSH_AGENTC_ADD_ID_CONSTRAINED. Базовый формат SSH_AGENTC_ADD_IDENTITY имеет вид

       byte             SSH_AGENTC_ADD_IDENTITY
       string           key type
       byte[]           key data
       string           comment

Поле key type указывает тип ключа, например, ssh-rsa для ключей RSA, определённых в [RFC4253]. Поле key data содержит открытую и секретную часть ключа и зависит от типа ключа, как описано в параграфах 5.2.1 — 5.2.4 для наиболее распространённых ключей. Поле comment содержит понятное человеку имя ключа или комментарий в форме строки символов UTF-8 и может служить для идентификации ключа в видимых пользователю сообщениях. Эта строка может быть пустой. Сообщение SSH_AGENTC_ADD_ID_CONSTRAINED имеет похожий формат с одним добавочным полем

       byte             SSH_AGENTC_ADD_ID_CONSTRAINED
       string           key type
       byte[]           key data
       string           comment
       constraint[]     constraints

Поле constraints служит для задания ограничений пригодности или использования ключа. Типы и формат ограничений описаны в параграфе 5.2.7. Клиентам следует применять сообщение SSH_AGENTC_ADD_IDENTITY, вместо SSH_AGENTC_ADD_ID_CONSTRAINED с пустым полем constraints, хотя пригодны (и эквивалентны) оба варианта.

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

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

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

5.2.1. Ключи DSA

Ключи DSA (Digital Signature Algorithm), указываемые как ssh-dss, определены в [RFC4253]. Эти ключи могут добавляться с использованием показанного ниже сообщения. Поле constraints присутствует только в сообщениях SSH_AGENTC_ADD_ID_CONSTRAINED.

       byte             SSH_AGENTC_ADD_IDENTITY или
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           ssh-dss
       mpint            p
       mpint            q
       mpint            g
       mpint            y
       mpint            x
       string           comment
       constraint[]     constraints

Значения p, q, g являются параметрами домена DSA, y и x указывают открытый и секретный ключ, соответственно. Значения определены в параграфе 4.1 [FIPS.186-4].

5.2.2. Ключи ECDSA

Ключи ECDSA (Elliptic Curve Digital Signature Algorithm) имеют тип ecdsa-sha2- и определены в [RFC5656]. Эти ключи могут добавляться с использованием указанного ниже сообщения. Поле constraints присутствует только в сообщениях SSH_AGENTC_ADD_ID_CONSTRAINED.

       byte             SSH_AGENTC_ADD_IDENTITY или
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           key type
       string           ecdsa_curve_name
       string           Q
       mpint            d
       string           comment
       constraint[]     constraints

Q и d указывают открытую и секретную часть, соответственно. Значения определены в параграфе 6.2 [FIPS.186-5].

5.2.3. Ключи EdDSA

В [RFC8709] определены ключи EdDSA (Edwards-curve Digital Signature Algorithm) (см. [RFC8032]) Ed25519 и Ed448 с именами ssh-ed25519 и ssh-ed448, соответственно. Эти ключи могут добавляться с использованием указанного ниже сообщения. Поле constraints присутствует только в сообщениях SSH_AGENTC_ADD_ID_CONSTRAINED.

       byte             SSH_AGENTC_ADD_IDENTITY или
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           ssh-ed25519 или ssh-ed448
       string           ENC(A)
       string           k || ENC(A)
       string           comment
       constraint[]     constraints

Первое значение является открытым ключом EdDSA — ENC(A), а второе — конкатенацией секретного ключа k и открытого ключа ENC(A) (повтор открытого ключа служит для совместимости с широко распространёнными реализациями). Содержимое и интерпретация значений ENC(A) и k определены в параграфе 3.2 [RFC8032].

5.2.4. Ключи RSA

Ключи RSA, именуемые как ssh-rsa, определены в [RFC4253]. Эти ключи могут добавляться с использованием указанного ниже сообщения. Поле constraints присутствует лишь в сообщениях SSH_AGENTC_ADD_ID_CONSTRAINED.

       byte             SSH_AGENTC_ADD_IDENTITY или
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           "ssh-rsa"
       mpint            n
       mpint            e
       mpint            d
       mpint            iqmp
       mpint            p
       mpint            q
       string           comment
       constraint[]     constraints

Поле n указывает открытый композитный модуль, e — секретный, а d — открытый показатель степени. Поля p и q — секретные простые сомножители, значение iqmp — обратно q по модулю p. Все значения, кроме iqmp (которое может быть рассчитано по другим значениям), определены в параграфе 5.1 [FIPS.186-5].

5.2.5. Другие ключи

Агенты и их клиенты могут поддерживать не указанные в этом документе типы ключей. Фирменные типы ключей должны использовать связанное с доменом именование, как указано в разделе 6 [RFC4251], пока коды не будут выделены IANA [IANA-PUBKEYS].

5.2.6. Добавление ключей из токенов

Ключи, хранящиеся на смарт-картах и других носителях (token), могут добавляться с помощью запросов SSH_AGENTC_ADD_SMARTCARD_KEY и SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED. Поле constraints включается лишь в вариант SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED.

       byte             SSH_AGENTC_ADD_SMARTCARD_KEY или
                        SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
       string           token id
       string           PIN
       constraint[]     constraints

Поле token id содержит неанализируемый (opaque) идентификатор носителя, а PIN — необязательный пароль или код PIN для разблокировки ключа. Протокол не задаёт интерпретацию token id, полностью отдавая её агенту.

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

Агент должен отвечать сообщением SSH_AGENT_SUCCESS, если хотя бы 1 ключ был успешно загружен в результате одного или нескольких таких сообщений. Если ключей не найдено, поле token id не распознано, запрос не соответствует правилам агента или агент не поддерживает ключи на аппаратных носителях, агент должен возвращать сообщение SSH_AGENT_FAILURE.

5.2.7. Ограничения ключей

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

       byte             constraint1_type
       byte[]           constraint1_data
       byte             constraint2_type
       byte[]           constraint2_data
       ....
       byte             constraintN_type
       byte[]           constraintN_data

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

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

5.2.7.1. Ограничение срока действия ключей

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

       byte             SSH_AGENT_CONSTRAIN_LIFETIME
       uint32           seconds

5.2.7.2. Требование подтверждения ключа

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

       byte             SSH_AGENT_CONSTRAIN_CONFIRM

5.2.7.3. Расширения для ограничений

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

       byte             SSH_AGENT_CONSTRAIN_EXTENSION
       string           extension name
       byte[]           extension-specific details

Поле extension name должно содержать строку UTF-8. В фирменных расширениях должен применяться суффикс домена реализации (например, foo@example.com), определяемый схемой именования из раздела 6 в [RFC4251].

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

5.3. Кодирование открытых ключей

Загруженные в агент ключи указываются блобами открытых ключей, которые представляют собой стандартное кодирование открытых ключей SSH для передачи в линию, заданное в [RFC4253] для ключей ssh-rsa и ssh-dss, в [RFC5656] — для ecdsa-sha2-* и в [RFC8709] — для ssh-ed25519и ssh-ed448.

5.4. Удаление ключей из агента

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

       byte             SSH_AGENTC_REMOVE_ALL_IDENTITIES

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

Конкретный ключ можно удалить с помощью сообщения

       byte             SSH_AGENTC_REMOVE_IDENTITY
       string           key blob

где key blob — стандартное кодирование удаляемого ключа (параграф 5.3). Агент должен возвращать отклик SSH_AGENT_SUCCESS при удалении ключа и SSH_AGENT_FAILURE, если ключ не найден.

Хранящиеся в носителях ключи можно удалить с помощью сообщения

       byte             SSH_AGENTC_REMOVE_SMARTCARD_KEY
       string           token id
       string           PIN

Поле token id — это неанализируемый (opaque) идентификатор носителя ключа, а PIN — необязательный пароль или PIN (обычно не применяется) в кодировке UTF-8. По запросу на удаление хранящегося в носителе ключа агенту следует удалять все ключи, загруженные с устройства, соответствующего token id. По запросу SSH_AGENTC_REMOVE_ALL_IDENTITIES агентам следует быстро и полностью удалять все ключи независимо от локальной политики. Удаление хранящегося на носителе ключа происходит только в агенте, а хранящийся на носителе ключ удалять не следует.

Агент должен отвечать сообщением SSH_AGENT_SUCCESS после удаления ключа и SSH_AGENT_FAILURE, если ключ не найден.

5.5. Запрос списка ключей

Клиент может запросить у агента список ключей с помощью сообщения

       byte             SSH_AGENTC_REQUEST_IDENTITIES

Агент должен отвечать сообщением

       byte             SSH_AGENT_IDENTITIES_ANSWER
       uint32           nkeys

где nkeys указывает число ключей, за которым могут следовать предоставляемые клиенту ключи в формате

       string           key blob
       string           comment

Поле key blob содержит стандартное кодирование открытого ключа (параграф 5.3), comment — понятную человеку строку комментария в кодировке UTF-8.

5.6. Операции с секретным ключом

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

       byte             SSH_AGENTC_SIGN_REQUEST
       string           key blob
       string           data
       uint32           flags

Поле key blob указывает запрошенный для подписи ключ (кодирование в соответствии с параграфом 5.3), data — данные для подписания, а flags — битовое поле с побитовым объединением (OR) флагов подписи (см. ниже). Если агент не поддерживает запрошенные флаги или по иной причине не может создать подпись (например, заданного ключа нет или пользователь не подтвердил ключ с ограничением), он должен ответить сообщением SSH_AGENT_FAILURE. При успешном подписании агент должен передать сообщение

       byte             SSH_AGENT_SIGN_RESPONSE
       string           signature

Формат подписи (signature) зависит от алгоритма используемого ключа. Форматы подписей протокола SSH заданы в [RFC4253] для ключей ssh-rsa и ssh-dss, в [RFC5656] — для ecdsa-sha2-* и в [RFC8709] — для ssh-ed25519и ssh-ed448.

5.6.1. Флаги подписи

В настоящее время для запросов подписи заданы флаги SSH_AGENT_RSA_SHA2_256 и SSH_AGENT_RSA_SHA2_512 (см. параграф 8.3). Оба эти флага пригодны лишь для ключей ssh-rsa и запрашивают у агента подпись с использованием метода rsa-sha2-256 или rsa-sha2-512, соответственно. Схемы подписи заданы в [RFC8332].

5.7. Установка и снятие блокировки агента

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

       byte             SSH_AGENTC_LOCK
       string           passphrase

Агент должен возвращать сообщение SSH_AGENT_SUCCESS после установки блокирования и SSH_AGENT_FAILURE в иных случаях (например, когда агент уже заблокирован).

Для снятия блокировки служит сообщение

       byte             SSH_AGENTC_UNLOCK
       string           passphrase

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

5.8. Механизм расширения

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

       byte             SSH_AGENTC_EXTENSION
       string           extension type
       byte[]           зависящее от запроса содержимое

Поле extension type указывает тип сообщения с расширением в форме строки UTF-8. Зависящие от реализации расширения должны иметь суффикс, соответствующий схеме из раздела 6 [RFC4251] (например, foo@example.com).

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

Содержимое отклика об успешном расширении зависит от extension type. В случае успеха агент должен возвращать SSH_AGENT_SUCCESS или зависящее от расширения сообщение вида

       byte             SSH_AGENT_EXTENSION_RESPONSE
       string           extension type
       byte[]           зависящее от отклика содержимое

где поле extension type совпадает с полученным в запросе.

Отказы при расширении следует передавать в сообщении SSH_AGENT_EXTENSION_FAILURE

       byte             SSH_AGENT_EXTENSION_FAILURE

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

5.8.1. Расширение Query

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

       byte             SSH_AGENTC_EXTENSION
       string           "query"

Если агент поддерживает расширение query, ему следует отвечать списком имён поддерживаемых расширений.

       byte             SSH_AGENT_EXTENSION_RESPONSE
       string           "query"
       string[]         поддерживаемые типы расширений

6. Соединение с агентом

Агенты раскрываются локальным системам через ориентированные на соединения конечные точки. В системах класса Unix агент обычно прослушивает связанный с файловой системой сокет домена Unix, в Microsoft Windows обычно используется Windows Named Pipe. Доступ к конечным точкам следует контролировать в соответствии с разделом 10. Через такие сокеты к одному агенту может подключаться множество клиентов. В обоих случаях имя или адрес прослушивающей конечной точки обычно раскрывается через переменную окружения SSH_AUTH_SOCK, которую клиенты используют для поиска и подключения к прослушивающему агенту. Как вариант, агенты могут использовать неявные механизмы обнаружения их конечной точки, например, заданное по умолчанию расположение для каждого пользователя.

7. Перенаправление доступа к агенту

С помощью протокола соединений, описанного в [RFC4254], можно пересылать протокол агента через соединение SSH. Это позволяет запрашивать перенаправление к агенту для любого канала сессии с использованием модели, похожей на перенаправление X11 Forwarding (параграф 6.3 в [RFC4254]). Это свойство является необязательным для реализаций протокола SSH и клиентов.

7.1. Анонсирование поддержки перенаправления

Сервер SSH может анонсировать перенаправление к агенту с помощью расширения, описанного в [RFC8308], используя имя agent-forward в сообщении SSH_MSG_EXT_INFO.

       string           "agent-forward"
       string           "0" (version)

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

7.2. Запрос перенаправления

Клиент SSH может запросить перенаправление к агенту для ранее созданной сессии (см. параграф 6.1 в [RFC4254]), используя показанный ниже запрос, который передаётся после создания канала, но до вызова оболочки, команды или подсистемы.

       byte             SSH_MSG_CHANNEL_REQUEST
       uint32           channel_id
       string           "agent-req" или "auth-agent-req@openssh.com"
       boolean          want_reply

Поле channel_id содержит идентификатор канала созданной сессии (возвращённый из предыдущего запроса SSH_MSG_CHANNEL_OPEN), а флаг want_reply указывает, следует ли серверу SSH подтверждать успешность запроса (как указано в параграфе 5.4 [RFC4254]). Если сервер SSH воспринимает запрос, он обычно предоставляет конечную точку (например, прослушивающий сокет) и анонсирует это в подчинённую сессию. Большинство реализаций в Unix-подобных системах деляют это, предоставляя приватный пользовательский прослушивающий сокет домена Unix и записывая его местоположение в переменную среды SSH_AUTH_SOCK.

Многие развёрнутые реализации поддерживают лишь предстандартное имя запроса auth-agent-req@openssh.com. Имя agent-req следует применять лишь при явном анонсировании поддержки, как указано в параграфе 7.1.

7.3. Запрос соединения с агентом

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

       byte             SSH_MSG_CHANNEL_OPEN
       string           "agent-connect" или "auth-agent@openssh.com"
       uint32           channel_id
       uint32           local_window
       uint32           local_maxpacket

Поля channel_id, local_window и local_maxpacket следует интерпретировать в соответствии с параграфом 5.1 [RFC4254]. Тип agent-connect следует применять лишь при явном анонсировании поддержки, как указано в параграфе 7.1.

Клиенту SSH следует быть готовым к обработке одновременно нескольких соединений, пересылаемых к агенту клиентской стороны, иначе запросы на доступ к агенту с удалённой стороны, перекрывающие прежние запросы, могут столкнуться с отказом. Перекрытие запросов может возникать из-за того, что протокол соединения SSH [RFC4254] допускает множество пользовательских сессий через один транспорт (см. [RFC4253]) и каждая сессия может запрашивать использование агента (возможно, одновременно).

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

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

8. Протокольные номера

8.1. Типы сообщений

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

Таблица 1.

SSH_AGENTC_REQUEST_IDENTITIES	11
SSH_AGENTC_SIGN_REQUEST	13
SSH_AGENTC_ADD_IDENTITY	17
SSH_AGENTC_REMOVE_IDENTITY	18
SSH_AGENTC_REMOVE_ALL_IDENTITIES	19
SSH_AGENTC_ADD_SMARTCARD_KEY	20
SSH_AGENTC_REMOVE_SMARTCARD_KEY	21
SSH_AGENTC_LOCK	22
SSH_AGENTC_UNLOCK	23
SSH_AGENTC_ADD_ID_CONSTRAINED	25
SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED	26
SSH_AGENTC_EXTENSION	27

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

Таблица 2.

SSH_AGENT_FAILURE	5
SSH_AGENT_SUCCESS	6
SSH_AGENT_IDENTITIES_ANSWER	12
SSH_AGENT_SIGN_RESPONSE	14
SSH_AGENT_EXTENSION_FAILURE	28
SSH_AGENT_EXTENSION_RESPONSE	29

8.1.1. Резервные номера сообщений

Для реализаций с поддержкой устаревшей версии протокола SSH v1 зарезервированы номера сообщений 1-4, 7-10, 15-16, 24. Эти номера могут применяться реализациями с поддержкой устаревшей версии протокола, но в иных случаях их использование недопустимо.

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

Сообщения с номерами 240-255 зарезервированы для приватного использования (Private Use) в расширениях протокола агента и их недопустимо применять в реализациях общего назначения (см. [RFC8126]).

8.2. Идентификаторы с ограничениями

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

Таблица 3.

SSH_AGENT_CONSTRAIN_LIFETIME	1
SSH_AGENT_CONSTRAIN_CONFIRM	2
SSH_AGENT_CONSTRAIN_EXTENSION	255

8.3. Флаги подписи

В таблице 4 указаны номера, которые могут присутствовать в запросах подписи (SSH_AGENTC_SIGN_REQUEST). Эти флаги формируют битовое поле (возможно, пустое) с помощью операции OR (или). Значение флага 1 зарезервировано для старых (historical) реализаций.

Таблица 4.

SSH_AGENT_RSA_SHA2_256	0x00000002
SSH_AGENT_RSA_SHA2_512	0x00000004

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

Для этого протокола создаётся 5 реестров: номера типов сообщений, номера ограничений, флаги запросов подписи, имена расширений для ограничений и имена запросов на расширение. Кроме того, добавляются значения в три существующих реестра.

9.1. Рекомендации назначенным экспертам

Когда назначенного эксперта (Designated Expert или DE) просят прорецензировать добавления в новые реестры, описанные здесь (параграфы 9.2, 9.3, 9.5, 9.6), это означает запрос на проверку наличия и общедоступности соответствующих документов, как описано в [RFC8126]. DE также предлагается проверить ясность назначения и использования запрошенных кодов. DE также следует убедиться, что созданные в IETF спецификации, которые запрашивают коды в этих реестрах, доступны для ознакомления рабочей группе SSHM (почтовая конференция ssh@ietf.org). Запросы для кодов из спецификаций, выполненных вне IETF, не должны конфликтовать с активными работами IETF или прежними спецификациями IETF.

Доступное число кодов в реестрах номеров протокола агента SSH (параграф 9.2), номеров ограничений (параграф 9.3) и флагов подписи агента SSH (параграф 9.5) ограничено, поэтому DE должен убедиться, что использование кодов должным образом обосновано. Для номеров сообщений протокола агента SSH именованные запросы на расширения (параграф 9.6) предоставляют для большинства применений практически неограниченное число доступных кодов. Для номеров ограничений для ключей механизм расширения ограничений (параграф 5.2.7.3) также обеспечивает неограниченное число вариантов.

9.2. Реестр SSH Agent Protocol Message Type Numbers

Реестр SSH Agent Protocol Message Type Numbers содержит номера типов сообщений для запросов клиента и откликов агента. Реестр размещается в разделе Secure Shell (SSH) Protocol Parameters [IANA-SSH]. Исходное содержимое реестра привадено в таблице 5, а выделение значений нужно выполнять по процедуре Expert Review [RFC8126].

Таблица 5.

Номер	Идентификатор	Документ
0	Резерв	Параграф 8.1.1 в RFC 9987
1	Резерв	Параграф 8.1.1 в RFC 9987
2	Резерв	Параграф 8.1.1 в RFC 9987
3	Резерв	Параграф 8.1.1 в RFC 9987
4	Резерв	Параграф 8.1.1 в RFC 9987
5	SSH_AGENT_FAILURE	Параграфы 5.1 и 8.1 в RFC 9987
6	SSH_AGENT_SUCCESS	Параграфы 5.1 и 8.1 в RFC 9987
7	Резерв	Параграф 8.1.1 в RFC 9987
8	Резерв	Параграф 8.1.1 в RFC 9987
9	Резерв	Параграф 8.1.1 в RFC 9987
10	Резерв	Параграф 8.1.1 в RFC 9987
11	SSH_AGENTC_REQUEST_IDENTITIES	Параграфы 5.5 и 8.1 в RFC 9987
12	SSH_AGENT_IDENTITIES_ANSWER	Параграфы 5.5 и 8.1 в RFC 9987
13	SSH_AGENTC_SIGN_REQUEST	Параграфы 5.6 и 8.1 в RFC 9987
14	SSH_AGENT_SIGN_RESPONSE	Параграфы 5.6 и 8.1 в RFC 9987
15	Резерв	Параграф 8.1.1 в RFC 9987
16	Резерв	Параграф 8.1.1 в RFC 9987
17	SSH_AGENTC_ADD_IDENTITY	Параграфы 5.2 и 8.1 в RFC 9987
18	SSH_AGENTC_REMOVE_IDENTITY	Параграфы 5.4 и 8.1 в RFC 9987
19	SSH_AGENTC_REMOVE_ALL_IDENTITIES	Параграфы 5.4 и 8.1 в RFC 9987
20	SSH_AGENTC_ADD_SMARTCARD_KEY	Параграфы 5.2.6 и 8.1 в RFC 9987
21	SSH_AGENTC_REMOVE_SMARTCARD_KEY	Параграфы 5.4 и 8.1 в RFC 9987
22	SSH_AGENTC_LOCK	Параграфы 5.7 и 8.1 в RFC 9987
23	SSH_AGENTC_UNLOCK	Параграфы 5.7 и 8.1 в RFC 9987
24	Резерв	Параграф 8.1.1 в RFC 9987
25	SSH_AGENTC_ADD_ID_CONSTRAINED	Параграфы 5.2 и 8.1 в RFC 9987
26	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED	Параграфы 5.2.6 и 8.1 в RFC 9987
27	SSH_AGENTC_EXTENSION	Параграфы 5.8 и 8.1 в RFC 9987
28	SSH_AGENT_EXTENSION_FAILURE	Параграфы 5.8 и 8.1 в RFC 9987
29	SSH_AGENT_EXTENSION_RESPONSE	Параграфы 5.8 и 8.1 в RFC 9987
240-255	Приватное использование	Параграф 8.1.1 в RFC 9987

9.3. Реестр SSH Agent Key Constraint Numbers

Реестр SSH Agent Key Constraint Numbers содержит номера ограничений на использование ключей и размещается в разделе Secure Shell (SSH) Protocol Parameters [IANA-SSH]. Исходное содержимое реестра приведено в таблице 6, а выделение значений нужно выполнять по процедуре Expert Review [RFC8126].

Таблица 6.

Номер	Идентификатор	Документ
0	Резерв	Параграф 8.2 в RFC 9987
1	SSH_AGENT_CONSTRAIN_LIFETIME	Параграф 8.2 в RFC 9987
2	SSH_AGENT_CONSTRAIN_CONFIRM	Параграф 8.2 в RFC 9987
255	SSH_AGENT_CONSTRAIN_EXTENSION	Параграф 8.2 в RFC 9987

9.4. Реестр SSH Agent Key Constraint Extension Names

Реестр SSH Agent Key Constraint Extension Names содержит имена, применяемые в типе расширения ограничений SSH_AGENT_CONSTRAIN_EXTENSION (параграф 5.2.7.3), и размещается в разделе Secure Shell (SSH) Protocol Parameters [IANA-SSH]. Исходно реестр пуст, а выделение значений нужно выполнять по процедуре Expert Review [RFC8126].

9.5. Реестр SSH Agent Signature Flags

Реестр SSH Agent Signature Flags содержит значения флагов запроса подписи (SSH_AGENTC_SIGN_REQUEST) и размещается в разделе Secure Shell (SSH) Protocol Parameters [IANA-SSH]. Исходное содержимое реестра приведено в таблице 7. Отметим, что флаги объединяются побитово операцией OR, все значения флагов должны быть степенями 2, а максимальное значение флага составляет 0x80000000. Новые флаги подписей нужно выделять по процедуре Expert Review [RFC8126].

Таблица 7.

Номер	Идентификатор	Документ
0x01	Резерв	Параграф 8.3 в RFC 9987
0x02	SSH_AGENT_RSA_SHA2_256	Параграф 8.3 в RFC 9987
0x04	SSH_AGENT_RSA_SHA2_512	Параграф 8.3 в RFC 9987

9.6. Реестр SSH Agent Extension Request Names

Реестр SSH Agent Extension Request Names содержит имена, используемые в базовых сообщениях запроса расширений (SSH_AGENTC_EXTENSION), и размещается в разделе Secure Shell (SSH) Protocol Parameters [IANA-SSH]. Исходное содержимое реестра приведено в таблице 8. Новые имена нужно выделять по процедуре Expert Review [RFC8126].

Таблица 8.

Имя расширения	Документ
query	Параграф 5.8.1 в RFC 9987

9.7. Дополнение в реестр Extension Names

Агентство IANA добавило в реестр Extension Names [IANA-SSH-EXT] раздела Secure Shell (SSH) Protocol Parameters [IANA-SSH] значение, приведённое в таблице 9.

Таблица 9.

Имя расширения	Документ
agent-forward	Параграф 7.1 в RFC 9987

9.8. Дополнение в реестр Connection Protocol Channel Request Names

Агентство IANA добавило в реестр Connection Protocol Channel Request Names [IANA-SSH-CHANREQ] раздела Secure Shell (SSH) Protocol Parameters [IANA-SSH] значение, приведённое в таблице 10.

Таблица 10.

Тип запроса	Документ
agent-req	Параграф 7.2 в RFC 9987

9.9. Дополнение в реестр Connection Protocol Channel Types

Агентство IANA добавило в реестр Connection Protocol Channel Types [IANA-SSH-CHANTYPE] раздела Secure Shell (SSH) Protocol Parameters [IANA-SSH] значение, приведённое в таблице 11.

Таблица 11.

Тип канала	Документ
agent-connect	Параграф 7.3 в RFC 9987

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

Агент — это служба, задачей которой является хранение и предоставление учётных данных (обычно долгосрочных) для аутентификации при входе в систему. По своей природе агент является конфиденциальным и доверенным компонентом. Сам протокол агента не включает какой-либо проверки подлинности или транспортной защиты. Возможности взаимодействовать с агентом обычно достаточно, чтобы вызвать агент для выполнения операций с секретным ключом. Поэтому очень важно раскрывать агент только владельцу и его полномочным представителям. В Unix-подобных системах это может обеспечиваться на основе прав доступа к файловой системе для сокета агента и/или проверки подлинности клиента, подключаемого к сокету (например, SO_PEERCRED в некоторых Unix-подобных системах). В Windows доступ к именованным каналам может контролироваться через дескриптор защиты, присваиваемый в момент создания канала.

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

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

Перенаправление доступа к локальному агенту через соединение SSH (раздел 7) по своей сути создаёт транзитивные отношения доверия. Реализациям SSH не следует перенаправлять использование агента по умолчанию, а пользователям не следует перенаправлять использование агента на хост, к которому нет полного доверия, поскольку это может приводить к тому, что злоумышленники на удалённых хостах получат доступ к ключам пользователя. Агентам следует реализовать дополнительные средства контроля за видимостью ключей и их использованием для перенаправленных к агенту соединений, иначе у пользователя будет лишь один вариант для перенаправления к агенту — «всё или ничего».

Реализации ключей в токенах и смарт-картах также требуют осторожности. В некоторых системах к токенам можно обращаться по пути к общей библиотеке (например, библиотеке конкретного модуля PKCS#11), которую нужно загрузить для использования размещенных на устройстве ключей. Загрузка общей библиотеки на большинстве платформ предполагает автоматическое исполнение кода этой библиотеки в адресном пространстве загрузившего её процесса. Для предотвращения загрузки потенциально вредоносного кода агентам с поддержкой ключей из токенов через путь к библиотеке следует убедиться, что загружаться могут лишь библиотеки доверенных поставщиков токенов. Кроме того, агентам следует гарантировать, что загруженный код библиотеки токенов не получит доступа к другим ключам, загруженным в агент, и можно полностью запрещать удаленным клиентам загрузку ключей из токена. Защиту имеющихся ключей от кода библиотеки токенов можно обеспечить путём загрузки этой библиотеки в отдельный процесс для агента и организации вызова агентом операций с токеном для этого процесса через IPC¹.

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

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

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

[FIPS.186-4] NIST, «Digital Signature Standard (DSS)», NIST FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, June 2013, <https://doi.org/10.6028/NIST.FIPS.186-4>.

[FIPS.186-5] NIST, «Digital Signature Standard (DSS)», NIST FIPS 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023, <https://doi.org/10.6028/NIST.FIPS.186-5>.

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

[RFC4251] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4254] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Connection Protocol», RFC 4254, DOI 10.17487/RFC4254, January 2006, <https://www.rfc-editor.org/info/rfc4254>.

[RFC5656] Stebila, D. and J. Green, «Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer», RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.

[RFC8032] Josefsson, S. and I. Liusvaara, «Edwards-Curve Digital Signature Algorithm (EdDSA)», RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

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

[RFC8308] Bider, D., «Extension Negotiation in the Secure Shell (SSH) Protocol», RFC 8308, DOI 10.17487/RFC8308, March 2018, <https://www.rfc-editor.org/info/rfc8308>.

[RFC8332] Bider, D., «Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol», RFC 8332, DOI 10.17487/RFC8332, March 2018, <https://www.rfc-editor.org/info/rfc8332>.

[RFC8709] Harris, B. and L. Velvindron, «Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol», RFC 8709, DOI 10.17487/RFC8709, February 2020, <https://www.rfc-editor.org/info/rfc8709>.

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

[IANA-PUBKEYS] IANA, «Public Key Algorithm Names», <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-SSH] IANA, «Secure Shell (SSH) Protocol Parameters», <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-SSH-CHANREQ] IANA, «Connection Protocol Channel Types», <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-SSH-CHANTYPE] IANA, «Extension Names», <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-SSH-EXT] IANA, «Connection Protocol Channel Request Names», <https://www.iana.org/assignments/ssh-parameters/>.

[RFC4252] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Authentication Protocol», RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

Протокол разработал и впервые реализовал Markus Friedl на основе похожего протокола для агента, поддерживающего устаревший протокол SSH версии 1, разработанного Tatu Ylonen.

Спасибо Simon Tatham, Niels Möller, James Spencer, Simon Josefsson, Matt Johnston, Jakub Jelen, Rich Salz, Caspar Schutijser, Florian Obser, Martin Thomson, Deb Cooley, Tero Kivinen за рецензии и помощь в улучшении документа.

Адрес автора

OpenSSH

Email: djm@openssh.com

URI: https://www.openssh.com/

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

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

nmalykh@protokols.ru

1Inter Process Communications — взаимодействие между процессами. Прим. перев.

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

RFC 9940 Some Key Terms for Network Fault and Problem Management

Опубликовано 11.04.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                     N. Davis, Ed.
Request for Comments: 9940                                         Ciena
Category: Informational                                   A. Farrel, Ed.
ISSN: 2070-1721                                       Old Dog Consulting
                                                                 T. Graf
                                                                Swisscom
                                                                   Q. Wu
                                                                   C. Yu
                                                                  Huawei
                                                              April 2026

Some Key Terms for Network Fault and Problem Management

Некоторые важные термины для сетевых отказов и решения проблем

PDF

Аннотация

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

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

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

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

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

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

1. Введение

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

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

В этом документе обсуждаются термины, имеющие фундаментальное значение для базового понимания вопросов контроля отказов и решения проблем. Хотя концепции «отказов» (fault) и «проблем» (problem) актуальны на всех уровнях технологий Internet, область применения этого документа охватывает сетевой и нижележащие уровни. Документ посвящён именно контролю отказов и решению проблем в сети. Затронуто также понятие «инцидент» (incident), когда это является следствием одной или нескольких проблем и вызывает нарушение работы сетевых служб.

Отметим, что ряд полезных терминов определён в [RFC3877] и [RFC8632]. Определения в данном документе связаны с приведёнными там определениями, но не зависят от них.

2. Использование терминов

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

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

Event — событие
State — состояние
Fault — отказ, сбой
Problem — проблема
Symptom — симптом
Cause — причина
Alert — сигнал тревоги
Alarm — тревожное оповещение

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

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

В этом разделе даны определения ключевых терминов:

параграф 3.1 посвящён терминам, связанным с контекстом систем контроля отказов и решения проблем;
параграф 3.2 содержит определения основных терминов, которые будут использоваться в документах, описывающих элементы систем контроля отказов и решения проблем;
параграф 3.3 содержит определения трёх дополнительных терминов, которые могут быть полезны.

3.1. Связанные с контекстом термины

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

Network Telemetry — сетевая телеметрия

Термин определён в [RFC9232] и описывает процесс сбора оперативных параметров сети, классифицируемых в соответствии с сетевой плоскостью (например, уровнями 3, 2 и 1), откуда они были получены. Данные, собранные процессом сетевой телеметрии, не включают сведений об определениях служб (намерений — intent, в соответствии с параграфом 3.1 в [RFC9315]).

Network Monitoring — мониторинг сети

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

Network Analytics — сетевая аналитика

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

Network Observability — наблюдение за сетью

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

Таким образом, имеется каскад взаимосвязанных процессов:

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

3.2. Основные термины

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

Resource — ресурс

Элемент сетевой системы.

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

Characteristic — характеристика

Наблюдаемый или измеряемый аспект или поведение, связанное с ресурсом.

Характеристика может рассматриваться как основанная на фактах (см. Value), а также на контексте и дескрипторах, которые указывают факты и придают им смысл.
Термин «метрика» (Metric, см. metric в [RFC9417]) служит другим обозначением характеристики и может рассматриваться как аналог термина «переменная» (variable).

Value — значение

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

Change — изменение

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

Не все изменения значимы (см. Relevance).
Восприятие изменений зависит от обнаружения, частоты, точности и детализации выборок, а также от точки зрения.
Возможно, будет полезно уточнить термин как «изменение значения» (Value Change), поскольку английское слово change применяется очень широко.

Event — событие

Смена значения характеристики ресурса в определённый момент времени (короткий интервал).

В отличие от изменения (Change), которое может занимать некоторое время, событие (Event) происходит в конкретный момент. Событием может быть наблюдение (фиксация) изменений.

Condition — условия, состояние

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

State — состояние, статус

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

Хотя состояние может наблюдаться в определённый момент времени, фактически оно определяется обобщением измерений за некоторый интервал времени, что иногда называют сжатием состояния.
Может оказаться полезным уточнять этот термин как «состояние ресурса», чтобы отличать от других использований термина state, таких как «состояние протокола» (protocol state).
Этот термин можно противопоставить «оперативному состоянию» (operational state) из [RFC8342]. Например, состояние канала может быть up/down/degraded, но его оперативное состояние будет включать набор значений характеристик канала.

Detect (hence Detected, Detection) — обнаружение (обнаруженный)

Фиксация наличия чего-либо (State, Change, Event, действия и т. д.).

Это также означает фиксацию изменения (с точки зрения наблюдателя, например, системы мониторинга).

Relevance — релевантность (взаимосвязь)

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

Применимы также термины «релевантные события», «релевантные состояния», «релевантные значения».

Occurrence — произошедшее (событие, состояние и т. п.)

Релевантное событие или конкретное изменение.

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

Fault — отказ, сбой

Нежелательное и ненужное произошедшее (событие или изменение), которое может указывать текущее или будущее нежелательное состояние. Отказ возникает в определённый момент времени и может быть связан с причиной (Cause). Более подробное рассмотрение сетевых отказов приведено а [RFC8632].

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

Problem — проблема

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

Отметим, что с понятием «проблема» связан исторический аспект. Текущее состояние может рабочим, но при этом могут присутствовать непонятные отказы, сам факт наличия которых является проблемой.
Пока проблема не решена, она может продолжать требовать внимания. Записи о решённых проблемах могут поддерживаться в журнале (log).
Состояние может рассматриваться как проблема с нескольких точек зрения. Рассмотрим, например, «потерю света» (loss of light), которая может приводить к отказам многих служб. В этом примере новое состояние (восстановление света) может решать проблему с одной точки зрения (службы снова работают), но оставить её нерешённой с другой точки зрения (причина пропадания не была выяснена). Кроме того, в этом примере возможно иное развитие событий, когда проблема была решена (микроизгиб волокна, который был устранён), но при этом остаётся ещё одна проблема — непонятно, почему произошёл изгиб — и она осталась нерешенной.

Cause — причина

События (обнаруженные или нет) вызвавшие возникновение отказа или проблемы.

Incident — инцидент

Используется также термин «сетевой инцидент» (Network Incident). Нежелательное событие или состояние (Occurrence), такое как неожиданное прерывание работы сетевой службы или падение производительности службы ниже целевого уровня. Инцидент ведёт к возникновению одной или нескольких проблем, а проблемы могут вызывать один или несколько инцидентов и влиять на возникшие инциденты. Более подробное обсуждение взаимосвязей сетевых инцидентов, включая клиентские инциденты и контроль инцидентов, приведено в [Net-Incident-Mgmt-YANG].

Symptom — симптом

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

Anomaly — аномалия

Используется также термин «сетевая аномалия» (Network Anomaly). Необычное или неожиданное событие или картина поведения сетевых данных в плоскости пересылки или плоскости управления, отличающиеся от обычного, ожидаемого поведения. Дополнительная информация приведена в [Net-Anomaly-Arch].

Alert — сигнал тревоги

Индикация отказа (сбоя).

Alarm — тревожное оповещение

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

3.3. Прочие термины

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

Intermittent — прерывистое

Состояние, которое не является непрерывным, но повторяется в течение некого интервала времени.

Transient — временное

Состояние, которое не является непрерывным и происходит однократно в неком интервале времени.

Recurrent — повторяющееся

Проблема, которую активно решают, но она повторяется

4. Рабочие процессы

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

На рисунке 1 показана связь между ресурсами и характеристиками. Отметим соотношение 1:n между сетевой системой и ресурсами, а также между ресурсами и характеристиками (для простоты это не показано на рисунке).

Характеристики
       ^
       |
    Ресурсы
       ^
       |
Сетевая система

Рисунок 1. Ресурсы и характеристики.

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

        Событие             Состояние               Значение
                             Условие
           ^                    ^                      ^
Обнаружение:         Обнаружение:           Обнаружение:
           :                    :                      :

      ^        ^          ^     ^     ^                   /\
      :        :          :     :     :                  /  \
      :        :          :     :     :             /\  /    \
       __    __               _____                /  \/
      |        |             |     |            /\/
    __|        |__       ____|     |____       /

Изменение со временем  Изменение со временем  Изменение со временем

Рисунок 2. Характеристики и обновления.

На практике изменение характеристик со временем может быть аналоговым, как показано в правой части рисунка 2. Значение может считываться или сообщаться (обнаруживаться) периодически, что даёт аналоговые значения, которые могут считаться связанными (Relevant) или оцениваться с течением времени, как показано на рисунке 6.

На рисунке 3 показан рабочий процесс для события. Как отмечено выше, событие является изменением значения характеристики в определённый момент. Событие может быть оценено (с учётом правил, с конкретной точки зрения, с учётом намерений и в связи с другими событиями, состояниями и значениями) для определения, является ли это произошедшим (Occurrence) или может указывать изменение состояния. Произошедшее может быть нежелательным (отказ) и может приводить к генерации сигнала тревоги (Alert). Это может быть также свидетельством наличия проблемы и напрямую указывать причину. В некоторых случаях может подаваться сигнал тревоги для оповещения (Alarm) об имеющейся или возможной проблеме.

Сигнал - - - > Оповещение
    ^
    |
    |     -----> Причина
    |    |
    |----------> Проблема
    |
    |
  Отказ
    ^
    |
    |
    |
Произошедшее
    ^
    |
    |----------> Состояние
    |
    |
 Событие

Рисунок 3. Событие и связанные термины.

На рисунке 4 показан рабочий процесс для состояний. Как показано на рисунке 2, изменение, отмеченное в определённый момент, вызывает состояние. Состояние может считаться значимым (Relevance) в плане правил, с конкретной точки зрения, с учётом намерений и в связи с другими событиями, состояниями и значениями. Релевантное состояние может считаться проблемой или указывать наличие или возможность возникновения проблемы.

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

Сигнал - - -> Оповещение
   ^
   |     ------> Инцидент
   |    |
   |    |   ---> Причина
   |    |  |
Проблема--------> Симптом
   ^
   |
   | Взаимосвязь
   |
   |
Состояние

Рисунок 4. Состояние и связанные термины.

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

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

                                  ---------
                   ------------- |         |
                  |  ----------> | Симптом |
                  | |            |         |
                  | |             ---------
                  v |                 ^
               ---------              |
      ------->| Причина |<---------   |
     |         ---------           |  |
     |           ^   |             |  |
     |           |   |             |  |
     |            ---              |  |
     |                             |  |
 ---------                      ---------          ----------
|  Отказ  |------------------->|Проблема |------->| Инцидент |
 ---------                      ---------          ----------

Рисунок 5. Консолидация симптомов и причин.

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

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

Произошедшее
     ^
     |
     |---------------------> Состояние
     |
     |        -------                  Взаимосвязь
     |------>|Счётчик|-----------------------------> Значение
     |        -------          |                       ^
     |           |             |                       |
     |           |             |                       | Взаимосвязь
     |           |             v                       |
     |           |        -----------           ----------------
  Событие        |       | Оценка во |         |                |
     ^           |       |  времени  |<--------|   Аналоговое   |
     |           v        -----------          |    значение    |
     |      -----------        |               |                |
     |     | Пороговый |       |               |                |
     |<----|  процесс  |<------                |                |
     |     |           |<----------------------|                |
     |      -----------                         ----------------
     |                                                 ^
     |                                                 |
     | Обнаружение                         Обнаружение |
     |                                                 |
Изменение во времени                            Изменение во времени

Рисунок 6. Счётчики, пороги и значения.

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

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

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

6. Вопросы приватности

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

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

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

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

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

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

[Net-Anomaly-Arch] Graf, T., Du, W., Francois, P., and A. Huang Feng, «A Framework for a Network Anomaly Detection Architecture», Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly-architecture-06, 21 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-architecture-06>.

[Net-Incident-Mgmt-YANG] Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, «A YANG Data Model for Network Incident Management», Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-08, 13 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-08>.

[RFC3877] Chisholm, S. and D. Romascanu, «Alarm Management Information Base (MIB)», RFC 3877, DOI 10.17487/RFC3877, September 2004, <https://www.rfc-editor.org/info/rfc3877>.

[RFC6632] Ersue, M., Ed. and B. Claise, «An Overview of the IETF Network Management Standards», RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/info/rfc6632>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8632] Vallin, S. and M. Bjorklund, «A YANG Data Model for Alarm Management», RFC 8632, DOI 10.17487/RFC8632, September 2019, <https://www.rfc-editor.org/info/rfc8632>.

[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, «Network Telemetry Framework», RFC 9232, DOI 10.17487/RFC9232, May 2022, <https://www.rfc-editor.org/info/rfc9232>.

[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, «Intent-Based Networking — Concepts and Definitions», RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/info/rfc9315>.

[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, «Service Assurance for Intent-Based Networking Architecture», RFC 9417, DOI 10.17487/RFC9417, July 2023, <https://www.rfc-editor.org/info/rfc9417>.

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

Авторы благодарны Med Boucadair, Wanting Du, Joe Clarke, Javier Antich, Benoit Claise, Christopher Janz, Sherif Mostafa, Kristian Larsson, Dirk Von Hugo, Carsten Bormann, Hilarie Orman, Stewart Bryant, Bo Wu, Paul Kyzivat, Jouni Korhonen, Reshad Rahman, Rob Wilton, Mahesh Jethanandani, Tim Bray, Paul Aitken, and Deb Cooley за их полезные замечания.

Особая благодарность команде конференции IETF 120, собравшейся для обсуждения острых вопросоы:

Benoit Claise

Watson Ladd

Brad Peters

Bo Wu

Georgios Karagiannis

Olga Havel

Vincenzo Riccobene

Yi Lin

Jie Dong

Aihua Guo

Thomas Graf

Qin Wu

Chaode Yu

Adrian Farrel

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

Nigel Davis (editor)

Ciena

United Kingdom

Email: ndavis@ciena.com

Adrian Farrel (editor)

Old Dog Consulting

United Kingdom

Email: adrian@olddog.co.uk

Thomas Graf

Swisscom

Binzring 17

CH-8045 Zurich

Switzerland

Email: thomas.graf@swisscom.com

Qin Wu

Huawei

101 Software Avenue, Yuhua District

Nanjing

Jiangsu, 210012

China

Email: bill.wu@huawei.com

Chaode Yu

Huawei

Email: yuchaode@huawei.com

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

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

nmalykh@protokols.ru

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

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

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

Доступ на сайт с внешними учётными записями

Опубликовано 03.04.2026 автором Nikolai Malykh

Настроена возможность входа на сайт с учетными записями других служб (соцсетей). Пока возможен вход лишь по Yandex ID и Google ID, но со временем список может быть расширен. Это позволит комментировать публикации и писать что-либо от себя, не регистрируясь на сайте.

Для входа достаточно воспользоваться ссылкой «Войти» (здесь или под заголовком Мета справа внизу на любой странице сайта) и выбрать в нижней части окна входа значок Yandex () или Google ()

Рубрика: RFC | 1 комментарий

RFC 9938 A Framework for the Deterministic Networking (DetNet) Controller Plane

Опубликовано 18.03.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          A. Malis
Request for Comments: 9938                                   Independent
Category: Informational                                     X. Geng, Ed.
ISSN: 2070-1721                                           M. (Guoyi)Chen
                                                                  Huawei
                                                                B. Varga
                                                                Ericsson
                                                           CJ. Bernardos
                                                                    UC3M
                                                              March 2026

A Framework for the Deterministic Networking (DetNet) Controller Plane

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

PDF

Аннотация

В этом документе приведён обзор модели плоскости контроллера детерминированной сети (Deterministic Networking или DetNet). Рассмотрены концепции и требования к плоскости контроллера DetNet, которые могут стать основой для будущей спецификации.

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

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

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

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

1. Введение

Детерминированная сеть (Deterministic Networking или DetNet) обеспечивает возможность передачи конкретных индивидуальных и групповых потоков данных с экстремально низкими потерями и гарантией сквозной задержки не более заданного значения. Описание основ и концепций DetNet приведено в [RFC8655].

Плоскость данных DetNet определена в документе «DetNet data plane framework» [RFC8938] и дополнительно разъяснена в DetNet MPLS [RFC8964], DetNet IP [RFC8939] и [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056].

Следует отметить, что в базовой архитектуре DetNet плоскость контроллера включает компоненты, обычно рассматриваемые как отдельные плоскости управления и обслуживания (см. параграф 4.4.2 в [RFC8655]). Плоскость обслуживания (management) связана в основном с обработкой отказов, настройкой конфигурации и управлением производительностью (иногда сюда включают учёт и безопасность, см. параграф 4.2 в [RFC6632], но это выходит за рамки данного документа). Плоскость управления отвечает в основном за организацию и поддержку потоков, выделение и распространение меток MPLS, а также активную сигнализацию по основному (in-band) или отдельному (out-of-band) каналу для поддержки функций DetNet. В архитектуре DetNet все эти функции объединяются в одну плоскость контроллера. Более подробное рассмотрение агрегирования плоскостей управления и администрирования приведено в [RFC8655] и параграфе 4.4.2 [RFC7426].

Хотя документы по архитектуре и плоскости данных DetNet сосредоточены в основном на операциях плоскости данных, они включают некоторые требования и соображения в части функций, требуемых для автоматизации предоставления и мониторинга службы DetNet через плоскость контроллера DetNet (например, раздел 4 в [RFC8938]). Цель данного документа состоит в объединении таких требований и соображений в цельный документ с обсуждением использования различных архитектур DetNet Controller Plane для исполнения этих требований без детализации протокола плоскости контроллера DetNet. Протокольные решения для плоскости контроллера будут рассмотрены в последующих документах, а данный документ можно считать справочником, который следует принимать во внимание при разработке протоколов DetNet Controller Plane.

2. Требования к плоскости контроллера DetNet

В других документах DetNet, включая [RFC8655], [RFC8938], [RFC9551] и [RFC9055], среди прочих вопросов рассматриваются требования к плоскости контроллера, которые для удобства собраны здесь. Требования организованы в три группы: 1) применимые в основном к плоскости управления, 2) применимые в основном к плоскости администрирования и 3) применимые к обеим плоскостям. Требования безопасности для плоскости контроллера DetNet рассмотрены в [RFC9055] и сводка этих требований приведена в параграфе 2.3. Там, где это применимо, в текст включены ссылки на документ, в котором требование было внесено.

2.1. Требования к плоскости управления DetNet

Ниже перечислены основные требования к плоскости контроллера DetNet.

Поддержка динамической организации, изменения и удаления потоков DetNet. Это может включать частично или полностью явное задание пути, резервирование пропускной способности, привязку потоков к конкретным каналам (например, каналам IEEE 802.1 TSN³), резервирование буферов и других ресурсов на узлах, задание требуемой дисциплины очередей, способность поддерживать двухсторонние потоки и другие свойства, нужные для потоков [RFC8938].
Поддержка агрегирования и деагрегирования потоков DetNet путём динамического создания и удаления агрегатов (flow aggregate или FA), а также изменения имеющихся FA путём добавления или исключения участвующих в них потоков [RFC8938].
Поддержка запросов на создание потоков от конечных приложений (через API⁴, статическое предоставление или динамическую плоскость управления, такую как контроллер SDN⁵ или распределенные протоколы сигнализации). Эти варианты более подробно рассматриваются в разделе 3.
Поддержка выделения и распространения [RFC8938] для плоскости данных DetNet MPLS меток S-Label, F-Label, A-Label [RFC8964]
Поддержка подуровня служб DetNet (в том числе для плоскости данных DetNet MPLS), обеспечивающего функции DetNet, такие как защита и переупорядочивание с применением функций PREOF⁶ [RFC8655].
Поддержка дисциплин управления очередями, заданных в параграфе 4.5 [RFC8655] и [RFC9320], которые требуют синхронизации часов на узлах плоскости данных.
Анонсирование статических и динамических характеристик узлов и каналов связи, таких как возможности и смежность, другим узлам сети (динамическая сигнализация) или контроллерам (централизованная модель) [RFC8938].
Масштабирование для поддержки ожидаемого числа потоков DetNet в домене, для чего может потребоваться сигнализация и обеспечение на уровне потока [RFC8938].
Предоставление сведений для идентификации потоков на каждом узле пути. Идентификация может зависеть от местоположения в сети и функциональности DetNet (например, на транзитных узлах и ретрансляторах) [RFC8938].

2.2. Требования к плоскости обслуживания DetNet

Основные требования к плоскости обслуживания DetNet приведены ниже.

Мониторинг производительности потоков и узлов DetNet для обеспечения соответствия требуемым целям как в проактивном режиме, так и по запросам [RFC9551].
Поддержка функций контроля непрерывности потоков DetNet и верификации связности [RFC9551].
Поддержка тестирования и мониторинга функций PREOF в домене DetNet [RFC9551].

2.3. Требования к обеим плоскостям

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

Работа в домене сети, включающем потоки DetNet и иные потоки [RFC8655].
Адаптация к изменениям топологии домена DetNet, таким как отказы, добавление и исключение каналов или узлов [RFC8655].

В дополнение к этому плоскости контроллера DetNet следует также выполнять вытекающие из [RFC9055] требования безопасности, которые задают модель безопасности для DetNet. Особенно важны указанные ниже требования.

Целостность и подлинность управляющих и сигнальных пакетов.

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

Защита от компрометации контроллера.

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

Безопасность системы в целом

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

Своевременная доставка сообщений плоскости управления

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

3. Архитектура плоскости управления DetNet

Как отмечено во введении, плоскость управления DetNet отвечает за организацию и поддержку потоков, создание и распространение сведений о потоках (например, меток MPLS), активное распространение (в основной полосе или по отдельному каналу) информации для поддержки этих функций.

В последующих разделах определяются три варианта архитектуры плоскости управления DetNet: 1) полностью распределенная архитектура с использованием протоколов динамической сигнализации 2) полностью централизованная архитектура в стиле SDN, 3) гибридная архитектура, включающая распределенную и централизованную плоскость управления. В документе рассматриваются различные способы обмена информацией для каждого типа архитектуры с указанием их преимуществ и недостатков.

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

3.1. Распределенная плоскость управления и протоколы сигнализации

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

Рассмотрим в качестве примера сеть MPLS RSVP-TE [RFC3209], где конечные системы не входят в домен DetNet.

Узлы сети собирают данные топологии и сведения о возможностях DetNet на узлах сети по протоколу IGP⁸.
Входной граничный узел получает запрос на создание потока от UNI и рассчитывает один или несколько путей.
Входной узел передаёт сообщение PATH с явным маршрутом через RSVP-TE. После получения сообщения PATH выходной граничный узел отправляет сообщение RESV с распределяемой меткой и запросом на резервирование ресурсов.

В этом примере для протоколов IGP и RSVP-TE могут потребоваться расширения для DetNet.

3.2. Централизованная плоскость управления

В полностью централизованной модели конфигурации (например, с контроллером SDN) информация о потоке и UNI может передаваться от центрального контроллера или от других приложений через API или северный интерфейс центральному контроллеру. Настройку узлов сети для потоков DetNet выполняет контроллер с использованием такого протокола, как NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], или основанного на PCE центрального контроллера (PCE-based central controller или PCE-CC) [RFC8283].

Пример такой конфигурации приведён ниже.

Контроллер собирает данные о топологии и возможностях DetNet на узлах сети по протоколу NETCONF/YANG.
Контроллер получает запрос на организацию потока от UNI и находит один или несколько путей через сеть.
Контроллер выбирает оптимальный путь и настраивает устройства на нем для передачи потока DetNet через PCE-CC.

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

3.3. Гибридная плоскость управления

В гибридной модели протоколы плоскости управления и контроллер совместно обеспечивают работу служб DetNet. Здесь возможно много разных комбинаций. Ниже приведён пример совместного применения RSVP-TE и контроллера.

Контроллер собирает данные о топологии и возможностях узлов DetNet по протоколу IGP и/или BGP-LS (Border Gateway Protocol — Link State) [RFC9552].
Контроллер получает запрос на организацию потока через API и находит один или несколько путей через сеть.
По результатам расчёта контроллер распространяет сведения о пути для потока входным граничным узлам и настраивает узлы сети на пути по информации DetNet (например, репликацию и исключение дубликатов).
Граничный входной узел с помощью RSVP-TE передаёт сообщение PATH с явным маршрутом. После получения PATH выходной граничный узел отправляет сообщение RESV с распространяемой меткой и запросом резервирования ресурсов.

Имеется много других вариантов организации гибридной плоскости управления. Расширения DetNet для протоколов — задача для будущей работы.

4. Плоскость управления DetNet для механизмов DetNet

В этом разделе рассматриваются запрашиваемые функции плоскости управления для механизмов DetNet, заданных в [RFC8655], включая PREOF. Службы DetNet могут реализовать все или часть функций в зависимости от потребностей.

4.1. Явные пути

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

Path computation — расчёт пути

Явные пути DetNet нужны для исполнения требований соглашения об обслуживании (Service Level Agreement или SLA) приложения, которые включают пропускную способность, максимальную сквозную задержку и её максимальные вариации, максимальный уровень потерь и т. п. В распределенной системе можно использовать IGP с алгоритмом CSPF⁹ для поиска кратчайшего пути с учётом ограничений. В централизованной системе контроллер может рассчитывать пути в соответствии с требованиями DetNet на основе данных, собранных в домене DetNet.

Path establishment — организация пути

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

4.2. Резервирование ресурсов

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

Resource Allocation — выделение ресурсов

Пропускная способность порта — один из базовых атрибутов сетевого устройства, который легко получить или рассчитать. В современных реализациях управления трафиком выделение ресурсов является синонимом выделения пропускной способности. Поток DetNet характеризуется спецификацией трафика, как указано в [RFC9016], включая такие атрибуты, как Interval, MaxPacketsPerInterval, MaxPayloadSize. Спецификация трафика описывает наихудшие, а не средние условия, чтобы обеспечить резервирование достаточной пропускной способности и буферной ёмкости для трафика. Однако в случае DetNet выделение ресурсов — это не только резервирование пропускной способности. Например, может потребоваться также выделение буферов и задание дисциплины очередей при пересылке. Кроме того, требуется обеспечить на узле ресурсы для выполнения функций сервисного подуровня DetNet, таких как защита и переупорядочивание с использованием PREOF.

Конфигурация устройства с дискриминацией потоков и без неё

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

4.3. Поддержка PREOF

Резервирование (избыточность) путей DetNet поддерживается с помощью функций PREOF. Поток DetNet реплицируется и передаётся по нескольким путям, чтобы избежать потери пакетов в результате отказа узлов или каналов. В общем случае имеющиеся механизмы плоскости управления, которые могут служить для (распределенной или централизованной) организации явного пути, поддерживают пути «точка-точка» (point-to-point или P2P) и многоточечные (point-to-multipoint или P2MP). PREOF требует возможности расчёта и организации набора путей (например, множества сегментов LSP¹⁰ в сети MPLS) из точек репликации пакетов в точки слияния и упорядочения. Требуется также сопоставление потоков DetNet или их номеров с сегментами явного пути. Для поддержки таких функций потребуются расширения протокола. Нужна также терминология для обозначения скоординированного набора сегментов пути (например, граф LSP для плоскости данных DetNet MPLS).

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

4.4.1. DetNet в домене MPLS

В этом документе термин «традиционная (legacy) MPLS» означает MPLS без применения маршрутизации по сегментам (Segment Routing, см. параграф 4.4.3) или транспортного профиля MPLS (Transport Profile или MPLS-TP) [RFC5960].

В традиционном домене MPLS для распространения меток, по которым пересылаются пакеты MPLS, обычно используется распределенный сигнальный протокол плоскости управления. Наиболее часто применяемыми протоколами динамической сигнализации для распространения меток являются LDP [RFC5036], RSVP-TE [RFC4875] и BGP [RFC8277] (поддержка основанных на BGP MPLS VPN L3 [RFC4384], L2 [RFC4664] и EVPN [RFC7432]). Любые из этих протоколов можно применять для распространения меток службы DetNet (Service Label или S-Label) и меток агрегирования (Aggregation Label или A-Labels) [RFC8964]. Как указано в [RFC8938], S-Label похожи на другие метки служб MPLS, таких как псевдопровода, L3 VPN и L2 VPN, и могут распространяться похожим способом, например, с помощью целевого LDP или BGP. При использовании в DetNet нужны расширения для поддержки специфичных для DetNet функций, таких как PREOF, A-Label, выделение ресурсов на узле, размещение в очереди.

4.4.2. DetNet в домене IP

В этом документе термин «традиционный (legacy) IP» означает IP без применения маршрутизации по сегментам (Segment Routing, см. параграф 4.4.3). Следует отметить, что плоскость данных DetNet IP [RFC8939] проще, чем DetNet MPLS [RFC8964], и не поддерживает PREOF, поэтому требуется лишь один путь для потока или агрегата потоков. Предполагается, что возможные расширения протоколов будут ограничиваться, например, имеющимися протоколами маршрутизации IP.

4.4.3. DetNet в домене Segment Routing

Маршрутизация по сегментам [RFC8402] предлагает расширяемый подход к построению сетевых доменов, обеспечивающий явную маршрутизацию с помощью заданных отправителем маршрутов, кодируемых в заголовках пакетов, и сочетающийся с централизованным управлением для расчёта путей через сеть. Пути пересылки распространяются вместе со связанными с ними правилами по граничным узлам сети для использования в заголовках пакетов. Маршрутизация по сегментам сокращает объем сигнальной информации, связанной с распределенными протоколами сигнализации (например, RSVP-TE), а также снижает число состояний в узлах ядра по сравнению с требуемыми для традиционной маршрутизации MPLS и IP, поскольку состояния содержатся в пакетах, а не в маршрутизаторах. Это может оказаться полезным для DetNet с большим числом потоков через сеть, где в ином случае пришлось бы держать экземпляр состояния для каждого потока на каждом узле сети.

Отметим, что плоскости данных DetNet MPLS и IP, описанные в [RFC8964] и [RFC8939], разрабатывались для совместимости с обоими типами маршрутизации по сегментам: SR-MPLS (Segment Routing over MPLS) [RFC8660] и SRv6 (Segment Routing over IPv6) [RFC8754] [RFC8986].

4.5. Поддержка метаданных и инкапсуляции

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

Плоскости контроллера нужно понимать возможности сетевых узлов в части поддержки инкапсуляции и метаданных и управлять ими для эффективной работы потоков DetNet. Этот процесс может включать этап обнаружения, где контроллер определяет поддерживаемые каждым узлом типы инкапсуляции (например, MPLS, IP) и схемы метаданных (например, упорядочивание, метки времени). После обнаружения контроллер может дать узлам указания в части конкретной инкапсуляции и метаданных для данного потока. Это обеспечит соответствующее обслуживание пакетов DetNet в сети. Например, контроллер может дать узлу указание использовать заголовок MPLS и добавлять порядковый номер для конкретного потока.

5. Обзор плоскости обслуживания

Плоскость обслуживания (management) включает возможность статического выделения узлов сети и использования OAM¹¹ для мониторинга производительности и обнаружения сбоев и иных проблем на уровне DetNet.

5.1. DetNet OAM

В этом документе рассматриваются общие вопросы, связанные с OAM.

5.1.1. OAM для мониторинга производительности

5.1.1.1. Активный мониторинг

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

5.1.1.2. Пассивный мониторинг

При пассивном мониторинге (например, In Situ Operations, Administration, and Maintenance (IOAM) [RFC9197]), отслеживается фактический трафик службы в рамках домена для измерения производительности без негативного влияния на сеть. Пассивный мониторинг является предпочтительным для доменов DetNet.

5.1.2. OAM для поддержки связности и контроля отказов

Детальные требования к CFM¹² в доменах DetNet IP и DetNet MPLS приведены в [RFC9551], [RFC9634] и [RFC9546].

6. Работа в нескольких доменах

При участии нескольких доменов разные функции плоскости контроллера (Controller Plane Function или CPF) будут взаимодействовать для исполнения запросов, полученных от элементов управления потоками (Flow Management Entity или FME) [RFC8655], на уровне потока, на уровне этапа пересылки (hop) в узлах DetNet для каждого отдельного потока. Добавление поддержки множества доменов может потребовать некоторой поддержки на уровне CPF. Например, CPF разных доменов (скажем, PCE) должны будут обнаруживать друг друга, а затем аутентифицироваться и согласовывать поведение на уровне этапа пересылки. Кроме того, в беспроводных доменах требуется также учитывать функции на уровне домена, обеспечивающие надёжность и доступность беспроводной связи (Reliable and Available Wireless или RAW) [RAW-ARCH], такие как точки локального восстановления (Point of Local Repair или PLR), в дополнение к PCE. В зависимости от поддержки множества доменов плоскостью приложений плоскость контроллера может быть освобождена от некоторых обязанностей (например, плоскость приложений может взять на себя распределение обязанностей между доменами).

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

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

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

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

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

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

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, «Deterministic Networking Architecture», RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane Framework», RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.

[RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, «Flow and Service Information Model for Deterministic Networking (DetNet)», RFC 9016, DOI 10.17487/RFC9016, March 2021, <https://www.rfc-editor.org/info/rfc9016>.

[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, «Deterministic Networking (DetNet) Security Considerations», RFC 9055, DOI 10.17487/RFC9055, June 2021, <https://www.rfc-editor.org/info/rfc9055>.

[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, CJ., Varga, B., and J. Farkas, «Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)», RFC 9551, DOI 10.17487/RFC9551, March 2024, <https://www.rfc-editor.org/info/rfc9551>.

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

[RAW-ARCH] Thubert, P., Ed., «Reliable and Available Wireless Architecture», Work in Progress, Internet-Draft, draft-ietf-raw-architecture-30, 25 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-30>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC4384] Meyer, D., «BGP Communities for Data Collection», BCP 114, RFC 4384, DOI 10.17487/RFC4384, February 2006, <https://www.rfc-editor.org/info/rfc4384>.

[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., «Extensions to Resource Reservation Protocol — Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)», RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., «LDP Specification», RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.

[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., «MPLS Transport Profile Data Plane Architecture», RFC 5960, DOI 10.17487/RFC5960, August 2010, <https://www.rfc-editor.org/info/rfc5960>.

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

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

[RFC6632] Ersue, M., Ed. and B. Claise, «An Overview of the IETF Network Management Standards», RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/info/rfc6632>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, «Software-Defined Networking (SDN): Layers and Architecture Terminology», RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

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

[RFC8277] Rosen, E., «Using BGP to Bind MPLS Labels to Address Prefixes», RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.

[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, «An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control», RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing Architecture», RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing with the MPLS Data Plane», RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, «IPv6 Segment Routing Header (SRH)», RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP», RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.

[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: MPLS», RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, «Segment Routing over IPv6 (SRv6) Network Programming», RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)», RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>.

[RFC9024] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, «Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS», RFC 9024, DOI 10.17487/RFC9024, June 2021, <https://www.rfc-editor.org/info/rfc9024>.

[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP», RFC 9025, DOI 10.17487/RFC9025, April 2021, <https://www.rfc-editor.org/info/rfc9025>.

[RFC9037] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)», RFC 9037, DOI 10.17487/RFC9037, June 2021, <https://www.rfc-editor.org/info/rfc9037>.

[RFC9056] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: IP over MPLS», RFC 9056, DOI 10.17487/RFC9056, October 2021, <https://www.rfc-editor.org/info/rfc9056>.

[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., «Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)», RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.

[RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, «Deterministic Networking (DetNet) Bounded Latency», RFC 9320, DOI 10.17487/RFC9320, November 2022, <https://www.rfc-editor.org/info/rfc9320>.

[RFC9546] Mirsky, G., Chen, M., and B. Varga, «Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane», RFC 9546, DOI 10.17487/RFC9546, February 2024, <https://www.rfc-editor.org/info/rfc9546>.

[RFC9552] Talaulikar, K., Ed., «Distribution of Link-State and Traffic Engineering Information Using BGP», RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/info/rfc9552>.

[RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, «Deterministic Networking (DetNet) YANG Data Model», RFC 9633, DOI 10.17487/RFC9633, October 2024, <https://www.rfc-editor.org/info/rfc9633>.

[RFC9634] Mirsky, G., Chen, M., and D. Black, «Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane», RFC 9634, DOI 10.17487/RFC9634, October 2024, <https://www.rfc-editor.org/info/rfc9634>.

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

Спасибо Jim Guichard, Donald Eastlake 3rd, Stewart Bryant за рецензии и комментарии.

Авторы признательны также Deb Cooley, Mike Bishop, Mohamed Boucadair, Gorry Fairhurst и Dave Thaler за комментарии в процессе рецензирования IESG.

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

Fengwei Qin

China Mobile

Email: qinfengwei@chinamobile.com

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

Andrew G. Malis

Independent

Email: agmalis@gmail.com

Xuesong Geng (editor)

Huawei

Email: gengxuesong@huawei.com

Mach (Guoyi)Chen

Huawei

Email: mach.chen@huawei.com

Balazs Varga

Ericsson

Email: balazs.a.varga@ericsson.com

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

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

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

nmalykh@protokols.ru

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

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

3Time-Sensitive Networking — чувствительные к времени сети.

4Application Programming Interface — интерфейс с прикладными программами.

5Software-Defined Networking — программно-управляемая сеть.

6Packet Replication, Elimination, and Ordering Functions — функции репликации, исключения и упорядочивания пакетов

7User-Network Interface — интерфейс между пользователем и сетью.

8Internal Gateway Protocol — протокол внутренней маршрутизации. Прим. перев.

9Constrained Shortest Path First — сначала кратчайший путь (с ограничениями).

10Label Switched Path — путь с коммутацией по меткам.

11Operations, Administration, and Maintenance — эксплуатация, администрирование и (техническое) обслуживание.

12Connectivity and Fault Management — управление связностью и контроль отказов.

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

RFC 9925 Unsigned X.509 Certificates

Опубликовано 28.02.2026 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                       D. Benjamin
Request for Comments: 9925                                    Google LLC
Updates: 5280                                              February 2026
Category: Standards Track                                               
ISSN: 2070-1721

Unsigned X.509 Certificates

Сертификаты X.509 без подписи

PDF

Аннотация

Этот документ определяет заменитель алгоритма подписи X.509, который может применяться в контексте, где не предполагается проверка подписи получателем. В этой части данный документ обновляет RFC 5280.

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

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

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

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

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

1. Введение

Сертификат X.509 [RFC5280]связывает две сущности PKI — сведения о субъекте и подтверждение от эмитента. Рассматривая PKI как граф с сущностями в качестве узлов, как в [RFC4158], сертификат можно считать границей между субъектом и эмитентом.

В некоторых случаях приложению нужна лишь информация о субъекте, а не сертификат (в модели с графом — узел, а не ребро). Например, проверка пути сертификации (раздел 6 в [RFC5280]) начинается с привязки доверия, которую иногда называют корнем удостоверяющего центра (root certification authority или root CA). Приложение доверяет сведениям об этой привязке без проверки через сеть (out-of-band) и не требует подписи эмитента.

X.509 не задаёт структуру для таких случаев и взамен привязки доверия X.509 зачатую представляются «самоподписанными» сертификатами, где ключи субъекта подписан им самим. Имеются и другие форматы (например, [RFC5914]) передачи привязок доверия, но по-прежнему широко применяются самоподписанные сертификаты.

Кроме того, в некоторых внедрениях серверов TLS [RFC8446] применяются самоподписанные сертификаты конечных сущностей (элементов), когда те не предназначены для представления выданных CA идентификаторов и предполагается, что принимающая сторона проверяет сертификат несетевыми (out-of-band) средствами, например, по известному отпечатку (fingerprint).

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

Расчёт подписей-заменителей имеет ряд недостатков:

постквантовые алгоритмы подписей слишком громоздки и включение самоподписи значительно повышает размер передаваемых данных;
если субъектом является конечный элемент (сущность), а не CA, расчёт подписей X.509 ведёт к риску кросс-протокольных атак с предусмотренным использованием ключа;
неясно, требует ли такая самоподпись установки бита CA в базовых ограничениях или keyCertSign при использовании ключей; если ключ предназначен для приложений, отличных от X.509, такие возможности могут приводить к неоправланному риску;
если субъектом является конечный элемент (сущность) и его ключ не является ключом подписи (например, ключ Key Encapsulation Mechanism или KEM), не существует алгоритма подписи для применения с ключом.

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

2. Уровни требований

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

3. Создание сертификата без подписи

В этом разделе рассматривавется создание отправителем сертификата без подписи.

3.1. Подпись

Для создания сертификата X.509 без подписи отправитель должен указать в поле сертификата signatureAlgorithm и в поле подписи TBSCertificate идентификатор алгоритма (AlgorithmIdentifier) id-alg-unsigned, как показано ниже

     id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}

Параметры id-alg-unsigned должны быть опущены, значение signatureValue должно иметь тип BIT STRING и нулевой размер.

3.2. Эмитент

Сертификат без подписи заменяет самоподписанный сертификат в случаях, когда приложению нужны лишь сведения о субъекте. В нем не указывается эмитент, поэтому некоторые требования профиля [RFC5280] не могут быть применены должным образом. Однако у приложения могут быть требования, вытекающие из [X.509] и [RFC5280], поэтому отправители могут создавать сертификат как самоподписанный, если это требуется для совместимости.

В частности, для описания эмитента сертификата применяются поля:

issuer (параграф 4.1.2.4 в [RFC5280])
issuerUniqueID (параграф 4.1.2.8 в [RFC5280])

Поле issuer не является опциональным и пустые поля запрещены [X.509] и параграфом 4.1.2.4 в [RFC5280], поэтому при пустом поле не обеспечивается совместимость с имеющимися приложениями.

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

Как вариант, отправители могут использовать короткий заменитель поля issuer, состоящий из относительного отличительного имени, имеющего 1 атрибут типа id-rdna-unsigned с значением UTF8String нулевого размера. Идентификатор id-rdna-unsigned показан ниже:

     id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}

Этот заменитель в строковом представлении [RFC4514] имеет вид:

     1.3.6.1.5.5.7.25.1=#0C00

Отправитель должен опускать поле issuerUniqueID, поскольку оно не требуется, не применимо и уже отменено в параграфе 4.1.2.8 [RFC5280].

3.3. Расширения

Некоторые расширения X.509 описывают эмитента сертификата и поэтому не имеют смысла а сертификате без подписи:

authority key identifier (идентификатор ключа агентства — параграф 4.2.1.1 в [RFC5280]);
issuer alternative name (дополнительное имя эмитента — параграф 4.2.1.7 в [RFC5280]).

Отправителям следует опускать расширения authority key identifier и issuer alternative name. Параграф 4.2.1.1 в [RFC5280] требует включать authority key identifier в сертификат, но допускает исключения для самоподписанных сертификатов, применяемых при распространении открытых ключей. Данный документ обновляет [RFC5280], дополнительно разрешая опускать authority key identifier в сертификатах без подписи.

Некоторые расширения отражают роль субъекта — CA или конечный элемент:

key usage (использование ключа — параграф 4.2.1.3 в [RFC5280]);
basic constraints (базовые ограничения — параграф 4.2.1.9 в [RFC5280]).

Отправителям следует заполнять эти поля в соответствии с субъектом:

если субъект является CA, следует указывать бит использования ключа keyCertSign, а также следует включать расширение basic constraints с cA = TRUE;
если субъект является конечным элементом, не следует устанавливать бит использования ключа keyCertSign и следует опускать расширение basic constraints или устанавливать в нем cA = FALSE. В отличие от самоподписанных сертификатов сертификат без подписи не эмиттирует себя, поэтому не требуется использовать самоподпись в расширениях.

4. Восприятие сертификатов без подписи

Подписи X.509 типа id-alg-unsigned недействительны, если:

при обработке сертификатов X.509 без проверки подписей получатели может воспринимать id-alg-unsigned;
при проверке подписей X.509 получатель должен отвергать (reject) id-alg-unsigned.

В частности, валидаторам X.509 недопустимо воспринимать id-alg-unsigned вместо подписи в пути сертификации.

Предполагается, что большинство неизменённых приложений X.509 уже соответствует этому руководству. Приложениям X.509 рекомендуется выполнять эти требования, игнорируя данный документ и считая взамен id-alg-unsigned нераспознанным алгоритмом подписи. Неизменённый валидатор X.509 не сможет проверить подпись (п. a.1 в параграфе 6.1.3 [RFC5280]) и, таким образом, отвергнуть путь сертификации. И наоборот, в случаях игнорирования приложением X.509 самоподписей id-alg-unsigned будет игнорироваться более эффективно.

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

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

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

Если приложение воспринимает id-alg-unsigned как часть пути сертификации или в ином контексте, где требуется проверка подписи X.509, такую проверку можно обойти. Раздел 4 запрещает это и рекомендует приложениям обрабатывать id-alg-unsigned так же, как другие нераспознанные алгоритмы подписи. Не выполняющие это условие приложения подвержены риску уязвимостей, аналогичных описанным в [JWT] и параграфе 1.1 [JOSE].

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

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

6.1. Идентификатор модуля

Агентство IANA добавило указанную в таблице 1 запись в реестр SMI Security for PKIX Module Identifier [RFC7299].

Таблица 1.

Значение	Описание	Документ
122	id-mod-algUnsigned-2025	RFC 9925

6.2. Алгоритм

Агентство IANA добавило указанную в таблице 2 запись в реестр SMI Security for PKIX Algorithms [RFC7299].

Таблица 2.

Значение	Описание	Документ
36	id- alg-unsigned	RFC 9925

6.3. Атрибут Relative Distinguished Name

Для выделения id-rdna-unsigned в этом документе вводится новое значение PKIX OID arc для атрибутов относительного отличительного имени (relative distinguished name).

Агентство IANA добавило указанную в таблице 3 запись в реестр SMI Security for PKIX [RFC7299].

Таблица 3.

Значение	Описание	Документ
25	Relative Distinguished Name Attribute	RFC 9925

Агентство IANA создало реестр SMI Security for PKIX Relative Distinguished Name Attribute а группе реестров Structure of Management Information (SMI) Numbers (MIB Module Registrations).

Описание нового реестра имеет вид iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.25).

Реест содержит 3 колонки и инициализируется приведёнными в таблице 4 значениями.

Таблица 4.

Значение	Описание	Документ
1	id-rdna-unsigned	RFC 9925

Обновления этой таблицы должны выполняться по процедуре Specification Required, заданной в [RFC8126].

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

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

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

[RFC5912] Hoffman, P. and J. Schaad, «New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)», RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

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

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

[JOSE] Madden, N., «JOSE: Deprecate ‘none’ and ‘RSA1_5′», Work in Progress, Internet-Draft, draft-ietf-jose-deprecate-none-rsa15-03, 19 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-jose-deprecate-none-rsa15-03>.

[JWT] Sanderson, J., «How Many Days Has It Been Since a JWT alg:none Vulnerability?», <https://www.howmanydayssinceajwtalgnonevuln.com/>.

[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, «Internet X.509 Public Key Infrastructure: Certification Path Building», RFC 4158, DOI 10.17487/RFC4158, September 2005, <https://www.rfc-editor.org/info/rfc4158>.

[RFC4514] Zeilenga, K., Ed., «Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names», RFC 4514, DOI 10.17487/RFC4514, June 2006, <https://www.rfc-editor.org/info/rfc4514>.

[RFC5914] Housley, R., Ashmore, S., and C. Wallace, «Trust Anchor Format», RFC 5914, DOI 10.17487/RFC5914, June 2010, <https://www.rfc-editor.org/info/rfc5914>.

[RFC7299] Housley, R., «Object Identifier Registry for the PKIX Working Group», RFC 7299, DOI 10.17487/RFC7299, July 2014, <https://www.rfc-editor.org/info/rfc7299>.

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

[X.509] ITU-T, «Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks», ITU-T Recommendation X.509, ISO/IEC 9594-8:2020, October 2019, <https://www.itu.int/rec/t-rec-x.509/en>.

Приложение A. Модуль ASN.1

В приведённом модуле ASN.1 используются соглашения, заданные в [RFC5912].

   SignatureAlgorithmNone
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-algUnsigned-2025(122) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
     SIGNATURE-ALGORITHM
     FROM AlgorithmInformation-2009  -- in [RFC5912]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-algorithmInformation-02(58) }
     ATTRIBUTE
     FROM PKIX-CommonTypes-2009 -- in [RFC5912]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkixCommon-02(57) } ;

   -- Алгоритм неподписанной подписи (Unsigned Signature Algorithm)

   id-alg-unsigned OBJECT IDENTIFIER ::= { iso(1)
      identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) alg(6) 36 }

   sa-unsigned SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-alg-unsigned
      PARAMS ARE absent
   }

   id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1)
      identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) rdna(25) 1 }

   at-unsigned ATTRIBUTE ::= {
      TYPE UTF8String (SIZE (0))
      IDENTIFIED BY id-rdna-unsigned
   }

   END

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

Спасибо Bob Beck, Nick Harper, Sophie Schmieg за обзор ранних вариантов документа, Alex Gaynor за ссылку на статью [JWT], Russ Housley за дополнительную информацию.

Адрес автора

David Benjamin

Google LLC

Email: davidben@google.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9937 Proportional Rate Reduction (PRR)

Опубликовано 21.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                         M. Mathis
Request for Comments: 9937                                              
Obsoletes: 6937                                              N. Cardwell
Category: Standards Track                                       Y. Cheng
ISSN: 2070-1721                                             N. Dukkipati
                                                            Google, Inc.
                                                           December 2025

Proportional Rate Reduction (PRR)

Пропорциональное снижение скорости

PDF

Аннотация

В этом документа описана стандартная (Standards Track) версия алгоритма пропорционального снижения скорости (Proportional Rate Reduction или PRR), которая отменяет экспериментальную версию, опубликованную в RFC 6937. PRR регулирует объем данных, передаваемых по протоколу TCP или иному транспортному протоколу в процессе ускоренного восстановления (fast recovery). PRR точно регулирует размер находящихся в сети данных (flight size) в процессе восстановления так, что в конце процесса быть как можно ближе к порогу замедленного старта (start threshold или ssthresh), заданному алгоритмом контроля перегрузок.

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

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

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

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

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

1. Введение

Принцип сохранения пакетов Ван Якобсона (Van Jacobson) [Jacobson88] задаёт процесс самосинхронизации, где N сегментов данных, доставленных получателю, вызывают генерацию подтверждения, которое отправитель данных использует для синхронизации отправки в сеть других N пакетов данных.

Алгоритмы контроля перегрузок, такие как Reno [RFC5681] и CUBIC [RFC9438], работают на основе такого процесса самосинхронизации. Они контролируют процесс передачи в транспортном соединении, используя окно перегрузки (congestion window или cwnd) для ограничения объёма находящихся в сети (inflight) данных в текущий момент. Кроме того, эти алгоритмы требуют от транспортного соединения снижения cwnd в ответ на потерю пакетов. Алгоритм быстрого восстановления (fast recovery, см. [RFC5681] и [RFC6675]) управляет снижением cwnd на основе обратной связи в виде подтверждений. Заявленная цель состоит в поддержке самосинхронизации отправителя на основе возвращаемых ему в процессе восстановления пакетов ACK для отправки в сеть большего объёма данных. Без пропорционального снижения скорости (PRR) механизм быстрого восстановления обычно регулирует окно, ожидая, пока пройдёт значительная часть времени кругового обхода (RTT) (половина RTT из ACK для Reno [RFC5681] или 30% RTT для CUBIC [RFC9438]) перед отправкой в сеть каких-либо данных.

[RFC6675] делает быстрое восстановление выполняется по селективным подтверждениям (Selective Acknowledgment или SACK) [RFC2018] более точным за счёт оценки отправителем числа байтов, остающихся в сети. В [RFC6675] быстрое восстановление реализуется отправкой данных по мере необходимости в каждом пакете ACK, что обеспечивает возможность увеличения числа остающихся в сети байтов до размера, соответствующего ssthresh — целевому размеру окна для быстрого восстановления, заданному алгоритмом контроля перегрузок. Это предотвращает тайм-ауты быстрого восстановления во многих случаях высокого уровня потерь. Однако [RFC6675] имеет два существенных недостатка. Во-первых, этот механизм вызывает большое мультипликативное сокращение cwnd в начале быстрого восстановления, что может вызывать тайм-аут при потере всей второй половины окна или пакетов ACK. Во-вторых, один пакет ACK с опцией SACK, подразумевающей потерю большого объёма данных, может приводить к ступенчатому разрыву оценки объёма остающихся в сети данных и активировать механизм Fast Retransmit для передачи большого объёма данных.

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

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

Когда inflight превышает ssthresh, PRR плавно снижает inflight в направлении ssthresh за счёт управления скоростью передачи по объёмам доставленных данных и ssthresh.

Когда inflight < ssthresh, PRR адаптивно выбирает один из режимов сокращения (Reduction Bound) для ограничения общего сокращения окна всеми механизмами, включая временные остановки приложений и потери. В качестве базы при сильных перегрузках PRR из осторожности использует консервативное снижение (Conservative Reduction Bound или CRB), которое строго сохраняет пакеты. Когда восстановление представляется проходящим успешно, PRR использует режим снижения замедленного старта (Slow Start Reduction Bound или SSRB), что является более агрессивным по сравнению с PRR-CRB (максимум на 1 сегмент на ACK). PRR-CRB соответствует строгому сохранению пакетов (Strong Packet Conservation Bound), как описано в Приложении A. Однако при использовании в реальных сетях как единственного механизма он работает не так хорошо, как алгоритм, описанный в [RFC6675], который во многих случаях оказывается более агрессивным. PRR-SSRB предлагает компромисс, позволяя в некоторых случаях передавать в соединение 1 дополнительный сегмент на ACK по сравнению с PRR-CRB. Хотя механизм PRR-SSRB менее агрессивен чем [RFC6675] (передаёт меньше сегментов или более медленно), он обеспечивает большую производительность за счёт снижения вероятности дополнительных потерь в процессе восстановления.

В исходном определении принципа сохранения [Jacobson88] пакетов, которые предполагались потерянными (например, помеченные как кандидаты на повтор передачи), считались остающимися в сети. Эта идея отражена в используемой PRR системе оценки остающихся в сети пакетов, но она отличается от Strong Packet Conservation Bound (Приложение A), где оценка выполняется исключительно на основе прибывших к получателю данных.

В этом документе указано несколько основных изменений в исходной версии PRR [RFC6937]. Во-первых, вводится новая адаптивная эвристика взамен настройки вручную параметров, определяющих уровень консервативности PRR при inflight меньше ssthresh (как для PRR-CRB, так и для PRR-SSRB). Во-вторых, алгоритм задаёт поведение соединений без SACK (не согласовавших поддержку SACK [RFC2018] через опцию SACK-permitted). В-третьих, алгоритм обеспечивает сглаженный процесс доставки даже если отправитель часто переупорядочивает данные и начинает восстановление после того, как для значительной части пространства номеров были получены SACK. Кроме того, в документе дополнительно обсуждается интеграция PRR с алгоритмами контроля перегрузок и обнаружения потерь.

Для PRR имеется значительный опыт внедрения в разных реализациях TCP с начала широкого внедрения реализации TCP PRR в 2011 г. [First_TCP_PRR].

2. Уровни требований

3. Определения

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

SND.UNA

Самый старый из неподтвержденных номеров (параграф 3.4 в [RFC9293].

SND.NXT

Следующий номер для передачи (параграф 3.4 в [RFC9293].

duplicate ACK

Подтверждение считается «дубликатом» в описанных здесь алгоритмах, если (a) получатель ACK имеет остающиеся для передачи данные, (b) входящее подтверждение не содержит каких-либо данных, (c) оба флага SYN и FIN сброшены, (d) номер подтверждения равен или превышает значение наибольшего номера подтверждения, полученного в данном соединении (SND.UNA) и (e) анонсируемое во входящем подтверждении окно равно окну, анонсированному в последнем входящем подтверждении (раздел 2 в [RFC5681]).

FlightSize

Количество данных, которые уже переданы, но ещё не подтверждены кумулятивно (раздел 2 в [RFC5681]).

Receiver Maximum Segment Size (RMSS)

RMSS — размер максимального сегмента, который желает принимать получатель. Это значение задаётся в опции MSS, передаваемой получателем при организации соединения (см. параграф 3.7.1 в [RFC9293]). Если опция MSS при организации соединения не была задана, используется значение 536 байтов для IPv4 и 1220 байтов для IPv6 (см. параграф 3.7.1 в [RFC9293]). Размер не включает заголовков и опций TCP/IP. Определение RMSS дано в разделе 2 [RFC5681] и параграфе 3.8.6.3 [RFC9293].

Sender Maximum Segment Size (SMSS)

SMSS представляет собой размер самого большого сегмента, который может быть передан отправителем. Это значение может определяться на основе максимального блока данных, передаваемого через сеть (Maximum Transmission Unit или MTU), алгоритма определения Path MTU [RFC1191] [RFC8201] [RFC4821], RMSS и других факторов. Размер не включает заголовков и опций TCP/IP (раздел 2 в [RFC5681]).

Receiver Window (rwnd)

Последнее анонсированное значение размера окна принимающей стороны в байтах. В любой момент через соединение недопустимо передавать данные с порядковым номером больше SND.UNA + rwnd (раздел 2 в [RFC5681]).

Congestion Window (cwnd)

Переменная состояния TCP, которая ограничивает количество данных, разрешённых протоколу для передачи. В любой момент недопустимо передавать данные, если объем находящихся в сети данных (см. ниже) не меньше cwnd (раздел 2 в [RFC5681]).

Slow Start Threshold (ssthresh)

Порог замедленного старта (переменная состояния ssthresh) используется для определения момента, когда следует использовать алгоритм замедленного старта или предотвращения перегрузки для управления передачей данных. В процесс быстрого восстановления ssthresh — это максимальный размер окна для эпизода быстрого восстановления, как задано алгоритмом контроля перегрузки (параграф 3.1 в [RFC5681]).

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

Delivered Data (DeliveredData)

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

In-Flight Data (inflight)

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

Recovery Flight Size (RecoverFS)

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

SafeACK

Локальная логическая переменная, указывающая, что текущее подтверждение ACK говорит об успешном процессе восстановления и возможности отправителя передавать более агрессивно, с увеличением inflight, если это нужно.

SndCnt

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

Voluntary window reductions — произвольное сокращение окна

Решение не передавать данные в ответ на некоторые ACK с целью сокращения окна передачи и скорости отправки.

4. Отличия от RFC 6937

Самым большим изменением с момента выпуска [RFC6937] является введение новой эвристики которая использует течение процесса восстановления (для TCP, когда последний пакет ACK достигает SND.UNA и не указывает потерю предшествующего ускоренного повтора передачи) для выбора режима сокращения (PRR-CRB или PRR-SSRB). В [RFC6937] выбор режима сокращения оставлен за разработчиками, но рекомендовано по умолчанию применять PRR-SSRB. Для всех сред, рассмотренных в предшествующих исследованиях PRR новая эвристика соответствует этой рекомендации.

В статье «An Internet-Wide Analysis of Traffic Policing» [Flach2016policing] отмечена критическая ситуация, которая не исследовалась ранее, когда оба варианта сокращения работают очень плохо, но по разным причинам. Во многих конфигурациях системы организации трафика на основе маркеров (token bucket) могут внезапно начать отбрасывание значительной части трафика при исчерпании маркеров без выдачи предупреждений конечным системам. Система транспортного контроля перегрузок не имеет возможности измерять скорость расхода маркеров и устанавливает ssthresh на основе ранее наблюдавшейся производительности пути. Такое значение ssthresh может привести к значительному превышению скорости данных над скоростью пополнения маркеров, что приведёт к высоким потерям. В таких условиях оба режима сокращения работают очень плохо. Метод PRR-CRB слишком мягок, что иногда ведёт к очень долгому восстановлению при меньших, чем требуется окнах, а PRR-SSRB слишком агрессивен и часто ведёт к потере множества повторно переданных пакетов в течение нескольких интервалов кругового обхода. Оба случая приводят к длительному восстановлению, ухудшающему задержки в приложениях и/или производительность.

Изучение этих сред привело к разработке эвристики SafeACK для динамического переключения режима сокращения. По умолчанию применяется консервативный метод PRR-CRB, а переключение на PRR-SSRB происходит лишь при указании пакетами ACK успешного хода восстановления (SND.UNA продвигается без новых потерь). Эвристика SafeACK была опробована в сети доставки содержимого Google (Content Delivery Network или CDN) [Flach2016policing] и реализована в Linux TCP с 2015 г.

Эвристика SafeACK применяется лишь в случаях, когда потери, ограничения приложений или иные события вызывают занижение оценки находящихся в сети пакетов до значения ниже ssthresh. Высокая частота потерь, делающая эвристику важной, характерна лишь при значительных потерях, таких как политика организации трафика (traffic policer) [Flach2016policing]. В таких средах эвристика работает лучше любого из двух ограничений, самого по себе.

Другое изменение PRR улучшает процесс передачи, когда отправитель переходит к восстановлению после того, как большая часть пространства номеров была подтверждена SACK. Такая ситуация может возникать при предшествующем обнаружении отправителем нарушения порядка доставки, например, с помощью [RFC8985]. В прежней версии PRR переменная RecoverFS некорректно учитывала диапазоны номеров, подтверждённые SACK до начала быстрого восстановления, что вызывало слишком медленную отправку в PRR. Изменение PRR корректно учитывает диапазоны порядковых номеров, подтверждённые SACK до начала быстрого восстановления.

Ещё одно изменение заключается в принудительном повторе передачи по первому пакету ACK, запустившему восстановления. Ранее механизм PRR мог, в зависимости от ситуации с потерями, не разрешать быстрый повтор передачи (т. е. SndCnt = 0) по первому пакету ACK при быстром восстановлении. Форсирование ускоренного повтора передачи важно для поддержки синхронизации ACK и предотвращения возможных тайм-аутов при повторе (retransmission timeout или RTO). Форсированный ускоренный повтор передачи выполняется лишь один раз в процессе восстановления и не нарушает принципов сохранения пакетов PRR. Эта эвристика внедрена в первой широко распространённой реализации TCP PRR в 2011 г. [First_TCP_PRR].

В соответствии с другим изменением, отправитель устанавливает cwnd = ssthresh при выходе из процедуры восстановления. Это важно для отказоустойчивости. Без установки cwnd = ssthresh в конце восстановления, а также с учётом отправителей с ограничениями и некоторых картин потерь, cwnd в конце восстановления может быть ниже ssthresh, что ведёт к снижению производительности. В некоторых случаях производительность может быть ниже, чем при восстановлении [RFC6675], где просто устанавливается cwnd = ssthresh в начале восстановления. Установка cwnd = ssthresh в конце восстановления была внедрена в первой широко распространённой реализации TCP PRR в 2011 г. [First_TCP_PRR] и это похоже на [RFC6675], где устанавливается cwnd = ssthresh в начале восстановления.

С момента публикации [RFC6937] механизм PRR был адаптирован для мультипликативного сокращения окна в алгоритмах контроля перегрузки, не основанных на потерях, таких как явное уведомление о перегрузке (Explicit Congestion Notification или ECN) [RFC3168]. Это можно сделать, используя некоторые части конечного автомата восстановления потерь (в частности, RecoveryPoint [RFC6675]) для вызова обработки PRR ACK ровно на один интервал кругового обхода из ACK. Однако могут существовать взаимосвязи между применением PRR и подходами с активным управлением очередями (Active Queue Management или AQM) и ECN. Рекомендации по разработке и внедрению механизмов контроля перегрузки приведено в [RFC9743].

5. Взаимодействие с другими стандартами

PRR можно применять в сочетании с любым алгоритмом контроля перегрузок, предназначенным для мультипликативного снижения скорости передачи данных в течение примерно одного интервала кругового обхода при условии, что текущий объём находящихся в сети данных ограничен размером окна перегрузки (cwnd) и целевой объём остающихся в сети данных в процессе сокращения является фиксированным значением, заданным ssthresh. В частности, PRR может работать с контролем перегрузок Reno [RFC5681] и CUBIC [RFC9438]. PRR описывается как модификация «A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP» [RFC6675]. Механизм наиболее точен в сочетании с SACK [RFC2018], но не требует наличия SACK.

PRR можно применять в сочетании с широким спектром алгоритмов обнаружения потерь. Это обусловлено независимостью PRR от деталей определения доставленных и потерянных пакетов механизмом обнаружения потерь. При получении каждого пакета ACK механизму PRR просто нужен алгоритм обнаружения потерь для информирования о числе пакетов, помеченных как доставленные и потерянные. Таким образом, PRR можно применять в сочетании с алгоритмами обнаружения потерь, заданными или описанными в Reno [RFC5681], NewReno [RFC6582], SACK [RFC6675], Forward Acknowledgment (FACK) [FACK], Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]. Благодаря свойствам RACK-TLP, включая устойчивость к потерям данных, нарушению порядке и потерям при повторной передаче рекомендуется реализовать PRR в сочетании с восстановлением потерь RACK-TLP [RFC8985].

Эвристика SafeACK является результатом отказоустойчивого обнаружения потерь при повторе передачи (Lost Retransmission Detection) при разработке раннего предшественника [RFC8985]. Без такого обнаружения системы управления трафиком (policer), ведущие к значительному уровню потерь, имеют очень высокий риск возникновения тайм-аутов при повторе передачи, поскольку в Reno [RFC5681], CUBIC [RFC9438] и [RFC6675] повторы возможны со значительным превышением скорости, заданной системой управления трафиком.

6. Алгоритм

6.1. Этапы инициализации

В начале эпизода реагирования на перегрузку, вызванного алгоритмом контроля отправитель, применяющий PRR, должен инициализировать состояние PRR. Момент начала реагирования на перегрузку полностью определяется алгоритмом контроля перегрузки и может, например, совпадать с запуском быстрого восстановления или однократным (за интервал кругового обхода) сокращением при обнаружении потери исходно или повторно переданных пакетов уже после начала быстрого восстановления. Инициализация PRR позволяет использовать алгоритм контроля перегрузок CongCtrlAlg(), который может установить для ssthresh значение, отличное от FlightSize/2 (включая , например, CUBIC [RFC9438]).

Ключевым этапом инициализации PRR является расчёт RecoverFS (число байтов, которые по оценке отправителя могут быть доставлены в течение эпизода PRR). Это можно представить как сумму установленных в начале эпизода значений объёма данных, остающихся в сети, числа байтов, кумулятивно подтверждённых запустившим восстановление пакетом ACK, числа байтов, подтверждённых SACK в пакете ACK, запустившим восстановление, и числа байтов между SND.UNA и SND.NXT, помеченных как потерянные. Значение RecoverFS включает потери, поскольку они маркируются с использованием эвристики, и некоторые пакеты, отмеченные как потерянные, могут быть всё-таки доставлены (без повтора передачи) в процессе восстановления. PRR использует RecoverFS для расчёта сглаженной скорости отправки. В начале быстрого восстановления PRR использует RecoverFS и это значение остаётся неизменным в течение данного эпизода быстрого восстановления.

Вся последовательность инициализации PRR приведены в псевдокоде ниже.

ssthresh = CongCtrlAlg() // Параметры восстановления     
// Целевое значение остающихся в сети данных      
prr_delivered = 0
// Общее число байтов, доставленных при восстановлении 
prr_out = 0
// Общее число байтов, переданных при восстановлении
RecoverFS = SND.NXT - SND.UNA
// Байты, подтверждённые SACK до начала восстановления,
// не будут маркироваться в процессе восстановления
RecoverFS -= (bytes SACKed in scoreboard)
// Включает (распространённый) случай селективно
// подтверждённых ACK байтов
RecoverFS += (bytes newly SACKed)
// Включает (редкий) случай кумулятивно подтверждённых байтов
RecoverFS += (bytes newly cumulatively acknowledged)

6.2. Действия при получении ACK

При получении каждого пакета ACK в начале и в процессе восстановления (за исключением завершения завершения эпизода PRR) выполняет описанные ниже действия.

Сначала отправитель рассчитывает DeliveredData (оценка отправителем общего числа байтов, доставку которых подтверждает текущий пакет ACK, после предшествующего ACK). При наличии SACK значение DeliveredData можно рассчитать точно как изменение SND.UNA плюс изменение (со знаком) объёма данных, помеченных SACK в таблице результатов. Таким образом, в частном случае отсутствия в таблице результатов подтверждённых SACK диапазонов или после ACK, значение DeliveredData будет указано изменением SND.UNA. При восстановлении без SACK значение DeliveredData оценивается как 1 SMSS на каждый полученный дубликат ACK (т. е. SND.UNA не меняется). При увеличении SND.UNA (т. е. полное или частичное подтверждение ACK) значением DeliveredData будет изменение SND.UNA за вычетом SMSS на каждый принятый дубликат ACK. При отсутствии SACK некорректно работающий получатель, возвращающий лишние дубликаты ACK (см. [Savage99]), может попытаться искусственно завысить значение DeliveredData. В качестве меры предосторожности при отсутствии SACK механизм PRR запрещает увеличение DeliveredData, если общее число байтов, доставленных в эпизоде PRR, превышает оценку объёма данных, остававшихся в сети на момент начала восстановления (RecoverFS).

Затем отправитель вычисляет inflight. Для расчёта в соединениях с поддержкой SACK и обнаружением потерь [RFC6675] можно использовать алгоритм pipe, как указано в [RFC6675]. В соединениях с SACK и RACK-TLP [RFC8985] или иным алгоритмом обнаружения потерь расчёт должен начинаться с SND.NXT — SND.UNA, из которого (по таблице результатов) вычитаются байты, подтверждённые SACK и потерянные байты, затем добавляются байты, переданные повторно с момента их последней маркировки как потерянных. Для соединений без SACK вместо вычитания подтверждённых SACK байтов из таблицы результатов отправитель должен вычитать меньшее из значений RecoverFS и (1 SMSS для каждого предшествующего дубликата ACK в последнем эпизоде восстановления). Функция min() с RecoverFS служит для защиты от некорректно работающих получателей [Savage99].

Далее отправитель определяет SafeACK — локальную логическую переменную, указывающую, что текущий пакет ACK сообщил об успешном ходе восстановления. SafeACK имеет значение true лишь в том случае, когда ACK кумулятивно подтверждает новые данные и не указывает дополнительных потерь. Например, пакет ACK, вызывающий «аварийный» (rescue) повтор передачи (раздел 4 в [RFC6675], NextSeg(), условие 4) может указывать дополнительные потери. Оба условия указывают на успешный ход восстановления и отправитель может передавать более агрессивно, увеличивая при необходимости inflight.

В заключение отправитель использует DeliveredData, inflight, SafeACK и другие переменные состояния PRR для расчёта SndCnt (локальная переменная, точно показывающая сколько байтов следует передать в ответ на каждый пакет ACK), а затем использует SndCnt для обновления cwnd.

Полный ход действия PRR при получении ACK показан ниже

if (DeliveredData is 0)
   Return

prr_delivered += DeliveredData
inflight = (оценка остающихся в сети данных)
SafeACK = (SND.UNA растёт и новых потерь не указано)
if (inflight > ssthresh) {
   // Пропорциональное снижение скорости
   // Используется целочисленное деление с округлением вверх:
   #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   out = DIV_ROUND_UP(prr_delivered * ssthresh, RecoverFS)
   SndCnt = out - prr_out
} else {
   // PRR-CRB применяется по умолчанию
   SndCnt = MAX(prr_delivered - prr_out, DeliveredData)
   if (SafeACK) {
      // PRR-SSRB при успешном ходе
      SndCnt += SMSS
   }
   // Попытка наверстать упущенное
   SndCnt = MIN(ssthresh - inflight, SndCnt)
}

if (prr_out is 0 AND SndCnt is 0) {
   // Форсирование быстрого повтора в начале восстановления
   SndCnt = SMSS
}
cwnd = inflight + SndCnt

После расчёта отправителем SndCnt и использования его для обновления cwnd отправитель передаёт больше данных. Отметим, что выбор данных для отправки (например, повтор или новые данные) выходит за рамки документа.

6.3. Этапы передачи

При любой передаче или повторе данных PRR выполняет указанное ниже действие.

      prr_out += (переданные данные)

6.4. Завершающие действия

Эпизод PRR заканчивается завершением процедуры быстрого восстановления или перед началом нового эпизода PRR в результате нового отклика на возникновение перегрузки. При завершении эпизода PRR устанавливается

      cwnd = ssthresh

Отметим, что установка cwnd = ssthresh в некоторых случаях может приводить к всплеску отправляемых в сеть сегментов. Реализациям рекомендуется регулировать такие всплески трафика данных. Эта рекомендация соответствует современной практике сглаживания пиков (например, [PACING]), включая регулирование отправки после перезапуска из состояния бездействия.

7. Свойства

Перечисленные ниже свойства являются общими для PRR-CRB и PRR-SSRB, за исключениям отмеченных случаев.

PRR пытается поддерживать синхронизацию отправки с ACK в процессе восстановления, включая пики потерь. В отличие от этого [RFC6675] может вызывать значительные всплески после пиков потерь. Обычно PRR равномерно распределяет сокращение окна в всего течение интервала RTT. Это может сглаживать пики трафика Internet и рассматриваться как своего рода мягкое регулирование. Гипотетически, любое регулирование может повышать вероятность чередования различных потоков, сокращая вероятность сжатия ACK и других явлений, способных вызывать пики. Однако количественная оценка таких эффектов не проводилась.

При низких потерях PRR будет сходиться точно к целевому окну, выбранному алгоритмом контроля перегрузок. Отметим, что по мере приближения отправителя к завершению восстановления, значение prr_delivered будет стремиться к RecoverFS, а значение SndCnt будет рассчитываться так, что prr_out будет стремиться к ssthresh.

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

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

Используя любую из методов сокращения, PRR улучшает ситуацию, когда приложение тормозится, например, передающее приложение недостаточно быстро помещает данные в очередь передачи или получатель перестаёт продвигать окно приёма. Если приложение тормозится в начале восстановления, prr_out будет отставать от суммарного объёма передачи, разрешённого SndCnt. Упущенные из-за задержки возможности отправки данных рассматриваются как отложенные сокращения, в частности, они делают разность prr_delivered — prr_out существенно положительной. Если приложение синхронизируется, пока отправитель ещё находится в состоянии восстановления, отправитель передаст всплеск (burst) для увеличения inflight, что бы достичь того состояния, которое было бы при отсутствии торможения. Хотя такой всплеск может негативно влиять на данный поток или другие потоки в «канале», именно это происходит всякий раз, когда приложение тормозится на часть RTT не в процессе восстановления. PRR делает такое торможение более однородным во всех состояниях. Изменение такого поведения выходит за рамки этого документа.

Метод PRR с привязкой сокращения менее чувствителен к ошибкам при оценке inflight. При восстановлении inflight по сути является оценкой на основе неполных сведений о потере или нарушении порядка данных, не указанных в SACK. В некоторых случаях inflight может включать существенные ошибки, например, значение недооценивается, если всплеск переупорядоченных данных будет сочтён потерей и промаркирован для повтора передачи. Если передача регулируется напрямую значением inflight, как в [RFC6675], разрывы в оценке inflight вызывают всплеск данных, который невозможно отменить после корректировки inflight новыми пакетами ACK. В части динамики PRR, inflight просто определяет, какой алгоритм, PRR или вариант сокращения применяется для расчёта SndCnt из DeliveredData. Несмотря на недооценку Winflight, алгоритмы различаются не более чем на 1 сегмент на ACK. После обновления оценки inflight они сходятся к одному размеру окна в конце восстановления.

При любых условиях и последовательности событий в процессе восстановления PRR-CRB строго ограничивает передачу данных, чтобы она не превысила объем данных, доставленных адресату. Strong Packet Conservation Bound (строгая привязка к сохранению пакетов) — это наиболее агрессивный алгоритм, не вызывающий дополнительных потерь в некоторых средах. Это обусловлено тем, что при наличии сохраняющейся очереди передачи в узком месте без кросс-трафика размер очереди в процессе восстановления будет меняться не более чем на +1/-1 из-за различий времени прибытия и выхода. Подробно этот вопрос рассматривается в Приложении A.

Хотя строгая привязка сохранения пакетов по многим причинам очень привлекательно, измерения (см. раздел 6 в [RFC6675]) показывают, что этот метод менее агрессивен и работает не так хорошо, как [RFC6675], где разрешены пики данных во время всплесков потерь. PRR-SSRB является компромиссом, позволяющим отправителю передать 1 дополнительный сегмент на ACK сверх Packet Conserving Bound (привязка сохранения пакетов), когда ACK показывает хороший ход восстановления без добавочных потерь. С точки зрения строгой привязки, PRR-SSRB открывает окно возможностей в процессе восстановления, однако при всплеске потерь этот метод менее агрессивен, чем [RFC6675].

8. Примеры

Этот раздел иллюстрирует поведение алгоритмов PRR и [RFC6675] демонстрируя различия в поведении для двух случаев: соединения с 1 потерей и всплеском из 15 последовательных потерь. В обоих случаях передаётся большой объем данных (без пауз в приложениях), применяется контроль перегрузок Reno [RFC5681], и установлено cwnd = FlightSize = inflight = 20 сегментов, поэтому в начале восстановления будет значение ssthresh = 10. В обоих случаях применяется ускоренный повтор (Fast Retransmit) [RFC5681] и ограниченная передача (Limited Transmit) [RFC3042], поэтому отправитель передаёт 2 сегмента, после чего следует 1 повтор в ответ на первые 3 дубликата ACK после потерь.

На рисунках ниже показаны отклики на пакет ACK за первый круговой обход для двух алгоритмов восстановления при потере нулевого сегмента. Верхняя строка (ack#) показывает номер переданного сегмента, вызвавшего пакеты ACK, где X указывает потерянный сегмент. Строки cwnd и inflight указывают значения соответствующих переменных для алгоритмов после обработки каждого возвращённого пакета ACK, но до последующей передачи (повтора). Строка sent указывает число новых (N) или повторённых (R) данных, которые были переданы. Алгоритмы выбора данных для передачи выходят за рамки этого документа.

RFC 6675
   a X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
   c   20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
   i   19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
   s    N  N  R                             N  N  N  N  N  N  N  N  N  N

PRR
   a X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
   c   20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
   i   19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
   s    N  N  R     N     N     N     N     N     N     N     N     N  N

   a: ack#;  c: cwnd;  i: inflight;  s: sent

Рисунок .1

В первом примере ACK#1 — ACK#19 содержат SACK для исходной отправки данных, в ACK#20 и ACK#21 содержатся SACK для ограниченной передачи, вызванной первым и вторым сегментами, подтверждёнными SACK, а ACK#22 содержит полное кумулятивное подтверждение ACK, охватывающее все данные вплоть до ограниченной передачи. ACK#22 завершает эпизод восстановления и, следовательно, — эпизод PRR.

Отметим, что оба алгоритма суммарно передают одинаковый объем данных и завершают эпизод восстановление с cwnd, соответствующим ssthresh = 20. В [RFC6675] возникает «половина окна тишины», а PRR распределяет сокращение окна по всему интервалу RTT.

Далее рассматривается случай с такими же начальными условиями, где теряется 15 первых пакетов (0-14). В результате прохождения оставшейся части пути отправителю возвращается лишь 5 пакетов 5 ACK.

RFC 6675
   a X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  15 16 17 18 19
   c                                              20 20 10 10 10
   i                                              19 19  4  9  9
   s                                               N  N 6R  R  R

PRR
   a X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  15 16 17 18 19
   c                                              20 20  5  5  5
   i                                              19 19  4  4  4
   s                                               N  N  R  R  R

   a: ack#;  c: cwnd;  i: inflight;  s: sent

Рисунок 2

В этой ситуации алгоритм [RFC6675] более агрессивен, поскольку при запуске Fast Retransmit (по ACK для сегмента 17) отправитель сразу передаёт повторно данные, достаточные для увеличения inflight до cwnd. Измерения (см. раздел 6 в [RFC6675]) показали, что [RFC6675] значительно превосходит version PRR [RFC6937] с использованием лишь PRR-CRB и некоторые похожие консервативные алгоритмы, которые тестировались. Это показывает, что фактические потери обычно превышают сокращение cwnd, определяемое алгоритмом контроля перегрузок.

При столь значительных потерях в первом интервале кругового обхода при восстановлении PRR использует PRR-CRB в соответствии с принципом сохранения пакетов. Поскольку общие потери ведут к тому, что inflight становится ниже ssthresh, данные передаются так, что общий объем отправки (prr_out) соответствует общему объёму доставленных получателю данных, сообщённому пакетами ACK. Передача контролируется пределом отправки (prr_delivered — prr_out).

Хотя на рисунке это не показано, после того, как ускоренные повторы по ACK#17 доставлены и вызвали пакеты ACK, увеличивающие SND.UNA, PRR переходит в режим PRR-SSRB и увеличивает окно ровно на 1 сегмент по каждому ACK, пока inflight не достигнет значения ssthresh в процессе восстановления. При больших потерях, когда значение cwnd велико, PRR-SSRB восстанавливает потери в разы быстрее, чем PRR-CRB. Хотя увеличение окна в процессе восстановления представляется разумным, важно помнить, что на деле это менее агрессивно, нежели разрешает [RFC6675], где передаётся тот же объем дополнительных данных в одном всплеске как отклик на пакет ACK, вызвавший Fast Retransmit.

При меньших потерях (суммарно меньше FlightSize — ssthresh) PRR-CRB и PRR-SSRB не вызываются, поскольку PRR остаётся в режиме пропорционального снижения скорости.

9. Адаптация PRR к другим транспортным протоколам

Основной алгоритм PRR и привязки сокращения можно адаптировать для любого транспорта, поддерживающего [RFC6675]. В одной из основных реализаций (Linux TCP) PRR является алгоритмом быстрого восстановления для принятых по умолчанию и поддерживаемых модулей контроля перегрузок с 2011 г. [First_TCP_PRR].

Эвристику SafeACK можно обобщить как любое подтверждение (ACK) повторной передачи, которое не ведёт к маркировке какого-либо другого сегмента для повторной передачи.

10. Измерения

Для [RFC6937] в документе [IMC11] проведены оценки [RFC3517] и экспериментальных версий PRR в рамках крупномасштабных измерений. На момент публикации этого документа использованные в исследовании устаревшие алгоритмы были уже исключены из реестров, что затрудняет сравнение без использования их. Интересующимся результатами измерений читателям следует обратиться к разделу 5 в [RFC6937] и статье IMC [IMC11].

11. Эксплуатационные вопросы

11.1. Поэтапное внедрение

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

11.2. Беспристрастность

Механизм PRR предназначен для обеспечения беспристрастности алгоритма контроля перегрузок, с которым он применяется. PRR работает лишь во время отклика контроля перегрузок, такого как быстрое восстановление, или при постепенном снижении cwnd в результате реакции TCP ECN [RFC3168], и принимает только краткосрочные решения на основе приёма подтверждений для плавной регулировки объёма остающихся в сети данных в течение эпизода так, чтобы в конце эпизода значение cwnd было как можно ближе к порогу замедленного старта, заданному алгоритмом контроля перегрузок. PRR не меняет механизмов изменения cwnd алгоритмом контроля перегрузок вне эпизодов отклика на перегрузку.

11.3. Защита сети от избыточных очередей и потери пакетов

В долгосрочной перспективе механизм PRR рассчитан на поддержку свойств постановки в очереди и потери пакетов, характерных для алгоритмов контроля перегрузок, с которыми он применяется. Как отмечено выше, PRR работает лишь в эпизодах откликов на перегрузку, таких как быстрое восстановление, или откликов на ECN, и принимает только краткосрочные решения для плавной регулировки объёма остающихся в сети данных, чтобы в конце эпизода размер окна cwnd был как можно ближе к порогу замедленного старта (ssthresh), заданному алгоритмом контроля перегрузок.

В краткосрочном масштабе механизм PRR предназначен для снижения скорости потери пакетов по сравнению с прежними подходами, например, [RFC6675]. На высоком уровне механизм PRR основан на принципе сохранения пакетов и опирается на процесс самосинхронизации, насколько это возможно. В отличие от этого, в [RFC6675] один пакет ACK с опцией SACK, подразумевающий отсутствие большого объёма данных, может вызвать разрыв в оценке остающихся в сети данных, который может активировать механизм ускоренного повтора (Fast Retransmit) для отправки пикового объёма данных, значительно превышающего объем доставленных данных. PRR позволяет избежать таких всплесков, принимая решение о передаче на основе объёма доставленных, а не потерянных данных. Кроме того, как отмечено выше, PRR-SSRB менее агрессивен, чем [RFC6675] (передаёт меньше сегментов или делает это медленней), и обладает большей производительностью из-за снижения вероятности дополнительных потерь при восстановлении.

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

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

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

PRR не изменяет профилей рисков транспортных протоколов

Разработчики, переводящие PRR с подсчёта байтов на подсчёт сегментов, должны быть осторожны в отношении атак с расщеплением ACK [Savage99], когда получатель подтверждает частичные сегменты с целью запутать отправителя при обработке перегрузки.

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

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

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

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

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

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

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

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

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

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

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

[RFC9293] Eddy, W., Ed., «Transmission Control Protocol (TCP)», STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed., «CUBIC for Fast and Long-Distance Networks», RFC 9438, DOI 10.17487/RFC9438, August 2023, <https://www.rfc-editor.org/info/rfc9438>.

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

[FACK] Mathis, M. and J. Mahdavi, «Forward Acknowledgment: Refining TCP Congestion Control», SIGCOMM ’96: Conference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 281-291, DOI 10.1145/248156.248181, August 1996, <https://dl.acm.org/doi/10.1145/248156.248181>.

[First_TCP_PRR] «Proportional Rate Reduction for TCP.», commit a262f0cdf1f2916ea918dc329492abb5323d9a6c, August 2011, <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>.

[Flach2016policing] Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng, Y., Karim, T., Katz-Bassett, E., and R. Govindan, «An Internet-Wide Analysis of Traffic Policing», SIGCOMM ’16: Proceedings of the 2016 ACM SIGCOMM Conference, pp. 468-482, DOI 10.1145/2934872.2934873, August 2016, <https://doi.org/10.1145/2934872.2934873>.

[Hoe96Startup] Hoe, J., «Improving the Start-up Behavior of a Congestion Control Scheme for TCP», SIGCOMM ’96: Conference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 270-280, DOI 10.1145/248156.248180, August 1996, <https://doi.org/10.1145/248156.248180>.

[IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi, «Proportional Rate Reduction for TCP», IMC ’11: Proceedings of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference, pp. 155-170, DOI 10.1145/2068816.2068832, November 2011, <https://doi.org/10.1145/2068816.2068832>.

[Jacobson88] Jacobson, V., «Congestion Avoidance and Control», Symposium proceedings on Communications architectures and protocols (SIGCOMM ’88), pp. 314-329, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.

[PACING] Welzl, M., Eddy, W., Goel, V., and M. Tüxen, «Pacing in Transport Protocols», Work in Progress, Internet-Draft, draft-welzl-iccrg-pacing-03, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-welzl-iccrg-pacing-03>.

[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, «Enhancing TCP’s Loss Recovery Using Limited Transmit», RFC 3042, DOI 10.17487/RFC3042, January 2001, <https://www.rfc-editor.org/info/rfc3042>.

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

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517, DOI 10.17487/RFC3517, April 2003, <https://www.rfc-editor.org/info/rfc3517>.

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

[RFC9743] Duke, M., Ed. and G. Fairhurst, Ed., «Specifying New Congestion Control Algorithms», BCP 133, RFC 9743, DOI 10.17487/RFC9743, March 2025, <https://www.rfc-editor.org/info/rfc9743>.

[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control with a Misbehaving Receiver», ACM SIGCOMM Computer Communication Review, vol. 29, no. 5, pp. 71-78, DOI 10.1145/505696.505704, October 1999, <https://doi.org/10.1145/505696.505704>.

[TCP-RH] Mathis, M., Mahdavi, J., and J. Semke, «The Rate-Halving Algorithm for TCP Congestion Control», Work in Progress, Internet-Draft, draft-mathis-tcp-ratehalving-00, 30 August 1999, <https://datatracker.ietf.org/doc/html/draft-mathis-tcp-ratehalving-00>.

Приложение A. Строгая привязка к сохранению пакетов

Привязка PRR-CRB основана на консервативной, философски чистой и эстетически привлекательной строгой привязке к сохранению пакетов (Strong Packet Conservation Bound), описанной здесь. Хотя механизм основан на принципе сохранения пакетов [Jacobson88], он отличается трактовкой пакетов, которые отсутствуют или считаются потерянными. При любых условиях и вариантах событий в процессе восстановления PRR-CRB строго ограничивает отправляемые данные — не больше объёма данных, доставленных получателю. Отметим, что последствия предполагаемых потерь учитываются при расчёте inflight, но не влияют на результат PRR-CRB, если inflight падает ниже ssthresh.

Этот алгоритм является наиболее агрессивным из числа не приводящих к дополнительным потерям в некоторых средах. Это свойство обусловлено тем, что при наличии в узком месте сохраняющейся очереди, через которую не передаётся другой трафик, очередь будет сохранять размер в течение всего периода восстановления с флуктуациями +1/-1 из-за разницы времени прибытия и выхода пакетов. Менее агрессивные алгоритмы приведут к сокращению очереди в узком месте, а более агрессивные вызовут рост очереди или дополнительные потери, если очередь переполнится.

Это свойство демонстрируется ниже с помощью мысленного эксперимента.

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

Если SndCnt = DeliveredData и ничто не мешает передаче данных, очевидно, что данные, приходящие в очередь узкого места, будут в точности заменять данные, отправленные из головы этой очереди, поэтому размер очереди не будет меняться. При заполнении очереди с отбрасыванием хвоста она будет оставаться заполненной. Потери или нарушение порядка на пути ACK будет лишь вызывать более значительные колебания размера очереди без превышения максимального размера, независимо от соблюдения порядка данных (включая восстановление потерь из более раннего RTT). Более агрессивный алгоритм, отправляющий больше данных, переполнит очередь и вызовет потери, а при менее агрессивной передаче очередь будет не заполнена. Поэтому установка SndCnt = DeliveredData является наиболее агрессивным вариантом, не вызывающим дополнительных потерь в такой простой сети. Ослабление допущений (например, повышение достоверности задержек и добавление потоков, задержки ACK и т. п.) может увеличить флуктуации очереди, но не изменят базовое поведение.

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

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

Этот документ частично основан на работе Janey C. Hoe (см. «Recovery from Multiple Packet Losses» в параграфе 3.2 [Hoe96Startup]), Matt Mathis, Jeff Semke и Jamshid Mahdavi [TCP-RH], а также обсуждениях с John Heffner.

Monia Ghobadi и Sivasankar Radhakrishnan помогли с анализом экспериментов. Ilpo Jarvinen проанализировал начальную реализацию. Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind, Gorry Fairhurst, Russ Housley, Paul Aitken, Daniele Ceccarelli, Mohamed Boucadair улучшили документ своими рецензиями и предложениями.

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

Matt Mathis

Email: matt.mathis@gmail.com

Neal Cardwell

Google, Inc.

Email: ncardwell@google.com

Yuchung Cheng

Google, Inc.

Email: ycheng@google.com

Nandita Dukkipati

Google, Inc.

Email: nanditad@google.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9847 IANA Registry Updates for TLS and DTLS

Опубликовано 18.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        J. Salowey
Request for Comments: 9847                                      CyberArk
Updates: 8447                                                  S. Turner
Category: Standards Track                                          sn3rd
ISSN: 2070-1721                                            December 2025

IANA Registry Updates for TLS and DTLS

Обновление реестров IANA для TLS и DTLS

PDF

Аннотация

Этот документ обновляет изменения в реестрах TLS и DTLS IANA, внесённые RFC 8447. Добавлено новое значение D (discouraged — не рекомендуется) в столбец Recommended некоторых реестров TLS и столбец Comment (комментарий) во все активные реестры, где его не было. Также обновлены инструкции для запросов на регистрацию.

Документ обновляет RFC 8447.

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

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

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

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

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

1. Введение

Этот документ предписывает IANA внести множество изменений в реестры, относящиеся к защите транспортного уровня (Transport Layer Security или TLS) и защите транспортного уровня дейтаграмм (Datagram Transport Layer Security или DTLS). Изменения обновляют данные, внесённые [RFC8447].

Спецификация добавляет новое значение D (discouraged — не рекомендуется) для столбца Recommended в некоторых реестрах TLS и столбца Comment в реестры, где его ещё нет.

Спецификация также обновляет инструкции для запросов регистрации.

2. Уровни требований

3. Обновление значений столбца Recommended

Этот документ обновляет столбец Recommended (рекомендовано), добавленный [RFC8447], значением D, указывающим что строка (значение) не рекомендуется. Возможные значения описаны ниже.

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

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

Указывает, что данный элемент не рекомендуется применять. Это может использоваться для указания механизмов, при использовании которых могут возникать проблемы (например, слабая криптография или проблемы функциональной совместимости при внедрении). При указании статуса D с колонке Reference или Comment должны быть достаточные сведения о причинах такой маркировки. Разработчикам и пользователям следует ознакомиться с этими сведениями для понимания условий, при которых элемент не следует или недопустимо использовать.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов (Expert Review) или IESG Approval [RFC8126]. Не все элементы, заданные в Standards Track RFC требуют установки статуса Y или D. Для всех элементов с неуказанным статусом предполагается N. Столбец не заполняется для резервных и невыделенных значений, пока не появится соответствующая спецификация.

3.1. Примечание для столбца Recommended

В имеющихся реестрах есть примечания о значении столбца Recommended. Для описанных ниже реестров эти примечания обновлены описанием значения D, как показано ниже.

Примечание. Если в столбце Recommended указано значение N, это необязательно говорит о недостатках. Скорее это указывает, что элемент не прошёл продедуру согласования IETF, имеет ограниченную применимость или предназначен лишь для конкретных случаев. Если в столбце Recommended указно D, данный элемент не рекомендуется и его не следует или недопустимо применять (в зависимости от ситуации). Для лучшего понимания следует обратиться к приведённым ссылкам.

4. Реестр типов расширений TLS

С учётом изменений в столбце Recommended агентство IANA обновило реестр TLS ExtensionType Values:

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ.

Таблица .

Значение	Имя расширения	Рекомендовано
4	truncated_hmac	D
40	Reserved	D
46	Reserved	D
53	connection_id(deprecated)	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Для truncated_hmac добавлена ссылка https://www.iacr.org/archive/asiacrypt2011/70730368/70730368.pdf в столбец Reference.
Для показанных в таблице строк Reserved добавлена ссылка https://mailarchive.ietf.org/arch/msg/tls-reg-review/5BD62HBFjo_AsW-Y8ohVuWEe1gI/ в столбец Reference.

5. Реестр шифров TLS

Несколько категорий шифров не рекомендуются для общего пользования и помечены значением D. Шифронаборы, использующие NULL-шифрование, не обеспечивают конфиденциальности, обычно ожидаемой от TLS. Протоколы и приложения часто разрабатываюися с учётом обеспечения конфиденциальности как свойства защиты и таких случаях недопустимо применять шифронаборы с NULL-шифрованием.

Наборы с пометкой EXPORT используют слабые шифры и не рекомендуются для TLS 1.1 [RFC4346].

Наборы с пометкой anon не обеспечивают аутентификации и уязвимы к атакам в пути, поэтому не рекомендуются для TLS 1.1 [RFC4346].

Шифр RC4 признан слабым и не рекомендуется [RFC7465]. DES и IDEA³ не считаются безопасными для общего пользования и не рекомендуются [RFC5469]. Алгоритмы MD5 и SHA-1 также признаны небезопасными для общего пользования и не рекомендуются [RFC9155].

В соответствии с изменениями столбца Recommended агентство IANA обновило реестр TLS Cipher Suites.

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ. Данный документ не меняет значений в столбце DTLS-OK.

Таблица .

Значение	Описание	Рекомендовано
0x00,0x1E	TLS_KRB5_WITH_DES_CBC_SHA	D
0x00,0x20	TLS_KRB5_WITH_RC4_128_SHA	D
0x00,0x21	TLS_KRB5_WITH_IDEA_CBC_SHA	D
0x00,0x22	TLS_KRB5_WITH_DES_CBC_MD5	D
0x00,0x24	TLS_KRB5_WITH_RC4_128_MD5	D
0x00,0x25	TLS_KRB5_WITH_IDEA_CBC_MD5	D
0x00,0x26	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA	D
0x00,0x27	TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA	D
0x00,0x28	TLS_KRB5_EXPORT_WITH_RC4_40_SHA	D
0x00,0x29	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5	D
0x00,0x2A	TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5	D
0x00,0x2B	TLS_KRB5_EXPORT_WITH_RC4_40_MD5	D
0x00,0x2C	TLS_PSK_WITH_NULL_SHA	D
0x00,0x8A	TLS_PSK_WITH_RC4_128_SHA	D
0x00,0xB0	TLS_PSK_WITH_NULL_SHA256	D
0x00,0xB1	TLS_PSK_WITH_NULL_SHA384	D
0xC0,0x06	TLS_ECDHE_ECDSA_WITH_NULL_SHA	D
0xC0,0x07	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA	D
0xC0,0x10	TLS_ECDHE_RSA_WITH_NULL_SHA	D
0xC0,0x11	TLS_ECDHE_RSA_WITH_RC4_128_SHA	D
0xC0,0x33	TLS_ECDHE_PSK_WITH_RC4_128_SHA	D
0xC0,0x39	TLS_ECDHE_PSK_WITH_NULL_SHA	D
0xC0,0x3A	TLS_ECDHE_PSK_WITH_NULL_SHA256	D
0xC0,0x3B	TLS_ECDHE_PSK_WITH_NULL_SHA384	D
0xC0,0xB4	TLS_SHA256_SHA256	D
0xC0,0xB5	TLS_SHA384_SHA384	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

6. Реестр поддерживаемых групп TLS

В соответствии с изменениями столбца Recommended агентство IANA обновило реестр TLS Supported Groups.

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ.

Таблица .

Значение	Описание	Рекомендовано
1	sect163k1	D
2	sect163r1	D
3	sect163r2	D
4	sect193r1	D
5	sect193r2	D
6	sect233k1	D
7	sect233r1	D
8	sect239k1	D
15	secp160k1	D
16	secp160r1	D
17	secp160r2	D
18	secp192k1	D
19	secp192r1	D
20	secp224k1	D
21	secp224r1	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Удалено примечание Elliptic curve groups (группы эллиптических кривых) из таблицы процедур регистрации.
Для приведённых выше записей добавлена сслыка https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-rfc8447bis-00 в столбец Comment.

7. Реестр меток экспортёров TLS

Этот документ одновляет процедуру регистрации в реестре TLS Exporter Labels и выделение столбца Recommended.

Процедура регистрации Specification Required заменена процедурой Expert Review.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Обновлена роль рецензии экспертов, как указано ниже.

Примечание. Роль назначенных экспертов описана в разделе 17 [RFC8447]. Хотя данный реестр не требует спецификации, [RFC8126] настоятельно рекомендует претендентам на регистрацию указывать ссылку на публично доступную спецификацию, в качестве каковой подходят Internet-Draft (размещён, но не опубликован как RFC), документ другого органа стандартизации, отраслевого консорциума, университета и т. п. Эксперты могут представить более глубокие обзоры, но их одобрение не следует считать одобрением метки экспортёра. Эксперты также проверяют, что метка представляет собой строку печатаемых символов ASCII, начинающуюся с EXPORTER. Агентство IANA должно убедиться, что метка не является префиксом какой-либо другой метки. Например, запрещены метки key и master secretary.

Столбец Note переименован в Comment.

8. Реестр типов сертификатов TLS

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS Certificate Types.

Скорректирована процедура регистрации в части значения столбца Recommended.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

9. Реестр алгоритмов хэширования TLS

TLS 1.0 и TLS 1.1 признаны устаревшими [RFC8996], TLS 1.2 будет применяться ещё некоторое время. В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS HashAlgorithm.

Скорректирована процедура регистрации в части значения столбца Recommended.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS HashAlgorithm добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
0	none	Y
1	md5	D
2	sha1	D
3	sha224	D
4	sha256	Y
5	sha384	Y
6	sha512	Y
8	Intrinsic	Y

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

10. Реестр алгоритмов подписи TLS

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS SignatureAlgorithm добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
0	anonymous	N
1	rsa	Y
2	dsa	N
3	ecdsa	Y
7	ed25519	Y
8	ed448	Y
64	gostr34102012_256	N
65	gostr34102012_512	N

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

11. Рееестр идентификаторв типа сертификата клиента TLS

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS ClientCertificateType Identifiers добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
1	rsa_sign	Y
2	dss_sign	N
3	rsa_fixed_dh	N
4	dss_fixed_dh	N
5	rsa_ephemeral_dh_RESERVED	D
6	dss_ephemeral_dh_RESERVED	D
20	fortezza_dms_RESERVED	D
64	ecdsa_sign	Y
65	rsa_fixed_ecdh	N
66	ecdsa_fixed_ecdh	N
67	gost_sign256	N
68	gost_sign512	N

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

12. Реестр режимов обмена ключами TLS PskKeyExchangeMode

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS PskKeyExchangeMode.

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

13. Реестр схем подписи TLS

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS SignatureScheme.

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

14. Добавление столбца Comment

Агентство IANA добавило столбец Comment в указанные ниже реестры.

TLS ExtensionType Values
TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
TLS CachedInformationType Values
TLS Certificate Compression Algorithm IDs
TLS ClientCertificateType Identifiers
TLS Cipher Suites
TLS ContentType
TLS EC Point Formats
TLS EC Curve Types
TLS Supplemental Data Formats (SupplementalDataType)
TLS UserMappingType Values
TLS SignatureAlgorithm
TLS HashAlgorithm
TLS Authorization Data Formats
TLS Heartbeat Message Types
TLS Heartbeat Modes
TLS SignatureScheme
TLS PskKeyExchangeMode
TLS KDF Identifiers
TLS SSLKEYLOGFILE Labels

В этом списке приведены все реестры, где ещё не было столбца Comment или Note, не отменённые TLS 1.3.

15. Рецензия экспертов на документы IETF и IRTF

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

16. Регистрационные запросы

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

Отправки по адресу iana@iana.org; в поле subject следует указывать цель (например, Request to register value in TLS bar registry).
Путём заполнения формы на странице https://www.iana.org/form/protocol-assignment.

Запросы по процедуре Specification Required [RFC8126] регистрируются после трехнедельного рассмотрения по рекомендации одного или нескльких назначенных экспертов. Для обеспечения возможности выделения значений до публикации назначенные эксперты могут одобрить регистрацию, как только убедятся, что спецификация будет опубликована.

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

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

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

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

Этот документ целиком посвящён изменениям связанных с TLS реестров IANA.

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

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

[RFC4346] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1», RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.

[RFC5469] Eronen, P., Ed., «DES and IDEA Cipher Suites for Transport Layer Security (TLS)», RFC 5469, DOI 10.17487/RFC5469, February 2009, <https://www.rfc-editor.org/info/rfc5469>.

[RFC7465] Popov, A., «Prohibiting RC4 Cipher Suites», RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.

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

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

[RFC8996] Moriarty, K. and S. Farrell, «Deprecating TLS 1.0 and TLS 1.1», BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, «Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2», RFC 9155, DOI 10.17487/RFC9155, December 2021, <https://www.rfc-editor.org/info/rfc9155>.

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

Joe Salowey

CyberArk

Email: joe@salowey.net

Sean Turner

sn3rd

Email: sean@sn3rd.com

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

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

nmalykh@protokols.ru

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

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

3International Data Encryption Algorithm — международный алгоритм шифрования данных.

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

RFC 9911 Common YANG Data Types

Опубликовано 13.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)               J. Schönwälder, Ed.
Request for Comments: 9911                        Constructor University
Obsoletes: 6991                                            December 2025
Category: Standards Track                                               
ISSN: 2070-1721

Common YANG Data Types

PDF

Аннотация

Этот документ вводит набор типов данных общего назначения для использования в языке моделирования данных YANG. Он включает несколько определений новых типов и отменяет RFC 6991.

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

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

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

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

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

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

1. Введение

YANG [RFC7950] является языком моделирования данных, служащим для создания моделей конфигурации и состояния, которыми манипулирует протокол NETCONF³ [RFC6241]. YANG поддерживает небольшой набор встроенных типов данных и обеспечивает механизмы создания производных типов на основе встроенных.

В этом документе представлен набор производных типов данных общего назначения, выведенных из встроенных в YANG типов данных. Производные типы рассчитаны на применение в моделировании всех типов данных управления. Определения типов организованы в несколько модулей YANG. Модуль ietf-yang-types содержит типы данных общего назначения, а в модуле ietf-inet-types содержатся определения, относящиеся к стеку протоколов Internet.

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

модуль ietf-yang-types определяет типы данных общего назначения, такие как счётчики и измерители (датчики), типы, связанные с датами и временем, а также типы для строковых значений (например, UUID, числа, разделённые точками, таги языка);
модуль ietf-inet-types определяет типы данных, связанные со стеком протоколов Internet, такие как адреса IP, доменные имена, имена хостов, URI, адреса электронной почты и типы для базовых полей протоколов (например, номера портов).

Первая версия этих модулей YANG была представлена в [RFC6021]. При пересмотре [RFC6021] в [RFC6991] были добавлены несколько определений типов. Данный пересмотр добавляет определения новых типов и решает проблемы, отмеченные в Erratum ID 4076 [Err4076] и 5105 [Err5105]. Кроме того, определение yang-identifier приведено в соответствие с YANG 1.1 [RFC7950], а также улучшены некоторые операторы pattern. Дополнительные сведения приведены в операторах revision модулей YANG разделов 3 и 4. Краткий обзор всех представленных в этом документе типов дан в разделе 2. В будущем могут быть добавлены новые определения типов путём представления предложений в рабочую группу NETMOD.

В документе используется терминология YANG, определённая в разделе 3 [RFC7950].

2. Обзор

В таблицах 1 и 2 перечислены типы, определённые в модулях YANG ietf-yang-types и ietf-inet-types. Для каждого тпа указано имя, базовый тип и RFC, где данный тип был определён.

Таблица . Типы, определённые в модуле ietf-yang-types.

Тип	Базовый тип	Документ
counter32	uint32	RFC 6021
zero-based-counter32	uint32	RFC 6021
counter64	uint64	RFC 6021
zero-based-counter64	uint64	RFC 6021
gauge32	uint32	RFC 6021
gauge64	uint64	RFC 6021
object-identifier	string	RFC 6021
object-identifier-128	object-identifier	RFC 6021
date-and-time	string	RFC 6021
date	string	RFC 9911
date-no-zone	string	RFC 9911
time	string	RFC 9911
time-no-zone	string	RFC 9911
hours32	int32	RFC 9911
minutes32	int32	RFC 9911
seconds32	int32	RFC 9911
centiseconds32	int32	RFC 9911
milliseconds32	int32	RFC 9911
microseconds32	int32	RFC 9911
microseconds64	int64	RFC 9911
nanoseconds32	int32	RFC 9911
nanoseconds64	int64	RFC 9911
timeticks	int32	RFC 6021
timestamp	timeticks	RFC 6021
phys-address	string	RFC 6021
mac-address	string	RFC 6021
xpath1.0	string	RFC 6021
hex-string	string	RFC 6991
uuid	string	RFC 6991
dotted-quad	string	RFC 6991
language-tag	string	RFC 9911
yang-identifier	string	RFC 6991

Таблица . Типы, определённые в модуле ietf-inet-types.

Тип	Базовый тип	Документ
ip-version	enum	RFC 6021
dscp	uint8	RFC 6021
ipv6-flow-label	uint32	RFC 6021
port-number	uint16	RFC 6021
protocol-number	uint8	RFC 9911
upper-layer-protocol-number	protocol-number	RFC 9911
as-number	uint32	RFC 6021
ip-address	union	RFC 6021
ipv4-address	string	RFC 6021
ipv6-address	string	RFC 6021
ip-address-no-zone	union	RFC 6991
ipv4-address-no-zone	ipv4-address	RFC 6991
ipv6-address-no-zone	ipv6-address	RFC 6991
ip-address-link-local	union	RFC 9911
ipv4-address-link-local	ipv4-address	RFC 9911
ipv6-address-link-local	ipv6-address	RFC 9911
ip-prefix	union	RFC 6021
ipv4-prefix	string	RFC 6021
ipv6-prefix	string	RFC 6021
ip-address-and-prefix	union	RFC 9911
ipv4-address-and-prefix	string	RFC 9911
ipv6-address-and-prefix	string	RFC 9911
domain-name	string	RFC 6021
host-name	domain-name	RFC 9911
host	union	RFC 6021
uri	string	RFC 6021
email-address	string	RFC 9911

Некоторые типы имеют эквиваленты в Structure of Management Information Version 2 (SMIv2) [RFC2578] [RFC2579]. Тип данных YANG является эквивалентным типу SMIv2, если оба типа имеют эквивалентные значения и их семантику.

В таблице 3 указаны типы из модуля ietf-yang-types и соответствующие типы SMIv2, а в таблице 4 — типы из ietf-inet-types и соответствующие типы SMIv2.

Таблица . Типы ietf-yang-types и их эквиваленты в SMIv2.

Тип YANG	Эквивалентный тип SMIv2 (модуль)
counter32	Counter32 (SNMPv2-SMI)
zero-based-counter32	ZeroBasedCounter32 (RMON2-MIB)
counter64	Counter64 (SNMPv2-SMI)
zero-based-counter64	ZeroBasedCounter64 (HCNUM-TC)
gauge32	Gauge32 (SNMPv2-SMI)
gauge64	CounterBasedGauge64 (HCNUM-TC)
object-identifier-128	OBJECT IDENTIFIER
centiseconds32	TimeInterval (SNMPv2-TC)
timeticks	TimeTicks (SNMPv2-SMI)
timestamp	TimeStamp (SNMPv2-TC)
phys-address	PhysAddress (SNMPv2-TC)
mac-address	MacAddress (SNMPv2-TC)
language-tag	LangTag (LANGTAG-TC-MIB)

Таблица . Типы ietf-inet-types и их эквиваленты в SMIv2.

Тип YANG	Эквивалентный тип SMIv2 (модуль)
ip-version	InetVersion (INET-ADDRESS-MIB)
dscp	Dscp (DIFFSERV-DSCP-TC)
ipv6-flow-label	IPv6FlowLabel (IPV6-FLOW-LABEL-MIB)
port-number	InetPortNumber (INET-ADDRESS-MIB)
as-number	InetAutonomousSystemNumber (INET-ADDRESS-MIB)
uri	Uri (URI-TC-MIB)

3. Базовые производные типы YANG

Модуль YANG ietf-yang-types ссылается на [IEEE-802-2024], [ISO-8601], [ISO-9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4502], [RFC5131], [RFC5646], [RFC7950], [RFC9557], [RFC9562], [XPATH], [XSD-TYPES].

   <CODE BEGINS> file "ietf-yang-types@2025-12-22.yang"
   module ietf-yang-types {
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
     prefix yang;

     organization
       "IETF Network Modeling (NETMOD) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Editor:   Jürgen Schönwälder
                  <mailto:jschoenwaelder@constructor.university>"; 
     description
       "Этот модуль содержит набор производных типов данных YANG 
        общего назначения.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

        Эта версия данного модуля YANG является частью RFC 9911, где
        правовые вопросы рассмотрены более полно.";

     revision 2025-12-22 {
       description
         "Этот выпуск документа добавляет указанные ниже типы данных:
          - yang:date
          - yang:date-no-zone
          - yang:time
          - yang:time-no-zone
          - yang:hours32
          - yang:minutes32
          - yang:seconds32
          - yang:centiseconds32
          - yang:milliseconds32
          - yang:microseconds32
          - yang:microseconds64
          - yang:nanoseconds32
          - yang:nanoseconds64
          - yang:language-tag
          Определение yang-identifier приведено в соответствие с YANG
          1.1 и типами, представляющими время с високосными секундами.
          Представление часовых поясов приведено в соответствие с RFC 
          9557. Улучшены некоторые операторы description и pattern.";
       reference
         "RFC 9911: Common YANG Data Types";
     }
     revision 2013-07-15 {
       description
         "Этот выпуск документа добавляет указанные ниже типы данных:
          - yang:yang-identifier
          - yang:hex-string
          - yang:uuid
          - yang:dotted-quad";
       reference
         "RFC 6991: Common YANG Data Types";
     }
     revision 2010-09-24 {
       description
         "Исходный выпуск.";
       reference
         "RFC 6021: Common YANG Data Types";
     }

     /*** Набор типов для счётчиков и датчиков ***/

     typedef counter32 {
       type uint32;
       description
         "Тип counter32 представляет неотрицательные целые числа,
          которые монотонно растут до максимального значения
          2^32-1 (десятичное число 4294967295), затем счёт 
          повторяется с нуля.

          Для счётчиков не определены 'начальные' значения, поэтому
          одиночное значение счётчика (обычно) не имеет смысла. Разрывы
          в монотонном росте значений счётчиков обычно связаны с 
          реинициализацией системы управления или другими событиями, 
          указанными в описании узла схемы, применяющего этот тип.
          Если не связанные с инициализацией события возможны, при 
          создании счётчиков типа counter32 не в процессе инициализации
          следует определить соответствующий  узел схемы подходящего типа
          для указания последнего разрыва счётчика.

          Тип counter32 не следует применять для конфигурационных 
          узлов схемы. НЕ СЛЕДУЕТ применять оператор default вместе
          с типом counter32.

          Набор значений и семантика этого типа эквивалентны типу
          Counter32 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef zero-based-counter32 {
       type counter32;
       default "0";
       description
         "Тип zero-based-counter32 представляет counter32 с начальным
          значением 0. 
          
          Узел схемы этого типа будет устанавливаться в 0  при создании
          и далее будет монотонно расти до максимального значения 2^32-1
          (десятичное число 4294967295), затем обращаться в 0 с 
          последующим монотонным ростом.

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

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению ZeroBasedCounter32 в SMIv2.";
       reference
         "RFC 4502: Remote Network Monitoring Management Information
                    Base Version 2";
     }

     typedef counter64 {
       type uint64;
       description
         "Тип counter64 представляет неотрицательные целые числа,
          которые монотонно растут до максимального значения
          2^64-1 (десятичное число 18446744073709551615), затем 
          счёт повторяется с нуля.

          Для счётчиков не определены начальные значения, поэтому
          одиночное значение счётчика (обычно) не имеет смысла.
          Разрывы в монотонном росте значений счётчиков обычно
          связаны с реинициализацией системы управления или другими
          событиями, указанными в описании узла схемы, применяющего
          этот тип. Если не связанные с инициализацией события
          возможны, при создании счётчиков типа  counter64 не в
          процессе инициализации следует определить соответствующий
          узел схемы подходящего типа для указания последнего 
          разрыва счётчика.
 
          Тип counter64 не следует применять для конфигурационных 
          узлов схемы. НЕ СЛЕДУЕТ применять оператор default вместе
          с типом counter64.

          Набор значений и семантика этого типа эквивалентны типу
          Counter64 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef zero-based-counter64 {
       type counter64;
       default "0";
       description
         "Тип zero-based-counter64 представляет counter64 с 
          начальным значением 0.

          Узел схемы этого типа будет устанавливаться в 0 при создании
          и далее будет монотонно расти до максимального значения
          2^64-1 (десятичное число 18446744073709551615), затем 
          обращаться в 0 с последующим монотонным ростом.

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

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению ZeroBasedCounter64 в SMIv2.";
       reference
         "RFC 2856: Textual Conventions for Additional High Capacity
                    Data Types";
     }

     typedef gauge32 {
       type uint32;
       description
         "Тип gauge32 представляет неотрицательное целое число,
          которое может расти и уменьшаться, не переходя максимального
          и минимального значения. Максимальное значение не может быть
          больше 2^32-1 (десятичное число 4294967295), а минимальное -
          меньше 0. Значение gauge32 достигает максимума, когда 
          моделируемые данные не меньше максимума, а минимума - когда
          моделируемые данные не больше минимального значения. Если
          моделируемые затем данные снижаются (растут) ниже максимума 
          (выше минимума) значение gauge32 также снижается (растёт).

          Набор значений и семантика этого типа эквивалентны типу
          Gauge32 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef gauge64 {
       type uint64;
       description
         "Тип gauge64 представляет неотрицательное целое число,
          которое может расти и уменьшаться, не переходя максимального
          и минимального значения. Максимальное значение не может быть
          больше 2^64-1 (десятичное число 18446744073709551615), а 
          минимальное - меньше 0. Значение gauge32 достигает максимума, 
          когда моделируемые данные не меньше максимума, а минимума - 
          когда моделируемые данные не больше минимального значения. Если
          моделируемые затем данные снижаются (растут) ниже максимума 
          (выше минимума) значение gauge64 также снижается (растёт).

          Набор значений и семантика этого типа эквивалентны текстовому
          соглашению CounterBasedGauge64 SMIv2, определённому в RFC 2856";
       reference
         "RFC 2856: Textual Conventions for Additional High Capacity
                    Data Types";
     }

     /*** Набор типов, связанных с идентификаторами ***/

     typedef object-identifier {
       type string {
         pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9][0-9]*))))'
               + '(\.(0|([1-9][0-9]*)))*';
       }
       description
         "Тип object-identifier представляет административно 
          назначаемые имена в дереве registration-hierarchical-name.

          Значения этого типа представляются последовательностью
          числовых неотрицательных значений субидентификаторов, каждое
          ДОЛЖНО быть не более 2^32-1 (десятичное число 4294967295).
          Субидентификаторы разделяются одним символом точки без
          промежуточных пробельных символов.

          Стандарт ASN.1 ограничивает пространство значений первого
          субидентификатора цифрами 0, 1 и 2. Кроме того, диапазон
          второго субидентификатора ограничен значениями от 0 до 39,
          если первый субидентификатор равен 0 или 1. В дополнение 
          стандарт ASN.1 требует наличия в идентификаторе объекта не
          менее 2 субидентификаторов. Шаблон соответствует этим
          ограничениям.

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

          Этот тип является надмножеством типа SMIv2 OBJECT IDENTIFIER,
          поскольку не ограничен пределом в 128 субидентификаторов.
          Поэтому данный тип НЕ СЛЕДУЕТ применять для представления 
          SMIv2 OBJECT IDENTIFIER, взамен СЛЕДУЕТ использовать тип
          object-identifier-128.";
       reference
         "ISO 9834-1: Information technology -- Procedures for the
          operation of object identifier registration authorities --
          Part 1: General procedures and top arcs of the international
          object identifier tree";
     }

     typedef object-identifier-128 {
       type object-identifier {
         pattern '[0-9]*(\.[0-9]*){1,127}';
       }
       description
         "Этот тип представляет идентификаторы объектов, содержащие
          не более 128 субидентификаторов.

          Набор значений и семантика этого типа эквивалентны типу
          OBJECT IDENTIFIER в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     /*** Набор типов для дат и времени ***/

     typedef date-and-time {
       type string {
         pattern
           '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'
         + 'T(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?'
         + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип date-and-time является профилем стандарта ISO 8601
          для представления дат и времени с использованием григорианского
          календаря. Профиль определён date-time в параграфе 5.6 RFC 3339
          и обновлён в разделе 2 RFC 9557. Значение 60 допускается лишь в
          в случае високосных секунд.

          Тип date-and-time совместим с типом dateTime схемы XML с учётом
          приведённых ниже исключений.

          (a) date-and-time не разрешает отрицательные значения лет.

          (b) Значение time-offset Z указывает, что date-and-time
              задано в UTC и локальный часовой пояс не известен.
              Значение time-offset +00:00 указывает, что date-and-time
              задано в UTC и локальным часовым поясом тоже служит UTC
              (см. раздел 2 в RFC 9557).

          Этот тип не эквивалентен текстовому соглашению DateAndTime 
          в SMIv2, поскольку RFC 3339 использует другой разделитель 
          между full-date и full-time, а также обеспечивает большую
          точность time-secfrac.

          Канонический формат для значений date-and-time с известным
          часовым поясом использует сдвиг часового пояса, который
          рассчитывается с использованием настроенного в устройстве 
          смещения от UTC. Смена смещения в устройстве меняет значение
          date-and-time должным образом. Такие изменения могут быть
          периодическими в результате перехода на летнее время (DST).
          В каноническом формате значений date-and-time в UTC с
          неизвестным часовым поясом СЛЕДУЕТ использовать 
          time-offset Z и МОЖНО MAY применять -00:00 для совместимости
          с прежними версиями.";
       reference
         "ISO 8601: Data elements and interchange formats -- Information
                    interchange -- Representation of dates and times
          RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          RFC 2579: Textual Conventions for SMIv2
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef date {
       type string {
         pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'
               + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип данных date представляет временной интервал в сутках (24
          24 часа) и может включать часовой пояс.

          Тип date совместим с типом date в схеме XML с приведёнными 
          ниже ограничениями:

          (a) Тип date не допускает отрицательные значения лет.

          (b) Значение time-offset Z указывает, что date задано в UTC 
              и локальный часовой пояс не известен. Значение time-offset 
              +00:00 указывает, что date задано в UTC и локальным 
              часовым поясом тоже служит UTC (см. раздел 2 в RFC 9557).

          Канонический формат для значений date с известным часовым
          поясом использует сдвиг часового пояса, который рассчитывается
          с использованием настроенного в устройстве смещения от UTC. 
          Смена смещения в устройстве меняет значение date должным 
          образом. Такие изменения могут быть периодическими в результате 
          перехода на летнее время (DST). В каноническом формате значений 
          date в UTC с неизвестным часовым поясом использзуется
          time-offset Z.";
       reference
         "RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef date-no-zone {
       type date {
         pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])';
       }
       description
         "Тип date-no-zone представляет дату без часового пояса.";
     }

     typedef time {
       type string {
         pattern
           '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?'
         + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип time представляет момент времени, повторяющийся каждый
          день, и может включать часовой пояс. Значение 60 допускается
          только для високосных секунд.

          Тип time совместим с типом time схемы XML с одним исключением:

          (a) Значение time-offset Z указывает, что time задано в UTC 
              и локальный часовой пояс не известен. Значение time-offset 
              +00:00 указывает, что time задано в UTC и локальным 
              часовым поясом тоже служит UTC (см. раздел 2 в RFC 9557).

          Канонический формат для значений time с известным часовым
          поясом использует сдвиг часового пояса, который рассчитывается
          с использованием настроенного в устройстве смещения от UTC. 
          Смена смещения в устройстве меняет значение time должным 
          образом. Такие изменения могут быть периодическими в результате 
          перехода на летнее время (DST). В каноническом формате значений 
          time в UTC с неизвестным часовым поясом использзуется
          time-offset Z.";
       reference
         "RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef time-no-zone {
       type time {
         pattern
           '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?';
       }
       description
         "Тип time-no-zone представляет время без часового пояса.";
     }

     typedef hours32 {
       type int32;
       units "hours";
       description
         "Период времени, заданный в часах.

          Допустимые значения лежат в диапазоне [-89478485 дней 
          08:00:00 часов - 89478485 дней 07:00:00 часов].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef minutes32 {
       type int32;
       units "minutes";
       description
         "Период времени, заданный в минутах.

          Допустимые значения лежат в диапазоне [-1491308 дней 2:08:00 - 
          1491308 дней 2:07:00].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef seconds32 {
       type int32;
       units "seconds";
       description
         "Период времени, заданный в секундах.

          Допустимые значения лежат в диапазоне [-24855 дней 03:14:08 - 
          24855 дней 03:14:07].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef centiseconds32 {
       type int32;
       units "centiseconds";
       description
         "Период времени, заданный в сотых долях секунды.

          Допустимые значения лежат в диапазоне [-248 дней 13:13:56 - 
          248 дней 13:13:56].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef milliseconds32 {
       type int32;
       units "milliseconds";
       description
         "Период времени, заданный в миллисекундах.

          Допустимые значения лежат в диапазоне [-24 дня 20:31:23 - 
          24 дня 20:31:23].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef microseconds32 {
       type int32;
       units "microseconds";
       description
         "Период времени, заданный в микросекундах.

          Допустимые значения лежат в диапазоне [-00:35:47 to 00:35:47].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef microseconds64 {
       type int64;
       units "microseconds";
       description
         "Период времени, заданный в микросекундах.

          Допустимые значения лежат в диапазоне [-106751991 дней 04:00:54
          - 106751991 дней 04:00:54].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef nanoseconds32 {
       type int32;
       units "nanoseconds";
       description
         "Период времени, заданный в наносекундах.

          Допустимые значения лежат в диапазоне [-00:00:02 to 00:00:02].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef nanoseconds64 {
       type int64;
       units "nanoseconds";
       description
         "Период времени, заданный в наносекундах.

          Допустимые значения лежат в диапазоне [-106753 дней 23:12:44 -
          106752 дней 0:47:16].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef timeticks {
       type uint32;
       description
         "Тип timeticks представляет неотрицательные целые числа,
          которые указывают по модулю 2^32 (десятичное число
          4294967296) время в сотых долях секунды между двумя эпохами.
          При определении узла схемы, использующего этот тип, описание
          узла указывает обе опорных эпохи.

          Набор значений и семантика этого типа эквивалентны типу
          TimeTicks в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef timestamp {
       type timeticks;
       description
         "Тип timestamp представляет значение связанного с ним узла
          схемы timeticks, где происходит конкретное вхождение,
          которое должно быть определено в описании каждого узла схемы,
          определённого с использованием этого типа. Когда конкретное
          вхождение происходит до того, как связанный атрибут timeticks
          в последний раз был равен нулю, timestamp = 0. 

          Отметим, что это требует сброса в 0 всех значений timestamp,
          когда значение связанного атрибута timeticks превышает 497
          дней и переходит через 0.

          Связанный узел схемы timeticks должен быть задан в описании
          любого узла схемы, использующего этот тип.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению TimeStamp в SMIv2.";
       reference
         "RFC 2579: Textual Conventions for SMIv2";
     }

     /*** Набор базовых типов для адресов ***/

     typedef phys-address {
       type string {
         pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
       }
       description
         "Представляет адрес среды или физического уровня в форме 
          последовательности октетов, каждый из которых указывается
          двумя шестнадцатеричными цифрами. В каноническом 
          представлении используются строчные буквы (нижний регистр).

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению PhysAddress в SMIv2.";
       reference
         "RFC 2579: Textual Conventions for SMIv2";
     }

     typedef mac-address {
       type string {
         pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
       }
       description
         "Тип mac-address представляет адрес IEEE 802 MAC.
          В каноническом представлении используются строчные буквы.
          Отметим, что этот тип не может представлять адреса с рахмером,
          отличным от IEEE 802 MAC и для них можно применять тип
          phys-address.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению MacAddress в SMIv2.";
       reference
         "IEEE 802: IEEE Standard for Local and Metropolitan Area
                    Networks: Overview and Architecture
          RFC 2579: Textual Conventions for SMIv2";
     }

     /*** Тип, связанный с XML ***/

     typedef xpath1.0 {
       type string;
       description
         "Этот тип представляет выражение XPATH 1.0.

          Когда определяется узел схемы, использующий этот тип, 
          описание узла ДОЛЖНО указывать контекст XPath, в котором
          вычисляется выражение XPath.";
       reference
         "XPATH: XML Path Language (XPath) Version 1.0";
     }

     /*** Строковые типы ***/

     typedef hex-string {
       type string {
         pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
       }
       description
         "Шестнадцатеричная строка с октетами, представленными двумя
          шестнадцатеричными цифрами, разделёнными двоеточием. В 
          каноническом варианте применяются строчные буквы.";
     }

     typedef uuid {
       type string {
         pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
               + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
       }
       description
         "Глобально уникальный идентификатор (UUID) в строковом 
          представлении, определённом в RFC 4122. В каноническом варианте 
          применяются строчные буквы.

          Ниже приведён пример строкового представления UUID 
          f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
       reference
         "RFC 9562: Universally Unique IDentifiers (UUIDs)";
     }

     typedef dotted-quad {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
       }
       description
         "32-битовое целое число без знака, представленное 4 десятичными
          числами, разделёнными точками (full stop).";
     }

     typedef language-tag {
       type string;
       description
         "Тег языка в соответствии с RFC 5646 (BCP 47). В каноническом
          представлении применяются строчные буквы.

          Значения этого типа должны быть корректно сформированными
          тегами языка в соответствии с BCP 47. Реализации МОГУТ 
          дополнительно ограничивать принимаемые значения 'проверяющим'
          процессором, как указано в BCP 47.

          Каноническое представление значений этого типа соответствует
          тектовому соглашению SMIv2 LangTag с учётом ограничений по
          длине, принятых для LangTag.";
       reference
         "RFC 5646: Tags for Identifying Languages
          RFC 5131: A MIB Textual Convention for Language Tags";
     }

     /*** Набор типов, связанных с YANG ***/

     typedef yang-identifier {
       type string {
         length "1..max";
         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
       }
       description
         "Строка идентификатора YANG в соответствии с правилом 
          'identifier' раздела 14 в RFC 7950. Идентификатор должен
          начинаться с буквы или символа подчёркивания, за которым
          следует произвольный набор букв, цифр, символов подчёркивания,
          дефисов и точек.

          Это определение соответствует YANG 1.1 (RFC 7950). В RFC 6991
          определение исключало строки, начинающиеся с xml (в любой
          комбинации регистров), как было задано для YANG 1 в RFC 6020. 
          Если данный тип применяется в контекте YANG 1, следует
          соблюдать данное ограничение.";
       reference
         "RFC 7950: The YANG 1.1 Data Modeling Language
          RFC 6991: Common YANG Data Types
          RFC 6020: YANG - A Data Modeling Language for the
                    Network Configuration Protocol (NETCONF)";
     }
   }
   <CODE ENDS>

4. Типы для стека протоколов Internet

Модуль YANG ietf-inet-types ссылается на [RFC0768], [RFC0791], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3927], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC4592], [RFC5017], [RFC5322], [RFC5890], [RFC5952], [RFC6532], [RFC6793], [RFC8200], [RFC9260], [RFC9293], [RFC9499].

   <CODE BEGINS> file "ietf-inet-types@2025-12-22.yang"
   module ietf-inet-types {
     namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
     prefix inet;

     organization
       "IETF Network Modeling (NETMOD) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Editor:   Jürgen Schönwälder
                  <mailto:jschoenwaelder@constructor.university>"; 
     description
       "Этот модуль содержит набор производных типов данных YANG 
        для адресов Internet и связанных элементов.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

        Эта версия модуля YANG является частью RFC 9911, где
        правовые аспекты выражены более полно.";

     revision 2025-12-22 {
       description
         "В этом выпуске добавлены указанные ниже типы данных:
          - inet:ip-address-and-prefix
          - inet:ipv4-address-and-prefix
          - inet:ipv6-address-and-prefix
          - inet:protocol-number
          - inet:upper-layer-protocol-number
          - inet:host-name
          - inet:email-address
          - inet:ip-address-link-local
          - inet:ipv4-address-link-local
          - inet:ipv6-address-link-local
          Определение inet:host было изменено с использованием
          inet:host-name вместо inet:domain-name. Улучшены некоторые 
          операторы pattern.";
       reference
         "RFC 9911: Common YANG Data Types";
     }
     revision 2013-07-15 {
       description
         "В этом выпуске добавлены типы данных:
          - inet:ip-address-no-zone
          - inet:ipv4-address-no-zone
          - inet:ipv6-address-no-zone";
       reference
         "RFC 6991: Common YANG Data Types";
     }
     revision 2010-09-24 {
       description
         "Исходный выпуск.";
       reference
         "RFC 6021: Common YANG Data Types";
     }

     /*** Набор типов для полей протоколов ***/

     typedef ip-version {
       type enumeration {
         enum unknown {
           value 0;
           description
             "An unknown or unspecified version of the Internet
              Protocol.";
         }
         enum ipv4 {
           value 1;
           description
             " Протокол IPv4 в соответствии с RFC 791.";
         }
         enum ipv6 {
           value 2;
           description
             " Протокол IPv6 в соответствии с RFC 8200.";
         }
       }
       description
         "Это значение представляет версию протокола IP.

          По набору значений и семантике этот тип эквивалентен
          текстовому соглашению InetVersion в SMIv2.";
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
          RFC 4001: Textual Conventions for Internet Network Addresses";
     }

     typedef dscp {
       type uint8 {
         range "0..63";
       }
       description
         "Тип dscp представляет коды дифференцированного обслуживания,
          которые могут применяться для маркировки пакетов в потоке.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению Dscp в SMIv2.";
       reference
         "RFC 3289: Management Information Base for the Differentiated
                    Services Architecture
          RFC 2474: Definition of the Differentiated Services Field
                    (DS Field) in the IPv4 and IPv6 Headers
          RFC 2780: IANA Allocation Guidelines For Values In
                    the Internet Protocol and Related Headers";
     }

     typedef ipv6-flow-label {
       type uint32 {
         range "0..1048575";
       }
       description
         "Тип ipv6-flow-label представляет идентификатор или метку 
          потока в заголовке пакета IPv6, которые могут служить для 
          различения потоков трафика.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению IPv6FlowLabel в SMIv2.";
       reference
         "RFC 3595: Textual Conventions for IPv6 Flow Label
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     typedef port-number {
       type uint16 {
         range "0..65535";
       }
       description
         "Тип port-number представляет 16-битовый номер порта протоколов
          транспортного уровня Internet, таких как UDP, TCP, DCCP, SCTP.

          Номера портов распределяются IANA. Текущий список выделенных
          портов доступен на сайте <http://www.iana.org/>. 

          Отметим, что номер 0 зарезервирован IANA.  В ситуациях, где
          нулевое значение не имеет смысла, оно может быть исключено
          путём создания субтипа для port-number без 0. 

          Набор значений и семантика для этого типа эквивалентны 
          текстовому соглашению InetPortNumber в SMIv2.";

       reference
         "RFC  768: User Datagram Protocol
          RFC 9293: Transmission Control Protocol (TCP)
          RFC 9260: Stream Control Transmission Protocol
          RFC 4340: Datagram Congestion Control Protocol (DCCP)
          RFC 4001: Textual Conventions for Internet Network Addresses";
     }

     typedef protocol-number {
       type uint8;
       description
         "Тип protocol-number представляет 8-битовый номер протокола 
          Internet, передаваемый в поле protocol заголовка IPv4 или в
          поле next header заголовка IPv6.
          Номера протоколов выделяются IANA. Текущий список номеров
          доступен по ссылке <https://www.iana.org/>."; 
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     typedef upper-layer-protocol-number {
       type protocol-number;
       description
         "Поле upper-layer-protocol-number представляет протокол 
          вышележащего уровня в пакете IP. Для пакетов IPv6 с заголовками
          расширения этот номер передаётся в последнем поле next header
          цепочки заголовков расширения IPv6.";
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     /*** Набор типов, связанных с автономными системами ***/

     typedef as-number {
       type uint32;
       description
         "Тип as-number представляет номера автономных систем (AS). 
          AS образует набор маршрутизаторов с общим техническим
          администрированием, использующих протокол внутренней
          маршрутизации и общую метрику внутри AS, а также протокол
          внешней маршрутизации для пересылки пакетов в другие AS. IANA 
          поддерживает пространство номеров AS, передав большую часть
          блоков AS для распределения региональным регистраторам.

          Номера AS исходно были 16-битовыми, но расширения BGP
          увеличили размер пространства номеров AS до 32 битов.
          Поэтому данный тип использует базовый тип uint32 без 
          ограничения диапазона для поддержки полного пространства.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению InetAutonomousSystemNumber в SMIv2.";
       reference
         "RFC 1930: Guidelines for creation, selection, and registration
                    of an Autonomous System (AS)
          RFC 4271: A Border Gateway Protocol 4 (BGP-4)
          RFC 4001: Textual Conventions for Internet Network Addresses
          RFC 6793: BGP Support for Four-Octet Autonomous System (AS)
                    Number Space";
     }

     /*** Набор типов для адресов IP и имён хостов ***/

     typedef ip-address {
       type union {
         type ipv4-address;
         type ipv6-address;
       }
       description
         "Тип ip-address представляет адрес IP независимо от версии IP.
          Формат текстового представления подразумевает версию IP. 
          Этот тип поддерживает ограниченные (scoped) адреса, разрешая
          указывать идентификаторы зон в формате адресов.";
       reference
         "RFC 4007: IPv6 Scoped Address Architecture";
     }

     typedef ipv4-address {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '(%.+)?';
       }
       description
         "Тип ipv4-address представляет адрес IPv4 в десятичной
          нотации с разделением точками. Адрес IPv4 может включать
          индекс зоны, отделённый символом %. Если в системе применяются
          имена зон, не представляемые символами UTF-8, реализации нужно
          иметь механизм преобразования локального имени в UTF-8. 
          Задание такого механизма выходит за рамки этого документа.

          Индекс зоны служит для того, чтобы различать идентичные
          значения адресов. Для адресов link-local индексом зоны
          обычно служит индекс или имя интерфейса. Если индекса зоны
          нет, используется принятая по умолчанию зона устройства.

          Каноническим для индекса зоны является числовой формат.";
     }
     typedef ipv6-address {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(%.+)?';
       }
       description
         "Тип ipv6-address представляет адрес IPv6 в полной, сокращённой
          или сокращённой смешанной нотации. Адрес IPv6 может включать 
          индекс зоны, отделённый символом %. Если в системе применяются
          имена зон, не представляемые символами UTF-8, реализации нужно
          иметь механизм преобразования локального имени в UTF-8. 
          Задание такого механизма выходит за рамки этого документа.

          Индекс зоны служит для того, чтобы различать идентичные
          значения адресов. Для адресов link-local индексом зоны
          обычно служит индекс или имя интерфейса. Если индекса зоны
          нет, будет применяться принятая по умолчанию зона устройства.

          Канонический формат адреса IPv6 использует текстовое
          представление, определённое в разделе 4 RFC 5952. 
          Для индекса зоны каноническим является числовой
          формат, описанный в параграфе 11.2 RFC 4007.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture
          RFC 4007: IPv6 Scoped Address Architecture
          RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-no-zone {
       type union {
         type ipv4-address-no-zone;
         type ipv6-address-no-zone;
       }
       description
         "Тип ip-address-no-zone представляет адрес IP независимо от
          версии IP. Формат текстового представления подразумевает
          версию IP. Этот тип не поддерживает ограниченные (scoped)
          адреса, поскольку он не включает идентификатор зоны.";
       reference
         "RFC 4007: IPv6 Scoped Address Architecture";
     }

     typedef ipv4-address-no-zone {
       type ipv4-address {
         pattern '[0-9\.]*';
       }
       description
         "Адрес IPv4 без индекса зоны. Этот тип, производный от 
          ipv4-address, может применяться в ситуациях, где индекс зоны
          известен из контекста и поэтому не требуется.";
     }

     typedef ipv6-address-no-zone {
       type ipv6-address {
         pattern '[0-9a-fA-F:\.]*';
       }
       description
         "Адрес IPv6 без индекса зоны. Этот тип, производный от 
          ipv6-address, может применяться в ситуациях, где индекс зоны
          известен из контекста и поэтому не требуется.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture
          RFC 4007: IPv6 Scoped Address Architecture
          RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-link-local {
       type union {
         type ipv4-address-link-local;
         type ipv6-address-link-local;
       }
       description
         "Тип ip-address-link-local представляет адрес link-local 
          независимо от версии IP. Формат текстового представления
          подразумевает версию IP.";
     }

     typedef ipv4-address-link-local {
       type ipv4-address {
         pattern '169\.254\..*';
       }
       description
         "Тип ipv4-address-link-local представляет адрес link-local IPv4
          в префиксе 169.254.0.0/16, как указано в параграфе 2.1 
          RFC 3927.";
       reference
         "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses";
     }

     typedef ipv6-address-link-local {
       type ipv6-address {
         pattern '[fF][eE][89aAbB][0-9a-fA-F]:.*';
       }
       description
         "Тип ipv6-address-link-local представляет адрес link-local IPv6
          в префиксе fe80::/10, как указано в параграфе 2.4 RFC 4291.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture";
     }

     typedef ip-prefix {
       type union {
         type ipv4-prefix;
         type ipv6-prefix;
       }
       description
         "Тип ip-prefix представляет префикс IP независимо от версии IP.
          Формат текстового представления подразумевает версию IP.";
     }

     typedef ipv4-prefix {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
       }
       description
         "Тип ipv4-prefix представляет адресный префикс IPv4. Размер 
          префикса указывается числом после знака / и должен
          быть не больше 32.
   
          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          Канонический формат префикса IPv4 имеет значение 0 во всех
          битах адреса IPv4, не являющихся частью префикса IPv4.";

          Определение ipv4-prefix не требует установки значения 0 для
          битов, не являющихся частью префикса. Однако реализации должны
          возвращать значения в каноническом формате, который требует
          установки таких битов в 0. Это означает, что префикс 
          192.0.2.1/24 должен восприниматься как корректный, но
          преобразовываться в каноническое значение 192.0.2.0/24.";
     }

     typedef ipv6-prefix {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(/.+)';
       }
       description
         "Тип ipv6-prefix представляет адресный префикс IPv6. Размер 
          префикса указывается числом после знака / и должен
          быть не больше 128.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          В адресе IPv6 все биты, не относящиеся к префиксу, следует
          устанавливать в 0.

          Канонический формат префикса IPv6 имеет значение 0 во всех
          битах адреса IPv6, не являющихся частью префикса IPv6. 
          Кроме того, адреса IPv6 представляется в соответствии 
          с разделом 4 RFC 5952.";

          Определение ipv6-prefix не требует установки значения 0 для
          битов, не являющихся частью префикса. Однако реализации должны
          возвращать значения в каноническом формате, который требует
          установки таких битов в 0. Это означает, что префикс 
          2001:db8::1/64 должен восприниматься как корректный, но
          преобразовываться в каноническое значение 2001:db8::/64.";
       reference
         "RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-and-prefix {
       type union {
         type ipv4-address-and-prefix;
         type ipv6-address-and-prefix;
       }
       description
         "Тип ip-address-and-prefix представляет адрес IP и префикс 
          независимо от версии IP. Формат текстового представления
          подразумевает версию IP.";
     }

     typedef ipv4-address-and-prefix {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
       }
       description
         "Тип ipv4-address-and-prefix представляет адрес IPv4 и
          связанный с ним префикс IPv4. Размер префикса указывается
          число после символа / и не может быть больше 32.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.
     }

     typedef ipv6-address-and-prefix {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(/.+)';
       }
       description
         "Тип ipv6-address-and-prefix представляет адрес IPv6 и
          связанный с ним префикс IPv6. Размер префикса указывается
          число после символа / и не может быть больше 128.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          Канонический формат требует представления адреса IPv6 
          в соответствии с разделом 4 в RFC 5952.";
       reference
         "RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     /*** Набор типов для доменных имён и URI ***/

     typedef domain-name {
       type string {
         length "1..253";
         pattern
           '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
         + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
         + '|\.';
       }
       description
         "Тип domain-name представляет доменные имена DNS.
          По возможности СЛЕДУЕТ применять полные имена (FQDN⁴). Этот
          тип не поддерживает шаблоны (wildcards, см. RFC 4592) и
          бесклассовое делегирование in-addr.arpa (см. RFC 2317).

          Доменные имена Internet не заданы жёстко. Параграф 3.5 в
          RFC 1034 задаёт рекомендуемый синтаксис (изменён в
          параграфе 2.1 RFC 1123). Показанный выше шаблон рассчитан
          на современную практику применения доменных имён и 
          возможные расширения. Отметим, что имена хостов Internet
          имеют более строгий синтаксис (см. RFC 952), чем рекомендации 
          DNS в RFC 1034 и 1123. Узлам схемы, представляющим имена
          хостов, следует применять тип host-name взамен domain-type.

          Размер имён DNS в протоколе DNS ограничен 255 символами.
          Поскольку в кодировании применяются метки с префиксом, 
          задающим размер в байтах, и завершающим NULL-байтом, 
          максимальный размер текстовой части метки составляет 253.

          Раздел описания узлов схемы, использующих тип domain-name,
          ДОЛЖЕН указывать, когда и как эти имена преобразуются в адреса
          IP. Отметим, что для преобразования значений domain-name может
          потребоваться запрос множества записей DNS (например, A для 
          IPv4 и AAAA для IPv6). Порядок преобразования и приоритет 
          записей DNS могут указываться явно или определятся 
          конфигурацией распознавателя (resolver).

          Значения доменных имён используют кодировку US-ASCII со 
          строчными буквами US-ASCII для канонического формата. Имена на 
          других языках ДОЛЖНЫ быть A-метками в соответствии с RFC 5890";
       reference
         "RFC  952: DoD Internet Host Table Specification
          RFC 1034: Domain Names - Concepts and Facilities
          RFC 1123: Requirements for Internet Hosts -- Application
                    and Support
          RFC 2317: Classless IN-ADDR.ARPA delegation
          RFC 2782: A DNS RR for specifying the location of services
                    (DNS SRV)
          RFC 4592: The Role of Wildcards in the Domain Name System
          RFC 5890: Internationalized Domain Names in Applications
                    (IDNA): Definitions and Document Framework
          RFC 9499: DNS Terminology";
     }

     typedef host-name {
       type domain-name {
         length "2..max";
         pattern '[a-zA-Z0-9\-\.]+';
       }
       description
         "Тип host-name представляет полное доменное имя хоста. Размер
          имени должен быть не менее 2 символов (см. RFC 952), которыми
          могут быть буквы, цифры и символы дефиса, разделённые точками
          (см. RFC 1123 и 952).";
       reference
         "RFC  952: DoD Internet Host Table Specification
          RFC 1123: Requirements for Internet Hosts -- Application
                    and Support";
     }

     typedef host {
       type union {
         type ip-address;
         type host-name;
       }
       description
        "Тип host представляет адрес IP или доменное имя (FQDN).";
     }

     typedef uri {
       type string {
         pattern '[a-z][a-z0-9+.-]*:.*';
       }
       description
         "Тип uri представляет идентификаторы URI⁵, заданные в STD 66.

          Объекты, использующие тип uri, ДОЛЖНЫ указываться в кодировке 
          ASCII и ДОЛЖНЫ нормализоваться в соответствии с параграфами 
          6.2.1, 6.2.2.1 и 6.2.2.2 в RFC 3986. Все необязательные 
          %-представления заменяются символами, для независимых от 
          регистра символов устанавливается нижний регистр, за 
          исключением шестнадцатеричных цифр, которые нормализуются в 
          верхний регистр как указано в параграфах 6.2.2.1 RFC 3986.

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

          Объекты, использующие тип uri, могут ограничивать разрешённые
          схемы. Например, схемы data: и urn: могут не подойти.

          URI нулевого размера не являются пригодными. Они могут служить
          для указания отсутствия URI при необходимости.
          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению Uri SMIv2, определённому в RFC 5017.";
       reference
         "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
          RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
                    Group: Uniform Resource Identifiers (URIs), URLs,
                    and Uniform Resource Names (URNs): Clarifications
                    and Recommendations
          RFC 5017: MIB Textual Conventions for Uniform Resource
                    Identifiers (URIs)";
     }

     typedef email-address {
       type string {
         pattern '.+@.+';
       }
       description
         "Тип email-address представляет адреса электронной почты 
          в международном формате (internationalized).

          Формат адресов электронной почты задан правилом addr-spec
          ABNF в параграфе 3.4.1 RFC 5322. Этот формат был расширен в
          RFC 6532 для поддержки адресов на других языках. Реализации
          ДОЛЖНЫ поддерживать расшинения интернационализации RFC 6532.
          Поддержка устаревших obs-local-part, obs-domain, obs-qtext 
          из RFC 5322 не требуется.

          В доменной части могут применяться метки A и U (см RFC 5890).
          В каноническом формате доменной части используются символы
          нижнего регистра и метки U (RFC 5890), когда это применимо.";
       reference
         "RFC 5322: Internet Message Format
          RFC 5890: Internationalized Domain Names in Applications
                    (IDNA): Definitions and Document Framework
          RFC 6532: Internationalized Email Headers";
     }
   }
   <CODE ENDS>

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

В этом документе используются URI для ietf-yang-types и ietf-inet-types в реестре IETF XML Registry [RFC3688].

В соответствии с этим документом агентство IANA обновило реестр YANG Module Names с указанием данного вместо [RFC6991] для модулей ietf-yang-types и ietf-inet-types. В соответствии с форматом [RFC6020] эти представления имеют вид:

   Name:  ietf-yang-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-yang-types
   Prefix:  yang
   Reference:  RFC 9911

   Name:  ietf-inet-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-inet-types
   Prefix:  inet
   Reference:  RFC 9911

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

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

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

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

[RFC3339] Klyne, G. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

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

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/info/rfc4007>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

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

[RFC9499] Hoffman, P. and K. Fujiwara, «DNS Terminology», BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/info/rfc9499>.

[RFC9557] Sharma, U. and C. Bormann, «Date and Time on the Internet: Timestamps with Additional Information», RFC 9557, DOI 10.17487/RFC9557, April 2024, <https://www.rfc-editor.org/info/rfc9557>.

[RFC9562] Davis, K., Peabody, B., and P. Leach, «Universally Unique IDentifiers (UUIDs)», RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/info/rfc9562>.

[XPATH] Clark, J., Ed. and S. DeRose, Ed., «XML Path Language (XPath) Version 1.0», W3C Recommendation, 16 November 1999, <http://www.w3.org/TR/xpath-10>.

[XSD-TYPES] Peterson, D., Ed., Gao, S., Ed., Malhotra, A., Ed., Sperberg-McQueen, C., Ed., and H. S. Thompson, Ed., «W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes», W3C Recommendation, 5 April 2012, <https://www.w3.org/TR/xmlschema11-2/>.

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

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <https://www.rfc-editor.org/info/rfc1930>.

[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, «Classless IN-ADDR.ARPA delegation», BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <https://www.rfc-editor.org/info/rfc2579>.

[RFC2780] Bradner, S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <https://www.rfc-editor.org/info/rfc2780>.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.

[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, «Textual Conventions for Additional High Capacity Data Types», RFC 2856, DOI 10.17487/RFC2856, June 2000, <https://www.rfc-editor.org/info/rfc2856>.

[RFC3289] Baker, F., Chan, K., and A. Smith, «Management Information Base for the Differentiated Services Architecture», RFC 3289, DOI 10.17487/RFC3289, May 2002, <https://www.rfc-editor.org/info/rfc3289>.

[RFC3305] Mealling, M., Ed. and R. Denenberg, Ed., «Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations», RFC 3305, DOI 10.17487/RFC3305, August 2002, <https://www.rfc-editor.org/info/rfc3305>.

[RFC3595] Wijnen, B., «Textual Conventions for IPv6 Flow Label», RFC 3595, DOI 10.17487/RFC3595, September 2003, <https://www.rfc-editor.org/info/rfc3595>.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, «Textual Conventions for Internet Network Addresses», RFC 4001, DOI 10.17487/RFC4001, February 2005, <https://www.rfc-editor.org/info/rfc4001>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.

[RFC4502] Waldbusser, S., «Remote Network Monitoring Management Information Base Version 2», RFC 4502, DOI 10.17487/RFC4502, May 2006, <https://www.rfc-editor.org/info/rfc4502>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.

[RFC5017] McWalter, D., Ed., «MIB Textual Conventions for Uniform Resource Identifiers (URIs)», RFC 5017, DOI 10.17487/RFC5017, September 2007, <https://www.rfc-editor.org/info/rfc5017>.

[RFC5131] McWalter, D., Ed., «A MIB Textual Convention for Language Tags», RFC 5131, DOI 10.17487/RFC5131, December 2007, <https://www.rfc-editor.org/info/rfc5131>.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.

[RFC5952] Kawamura, S. and M. Kawashima, «A Recommendation for IPv6 Address Text Representation», RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.

[RFC6021] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6021, DOI 10.17487/RFC6021, October 2010, <https://www.rfc-editor.org/info/rfc6021>.

[RFC6532] Yang, A., Steele, S., and N. Freed, «Internationalized Email Headers», RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, «Stream Control Transmission Protocol», RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.

[RFC9293] Eddy, W., Ed., «Transmission Control Protocol (TCP)», STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[ISO-8601] ISO/IEC, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO/IEC 8601:2000, December 2008, <https://www.iso.org/standard/26780.html>.

[ISO-9834-1] ISO/IEC, «Information technology — Procedures for the operation of object identifier registration authorities — Part 1: General procedures and top arcs of the international object identifier tree», ISO/IEC 9834-1:2012, 2012, <https://www.iso.org/standard/58055.html>.

[IEEE-802-2024] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2024, DOI 10.1109/IEEESTD.2025.10935844, March 2025, <https://doi.org/10.1109/IEEESTD.2025.10935844>.

[Err4076] RFC Errata, Erratum ID 4076, RFC 6991, <https://www.rfc-editor.org/errata/eid4076>.

[Err5105] RFC Errata, Erratum ID 5105, RFC 6991, <https://www.rfc-editor.org/errata/eid5105>.

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

В создании исходного документа, опубликованного как [RFC6021] приняли участие: Andy Bierman, Martin Björklund, Balazs Lengyel, David Partain, Phil Shafer.

Полезные замечания к черновым вариантам этого документа представили: Andy Bierman, Martin Björklund, Benoît Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, Dan Romascanu.

Адрес автора

Jürgen Schönwälder (editor)

Constructor University

Email: jschoenwaelder@constructor.university

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

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

nmalykh@protokols.ru

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

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

3Network Configuration Protocol — протокол настройки конфигурации сети.

4Fully qualified domain name.

5Uniform Resource Identifier — унифицированный идентификатор ресурса.

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