RFC 9564 Faster Than Light Speed Protocol (FLIP)

Independent Submission                                       M. Blanchet
Request for Comments: 9564                                      Viagenie
Category: Informational                                     1 April 2024
ISSN: 2070-1721

Faster Than Light Speed Protocol (FLIP)

Протокол FLIP

PDF

Аннотация

Последние достижения в сфере искусственного интеллекта (artificial intelligence или AI), такие как большие языковые модели позволяют разработать для Internet протокол, работающий быстрее скорости света (Faster than LIght speed Protocol или FLIP). FLIP позволяет избежать перегрузок, повысить безопасность и ускорить доставку пакетов в Internet с использованием AI для предсказания будущих пакетов на приёмной стороне до их прибытия. Документ описывает протокол, его различные инкапсуляции и некоторые эксплуатационные соображения.

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

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

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

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (https://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение

Представление ChatGPT широкой публике состоялось 30 ноября 2022 г. [CHATGPT]. С тех пор большие языковые модели (large language model или LLM) используются в самых разных приложениях. Они демонстрируют мощные способности генерировать точные результаты на основе входных данных и соответствующего обучения LLM. Данная спецификация протокола использует эту способность для предсказания будущих рпкетов до их прибытия к принимающему партнёру, что позволяет достичь скорости доставки, превышающей световую, поэтому протокол получи название «Быстрее скорости света» (Faster than LIght speed Protocol или FLIP).

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

Поскольку скорость связи в дальнем космосе, к сожалению, ограничена скоростью света, а расстояния между космическими аппаратами и Землёй очень велики, возникают очень большие задержки при связи. Обеспечивая доставку быстрее скорости света (faster-than-light-speed), FLIP является ключевым дополнением для сетей IP в дальнем космосе [IP-DEEP-SPACE].

2. Подготовка партнёров по протоколу

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

Например, реализация может взять большое число файлов с собранными пакетами (Packet Capture или PCAP) от tcpdump в разных точках Internet. То, что трафик может оказаться зашифрованным, не имеет значения, поскольку хорошо обученная LLM способна предсказать зашифрованных трафик так же хорошо, как открытый.

3. Заголовок FLIP

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

+----------+---------+----------------+----------------+
|  Version | Command | Inner Protocol | Optional Data  |
+----------+---------+----------------+----------------+

Version – версия

Это поле переменного и незаданного размера содержит хэш-значение SHA-256 для модели, используемое в качестве версии, как описано в разделе 5.

Command – команда

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

Таблица .

 

Команда

Код

Документ

model

0x01

RFC 9564

data

0x02

RFC 9564

 

Inner Protocol – внутренний протокол

Поскольку заголовок FLIP является промежуточным (shim), в этом поле указывается внутренний (вложенный) протокол. Например, промежуточный заголовок FLIP может помещаться между заголовками IP и TCP, а пакет IP будет содержать код FLIP в качестве транспортного протокола. Тогда поле внутреннего протокола FLIP будет содержать код TCP, который иначе размещался бы в заголовке пакета IP.

Optional Data – необязательные данные

Некоторые команды имеют дополнительные данные, размещаемые вслед за полем Command.

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

Для подобающей сигнализации вышележащему уровню о наличии заголовка FLIP резервируется определённый код (codepoint) на уровне ниже FLIP. В разделе 7 указаны такие регистрации для IP и транспортных кодов.

4. Работа протокола

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

Команды протокола описаны ниже.

Model (codepoint 0x01) – модель

Эта команда предоставляет партнёрам возможность передать свою модель по основному каналу (in-band) протокола FLIP. Сама модель передаётся в поле Optional Data заголовка FLIP. Перед фактическими данными модели помещается заголовок MIME с подходящим типом носителя. Если типа носителя для модели не существует, его следует зарегистрировать в реестре IANA Media Type.

Data (codepoint 0x02) – данные

Эта команда говорит принимающему партнёру, что следующие за ней данные могут быть предсказаны, благодаря чему достигается производительность выше скорости света (faster-than-light-speed).

Передачу модели партнёру по основному каналу (in-band) следует выполнять редко, поскольку размер моделей может быть большим. Кроме того, такая передача фактически раскрывает модель для прослушивающего линии злоумышленника. Разработчики могут предусмотреть использование пост-квантового криптографического алгоритма, который устойчив к предсказаниям AI, т. е. постквантового криптографического алгоритма с искусственным интеллектом (post-Quantum-AI cryptographic algorithm).

5. Версия протокола

Как описано в [RFC6709], большинство протоколов должно разрабатываться с возможностью будущих улучшений, например, предоставляя способ указать новую версию протокола. В случае FLIP обученные модели всегда будут улучшаться в результате нового обучения. В качестве номера версии применяется хэш-значение SHA-256 [RFC6234] обученной модели, чтобы каждый партнёр знал используемую версию FLIP. Значение SHA-256 помещается в поле Version заголовка FLIP, как описано выше. С учётом того, что новые значения SHA-256 являются не последовательными, а полностью случайными, это предотвращает атаки с повторным использованием (replay) предсказаний будущего.

6. Продолжение работы

Этот новый протокол может революционизировать разработку протоколов Internet и пути использования Internet. Например, предполагается, что протокол можно будет использовать для потокового видео, дополненной и виртуальной реальности, пост-квантовой криптографии и т. п. Предсказывая будущие пакеты, все эти протоколы и приложения смогут получить выгоду от использования FLIP.

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

Коды для FLIP могут регистрироваться в реестрах IANA:

  • Protocol Numbers [IANA-PN]: 345, FLIP, Faster than LIght speed Protocol, RFC 9564;

  • Service Name and Transport Protocol Port Number Registry [IANA-SN]: FLIP, 68534, udp and tcp, RFC 9564

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

Способность предсказывать будущие пакеты на основе LLM может использоваться злоумышленниками, прослушивающими трафик путём его перехвата. Если у них есть доступ к той же модели, которую использует целевой партнёр, можно предсказать следующие пакеты и начать различные атаки, включая такие новые атаки, как «воспроизведение будущего» (futureplay attack). По сравнению с типичными replay-атаками в этом случае злоумышленник может предсказать будущие пакеты и заранее отправить их получателю. Хотя сейчас это может показаться неочевидным, эти новые атаки следует изучить, пока они не стали проблемой. Поэтому предлагается продолжить исследования в этом направлении.

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

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

[CHATGPT] Wikipedia, “ChatGPT”, 20 March 2024, <https://en.wikipedia.org/w/index.php?title=ChatGPT&oldid=1214732037>.

[IANA-PN] IANA, “Protocol Numbers”, <https://www.iana.org/assignments/protocol-numbers/>.

[IANA-SN] IANA, “Service Name and Transport Protocol Port Number Registry”, <https://www.iana.org/assignments/service-names-port-numbers/>.

[IP-DEEP-SPACE] Blanchet, M., Huitema, C., and D. Bogdanović, “Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions”, Work in Progress, Internet-Draft, draft-many-deepspace-ip-assessment-01, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment-01>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, “Design Considerations for Protocol Extensions”, RFC 6709, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-editor.org/info/rfc6709>.

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

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

Адрес автора

Marc Blanchet
Viagenie
Email: marc.blanchet@viagenie.ca

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

nmalykh@protokols.ru

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

RFC 9499 DNS Terminology

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 9499                                         ICANN
BCP: 219                                                     K. Fujiwara
Obsoletes: 8499                                                     JPRS
Updates: 2308                                                 March 2024
Category: Best Current Practice                                         
ISSN: 2070-1721

DNS Terminology

Терминология DNS

PDF

Аннотация

Система доменных имён (Domain Name System или DNS) определена в десятках разных RFC. Терминология, используемая при разработке и внедрении протоколов DNS, а также в работе операторов систем DNS, изменилась за десятилетия, прошедшие с момента исходного определения DNS. В этом документе приведены современные определения для многих терминов, применяемых в DNS.

Документ обновляет RFC 2308, уточняя определения терминов forwarder и QNAME. Документ отменяет RFC 8499, добавляя множество определений и уточнений. Полные списки изменённых и новых определений даны в Приложениях A и B.

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

Документ относится к категории Internet Best Current Practice.

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

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

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

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

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

1. Введение

DNS – простой протокол «запрос-отклик», где сообщения имеют общий формат для обоих направлений (в разделе 2 дано определение термина global DNS, который для многих зачастую означает то же, что и DNS). Протокол и формат сообщений заданы в [RFC1034] и [RFC1035], где определены некоторые термины. В последующих RFC определены другие термины. Некоторые из терминов, заданных в [RFC1034] и [RFC1035], сейчас имеют иное значение, нежели в 1987 г.

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

Связанные с DNS термины иногда определяют другие организации, например, рабочая группа WHATWG определила термин domain (см. https://url.spec.whatwg.org/). Консультативный комитет системы корневых серверов (Root Server System Advisory Committee или RSSAC) имеет хороший глоссарий [RSSAC026].

Большинство приведённых здесь определений представляют согласованный подход сообщества DNS – разработчиков протокола и операторов. Некоторые определения отличаются от прежних RFC и такие различия отмечены. При совпадении приведённых здесь определений с определениями прежних RFC приводится цитата из такого RFC. Если определение так или иначе изменено, прежний RFC указывается, но даётся новое определение. Список обновлённых определений представлен в Приложении A.

Важно отметить, что в процессе подготовки этого документа стало ясно, что некоторые термины, связанные с DNS, по-разному интерпретируются DNS-экспертами. Кроме того, некоторые термины из прежних DNS RFC имеют определения, которые в целом согласованы, но отличаются от исходных. Этот документ является незначительной переработкой [RFC8499], который был существенной переработкой [RFC7719].

Отметим, что нет согласованного определения DNS. Можно рассматривать DNS как некую комбинацию общепринятой схемы именования объектов в Internet, распределенной базы данных, представляющей имена и некоторые свойства этих объектов, архитектуры, обеспечивающей распределенное обслуживание, устойчивость и нестрогую когерентность распределенной базы данных и простого протокола «запрос-отклик» (как отмечено ниже), реализующего эту архитектуру. В разделе 2 даны определения терминов global DNS и private DNS, чтобы разобраться с этими разными определениями.

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

Термины byte (байт) и octet (октет) в этом документе взаимозаменяемы. Использование обоих терминов обусловлено их применением в прежних RFC, определяющих термины DNS.

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

2. Имена

Naming system – система именования

Система именования связывает имена с данными. Системы именования имеют множество важных аспектов, позволяющих отличать одну систему от другой, наиболее заметные из них включают:
  • состав имён;
  • формат имён;
  • администрирование имён;
  • типы данных, которые могут быть связаны с именами;
  • типы метаданных для имён;
  • протокол для получения данных по имени;
  • контекст для распознавания имени.
Отметим, что этот список представляет небольшое подмножество аспектов, которые были определены людьми для систем именования, и IETF ещё предстоит согласовать набор аспектов, которые хорошо подойдут для сравнения систем именования. Например, такие аспекты могут включать протокол для обновления данных по имени, приватность имён, приватность связанных с именами данных, но эти аспекты не определены так же хорошо, как перечисленные выше. Приведённый список выбран потому, что он помогает описать DNS и похожие на DNS системы именования.

Domain name – доменное имя

Упорядоченный список из одной или нескольких меток.
Отметим, что это определение независимо от DNS RFC ([RFC1034] и [RFC1035]) и применимо к отличным от DNS системам. В [RFC1034] определено пространство доменных имён (domain name space) с использованием математических деревьев и их узлов в теории графов и это определение имеет такой же практический результат, что и приведённое здесь. Любой путь в направленном ациклическом графе можно представить доменным именем, состоящим из меток узлов графа, упорядоченных по удалённости от корня (это соглашение DNS, включённое в данный документ). Доменное имя, в котором последняя метка указывает корень графа, является полным, другие имена, чьи метки формируют строгий префикс полного доменного имени, связаны с первым опущенным узлом.
В разных документах IETF и других организаций термин «доменное имя» может использоваться по-разному. Обычно в предшествующих документах этот термин означает «имена, соответствующие синтаксису [RFC1035]», возможно, с дополнительными правилами, такими как «и являются или могут быть распознаваемыми в глобальной системе DNS» или «но только с использованием формата представления».

Label – метка

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

Global DNS – глобальная система DNS

С использованием краткого набора аспектов из Naming system глобальную систему DNS можно определить, как показано ниже. Большинство правил взято из [RFC1034] и [RFC1035], но термин global DNS определяется впервые.

Composition of names – состав имён

Имя в глобальной системе DNS имеет одну или несколько меток, размер каждой из которых составляет от 0 до 63 октетов (включительно). В полном доменном имени последняя метка в упорядоченном списке имеет размер 0 октетов, это единственная метка такого размера и она называется корнем (root) или корневой меткой (root label). Размер доменного имени в глобальной системе DNS не может превышать 255 октетов в формате передачи, корень вносит в этот размер 1 октет (в Multicast DNS [RFC6762] разрешаются имена размером 255 байтов плюс 1 завершающий нулевой байт на основе иной интерпретации RFC 1035 и учёта включаемого в 255 октетов).

Format of names – формат имён

Имена в глобальной системе DNS являются доменными именами. Имеется три формата имён – формат передачи, формат представления и базовый формат отображения.

Wire format – формат передачи

Базовым форматом передачи для имён в глобальной системе DNS является список меток, упорядоченных по удалению от корня, где корневая метка является последней. Каждой метке предшествует октет её размера. В [RFC1035] задана схема сжатия, меняющая этот формат.

Presentation format – формат представления

Форматом представления имён в глобальной системе DNS является список меток, упорядоченных по удалению от корня, в кодировке ASCII с разделением меток символом точки (.). Ф формате представления полное доменное имя включает корневую метку и связанную с ней точку. Например, полное доменное имя с двумя некорневыми метками в формате представления будет иметь вид «example.tld.», а не «example.tld». В [RFC1035] определён метод показа октетов, не отображающихся в кодировке ASCII.

Common display format – базовый формат отображения

Базовый формат отображения применяется в приложениях и произвольных текстах. Он отличается от формата представления лишь необязательностью указания корневой метки и связанной с ней точки. Например, в базовом формате отображения полное доменное имя с двумя некорневыми метками обычно имеет вид «example.tld», а не «example.tld.». Имена в базовом формате отображения обычно записываются так, чтобы с учётом направления письма метки размещались в порядке снижения расстояния от корня. Например, в английском языке и языке программирования C корень или метка верхнего уровня (Top-Level Domain или TLD) размещаются справа, а в арабских языках могут размещаться слева в зависимости от местных традиций.

Administration of names – администрирование имён

Администирование задаётся путём передачи полномочий (см. определение термина delegation в разделе 7). Правила администрирования корневой зоны в глобальной системе DNS определяются операционным сообществом, организуемым в рамках Корпорации Internet по назначению имён и номеров (Internet Corporation for Assigned Names and Numbers или ICANN). Это сообщество выбирает оператора функций IANA (Functions Operator) для корневой зоны глобальной системы DNS. Серверы имён, обслуживающие корневую зону, предоставляются независимыми корневыми операторами. В других зонах глобальной системы DNS имеются свои правила администрирования.

Types of data that can be associated with names – типы данных, которые могут быть связаны с именами

С именем могут (необязательно) связаны записи о ресурсах. Имеется множество типов таких записей с уникальными структурами данных, определёнными в разных RFC и реестре IANA [IANA_Resource_Registry].

Types of metadata for names – типы метаданных для имён

Любое имя, опубликованное в DNS, представляется как набор записей о ресурсах (см. определение термина RRset в разделе 5). Некоторые имена сами по себе не имеют связанных с ними данных в глобальной системе DNS, но «присутствуют» в DNS, поскольку являются частью более длинных имён, с которыми связаны данные (см. определение термина empty non-terminals в разделе 7).

Protocol for getting data from a name – протокол для получения данных по имени

Протокол, описанный в [RFC1035].

Context for resolving a name – контекст для распознавания имени

Корневая зона глобальной системы DNS, распределенная по общедоступным техническим идентификаторам (Public Technical Identifier или PTI).

Private DNS – приватная система DNS

Имена, использующие протокол из [RFC1035], но не связанные с корневой зоной глобальной системы DNS, или недоступные всем в Internet по иным причинам. Система может использовать одновременно имена глобальной системы DNS и одной или нескольких приватных систем DNS (см., например, Split DNS в разделе 6).
Отметим, что имена, не появляющиеся в DNS и не предназначенные для поиска с использованием протокола DNS, не являются частью глобальной или приватной системы DNS, даже если они являются доменными именами.

Multicast DNS (mDNS)

«Multicast DNS (mDNS) обеспечивает возможность выполнения операций в стиле DNS на локальном канале при отсутствии какого либо обычного сервера Unicast DNS. В дополнение к этому Multicast DNS выделяет часть пространства имён DNS для свободного локального применения без необходимости внесения ежегодной платы, передачи полномочий или иной настройки традиционных серверов DNS для поиска этих имён.» (цитата из Аннотации к [RFC6762]). Несмотря на использование совместимого формата передачи, mDNS, строго говоря, является протоколом, отличным от DNS. Кроме того, в приведённой выше цитате вместо «части пространства имён DNS» уместней было бы сказать «часть пространства доменных имён». Имена mDNS не предназначены для поиска через DNS.

Locally served DNS zone – локально обслуживаемая зона DNS

Локально обслуживаемая зона DNS является частным случаем приватной системы DNS, где имена распознаются с использованием протокола DNS в локальном контексте. В [RFC6303] заданы субдомены IN-ADDR.ARPA, являющиеся зонами с локальным обслуживанием. Распознавание имён через локально обслуживаемые зоны может давать неоднозначные результаты. Например, одно и то же имя может распознаваться по-разному в разных контекстах локально обслуживаемых зон DNS. Контекст локально обслуживаемой зоны DNS может быть явным (например, как указано в [RFC6303] и [RFC7793]) или неявным (например, заданным локальным администратором DNS и неизвестным клиенту распознавания).

Fully Qualified Domain Name (FQDN) – полное доменное имя

Зачастую это просто эквивалент термина domain name of a node, указанного выше, однако такой вариант неоднозначен. Строго говоря, полное доменное имя должно включать все метки, в том числе метку корня с нулевым размером – такое имя записывается как «www.example.net.» (точка в конце). Однако все имена имеют общий корень, поэтому они часто указываются относительно этого корня (www.example.net) и все равно называются полными. Термин был введён в [RFC819]. В этом документе имена часто указываются от корня.
Необходимость термина «полное доменное имя» обусловлена существованием неполных доменных имён, где одна или несколько последних меток в списке опущены (например, www относительно example.net указывает www.example.net). Такие относительные имена понятны только с учётом контекста.

Host name – имя хоста

Этот термин и его эквивалент hostname используются широко, но не определены в [RFC1034], [RFC1035], [RFC1123], [RFC2181]. Система DNS исходно была развёрнута в среде с таблицами хостов (Host Table), как описано в [RFC952], и термин, вероятно, неформально следовал определению из этого документа, но со временем определение изменилось. Имя хоста часто указывает доменное имя, соответствующее правилам из параграфа 3.5 в [RFC1034], которые называют также предпочтительным синтаксисом имён (preferred name syntax), где каждый символ в каждой метке является буквой, цифрой или дефисом (-). Отметим, что любая метка в доменном имени может содержать любые значения октетов, а имена хостов обычно считаются доменными именами, где каждая метка следует правилам предпочтительного синтаксиса имён с поправкой на то, что метки могут начинаться с цифр ASCII (параграф 2.1 в [RFC1123]).
Термин hostname иногда используют для обозначения первой метки в FQDN, например, printer в printer.admin.example.com (иногда это формализуется в конфигурации операционных систем). Кроме того, термин иногда служит для описания любого имени, указывающего машину, и может включать метки, не соответствующие правилам предпочтительного синтаксиса имён.

Top-Level Domain (TLD) – домен верхнего уровня

Доменом верхнего уровня называют зону на 1 уровень ниже корня, такую как com или jp. С точки зрения DNS в TLD нет ничего особого. Большинство TLD являются зонами, ориентированными на передачу полномочий (определена в разделе 7), и их функционирование связано с существенными политическими вопросами. TLD часто делятся на подгруппы, такие как домены верхнего уровня с кодом страны (Country Code Top-Level Domain или ccTLD), базовые домены верхнего уровня (Generic Top-Level Domainили gTLD) и т. п. такое деление является вопросом политики и выходит за рамки этого документа.

Internationalized Domain Name (IDN) – доменное имя на национальном языке

Протокол доменов на национальных языках для приложений (Internationalized Domain Names for Applications или IDNA) обеспечивает стандартный механизм для обработки доменных имён с символами, отличными от ASCII, в приложениях DNS. На момент подготовки этого документа текущий стандарт, обычно называемый IDNA2008, определялся [RFC5890], [RFC5891], [RFC5892], [RFC5893] и [RFC5894]. В этих документах задано множество относящихся к IDN терминов, таких как LDH label, A-label, U-label. В [RFC6365] определены дополнительные термины, связанные с использованием национальных языков (часть их относится к IDN), в [RFC6055] приведено дополнительное рассмотрение IDN, включая новую терминологию.

Subdomain – субдомен

«Домен является субдоменом другого домена, если он содержится в том домене. Для проверки принадлежности достаточно убедиться, что в конце имени субдомена содержится имя домена. » (цитата из параграфа 3.1 в [RFC1034]). Например, в имени хоста nnn.mmm.example.com компоненты mmm.example.com и nnn.mmm.example.com являются субдоменами домена example.com. Отметим, что при сравнении учитываются метки целиком, т. е. ooo.example.com не будет субдоменом oo.example.com.

Alias – псевдоним

Владелец записи о ресурсе CNAME или субдомен владельца записи о ресурсе DNAME (определена в [RFC6672]). См. также canonical name.

Canonical name – каноническое имя

Запись о ресурсе CNAME «идентифицирует имя своего владельца в качестве псевдонима и задаёт соответствующее каноническое имя в разделе RDATA записи RR» (цитата из параграфа 3.6.2 в [RFC1034]). Такое использование термина «канонический» связано с математической концепцией канонической формы.

CNAME

«По традиции [владельца] метку[и] записи CNAME называют просто «CNAME». Это неудачная традиция, поскольку CNAME является сокращением «canonical name», а [владелец] метку[и] записи CNAME чаще всего не является каноническим именем» (цитата из параграфа 10.1.1 в [RFC2181] с заменой метки на владельца метки).

3. Коды откликов DNS

Некоторые коды откликов (response code или RCODE), заданные в [RFC1035], получили свои сокращённые имена. Все RCODE перечислены в реестре [IANA_Resource_Registry], где строчные и прописные буквы смешаны, хотя в большинстве документов применяются только заглавные буквы. В этом разделе описаны некоторые распространённые имена, заданные в [RFC1035], а также включён новый код и его описание. Полный список RCODE приведён в реестре IANA.

NOERROR

Этот код описан как отсутствие ошибок (No error condition) в параграфе 4.1.1 [RFC1035].

FORMERR

Этот код описан как ошибка формата, не позволяющая серверу интерпретировать запрос (Format error – The name server was unable to interpret the query), в параграфе 4.1.1 [RFC1035].

SERVFAIL

Этот код описан как отказ сервера, связанный с его неспособностью обработать запрос из-за своих проблем (Server failure – The name server was unable to process this query due to a problem with the name server), в параграфе 4.1.1 [RFC1035].

NXDOMAIN

Этот код описан как ошибка имени, связанная с отсутствием на сервере указанного в запросе имени (Name Error […] this code signifies that the domain name referenced in the query does not exist), в параграфе 4.1.1 [RFC1035]. В [RFC2308] код NXDOMAIN указан как синоним Name Error.

NOTIMP

Этот код описан как отсутствие поддержки сервером имён запрошенной функции (Not Implemented – The name server does not support the requested kind of query) в параграфе 4.1.1 [RFC1035].

REFUSED

Этот код описан как отклонение запроса в соответствии с правилами сервера, например, нежеланием предоставлять сведения конкретному запрашивающему или выполнять определённую информацию, такую как перенос зоны, для конкретных данных (Refused – The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data) в параграфе 4.1.1 [RFC1035].

NODATA

«Псевдо-RCODE, указывающий, что имя корректно для данного класса, но записей этого типа нет. Код NODATA выводится из ответа» (цитата из раздела 1 в [RFC2308]). «NODATA указывается ответом с RCODE = NOERROR и отсутствием имеющей отношение к делу информации в разделе ответов. Раздел полномочий будет содержать запись SOA или в нем совсем не будет записей NS» (цитата из параграфа 2.2 в [RFC2308]). Отметим, что рекомендации (referral) имеют формат, похожий на NODATA, и в [RFC2308] указано, как различать их.
Термин NXRRSET иногда применяется как синоним NODATA, однако это является ошибкой, поскольку для NXRRSET задан конкретный код ошибки [RFC2136].

Negative response – негативный отклик

Отклик, заказывающий, что конкретного набора RRset не существует, или RCODE для него говорит, что сервер не может ответить. Типы негативных откликов подробно рассмотрены в разделах 2 и 7 [RFC2308].

4. Транзакции DNS

Заголовком сообщения DNS являются первые 12 октетов. Многие поля и флаги на рисунках в параграфах 4.1.1 – 4.1.3 [RFC1035] указываются их именами. Например, коды откликов указаны как RCODE, данные записей – как RDATA, а бит полномочности ответа – как флаг (бит) AA.

Class – класс

Класс указывает «семейство протоколов или экземпляр протокола» (цитата из параграфа 3.6 в [RFC1034]). «DNS помечает все данные тегом класса и типа, что позволяет параллельно использовать разные форматы для данных типа адрес.» (цитата из параграфа 2.2 в [RFC1034]). На практике почти в каждом запросе используется класс IN (Internet). Имеется несколько запросов для класса CH (Chaos), но они обычно служат для получения сведений о самом сервере, а не для получения другого типа адреса.

QNAME

Наиболее распространённым является грубое определение QNAME как поля в разделе запроса Question. «Стандартный запрос задает искомое доменное имя (QNAME), тип (QTYPE) и класс (QCLASS) запроса, а также запрашивает соответствующие записи RR.» (цитата из параграфа 3.7.1 в [RFC1034]). Строго говоря, определение взято из параграфа 4.1.2 в [RFC1035], где QNAME определяется применительно к разделу Question. Это определение, по-видимому, применяется согласованно, поскольку при обсуждении реверсных запросов в параграфе 6.4.1 [RFC1035] указывается «имя владельца RR запроса и значение TTL», так как при реверсных запросах заполняется поле Answer, а раздел Question остаётся пустым (реверсные запросы отменены в [RFC3425], поэтому в данном документе нет соответствующих определений).
В [RFC2308] имеется альтернативное определение, помещающее QNAME в ответ (или последовательность ответов) вместо запроса. QNAME определяется как «Имя в запросном разделе (query section) ответа или место, где оно преобразуется в CNAME или цепочку CNAME, поле данных последней записи CNAME. Последней CNAME в данном случае считается запись, содержащая значение, которое не преобразуется в другую запись CNAME». В этом определении есть некая внутренняя логика, обусловленная определением и способом подстановки CNAME. Если сервер имён не находит набора RRset, соответствующего запросу, но находит то же имя в неком классе с записью CNAME, он «включает запись CNAME в отклик и повторяет запрос для доменного имени, заданного в поле данных записи CNAME» (цитата из параграфа 3.6.2 в [RFC1034]). Это явно указано в алгоритме распознавания, описанном в параграфе 4.3.2 [RFC1034]: «QNAME меняется на каноническое имя в CNAME RR и выполняется возврат к п 1». Поскольку запись CNAME явно говорит, что имя владельца является каноническим именем того, что содержится в RDATA, можно рассматривать новое имя (имя, которое было в RDATA записи CNAME RR) как QNAME. Однако это создаёт путаницу, поскольку отклик на запрос, который ведёт к обработке CNAME, содержит в отражённом разделе Question два значения QNAME – имя в исходном запросе и содержимое поля данных в последнем CNAME. Путаница возникает из-за итерационного (рекурсивного) режима распознавания, возвращающего в результате отклик, который не обязательно имеет то же имя владельца, что и QNAME в исходном запросе.
Для предотвращения возможной путаницы полезно различать три указанных ниже значения.

QNAME (исходное)

Имя, фактически переданное в разделе Question исходного запроса, которое всегда отражается (echo) в разделе Question (финального) отклика, когда установлено значение 1 для бита QR.

QNAME (эффективное)

Фактически распознанное имя, которое является исходно запрошенным или полученным в цепочке откликов CNAME.

QNAME (финальное)

Фактически распознанное имя, которое является исходно запрошенным или последним именем в цепочке откликов CNAME.
Поскольку определение в [RFC2308] относится фактически не к тому понятию, которое было принято в [RFC1034], лучше было бы использовать в [RFC2308] другое имя для этого понятия. В современной практике QNAME почти всегда означает то, что выше отмечено как QNAME (исходное).

Referrals – рекомендации (перенаправление)

Тип отклика, в котором сервер, сообщая о своей полной неполномочности для отклика, указывает запрашивающему распознавателю другое место для отправки запроса. Рекомендации могут быть частичными.
Рекомендации возникают, когда сервер не выполняет рекурсивное обслуживание при ответе на запрос. Это показано на этапе 3(b) алгоритма [RFC1034] (параграф 4.3.2).
Имеется два типа перенаправления. Первый указывает перенаправление вниз (downward referral, иногда описывается как отклик делегирования – delegation response), когда сервер полномочен для некоторой части QNAME. Раздел Authority в RDATA набора RRset содержит серверы имён, указанные на срезе зоны referred-to. При обычной работе DNS этот тип откликов нужен для поиска имён ниже передачи полномочий. Использование термина referral без дополнительных атрибутов означает именно этот вариант и многие считают его единственным допустимым типом перенаправления в DNS. Второй вариант перенаправляет вверх (upward referral, иногда описывается как перенаправление к корню – root referral), когда у сервера совсем нет полномочий для QNAME. В этом случае зоной referred-to в разделе Authority обычно является корневая зона (.). При нормальной работе DNS этот тип откликов не требуется для распознавания и корректного ответа на любой запрос. От серверов не требуется передавать перенаправление вверх и некоторые считают такое перенаправление признаком ошибочной настройки или ошибки. Для перенаправления вверх всегда требуется то или иное уточнение (например, upward или root) и оно никогда не указывается просто словом referral.
Отклик, содержащий лишь рекомендации, имеет пустой раздел Answer и содержит NS RRset для зоны referred-to в разделе Authority. Отклик может содержать RR, указывающие адреса, в разделе Additional. Бит AA сброшен.
В случае, когда запрос соответствует псевдониму (alias) и сервер не полномочен для цели этого псевдонима, но имеет полномочия для некого имени выше этой цели, алгоритм распознавания будет создавать отклик, который содержит полномочный ответ для псевдонима и перенаправление. Такой отклик с частичным ответом и перенаправлением содержит данные в разделе Answer, а в разделе Authority содержится NS RRset для зоны referred-to. Отклик может содержать RR, указывающие адреса, в разделе Additional. Бит AA установлен, поскольку первое имя в разделе Answer соответствует QNAME и сервер полномочен для ответа (см. параграф 4.1.1 в [RFC1035]).

5. Записи о ресурсах

RR

Сокращение для записи о ресурсах (resource record), см. параграф 3.6 в [RFC1034].

RRset

Набор записей о ресурсах «с совпадающими метками, типом и классом, но различными данными» (согласно разделу 5 в [RFC2181]). Иногда применяется обозначение RRSet. «Одна метка» в этом определении означает «одно имя владельца». Кроме того, в [RFC2181] сказано: «все значения TTL для записей RR в наборе RRSet должны быть одинаковы». Отметим, что записи RRSIG не соответствуют этому определению. В [RFC4035] сказано:
Процесс создания RRSIG RR для данного набора RRset описан в [RFC4034]. Набор RRset может включать множество связанных с ним записей RRSIG. Отметим, что по причине тесной связи записей RRSIG RR с наборами RRset, чьи сигнатуры эти записи содержат, записи RRSIG RR, в отличие от других типов DNS RR, не формируют наборов RRset. В частности, значения TTL для записей RRSIG RR с общим именем владельца, не следуют правилам для RRset, описанным в [RFC2181].

Master file – первичный файл

«Первичные файлы являются текстовыми и содержат записи RR в виде текста. Поскольку содержимое зоны может быть выражено в форме списка RR, первичные файлы используются в основном для определения зон, хотя их можно применять и для списков содержимого кэша» (цитата из раздела 5 в [RFC1035]). Первичные файлы иногда называют файлами зоны (zone file).

Presentation format – формат представления

Текстовый формат, используемый в первичных файлах. Этот формат показан, но не определён формально в [RFC1034] и [RFC1035]. Термин presentation format впервые использован в [RFC4034].

EDNS

Механизмы расширения для DNS, определённые в [RFC6891]. Иногда применяются обозначения EDNS0 и EDNS(0) для указания номера версии. EDNS позволяет клиентам и серверам DNS задавать размер сообщений больше заданных исходно 512 октетов, расширять пространство кодов откликов и передавать дополнительные опции, влияющие на обработку запросов DNS.

OPT

Псевдо-RR (иногда называется meta-RR), используемая для управляющей информации, относящейся к последовательности запросов и откликов конкретной транзакции (перефразированное определение из параграфа 6.1.1 в [RFC6891]). Применяется в EDNS.

Owner – владелец

«Имя домена, где найдена RR» (цитата из параграфа 3.6 в [RFC1034]). Зачастую применяется термин owner name.

SOA field names – имена полей SOA

В документах DNS, включая приведённые здесь определения, поля в RDATA записи о ресурсах SOA указываются по именам. SOA является сокращением от начала зоны полномочий (start of a zone of authority). Эти поля определены в параграфе 3.3.13 [RFC1035]. Имена полей (в порядке их указания в SOA RDATA) – MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, MINIMUM. Отметим, что назначение поля MINIMUM обновлено в разделе 4 [RFC2308] и новое определение говорит, что поле MINIMUM – это только «TTL для негативных откликов». В этом документе как правило используются имена полей, а не описывающие поля термины.

TTL

Максимальный срок действия (time to live) записи о ресурсе. «Поле TTL представляет собой целое число без знака с минимальным значением 0 и максимальным 2147483647 (т. е., 231 – 1). При передаче это значение следует помещать в младшие биты (31) 32-битового поля TTL, устанавливая для старшего бита (знак) нулевое значение.» (цитата из раздела 8 в [RFC2181]). Отметим, что в [RFC1035] ошибочно указано, что это целое число со знаком. Ошибка исправлена в [RFC2181].
TTL «задаёт временной интервал, в течение которого запись может кэшироваться прежде, чем снова возникнет необходимость обращения к источнику данных» (цитата из параграфа 3.2.1 в [RFC1035]). В параграфе 4.1.3 [RFC1035] сказано: «временной интервал (в секундах), в течение которого запись может кэшироваться до ее отбрасывания». Несмотря на определение для записи о ресурсе, значение TTL в каждой записи RRset должно быть одинаковым ([RFC2181], параграф 5.2).
Причина того, что TTL указывает максимальный срок действия, заключается в том, что оператор может сократить срок действия в оперативных целях, например при наличии запрета TTL больше определённого значения. Известно, что некоторые серверы игнорируют TTL в некоторых RRset (например, когда для полномочных данных установлен очень короткий срок действия), хотя это противоречит рекомендациям [RFC1035]. RRset может удаляться из кэша до завершения интервала TTL, при этом значение TTL становится неизвестным, поскольку RRset, с которым оно связано, больше не существует.
Существует также концепция принятого по умолчанию срока действия (default TTL) для зоны, который может быть параметром конфигурации программы сервера. Часто это выражается принятым по умолчанию значением для всего сервера и для зоны с помощью директивы $TTL в файле зоны. Директива $TTL была добавлена в формат первичного файла документом [RFC2308].

Class independent – независимый от класса

Тип записи о ресурсе, синтаксис и сементика которого одинаковы для каждого класса DNS. Тип записи о ресурсе, не являющийся независимым от класса, имеет разную трактовку в зависимости от класса DNS, к которому относится запись, если трактовка не определена для некоторых классов. Большинство типов записей о ресурсах определено для класса 1 (IN, Internet), но многие записи не определены для других классов.

Address records – адресные записи

Записи типа A или AAAA. В [RFC2181] они неформально определены как «(A, AAAA и т. п.)». Отметим, что в будущем могут быть определены новые типы адресных записей.

6. Серверы и клиенты DNS

В этом разделе даны определения терминов, используемых для систем, являющихся клиентами и/или серверами DNS. В прошлых RFC серверы DNS иногда назывались серверами имён (name server, nameserver) или просто серверами. Формального определения сервера DNS не существует, но в RFC обычно предполагается, что это сервер Internet, прослушивающий запросы и отправляющий отклики с использованием протокола DNS, заданного в [RFC1035] и его преемниках.

Важно отметить, что термины сервер DNS и сервер имён требуют контекста для понимания предоставляемых услуг. Как полномочные (authoritative) серверы, так и рекурсивные распознаватели (recursive resolver) часто называют серверами DNS и серверами имён, хотя их функции различаются (те и другие могут быть частями одного программного пакета).

Термины, относящиеся к системе глобальных корневых серверов DNS, приведены в [RSSAC026], где определены такие термины как root server (корневой сервер), root server operator (оператор корневого сервера), а также термины, связанные со способами обслуживания корневой зоны глобальной системы DNS.

Resolver – распознаватель

«Программа, извлекающая из серверов имен информацию в ответ на запрос клиента» (цитата из параграфа 2.4 в [RFC1034]). Распознаватель выполняет запросы по имени, типу и классу, получая отклики. Логическая функция называется распознаванием (resolution). На практике термин обычно обозначает тот или иной тип распознавателя (некоторые типы определены ниже) и трактовка термина зависит от понимания контекста.
Связанным термином является resolve, для которого нет формального определения в [RFC1034] и [RFC1035]. Вмененное определение может иметь вид: «задание вопроса, состоящего из доменного имени, класса и типа и получение какого-то ответа». Вмененным определением для распознавания (resolution) может быть: «ответ, полученный от распознавания».

Stub resolver – распознаватель-заглушка

Распознаватель, не способный самостоятельно выполнить распознавание. Заглушки обычно зависят от рекурсивного распознавателя, который принимает на себя функцию фактического распознавания. Распознаватели-заглушки обсуждаются в параграфе 5.3.1 [RFC1034], но не определены там формально. Полное определение дано в параграфе 6.1.3.1 [RFC1123].

Iterative mode – итерационный режим

Режим распознавания, при котором получающий запросы сервер DNS отвечает ссылкой (рекомендацией — referral) на другой сервер. В параграфе 2.3 [RFC1034] это описано так: «сервер указывает клиенту другой сервер, который способен ответить на запрос клиента». Распознаватель, работающий в итерационном режиме иногда называют итерационным распознавателем (iterative resolver). См. также определение термина iterative resolution ниже.

Recursive mode – рекурсивный режим

Режим распознавания, при котором получающий запросы сервер DNS отвечает на них с использованием локального кэша или передаёт запросы другим серверам для получения окончательных ответов на них. В параграфе 2.3 [RFC1034] это описано так: «когда первый сервер транслирует (передаёт) запрос клиента другому серверу». В параграфе 4.3.1 [RFC1034] сказано: «в этом [рекурсивном] режиме сервер имён выполняет функции распознавателя имён и всегда возвращает ответ или сообщение об ошибке, но не ссылку на другой сервер». В этом же параграфе сказано:
Рекурсивный режим возникает в тех случаях, когда запрос с установленным флагом RD поступает на сервер, который желает обеспечивать рекурсивный сервис; клиент может убедиться в использовании рекурсивного режима, проверяя наличие в отклике обоих флагов RA и RD.
Работающий в рекурсивном режиме сервер можно рассматривать как комбинацию сервера имён (отвечает на запросы) и распознавателя (выполняет функцию распознавания). Работающие в таком режиме системы обычно называют рекурсивными серверами (recursive server), а иногда – рекурсивными распознавателями (recursive resolver). Эти термины могут применяться как взаимозаменяемые. На практике нет возможности узнать заранее, будет ли запрашиваемый сервер выполнять рекурсию.

Recursive resolver – рекурсивный распознаватель

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

Recursive query – рекурсивный запрос

Запрос с установленным (1) битом желательности рекурсии (Recursion Desired или RD) в заголовке (см. параграф 4.1.1 в [RFC1035]). Если рекурсивный сервис доступен и в запросе установлен бит RD, сервер использует свой распознаватель для ответа на запрос (см. параграф 4.3.2 в [RFC1034].)

Non-recursive query – нерекурсивный запрос

Запрос со сброшенным (0) битом RD в заголовке. Сервер может отвечать на такой запрос только локальными сведениями или возвращать ссылку на другой сервер, который «ближе» к ответу (см. параграф 4.3.1 в [RFC1034]).

Iterative resolution – итерационное распознавание

Сервер имён может получить запрос, на который способен ответить только другой сервер. Для решения этой проблемы имеется два подхода – рекурсивный, когда первый сервер выполняет от имени клиента запрос к другому серверу, и итерационный, когда сервер указывает клиенту другой сервер для передачи запроса тому (см. параграф 2.3 в [RFC1034]). При итерационном распознавании клиент повторяет нерекурсивные запросы и следует за перенаправлениями и/или псевдонимами (alias). Алгоритм итерационного распознавания описан в параграфе 5.3.3 [RFC1034].

Full resolver – полный распознаватель

Этот термин применяется в [RFC1035], но не определён там. В RFC 1123 определён полнофункциональный распознаватель (full-service resolver), который может совпадать или не совпадать с тем, что подразумевалось по full resolver в [RFC1035]. Это термин не определён должным образом ни в одном RFC и нет единого мнения о его трактовке. Использовать термин без надлежащего контекста не рекомендуется.

Full-service resolver

В параграфе 6.1.3.1 [RFC1123] этот термин определён как распознаватель, работающий в рекурсивном режиме с кэшированием (и соответствующий другим требованиям).

Priming – подготовка

«Поиск списка корневых серверов по конфигурации, где указаны все или некоторые предполагаемые адреса IP корневых серверов» (цитата из раздела 2 в [RFC8109]). Для работы в рекурсивном режиме распознавателю нужно знать адрес хотя бы одного корневого сервера. Подготовка зачастую выполняется по конфигурации, содержащей список полномочных серверов корневой зоны.

Root hints – подсказки корневых серверов

«Операторам рекурсивных распознавателей DNS обычно нужно настроить «файл подсказки корневых серверов» (root hints file). Этот файл содержит имена и адреса IP полномочных серверов имён корневой зоны, чтобы программы могли запускать процесс распознавания DNS. Во многих программах этот список является встроенным» (цитата из [IANA_RootFiles]). Файл подсказок часто используется при подготовке.

Negative caching – негативное кэширование

«Хранение информации о том, что чего-либо не существует, ответ не может быть получен или его не дают» (цитата из раздела 1 в [RFC2308]).

Authoritative server – полномочный сервер

«Сервер, знающий содержимое зоны DNS из локальных сведений и способный, тем самым, отвечать на запросы для зоны без необходимости обращения к другим серверам» (цитата из раздела 2 в [RFC2182]). Полномочный сервер указан в записи NS (name server) для зоны. Это система, отвечающая на запросы DNS сведениями о зонах, для которых она была настроена на отклик, с установленным (1) в заголовке отклика флагом AA. Это сервер, имеющий полномочия для одной или нескольких зон DNS. Отметим, что полномочный сервер может отвечать на запросы без передачи ему полномочий родительской зоны. Полномочные серверы также предоставляют рекомендации (referral), обычно для дочерних зон, получивших полномочия от них. В этих рекомендациях бит AA сброшен (0) и содержатся данные перенаправления в разделе Authority, а при необходимости и в разделах Additional.

Authoritative-only server – сервер, выполняющий только функции полномочного (без рекурсии)

Сервер, обслуживающий лишь полномочные данные и игнорирующий запросы на рекурсию. Обычно он «не генерирует запросов сам. Сервер отвечает на нерекурсивные запросы от итерационных распознавателей, ищущих информацию в обслуживаемых им зонах» (цитата из параграфа 2.4 в [RFC4697]). В этом случае игнорирование запросов на рекурсию означает ответ на них откликами, указывающими, что рекурсия не выполняется.

Zone transfer – перенос зоны

Действие, при котором клиент запрашивает копию зоны, а полномочный сервер передаёт требуемые сведения (описание зон приведено в разделе 7). Имеется два базовых стандартных способа переноса зон – AXFR (Authoritative Transfer) для копирования всей зоны [RFC5936] и IXFR (“Incremental Transfer”) для копирования лишь изменившихся частей зоны [RFC1995]. Во многих системах применяются нестандартные методы переноса зон, выходящие за рамки протокола DNS.

Slave server – ведомый сервер

См. Secondary server.

Secondary server – вторичный сервер

«Полномочный сервер, который использует перенос зоны для ее получения» (цитата из параграфа 2.1 в [RFC1996]). Вторичные серверы обсуждаются также в [RFC1034], а в [RFC2182] они описаны более подробно. Хотя в ранних DNS RFC, таких как [RFC1996], использовался термин «ведомый» (slave), сейчас принято называть такие серверы вторичными (secondary).

Master server – ведущий сервер

См. Primary server.

Primary server – первичный сервер

«Любой полномочный сервер, настроенный на то, чтобы играть роль источника при переносе зоны для одного или нескольких [вторичных] серверов» (цитата из параграфа 2.1 в [RFC1996]). Более конкретно в [RFC2136] указано, что это: «полномочный сервер, настроенный как источник данных AXFR или IXFR для одного или нескольких [вторичных] серверов». Первичные серверы обсуждаются также в [RFC1034]. Хотя в ранних DNS RFC, таких как [RFC1996], использовался термин «ведущий» (master), сейчас принято называть такие серверы первичными (primary).

Primary master – первичный ведущий

«Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR» (цитата из параграфа 2.1 в [RFC1996]). В [RFC2136] термин primary master определён как: «Ведущий сервер в корне графа зависимостей AXFR/IXFR. Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR. По определению имеется лишь один первичный ведущий сервер на зону».
Идея первичного ведущего сервера используется лишь в [RFC1996] и [RFC2136]. В современной интерпретации primary master – это сервер, который является полномочным для зоны и получает обновления зоны из конфигурации (например, первичного файла) или транзакций UPDATE.

Stealth server – скрытый сервер

«Похож на ведомый сервер, но не указывается в NS RR для данной зоны» (цитата из параграфа 2.1 в [RFC1996]).

Hidden master – скрытый ведущий

Скрытый сервер, который является первичным для переноса зон. «При такой схеме ведущий сервер имён, обрабатывающий обновления, недоступен для хостов общего назначения в Internet, он не указывается в NS RRset» (цитата из параграфа 3.4.3 в [RFC6781]). В [RFC4641] сказано, что имя скрытого ведущего «присутствует в поле MNAME записей SOA RR», однако это имя вообще не присутствует в некоторых серверах глобальной системы DNS. Скрытый ведущий может быть также вторичным сервером для самой зоны.

Forwarding – пересылка

Процесс передачи сервером запроса DNS с установленным (1) битом RD другому серверу для распознавания. Пересылка является функцией распознавателя DNS и отличается от простой ретрансляции запросов вслепую.
В [RFC5625] не дано конкретного определения пересылки, но подробно описаны функции которые должна поддерживать система, выполняющая пересылку. Системы с пересылкой иногда называют DNS-прокси, но этот термин ещё не определён (даже в [RFC5625]).

Forwarder – пересылающий сервер

В разделе 1 [RFC2308] пересылающий сервер описан как «Сервер имён, используемый для распознавания (resolve) запросов взамен прямого использования цепочки полномочных серверов имён». Кроме того, в [RFC2308] сказано: «Обычно пересылающий сервер имеет более качественный доступ в Internet или поддерживает кэш большего размера, совместно используемый множеством распознавателей имён». Из этого определения следует, что пересылающие серверы обычно обращаются в запросами лишь к полномочным серверам. Однако в настоящее время пересылающие серверы часто занимают промежуточное место между распознавателями-заглушками (stub) и рекурсивными серверами. В [RFC2308] не сказано, является ли пересылающий сервер только итерационным или полнофункциональным распознавателем.

Policy-implementing resolver – реализующий правила распознаватель

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

Open resolver – открытый распознаватель

Полнофункциональный распознаватель, воспринимающий и обрабатывающий запросы от любых (или почтчи любых) клиентов. Их иногда называют общедоступными (public), хотя термин public resolver чаще применяется к распознавателям, которые предусмотрены как общедоступные, в отличие от распознавателей, которые открыты из-за ошибок в настройке. Открытые распознаватели обсуждаются в [RFC5358].

Split DNS – расщепление DNS

Термины split DNS и split-horizon DNS уже давно применяются в сообществе DNS без формального определения. Обычно они относятся к случаям, когда серверы DNS, полномочные для определённого набора доменов, дают разные ответы для этих доменов в зависимости от источника запроса. Результатом этого является то, что доменное имя, которое условно является уникальным в глобальном масштабе, имеет разный смысл для разных пользователей сети. Иногда это может быть результатом настройки представлений (view), описанных ниже.
В параграфе 3.8 [RFC2775] приведено связанное определение, которое слишком специфично, чтобы быть полезным в общем случае.

View – представление

Конфигурация сервера DNS, позволяющая ему предоставлять разные отклики в зависимости от атрибутов запроса, например для расщепления DNS. Обычно представления различаются по IP-адресу источника запроса, но могут различаться и по IP-адресу назначения, типу запроса (например, AXFR), его рекурсивности и т. п. Представления часто применяются для предоставления во «внутреннюю» защищённую сеть большего числа имён, чем во «внешнюю» незащищённую. Представления не являются стандартизованной частью DNS, но реализованы во многих серверных программах.

Passive DNS – пассивная система DNS

Механизм сбора данных DNS за счёт сохранения откликов DNS от серверов имён. Некоторые из таких систем собирают также связанные с откликами запросы DNS, хотя при этом возникают некоторые проблемы приватности. Базы данных пассивных систем DNS могут использоваться для ответов на исторические запросы о зонах DNS, например, о значениях, присутствовавших в прошлом, или времени появления имени. Базы данных пассивных DNS позволяют искать хранящиеся записи по ключам, отличающимся от имени и типа, например, «найти все имена, в которых есть запись A с определённым значением».

Anycast

«Технология, позволяющая сделать определённый адрес службы (Service Address) доступным во множестве дискретных, автономных пунктов, чтобы дейтаграмма, отправленная по anycast-адресу, маршрутизировалась в одно из доступных мест» (цитата из раздела 2 в [RFC4786]). В [RFC4786] приведено более подробное объяснение для Anycast и других терминов, связанный с таким использованием.

Instance – экземпляр

«При использовании anycast-маршрутизации, позволяющей нескольким серверам иметь один адрес IP, каждый из этих серверов принято называть экземпляром». Далее в [RSSAC026] сказано: «Экземпляр сервера, например, корневого, часто называют Anycast-экземпляром».

Privacy-enabling DNS server – сервер DNS с поддержкой приватности

«Сервер DNS, реализующий DNS на основе TLS [RFC7858], который может также поддерживать DNS на основе DTLS [RFC8094]» (цитата из раздела 2 в [RFC8310]). Поддержка приватности может обеспечиваться и другими типами серверов DNS, такими как DNS-over-HTTPS [RFC8484] и DNS-over-QUIC [RFC9250].

DNS-over-TLS (DoT) – DNS на основе TLS

DNS по протоколу TLS, как определено в [RFC7858] и преемниках.

DNS-over-HTTPS (DoH) – DNS на основе HTTPS

DNS по протоколу HTTPS, как определено в DNS [RFC8484] и преемниках.

DNS-over-QUIC (DoQ) – DNS на основе QUIC

DNS по протоколу QUIC, как определено в [RFC9250] и преемниках. В [RFC9250] DoQ определён как транспорт общего назначения для DNS, который может применяться между распознавателями-заглушками (stub) и рекурсивными серверами, между рекурсивными и полномочными серверами, а также для переноса зон.

Classic DNS – классический протокол DNS

DNS по протоколу UDP или TCP, как определено в [RFC1035] и преемниках. Classic DNS применяется при взаимодействии DNS между распознавателями-заглушками и рекурсивными распознавателями, а также между рекурсивными распознавателями и полномочными серверами. Протокол иногда называют Do53. Шифрование в классическом DNS не применяется.

Recursive DoT (RdoT) – рекурсивный DNS на основе TLS

RDoT – это транспорт DNS-over-TLS для между распознавателем-заглушкой и рекурсивным распознавателем или парой рекурсивных распознавателей. Этот термин нужен, поскольку предполагается в будущем применение DNS-over-TLS в качестве транспорта между рекурсивными распознавателями и полномочными серверами.

Authoritative DoT (ADoT) – полномочный DoT

Если DNS-over-TLS в будущем станет транспортом между рекурсивными распознавателями и полномочными серверами, ADoT будет обозначать такой транспорт.

XFR-over-TLS (XoT)

Перенос зоны DNS по протоколу TLS, как задано в [RFC9103]. Этот термин применим как для AXFR over TLS (AxoT), так и для IXFR over TLS (IXoT).

7. Зоны

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

Zone – зона

«Полномочная информация организуется в блоки, называемые зонами (ZONE) и эти зоны могут автоматически распространяться серверам имён, которые являются резервными для данных зон» (цитата из параграфа 2.4 в [RFC1034]).

Child – потомок

«Сущность (объект) в записи, которой переданы полномочия для домена от родителя (Parent)» (цитата из параграфа 1.1 в [RFC7344]).

Parent – родитель

«Домен, в котором зарегистрирован потомок (Child)» (цитата из параграфа 1.1 в [RFC7344]). Ранее в [RFC0882] был определён термин parent name server (родительский сервер имён) как «сервер имён, имеющий полномочия для пространства имён, которое будет содержать новый домен» (отметим, что [RFC0882] был отменён [RFC1034] и [RFC1035]). В [RFC819] описаны некоторые взаимоотношения между родителями и потомками.

Origin – начало (источник)

Имеется два вариант использования этого термина.
  1. «Доменное имя, появляющееся наверху зоны (сразу под срезом, отделяющим зону от её родителя)… Имя зоны совпадает с именем домена в источнике зоны» (цитата из раздела 6 в [RFC2181]. В настоящее время термины origin и apex (вершина, см. ниже) часто применяются как взаимозаменяемые.
  2. Доменное имя, в рамках которого данное относительное доменное имя появляется в файлах зоны. Обычно рассматривается в контексте $ORIGIN – элемента управления, определённого в параграфе 5.1 [RFC1035] как часть формата первичного файла. Например, если $ORIGIN имеет значение example.org., строка первичного файла для www фактически является записью для www.example.org..

Apex – вершина

Точка в дереве, где размещается владелец SOA и соответствующего полномочного NS RRset. Эта точка называется также вершиной зоны (zone apex). В [RFC4033] вершина определена как «имя на дочерней стороне среза зоны». Понятие вершины может быть полезно в теоретико-информационном описании структуры дерева, а понятие начала (origin) – как название той же концепции при реализации в файлах зоны. Однако это различие не всегда сохраняется на практике и можно найти примеры использования, противоречащие данному определению. В [RFC1034] используется термин «верхний узел зоны» в качестве синонима вершины, но этот термин не получил широкого распространения. В наши дни первое значение термина origin (см. выше) и термин apex часто используются как взаимозаменяемые.

Zone cut – срез зоны

Точка разграничения зон, где начало одной зоны является потомком другой. «Зоны ограничены «срезами». Каждый срез отделяет «дочернюю» зону (ниже среза) от «родительской» (выше среза)» (цитата из раздела 6 в [RFC2181], хотя это определение достаточно поверхностно). В параграфе 4.2 [RFC1034] вместо термина «срез зоны» используется просто срез (cut).

Delegation – передача полномочий (делегирование)

Процесс, в котором под вершиной данной зоны в пространстве имён создаётся отдельная зона. Передача полномочий происходит при добавлении в родительскую зону NS RRset для начала (origin) дочерней зоны. Делегирование всегда выполняется на срезе зоны. Термин часто является существительным3 – новая зона создаётся актом передачи полномочий.

Authoritative data – полномочные данные

«Все записи RR, связанные со всеми узлами от вершины зоны до узлов ветвей или узлов над срезами на нижнем краю зоны» (цитата из параграфа 4.2.1 в [RFC1034]). Отметим, что это определение может приводить к непреднамеренному включению любых присутствующих в зоне записей NS, которые на деле не являются полномочными, поскольку идентичные NS RR имеются ниже среза зоны. В этом проявляется неоднозначность понятия полномочных данных, поскольку записи NS на родительской стороне полномочно указывают делегирование, хотя сами не являются полномочными.
В разделе 2 [RFC4033] даётся определение Authoritative RRset, которое связано с полномочными данными, но более точно.

Lame delegation – неудачное делегирование

«Неудачное делегирование имеет место, когда серверу имён переданы полномочия предоставлять службу имён для зоны (через записи NS), но тот не обслуживает имена для этой зоны (обычно из-за того, что он не настроен как первичный или вторичный сервер этой зоны). (цитата из параграфа 2.8 в [RFC1912]). Согласно другому определению, неудачное делегирование «… возникает, когда сервер имён указан в записях NS для некого домена, но на деле не является сервером имён для этого домена. Запросы в этом случае передаются серверам, которые ничего [!] не знают об интересующем домена (по меньшей мере не возвращают ожидаемого). Более того, иногда на этих узлах (если они существуют) даже нет серверов имён» (цитата из параграфа 2.3 в [RFC1713]).
Приведённые ранние определения не совпадают с современным использованием термина lame delegation, но единого мнения о том, что считать неудачным делегированием, ент. Термин применяется не только для указания приведённых выше случаев, но и для ряда других ошибок при передаче полномочий, которые ведут к отсутствию откликов или возврату неполномочных откликов:
  • сервер имён с записью NS для зоны не отвечает на запросы DNS;
  • сервер имён с адресом IP, недоступным распознавателю;
  • сервер имён отвечает на запросы для определённого имени ошибкой или без бита полномочий.
Поскольку современное применение термина отличается от исходного определения, его следует считать устаревшим (историческим) и отказываться от него в пользу более чётких терминов.

Glue records – склеивающие записи

«… записи [RR], которые не относятся к полномочным данным зоны и являются RR с адресами серверов имён. Эти RR требуются только в тех случаях, когда имя сервера [имён] находится «ниже» среза и используются только, как часть отклика со ссылкой». Без склеивающих записей «может возникнуть ситуация, когда NS RR скажут, что для получения адреса сервера имён следует обратиться к серверу имён, адрес которого мы хотим узнать» (цитата из параграфа 4.2.1 в [RFC1034]).
В соответствии с более поздним определением склеивающие записи – это «любые записи в файле зоны, которые не являются в полной мере частью данной зоны, включая имена серверов DNS делегированных субзон (записи NS), адресные записи, сопровождающие эти записи NS (A, AAAA и т. п.), а также любые другие «приблудившиеся» данные» (цитата из параграфа 5.4.1 в [RFC2181]). Хотя терми иногда используется сегодня в соответствии с этим расширенным определением, контекст определения в [RFC2181] позволяет предположить, что оно относится лишь к использованию термина в этом документе.
В записях NS имеется три типа отношений между владельцем записи, именем в NS RDATA и началом зоны: отсутствие связи, нахождение в домене (in-domain) и братский домен. Применение этих трёх типов к склеивающим записям описано в [RFC9471].
Отсутствие связи – это отношения, где NS RDATA содержит сервер имён, который не является подчиненным началу зоны и, следовательно, не является частью самой зоны.
Нахождение в домене (in-domain) – это отношения, где NS RDATA содержит сервер имён, чьё имя является подчинённым или (редко) совпадает с именем владельца записей NS. Например, передача полномочий для child.example.com может создавать сервер имён в домене (in-domain) ns.child.example.com.
Братские отношения имеются, когда NS RDATA NS RDATA содержит сервер имён, чьё имя является подчинённым или (редко) совпадает с началом зоны родителя, но не является подчиненным или совпадающим с с именем владельца записей NS. Например, передача полномочий для child.example.com в зоне example.com может создавать сервер имён братского домена ns.another.example.com.
Примеры типов передачи полномочий приведены в таблице 1.

Таблица .

 

Делегирование

Родитель

Имя сервера имён

Тип

com

.

a.gtld-servers.net

sibling domain

net

.

a.gtld-servers.net

in-domain

example.org

org

ns.example.org

in-domain

example.org

org

ns.ietf.org

sibling domain

example.org

org

ns.example.com

unrelated

example.jp

jp

ns.example.jp

in-domain

example.jp

jp

ns.example.ne.jp

sibling domain

example.jp

jp

ns.example.com

unrelated

 

Bailiwick – сфера компетенции

Модификаторы In-bailiwick и Out-of-bailiwick служат для описания отношений между зоной и обслуживающими её серверами имён. Отмечено, что определение термина bailiwick в словаре вызывает больше путаницы, чем приносит пользы. Эти термины следует считать историческими (устаревшими) по своей природе.

Root zone – корневая зона

Зона дерева на основе DNS, вершиной которой является пустая метка. Иногда называется корнем DNS (DNS root).

Empty non-terminals (ENTs) – пустые нетерминальные элементы

«Доменные имена, в которых нет записей о ресурсах, но имеются субдомены» (цитата из параграф 2.2.2 в [RFC4592]). Типичный пример е примеры в записях SRV – в имени _sip._tcp.example.com, домен _tcp.example.com, вероятно, не имеет RRset, но _sip._tcp.example.com имеет (по меньшей мере) SRV RRset.

Delegation-centric zone – ориентированная на передачу полномочий зона

Зона, состоящая в основном из передачи полномочий дочерним зонам. Это противоположность зоне, которая может включать делегирование дочерним зонам, но включает множество записей о ресурсах самой зоны и/или дочерних зон. Термин применяется в [RFC4956] и [RFC5155], но не определён ни в одном из них.

Occluded name – поглощённое имя

«Добавление точки делегирования через динамическое обновление будет переводить все подчинённые доменные имена в «подвешенное» состояние, когда они остаются частью зоны, но утрачивают доступность для поиска. Добавление записи DNAME даёт такой же эффект. Такие подчинённые имена называют поглощёнными (скрытыми)» (цитата из параграфа 3.5 в [RFC5936]).

Fast flux DNS – быстрая смена

Это «происходит, когда домен [найденный] в DNS использует записи A с несколькими адресами IP, имеющие очень короткий срок действия (Time-to-Live или TTL). Это означает, что домен распознаётся по разным адресам IP в течение короткого интервала времени» (цитата из параграфа 1.1.5 в [RFC6561] с исправлением опечаток). Помимо легитимных применений быструю смену можно использовать для доставки вредоносных программ. Поскольку адреса меняются быстро, сложно проверить все хосты. Следует отметить, что этот метод работает и с записями AAAA, но на момент создания этого документа такое использование редко наблюдалось в Internet.

Reverse DNS, reverse lookup – обратный (реверсный) поиск

«Процесс отображения адреса на имя обычно называется реверсным поиском (reverse lookup), а о зонах IN-ADDR.ARPA и IP6.ARPA говорят как об обратной системе DNS (reverse DNS)» (цитата из раздела 1 в [RFC5855]).

Forward lookup – прямой поиск

«Трансляция имени хоста в адрес» (цитата из раздела 6 в [RFC3493]).

arpa (Address and Routing Parameter Area Domain) – домен arpa

«Домен arpa был создан как часть исходного развёртывания DNS для предоставления механизма перехода от таблиц хостов (Host Table), применяемых в сети ARPANET, а также в качестве домена для реверсного отображения адресов IPv4. В 2000 г. аббревиатура была переименована в Address and Routing Parameter Area (область адресов и параметров маршрутизации) в надежде снизить путаницу с названием сети» (цитата из раздела 2 в [RFC3172]). Домен .arpa является «инфраструктурным», (ролью которого является поддержка операционной инфраструктуры Internet» (цитата из раздела 2 в [RFC3172]). История имени описана в [RFC3172].

Service name – имя службы

«Имена служб являются уникальными ключами реестра Service Name and Transport Protocol Port Number. Это уникальные символьные имена служб, которые могут использоваться для других целей, например, в записях DNS SRV» (цитата из раздела 5 в [RFC6335]).

8. Шаблоны

Wildcard – шаблон

В [RFC1034] термин wildcard (шаблон) определён так, что это оказалось непонятным для внедряющих протокол. Расширенное обсуждение шаблонов, включая более чёткие определения, приведено в [RFC4592]. Особое внимание уделено RR, в которых имя владельца начинается с метки *. «Такие RR называют шаблонами. Шаблонные RR можно представлять, как инструкцию по синтезированию RR» (цитата из параграфа 4.3.3 в [RFC1034])

Asterisk label – метка *

«Первый октет – это обычный тип и размер 1-октетной метки, а второй содержит код ASCII [RFC20] для символа *. Описательным именем для такой метки является «звёздочка» (цитата из параграфа 2.1.1 в [RFC4592]).

Wildcard domain name – шаблонное доменное имя

«Шаблонное имя домена определяется наличием в его начале (левые или младшие символы) метки с двоичным представлением 0000 0001 0010 1010 = 0x01 0x2a (шестнадцатеричное)» (цитата из параграфа 2.1.1 в [RFC4592]). Второй октет этой метки является кодом ASCII для символа *.

Closest encloser – ближайшее включающее [имя]

«Самый длинный предок имени» (цитата из параграфа 1.3 в [RFC5155]). Прежним определением было: «Узел в дереве зоны имеющихся доменных имён, в котором наибольшее число меток соответствует имени в запросе (последовательно вниз от корневой метки). Каждое совпадение является совпадением метки и порядок меток одинаков» (цитата из параграфа 3.3.1 в [RFC4592]).

Closest provable encloser- ближайшее подтверждённое включающее [имя]

«Самый длинный предок имени, наличие которого может быть доказано. Отметим, что это имя отличается от ближайшего включающего имени в зоне Opt-Out» (цитата из параграфа 1.3 в [RFC5155]). Определение opt-out дано в разделе 10.

Next closer name – имя вслед за включающим

«Имя, которое на 1 метку длиннее ближайшего подтверждённого включающего имени (closest provable encloser)» (цитата из параграфа 1.3 в [RFC5155]).

Source of Synthesis – источник синтезирования

«Источник синтеза определяется в контексте процесса запроса как шаблонное доменное имя, непосредственно порождаемое (descending) ближайшим включающим именем (closest encloser), при условии существования такого шаблонного имени. Непосредственно порождаемое означает, что источник источник синтезирования имеет форму <asterisk label>.<closest encloser>» (цитата из параграфа 3.3.1 в [RFC4592]).

9. Модель регистрации

Registry – реестр

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

Registrant – регистрирующий

Организация или человек, от имени которого зона регистрируется в реестре. Во многих случаях реестр (registry) и регистрирующий (registrant) могут быть одним лицом, но для TLD это часто не так.

Registrar – регистратор

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

EPP

Расширяемый протокол обеспечения (Extensible Provisioning Protocol или EPP), обычно применяемый для передачи регистрационных сведений между реестром и регистрирующим. Протокол EPP определён в [RFC5730].

WHOIS

Протокол, заданный в [RFC3912] и часто применяемый для запроса к базам данных реестров. Данные WHOIS часто применяются для связывания данных регистрации (таких, как контакты управляющих зоной лиц) с доменными именами. Термин «данные WHOIS» часто служит синонимом базы данных реестра, хотя сама база может обслуживаться другими протоколами, в частности, RDAP. Протокол WHOIS применяется также для работы с данными реестров адресов IP.

RDAP

Протокол доступа к данным регистрации (Registration Data Access Protocol), заданный в [RFC7480], [RFC7481], [RFC7485], [RFC9082], [RFC9083] и [RFC9224]. Протокол и формат данных RDAP предназначены для замены WHOIS.

DNS operator – оператор DNS

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

Public suffix – суффикс общего пользования

«Домен, контролируемый публичным регистратором» (цитата из параграфа 5.3 в [RFC6265]). Общепринятым толкованием этого термина является домен, в котором третьи лица могут регистрировать свои субдомены, а HTTP cookie (см. [RFC6265]) не следует устанавливать. В доменном имени нет сведений, является ли имя публичным суффиксом и определить это можно лишь внешними средствами. Фактически общедоступными суффиксами может быть как домен, так и его субдомены. Одним из ресурсов для нахождения публичных суффиксов является список (Public Suffix List или PSL), поддерживаемых компанией Mozilla <https://publicsuffix.org/>. Например, в момент создания этого документа домен com.au был указан в PSL как общедоступный суффикс (отметим, что впредь это может измениться).
Отметим, что термин public suffix по многим причинам вызывает разногласия в сообществе DNS и в будущем может быть существенно изменён. Одним из примеров сложностей отнесения домена к суффиксам общего пользования является то, что обозначение может меняться по мере изменения правил регистрации в зоне, как в случае домена uk (TLD) в 2014 г.

Subordinate и Superordinate – подчинённый и вышестоящий

Эти термины применяются в [RFC5731] для модели регистрации, но не определены там. Вместо этого они приведены в примерах: «Например, доменное имя example.com является вышестоящим для имени хоста ns1.example.com… Например, имя хоста ns1.example1.com является подчиненным для домена example1.com, но не является таковым для example2.com» (цитата из параграфа 1.1 в [RFC5731]). Эти термины указывают строгие способы обозначения отношений между доменами, когда один является субдоменом другого.

10. Базовые термины DNSSEC

Большинство терминов DNSSEC определено в [RFC4033], [RFC4034], [RFC4035] и [RFC5155]. Здесь выделены термины, вызывающие путаницу в сообществе DNS.

DNSSEC-aware и DNSSEC-unaware – с поддержкой или без поддержки DNSSEC

Эти два термина используются в некоторых RFC, но не определены формально. Однако в разделе 2 [RFC4033] определены многие типы распознавателей и валидаторов, включая «не проверяющий достоверность защищённый оконечный распознаватель» (non-validating security-aware stub resolver), «не проверяющий корректность оконечный распознаватель» (non-validating stub resolver), «защищённый сервер имён» (security-aware name server), «защищённый рекурсивный сервер имён» (security-aware recursive name server), «защищённый распознаватель» (security-aware resolver), «защищённый оконечный распознаватель» (security-aware stub resolver), «обычное <нечто>» (security-oblivious ‘anything’). Отметим, что термин «проверяющий распознаватель» (validating resolver), используемый в связанных с DNSSEC документах также не определён в указанных RFC, но определён ниже.

Signed zone – подписанная зона

«Зона с подписанными наборами RRset, содержащая корректно созданный ключ DNSKEY, подпись RRSIG, записи NSEC и (необязательно) DS» (цитата из раздела 2 в [RFC4033]). В другом контексте отмечалось, что сама зона фактически не подписывается, но все соответствующие RRset в зоне подписываются. Тем не менее, если зона, которую следует подписывать, содержит какие-либо не подписанные (или отклонённые) RRset, эти наборы будут считаться фиктивными, поэтому вся зона должна обслуживаться каким-либо способом.
Следует также отметить, что с момента публикации [RFC6840], записи NSEC больше не требуются для подписанных зон и вместо них подписанная зона может включать записи NSEC3. В [RFC7129] представлен дополнительный справочный комментарий и некоторый контекст для механизмов NSEC и NSEC3, используемых в DNSSEC для предоставления аутентифицированных откликов о несуществовании (denial-of-existence). NSEC и NSEC3 описаны ниже.

Online signing – подписание по запросам

В [RFC4470] определён термин on-line signing (через дефис) как: «генерация и подписывание этих записей по запросу», где «эти» относится к записям NSEC. Текущее определение расширено включением генерации и подписывания по запросам записей RRSIG, NSEC и NSEC3.

Unsigned zone – неподписанная зона

В разделе 2 [RFC4033] указано, что это «зона, не имеющая подписи». В разделе 2 [RFC4035] указано: «Зона, не включающая записи [корректно созданные записи DNSKEY, RRSIG, NSEC и (не обязательно) DS] в соответствии с указанными правилами, является неподписанной». Важно подчеркнуть, что в конце параграфа 5.2 [RFC4035] указана дополнительная ситуация, когда зона считается неподписанной: «Если распознаватель не поддерживает ни одного алгоритма, указанного в DS RRset, он не сможет проверить путь аутентификации к дочерней зоне. В таких случаях распознавателю следует трактовать дочернюю зону, как неподписанную».

NSEC

«Запись NSEC позволяет защищённому распознавателю аутентифицировать негативный отклик в случаях отсутствия имени или типа с использованием того же механизма, который применяется при аутентификации других откликов DNS» (цитата из параграфа 3.2 в [RFC4033]). Короче говоря, запись NSEC предоставляет аутентифицированные сведения о несуществовании.
«Запись NSEC содержит два отдельных элемента – имя следующего владельца (в каноническом порядке для зоны), содержащего полномочные данные, или точка передачи полномочий (делегирования) NS RRset и множество типов RR, присутствующих в имени владельца NSEC RR» (цитата из раздела 4 в [RFC4034]).

NSEC3

Подобно NSEC, запись NSEC3 предоставляет аутентифицированные сведения о несуществовании, однако записи NSEC3 смягчают перечисление зоны и поддерживают Opt-Out. Записи NSEC3 требуют связанных записей о ресурсах NSEC3PARAM. Записи NSEC3 и NSEC3PARAM определены в [RFC5155].
Отметим, что в [RFC6840] сказано, что [RFC5155] «в настоящее время считается частью семейства документов DNS Security, как указано в разделе 10 [RFC4033]». Это означает, что некоторые определения из прежних RFC, где говорится только о записях NSEC, вероятно, следует считать относящимися как к NSEC, так и к NSEC3.

Opt-out

«Флаг Opt-Out указывает, что NSEC3 RR может охватывать неподписанное делегирование» (цитата из параграфа 3.1.2.1 в [RFC5155]). Opt-Out решает проблему высоких затрат на защиту делегирования в незащищённую зону. При использовании Opt-Out имена, являющиеся незащищённым делегированием и пустые нетерминальные элементы, выводимое только из незащищённого делегирования) не требуют записи NSEC3 или соответствующих записей RRSIG. Записи Opt-Out NSEC3 не могут подтверждать или опровергать наличие незащищённого делегирования (взято из параграфа 5.1 в [RFC7129]).

Insecure delegation – незащищённая передача полномочий

«Подписанное имя, содержащее делегирование (NS RRset), но не имеющее DS RRset, что означает передачу полномочий в неподписанную субзону (цитата из раздела 2 в [RFC4956]).

Zone enumeration – перечисление зоны

«Практика выявления полного содержимого зоны с помощью последовательных запросов» (цитата из параграфа 1.3 в [RFC5155]). Иногда применяется термин zone walking (прохождение по зоне). Перечисление зоны отличается от предсказывания содержимого зоны – при предсказывании используется большой словарь возможных меток и передаются последовательные запросы для них или сопоставляет содержимое записей NSEC3 с таким словарём.

Validation – проверка

Проверкой в контексте DNSSEC считается одно из указанных ниже действий.
  • Проверка достоверности подписей DNSSEC.
  • Проверка достоверности откликов DNS, в том числе аутентифицированных сведений о несуществовании.
  • Создание цепочки аутентификации от привязки доверия до отклика DNS или отдельных DNS RRset в нем.
В двух первых определениях рассматривается лишь достоверность отдельных компонентов DNSSEC, таких как RRSIG и доказательства NSEC. Третье определение учитывает всю цепочку проверки подлинности DNSSEC и распознаватель «должен быть настроен так, чтобы он знал хотя бы одну аутентифицированную запись DNSKEY или DS» (цитата из раздела 5 в [RFC4035]).
В разделе 2 [RFC4033] сказано, что «проверяющий достоверность защищённый оконечный распознаватель … выполняет проверку достоверности подписи» и использует привязку доверия «как стартовую точку для создания цепочки аутентификации к подписанному отклику DNS». Таким образом, используются первое и третье определение. Процесс проверки достоверности записей RRSIG описана в параграфе 5.3 [RFC4035].
В [RFC5155] проверка достоверности откликов упоминается в контексте хэшированных аутентифицированных откликов о несуществовании, где применяется второе определение.
Термин аутентификация используется как взаимозаменяемый с проверкой достоверности в смысле третьего определения. В разделе 2 [RFC4033] описана цепочка, связывающая привязку доверия с данными DNS, как цепочка аутентификации (authentication chain). Отклик считается подлинным, если «все RRset в разделах Answer и Authority [проверены] на предмет аутентичности» (цитата из [RFC4035]). Данные DNS и отклики, сочтённые подлинными или достоверными, имеют статус безопасности secure (параграф 4.3 в [RFC4035] и раздел 5 в [RFC4033]). «Последнее слово при анализе аутентификации для ключей и данных DNS остаётся за локальной политикой, которая может расширить или переназначить расширения протокола [DNSSEC]» (цитата из параграфа 3.1 в [RFC4033]).
При использовании термина проверка (verification) он обычно является синонимом проверки достоверности.

Validating resolver – проверяющий распознаватель

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

Key signing key (KSK) – ключ подписания ключей

Ключ DNSSEC, «подписывающий только DNSKEY RRset на вершине зоны» (цитата из параграфа 3.1 в [RFC6781]).

Zone signing key (ZSK) – ключ подписания зоны

«Ключ DNSSEC, который может применяться для подписания всех RRset в зоне, для которых требуется подпись, за исключением DNSKEY RRset на вершине» (цитата из параграфа 3.1 в [RFC6781]). Отметим, что иногда ZSK применяется и для подписания DNSKEY RRset на вершине.

Combined signing key (CSK) – комбинированный ключ подписания

«В случаях, когда различия между KSK и ZSK не проводится, т. е. каждый может играть обе роли, говорят о схеме однотипного подписания (Single-Type Signing Scheme)» (цитата из параграфа 3.1 в [RFC6781]). Иногда применяется термин «комбинированный ключ подписания» (combined signing key или CSK). Применение определённого ключа ZSK, KSK или CSK определяет практика работы, а не протокол.

Secure Entry Point (SEP) – защищённая точка входа

Флаг в DNSKEY RDATA, который «можно использовать для различения ключей, предназначенных служить защищёнными точками входа в зону при создании цепочек доверия, т. е. на них (должны) будут указывать родительские DS RR или они будут заданы как привязки доверия. … Поэтому предполагается устанавливать флаг SEP для ключей, применяемых как KSK, но не для ключей, служащих ZSK, хотя в тех случаях, когда эти ключи не различаются (Single-Type Signing Scheme), предлагается устанавливать флаг SEP для всех ключей» (цитата из параграфа 3.2.3 в [RFC6781]). Отметим, что флаг SEP служит лишь подсказкой и его наличие или отсутствие не может применяться для дисквалификации применения DNSKEY RR в качестве KSK или ZSK при проверке достоверности.
Исходное определение SEP дано в [RFC3757] и чётко указывает, что SEP является ключом, а не просто битом в ключе. В аннотации к [RFC3757] сказано: «С помощью записи DS RR (Delegation Signer) была введена концепция открытого ключа, служащего защищённой точкой входа (secure entry point или SEP). В процессе обмена открытыми ключами с родителем возникает необходимость отличать ключи SEP от других открытых ключей в наборе записей DNSKEY (Domain Name System KEY). Бит флага в DNSKEY RR определён для индикации того, что DNSKEY применяется как SEP». Определение SEP как ключа было отменено в [RFC4034], а определение [RFC6781] согласуется с определением [RFC4034].

Trust anchor – привязка доверия

«Сконфигурированная запись DNSKEY RR или хэш DS RR записи DNSKEY RR. Проверяющий защищённый оконечный распознаватель использует этот открытый ключ или хэш а качестве стартовой точки для построения аутентификационной цепочки отклика DNS. В общем случае проверяющий распознаватель будет получать начальные значения таких привязок с помощью того или иного защищённого или доверенного способа, не входящего в протокол DNS.» (цитата из раздела 2 в [RFC4033].

DNSSEC Policy (DP) – правила (политика) DNSSEC

Заявление, которое «устанавливает требования и стандарты безопасности для реализации в зоне, подписанной DNSSEC» (цитата из раздела 2 в [RFC6841]).

DNSSEC Practice Statement (DPS) – заявление о практике DNSSEC

«Раскрывающий практику документ, который может поддерживать и дополнять правила DNSSEC (при наличии) и в котором говорится, как в управлении данной зоной реализованы процедуры и элементы управления на высоком уровне» (цитата из раздела 2 в [RFC6841]).

Hardware security module (HSM) – аппаратный модуль защиты

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

Signing software – программы для подписания

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

11. Состояния DNSSEC

Проверяющий достоверность распознаватель может определить, что отклик имеет одно из четырёх состояний – secure, insecure, bogus, indeterminate. Эти состояния определены в [RFC4033] и [RFC4035], хотя определения в этих документах несколько различаются. Здесь не предпринимается попытки согласовать эти определения и не высказывается мнения о необходимости такого согласования.

В разделе 5 [RFC4033] сказано:

Проверяющий распознаватель может определять 4 перечисленных ниже состояния.

Secure – защищённое

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

Insecure – незащищённое

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

Bogus – подделка

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

Indeterminate – неопределённое

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

В параграфе 4.3 [RFC4035] сказано:

Защищённый распознаватель должен быть способен должен различать перечисленные ниже случаи.

Защищённый (Secure)

RRset, для которого распознаватель способен построить цепочку подписанных записей DNSKEY и DS RR от доверенной защитной привязки (security anchor) до RRset. В этом случае набору RRset следует быть подписанным и для него выполняется проверка подписи, описанная выше.

Незащищённый (Insecure)

RRset, для которого распознаватель знает об отсутствии цепочки подписанных записей DNSKEY и DS RR от любой доверенной стартовой точки до RRset. Это может наблюдаться в тех случаях, когда целевой набор RRset находится в неподписанной зоне или потомке такой зоны. В этом случае набор RRset может быть как подписанным, так и неподписанным и распознаватель не сможет проверить подпись.

Подделка (Bogus)

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

Неопределённость (Indeterminate)

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

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

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

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

Ссылки на RFC 8499 в реестрах IANA заменены ссылками на этот документ.

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

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

[IANA_RootFiles] IANA, “Root Files”, <https://www.iana.org/domains/root/files>.

[RFC0882] Mockapetris, P., “Domain names: Concepts and facilities”, RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.

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

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

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

[RFC1912] Barr, D., “Common DNS Operational and Configuration Errors”, RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.

[RFC1996] Vixie, P., “A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)”, RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.

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

[RFC2181] Elz, R. and R. Bush, “Clarifications to the DNS Specification”, RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.

[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, “Selection and Operation of Secondary DNS Servers”, BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997, <https://www.rfc-editor.org/info/rfc2182>.

[RFC2308] Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE)”, RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.

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

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

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions”, RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.

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

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence”, RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.

[RFC5358] Damas, J. and F. Neves, “Preventing Use of Recursive Nameservers in Reflector Attacks”, BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.

[RFC5730] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)”, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.

[RFC5731] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping”, STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.

[RFC5855] Abley, J. and T. Manderson, “Nameservers for IPv4 and IPv6 Reverse Zones”, BCP 155, RFC 5855, DOI 10.17487/RFC5855, May 2010, <https://www.rfc-editor.org/info/rfc5855>.

[RFC5936] Lewis, E. and A. Hoenes, Ed., “DNS Zone Transfer Protocol (AXFR)”, RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.

[RFC6561] Livingood, J., Mody, N., and M. O’Reirdan, “Recommendations for the Remediation of Bots in ISP Networks”, RFC 6561, DOI 10.17487/RFC6561, March 2012, <https://www.rfc-editor.org/info/rfc6561>.

[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, “DNSSEC Operational Practices, Version 2”, RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.

[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., “Clarifications and Implementation Notes for DNS Security (DNSSEC)”, RFC 6840, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-editor.org/info/rfc6840>.

[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, “A Framework for DNSSEC Policies and DNSSEC Practice Statements”, RFC 6841, DOI 10.17487/RFC6841, January 2013, <https://www.rfc-editor.org/info/rfc6841>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, “Extension Mechanisms for DNS (EDNS(0))”, STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, “Automating DNSSEC Delegation Trust Maintenance”, RFC 7344, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-editor.org/info/rfc7344>.

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, “Usage Profiles for DNS over TLS and DNS over DTLS”, RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.

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

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, “DNS over Dedicated QUIC Connections”, RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, “DNS Glue Requirements in Referral Responses”, RFC 9471, DOI 10.17487/RFC9471, September 2023, <https://www.rfc-editor.org/info/rfc9471>.

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

[IANA_Resource_Registry] IANA, “Resource Record (RR) TYPEs”, <https://www.iana.org/assignments/dns-parameters/>.

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

[RFC819] Su, Z. and J. Postel, “The Domain Naming Convention for Internet User Applications”, RFC 819, DOI 10.17487/RFC0819, August 1982, <https://www.rfc-editor.org/info/rfc819>.

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

[RFC1713] Romao, A., “Tools for DNS debugging”, FYI 27, RFC 1713, DOI 10.17487/RFC1713, November 1994, <https://www.rfc-editor.org/info/rfc1713>.

[RFC1995] Ohta, M., “Incremental Zone Transfer in DNS”, RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.

[RFC2775] Carpenter, B., “Internet Transparency”, RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.

[RFC3172] Huston, G., Ed., “Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain (“arpa”)”, BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>.

[RFC3425] Lawrence, D., “Obsoleting IQUERY”, RFC 3425, DOI 10.17487/RFC3425, November 2002, <https://www.rfc-editor.org/info/rfc3425>.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6”, RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, “Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag”, RFC 3757, DOI 10.17487/RFC3757, April 2004, <https://www.rfc-editor.org/info/rfc3757>.

[RFC3912] Daigle, L., “WHOIS Protocol Specification”, RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.

[RFC4470] Weiler, S. and J. Ihren, “Minimally Covering NSEC Records and DNSSEC On-line Signing”, RFC 4470, DOI 10.17487/RFC4470, April 2006, <https://www.rfc-editor.org/info/rfc4470>.

[RFC4641] Kolkman, O. and R. Gieben, “DNSSEC Operational Practices”, RFC 4641, DOI 10.17487/RFC4641, September 2006, <https://www.rfc-editor.org/info/rfc4641>.

[RFC4697] Larson, M. and P. Barber, “Observed DNS Resolution Misbehavior”, BCP 123, RFC 4697, DOI 10.17487/RFC4697, October 2006, <https://www.rfc-editor.org/info/rfc4697>.

[RFC4786] Abley, J. and K. Lindqvist, “Operation of Anycast Services”, BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[RFC4956] Arends, R., Kosters, M., and D. Blacka, “DNS Security (DNSSEC) Opt-In”, RFC 4956, DOI 10.17487/RFC4956, July 2007, <https://www.rfc-editor.org/info/rfc4956>.

[RFC5625] Bellis, R., “DNS Proxy Implementation Guidelines”, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.

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

[RFC5891] Klensin, J., “Internationalized Domain Names in Applications (IDNA): Protocol”, RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.

[RFC5892] Faltstrom, P., Ed., “The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)”, RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.

[RFC5893] Alvestrand, H., Ed. and C. Karp, “Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)”, RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.

[RFC5894] Klensin, J., “Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale”, RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.

[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, “IAB Thoughts on Encodings for Internationalized Domain Names”, RFC 6055, DOI 10.17487/RFC6055, February 2011, <https://www.rfc-editor.org/info/rfc6055>.

[RFC6265] Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[RFC6303] Andrews, M., “Locally Served DNS Zones”, BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, “Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry”, BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC6365] Hoffman, P. and J. Klensin, “Terminology Used in Internationalization in the IETF”, BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.

[RFC6672] Rose, S. and W. Wijngaards, “DNAME Redirection in the DNS”, RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.

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

[RFC7129] Gieben, R. and W. Mekking, “Authenticated Denial of Existence in the DNS”, RFC 7129, DOI 10.17487/RFC7129, February 2014, <https://www.rfc-editor.org/info/rfc7129>.

[RFC7480] Newton, A., Ellacott, B., and N. Kong, “HTTP Usage in the Registration Data Access Protocol (RDAP)”, STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>.

[RFC7481] Hollenbeck, S. and N. Kong, “Security Services for the Registration Data Access Protocol (RDAP)”, STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.

[RFC9082] Hollenbeck, S. and A. Newton, “Registration Data Access Protocol (RDAP) Query Format”, STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.

[RFC9083] Hollenbeck, S. and A. Newton, “JSON Responses for the Registration Data Access Protocol (RDAP)”, STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, <https://www.rfc-editor.org/info/rfc9083>.

[RFC9224] Blanchet, M., “Finding the Authoritative Registration Data Access Protocol (RDAP) Service”, STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, <https://www.rfc-editor.org/info/rfc9224>.

[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, “Inventory and Analysis of WHOIS Registration Objects”, RFC 7485, DOI 10.17487/RFC7485, March 2015, <https://www.rfc-editor.org/info/rfc7485>.

[RFC7793] Andrews, M., “Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry”, BCP 163, RFC 7793, DOI 10.17487/RFC7793, May 2016, <https://www.rfc-editor.org/info/rfc7793>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, “Specification for DNS over Transport Layer Security (TLS)”, RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8094] Reddy, T., Wing, D., and P. Patil, “DNS over Datagram Transport Layer Security (DTLS)”, RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.

[RFC8109] Koch, P., Larson, M., and P. Hoffman, “Initializing a DNS Resolver with Priming Queries”, BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017, <https://www.rfc-editor.org/info/rfc8109>.

[RFC8484] Hoffman, P. and P. McManus, “DNS Queries over HTTPS (DoH)”, RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Mankin, “DNS Zone Transfer over TLS”, RFC 9103, DOI 10.17487/RFC9103, August 2021, <https://www.rfc-editor.org/info/rfc9103>.

[RSSAC026] Root Server System Advisory Committee (RSSAC), “RSSAC0226 RSSAC Lexicon”, 2017, <https://www.icann.org/en/system/files/files/rssac-026-14mar17-en.pdf>.

Приложение A. Определения, обновлённые этим документом

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

  • Forwarder из [RFC2308]

  • QNAME из [RFC2308]

  • Secure Entry Point (SEP) из [RFC3757] (этот RFC уже устарел, см. [RFC4033], [RFC4034], [RFC4035]).

Приложение B. Определения, добавленные этим документом

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

  • Alias в разделе 2

  • Apex в разделе 7

  • arpa в разделе 7

  • Authoritative DoT (ADot)” в разделе 6

  • Bailiwick в разделе 7

  • Class independent в разделе 5

  • Classic DNS в разделе 6

  • Delegation-centric zone в разделе 7

  • Delegation в разделе 7

  • DNS operator в разделе 9

  • DNSSEC-aware в разделе 10

  • DNSSEC-unaware в разделе 10

  • Forwarding в разделе 6

  • Full resolver в разделе 6

  • Fully Qualified Domain Name в разделе 2

  • Global DNS в разделе 2

  • Hardware Security Module (HSM) в разделе 10

  • Host name в разделе 2

  • IDN в разделе 2

  • In-domain в разделе 7

  • Iterative resolution в разделе 6

  • Label в разделе 2

  • Locally served DNS zone в разделе 2

  • Naming system в разделе 2

  • Negative response в разделе 3

  • Non-recursive query в разделе 6

  • Open resolver в разделе 6

  • Passive DNS в разделе 6

  • Policy-implementing resolver в разделе 6

  • Presentation format в разделе 5

  • Priming в разделе 6

  • Private DNS в разделе 2

  • Recursive DoT (RDot) в разделе 6

  • Recursive resolver в разделе 6

  • Referrals в разделе 4

  • Registrant в разделе 9

  • Registrar в разделе 9

  • Registry в разделе 9

  • Root zone в разделе 7

  • Secure Entry Point (SEP) в разделе 10

  • Sibling domain в разделе 7

  • Signing software в разделе 10

  • Split DNS в разделе 6

  • Stub resolver в разделе 6

  • Subordinate в разделе 8

  • Superordinate в разделе 8

  • TLD в разделе 2

  • Validating resolver в разделе 10

  • Validation в разделе 10

  • View в разделе 6

  • Zone transfer в разделе 6

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

Andrew Sullivan был соавтором [RFC8499] и его предшественника – [RFC7719]. У текущего документа, который является небольшим обновлением [RFC8499], всего два автора. Работа Andrew над предыдущими документами заслуживает высокой оценки.

В создание [RFC8499] и [RFC7719] внесли вклад многие люди, отмеченные в разделах благодарностей этих документов.

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

Предметный указатель


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

Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
 
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Email: fujiwara@jprs.co.jp

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

nmalykh@protokols.ru


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

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

3В английском языке. Прим. перев.

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

RFC 9533 One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Internet Engineering Task Force (IETF)                             Z. Li
Request for Comments: 9533                                  China Mobile
Category: Standards Track                                        T. Zhou
ISSN: 2070-1721                                                   Huawei
                                                                  J. Guo
                                                               ZTE Corp.
                                                               G. Mirsky
                                                                Ericsson
                                                               R. Gandhi
                                                     Cisco Systems, Inc.
                                                            January 2024

One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Расширения протоколов OWAMP и TWAMP для измерения производительности LAG

PDF

Аннотация

Этот документ задаёт расширения протоколов односторонних One-Way Active Measurement Protocol или OWAMP) и двухсторонних (Two-Way Active Measurement Protocol или TWAMP) активных измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.

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

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

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

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

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

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

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

1. Введение

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

Обычно при пересылке трафика через LAG применяется основанный на хэшировании механизм распределения трафика между членами LAG. Задержка в в разных каналах группы может различаться из-за разных транспортных путей, особенно при использовании LAG в распределенной сети. Для обеспечения малой задержки чувствительного ко времени трафика требуется явно распределять трафик по каналам LAG с учётом задержки, потерь и т. п. Для этого требуется решение, позволяющее измерить показатели производительности на каждом канале LAG. Измеренные значения показателей могут применяться вместе с анонсами атрибутов L2 членов группы [RFC8668] для распределения трафика.

В соответствии с классификацией [RFC7799], OWAMP [RFC4656] и TWAMP [RFC5357] являются активными методами измерения и могут дополнять пассивные и гибридные методы. В любом из методов можно использовать одну тестовую сессию через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия не может применяться для измерения производительности каждого физического канала в группе.

Этот документ расширяет протоколы OWAMP и TWAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP и TWAMP (задержка и её вариации, потери пакетов.

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

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

2. Микросессии в LAG

В этом документе рассматривается вариант, где LAG напрямую соединяет два узла. Пример на рисунке 1 показывает LAG из 4 каналов, соединяющих узлы A и B. Задача состоит в измерении производительности каждого канала в LAG.

+---+                       +---+
|   |-----------------------|   |
| A |-----------------------| B |
|   |-----------------------|   |
|   |-----------------------|   |
+---+                       +---+

Рисунок . Измерение производительности в LAG.

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

Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.

Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии TWAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы.

3. Сессия OWAMP

3.1. Micro OWAMP-Control

Для поддержки микросессий OWAMP этот документ определяет новую команду – Request-OW-Micro-Sessions (5), основанную на команде OWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC4656]. Создание микросессии OWAMP выполняется по процедуре, описанной в параграфе 3.5 [RFC4656] с указанным ниже отличием.

Когда OWAMP Server получает команду Request-OW-Micro-Sessions и запрос воспринят, OWAMP Server должен организовать набор микросессии для всех членов группы LAG из которой было получено сообщение Request-OW-Micro-Sessions.

3.2. Micro OWAMP-Test

Пакеты Micro OWAMP-Test используют формат и процедуры, заданные для OWAMP-Test в разделе 4 [RFC4656] с указанным ниже дополнением.

OWAMP Session-Sender микросессии должен передавать пакеты Micro OWAMP-Test через канал, с которым связана микросессия. При получении тестового пакета OWAMP Session-Receiver микросессии должен сопоставлять канал, из которого принят пакет, с микросессией OWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться.

4. Сессия Micro TWAMP

4.1. Micro TWAMP-Control

Для поддержки микросессий TWAMP этот документ определяет новую команду – Request-TW-Micro-Sessions (11), основанную на команде TWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC5357]. Для организации микросессии TWAMP используется процедура из параграфа 3.5 в [RFC5357] с указанным ниже дополнением.

При получении сервером TWAMP команды Request-TW-Micro-Sessions и восприятии запроса TWAMP Server должен организовать набор микросессий для всех членов группы каналов LAG, из которой получено сообщение Request-TW-Micro-Sessions.

4.2. Micro TWAMP-Test

Протокол Micro TWAMP-Test основан на протоколе TWAMP-Test [RFC5357] с расширениями, описанными в последующих параграфах.

4.2.1. Формат и содержимое пакетов отправителя

Формат пакета Micro TWAMP Session-Sender основан на формате TWAMP Session-Sender, заданном в параграфе 4.1.2 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |             MBZ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session-Sender в режиме без аутентификации.

Для режима с аутентификацией и шифрованием применяется показанный ниже формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        MBZ (12 октетов)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |              MBZ              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                        Packet Padding                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session-Sender в режиме с аутентификацией.

Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.

Sender Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.

4.2.2. Поведение отправителя

TWAMP Session-Sender микросессии наследует поведение TWAMP Session-Sender, заданное в параграфе 4.1 [RFC5357]. Дополнительно TWAMP Session-Sender должен передавать тестовые пакеты Micro Session-Sender через каналы-члены, с которыми связана сессия. При передаче тестового пакета TWAMP Session-Sender микросессии должен включать идентификатор канала Sender, связанного с микросессией TWAMP, в поле Sender Micro-session ID. Если Session-Sender изнает идентификатор канала-члена группы у Reflector, он должен указываться в поле Reflector Micro-session ID (см. рисунки 2 и 3). В иных случаях поле Reflector Micro-session ID должно иметь значение 0.

Тестовый пакет с идентификатором канала у Sender передаётся рефлектору Session-Reflector, который «отражает» его с тем же идентификатором канала Sender. Таким образом, Session-Sender может использовать идентификатор канала Sender для проверки получения отражённого тестового пакета из канала-члена, связанного с корректной микросессией TWAMP.

Идентификатор канала у Reflector в поле Reflector Micro-session ID используется рефлектором Session-Reflector для проверки получения тестового пакета из канала, связанного с корректной микросессией TWAMP. Это означает, что Session-Sender нужно узнать идентификатор канала-члена группы у Reflector. Когда Session-Sender знает идентификатор канала у Reflector, он должен помещать его в поле Reflector Micro-session ID (см. рисунки 2 и 3) тестового пакета, передаваемого рефлектору Session-Reflector. Идентификатор канала у Reflector может быть определён из конфигурации или плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала на стороне Reflector.

При получении отражённого тестового пакета TWAMP Session-Sender микросессии должен использовать полученный идентификатор канала для сопоставления тестового пакета с микросессией TWAMP. Если соответствующей сессии нет, отражённый тестовый пакет должен отбрасываться. Если имеется соответствующая сессия, Session-Sender микросессии должен использовать Sender Micro-session ID для проверки корректного получения тестового пакета из ожидаемого канала группы. Если пакет получен из другого канала, он должен отбрасываться. Session-Sender микросессии должен использовать поле Reflector Micro-session ID для проверки поведения Reflector. При несоответствии идентификатора тестовый пакет должен отбрасываться.

4.2.3. Формат и содержимое пакетов рефлектора

Формат пакета Micro TWAMP Session-Reflector основан на формате TWAMP Session-Reflector, заданном в параграфе 4.2.1 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |               MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receive Timestamp                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Sequence Number                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sender Timestamp                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sender Error Estimate    |    Sender Micro-session ID    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sender TTL   |      MBZ      |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session- Reflector в режиме без аутентификации.


Для режима с аутентификацией и шифрованием применяется показанный ниже формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |               MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receive Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sender Sequence Number                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sender Error Estimate    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sender TTL   |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
|                                                               |
|                        MBZ (15 октетов)                       |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session- Reflector в режиме с аутентификацией.

Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.

Sender Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.

4.2.4. Поведение рефлектора

TWAMP Session-Reflector микросессии наследует поведение TWAMP Session-Reflector, описанное в параграфе 4.2 [RFC5357]. Дополнительно TWAMP Session-Reflector должен использовать идентификатор канала, откуда получен пакет, для сопоставления пакета с микросессией TWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться. Если поле Reflector Micro-session ID отлично от 0, Reflector должен использовать значение Reflector Micro-session ID для проверки соответствия идентификатору канала, из которого получен пакет (при Reflector Micro-session ID = 0 проверка не выполняется), и должен отбрасывать тестовый пакет при несоответствии.

При отправке отклика на полученный тестовый пакет TWAMP Session-Reflector микросессии должен копировать идентификатор каналу Sender из принятого пакета в поле Sender Micro-session ID отражённого тестового пакета (см. рисунки 4 и 5). Кроме того, TWAMP Session-Reflector микросессии должен помещать в поле Reflector Micro-session ID (см. рисунки 4 и 5) отражённого пакета идентификатор канала, связанного с микросессией TWAMP.

5. Применимость

Для организации микросессий OWAMP клиент Control-Client передаёт команду Request-OW-Micro-Sessions серверу OWAMP. Сервер OWAMP воспринимает запрос и организует набор микросессий для всех каналов группы LAG.

Для микросессий TWAMP применяется похожая процедура, после чего TWAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с полями Sender Micro-session ID и Reflector Micro-session ID. Если поле Reflector Micro-session ID задано (не 0), Session-Reflector микросессии проверяет получение тестового пакета из канала, соответствующего корректной микросессии TWAMP. При отражении TWAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного от Session-Sender микросессии пакета в пакет Micro Session-Reflector, затем указывает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией TWAMP. При получении пакета Micro TWAMP Session-Reflector поле Sender Micro-session ID используется Session-Sender микросессии для проверки получения пакета из канала, соответствующего корректной сессии TWAMP. Session-Sender микросессии также использует поле Reflector Micro-session ID для проверки поведения Reflector.

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

6.1. Команда Micro OWAMP-Control

Агентство IANA включило указанную в таблице 1 команду в реестр OWAMP-Control Command Numbers.

Таблица . Номер команды Request-OW-Micro-Sessions.

 

Значение

Описание

Документ

5

Request-OW-Micro-Sessions

Этот документ

 

6.2. Команда Micro TWAMP-Control

Агентство IANA включило указанную в таблице 2 команду в реестр TWAMP-Control Command Numbers.

Таблица . Номер команды Request-TW-Micro-Sessions.

 

Значение

Описание

Документ

11

Request-TW-Micro-Sessions

Этот документ

 

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

Этот документ не задаёт дополнительных требований безопасности и механизмов защиты к описанным в [RFC4656] и [RFC5357].

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

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

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

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

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

[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, “Advertising Layer 2 Bundle Member Link Attributes in IS-IS”, RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.

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

[IEEE802.1AX] IEEE, “IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation”, IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, <https://ieeexplore.ieee.org/document/9105034>.

[RFC7799] Morton, A., “Active and Passive Metrics and Methods (with Hybrid Types In-Between)”, RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

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

Авторы благодарны Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, Marcus Ihlar, Richard Foote за ценные замечания к работе.

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

Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
 
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
 
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
 
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
 
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com

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

nmalykh@protokols.ru


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

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

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

RFC 9534 Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Internet Engineering Task Force (IETF)                             Z. Li
Request for Comments: 9534                                  China Mobile
Category: Standards Track                                        T. Zhou
ISSN: 2070-1721                                                   Huawei
                                                                  J. Guo
                                                               ZTE Corp.
                                                               G. Mirsky
                                                                Ericsson
                                                               R. Gandhi
                                                     Cisco Systems, Inc.
                                                            January 2024

Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Расширение протокола STAMP для измерения производительности LAG

PDF

Аннотация

Этот документ расширяет простой протокол двухсторонних активных измерений (Simple Two-way Active Measurement Protocol или STAMP) измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.

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

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

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

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

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

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

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

1. Введение

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

Обычно при пересылке трафика через LAG применяется основанный на хэшировании механизм распределения трафика между членами LAG. Задержка в в разных каналах группы может различаться из-за разных транспортных путей, особенно при использовании LAG в распределенной сети. Для обеспечения малой задержки чувствительного ко времени трафика требуется явно распределять трафик по каналам LAG с учётом задержки, потерь и т. п. Для этого требуется решение, позволяющее измерить показатели производительности на каждом канале LAG. Измеренные значения показателей могут применяться вместе с анонсами атрибутов L2 членов группы [RFC8668] для распределения трафика.

В соответствии с классификацией [RFC7799], (STAMP) [RFC8762] является активным методом измерения и может дополнять пассивные и гибридные методы. Протокол обеспечивает механизм измерения в одном направлении или по кругу (round-trip) таких показателей как задержка и её вариации, потеря пакетов. Тестовую сессию STAMP через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия STAMP не может применяться для измерения производительности каждого физического канала в группе.

Этот документ расширяет протокол STAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP [RFC4656] и TWAMP [RFC5357] (задержка и её вариации, потери пакетов.

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

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

2. Микросессии в LAG

В этом документе рассматривается вариант, где LAG напрямую соединяет два узла. Пример на рисунке 1 показывает LAG из 4 каналов, соединяющих узлы A и B. Задача состоит в измерении производительности каждого канала в LAG.

+---+                       +---+
|   |-----------------------|   |
| A |-----------------------| B |
|   |-----------------------|   |
|   |-----------------------|   |
+---+                       +---+

Рисунок . Измерение производительности в LAG.


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

Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.

Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии STAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы. Сведения о канале группы кодируются в Micro-session ID TLV (см. раздел 3, где представлено также подробное описание проверки канала.

STAMP Session-Sender в микросессии может включать Follow-Up Telemetry TLV [RFC8972] для запроса сведений у Session-Reflector микросессии. Эта временная метка может быть важна для Session-Sender в микросессии, поскольку она повышает точность сетевых измерений за счёт минимизации влияния задержки на измерения.

3. Проверка каналов группы

Тестовые пакеты должны передавать сведения о члене группы в Micro-session ID TLV, заданном в этом параграфе, для проверки канала. Session-Sender микросессии проверяет, получен ли тестовый пакет из ожидаемого канала группы, а также проверяет, отправлен ли пакет ожидаемым каналом-членом на стороне Reflector. Session-Reflector микросессии проверяет, был ли пакет передан ожидаемым членом группы.

3.1. Micro-session ID TLV

Механизм STAMP TLV [RFC8972] расширяет тестовые пакеты STAMP добавлением одного или нескольких необязательных TLV. Этот документ задаёт TLV Type (11) для Micro-session ID TLV, передающих идентификатор канала-члена для STAMP Session-Sender в поле Sender Micro-session ID и для Session-Reflector – в поле Reflector Micro-session ID. Формат Micro-session ID TLV показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|  Type = 11    |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Sender Micro-session ID   |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Micro-session ID TLV.


Type (1 октет)

Служит для указания Micro-session ID TLV. Значение 11 выделено агентством IANA (раздел 5).

Length (2 октета)

Размер поля Value в октетах. Поле должно иметь значение 4.

Sender Micro-session ID (2 октета)

Указывает идентификатор канала группы LAG на стороне отправителя (Sender). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Указывает идентификатор канала группы LAG на стороне рефлектора (Reflector). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Reflector.

3.2. Процедуры Micro STAMP-Test

Для Micro STAMP-Test используются процедуры из раздела 4 STAMP [RFC8762] с указанными ниже дополнениями.

STAMP Session-Sender микросессии должен передавать пакеты Micro STAMP-Test через канал группы, с которым связана сессия. Сопоставление микросессий STAMP м идентификаторами каналов Sender/Reflector может быть задано путём добавления STAMP YANG [STAMP-YANG], детали добавления выходят за рамки этого документа.

При передаче тестовых пакетов STAMP Session-Sender микросессии должен указывать в поле Sender Micro-session ID идентификатор канала, связанного с микросессией STAMP. Если Session-Sender знает идентификатор канала для рефлектора, должно устанавливаться поле Reflector Micro-session ID. В иных случаях должно указываться Reflector Micro-session ID = 0. Идентификатор канала для рефлектора можно узнать из конфигурации или определить из плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала для Reflector.

При получении STAMP Session-Reflector тестового пакета с отличным от 0 полем Reflector Micro-session ID, рефлектор микросессии должен использовать идентификатор канала Reflector для проверки принадлежности к микросессии STAMP. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Если Reflector Micro-session ID = 0, проверка не выполняется. Если все проверки успешны, Session-Reflector передаёт отражённый тестовый пакет для Session-Sender. STAMP Session-Reflector микросессии должен указывать идентификаторы канала для Sender и Reflector, связанные с микросессией STAMP, в поля Sender Micro-session ID и Reflector Micro-session ID, соответственно. Идентификатор канала для Sender копируется из полученного тестового пакета.

При получении отражённого тестового пакета Session-Sender микросессии должен использовать Sender Micro-session ID для проверки получения тестового пакета из ожидаемого канала. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Session-Sender микросессии должен использовать значение Reflector Micro-session ID для проверки корректности поведения рефлектора и при несовпадении значений тестовый пакет должен отбрасываться.

Два режима работы STAMP Session-Reflector (stateless и stateful) характеризуют ожидаемое поведение, как описано в разделе 4 STAMP [RFC8762]. Для STAMP-Test в микросессиях также поддерживаются режимы с учётом и без учёта состояния, однако Micro STAMP-Test не создаёт дополнительного состояния STAMP, т. е. все процедуры, относящиеся к Micro-session ID не учитывают состояния.

4. Применимость

STAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с Micro-session ID TLV. Session-Reflector микросессии проверяет, получен ли тестовый пакет из канала, связанного с микросессией STAMP, если поле Reflector Micro-session ID установлено. При отражении тестового пакета STAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного пакета от Session-Sender микросессии в свой пакет Session-Reflector и устанавливает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией STAMP. Session-Sender микросессии при получении пакета Micro Session-Reflector проверяет, принят ли он из канала, связанного с микросессией STAMP, по значению поля Sender Micro-session ID. Session-Sender микросессии использует также Reflector Micro-session ID для проверки корректности поведения Reflector.

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

Агентство IANA выделило значение STAMP TLV Type лоя Micro-session ID TLV в реестре STAMP TLV Types [RFC8972].

Таблица . Новое значение STAMP TLV Type.

 

Значение

Описание

Документ

11

Micro-session ID

Этот документ

 

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

Заданное в этом документе расширение STAMP предназначено для применения в системах с LAG, где Session-Sender и Session-Reflector соединены напрямую групповым каналом. Предполагается, что узел, вовлечённый в работу STAMP был проверен на предмет целостности соединения LAG и нахождения узла-партнера на другом конце этого соединения (one-hop-away).

Документ не добавляет соображений безопасности, а механизмы защиты, указанные в [RFC8762] и [RFC8972], применимы и к этому документу.

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

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

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, “Simple Two-Way Active Measurement Protocol”, RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, “Simple Two-Way Active Measurement Protocol Optional Extensions”, RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.

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

[IEEE802.1AX] IEEE, “IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation”, IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, <https://ieeexplore.ieee.org/document/9105034>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC7799] Morton, A., “Active and Passive Metrics and Methods (with Hybrid Types In-Between)”, RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, “Advertising Layer 2 Bundle Member Link Attributes in IS-IS”, RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.

[STAMP-YANG] Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, “Simple Two-way Active Measurement Protocol (STAMP) Data Model”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-12, 5 November 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-12>.

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

Авторы благодарят Mach Chen, Min Xiao, Fang Xin, Marcus Ihlar, Richard Foote за ценные комментарии к работе.

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

Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
 
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
 
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
 
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
 
 
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com

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

nmalykh@protokols.ru


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

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

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

RFC 9519 Update to the IANA SSH Protocol Parameters Registry Requirements

Internet Engineering Task Force (IETF)                            P. Yee
Request for Comments: 9519                                        AKAYLA
Updates: 4250, 4716, 4819, 8308                             January 2024
Category: Standards Track                                               
ISSN: 2070-1721

Update to the IANA SSH Protocol Parameters Registry Requirements

Обновление требований к реестру параметров протокола SSH

PDF

Аннотация

Эта спецификация обновляет правила регистрации для добавления новых записей в реестры группы IANA Secure Shell (SSH) Protocol Parameters. Ранее обычно применялась процедура IETF Review, определённая в RFC 8126, хотя для некоторых реестров требовалась процедура Standards Action. Эта спецификация заменяет IETF Review процедурой Expert Review. Документ обновляет RFC 4250, 4716, 4819, 8308.

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

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

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

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

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

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

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

1. Введение

Реестр IANA Secure Shell (SSH) Protocol Parameters заполнялся несколькими RFC, включая [RFC4250], [RFC4716], [RFC4819], [RFC8308]. За исключением небольших подддиапазонов значений, требующих использовать процедуру Standards Action или помеченных для частного использования (Private Use), добавление значений происходило по процедуре IETF Review [RFC8126]. Эта спецификация заменяет правило IETF Review на Expert Review. Изменение соответствует похожим изменениям для некоторых реестров IPsec и TLS.

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

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

2. Затрагиваемые параметры протокола SSH

В таблице 1 приведены реестры Secure Shell (SSH) Protocol Parameters, для которых политика регистрации IETF Review заменена на Expert Review. Если изменения относятся к определённому диапазону, он указывается в колонке примечаний. Затронутые реестры ссылаются на данный документ.

Таблица . Затронутые параметры протокола Secure Shell (SSH).

 

Имя параметра

RFC

Примечания

Authentication Method Names

[RFC4250]

Channel Connection Failure Reason Codes and Descriptions

[RFC4250]

0x00000001-0xFDFFFFFF (включительно)

Compression Algorithm Names

[RFC4250]

Connection Protocol Channel Request Names

[RFC4250]

Connection Protocol Channel Types

[RFC4250]

Connection Protocol Global Request Names

[RFC4250]

Connection Protocol Subsystem Names

[RFC4250]

Disconnection Messages Reason Codes and Descriptions

[RFC4250]

0x00000001-0xFDFFFFFF (включительно)

Encryption Algorithm Names

[RFC4250]

Extended Channel Data Transfer data_type_code and Data

[RFC4250]

0x00000001-0xFDFFFFFF (включительно)

Extension Names

[RFC8308]

Key Exchange Method Names

[RFC4250]

MAC Algorithm Names

[RFC4250]

Pseudo-Terminal Encoded Terminal Modes

[RFC4250]

Public Key Algorithm Names

[RFC4250]

Publickey Subsystem Attributes

[RFC4819]

Publickey Subsystem Request Names

[RFC4819]

Publickey Subsystem Response Names

[RFC4819]

Service Names

[RFC4250]

Signal Names

[RFC4250]

SSH Public-Key File Header Tags

[RFC4716]

За исключением тегов, начинающихся с x-

 

Не затронуты изменениями лишь реестры протокола IANA SSH Message Numbers и Publickey Subsystem Status Codes, поскольку для них сохраняется процедура Standards Action из-за ограниченности ресурсов однобайтовых значений.

3. Пул назначаемых экспертов

По процедуре Expert Review [RFC8126] запросы на регистрацию рассматриваются в течение трёх недель в почтовой конференции <ssh-reg-review@ietf.org>, по рекомендации одного или нескольких назначенных экспертов. Однако для выделения значений до публикации документа назначенные эксперты могут одобрять регистрацию, как только они будут уверены, что спецификация будет опубликована.

В запросах на регистрацию, направляемых в список рассылки для рецензирования, следует использовать подходящую тему (например, Request to register value in SSH protocol parameters <specific parameter> registry).

В течение периода рецензирования назначенные эксперты одобряют или отклоняют запрос на регистрацию, сообщая о своём решении в списке рассылки и направляя его в IANA. Отказ должен включать обоснование и, если это применимо, предложения в части требуемых для принятия изменений. Запросы на регистрацию, по которым не принято решения по истечении 21 дня, могут передаваться в IESG через почтовую конференцию <iesg@ietf.org> для разрешения вопроса.

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

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

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

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

Этот документ полностью посвящён обновлению реестра IANA Secure Shell (SSH) Protocol Parameters.

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

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

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

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

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., “The Secure Shell (SSH) Protocol Assigned Numbers”, RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.

[RFC4819] Galbraith, J., Van Dyke, J., and J. Bright, “Secure Shell Public Key Subsystem”, RFC 4819, DOI 10.17487/RFC4819, March 2007, <https://www.rfc-editor.org/info/rfc4819>.

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

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

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

[CURDLE-MA] Turner, S., “Subject: [Curdle] Time to Review IANA SSH Registries Policies?”, message to the Curdle mailing list, February 2021, <https://mailarchive.ietf.org/arch/msg/curdle/gdiOlZr9bnrZv8umVyguGG3woIM/>.

[RFC4716] Galbraith, J. and R. Thayer, “The Secure Shell (SSH) Public Key File Format”, RFC 4716, DOI 10.17487/RFC4716, November 2006, <https://www.rfc-editor.org/info/rfc4716>.

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

Толчком к созданию этого документа послужило обсуждение в феврале 2021 г. в почтовой конференции CURDLE [CURDLE-MA].

Адрес автора

Peter E. Yee
AKAYLA
Mountain View, CA 94043
United States of America
Email: peter@akayla.com

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

nmalykh@protokols.ru


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

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

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

RFC 9522 Overview and Principles of Internet Traffic Engineering

Internet Engineering Task Force (IETF)                    A. Farrel, Ed.
Request for Comments: 9522                            Old Dog Consulting
Obsoletes: 3272                                             January 2024
Category: Informational                                                 
ISSN: 2070-1721

Overview and Principles of Internet Traffic Engineering

Обзор и принципы организации трафика Internet

PDF

Аннотация

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

Эта работа была впервые опубликована как RFC 3272 в мае 2002 г. Документ заменяет RFC 3272, полностью обновляя текст для приведения в соответствие с передовым опытом организации трафика Internet и включения ссылок на соответствующие свежие работы IETF.

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

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

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

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

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

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

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

1. Введение

В этом документе описываются принципы Internet TE. Целью документа является формулировка общих вопросов и принципов Internet TE, а также предоставление при необходимости руководств, рекомендаций и вариантов для разработки предварительно планируемых (offline) и динамических (online) возможностей Internet TE и систем поддержки.

Несмотря на максимальную эффективность Internet TE при сквозном применении, в этом документе основное внимание уделено TE в конкретном домене, таком как автономная система (Autonomous System или AS). Большая часть трафика Internet, как правило, исходит из одной AS и завершается в другой, поэтому в документ включён обзор аспектов междоменной организации трафика.

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

Эта работа была впервые опубликована как RFC 3272 в мае 2002 г. Документ заменяет RFC 3272, полностью обновляя текст для приведения в соответствие с передовым опытом организации трафика Internet и включения ссылок на соответствующие свежие работы IETF. Следует отметить, что примерно 3/5 RFC, упомянутых в этом документе, выпущены после публикации [RFC3272]. В Приложении A приведена сводка отличий этого документа от [RFC3272].

1.1. Что такое организация трафика Internet?

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

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

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

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

Другой важной задачей Internet TE является содействие надёжной работе сети [RFC2702]. Надёжность работы может быть обеспечена путём предоставления механизмов, улучшающих целостность сети, и внедрения правил для повышения живучести сети. Это снижает уязвимость служб при сбоях, возникающих из-за ошибок, отказов и неисправностей в инфраструктуре сети.

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

  1. функции управления трафиком на узлах, такие как кондиционирование, управление очередями, планирование;

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

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

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

Организация трафика бывает двух видов:

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

  • заранее спланированное распределение трафика, которое считается оптимальным.

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

  • задача планирования TE для обеспечения оптимального распределения трафика;

  • задачи маршрутизации и пересылки, поддерживающие потоки трафика в соответствии с запланированным распределением.

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

1.2. Компоненты TE

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

Ключевыми элементами TE, требуемыми для любого решения, являются:

  1. правила (политика);

  2. управления путями;

  3. управления ресурсами.

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

Политика позволяет выбирать пути (включая следующий узел) на основе сведений, выходящих за рамки базовой достижимости. В ранних определениях политики маршрутизации (например, [RFC1102] и [RFC1104]) рассмотрено применение политики маршрутизации для ограничения доступа к сетевым ресурсам на уровне агрегирования. BGP служит примером широко распространённого механизма применения таких правил (см. [RFC4271] и [RFC8955]). В контексте TE решения на основе правил принимаются в плоскости управления или на контроллерах и определяют выбор путей. Примеры этого приведены в [RFC4655] и [RFC5394]. Решения TE могут включать механизмы для распространения и/или применения правил, но определения конкретных правил остаётся за операторами сети.

Управление путями – это возможность пересылать пакеты с использованием дополнительных сведений, а не только информации о следующем узле (next hop). Примеры такого управления включают заданные отправителем маршруты IPv4 [RFC0791], явные маршруты RSVP-TE [RFC3209], маршрутизацию по сегментам (Segment Routing или SR) [RFC8402], цепочки сервисных функций (Service Function Chaining) [RFC7665]. Управления путями для TE может поддерживаться через протоколы плоскости управления, путём кодирования в заголовках плоскости данных или с использованием сочетания этих методов. Это включает управление с помощью контроллера с использованием ориентированного на сеть протокола управления.

Управление ресурсами обеспечивает пересылку и управление с учётом ресурсов. Примерами ресурсов являются пропускная способность, буферы и очереди, которыми можно управлять для контроля потерь и задержек. Резервирование ресурсов является частью управления ресурсами и обеспечивает в масштабе домена согласованное представление о сетевых ресурсах, используемых конкретными потоками. Определение используемых ресурсов может выполняться грубо или на очень тонком уровне. Отметим, что согласованное представление существует на уровне плоскости управления или контроллере, но не в плоскости данных. Представление может включать лишь данные учёта, но обычно в него входят возможности принимать, отвергать или реклассифицировать потоки на основе правил. Учёт может выполняться на основе любого сочетания статических представлений о потребностях в ресурсах и использования динамических механизмов сбора требований (например, через RSVP-TE [RFC3209]) или сведений о доступности ресурсов (например, через расширения OSPF для GMPLS [RFC4203]).

Распределение ресурсов – это аспект управления ресурсами в плоскости данных. Оно обеспечивает выделение конкретным потокам определённых ресурсов узлов и каналов. Примеры ресурсов включают буферы, механизмы применения правил и формирования скорости, которые обычно поддерживаются с помощью очередей. Распределение ресурсов включает также сопоставление потоков (классификацию) с определенным набором выделенных ресурсов. Методы классификации и дискретность управления ресурсами зависят от технологии. Примеры включают дифференцированное обслуживание (Diffserv) с отбрасыванием и перемаркировкой [RFC4594], MPLS-TE [RFC3209], пути с коммутацией по меткам (Label Switched Path или LSP) на основе GMPLS [RFC3945], а также решения на основе контроллеров [RFC8453]. Это уровень управления ресурсами не является обязательным, но важен для сетей, которые хотят поддерживать правила контроля перегрузок для контроля или регулирования предлагаемого трафика с целью предоставления разных уровней обслуживания и смягчения проблем перегрузки, а также для сетей, желающих контролировать задержки определённых потоков трафика.

1.3. Сфера применения

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

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

Хотя основное внимание в этом документе уделяется внутридоменной организации трафика, в разделе 7 приведён высокоуровневый обзор междоменного TE. Междоменная организация трафика Internet очень важна для повышения производительности планетарной инфраструктуры Internet.

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

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

В этом параграфе определены термины, полезные для Internet TE. Определения относятся к данному документу и в других документах могут иметь иной смысл.

Busy hour – час высокой загрузки

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

Congestion – перегрузка

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

Congestion avoidance – предотвращение перегрузок

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

Congestion response – реагирование на перегрузку

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

Constraint-based routing – маршрутизация на основе ограничений

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

Demand-side congestion management – контроль перегрузок по запросам

Схема контроля перегрузок на основе регулирования или кондиционирования предлагаемой нагрузки.

Effective bandwidth – эффективная пропускная способность

Минимальная пропускная способность, которую нужно предоставить потоку или агрегату потоков для обеспечения им «приемлемого качества обслуживания». Более строгое определение приведено в [KELLY].

Egress node – выходной узел

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

End-to-end – сквозной

Этот термин зависит от контекста и часто применяется к потокам трафика от исходного отправителя до конечного получателя. Другой термин – «от границы до границы» (edge-to-edge) часто применяется для описания потоков трафика от входа в домен или сеть до выхода оттуда. Однако в некоторых случаях (например, при наличии сервисного интерфейса между сетью и её клиентом или при прохождении пути через несколько доменов, контролируемых одним процессом) термин «сквозной» применяется для обозначения полной работы службы, которая может включать конкатенацию операций «от границы до границы». Таким образом, в контексте TE термин «сквозной» может относиться к полному пути TE, но не к полному пути трафика от приложения-источника до конечного получателя.

Hotspot – «горячая точка»

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

Ingress node – входной узел

Устройство (маршрутизатор), через которое трафик входит в сеть от источника (хост) или из другой сети.

Metric – показатель

Параметр, определяемый в стандартных единицах измерения.

Measurement methodology – методология измерений

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

Network congestion – перегрузка сети

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

Network survivability – жизнеспособность сети

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

Offered load – предлагаемая нагрузка

Предлагаемая нагрузка или предлагаемый нагрузочный трафик (offered traffic load) – это количественная мера объёма трафика, представляемого для передачи через сеть по сравнению с передаточными возможностями этой сети. Этот термин заимствован из теории очередей и значение 1 для предлагаемой нагрузки указывает, что сеть может передавать весь предложенный трафик, но не более того.

Offline traffic engineering – автономная организация трафика

Система организации трафика, существующая вне сети.

Online traffic engineering – внутренняя организация трафика

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

Performance measures – показатели производительности

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

Performance metric – показатель производительности

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

Provisioning – предоставление

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

Quality of Service (QoS) – качество обслуживания

QoS [RFC3198] – это механизмы, применяемые в сети для достижения определённых целей по доставке трафика конкретной службы в соответствии с параметрами, заданными соглашением об уровне обслуживания (SLA). «Качество» характеризуется доступностью услуги, задержками и их вариациями, пропускной способностью и долей теряемых пакетов. На уровне сетевого ресурса QoS относится к набору возможностей, позволяющих сервис-провайдеру приоритизировать трафик и управлять пропускной способностью и задержкой в сети.

QoS routing – маршрутизация QoS

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

Service Level Agreement (SLA) – соглашение об уровне обслуживания

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

Service Level Objective (SLO) – цель уровня обслуживания

Основной элемент SLA между провайдером и клиентом. SLO согласовываются как меры оценки работы поставщика услуг и обеспечивают способ предотвращения споров между сторонами из-за недопонимания.

Stability – стабильность

Рабочее состояние, когда сеть не переходит из одного режима а другой (и обратно).

Supply-side congestion management – контроль перегрузок на основе предложений

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

Traffic characteristic – характеристики трафика

Описание временного поведения или атрибутов данного потока или агрегата трафика.

Traffic-engineering system – система организации трафика

Набор объектов, механизмов и протоколов, применяемых совместно в целях организации трафика.

Traffic flow – поток трафика

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

Traffic mapping – отображение трафика

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

Traffic matrix – матрица трафика

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

Traffic monitoring – отслеживание трафика

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

Traffic trunk – транк трафика

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

Workload – рабочая нагрузка

Оценка объёма работы, которую нужно выполнить в сети для удовлетворения потребностей в трафике (насколько загружена сеть). Иногда применяется термин traffic workload.

2. Основы

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

2.1. Контекст Internet TE

Контекст организации трафика Internet включает несколько частей.

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

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

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

  4. Контекст реализации и применения, где воплощаются принятые решения. Этот контекст включает планирование, организацию и выполнение.

Контекст Internet TE и различные варианты решения задач рассматриваются в последующих параграфах.

2.2. Контекст сетевого домена

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

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

  • набора соединённых между собой ресурсов, обеспечивающих транспортные услуги для трафика IP с учётом некоторых ограничений;

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

  • системы реагирования, состоящей из сетевых процессов, протоколов и соответствующих механизмов, облегчающих перемещение трафика через сеть (см. [AWD2]).

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

  • управления действиями по обработке пакетов в рамках данного ресурса;

  • арбитража доступа различных пакетов к ресурсу;

  • регулирования поведения трафика на данном ресурсе.

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

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

Сети в Internet имеют две важных характеристики:

  • предоставление услуг в реальном масштабе времени;

  • работа в быстро меняющихся средах.

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

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

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

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

Сеть Internet должна функционировать при наличии разных классов трафика со своими требованиями к обслуживанию. Это требование разъяснено в архитектуре дифференцированного обслуживания (Differentiated Services или Diffserv) [RFC2475]. В этом документе описывается, как пакеты можно группировать в разные агрегаты трафика, чтобы каждый из агрегатов имел свой набор поведенческих характеристик или общий набор требований к доставке, которые могут задаваться явно или неявно. Два наиболее важных требования к доставке трафика приведены ниже.

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

  • Требования QoS могут задаваться:

    • ограничениями целостности, такими как потери пакетов;

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

2.3. Контекст задачи

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

  • способы идентификации требований к пространству решений;

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

  • способы фактического решение задач;

  • способы измерения и характеризации эффективности решений.

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

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

В этом документе характеристики сети на системном уровне называются макросостояниями, а на уровне ресурсов – микросостояниями. Характеристики системного уровня также называют возникающими (emergent) свойствами сети. Соответственно, схемы TE, имеющие дело с оптимизацией производительности сети на системно уровне называются макро-TE, а на уровне ресурсов – микро-TE. При определённых обстоятельствах производительность на системном уровне можно вывести из производительности на уровне ресурсов, используя соответствующие правила композиции, в зависимости от конкретных показателей производительности, представляющих интерес.

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

2.3.1. Перегрузки и их последствия

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

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

2.4. Контекст решения

Контекст решения для Internet TE включает анализ, оценку вариантов и выбор между вариантами действий. Обычно контекст решения основывается на выводах о текущем или будущем состоянии сети и принятии решений, которые могут включать предпочтения для того или иного набора действий. Более конкретно, контекст решения требует обоснованных оценок рабочей нагрузки, характеристики состояния сети, вывода решений, которые могут формулироваться явно или неявно, и возможно, выполнения набора управляющих воздействий. Действия по управлению могут включать манипуляции с параметрами, связанными с маршрутизацией, приобретением тактических мощностей и контролем над функциями управления трафиком. Ниже приведён список инструментов, которые могут применяться в контексте решения Internet TE

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

  • Набор интерактивных (online) а в некоторых случаях и автономных (offline) инструментов и механизмов для измерения, определения характеристик моделирования и управления трафиком, управления размещением и распределением сетевых ресурсов, а также управления отображением и распределением трафика по инфраструктуре.

  • Набор ограничений для рабочей среды, сетевых протоколов и самой системы TE.

  • Набор количественных и качественных методов и методик для абстрагирования, формулировки и решения задач TE.

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

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

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

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

  • документы по архитектуре сети;

  • проект сети;

  • конфигурационные файлы маршрутизаторов;

  • базы данных маршрутизации, такие как базы сведений о состоянии каналов протоколов внутренней маршрутизации (Interior Gateway Protocol или IGP);

  • таблицы маршрутизации;

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

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

Маршрутизация в работающих сетях IP может управляться административно на разных уровнях абстракции, включая манипуляции с атрибутами BGP и метрикой IGP. Для ориентированных на пути технологий, таких как MPLS, дополнительное управление маршрутизацией может выполняться манипуляциями с соответствующими параметрами TE и ресурсов, а также административными ограничениями в правилах. В контексте MPLS путь явно маршрутизируемого LSP можно рассчитать и организовать разными способами:

  • вручную;

  • автоматически и интерактивно (online) с использованием процессов маршрутизации по ограничениям на маршрутизаторах с коммутацией по меткам (Label Switching Router или LSR);

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

2.4.1. Борьба с перегрузками

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

  1. Контроль перегрузок на основе временных рамок отклика.

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

    • Средний (от минут до дней). Например, указанные ниже правила управления.

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

      2. Организация и настройка явно маршрутизируемых LSP в сетях MPLS для направления транков трафика от потенциально перегруженных ресурсов сети на более предпочтительные маршруты.

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

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

    • Короткий (минуты и меньше). Эта категория включает функции обработки и события на уровне пакетов в интервале нескольких периодов кругового обхода. Она включает также механизмы маршрутизаторов, такие как активное и пассивное управление буферами. Все эти механизмы служат для контроля перегрузок и сигнализации о них конечным системам, чтобы те могли адаптивно регулировать скорость передачи трафика в сеть. Общеизвестной схемой управления очередями, особенно для такого отзывчивого трафика, как TCP, является случайное упреждающее обнаружение (Random Early Detection или RED) [FLJA93]. Во время перегрузки (но до заполнения очереди) схема RED выбирает поступающие пакеты для «маркировки» по вероятностному алгоритму с учётом среднего размера очереди. Маршрутизатор, не использующий явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) [RFC3168], может просто отбрасывать помеченные пакеты для снижения перегрузки и неявного уведомления получателя о ней. С другой стороны, если маршрутизатор и конечный хост поддерживают ECN, они могут устанавливать поле ECN в заголовках пакетов и конечный хост может действовать на основе такой маркировки. Было предложено несколько вариантов RED для поддержки различных уровней предпочтения при отбрасывании в средах с разными классами [RFC2597]. RED обеспечивает предотвращение перегрузок не хуже, чем управление очередями Tail-Drop (TD)- отбрасывание прибывающих пакетов только после заполнения очереди. Важно, что RED снижает вероятность синхронизации пиков повторной передачи в сети и повышает уровень беспристрастности для сеансов трафика с разной реакцией. Однако RED, сам по себе, не может предотвратить перегрузки и отсутствие беспристрастности, связанные с источниками, не реагирующими на RED, например, некоторыми «жадными» потоками с некорректным поведением. Для повышения производительности и беспристрастности при наличии невосприимчивого трафика были предложены другие схемы. Некоторые из таких схем, например, отбрасывание в самой длинной очереди (Longest Queue Drop или LQD) и динамическое мягкое разделение со случайным отбрасыванием (Dynamic Soft Partitioning with Random Drop или RND) [SLDC98], были предложены как теоретические основы и обычно не поддерживаются в имеющейся коммерческой продукции, тогда как другие, например, примерно беспристрастное отбрасывание (Approximate Fair Dropping или AFD) [AFD03], были реализованы на практике. Рекомендации при применению схем активного управления очередями (Active Queue Management или AQM) представлены в [RFC7567], где рекомендуются алгоритмы AQM, подобные опубликованным IETF в [RFC8290], [RFC8033], [RFC8034], [RFC9332], на RED все ещё подходит для каналов со стабильной пропускной способностью при тщательной настройке.

  1. Реактивные и упреждающие схемы контроля перегрузок.

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

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

  1. Контроль перегрузок со стороны спроса и предложения.

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

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

2.5. Контекст реализации и применения

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

3. Модели процессов TE

В этом разделе описывается общая модель процесса, отражающая высокоуровневые практические аспекты организации трафика Internet в рабочем контексте. Модель процесса описывается как последовательность действий, которые должны быть выполнены для оптимизации производительности работающей сети (см. также [RFC2702] и [AWD2]). Модель процесса может быть реализована явно или неявно программным процессом или человеком.

Модель процесса TE является интерактивной [AWD2]. Четыре фазы модели, указанные ниже, повторяются как непрерывная последовательность.

  1. Определение соответствующих правил управления, регулирующих работу сети.

  2. Получение результатов измерения в работающей сети.

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

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

3.1. Компоненты модели

Основные компоненты модели процесса организации трафика указаны ниже.

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

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

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

4. Таксономия систем TE

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

  • В зависимости от времени, состояния или событий.

  • Автономные и интерактивные (online).

  • Централизованные и распределенные.

  • По локальным или глобальным сведениям.

  • Предписывающие и описательные.

  • С открытым и закрытым контуром.

  • Тактические и стратегические.

4.1. Управление по времени, состояниям и событиям

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

В зависящих от времени методиках TE применяются исторические сведения, основанные на периодических вариациях трафика (например, по времени суток), для предварительного программирования маршрутизации и других механизмов TE. Кроме того, может учитываться клиентская подписка и прогнозы трафика. Предварительно планируемая маршрутизация обычно изменяется сравнительно медленно (например, 1 раз в день). Зависящие от времени алгоритмы не пытаются приспособиться к краткосрочным вариациям трафика или изменениям условий в сети. Примером зависящего от времени алгоритма является централизованный оптимизатор, где на вход системы поступает матрица трафика и требования с несколькими классами QoS, как описано в [MR99]. Другим примером является приложение сбора данных о трафике Internet [AJ19], позволяющие применять алгоритмы машинного обучения для идентификации картин трафика в собранных с течением времени сведениях о трафике Internet и извлечения информации для принятия решений и повышения эффективности и продуктивности рабочих процессов.

В TE по состоянию планы маршрутизации приспосабливаются к текущему состоянию сети, что даёт дополнительные сведения о вариациях фактического трафика (т. е. возмущениях относительно регулярных вариаций), которые невозможно предсказать по историческим данным. Примером TE в зависимости от состояния является маршрутизация на основе ограничений, работающая в сравнительно долгосрочном масштабе времени. Примером для сравнительно коротких интервалов является алгоритм распределения нагрузки, описанный в [MATE]. Состояние сети может определяться на основе параметров, рассылаемых маршрутизаторами в лавинном режиме. Другой подход заключается в том, что конкретный маршрутизатор с адаптивной системой TE передаёт пробные пакеты по заданному пути для сбора сведений об этом пути. В [RFC6374] заданы расширения протоколов для сбора сведений о производительности сетей MPLS. Ещё один подход состоит в сборе системой управления сведений напрямую из элементов сети с использованием методов сбора данных телеметрии через публикацию и подписку [RFC7923]. Своевременный сбор и распространение данный очень важны для адаптивных TE. Зависящие от времени алгоритмы подходят для предсказуемых изменений трафика, а алгоритмы на основе состояний могут требоваться для повышения эффективности сети и обеспечения устойчивости к смене состояний сети.

Методы TE, зависящие от событий, также могут применяться для выбора пути TE. Эти методы отличаются от методов TE, зависящих от времени и состояний, по способу выбора путей. Алгоритмы являются адаптивными и распределенными по своей природе и обычно используют модели обучения для поиска в сети хороших путей TE. В то время как модели TE на основе состояний для выбора путей TE применяют лавинную рассылку в доступной полосе канале (available-link-bandwidth или ALB) [E.360.1], методам TE на основе событий не нужна лавинная рассылка ALB. Вместо этого они обычно находят пропускную способность по моделям обучения, как в методе STT (success-to-the-top) [RFC6601]. Лавинная рассылка ALB может отнимать много ресурсов, поскольку для неё нужна пропускная способность на передачу маршрутных анонсов состояний каналов и процессорное время для обработки этих анонсов. Кроме того, издержки на анонсы ALB и их обработку могут ограничивать размер области (area) и AS. Результаты моделирования показывают, что методы TE на основе событий могут приводить к снижению издержек ALB без потери пропускной способности сети [TE-QoS-ROUTING].

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

4.2. Автономные и интерактивные системы

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

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

4.3. Централизованные и распределенные системы

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

При распределенном управлении маршруты выбирает каждый маршрутизатор автономно на основе своего представления о состоянии сети. Сведения о состоянии сети маршрутизаторы могут получать с помощью зондирования или от других маршрутизаторов на периодической основе через анонсы состояний каналов. Сведения о состоянии сети могут распространяться и в исключительных ситуациях. Примеры протокольных расширений, применяемых для анонсирование сведений о состоянии каналов, определены в [RFC5305], [RFC6119], [RFC7471], [RFC8570], [RFC8571]. См. также параграф 5.1.3.9.

4.3.1. Гибридные системы

На практике большинство систем TE буду представлять гибрид централизованного и распределенного управления. Например, популярный в MPLS подход к TE заключается в применении центрального контроллера на основе элемента расчёта пути (Path Computation Element или PCE) с учётом состояний, а протоколы маршрутизации служат для принятия локальных решений на маршрутизаторах внутри сети. Локальные решения позволяют быстрее реагировать на события в сети, но могут возникать конфликты между решениями разных маршрутизаторов.

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

4.3.2. Соображения для программно-определяемых сетей (SDN)

Как отмечено в параграфе 5.1.2.2, одним из основных факторов развития программно-определяемых сетей (Software-Defined Networking или SDN) является отделение плоскости управления сетью от плоскости данных [RFC7149]. Однако SDN может также обеспечивать централизованное управление ресурсами и облегчать взаимодействие приложений с сетью через интерфейс прикладных программ (Application Programming Interface или API), как описано в [RFC8040]. Сочетание этих свойств обеспечивает гибкость сетевой архитектуры, позволяя приспосабливать сетевые требования к разным приложениям верхнего уровня. Это часто называют программируемой сетью [RFC7426].

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

С использованием основанной на PCE схемы управления SDN [RFC7491] топологию сети можно раскрыть путём запуска пассивного экземпляра OSPF или IS-IS, а также через BGP Link State (BGP-LS) [RFC9552]) для генерации базы организации трафика (Traffic Engineering Database или TED) (см. параграф 5.1.3.14). PCE служит для расчёта пути (см. параграф 5.1.3.11) на основе TED и доступной пропускной способности, а затем может быть выполнена оптимизация пути на основе запрошенных целевых функций [RFC5541]. Когда подходящий путь рассчитан, программирование явного сетевого пути можно выполнить с использованием протокола сигнализации, проходящего по всему пути [RFC3209], или поэтапно (per-hop) с непосредственным программированием каждого узла контроллером SDN [RFC8283].

Используя централизованный подход к управлению сетью, можно получить дополнительные преимущества, включая глобальную одновременную оптимизацию (Global Concurrent Optimization или GCO) [RFC5557]. Запрос расчёта пути GCO будет использовать топологию сети и сигнальные запросы пути вместе с соответствующими ограничениями для оптимального размещения в сети. Поэтому расчёты на основе GCO можно применять для пересчёта имеющихся сетевых путей с целью оптимизации трафика и снижения перегрузок.

4.4. Локальные и глобальные сведения

Для алгоритмов организации могут требоваться локальные и глобальные сведения о состоянии сети.

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

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

4.5. Предписывающие и описательные системы

Системы TE можно разделить на предписывающие и описательные.

В предписывающей организации трафика оцениваются варианты и рекомендуется курс действий. Такие системы можно дополнительно разделить на корректирующие и совершенствующие (perfective). Корректирующие TE предписывают курс действий для устранения имеющихся или прогнозируемых аномалий. Совершенствующие TE предписывают курс действий для развития и повышения производительности сети даже при отсутствии аномалий.

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

4.5.1. Сети на основе намерений

Одним из способов выразить запрос на обслуживание является намерение (intent). Сети на основе намерений проще в управлении и эксплуатации, требуя лишь минимального вмешательства. Намерения определены в [RFC9315].

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

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

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

4.6. Системы с открытым и закрытым контуром

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

4.7. Тактические и стратегические системы

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

5. Обзор методов TE

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

  • механизмы TE, соответствующие определениям из параграфа 1.2;

  • подходы, основанные на этих механизмах TE;

  • методы, применяемые в этих подходах и механизмах TE.

Рассмотрение не претендует на полноту и предназначено в основном для освещения имеющихся подходов к TE в сети Internet. Исторический обзор TE в телекоммуникационных сетях приведён в разделе 4 [RFC3272], а в параграфе 4.6 этого документа представлен обзор некоторых ранних подходов к TE, разработанных другими органами стандартизации. В задачи этого документа не входит анализ истории TE или перечисление связанной с TE работы других органов стандартизации (Standards Development Organization или SDO).

5.1. Обзор проектов IETF, связанных с TE

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

5.1.1. Механизмы IETF TE

5.1.1.1. Интегрированные услуги

В IETF разработана модель интегрированных услуг (Integrated Services или Intserv), требующая предварительного выделения ресурсов, таких как пропускная способность и буферы, для данного потока трафика с целью исполнения запрошенных этим трафиком требований QoS. Модель Intserv включает компоненты, дополняющие принятые в модели обслуживания по возможности (best-effort), такие как классификаторы и планировщики пакетов, а также контроль допуска. Классификаторы пакетов служат для идентификации потоков, получающих определённый уровень обслуживания, планировщики реализуют планирование обслуживания разных потоков пакетов в соответствии с обязательствами QoS, а контроль допуска служит для проверки наличия у маршрутизатора ресурсов, требуемых для нового потока.

Основной проблемой модели Intserv является расширяемость [RFC2998], особенно в больших общедоступных сетях IP, где могут одновременно существовать миллионы активных потоков трафика. Уведомления о наступающей перегрузке (Pre-Congestion Notification или PCN) [RFC5559] решают проблему расширяемости Intserv за счёт инструментального контроля допуска (и прерывания потоков при отказах) между граничными узлами. Узлы между границами межсетевого обмена не применяют операций на уровне потоков, а граничные узлы могут использовать для потока или агрегата потоков протокол резервирования ресурсов (Resource Reservation Protocol или RSVP).

Примечательной особенностью модели Intserv является необходимость явной сигнализации требований QoS от конечных систем к маршрутизаторам [RFC2753]. Протокол RSVP (см. параграф 5.1.3.2) реализует эту функцию и является критически важным для модели Intserv.

5.1.1.2. Дифференцированные услуги

Целью дифференцированного обслуживания (Differentiated Services или Diffserv) в рамках IETF было создание расширяемых механизмов классификации трафика по агрегатам поведения, в конечном итоге приводящих к разной трактовке поведения каждого агрегата, особенно в случаях нехватки ресурсов (таких как пропускная способность каналов и ёмкость буферов) [RFC2475]. Одним из основных мотивов создания Diffserv была разработка дополнительных механизмов дифференциации услуг в Internet для смягчения проблем расширяемости, присущих модели Intserv.

В Diffserv применяется поле DS заголовка IP (6 битов) которое исходно служило октетом типа обслуживания (Type of Service или TOS). Поле DS служит для указания режима пересылки, который следует обеспечивать пакету на транзитных узлах [RFC2474]. Diffserv включает концепцию групп поведения на этапах пересылки (Per-Hop Behavior или PHB). С помощью PHB можно задать несколько классов обслуживания, используя различные правила классификации, контроля, формирования и планирования трафика.

Для применения конечным пользователем услуг Diffserv, предоставляемых его сервис-провайдером (Internet Service Provider или ISP), ему может потребовать заключение соглашения об уровне обслуживания (SLA) с ISP. В SLA может явно или неявно включаться соглашение о кондиционировании трафика (Traffic Conditioning Agreement или TCA), задающее правила классификации, измерения, маркировки, отбрасывания и формовки трафика.

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

После планирования сети и маркировки пакетов на её границе модель Diffserv решает вопросы управления трафиком на каждом узле (per-hop). Модель управления Diffserv состоит из набора управляющих механизмов микро-TE. Для обеспечения приемлемого качества обслуживания в сетях Diffserv нужны и другие возможности TE, такие как управление пропускной способностью (включая управление маршрутизацией). Для лучшего представления Diffserv в рамках всего домена введена концепция поведения в домене (Per-Domain Behavior) [RFC3086].

Процедуры Diffserv применимы и в контексте MPLS (см. параграф 6.8).

5.1.1.3. SR Policy

SR Policy [RFC9256] является развитием SR (см. параграф 5.1.3.12) для расширения возможностей TE в SR. Это модель, позволяющая создавать на узле упорядоченный список сегментов для реализации правил маршрутизации от источника с конкретным намерением направлять трафик от этого узла. SR Policy указывается триплетом <headend, color, endpoint>, где headend – это IP-адрес узла, на котором установлены правила, endpoint – IP-адрес цели правил, а color — индекс, связывающий SR Policy с намерением (например, малая задержка).

Головной узел (headend) получает уведомления о правилах SR и связанных с ними путях SR через конфигурацию или расширения протоколов, таких как коммуникационный протокол PCE (Path Computation Element Communication Protocol или PCEP) [RFC8664] или BGP [SR-TE-POLICY]. Каждый путь SR состоит из списка сегментов (путь SR с маршрутизацией от источника) и головной узел использует параметры endpoint и color для классификации пакетов в соответствии с SR Policy и определения пути для их пересылки. Если правила SR связаны с набором путей SR, каждый из путей имеет все для взвешенного распределения нагрузки. Кроме того, с набором полей SR может быть связано несколько SR Policy, чтобы по одним путям передавалось несколько потоков трафика.

С каждым путём-кандидатом, связанным с SR Policy или с самой политикой SR можно связать идентификатор привязки (SR Binding SID или BSID). Головной узел устанавливает запись с ключом BSID в плоскости пересылки и назначает ей действие по направлению пакетов, соответствующих записи, на выбранный путь SR Policy. Это направление можно реализовать разными способами.

По SID

Идентификатор сегмента (SID) входящих пакетов совпадает с локальным BSID на головном узле.

По адресату

Входящие пакеты соответствуют маршруту BGP/Service, указывающему SR Policy.

По потоку

Входящие пакеты соответствуют массиву пересылки (например, классический 5-tuple), указывающему SR Policy.

По правилам

Входящие пакеты соответствуют правилу маршрутизации, направляющему их в SR Policy.
5.1.1.4. TE на основе транспорта L4

В дополнение к механизмам TE на основе IP могут рассматриваться подходы на основе транспорта L4 в соответствующем контексте развёртывания (например, ЦОД и многодомные системы). Например, 3GPP определяет сервисные функции направления, коммутации и расщепления трафика доступа (Access Traffic Steering, Switching, and Splitting или ATSSS) [ATSSS], как указано ниже.

Access Traffic Steering – направление трафика доступа

Выбор сети доступа для нового потока и передача трафика этого потока через выбранную сеть доступа.

Access Traffic Switching – коммутация трафика доступа

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

Access Traffic Splitting – расщепление трафика доступа

Пересылка пакетов потока через несколько сетей доступа одновременно.

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

Active-Standby – активный-резервный

Трафик передаётся через конкретный (активный) доступ и коммутируется в другой (резервный) при недоступности активного.

Priority-based – по приоритетам

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

Load-Balancing – распределение нагрузки

Трафик распределяется между сетями доступа в заданном процентном отношении (например, 75% и 25%).

Smallest Delay – наименьшая задержка

Трафик пересылается через систему доступа с наименьшим временем кругового обхода (round-trip time или RTT).

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

С целью предоставления услуг ATSSS для трафика TCP применяются Multipath TCP [RFC8684] и 0-RTT Convert Protocol [RFC8803], для UDP – Multipath QUIC [QUIC-MULTIPATH] и Proxying UDP in HTTP [RFC9298]. Отметим, что QUIC поддерживает процедуру переноса соединений, позволяющую партнёрам менять свои транспортные координаты L4 (адреса IP и номера портов) без прерывания базового соединения QUIC. Расширения протокола контроля перегрузок для дейтаграмм (Datagram Congestion Control Protocol или DCCP) [RFC4340] с поддержкой операций по нескольким путям, заданы в [MULTIPATH-DCCP].

5.1.1.5. Детерминированные сети

Архитектура детерминированных сетей (Deterministic Networking или DetNet) [RFC8655] предназначена для приложений с критическими требованиями по времени и надёжности. Многоуровневая архитектура сосредоточена в основном на развитии возможностей служб DetNet в плоскости данных [RFC8938]. Подуровень сервиса DetNet обеспечивает набор функций репликации, устранения и упорядочения пакетов (Packet Replication, Elimination, and Ordering Functions или PREOF) для сквозной гарантии обслуживания. Подуровень пересылки DetNet обеспечивает соответствующие гарантии пересылки (низкие потери, ограниченная задержка, упорядоченная доставка), используя механизмы выделения ресурсов и явного задания маршрутов. Разделение на два подуровня обеспечивает гибкую адаптацию возможностей DetNet к ряду механизмов TE, таких как IP, MPLS, SR. Ещё более важна связь между чувствительными ко времени сетями (Time Sensitive Networking или TSN) IEEE 802.1 [RFC9023], развёрнутыми в системах промышленного управления и автоматизации (Industry Control and Automation Systems или ICAS).

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

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

Отметим, что в DetNet могут проявляться некоторые проблемы расширяемости, отмеченные для Intserv в параграфе 5.1.1.1, но область действия DetNet обычно меньше и такие проблемы менее часты.

5.1.2. Подходы IETF на основе механизмов TE

5.1.2.1. Оптимизация трафика прикладного уровня

В этом документе описаны различные механизмы TE, доступные в сети, однако в общем случае распределенные приложения (в частности, «жадные» до пропускной способности приложения P2P, применяемые, например, для совместного использования файлов) не могут использовать эти методы напрямую. В соответствии с [RFC5693] приложения могут значительно улучшить распределение и качество трафика за счёт взаимодействия с внешними источниками, знающими топологию сети. Решение задачи оптимизации трафика прикладного уровня Application-Layer Traffic Optimization или ALTO) означает, с одной стороны, внедрение службы ALTO для предоставления приложениям сведений о базовой сети (например, структуры базового размещения и предпочтений для сетевых путей), а с другой – усовершенствование приложений в плане применения этих данных для лучшего, чем случайный, выбора конечных точек с которыми организуются соединения.

Основная функция ALTO основана на абстрактных планах сети, обеспечивающих упрощённое представление, но содержащих достаточно сведений для их эффективного использования приложениями. На основе этих планов строятся дополнительные службы. В [RFC7285] описан протокол, реализующий услуги ALTO как интерфейс публикации сведений, позволяющий сети публиковать информацию о себе для сетевых приложений. Эта информация может включать местоположение узлов сети, группы соединений между узлами, упорядоченными по стоимости в соответствии с настраиваемой детализацией, а также свойства конечных хостов. Сведения, публикуемые протоколом ALTO, следует делать полезными для сети и приложений. Протокол ALTO имеет соответствующее REST устройство и представляет свои запросы и отклики с использованием модульного представления JSON [RFC8259] путём деления публикации сведений ALTO на множество услуг ALTO (например, Map Service, Map-Filtering Service, Endpoint Property Service, Endpoint Cost Service).

В [RFC8189] задана новая служба, позволяющая клиенту ALTO извлекать несколько показателей стоимости через один запрос для отфильтрованной карты стоимости ALTO и карту стоимости конечных точек. [RFC8896] расширяет службу сведений о стоимости ALTO, чтобы приложения могли решать не только «где» присоединиться, но и «когда» это делать. Это полезно для приложений, которым нужна массовая передача данных с её планированием (например, в часы малой загрузки). В [RFC9439] введены показатели производительности сети, включая задержку и её вариации, долю теряемых пакетов, число интервалов пересылки (hop) и пропускную способность. Сервер ALTO может выводить и агрегировать такие показатели из BGP-LS (см. параграф 5.1.3.10), IGP-TE (см. параграф 5.1.3.9) или инструментов управления и раскрывать эти сведения, чтобы позволить приложениям определить, где подключаться к сети на основе критериев производительности. Рабочая группа ALTO оценивает использование свойств TE в сети при принятии решений о новых вариантах использования, таких как пограничные расчёты и объединение ЦОД.

5.1.2.2. Визуализация и абстрагирование сети

Одной из основных движущих сил SDN [RFC7149] является отделение плоскости управления сетью от плоскости данных. Это разделение можно обеспечить для сетей TE путём развития MPLS (параграф 5.1.3.3) и GMPLS (параграф 5.1.3.5) и элементов PCE (параграф 5.1.3.11). Одним из преимуществ SDN является логическая централизация управления, позволяющая полностью видеть базовые сети. Централизованное управление в SDN помогает улучшить использование ресурсов сети по сравнению с распределенным управлением.

Абстракция и управление сетями TE (Abstraction and Control of TE Networks или ACTN) [RFC8453] задаёт иерархическую архитектуру SDN, описывающую функциональные элементы и методы согласования ресурсов в нескольких доменах для предоставления композитных услуг с организацией трафика. ACTN облегчает составные междоменные соединения и предоставляет их пользователю. Основные задачи ACTN указаны ниже.

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

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

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

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

5.1.2.3. Расслоение сети

IETF Network Slice – это логическая топология сети, соединяющая множество конечных точек с использованием набора общих или выделенных ресурсов сети [NETWORK-SLICES]. Ресурсы применяются для выполнения конкретных SLO, заданных клиентами.

Сетевые слои, сами по себе, не являются конструкциями TE, однако оператор сети, предлагающий такое расслоение, будет, скорей всего, применять множество инструментов TE для управления своей сетью и предоставления услуг. Слои сети IETF определены так, что они не зависят от базовой инфраструктуры соединений и применяемой технологии. С точки зрения клиента IETF Network Slice выглядит как матрица связности VPN с дополнительными сведениями об уровне обслуживания, который нужен клиенту между конечными точками. С точки зрения оператора IETF Network Slice выглядит как набор инструкций по маршрутизации и туннелированию с резервированием сетевых ресурсов, требуемых для обеспечения уровня обслуживания, заданного в SLO. Концепция IETF Network Slice согласуется и расширенными VPN [ENHANCED-VPN].

5.1.3. Методы IETF, используемые TE

5.1.3.1. Маршрутизация на основе ограничений

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

Концепция маршрутизации на основе ограничений в контексте требований MPLS-TE в сетях IP была впервые описана в [RFC2702] и привела к разработке MPLS-TE [RFC3209], как указано в параграфе 5.1.3.3.

В отличие от маршрутизации на основе QoS (например, [RFC2386], [MA], [PERFORMANCE-ROUTING]), где обычно решаются задачи маршрутизации отдельных потоков трафика для выполнения предписанных требований QoS при условии доступности сетевых ресурсов, маршрутизация на основе ограничений применима к агрегатам и потокам трафика с возможностью выполнения широкого круга ограничений, включая ограничения политики.

5.1.3.1.1. Гибкие алгоритмы IGP

Обычный подход к маршрутизации в сети IGP основан на определении протоколами IGP «кратчайших путей» через сеть на основе лишь метрики IGP, назначенной для каналов. С таким подходом часто связаны ограничения – трафик может сгущаться в направлении адресата, что может вызывать перегрузку, а также невозможно направить трафик по путям в соответствии со сквозным качеством, запрашиваемым приложениями.

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

Гибкие алгоритмы IGP [RFC9350] позволяют протоколам IGP строить пути через сеть с учётом ограничений, определяя следующий узел (hop) на основе ограничений. Целью гибких алгоритмов является снижение сложности TE за счёт разрешения протоколу IGP выполнять некоторые базовые расчёты TE. Гибкий алгоритм включает набор расширений IGP, который позволяет маршрутизатору передавать TLV:

  • описывающие набор ограничений для технологии;

  • определяющие тип расчёта;

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

Заданная комбинация типов расчёта и метрики, а также ограничений называется определением гибкого алгоритма (Flexible Algorithm Definition или FAD). Маршрутизатор, передающий такой набор TLV, также назначает конкретный идентификатор (гибкий алгоритм) такой заданной комбинации.

Имеется два варианта применения гибкого алгоритма в сетях IP [RFC9502] и сетях SR [RFC9350]. В первом случае гибкий алгоритм рассчитывает пути к адресам IPv4 или IPv6, во втором – к Prefix SID (см. параграф 5.1.3.12).

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

  • Расширение функций показателей производительности IP [RFC5664], где в сети может быть организована конкретная маршрутизация на основе ограничений (гибкий алгоритм) по результатам измерения производительности.

  • Формирование «базовой» сети с использованием гибких алгоритмов и реализация «наложенной» сети с использованием методов TE. Такой подход позволяет использовать вложенную комбинацию гибкого алгоритма и расширений TE для IGP (см. параграф 5.1.3.9).

  • Гибкие алгоритмы в SR-MPLS (параграф 5.1.3.12) могут служить основой для простого создания топологии в стиле TE без компонентов TE на маршрутизаторах и использования PCE (см. параграф 5.1.3.11).

  • Поддержка сетевых слоёв (slice) [NETWORK-SLICES] где SLO конкретного IETF Network Slice может гарантироваться гибким алгоритмом или с использованием гибкого алгоритма может быть создана отфильтрованная топология (Filtered Topology) [NETWORK-SLICES] в стиле топологии TE.

5.1.3.2. RSVP

RSVP – это протокол сигнализации «мягкого состояния» (soft-state) [RFC2205]. Протокол поддерживает резервирование ресурсов для индивидуальных и групповых потоков по инициативе получателей. RSVP был разработан как сигнальный протокол модели интегрированных услуг (IntServ, см. параграф 5.1.1.1) для приложений, передающих требования QoS в сеть с целью резервирования соответствующих ресурсов QoS [RFC2205].

В RSVP отправитель трафика или узел-источник передаёт сообщение Path получателю трафика с теми же адресами отправителя и получателя, которые будет использовать отправитель. Сообщение Path включает:

  • спецификацию трафика от отправителя, описывающую характеристики трафика;

  • шаблон отправителя, задающий формат трафика;

  • необязательная спецификация анонса, используемая для поддержки концепции «один путь с анонсами» (One Pass With Advertising или OPWA) [RFC2205]

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

Одна из проблем исходной спецификации [RFC2205] связана с расширяемостью. Это обусловлено тем, что резервирование требовалось для микропотоков, что обычно вело к линейному росту числа состояний, поддерживаемых элементами сети, по мере увеличения числа потоков. Эти проблемы описаны в [RFC2961], где предложены изменения и расширения RSVP для смягчения проблемы расширяемости и возможности применять RSVP в качестве универсального протокола сигнализации для Internet. Например, RSVP можно расширить с целью резервирования ресурсов для агрегатов потоков [RFC3175], создания явных MPLS LSP (см. параграф 5.1.3.3) и выполнения других сигнальных функций в Internet. В [RFC2961] также описан механизм для сокращения числа сообщений Refresh, требуемых для поддержки созданных сессий RSVP.

5.1.3.3. MPLS

MPLS – это схема пересылки, включая расширения традиционных протоколов плоскости управления IP. MPLS расширяет модель маршрутизации Internet и улучшает пересылку пакетов и управление путями [RFC3031].

На входе в домен MPLS маршрутизаторы LSR делят пакеты IP по классам эквивалентности пересылки (Forwarding Equivalence Class или FEC) на основе множества факторов, включая, например, сочетание сведений из заголовков IP в пакетах и локальные данные маршрутизации, поддерживаемые LSR. Затем в начало стека меток MPLS каждого пакета добавляется метка, соответствующая FEC. Запись стека меток MPLS имеет размер 32 бита и содержит 20-битовое поле метки.

LSR принимает решения о пересылке с использованием метки, добавленной в начало пакета, как индекса локальной записи о следующем узле пересылки по меткам (Next Hop Label Forwarding Entry или NHLFE). Затем пакет обрабатывается в соответствии с NHLFE. Входящая метка заменяется исходящей (смена меток – label swap) и пакет может пересылаться следующему LSR. Перед выходом пакета из домена MPLS его (верхняя) метка MPLS может быть удалена. LSP – путь между входным и выходным LSR, по которому проходит пакет с меткой. Путь явного LSP определяется узлом отправителя (входным) LSP. В MPLS для организации LSPможет применяться сигнальный протокол, такой как RSVP или протокол распространения меток (Label Distribution Protocol или LDP).

MPLS является мощной технологией для Internet TE за счёт поддержки явных LSP, позволяющих эффективно реализовать маршрутизацию на основе ограничений в сетях IP [AWD2]. Требования для TE в MPLS описаны в [RFC2702]. Расширения RSVP для поддержки организации явных LSP рассмотрены в [RFC3209] и параграфе 5.1.3.4.

5.1.3.4. RSVP-TE

RSVP-TE является расширением протокола RSVP (параграф 5.1.3.2) для организации трафика, спецификация расширения задана в [RFC3209]. RSVP-TE позволяет создавать MPLS LSP с организацией трафика (TE LSP), используя строгие или нестрогие пути и учитывая ограничения сети, такие как доступная пропускная способность. Расширение поддерживает сигнализацию LSP по явным путям, которые могут быть заданы административно или рассчитаны подходящим элементом (таким, как PCE, см. параграф 5.1.3.11) на основе требования QoS и правил с учётом превалирующего состояния сети, анонсированного расширением IGP для IS-IS [RFC5305], OSPFv2 [RFC3630], или OSPFv3 [RFC5329]. RSVP-TE позволяет резервировать ресурсы (например, пропускную способность) на пути.

RSVP-TE включает возможность вытеснять LSP на основе приоритета и использовать близость (affinity) каналов для их исключения или включения в LSP. Протокол дополнительно расширен для поддержки быстрой перемаршрутизации (Fast Reroute или FRR) [RFC4090], Diffserv [RFC4124] и двухсторонних LSP [RFC7551]. Расширения RSVP-TE для поддержки GMPLS (см. параграф 5.1.3.5) заданы в параграфе [RFC3473]. Требования к MPLS-TE LSP «один со многими» (point-to-multipoint или P2MP) заданы в [RFC4461], а расширения для организации P2MP MPLS-TE LSP через RSVP-TE – в [RFC4875]. P2MP LSP состоит из множества суб-LSP «от источника к листу» (source-to-leaf или S2L). Для определения путей P2MP LSP важен выбор точек ветвления (на основе возможностей, состояния сети и правил) [RFC5671]

Протокол RSVP-TE был расширен для предоставления в реальном масштабе времени динамических показателей для выбора пути с малой задержкой с использованием расширений IS-IS [RFC8570] и OSPF [RFC7471] на основе простого протокола активных двухсторонних измерений (Simple Two-Way Active Measurement Protocol или STAMP) [RFC8972] и протокола двухсторонних активных измерений (Two-Way Active Measurement Protocol или TWAMP) [RFC5357].

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

5.1.3.5. GMPLS

GMPLS расширяет протоколы управления MPLS охватывая технологии с разделением по времени (например, SONET/SDH3, PDH4, OTN5), длине волны (lambda) и пространственной коммутацией (например, входного порта или волокна в выходной порт или волокно) и продолжая поддерживать коммутацию пакетов. GMPLS предоставляет общий набор протоколов управления для всех этих уровней (включая расширения для некоторых технологий), каждый из которых имеет свою плоскость данных или пересылки. GMPLS охватывает сигнализацию и маршрутизацию в плоскости управления и базируется на расширениях TE для MPLS (см. параграф 5.1.3.4).

В GMPLS [RFC3945] исходная архитектура MPLS расширена для включения LSR с плоскостью пересылки на основе коммутации каналов (устройств), поэтому здесь не могут применяться для пересылки данных сведения из заголовков пакетов или ячеек. В частности, такие LSR включают устройства, где коммутация основана на временных интервалах (time slot), длине волны или физических порта. Эти дополнения влияют на базовые свойства LSP – способы запроса и передачи меток, одностороннюю природу MPLS LSP, способы распространения сведений об ошибках и информацию, предоставляемую для синхронизации входных и выходных LSR [RFC3473].

5.1.3.6. IPPM

Рабочая группа IETF по показателям производительности IP (IP Performance Metrics или IPPM) подготовила набор стандартных показателей, которые могут применяться для мониторинга качества, производительности и надёжности служб Internet. Эти показатель могут применять операторы сетей, конечные пользователи и независимые тестировщики для обеспечения пользователей и сервис-провайдеров общим пониманием в части производительности и надёжности облаков компонентов Internet [RFC2330]. Критерии для показателей производительности, разработанных IPPM, описаны в [RFC2330]. Примеры показателей производительности включают потери пакетов в одном направлении [RFC7680], задержку в одном направлении [RFC7679] и показатели связности между парой узлов [RFC2678]. Другие показатели включают измерения второго порядка для задержек и потери пакетов.

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

Рабочая группа IPPM также разрабатывает методы и протоколы измерений для определения показателей.

5.1.3.7. Измерение потоков

Рабочая группа IETF по измерению потоков в реальном масштабе времени (Real Time Flow Measurement или RTFM) разработала архитектуру, определяющую метод указания потоков трафика, а также ряд измерительных компонентов (измерители, считыватели и диспетчеры измерителей) [RFC2722]. Система измерения потоков позволяет проводить измерения и анализ на уровне отдельного потока сетевого трафика. Как отмечено в [RFC2722], система измерения потоков может быть очень полезна в ряде случаев:

  • анализ поведения существующих сетей;

  • планирование внедрения и расширения сетей;

  • количественная оценка производительности сети;

  • проверка качества сетевых услуг;

  • идентификация работы пользователей с сетью.

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

Спецификация экспорта данных о потоках IP (IP Flow Information Export или IPFIX) [RFC5470] определяет архитектуру, которая очень похожа на архитектуру RTFM6 и включает процессы измерения, экспорта и сбора. В [RFC5472] рассмотрена применимость IPFIX и дано сравнение с RTFM, где указано, что архитектурно RTFM имеет дело с устройствами, а IPFIX – с процессами, для уточнения того, что на одной машине может присутствовать множество таких процессов. Протокол IPFIX [RFC7011] получил широкое распространение.

5.1.3.8. Контроль перегрузки конечных точек

В [RFC3124] описан набор механизмов контроля перегрузок для транспортных протоколов, позволяющих также создавать механизмы унификации контроля перегрузок для подмножества индивидуальных соединений (групп перегрузки). Диспетчер контроля перегрузок отслеживает состояние пути для каждой контролируемой им «группы перегрузок», используя полученные сведения для инструктирования планировщика в части распределения пропускной способности между соединениями этой группы. Концепции, описанные в [RFC3124], и уроки, которые можно извлечь из этой работы, нашли применение в HTTP/2 [RFC9113] и QUIC [RFC9000], а в [RFC9040] описана взаимозависимость блоков управления TCP, лежащая в основе работы диспетчера контроля перегрузок, описанного в [RFC3124].

5.1.3.9. Расширения TE для IGP

В [RFC5305] описаны расширения протокола взаимодействия промежуточных систем (Intermediate System to Intermediate System или IS-IS) для поддержки TE, в [RFC3630] – расширения TE OSPFv2, а в [RFC5329] – для OSPFv3. В IS-IS и OSPF применяется общая концепция расширений TE для распространения параметров TE, таких как тип и идентификатор канала, локальный и удалённый адрес IP, метрика TE, максимальная пропускная способность, максимальная резервируемая пропускная способность, незарезервированная пропускная способность и административная группа. Распространяемые IGP сведения могут служить для создания представления о состоянии и возможностях сети TE (см. параграф 5.1.3.14).

Различия между IS-IS и OSPF заключаются в деталях кодирования и передачи параметров TE.

  • В IS-IS используются Extended IS Reachability TLV (тип 22), Extended IP Reachability TLV (тип 135) и Traffic Engineering router ID TLV (тип 134), где для передачи параметров TE служат суб-TLV, описанные в [RFC8570].

  • В OSPFv2 используются Opaque LSA [RFC5250] типа 10, а в OSPFv3 – Intra-Area-TE-LSA. В обеих версиях OSPF применяются два TLV верхнего уровня (Router Address и Link TLV), использующие суб-TLV для передачи параметров TE ([RFC7471] для OSPFv2 и [RFC5329] для OSPFv3).

5.1.3.10. BGP – состояние канала

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

BGP (см. раздел 7) является одним из основных протоколов маршрутизации, объединяющим Internet. BGP-LS [RFC9552] – это механизм, с помощью которого можно собрать из сети сведения о состоянии каналов и TE, а также передать её внешним компонентам с помощью протокола маршрутзации BGP. Механизм подходит для физических и виртуальных каналов IGP и может управляться на основе правил. Сведения, собранные BGP-LS, можно использовать, например, для создания базы TED (параграф 5.1.3.14), используемой PCE (параграф 5.1.3.11), или на серверах ALTO (параграф 5.1.2.1).

5.1.3.11. Элемент расчёта пути

Расчёт путей на основе ограничений является важнейшей частью TE в сетях MPLS и GMPLS. Расчёт путей в больших многодоменных сетях сложен и может требовать специальных расчётных компонентов и кооперации между элементами разных доменов. PCE [RFC4655] – это элемент (компонент, приложение или узел сети), способный рассчитать путь или маршрут через сеть на основе графа сети и зададных для расчёта ограничений. PCE может служить центральным компонентом TE, работающей на основе базы TED (см. параграф 5.1.3.14), с передачей ему ответственности за расчёт путей в сетях MPLS, GMPLS или SR. PCE использует коммуникационный протокол PCEP [RFC5440] для взаимодействия с клиентами расчёта путей (Path Computation Client или PCC), такими как MPLS LSR, для ответов на их запросы расчёта путей или инструктирования их для инициирования новых путей [RFC8281] и поддержки состояния для путей, уже организованных в сети [RFC8231].

PCE являются ключевыми компонентами ряда систем TE. Дополнительные сведения о применимости PCE приведены в [RFC8051], а в [RFC6805] описано использование PCE для определения путей через несколько доменов. PCE могут также применяться в сетях ACTN (см. параграф 5.1.2.2), централированном управлении сетями (Centralized Network Control) [RFC8283] и SDN (см. параграф 4.3.2).

5.1.3.12. Маршрутизация по сегментам (SR)

Архитектура SR [RFC8402] использует парадигмы маршрутизации от источника и туннелирования. Путь передачи пакетов определяется на входе, а на выходе пакет туннелируется. В реализации протокола входной узел направляет пакет с использованием набора инструкций, называемых сегментами, которые включаются в добавляемый в начало пакета заголовок SR – стек меток в случае MPLS или последовательность 128-битовых SID для IPv6. Сегменты указываются идентификаторами SID. Имеется 4 типа SID, относящихся к TE.

  • Prefix SID – уникальное в домене маршрутизации значение SID, служащее для идентификации префикса.

  • Node SID – Prefix SID с установленным битом N для идентификации узла.

  • Adjacency SID указывает смежность в одном направлении.

  • Binding SID используется для двух целей:

    1. анонсирование сопоставлений префиксов с SID или метками;

    2. анонсирование пути, доступного для класса эквивалентной пересылки (FEC).

Сегмент может представлять любую инструкцию, основанную на топологии или услуге. SID можно искать в глобальном (домен) или ином конткексте (см., например, контекст меток в разделе 3 [RFC5331]).

Применение правил к SR может превратить SR в механизм TE, как описано в параграфе 5.1.1.3.

5.1.3.13. Построение дерева для явной репликации битового индекса

Явная репликация битового индекса (Bit Index Explicit Replication или BIER) [RFC8279] задаёт инкапсуляцию для групповой пересылки, которая может применяться в транспорте MPLS или Ethernet. Механизм построения дерева для репликации битового индекса (Tree Engineering for Bit Index Explicit Replication или BIER-TE) [RFC9262] представляет собой компонент, который может служить для построения групповой системы организации трафика. BIER-TE сам по себе не обеспечивает полной организации трафика и TE в данном случае с организацией трафика не связано.

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

Управление ресурсами влияет на плоскость пересылки не только в части направления пакетов, заданного для BIER-TE. Оно включает выделение буферов для удовлетворения требований представленного трафика и может включать механизмы применения правил и/или формирования скорости с помощью различных форм очередей. Этот уровень управления ресурсов, хотя и не является обязательным, важен для сетей, которые хотят поддерживать правила контроля перегрузок для контроля или регулирования предлагаемого трафика, чтобы предоставлять различные уровни обслуживания и смягчать проблемы перегрузки. Она важен также для сетей, жалающий контролировать задержки, возникающие для конкретных потоков трафика.

5.1.3.14. Определение и представление состояния TE в сети

Состояния сети, относящиеся к TE, должны сохраняться в системе и представляться пользователю. База TED содержит набор сведений TE об узлах и каналах TE в сети. Она является важным компонентом таких систем TE, как MPLS-TE [RFC2702] и GMPLS [RFC3945]. Для формального определения данных TED и их представления пользователю можно применять язык моделирования данных YANG [RFC7950], как описано в [RFC8795].

5.1.3.15. Интерфейсы управления системой

Система управления TE должна иметь удобный для человека интерфейс, программируемый для оптимизации. Протокол настройки сети (Network Configuration Protocol или NETCONF) [RFC6241] и протокол RESTCONF [RFC8040] обеспечивают программируемые интерфейсы, удобные для человека. Эти протоколы используют сообщения в формате XML или JSON. Если для оптимизации интерфейса управления или экономии пропускной способности нужно сжимать сообщения, можно воспользоваться протоколом грруповых коммуникаций для приложений с ограничениями (Constrained Application Protocol или CoAP) [RFC7390] или gRPC [GRPC], особенно при кодировании сообщений в двоичном формате. Вместе с любым из этих протоколов можно использовать язык моделирования данных YANG [RFC7950] для формального и точного описания данных интерфейса.

Другим вариантом является протокол PCEP [RFC5440], разработанный как вариант интерфейса управления системой TE. Сообщения PCEP передаются в формате TLV и не определяются языком моделирования данных, таким как YANG.

5.2. Распространение содержимого

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

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

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

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

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

6. Рекомендации по организации трафика Internet

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

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

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

6.1. Базовые нефункциональные рекомендации

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

Автоматизация

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

Гибкость

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

Функциональная совместимость

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

Расширяемость

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

Безопасность

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

Простота

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

Стабильность

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

Удобство использования

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

Видимость

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

6.2. Рекомендации по маршрутизации

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

Протоколы IGP, основанные на алгоритмах поиска кратчайших путей (Shortest Path First или SPF), имеют ограниченные возможности управления TE [RFC2702] [AWD2]. Эти ограничения кратко описан ниже.

  1. Чистые протоколы SPF не учитывают ограничения сети и характеристики трафика при выборе маршрутов. Например, IGP всегда выбирают кратчайшие пути на основе метрики каналов, заданно администраторами, поэтому распределение нагрузки по неравноценным путям невозможно. Отметим, что метрика каналов назначается на основе выбранных оператором правил, которые могут включать предпотение одних каналов над другими, следовательно, «кратчайший» путь может не быть мерой дальности. Использование кратчайших путей для пересылки трафика может вызывать ряд проблем, указанных ниже.

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

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

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

  1. Поддержка нескольких равноценных путей (Equal-Cost Multipath или ECMP) в SPF IGP позволяет распределять трафик по ряду путей с одинаковой стоимостью. Однако ECMP пытается равномерно распределить трафик между равноценными кратчайшими путями. В общем случае ECMP не поддерживает настраиваемое распределение нагрузки между равноуенными путями. В результате трафик на одном из путей может оказаться значительно выше из-за передачи по нему трафика из других источников и может вызывать перегрузку на этом пути. Некоторое смягмение этой проблемы обеспечивает взвешенный ECMP (Weighted ECMP или WECMP, см., например, [EVPN-UNEQUAL-LB]).

  2. Смена метрики IGP для управления трафиком обычно оказывает влияние на всю сеть, что может приводить к непредвиденным и нежелательным эффектам. Описанная в разделе 8 работа [FT00] [FT01] может улучшить контроль.

С учётом ограничений нужны средства улучшения функций маршрутизации в сетях IP. Некоторые из таких возможностей указаны ниже.

  • Маршрутизация на основе ограничений может быть полезна на общедоступных магистралях IP со сложной топологией. Ограничения могут включать пропускную способность, число пересылок и административные средства, такие как атрибуты классов ресурсов [RFC2702] [RFC2386]. Это позволяет выбирать маршруты, соответствующие заданному набору требований. Маршруты, рассчитанные с учётом ограничений, не обязательно будут кратчайшими. Маршрутизация на основе ограничений лучше всего работает с ориетированными на пути технологиями, поддерживающими явные маршруты, такими как MPLS.

  • Машрутизацию на основе правил можно также применять для распределения трафика по инфраструктуре (в том числе трафика best-effort). Например, проблем, связанных с перегрузками из-за неравномерного распределения трафика, можно избежать (или смягчить их), зная атрибуты возможности резервирования пропускной способности каналов сети и задавая требования к пропускной способности при выборе пути.

  • Ряд усовершенствований IGP на основе состояния каналов позволяет этим протоколам распространять дополнительные сведения о состоянии каналов, требуемые для маршрутизации на основе ограничений. Расширения для OSPF описаны в [RFC3630], для IS-IS – в [RFC5305]. Некоторые добавочные сведения о состоянии топологии включают атрибуты каналов, такие как доступная для резервирования пропускная способность и атрибуты классов ресурсов (задаваемые административно свойства каналов). Концепция атрибутов класса ресурсов введена [RFC2702]. Дополнительные сведения о топологии передаются в новых TLV и суб-TLV для IS-IS [RFC5305] и в Opaque LSA для OSPF [RFC3630].

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

  • В системах TE желательно, чтобы подсистема маршрутизации позволяла настраивать долю трафика для отдельных путей (с одинаковой или разной стоимостью). Это позволит администраторам сетей более гибко контролировать распределение трафика в сетях и может быть очень полезно в определённых ситуациях для предотвращения и смягчения перегрузок. Примеры этого представлены в [XIAO] и [EVPN-UNEQUAL-LB].

  • Системе маршрутизации следует также обеспечивать возможность контроля маршрутов для подмножеств трафика без влияния на маршруты другого трафика при наличии достаточных ресурсов. Это позволит более тонко управлять распределением трафика по сети. Например, возможность переноса трафика с одного пути на другой (не воздействуя на остальные пути трафика) позволяет перенаправить трафик по пути с достаточными ресурсами. Ориентированные на пути технологии, такие как MPLS-TE, по своей природе поддерживают такую возможность, как описано в [AWD2].

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

6.3. Рекомендации по распределению трафика

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

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

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

При зависимости методов распределения трафика от динамической обратной связи, например, адаптивной организации трафика MPLS (MPLS Adaptive Traffic Engineering или MATE) [MATE], требуется уделять особое внимание стабильности сети.

6.4. Рекомендации по измерениям

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

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

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

В статистике трафика следует предоставлять разумные и надёжные показатели текущего состояния сети в краткосрочном масштабе. Некоторые из таких показателей могут отражать загрузку каналов и состояния перегрузки в сети. Примеры индикаторов перегрузки включают чрезмерную задержку пакетов, потери и высокую загрузку ресурсов. Примеры механизмов распространения таких сведений включают SNMP, инструменты зондирования, FTP, анонсы состояния каналов IGP, NETCONF, RESTCONF и т. п.

6.5. Политика, планирование и контроль доступа

Рекомендации параграфов 6.2 и 6.3 могут быть неоптимальными или неэффективными, если объем трафика по маршруту или пути превышает возможности ресурсов на этом маршруте или пути. Для повышения производительности систем TE может применяться несколько подходов.

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

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

  • Контроль допуска к ресурсам – это процесс, в котором узлы сети принимают решение о предоставлении доступа к своим ресурсам на уровне пакетов в соответствии с потоком, к которому пакет относится. Сведения о принадлежности применяются правилами, заданными локально или установленными через систему управления или плоскость управления. В итоге пакет получает доступ к конкретным ресурсам лишь в случае соответствия потока, к которому он относится, заданным правилам.

Для построения эффективной системы TE рекомендуется применять сочетание указанных подходов.

6.6. Живучесть сети

Под живучестью понимается способность сети поддерживать непрерывность обслуживания при возникновении отказов. Это может быть достигнуто путём быстрого восстановления после сбоев и поддержкой после восстановления требуемого уровня QoS для имеющихся служб. Живучесть вызывает серьёзную озабоченность сообщества Internet в связи с необходимостью передачи через Internet критически важного и высокоприоритетного трафика, а также трафика в реальном масштабе времени. Проблему живучести можно решать на уровне устройств путём разработки более надёжных элементов сети или на уровне сети за счёт включения избыточности в архитектуру, проектирование и эксплуатацию сетей. Рекомендуется использовать отказоустойчивость и живучесть в архитектуре, проектировании и эксплуатации систем TE, применяемых для управления сетями IP (особенно общедоступными). Поскольку требования к живучести могут зависеть от контекста, поддержку живучести следует делать гибкой, чтобы её можно было приспособить к разным потребностям. Для обеспечения живучести сетей разработан ряд методов и инструментов, включая быструю перемаршрутизацию MPLS (Fast Reroute) [RFC4090], независимую от топологии быструю перемаршрутизацию по дополнительным путям без петель (Topology Independent Loop-free Alternate Fast Reroute for Segment Routing) [SR-TI-LFA], расширения RSVP-TE для поддержки сквозного [RFC4872] и посегментного [RFC4873] восстановления GMPLS.

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

Возможности защиты и восстановления доступны на разных уровнях, поскольку сетевые технологии продолжают развиваться. Оптические сети способны обеспечивать динамическое восстановление в кольцах и многосвязных (mesh) соединениях на уровне длин волн. На уровне SONET/SDH свойства живучести обеспечиваются автоматическим защитным переключением (Automatic Protection Switching или APS), а также самовосстановлением колец и mesh-соединений. Похожая функциональность обеспечивается технологиями канального уровня, такими как Ethernet.

На уровне IP используется перемаршрутизация для восстановления обслуживания после отключения каналов и узлов. Перемаршрутизация на уровне IP происходит после схождения маршрутов, для чего могут потребоваться секунды и даже минуты. Для повышения живучести сетей IP экономически эффективным способом можно применять основанные на путях технологии, такие как MPLS [RFC3469].

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

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

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

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

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

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

6.6.1. Живучесть сетей на основе MPLS

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

Защита канала

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

Защита узла

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

Защита пути

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

Защита сегмента

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

Более полное описание восстановления на основе MPLS представлено в [RFC3469] и [RFC6372].

6.6.2. Варианты защиты

Ещё одним вопросом, требующим рассмотрения, является концепция опций защиты. Здесь используются обозначения m:n, где m указывает число защитных LSP, применяемых для защиты n рабочих LSP. Во всех вариантах, кроме защиты 1+1, связанные с защитными LSP ресурсы могут использоваться для трафика best-effort, когда на рабочем LSP не наблюдается проблем.

1:1

Один рабочий LSP защищается (восстанавливается) одним защитным LSP. Трафик передаётся по защищаемому LSP пока событие защиты (восстановления) не перенесёт трафик в защитный LSP.

1:n

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

n:1

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

1+1

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

6.7. Многоуровневая организация трафика

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

Многоуровневая организация трафика сопряжена с рядом проблем, связанных с расширяемостью и конфиденциальностью. Эти вопросы рассмотрены в [RFC7926], где обсуждается обобществление сведений между доменами по правилам фильтрации, агрегирования, абстрагирования и виртуализации. В этом документе также обсуждается, какие из имеющихся протоколов могут поддерживать такой сценарий, с особым упором на BGP-LS (см. параграф 5.1.3.10).

PCE (параграф 5.1.3.11) также является полезным инструментом для многоуровневых сетей, как описано в [RFC6805], [RFC8685] и [RFC5623]. Методы сигнализации для многоуровневой организации трафика описаны в [RFC6107].

Живучесть многоуровневых сетей рассмотрена в параграфе 6.6.

6.8. Организация трафика в средах Diffserv

Растущие требования к поддержке множества классов трафика в Internet (например, best-effort и критически важные данные) требуют от сетей IP разделять трафик по некоторым критериям и обеспечивать преимущественную обработку определенным типам трафика. Большое число потоков может объединяться в несколько поведенческих агрегатов на основе критериев, связанных с базовыми требованиями к производительности в плане потери пакетов, задержек и их вариаций, а также с базовыми полями заголовков в пакетах IP.

Дифференцированное обслуживание (Diffserv) [RFC2475] может применяться для соблюдения соглашений SLA, заданных для разделения потоков трафика. Классы обслуживания могут поддерживаться в среде за счёт конкатенации поведения на этапе пересылки (Per-Hop Behavior или PHB) на пути маршрутизации. PHB задаёт поведение пересылки пакетов на поддерживающих Diffserv узлах и может настраиваться на каждом маршрутизаторе. PHB обеспечивается с помощью механизмов управления буферами и планирования, требуя выполнять на входном узле классификацию и маркировку трафика, а также применение правил и формовку (shaping).

TE может дополнять Diffserv для улучшения использования ресурсов сети. TE может работать сразу для всех классов обслуживания [RFC3270] или по отдельным классам. Первый вариант применяется для лучшего распределения нагрузки между ресурсами сети (описание механизмов для этого приведено в [RFC3270]). Второй вариант рассматривается ниже, поскольку он специфичен для среды Diffserv (организация трафика с поддержкой Diffserv [RFC4124]).

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

  • механизмы TE по классам обслуживания, связывающие объем трафика данного класса с выделяемыми этому классу ресурсами;

  • механизмы, динамически регулирующие выделенные данному классу ресурсы в соответствии с объёмом трафика этого класса.

Может оказаться желательным ограничение влияния высокоприоритетного трафика на производительность трафика с более низким приоритетом. Это может быть достигнуто, например, путём контроля доли высокоприоритетного трафика, маршрутизируемого через данный канал. Другим вариантом является соответствующее повышение пропускной способности канала, чтобы трафик с низким приоритетом по-прежнему получал надлежащее обслуживание. Когда доли трафика с разными классами обслуживания существенно меняются от маршрутизатора к маршрутизатору, традиционных протоколов маршрутизации IGP и механизмов TE, не различающих классы обслуживания, может оказаться недостаточно. Взамен может быть желательно выполнение TE по классам обслуживания, особенно для функций управления маршрутизацией и отображения. Одним из вариантов реализации этого в домене с поддержкой MPLS и Diffserv является задание LSP по классам обслуживания и отображение трафика каждого класса на один или несколько таких LSP. Для данного класса обслуживания LSP может маршрутизироваться с поддержкой защиты (восстановления) в зависимости от класса по соответствующим правилам.

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

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

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

Подробное описание требований к TE с поддержкой Diffserv приведено в [RFC4124].

6.9. Управляемость сети

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

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

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

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

7. Междоменное взаимодействие

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

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

Распространение маршрутов

Управление импортом и экспортом маршрутов между AS, а также передачей маршрутов между BGP и другими протоколами внутри AS.

Выбор лучшего пути

Выбор лучшего из имеющихся вариантов пути в данную целевую сеть. Этот выбор осуществляет процесс решения BGP, который определяет точки выхода из данной AS в направлении конкретных целевых сетей с учётом различных факторов и соображений. На процесс выбора пути BGP могут влиять с помощью атрибутов, таких как NEXT_HOP, LOCAL_PREF, AS_PATH, ORIGIN, MULTI_EXIT_DISC (MED), метрика IGP и т. п.

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

При рассмотрении междоменной TE с BGP следует учитывать, что точка выхода трафика является управляемой, тогда как соединительная точка, через которую входит трафик, обычно не управляется. Поэтому каждая отдельная сеть реализует стратегию TE, нацеленную на эффективную доставку трафика, исходящего от её клиентов, к точкам партнёрства (peering). Большинство правил TE основано на стратегии «ближайшего выхода», где междоменный трафик «выгружается» в точку выхода, ближайшую в направлении целевой AS. Большинство методов манипулирования точкой входа трафика неэффективно или неприемлемо в сообществе партнёров.

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

Туннели MPLS-TE (LSP) могут повышать гибкость выбора точек выхода для междоменной маршрутизации за счёт применения концепции абсолютной и относительной метрики. Если атрибуты BGP определены так, что процесс решения BGP зависит от метрики IGP при выборе точек выхода для междоменного трафика, для некого междоменного трафика, адресованного в данную партнерскую сеть, можно сделать конкретную точку выхода предпочтительной путём организации туннеля TE между маршрутизатором, делающим выбор, и его партнёром с назначением туннелю TE метрики, которая меньше стоимости IGP для всех других точек партнёрства. Расширения протокола RSVP-TE для междоменных систем MPLS и GMPLS описаны в [RFC5151].

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

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

8. Обзор современных методов TE в работающих сетях IP

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

Сервис-провайдеры применяют множество описанных в этом документе механизмов TE для оптимизации производительности своих сетей IP, хотя некоторые совсем не используют их. Эти методы включают планирование пропускной способности, в том числе с использованием ECMP, для долгих интервалов, управление маршрутизацией с использованием метрики IGP и MPLS, а также планирование путей и управление ими с использованием MPLS и SR на средних интервалах и механизмы управления трафиком для коротких интервалов.

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

  • Оптимизация производительности работающих сетей обычно представляет собой продолжающийся процесс, в ходе которого в сети постоянно собираются сведения о статистике трафика, параметрах производительности и индикаторах отказов. Эти эмпирические данные анализируются и применяются в качестве триггеров для механизмов TE. Для содействия процессам TE путём анализа сценариев до применения новой конфигурации в работающих сетях могут применяться инструменты прогнозирования «что, если» (what-if).

  • TE внутри домена с использованием IGP выполняется путём увеличения значений метрики OSPF или IS-IS на перегруженных каналах, пока с них не будет снят достаточный объем трафика. Такому подходу присущи некоторые ограничения, отмеченные в параграфе 6.2. Подходы к TE внутри домена [RR94] [FT00] [FT01] [WANG] принимают на входе матрицу трафика, топологию сети и целевые параметры производительности, давая на выходе значения метрики и коэффициенты распределения нагрузки. Эти процессы позволяют более системно внедрять внутри домена TE с использованием IGP.

Администраторы сетей MPLS-TE задают и настраивают атрибуты каналов и ограничения ресурсов, такие как максимальная резервируемая пропускная способность и атрибуты класса ресурсов для каналов в домене. Для распространения сведений о топологии сети и атрибутах каналов всем маршрутизаторам домена служит протокол IGP на основе состояний каналов, поддерживающий расширения TE (IS-IS-TE или OSPF-TE). Администраторы задают LSP, начинающиеся в каждом маршрутизаторе, указывая для каждого LSP целевой узел и атрибуты LSP, указывающие требования, которые должны быть выполнены при выборе пути. Атрибуты могут включать явный путь для LSP или маршрутизатор-источник может использовать локальный процесс маршрутизации на основе ограничений для расчёта пути LSP. Для создания LSP применяется сигнальный протокол RSVP-TE. Задавая для каналов и LSP подходящие значения пропускной способности можно предотвратить или смягчить перегрузки, связанные с неравномерным распределением трафика.

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

Системы сетевого управления и планирования развиваются, принимая на себя большую часть ответственности за определение путей трафика в сетях TE. Это позволяет получить представление о ресурсах в масштабе всей сети и упрощает координацию использования ресурсов для всех потоков трафика в сети. Первоначальные решения с использованием PCE для расчёта пути от имени сетевых маршрутизаторов уступили место подходу на основе архитектуры SDN. PCE с учётом состояний может отслеживать все LSP в сети и распространять их для более эффективного использования доступных ресурсов. Такой элемент PCE может быть частью оркестратора сети, использующего PCEP или иной интерфейс настройки и управления для инструктирования сигнального протокола или непосредственного программирования маршрутизаторов.

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

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

TE между доменами с BGP начинается с размещения партнерских точек соединений, расположенных в непосредственной близости к источникам/получателям трафика и предоставляющих наименее затратные пути через сеть между партнерскими точками и источниками/получателями. Некоторые проблемы принятия решений о местоположении, возникающие в связи с междоменной маршрутизацией, рассмотрены в работе [AWD5].

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

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

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

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

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

  • TE может использовать туннели, слегка помогающие защитить трафик от просмотра, а в некоторых случаях туннели могут использовать шифрование.

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

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

  • TE позволяет направлять трафик в более защищённые каналы и участки сети.

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

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

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

  • трафик можно направить на пути, обеспечивающие качество доставки ниже желаемого;

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

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

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

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

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

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

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

[AFD03] Pan, R., Breslau, L., Prabhakar, B., and S. Shenker, “Approximate fairness through differential dropping”, ACM SIGCOMM Computer Communication Review, Volume 33, Issue 2, Pages 23-39, DOI 10.1145/956981.956985, April 2003, <https://dl.acm.org/doi/10.1145/956981.956985>.

[AJ19] Adekitan, A., Abolade, J., and O. Shobayo, “Data mining approach for predicting the daily Internet data traffic of a smart university”, Journal of Big Data, Volume 6, Number 1, Page 1, DOI 10.1186/s40537-019-0176-5, February 2019, <https://journalofbigdata.springeropen.com/track/pdf/10.1186/s40537-019-0176-5.pdf>.

[ATSSS] 3GPP, “Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture”, Release 16, 3GPP TR 23.793, December 2018, <https://www.3gpp.org/ftp//Specs/archive/23_series/23.793/23793-g00.zip>.

[AWD2] Awduche, D., “MPLS and traffic engineering in IP networks”, IEEE Communications Magazine, Volume 37, Issue 12, Pages 42-47, DOI 10.1109/35.809383, December 1999, <https://ieeexplore.ieee.org/document/809383>.

[AWD5] Awduche, D., “An approach to optimal peering between autonomous systems in the Internet”, Proceedings 7th International Conference on Computer Communications and Networks (Cat. No. 98EX226), DOI 10.1109/ICCCN.1998.998795, October 1998, <https://ieeexplore.ieee.org/document/998795>.

[E.360.1] ITU-T, “Framework for QoS routing and related traffic engineering methods for IP-, ATM-, and TDM-based multiservice networks”, ITU-T Recommendation E.360.1, May 2002, <https://www.itu.int/rec/T-REC-E.360.1-200205-I/en>.

[ENHANCED-VPN] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, “A Framework for NRP-based Enhanced Virtual Private Network”, Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-17, 25 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-17>.

[Err309] RFC Errata, Erratum ID 309, RFC 3272, <https://www.rfc-editor.org/errata/eid309>.

[EVPN-UNEQUAL-LB] Malhotra, N., Ed., Sajassi, A., Rabadan, J., Drake, J., Lingala, A., and S. Thoria, “Weighted Multi-Path Procedures for EVPN Multi-Homing”, Work in Progress, Internet-Draft, draft-ietf-bess-evpn-unequal-lb-21, 7 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-21>.

[FLJA93] Floyd, S. and V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance”, IEEE/ACM Transactions on Networking, Volume 1, Issue 4, Pages 397-413, DOI 10.1109/90.251892, August 1993, <https://www.icir.org/floyd/papers/early.twocolumn.pdf>.

[FT00] Fortz, B. and M. Thorup, “Internet Traffic Engineering by Optimizing OSPF Weights”, Proceedings IEEE INFOCOM 2000, DOI 10.1109/INFCOM.2000.832225, March 2000, <https://www.cs.cornell.edu/courses/cs619/2004fa/documents/ospf_opt.pdf>.

[FT01] Fortz, B. and M. Thorup, “Optimizing OSPF/IS-IS Weights in a Changing World”, IEEE Journal on Selected Areas in Communications, DOI 10.1109/JSAC.2002.1003042, May 2002, <https://ieeexplore.ieee.org/document/1003042>.

[GRPC] gRPC Authors, “gRPC: A high performance, open source universal RPC framework”, <https://grpc.io>.

[KELLY] Kelly, F., “Notes on effective bandwidths”, Oxford University Press, 1996.

[MA] Ma, Q., “Quality-of-Service Routing in Integrated Services Networks”, Ph.D. Dissertation, Carnegie Mellon University, CMU-CS-98-138, January 1998, <https://apps.dtic.mil/sti/pdfs/ADA352299.pdf>.

[MATE] Elwalid, A., Jin, C., Low, S., and I. Widjaja, “MATE: MPLS Adaptive Traffic Engineering”, Proceedings IEEE INFOCOM 2001, Conference on Computer Communications, Twentieth Annual Joint Conference of the IEEE Computer and Communications Society (Cat. No. 01CH37213), DOI 10.1109/INFCOM.2001.916625, August 2002, <https://www.yumpu.com/en/document/view/35140398/mate-mpls-adaptive-traffic-engineering-infocom-ieee-xplore/8>.

[MR99] Mitra, D. and K.G. Ramakrishnan, “A case study of multiservice, multipriority traffic engineering design for data networks”, Seamless Interconnection for Universal Services, Global Telecommunications Conference, GLOBECOM’99, (Cat. No. 99CH37042), DOI 10.1109/GLOCOM.1999.830281, December 1999, <https://ieeexplore.ieee.org/document/830281>.

[MULTIPATH-DCCP] Amend, M., Ed., Brunstrom, A., Kassler, A., Rakocevic, V., and S. Johnson, “DCCP Extensions for Multipath Operation with Multiple Addresses”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-multipath-dccp-11, 12 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-multipath-dccp-11>.

[NETWORK-SLICES] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, “A Framework for Network Slices in Networks Built from IETF Technologies”, Work in Progress7, Internet-Draft, draft-ietf-teas-ietf-network-slices-25, 14 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-25>.

[PERFORMANCE-ROUTING] Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. Jacquenet, “Performance-based BGP Routing Mechanism”, Work in Progress, Internet-Draft, draft-ietf-idr-performance-routing-03, 22 December 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-03>.

[QUIC-MULTIPATH] Liu, Y., Ed., Ma, Y., Ed., De Coninck, Q., Ed., Bonaventure, O., Huitema, C., and M. Kühlewind, Ed., “Multipath Extension for QUIC”, Work in Progress, Internet-Draft, draft-ietf-quic-multipath-06, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-06>.

[RFC0791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC1102] Clark, D., “Policy routing in Internet protocols”, RFC 1102, DOI 10.17487/RFC1102, May 1989, <https://www.rfc-editor.org/info/rfc1102>.

[RFC1104] Braun, H., “Models of policy based routing”, RFC 1104, DOI 10.17487/RFC1104, June 1989, <https://www.rfc-editor.org/info/rfc1104>.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification”, RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, “A Framework for QoS-based Routing in the Internet”, RFC 2386, DOI 10.17487/RFC2386, August 1998, <https://www.rfc-editor.org/info/rfc2386>.

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

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group”, RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>.

[RFC2678] Mahdavi, J. and V. Paxson, “IPPM Metrics for Measuring Connectivity”, RFC 2678, DOI 10.17487/RFC2678, September 1999, <https://www.rfc-editor.org/info/rfc2678>.

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, “Requirements for Traffic Engineering Over MPLS”, RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.

[RFC2722] Brownlee, N., Mills, C., and G. Ruth, “Traffic Flow Measurement: Architecture”, RFC 2722, DOI 10.17487/RFC2722, October 1999, <https://www.rfc-editor.org/info/rfc2722>.

[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, “A Framework for Policy-based Admission Control”, RFC 2753, DOI 10.17487/RFC2753, January 2000, <https://www.rfc-editor.org/info/rfc2753>.

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, “RSVP Refresh Overhead Reduction Extensions”, RFC 2961, DOI 10.17487/RFC2961, April 2001, <https://www.rfc-editor.org/info/rfc2961>.

[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, “A Framework for Integrated Services Operation over Diffserv Networks”, RFC 2998, DOI 10.17487/RFC2998, November 2000, <https://www.rfc-editor.org/info/rfc2998>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture”, RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC3086] Nichols, K. and B. Carpenter, “Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification”, RFC 3086, DOI 10.17487/RFC3086, April 2001, <https://www.rfc-editor.org/info/rfc3086>.

[RFC3124] Balakrishnan, H. and S. Seshan, “The Congestion Manager”, RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.

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

[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations”, RFC 3175, DOI 10.17487/RFC3175, September 2001, <https://www.rfc-editor.org/info/rfc3175>.

[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, “Terminology for Policy-Based Management”, RFC 3198, DOI 10.17487/RFC3198, November 2001, <https://www.rfc-editor.org/info/rfc3198>.

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

[RFC3270] Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services”, RFC 3270, DOI 10.17487/RFC3270, May 2002, <https://www.rfc-editor.org/info/rfc3270>.

[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, “Overview and Principles of Internet Traffic Engineering”, RFC 3272, DOI 10.17487/RFC3272, May 2002, <https://www.rfc-editor.org/info/rfc3272>.

[RFC3469] Sharma, V., Ed. and F. Hellstrand, Ed., “Framework for Multi-Protocol Label Switching (MPLS)-based Recovery”, RFC 3469, DOI 10.17487/RFC3469, February 2003, <https://www.rfc-editor.org/info/rfc3469>.

[RFC3473] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

[RFC3945] Mannie, E., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture”, RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., “Fast Reroute Extensions to RSVP-TE for LSP Tunnels”, RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.

[RFC4124] Le Faucheur, F., Ed., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering”, RFC 4124, DOI 10.17487/RFC4124, June 2005, <https://www.rfc-editor.org/info/rfc4124>.

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.

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

[RFC4461] Yasukawa, S., Ed., “Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)”, RFC 4461, DOI 10.17487/RFC4461, April 2006, <https://www.rfc-editor.org/info/rfc4461>.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes”, RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, “A Path Computation Element (PCE)-Based Architecture”, RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.

[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery”, RFC 4872, DOI 10.17487/RFC4872, May 2007, <https://www.rfc-editor.org/info/rfc4872>.

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, “GMPLS Segment Recovery”, RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.

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

[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, “Inter-Domain MPLS and GMPLS Traffic Engineering — Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 5151, DOI 10.17487/RFC5151, February 2008, <https://www.rfc-editor.org/info/rfc5151>.

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, “The OSPF Opaque LSA Option”, RFC 5250, DOI 10.17487/RFC5250, July 2008, <https://www.rfc-editor.org/info/rfc5250>.

[RFC5305] Li, T. and H. Smit, “IS-IS Extensions for Traffic Engineering”, RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., “Traffic Engineering Extensions to OSPF Version 3”, RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, “MPLS Upstream Label Assignment and Context-Specific Label Space”, RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, “Policy-Enabled Path Computation Framework”, RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>.

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., “Path Computation Element (PCE) Communication Protocol (PCEP)”, RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.

[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, “Architecture for IP Flow Information Export”, RFC 5470, DOI 10.17487/RFC5470, March 2009, <https://www.rfc-editor.org/info/rfc5470>.

[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, “IP Flow Information Export (IPFIX) Applicability”, RFC 5472, DOI 10.17487/RFC5472, March 2009, <https://www.rfc-editor.org/info/rfc5472>.

[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, “Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)”, RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.

[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, “Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization”, RFC 5557, DOI 10.17487/RFC5557, July 2009, <https://www.rfc-editor.org/info/rfc5557>.

[RFC5559] Eardley, P., Ed., “Pre-Congestion Notification (PCN) Architecture”, RFC 5559, DOI 10.17487/RFC5559, June 2009, <https://www.rfc-editor.org/info/rfc5559>.

[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, “Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering”, RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.

[RFC5664] Halevy, B., Welch, B., and J. Zelenka, “Object-Based Parallel NFS (pNFS) Operations”, RFC 5664, DOI 10.17487/RFC5664, January 2010, <https://www.rfc-editor.org/info/rfc5664>.

[RFC5671] Yasukawa, S. and A. Farrel, Ed., “Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)”, RFC 5671, DOI 10.17487/RFC5671, October 2009, <https://www.rfc-editor.org/info/rfc5671>.

[RFC5693] Seedorf, J. and E. Burger, “Application-Layer Traffic Optimization (ALTO) Problem Statement”, RFC 5693, DOI 10.17487/RFC5693, October 2009, <https://www.rfc-editor.org/info/rfc5693>.

[RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., “Procedures for Dynamically Signaled Hierarchical Label Switched Paths”, RFC 6107, DOI 10.17487/RFC6107, February 2011, <https://www.rfc-editor.org/info/rfc6107>.

[RFC6119] Harrison, J., Berger, J., and M. Bartlett, “IPv6 Traffic Engineering in IS-IS”, RFC 6119, DOI 10.17487/RFC6119, February 2011, <https://www.rfc-editor.org/info/rfc6119>.

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

[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., “MPLS Transport Profile (MPLS-TP) Survivability Framework”, RFC 6372, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-editor.org/info/rfc6372>.

[RFC6374] Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for MPLS Networks”, RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.

[RFC6601] Ash, G., Ed. and D. McDysan, “Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks”, RFC 6601, DOI 10.17487/RFC6601, April 2012, <https://www.rfc-editor.org/info/rfc6601>.

[RFC6805] King, D., Ed. and A. Farrel, Ed., “The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS”, RFC 6805, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information”, STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7149] Boucadair, M. and C. Jacquenet, “Software-Defined Networking: A Perspective from within a Service Provider Environment”, RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, “Application-Layer Traffic Optimization (ALTO) Protocol”, RFC 7285, DOI 10.17487/RFC7285, September 2014, <https://www.rfc-editor.org/info/rfc7285>.

[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., “Group Communication for the Constrained Application Protocol (CoAP)”, RFC 7390, DOI 10.17487/RFC7390, October 2014, <https://www.rfc-editor.org/info/rfc7390>.

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

[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, “OSPF Traffic Engineering (TE) Metric Extensions”, RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.

[RFC7491] King, D. and A. Farrel, “A PCE-Based Architecture for Application-Based Network Operations”, RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.

[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., “RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)”, RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., “IETF Recommendations Regarding Active Queue Management”, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., “Service Function Chaining (SFC) Architecture”, RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.

[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Delay Metric for IP Performance Metrics (IPPM)”, STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.

[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., “A One-Way Loss Metric for IP Performance Metrics (IPPM)”, STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.

[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, “Requirements for Subscription to YANG Datastores”, RFC 7923, DOI 10.17487/RFC7923, June 2016, <https://www.rfc-editor.org/info/rfc7923>.

[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, “Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks”, BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.

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

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, “Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem”, RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8034] White, G. and R. Pan, “Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems”, RFC 8034, DOI 10.17487/RFC8034, February 2017, <https://www.rfc-editor.org/info/rfc8034>.

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

[RFC8051] Zhang, X., Ed. and I. Minei, Ed., “Applicability of a Stateful Path Computation Element (PCE)”, RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.

[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, “Multi-Cost Application-Layer Traffic Optimization (ALTO)”, RFC 8189, DOI 10.17487/RFC8189, October 2017, <https://www.rfc-editor.org/info/rfc8189>.

[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, “Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE”, RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.

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

[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, “Multicast Using Bit Index Explicit Replication (BIER)”, RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.

[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, “Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model”, RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.

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

[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, “The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm”, RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.

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

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., “Framework for Abstraction and Control of TE Networks (ACTN)”, RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, “IS-IS Traffic Engineering (TE) Metric Extensions”, RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, “BGP – Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions”, RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.

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

[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, “Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing”, RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.

[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, “TCP Extensions for Multipath Operation with Multiple Addresses”, RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.

[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, “Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture”, RFC 8685, DOI 10.17487/RFC8685, December 2019, <https://www.rfc-editor.org/info/rfc8685>.

[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, “YANG Data Model for Traffic Engineering (TE) Topologies”, RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/info/rfc8795>.

[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., Seo, S., and B. Hesmans, “0-RTT TCP Convert Protocol”, RFC 8803, DOI 10.17487/RFC8803, July 2020, <https://www.rfc-editor.org/info/rfc8803>.

[RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N. Schwan, “Application-Layer Traffic Optimization (ALTO) Cost Calendar”, RFC 8896, DOI 10.17487/RFC8896, November 2020, <https://www.rfc-editor.org/info/rfc8896>.

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

[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, “Dissemination of Flow Specification Rules”, RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.

[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, “Simple Two-Way Active Measurement Protocol Optional Extensions”, RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.

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

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

[RFC9040] Touch, J., Welzl, M., and S. Islam, “TCP Control Block Interdependence”, RFC 9040, DOI 10.17487/RFC9040, July 2021, <https://www.rfc-editor.org/info/rfc9040>.

[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, “Tree Engineering for Bit Index Explicit Replication (BIER-TE)”, RFC 9262, DOI 10.17487/RFC9262, October 2022, <https://www.rfc-editor.org/info/rfc9262>.

[RFC9298] Schinazi, D., “Proxying UDP in HTTP”, RFC 9298, DOI 10.17487/RFC9298, August 2022, <https://www.rfc-editor.org/info/rfc9298>.

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

[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, “Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)”, RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.

[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, “IGP Flexible Algorithm”, RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.

[RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and L. Contreras, “Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics”, RFC 9439, DOI 10.17487/RFC9439, August 2023, <https://www.rfc-editor.org/info/rfc9439>.

[RFC9502] Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, R., and P. Psenak, “IGP Flexible Algorithm in IP Networks”, RFC 9502, DOI 10.17487/RFC9502, November 2023, <https://www.rfc-editor.org/info/rfc9502>.

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

[RR94] Rodrigues, M. and K.G. Ramakrishnan, “Optimal routing in shortest-path data networks”, Bell Labs Technical Journal, Volume 6, Issue 1, Pages 117-138, DOI 10.1002/bltj.2267, August 2002, <https://onlinelibrary.wiley.com/doi/abs/10.1002/bltj.2267>.

[SLDC98] Suter, B., Lakshman, T.V., Stiliadis, D., and A.K. Choudhury, “Design considerations for supporting TCP with per-flow queueing”, Proceedings IEEE INFOCOM ’98, DOI 10.1109/INFCOM.1998.659666, April 1998, <https://ieeexplore.ieee.org/document/659666>.

[SR-TE-POLICY] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, “Advertising Segment Routing Policies in BGP”, Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-26, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26>.

[SR-TI-LFA] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, “Topology Independent Fast Reroute using Segment Routing”, Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-13, 16 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-13>.

[TE-QoS-ROUTING] Ash, G., “Traffic Engineering & QoS Methods for IP-, ATM-, & Based Multiservice Networks”, Work in Progress, Internet-Draft, draft-ietf-tewg-qos-routing-04, October 2001, <https://datatracker.ietf.org/doc/html/draft-ietf-tewg-qos-routing-04>.

[WANG] Wang, Y., Wang, Z., and L. Zhang, “Internet traffic engineering without full mesh overlaying”, Proceedings IEEE INFOCOM 2001, DOI 10.1109/INFCOM.2001.916782, April 2001, <https://ieeexplore.ieee.org/document/916782>.

[XIAO] Xiao, X., Hannan, A., Bailey, B., and L. Ni, “Traffic Engineering with MPLS in the Internet”, IEEE Network, Volume 14, Issue 2, Pages 28-33, DOI 10.1109/65.826369, March 2000, <https://courses.cs.washington.edu/courses/cse561/02au/papers/xiao-mpls-net00.pdf>.

[YARE95] Yang, C. and A. Reddy, “A Taxonomy for Congestion Control Algorithms in Packet Switching Networks”, IEEE Network, Pages 34-45, DOI 10.1109/65.397042, August 1995, <https://ieeexplore.ieee.org/document/397042>.

Приложение A. Отличия от RFC 3272

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

A.1. RFC 3272

  • Раздел 1.0 (Введение) отредактирован в разделе 1.

    • Параграф 1.1 (Что такое Internet TE?) отредактирован в параграфе 1.1.

    • Параграф 1.2 (Область действия) перенесён в параграф 1.3.

    • Параграф 1.3 (Терминология) перенесён в параграф 1.4 с удалением некоторых устаревших терминов и незначительным редактированием.

  • Раздел 2.0 (Основы) сохранен как раздел 2 с удалением части текста.

    • Параграф 2.1 (Контекст Internet TE) сохранен как параграф 2.1.

    • Параграф 2.2 (Контекст сети) переписан как параграф 2.2.

    • Параграф 2.3 (Контекст задачи) переписан как параграф 2.3.

      • Параграф 2.3.1 (Перегрузки и их последствия) сохранен как параграф 2.3.1.

    • Параграф 2.4 (Контекст решения) отредактирован как параграф 2.4.

      • Параграф 2.4.1 (Борьба с перегрузками) переформатирован как параграф 2.4.1.

    • Параграф 2.5 (Контекст реализации и применения) сохранен как параграф 2.5.

  • Раздел 3.0 (Модель процесса TE) сохранен как раздел 3.

    • Параграф 3.1 (Компоненты модели процесса TE) сохранен как параграф 3.1.

    • Параграф 3.2 (Измерения) объединён с параграфом 3.1.

    • Параграф 3.3 (Моделирование, анализ и имитация) объединён с параграфом 3.1.

    • Параграф 3.4 (Оптимизация) объединён с параграфом 3.1.

  • Раздел 4.0 (Исторический обзор и дальнейшее развитие) сохранен как раздел 5 с удалением исторических аспектов.

    • Параграф 4.1 (TE в классических телефонных сетях) удалён.

    • Параграф 4.2 (Эволюция TE в Internet) удалён.

    • Параграф 4.3 (Модель наложения) удалён.

    • Параграф 4.4 (Маршрутизация на основе ограничений) сохранен как параграф 5.1.3.1, но перемещён в параграф 5.1.

    • Параграф 4.5 (Обзор других проектов IETF, связанных с TE) сохранен как параграф 5.1 с добавлением новых подпараграфов.

      • Параграф 4.5.1 (Интегрированные услуги) сохранен как параграф 5.1.1.1.

      • Параграф 4.5.2 (RSVP) сохранен как параграф 5.1.3.2 с некоторым редактированием.

      • Параграф 4.5.3 (Дифференцированные услуги) сохранен как параграф 5.1.1.2.

      • Параграф 4.5.4 (MPLS) сохранен как параграф 5.1.3.3.

      • Параграф 4.5.5 (Показатели производительности IP) сохранен как параграф 5.1.3.6.

      • Параграф 4.5.6 (Измерение потоков) сохранен как параграф 5.1.3.7 с некоторым переформатированием.

      • Параграф 4.5.7 (Контроль перегрузок конечных точек) сохранен как параграф 5.1.3.8.

    • Параграф 4.6 (Обзор действий ITU, связанных с TE) удалён.

    • Параграф 4.7 (Распространение содержимого) сохранен как параграф 5.2.

  • Раздел 5.0 (Таксономия систем TE) сохранен как раздел 4.

    • Параграф 5.1 (Управление в зависимости от времени и состояния) сохранен как параграф 4.1.

    • Параграф 5.2 (Автономные и интерактивные системы) сохранен как параграф 4.2.

    • Параграф 5.3 (Централизованные и распределенные системы) сохранен как параграф 4.3 с дополнениями.

    • Параграф 5.4 (Локальные и глобальные сведения) сохранен как параграф 4.4.

    • Параграф 5.5 (Предписывающие о описательные системы) сохранен как параграф 4.5 с дополнениями.

    • Параграф 5.6 (Системы с открытым и закрытым контуром) сохранен как параграф 4.6.

    • Параграф 5.7 (Тактические и стратегические системы) сохранен как параграф 4.7.

  • Раздел 6.0 (Рекомендации для Internet TE) сохранен как раздел 6.

    • Параграф 6.1 (Базовые нефункциональные рекомендации) сохранен как параграф 6.1.

    • Параграф 6.2 (Рекомендации по маршрутизации) сохранен как параграф 6.2 с редактированием.

    • Параграф 6.3 (Рекомендации по отображению трафика) сохранен как параграф 6.3.

    • Параграф 6.4 (Рекомендации по измерениям) сохранен как параграф 6.4.

    • Параграф 6.5 (Живучесть сети) сохранен как параграф 6.6.

      • Параграф 6.5.1 (Живучесть сети на основе MPLS) сохранен как параграф 6.6.1.

      • Параграф 6.5.2 (Варианты защиты) сохранен как параграф 6.6.2.

    • Параграф 6.6 (TE в среде Diffserv) сохранен как параграф 6.8 с редактированием.

    • Параграф 6.7 (Управляемость сети) сохранен как параграф 6.9.

  • Раздел 7.0 (Междоменное взаимодействие) сохранен как раздел 7.

  • Раздел 8.0 (Обзор современной практики TE в работающих сетях IP) сохранен как раздел 8.

  • Раздел 9.0 (Заключение) удалён.

  • Раздел 10.0 (Вопросы безопасности) сохранен как раздел 9 с существенным добавлением текста.

A.2. Этот документ

  • Раздел 1 основан на разделе 1 из [RFC3272].

    • Параграф 1.1 основан на параграфе 1.1 из [RFC3272].

    • Параграф 1.2 написан заново.

    • Параграф 1.3 основан на параграфе 1.2 из [RFC3272].

    • Параграф 1.4 основан на параграфе 1.3 из [RFC3272].

  • Раздел 2 основан на разделе 2 из [RFC3272].

    • Параграф 2.1 основан на параграфе 2.1 из [RFC3272].

    • Параграф 2.2 основан на параграфе 2.2 из [RFC3272].

    • Параграф 2.3 основан на параграфе 2.3 из [RFC3272].

      • Параграф 2.3.1 основан на параграфе 2.3.1 из [RFC3272].

    • Параграф 2.4 основан на параграфе 2.4 из [RFC3272].

      • Параграф 2.4.1 основан на параграфе 2.4.1 из [RFC3272].

    • Параграф 2.5 основан на параграфе 2.5 из [RFC3272].

  • Раздел 3 основан на разделе 3 из [RFC3272].

    • Параграф 3.1 основан на параграфах 3.1, 3.2, 3.3, 3.4 из [RFC3272].

  • Раздел 4 основан на разделе 5 из [RFC3272].

    • Параграф 4.1 основан на параграфе 5.1 из [RFC3272].

    • Параграф 4.2 основан на параграфе 5.2 из [RFC3272].

    • Параграф 4.3 основан на параграфе 5.3 из [RFC3272].

      • Параграф 4.3.1 написан заново.

      • Параграф 4.3.2 написан заново.

    • Параграф 4.4 основан на параграфе 5.4 из [RFC3272].

    • Параграф 4.5 основан на параграфе 5.5 из [RFC3272].

      • Параграф 4.5.1 написан заново.

    • Параграф 4.6 основан на параграфе 5.6 из [RFC3272].

    • Параграф 4.7 основан на параграфе 5.7 из [RFC3272].

  • Раздел 5 основан на разделе 4 из [RFC3272].

    • Параграф 5.1 основан на параграфе 4.5 из [RFC3272].

      • Параграф 5.1.1.1 основан на параграфе 4.5.1 из [RFC3272].

      • Параграф 5.1.1.2 основан на параграфе 4.5.3 из [RFC3272].

      • Параграф 5.1.1.3 написан заново.

      • Параграф 5.1.1.4 написан заново.

      • Параграф 5.1.1.5 написан заново.

      • Параграф 5.1.2.1 написан заново.

      • Параграф 5.1.2.2 написан заново.

      • Параграф 5.1.2.3 написан заново.

      • Параграф 5.1.3.1 основан на параграфе 4.4 из [RFC3272].

        • Параграф 5.1.3.1.1 написан заново.

      • Параграф 5.1.3.2 основан на параграфе 4.5.2 из [RFC3272].

      • Параграф 5.1.3.3 основан на параграфе 4.5.4 из [RFC3272].

      • Параграф 5.1.3.4 написан заново.

      • Параграф 5.1.3.5 написан заново.

      • Параграф 5.1.3.6 основан на параграфе 4.5.5 из [RFC3272].

      • Параграф 5.1.3.7 основан на параграфе 4.5.6 из [RFC3272].

      • Параграф 5.1.3.8 основан на параграфе 4.5.7 из [RFC3272].

      • Параграф 5.1.3.9 написан заново.

      • Параграф 5.1.3.10 написан заново.

      • Параграф 5.1.3.11 написан заново.

      • Параграф 5.1.3.12 написан заново.

      • Параграф 5.1.3.13 написан заново.

      • Параграф 5.1.3.14 написан заново.

      • Параграф 5.1.3.15 написан заново.

    • Параграф 5.2 основан на параграфе 4.7 из [RFC3272].

  • Раздел 6 основан на разделе 6 из [RFC3272].

    • Параграф 6.1 основан на параграфе 6.1 из [RFC3272].

    • Параграф 6.2 основан на параграфе 6.2 из [RFC3272].

    • Параграф 6.3 основан на параграфе 6.3 из [RFC3272].

    • Параграф 6.4 основан на параграфе 6.4 из [RFC3272].

    • Параграф 6.5 написан заново.

    • Параграф 6.6 основан на параграфе 6.5 из [RFC3272].

      • Параграф 6.6.1 основан на параграфе 6.5.1 из [RFC3272].

      • Параграф 6.6.2 основан на параграфе 6.5.2 из [RFC3272].

    • Параграф 6.7 написан заново.

    • Параграф 6.8 основан на параграфе 6.6 из [RFC3272].

    • Параграф 6.9 основан на параграфе 6.7 из [RFC3272].

  • Раздел 7 основан на разделе 7 из [RFC3272].

  • Раздел 8 основан на разделе 8 из [RFC3272].

  • Раздел 9 основан на разделе 10 из [RFC3272].

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

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

Daniel O. Awduche
Movaz Networks
 
Angela Chiu
Celion Networks
 
Anwar Elwalid
Lucent Technologies
 
Indra Widjaja
Bell Labs, Lucent Technologies
 
XiPeng Xiao
Redback Networks

Ниже приведён раздел благодарностей из [RFC3272]. Всем, кто помог в создании этого документа, нужно поблагодарить за вклад в новый документ.

Авторы благодарны Jim Boyle за вклад в раздел рекомендаций, Francois Le Faucheur – за вклад об аспектах Diffserv, Blaine Christian – за вклад по измерениям, Gerald Ash – за вклад по маршрутизации в телефонных сетях и текст о методах TE по событиям, Steven Wright – за вклад по управляемости сети, Jonathan Aufderheide – за вклад по междоменному TE с BGP. Отдельная благодарность Randy Bush за предложение таксономии TE на основе сравнения тактических и стратегических методов. Параграф, описывающий действия ITU, связанные с TE был создан на основе предложений Waisum Lai. Полезные отклики и ссылки на соответствующие материалы были предоставлены J. Noel Chiappa. Дополнительные комментарии предоставил Glenn Grotefeld во время рабочих встреч процесса last call. Кроме того, авторы благодарны Ed Kern, сопредседателю TEWG, за комментарии и поддержку.

Ранние черновые варианты этого документа были подготовлены командой разработчиков RFC3272bis в рамках рабочей группы TEAS. Полный список членов команды приведён ниже.

Acee Lindem
Adrian Farrel
Aijun Wang
Daniele Ceccarelli
Dieter Beller
Jeff Tantsura
Julien Meuric
Liu Hua
Loa Andersson
Luis Miguel Contreras
Martin Horneffer
Tarek Saad
Xufeng Liu

Этот документ содержит исправление оригинального текста, отмеченное в информации об ошибке [Err309] от Jean-Michel Grimaldi.

Редактор документа благодарит также Dhruv Dhody, Gyan Mishra, Joel Halpern, Dave Taht, John Scudder, Rich Salz, Behcet Sarikaya, Bob Briscoe, Erik Kline, Jim Guichard, Martin Duke, Roman Danyliw за рецензии.

Эта работа частично поддерживалась Европейской комиссией в рамках гранта Horizon 2020 по соглашению 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow).

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

Ниже указаны люди, внёсшие существенный вклад в этот документ.

Gert Grammel
Email: ggrammel@juniper.net
 
Loa Andersson
Email: loa@pi.nu
 
Xufeng Liu
Email: xufeng.liu.ietf@gmail.com
 
Lou Berger
Email: lberger@labn.net
 
Jeff Tantsura
Email: jefftant.ietf@gmail.com
 
Daniel King
Email: daniel@olddog.co.uk
 
Boris Hassanov
Email: bhassanov@yandex-team.ru
 
Kiran Makhijani
Email: kiranm@futurewei.com
 
Dhruv Dhody
Email: dhruv.ietf@gmail.com
 
Mohamed Boucadair
Email: mohamed.boucadair@orange.com

Адрес автора

Adrian Farrel (editor)
Old Dog Consulting
Email: adrian@olddog.co.uk

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

nmalykh@protokols.ru


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

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

3Synchronous Optical Network / Synchronous Digital Hierarchy – синхронная оптическая сеть / синхронная цифровая иерархия.

4Plesiochronous Digital Hierarchy – плезиохронная цифровая иерархия.

5Optical Transport Network – оптическая транспортная сеть.

6Realtime Traffic Flow Measurement – измерение потоков трафика в реальном масштабе времени. Прим. перев.

7Опубликовано в RFC 9543. Прим. перев.

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

RFC 9518 Centralization, Decentralization, and Internet Standards

Independent Submission                                     M. Nottingham
Request for Comments: 9518                                 December 2023
Category: Informational                                                 
ISSN: 2070-1721

Centralization, Decentralization, and Internet Standards

Централизация, децентрализация и стандарты Internet

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

Хотя сохранение такого состояния остаётся широко поддерживаемой целью, согласованное сохранение во всем спектре услуг и прложений, который люди воспринимают как Internet, оказалось труднодостижимым. Если ранние службы, такие как сетевые новости (Network News Transfer Protocol или NNTP) и электронная почта, имели множество взаимодействующих провайдеров, то многие современные платформы для содержимого и услуг управляются одной коммерческой структурой без какого-либо совместимого варианта. Некоторые из них стали настолько распространёнными и важными, что многие стали считать их синонимом Internet [Komaitis].

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

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

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

В разделе 2 приведено определение централизации и разъяснено, почему она зачастую нежелательна, и рассмотрены проявления централизации в Internet. В разделе 3 рассматривается децентрализация и выделены некоторые стратегии и их ограничения. Раздел 4 рассматривается роль стандартов Internet в контроле централизации, а раздел 5 посвящён будущим направлениям работы.

2. Централизация

В этом документе централизацией называется положение дел, когда один субъект или небольшая группа может монопольно (исключительно) наблюдать, фиксировать (capture), контролировать или получать ренту от работы или использования функций Internet. Субъектом (entity) в данном случае может быть один человек, группа или корпорация. ACK organization might be subject to governance that mitigates centralization risk (see Section 3.1.3), but that organization is still a centralizing entity.

Термин «функция Internet» применяется в этом документе в широком смысле. В самом прямом смысле это может used broadly in this document. Most directly, it might be an enabling protocol already defined by standards, such as IP [RFC791], BGP [RFC4271], TCP [RFC9293], or HTTP [HTTP]. It might also be a proposal for a new enabling protocol or an extension to an existing one.

Because people’s experience of the Internet are not limited to standards-defined protocols and applications, this document also considers centralization in functions built on top of standards — for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking equipment, hardware, operating systems, and software that act as enabling technologies for the Internet can also impact centralization. The supply of Internet connectivity to end users in a particular area or situation can exhibit centralization, as can the supply of transit between networks (so called “Tier 1” networks).

This definition of centralization does not capture all types of centralization. Notably, technical centralization (for example, where a machine or network link is a single point of failure) is relatively well understood by engineers; it can be mitigated, typically by distributing a function across multiple components. As we will see, such techniques might address that type of centralization while failing to prevent control of the function falling into few hands. A failure because of a cut cable, power outage, or failed server is well understood by the technical community but is qualitatively different from the issues encountered when a core Internet function has a gatekeeper.

Likewise, political centralization (for example, where a country is able to control how a function is supplied across the whole Internet) is equally concerning but is not considered in depth here.

Even when centralization is not currently present in a function, some conditions make it more likely that centralization will emerge in the future. This document uses “centralization risk” to characterize that possibility.

2.1. Централизация может быть вредной

Многие инженеры, участвующие в разработке стандартов Internet, стремятся предотвратить централизацию и противодействовать ей, поскольку считают централизацию несовместимой с историей и архитектурой Internet. Будучи «большим разнородным набором соединённых сетей» [BCP95], Internet часто характеризуется как «сеть сетей», где операторы выступают как партнёры (peer), согласные упростить взаимодействие, а не исполнители чужой воли. Такая ориентация на независимость превалирует в устройстве Internet, например, в виде концепции автономных систем.

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

Power Imbalance – дисбаланс власти

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

Limits on Innovation – ограничения для инноваций

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

Constraints on Competition – ограничения для конкуренции

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

Reduced Availability – снижение доступности

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

Monoculture – монокультура

Зона действия (масштабы) централизованного провайдера может повышать роль незначительных недостатков в функциях до такой степени, что они будут приводить к серьёзным последствиям. Например, единая база кодов для маршрутизации повышает влияние ошибок и уязвимостей, а один алгоритм рекомендаций для содержимого может иметь серьёзные социальные последствия. Разнообразие реализаций функций ведёт к росту устойчивости при системном рассмотрении, поскольку «прогресс – это результат эволюционного процесса проб и ошибок множества свободно взаимодействующих между собой агентов» [Aligia].

Self-Reinforcement – самоусиление

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

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

Это противоречие можно наблюдать в таких областях, как облачные технологии и мобильный доступ в Internet. Если популярный провайдер облачного хостинга становится недоступным (по техническим или иным причинам), работа многих пользователей Internet может быть нарушена (особенно при наличии множества зависимостей у современных web-сайтов, см. [Kashaf]). У крупного поставщика услуг доступа в Internet может возникнуть отказ, затрагивающий сотни тысяч пользователей (и более) точно так же, как ранее проблемы у крупных телефонных компаний приводили к масштабным отключениям [PHONE]. В обоих случаях услуги не являются технически централизованными и у операторов имеются серьёзные стимулы для резервирования и применения различных средств снижения риска отказа одного компонента. Однако в целом операторы полагаются на единую базу кода, ограниченный набор оборудования, единую плоскость управления и все они могут стать причиной широкомасштабных отказов.

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

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

2.2. Централизация может быть полезной

Перечисленные выше вредные последствия централизации широко известны. Менее изучена зависимость функциональности некоторых протоколов и приложений от централизации. Централизация зачастую обусловлена технической необходимостью. Например, единый глобально координируемый «корень доверия» (source of truth) является централизованным по своей природе. Примером является корневая зона системы доменных имён (Domain Name System или DNS), которая позволяет преобразовывать понятные человеку имена в сетевые адреса согласованным в глобальном масштабе способом.

Другим примером является распределение адресов IP. Для маршрутизации Internet требуется распределение уникальных адресов, но если одно правительство или компания захватит управление распределением адресов, вся сеть Internet окажется под угрозой злоупотреблений со стороны этой организации. Модель доверия в Web требует наличия удостоверяющего центра (Certificate Authority или CA) в качестве корня доверия при обмене данными между браузерами и серверами, что влечёт за собой риск централизации, который нужно учитывать при создании системы.

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

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

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

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

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

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

3. Децентрализация

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

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

Первая и наиболее важная проблема связана с тем, что технические меры децентрализации в лучшем случае имеют ограниченное влияние не нетехнические формы централизации. Согласно [Schneider1], «децентрализованная технология сама по себе не гарантирует децентрализованных результатов». Как показано ниже в параграфе 3.1, технические меры лучше считать необходимыми, не недостаточными для полной децентрализации функции.

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

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

В-четвёртых, у разных сторон могут быть добросовестные разногласия в части понимания достаточности децентрализации, основанные на убеждениях, представлениях и целях. Как централизация, так и децентрализация не являются дискретными процессами (континуум) и не все согласны с определением «верного» уровня или типа, а также соотнесением разных форм централизации друг с другом или архитектурными целями (например, безопасностью и приватностью). Эти противоречия можно проследить на примере DNS. Хотя некоторые аспекты системы децентрализованы (например, распределение функции поиска между локальными серверами, которые пользователь может задавать), основным аспектом централизации DNS является работа системы в качестве пространства имён – единой глобальной «точки доверия» с присущей (хотя и выгодной) централизацией управления. ICANN смягчает связанные с этим риски за счёт управления с участием множества заинтересованных сторон (см. параграф 3.1.3). Хотя многие считают такой механизм достаточным и даже обладающим желаемыми качествами (например, возможность навязывать стандарты сообщества в части работы пространства имён), другие отвергают надзор ICANN за DNS как незаконный, отдавая предпочтение децентрализации на основе протоколов распределенного согласия перед управлением людьми [Musiani].

В-пятых, децентрализация неизбежно влечёт за собой корректировку властных отношений между участниками протокола, особенно при появлении возможности централизации в других местах. Как отмечено в [Schneider2], децентрализация «выглядит как риторическая стратегия, направляющая внимание на одни аспекты предлагаемого социального порядка и отвлекающая от других», поэтому «мы не можем воспринимать технологию как замену серьёзному отношению к социальным, культурным и политическим вопросам». Или более прямо, «без наличия механизмов управления узлы могут вступать в сговор, люди могут обманывать друг друга, рынки могут фальсифицироваться, а вход на рынок или выход с него могут быть связаны со значительными расходами» [Bodo]. Например, хотя криптовалюты на основе цепочек блоков (blockchain) призваны решить проблему централизации, присущую имеющимся валютам, техническими средствами, многие из них демонстрируют значительную концентрацию власти на основе голосования/майнинга, распределения средств и разнообразия баз кодов [Makarov]. Чрезмерная зависимость от технических мер также открывает возможности для скрытых неформальных властных структур, с которыми связаны свои риски, включая централизацию [Freeman].

В целом децентрализация функций требует значительных усилий, по сути является политическим процессом т связана со значительной неопределённостью в части результатов. Если рассматривать децентрализацию как социальную цель (в том смысле, который этот термин имеет в не связанном с компьютерами контексте), простая перестановка технических функций может привести к разочарованию. «Распределенная сеть не создаёт автоматически уравнительный, равноправный или просто социальный, экономический, политический ландшафт» [Bodo].

3.1. Стратегии децентрализации

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

3.1.1. Объединение

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

Например, набор протоколов электронной почты должен маршрутизировать сообщения к пользователю, даже если тот меняет местоположение в сети или отключается на долгое время. Для решения этой задачи протокол SMTP [RFC5321] определяет особую роль для маршрутизации пользовательских сообщений – агент передачи сообщений (Message Transfer Agent или MTA). Позволяя любому развернуть MTA и определяя правила соединений между агентами, протокол избегает необходимости использования в этой роли центрального сервера. Пользователь может (и часто делает это) передать функции доставки кому-либо или запустить свой агент MTA.

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

Расширяемый протокол обмена сообщениями и присутствия (Extensible Messaging and Presence Protocol или XMPP) [RFC6120] – это протокол общения (чат), который показывает ещё одну проблему федерации – добровольный характер технических стандартов. Как и электронная почта, XMPP использует объединение для облегчения встречи пользователей из разных систем, если они разрешают это. Хотя некоторые системы XMPP действительно поддерживают федеративный обмен сообщениями (т. е., человек, использующий службу A может общаться с пользователем службы B), многие из крупных систем не делают этого. Поскольку объединение является добровольным, некоторые операторы вынуждают клиентов пользоваться лишь одной службой, намеренно лишая их возможностей глобального взаимодействия.

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

3.1.2. Распределённое согласие

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

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

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

Хотя эти меры могут быть эффективными для децентрализации работы функции, другие аспекты её предоставления могут быть централизованы (например, управление устройством, создание общих реализаций, документирование протоколов передачи). Необходимость координации является путём к централизации, даже если работа функции остаётся децентрализованной. Например «слияние» (merge) Ethereum показало, что блокчейн может решать экологические проблемы, но лишь при условии координированных усилий сообщества и правительства – координация, казавшаяся большинству безвредной, на деле была централизованной [ETHEREUM].

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

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

3.1.3. Оперативное управление

Объединение и распределённое согласие могут создавать условия для предоставления функции несколькими провайдерами, но не могут этого гарантировать. Однако когда поставщикам услуги требуется доступ к ресурсу или кооперация с другими, это узкое место может, само по себе, применяться для воздействия на поведение провайдера, включая противодействие централизации. В таких условиях для получения желаемого результата нужна та или иная форма управления этим узким местом. Зачастую это обеспечивается путём создания многостороннего органа, который представляет собой учреждение, включающее представителей разных сторон, влияющих на работу системы (заинтересованные стороны – stakeholder), в попытке обеспечить принятие обоснованных, легитимных и полномочных решений. Хорошо изученным примером такого метода является управление пространством имён DNS, которое раскрывает централизацию как «единый корень доверия» [Moura]. Этот источник доверия контролируется Корпорацией Internet по назначению имён и номеров (Internet Corporation for Assigned Names and Numbers или ICANN) <https://www.icann.org/resources/pages/governance/governance-en> – глобальным многосторонним органом, где представлены конечные пользователи, правительства, операторы и др.

Другим примером является управление моделью доверия в Web, реализуемое web-браузерами как полагающимися на доверие сторонами, у которых есть серьёзные стимулы для защиты приватности и безопасности пользователей, и CA в качестве привязки доверия, у которой есть серьёзные основания для включения в хранилище доверия браузера. Для продвижения операционных требований и требований безопасности, необходимых для обеспечения желаемых свойств был организован Форум CA/Browser <https://cabforum.org> в качестве надзорного органа, в котором участвуют обе стороны как заинтересованные лица.

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

4. Что могут сделать стандарты Internet?

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

4.1. Повышение легитимности

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

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

Работа по устранению этих недостатков продолжается, см., например, [RFC8890]. В целом, укрепление легитимности организации следует считать постоянной работой.

При участии во внешних работах, сообществу IETF (особенно руководству) следует помнить, что мнение организации наиболее авторитетно, когда оно сосредоточено на техническом и архитектурном влиянии.

4.2. Обсуждение централизации

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

Однако участники разработки стандартов редко обладают достаточным опытом или сведениями для полной оценки таких утверждений, поскольку они включают не только технические факторы, но и экономические, социальные, коммерческие и юридические аспекты. Например, экономия от широкого распространения может привести к концентрации из-за связанной с этим эффективности [Demsetz], поэтому для оценки целесообразности такой концентрации нужен детальный экономический анализ, который не входит в сферу компетенции технических органов стандартизации. Кроме того, претензии на централизацию могут иметь и другие мотивы, например, они могут служить борьбе за власть между участниками с конкурирующими интересами, а также для блокирования участникам рынка и (что может быть важнее) пользователям возможности воспользоваться преимуществами стандартизации. Поэтому такие подходы, как требование включать в документы раздел «Вопросы централизации», публикация обзоров по централизации или выделение значительных ресурсов на поиск централизации в протоколах вряд ли улучшат Internet.

Отказ от стандартизации протокола по причине отсутствия активного предотвращения всех форм централизации игнорирует очень ограниченные возможности работ по созданию стандартов. Почти все имеющиеся протоколы Internet, включая IP, TCP, HTTP и DNS, не могут предотвратить централизацию применяющих эти протоколы приложений. Хотя одобрение проектов стандартов [RFC2026] не лишено ценности, простой отказ от него не помешает централизации.

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

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

  1. Какова природа централизации, представляющейся проблематично?

  2. Каковы глубинные предпосылки и допущения (концептуальная логика) лежат в основе представления «проблемы»?

  3. Как возникло это представление проблемы?

  4. Что остаётся избавленным от проблем в этом представлении? О чем умалчивается? Можно ли концептуализировать «проблему» иначе?

  5. Какие последствия влечёт это представление «проблемы»?

  6. Как и где это представление «проблемы» создавалось, распространялось и защищалось? Как оно было и/или может быть разрушено или заменено?

4.3. Целевые фирменные функции

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

Основным возражением против такого подхода является его добровольное принятие – здесь нет «полиции стандартов» которая требовала бы от всех их применения или вынуждала к правильной реализации. Например, спецификации вроде [ACTIVITYSTREAMS] были доступны в течение некоторого времени, но не применялись на федеративной основе провайдерами коммерческих социальных сетей.

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

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

4.4. Возможность переключения

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

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

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

Цели достижения полноты и разнообразия иногда противоречат друг другу. Если стандарт становится чрезвычайно сложным, это может стать препятствием для разнообразия реализаций, поскольку стоимость полной реализации будет слишком высокой (вспомним web-браузеры). С другой стороны, слишком простая спецификация может не обеспечить простого переключения, особенно если для полноты нужны нестандартные (proprietary) расширения (см. параграф 4.7).

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

4.5. Управление передачей полномочий

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

Efficiency – эффективность

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

Simplicity – простота

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

Specialization – специализация

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

Privacy – приватность

Для некоторых функций приватность пользователей можно повысить за счёт консолидации действий, позволяющей предотвратить распознавание поведения отдельных людей [Chaum]. Добавление третьей стороны может также установить функциональные границы, например, избавить пользователей от необходимости доверять потенциально вредоносным конечным точкам, как это случается в так называемых «забывчивых» (oblivious) протоколах (например, [RFC9230]), которые позволяют пользователям скрыть своё отождествление от сервиса, сохраняя доступ к нему.

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

Для случаев вовлечения в функцию третьей стороны оказались полезными два правила. Во-первых, третьей стороне следует вмешиваться во взаимодействие, когда хотя бы одна из двух сторон предпринимает позитивные действия для этого. Во-вторых, третьей стороне следует быть способной наблюдать или контролировать взаимодействия, ограничиваясь лишь тем, что необходимо для выполнения предусмотренной функции. Например, ранние реализации HTTP позволяли посредникам вмешиваться в сеть без знания конечных точек и эти посредники могли по умолчанию видеть и изменять всё содержимое трафика, даже будучи предназначенными для выполнения лишь базовых функций, таких как кэширование. В результате введения HTTPS и метода CONNECT (см. параграф 9.3.6 в [HTTP]) в сочетании с усилиями по их внедрению посредники сейчас должны явно указываться конечной точкой и имеют доступ лишь к базовым маршрутным сведениям. Дополнительные сведения о протокольном посредничестве приведены в [THOMSON-TMI].

Термин «посредник» часто применяется (особенно в правовом и нормативном контексте) в более широком смысле, нежели для протоколов. Например, web-сайт аукциона, посредничающий между продавцами и покупателями, является посредником, хотя формально не выполняет функций посредника HTTP (см. параграф 3.7 в [HTTP]). Разработчики протоколов могут решить проблему централизации, связанную с такого рода посредничеством, путём стандартизации функции, а не ограничения возможностей базовых протоколов (см. параграф 4.3).

4.6. Установка границ

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

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

4.7. Осторожность при расширении

Способность Internet к развитию имеет решающее значение, позволяя соответствовать новым требованиям и адаптироваться к новым условиям без «дня флага» для обновления реализаций. Обычно функции поддерживают развитие путём определения интерфейсов расширения, которые позволяют добавлять или изменять функции с течением времени обеспечивающим функциональную совместимость способом. Однако эти интерфейсы могут быть использованы сильной стороной, если они могут менять цель для обеспечения значимой совместимости путём добавления своих (proprietary) расширений к стандарту. Это особенно верно в случаях, когда сам базовый стандарт не обеспечивает достаточной полезности. Например, чрезвычайная гибкость SOAP [SOAP] и неспособность обеспечить самостоятельную ценность позволяет производителям требовать использования определённых расширений, отдавая предпочтение тем, кто сильней на рынке.

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

4.8. Использование того, что работает

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

5. Продолжение работы

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

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

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

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

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

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

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

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

[Abrahamson] Abrahamson, Z., “Essential Data”, Yale Law Journal, Vol. 124, No. 3, December 2014, <https://www.yalelawjournal.org/comment/essential-data>.

[ACTIVITYSTREAMS] Prodromou, E., Ed. and J. Snell, Ed., “Activity Streams 2.0”, W3C Recommendation, 23 May 2017, <https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/>. Latest version available at <https://www.w3.org/TR/ activitystreams-core/>.

[Aligia] Aligia, P. and V. Tarko, “Polycentricity: From Polanyi to Ostrom, and Beyond”, Governance: An International Journal of Policy, Administration, and Institutions, Vol. 25, No. 2, p. 237, DOI 10.1111/j.1468-0491.2011.01550.x, April 2012, <https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1468-0491.2011.01550.x>.

[Bacchi] Bacchi, C., “Introducing the ‘What’s the Problem Represented to be?’ approach”, Chapter 2, Engaging with Carol Bacchi, 2012, <https://library.oapen.org/bitstream/handle/20.500.12657/33181/560097.pdf?sequence=1#page=34>.

[Baran] Baran, P., “On Distributed Communications: Introduction to Distributed Communications Networks”, DOI 10.7249/RM3420, 1964, <https://www.rand.org/pubs/research_memoranda/RM3420.html>.

[BCP95] Alvestrand, H., “A Mission Statement for the IETF”, BCP 95, RFC 3935, October 2004. <https://www.rfc-editor.org/info/bcp95>

[Bodo] Bodó, B., Brekke, J. K., and J.-H. Hoepman, “Decentralization: a multidisciplinary perspective”, Internet Policy Review, Vol. 10, No. 2, DOI 10.14763/2021.2.1563, June 2021, <https://policyreview.info/concepts/decentralisation>.

[Chaum] Chaum, D., “Untraceable electronic mail, return addresses, and digital pseudonyms”, Communications of the ACM, Vol. 24, No. 2, DOI 10.1145/358549.358563, February 1981, <https://dl.acm.org/doi/10.1145/358549.358563>.

[Christensen] Christensen, C., “The Law of Conservation of Attractive Profits”, Harvard Business Review, “Breakthrough Ideas for 2004”, February 2004.

[Demsetz] Demsetz, H., “Industry Structure, Market Rivalry, and Public Policy”, Journal of Law and Economics, Vol. 16, No. 1, April 1973, <https://www.jstor.org/stable/724822>.

[DMA] The European Parliament and the Council of the European Union, “Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act)”, OJ L 265/1, 12.10.2022, September 2022, <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925>.

[Doctorow] Doctorow, C., “Adversarial Interoperability”, October 2019, <https://www.eff.org/deeplinks/2019/10/adversarial-interoperability>.

[ETHEREUM] Ethereum, “The Merge”, February 2023, <https://ethereum.org/en/roadmap/merge/>.

[FarrellH] Farrell, H. and A. Newman, “Weaponized Interdependence: How Global Economic Networks Shape State Coercion”, International Security, Vol. 44, No. 1, p. 42, DOI 10.1162/ISEC_a_00351, July 2019, <https://doi.org/10.1162/ISEC_a_00351>.

[FarrellJ] Farrell, J. and C. Shapiro, “Dynamic Competition with Switching Costs”, UC Berkeley Department of Economics Working Paper 8865, DOI 10.2307/2555402, January 1988, <https://doi.org/10.2307/2555402>.

[Fletcher] Fletcher, A., “The Role of Behavioural Economics in Competition Policy”, DOI 10.2139/ssrn.4389681, March 2023, <https://doi.org/10.2139/ssrn.4389681>.

[Freeman] Freeman, J., “The Tyranny of Structurelessness”, Berkeley Journal of Sociology, Vol. 17, 1972, <https://www.jstor.org/stable/41035187>.

[Holzbauer] Holzbauer, F., Ullrich, J., Lindorfer, M., and T. Fiebig, “Not that Simple: Email Delivery in the 21st Century”, July 2022, <https://www.usenix.org/system/files/atc22-holzbauer.pdf>.

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

[Kashaf] Kashaf, A., Sekar, V., and Y. Agarwal, “Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?”, DOI 10.1145/3419394.3423664, October 2020, <https://dl.acm.org/doi/pdf/10.1145/3419394.3423664>.

[Komaitis] Komaitis, K., “Regulators Seem to Think That Facebook Is the Internet”, August 2021, <https://slate.com/technology/2021/08/facebook-internet-regulation.html>.

[Lessig] Lessig, L., “The New Chicago School”, Journal of Legal Studies, Vol. 27, DOI 10.1086/468039, June 1998, <https://www.journals.uchicago.edu/doi/10.1086/468039>.

[Madison] Madison, J., “The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments”, The Federalist Papers, No. 51, February 1788.

[Makarov] Makarov, I. and A. Schoar, “Blockchain Analysis of the Bitcoin Market”, National Bureau of Economic Research, Working Paper 29396, DOI 10.3386/w29396, October 2021, <https://www.nber.org/papers/w29396>.

[Marlinspike] Marlinspike, M., “Reflections: The ecosystem is moving”, May 2016, <https://signal.org/blog/the-ecosystem-is-moving/>.

[Moura] Moura, G., Castro, S., Hardaker, W., Wullink, M., and C. Hesselman, “Clouding up the Internet: how centralized is DNS traffic becoming?”, DOI 10.1145/3419394.3423625, October 2020, <https://dl.acm.org/doi/abs/10.1145/3419394.3423625>.

[Musiani] Musiani, F., “Alternative Technologies as Alternative Institutions: The Case of the Domain Name System”, The Turn to Infrastructure in Internet Governance, DOI 10.1057/9781137483591_4, 2016, <https://link.springer.com/chapter/10.1057/9781137483591_4>.

[Palladino] Palladino, N. and M. Santaniello, “Legitimacy, Power, and Inequalities in the Multistakeholder Internet Governance”, DOI 10.1007/978-3-030-56131-4, November 2020, <https://link.springer.com/book/10.1007/978-3-030-56131-4>.

[PHONE] Skrzycki, C. and J. Burgess, “Computer Failure Paralyzes Region’s Phone Service”, June 1991, <https://www.washingtonpost.com/archive/politics/1991/06/27/computer-failure-paralyzes-regions-phone-service/0db94ac7-89f0-446e-ba33-c126c751b251/>.

[RFC2026] Bradner, S., “The Internet Standards Process – Revision 3”, BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

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

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

[RFC5321] Klensin, J., “Simple Mail Transfer Protocol”, RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.

[RFC6120] Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core”, RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.

[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC8890] Nottingham, M., “The Internet is for End Users”, RFC 8890, DOI 10.17487/RFC8890, August 2020, <https://www.rfc-editor.org/info/rfc8890>.

[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. Wood, “Oblivious DNS over HTTPS”, RFC 9230, DOI 10.17487/RFC9230, June 2022, <https://www.rfc-editor.org/info/rfc9230>.

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

[Schneider1] Schneider, N., “What to do once you admit that decentralizing everything never seems to work”, Hacker Noon, September 2019, <https://hackernoon.com/decentralizing-everything-never-seems-to-work-2bb0461bd168>.

[Schneider2] Schneider, N., “Decentralization: An Incomplete Ambition”, Journal of Cultural Economy, Vol. 12, No. 4, DOI 10.31219/osf.io/m7wyj, April 2019, <https://osf.io/m7wyj/>.

[SOAP] Mitra, N., Ed. and Y. Lafon, Ed., “SOAP Version 1.2 Part 0: Primer (Second Edition)”, W3C Recommendation, 27 April 2007, <https://www.w3.org/TR/2007/REC-soap12-part0-20070427/>. Latest version available at <https://www.w3.org/TR/soap12-part0/>.

[Spulber] Spulber, D., “Solving The Circular Conundrum: Communication and Coordination in Two-Sided Markets”, Northwestern University Law Review, Vol. 104, No. 2, October 2009, <https://wwws.law.northwestern.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.pdf>.

[THOMSON-TMI] Thomson, M., “Principles for the Involvement of Intermediaries in Internet Protocols”, Work in Progress, Internet-Draft, draft-thomson-tmi-04, 8 September 2022, <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-04>.

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

Этот документ родился из ранних обсуждений с Brian Trammell во время совместной работы в Совете по архитектуре Internet (Internet Architecture Board или IAB).

Особая благодарность Geoff Huston и Milton Mueller за продуманные и полезные рецензии.

Спасибо Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, Christian Huitema, Eliot Lear, John Levine, Tommy Pauly, Martin Thomson за их комментарии и предложения. Ценные обсуждения и отклики предоставили список рассылки arch-discuss@ietf.org и исследовательская группа Decentralized Internet Infrastructure.

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

Адрес автора

Mark Nottingham
Prahran
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/

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

nmalykh@protokols.ru


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

RFC 9501 Open Participation Principle regarding Remote Registration Fee

Internet Engineering Task Force (IETF)                      M. Kühlewind
Request for Comments: 9501                                      Ericsson
BCP: 239                                                         J. Reed
Category: Best Current Practice                                  R. Salz
ISSN: 2070-1721                                      Akamai Technologies
                                                           December 2023

Open Participation Principle regarding Remote Registration Fee

Принцип открытого участия применительно к регистрационной плате

PDF

Аннотация

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

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

Документ относится к категории Internet Best Current Practice.

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

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

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

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

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

1. Введение

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

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

Однако с переходом полностью на онлайн-заседания в 2020 и 2021 гг. различий между удаленным участием и личным присутствием не стало. Поскольку затраты на проведение заседаний IETF и другие расходы все равно требовалось покрывать, удалённое участие стало платным вместо прежней возможности бесплатного доступа для всех удалённых участников.

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

2. Принцип открытого участия

В этом документе изложен принцип открытого участия, которые предполагается учитывать IETF LLC3 при принятии решений о структуре регистрационных взносов за удалённое участие. Принцип прост – должна быть возможность бесплатного удалённого участия в любом заседании IETF, независимо от того, проводится ли оно также очно. Смежные мероприятия, связанные с заседаниями IETF являются частью открытого процесса IETF [RFC3935] и для них также рекомендуется применять этот принцип, если мероприятие предполагает удалённое участие.

Это направлено на поддержку принципа открытости IETF, указанного в [RFC3935].

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

Хотя в [RFC3935] явно указано, что этот принцип требует открытого доступа к материалам и документам через Internet, документ был написан в основном с учётом взаимодействия по электронной почте, когда шла речь от участии. В этом документе принцип расширяется для явного охвата удалённого участия с собраниях. В частности, в этом контексте открытость должна рассматриваться как доступность и бесплатность (free). Документ не оговаривает, что все собрания IETF и связанные с ними события IETF должны предполагать возможность удалённого участия, поскольку могут быть технические или иные причины, не позволяющие обеспечить такое участие. Однако, если удалённое участие предусмотрено, должна быть возможность бесплатного участия, чтобы сделать процесс максимально открытым. Как минимум предполагается, что такая возможность будет предусматриваться для заседаний рабочих групп, BoF4, и административных пленарных заседаний.

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

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

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

3. Финансовые последствия

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

Изменения в структуре сборов IETF и общей модели финансирования не входят в сферу действия этого документа. Как указано в [RFC8711], IETF LLC отвечает за управление финансами и бюджетом IETF и поэтому: «от IETF LLC ожидается ответственное поведение с целью минимизации рисков (таких, как финансовые) для участников IETF и будущего IETF», Кроме того, совет IETF LLC обязан «действовать в соответствии с документированным согласованным мнением сообщества IETF» [RFC8711], принимая во внимание согласованные принципы, подобные описанному в этом документе.

Если будет установлено, что неограниченное бесплатное удалённое участие негативно влияет на финансовую устойчивость IETF (например, если число платных участников или стоимость бесплатного участия станут важными факторами), от LLC ожидается принятие дополнительных мер по управлению этими расходами. Этот документ не ограничивает и не может ограничивать финансовую ответственность LLC и поэтому не вносит каких-либо ограничений на применение дополнительных мер. Если LLC решит реализовать дополнительные меры, это решение и его обоснование следует предоставить сообществу и рассмотреть вопрос о необходимости консультаций с сообществом, как указано в параграфе 4.4 [RFC8711], «для получения обоснованного согласия сообщества по ключевым вопросам». Кроме того, реализуемый процесс следует описать достаточно подробно, чтобы участники могли принять осознанное решение об использовании бесплатного варианта.

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

4. Использование и злоупотребления бесплатной регистрацией

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

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

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

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

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

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

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

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

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

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

[RFC3935] Alvestrand, H., “A Mission Statement for the IETF”, BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <https://www.rfc-editor.org/info/rfc3935>.

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

[RFC8711] Haberman, B., Hall, J., and J. Livingood, “Structure of the IETF Administrative Support Activity, Version 2.0”, BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, <https://www.rfc-editor.org/info/rfc8711>.

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

Спасибо всем, кто участвовал в обсуждениях рабочей группы SHMOO, особенно Brian Carpenter, Jason Livingood, Lars Eggert, Charles Eckel за предложения по конкретным улучшениям и глубокие обзоры.

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

Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
 
Jon Reed
Akamai Technologies
Email: jreed@akamai.com
 
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com

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

nmalykh@protokols.ru


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

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

3IETF Administration LLC (IETF LLC) – объединенная юридическая структура для IETF, Совета по архитектуре Internet (IAB) и Целевой группы по исследованиям Internet (IRTF). Прим. перев.

4Birds of a Feather – первоначальное обсуждение определённой темы, представляющей интерес для сообщества IETF. Прим. перев.

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

RFC 9500 Standard Public Key Cryptography (PKC) Test Keys

Internet Engineering Task Force (IETF)                        P. Gutmann
Request for Comments: 9500                        University of Auckland
Category: Informational                                       C. Bonnell
ISSN: 2070-1721                                                 DigiCert
                                                           December 2023

Standard Public Key Cryptography (PKC) Test Keys

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

PDF

Аннотация

Этот документ представляет набор стандартных ключей для криптографии с открытым ключом (Public Key Cryptography или PKC) которые можно применять везде, где требуются заранее созданные ключи и связанные с ними операции, такие как цифровые подписи. Подобно тесту вирусов Европейского института антивирусных компьютерных исследований (European Institute for Computer Antivirus Research или EICAR) и файлам базового теста спама (Generic Test for Unsolicited Bulk Email или GTUBE), эти общеизвестные тестовые ключи могут быть обнаружены и распознаны приложениями, использующими их исключительно для тестирования, не предполагая каких-либо свойств защиты.

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

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

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

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

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

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

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

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

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

1. Введение

Широкое использование криптосистем с открытым ключом в Internet привело к распространению общеизвестных, но не всегда признанных ключей, применяемых для тестирования или поставки в приложениях с предустановленной конфигурацией. Эти ключи не обеспечивают защиты, но по причине отсутствия каких-либо записей о ключах полагающиеся на них стороны часто не знают об отсутствии защиты. Для решения этой проблемы данный документ представляет набор стандартных открытых тестовых ключей, которые могут применяться везде, где нужен заранее созданный или эталонный ключ, а также (за счёт расширений) – в ситуациях, где такие ключи могут применяться, например, при тестировании цифровых подписей для данных. Назначение ключей примерно соответствует назначению тестового файла EICAR (файл без вирусов для проверки антивирусной продукции) и файлу GTUBE, применяемому в продукции для обнаружения спама.

Ключи охватывают три основных семейства алгоритмов:

  • RSA;

  • алгоритмы, основанные на задаче дискретного логарифмирования (Discrete Logarithm Problem или DLP), такие как DSA, Diffie-Hellman (DH), Elgamal;

  • алгоритмы, основанные на задаче дискретного логарифмирования эллиптической кривой (Elliptic Curve Discrete Logarithm Problem или ECDLP), такие как ECDSA и Elliptic Curve Diffie-Hellman (ECDH).

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

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

2. Общеизвестные тестовые ключи

В этом разделе представлены тестовые ключи разных размеров для групп алгоритмов в нотации в стиле языка C, которые можно напрямую включать в криптокод, написанный на языках, подобных C, таких как C, C++, Java, JavaScript, Go, Swift, Rust, что охватывает большинство языков, применяемых для реализации криптокоа.

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

Каждый элемент ключа приведён с указанием числа битов (значение, из которого берётся номинальный размер ключа), за которым следует строка байтов элемента ключа с порядком big-endian. Например, ниже представлен образец компонента ключа для значения RSA p, где 0xCF является старшим байтом значения RSA p, а 0x03 — младшим.

       /* p */
       512,
       { 0xCF, 0xDA, 0xF9, 0x99, 0x6F, 0x05, 0x95, 0x84,
         0x09, 0x90, 0xB3, 0xAB, 0x39, 0xB7, 0xDD, 0x1D,
         [...]
         0xE1, 0x2C, 0x0D, 0xF7, 0x30, 0xE2, 0xB8, 0x09,
         0x73, 0x50, 0x28, 0xF6, 0x55, 0x85, 0x57, 0x03 },

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

2.1. Ключи RSA

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

Ключ RSA-1024 testRSA1024

           /* n */
           1024,
           { 0xB0, 0xD1, 0x83, 0x52, 0xA8, 0x8F, 0x53, 0xD5,
             0x51, 0x6F, 0x46, 0xC2, 0x0E, 0x7A, 0x36, 0x7D,
             0x7D, 0xE8, 0x8A, 0xCF, 0x54, 0xA0, 0x19, 0xF6,
             0xDE, 0xF5, 0x7A, 0xB9, 0xB4, 0x4C, 0xED, 0xDB,
             0x22, 0x42, 0xB1, 0xBC, 0xA0, 0xFB, 0x1B, 0x5C,
             0xB8, 0x2B, 0x30, 0x36, 0x17, 0x6A, 0x63, 0x90,
             0x35, 0x64, 0xDE, 0xC6, 0xEB, 0x41, 0xDB, 0x2F,
             0x8F, 0xC7, 0x87, 0xF4, 0xE5, 0x2E, 0x11, 0x49,
             0xE3, 0x33, 0x47, 0x57, 0x29, 0x73, 0xF6, 0x60,
             0xC3, 0xC7, 0x7C, 0xA9, 0xE0, 0x82, 0x1C, 0x2B,
             0x69, 0x5B, 0xE7, 0xAE, 0x9D, 0x7D, 0x30, 0xF4,
             0x07, 0x91, 0x10, 0xF4, 0x8A, 0xAE, 0x6F, 0x8B,
             0x70, 0x2D, 0x47, 0x4B, 0x29, 0x00, 0x81, 0x7F,
             0x28, 0x66, 0x24, 0x9B, 0xEC, 0x12, 0xA2, 0xB1,
             0x9B, 0x82, 0x78, 0x41, 0x68, 0x08, 0xF8, 0x1A,
             0xE1, 0xFC, 0xF9, 0xB7, 0x77, 0x8A, 0x62, 0x3F },
           /* e */
           17,
           { 0x01, 0x00, 0x01 },
           /* d */
           1023,
           { 0x48, 0x2E, 0x9F, 0x8F, 0xA4, 0xE4, 0x2D, 0xF3,
             0x0D, 0x75, 0x81, 0xCB, 0x42, 0xA1, 0xBD, 0x90,
             0xE9, 0x4F, 0x7F, 0x2B, 0x38, 0x7E, 0xCB, 0x5A,
             0xAE, 0x96, 0x43, 0xED, 0x7F, 0x9F, 0x50, 0x12,
             0x7F, 0x1F, 0xFE, 0xF2, 0xE4, 0x3C, 0xDE, 0x64,
             0xB1, 0x82, 0x60, 0x02, 0x14, 0xF9, 0x07, 0x80,
             0x1D, 0x6B, 0xFA, 0x4D, 0xF6, 0x48, 0x42, 0x34,
             0x5E, 0x5B, 0xB4, 0x32, 0xD3, 0x44, 0x45, 0x25,
             0xD8, 0x30, 0x16, 0x54, 0xC5, 0x44, 0x2B, 0x0A,
             0x5E, 0x11, 0xB9, 0xC7, 0xE2, 0x01, 0xFA, 0x32,
             0xF4, 0x1A, 0xBA, 0xF4, 0xF0, 0xA6, 0xE0, 0x3C,
             0xF0, 0xE0, 0xCB, 0x82, 0x66, 0xC6, 0x2A, 0xD1,
             0x1D, 0x95, 0x6D, 0x53, 0xC9, 0x46, 0x6E, 0x48,
             0x99, 0x5F, 0xEA, 0x26, 0x0C, 0x85, 0x36, 0xF0,
             0x41, 0xCB, 0x35, 0x62, 0xFA, 0xAC, 0x51, 0x1C,
             0x4D, 0x66, 0xA8, 0xFE, 0xD1, 0x11, 0xB2, 0x91 },
           /* p */
           512,
           { 0xE9, 0xD8, 0x6E, 0x4D, 0xC3, 0x4A, 0x98, 0x5A,
             0x7E, 0xC7, 0x5A, 0x6F, 0x54, 0xA7, 0x5C, 0xE4,
             0x51, 0x39, 0xE4, 0x52, 0x40, 0xB3, 0x86, 0xAB,
             0x71, 0x1D, 0xB7, 0x91, 0xBC, 0xD9, 0x87, 0x18,
             0xA1, 0x3B, 0xAF, 0x21, 0x8C, 0x24, 0x49, 0x36,
             0x46, 0x68, 0x07, 0x56, 0xCB, 0x50, 0xA6, 0xCB,
             0xEE, 0x15, 0x8E, 0x25, 0x21, 0x44, 0x99, 0x12,
             0x30, 0x1C, 0x0D, 0x41, 0x49, 0x11, 0x18, 0x45 },
           /* q */
           512,
           { 0xC1, 0x91, 0xFA, 0x3B, 0x55, 0x0B, 0x39, 0x1A,
             0x7C, 0xB0, 0x72, 0x83, 0x76, 0x27, 0x72, 0x95,
             0xE6, 0x1C, 0x65, 0x4F, 0x0B, 0xEF, 0x2F, 0x58,
             0xDC, 0xE5, 0xC9, 0x62, 0xA1, 0x0B, 0x7D, 0xD7,
             0x5F, 0x06, 0x01, 0x54, 0x65, 0xE5, 0x50, 0x76,
             0xE4, 0x66, 0x26, 0x3E, 0xEB, 0xCA, 0xED, 0x20,
             0xD2, 0xEB, 0xAB, 0x39, 0x31, 0x3E, 0x8B, 0xC5,
             0x67, 0x32, 0x0F, 0xE8, 0xB2, 0xDC, 0x62, 0xB3 },
           /* u */
           512,
           { 0xB9, 0x9D, 0x7F, 0x8F, 0x4D, 0x4D, 0x45, 0x5F,
             0x1F, 0xBA, 0x46, 0x2D, 0x99, 0x0A, 0x2E, 0x84,
             0x8C, 0x42, 0x8C, 0x1E, 0xBE, 0xE0, 0x1D, 0xC0,
             0x01, 0x84, 0xC8, 0xA7, 0x65, 0x83, 0xAD, 0x37,
             0x9F, 0x69, 0xAD, 0xAF, 0x54, 0x75, 0x54, 0x30,
             0xF6, 0x3C, 0x42, 0x53, 0xD1, 0xBB, 0x78, 0xCC,
             0x9B, 0xD2, 0x32, 0x64, 0x34, 0x00, 0x80, 0xB8,
             0x4C, 0x1A, 0x91, 0x7D, 0xE0, 0x8B, 0x6E, 0xDB },
           /* exponent1 */
           512,
           { 0xE7, 0x3A, 0xE0, 0x37, 0x7C, 0xB8, 0xB2, 0x56,
             0x29, 0xAE, 0xAE, 0xBA, 0x0F, 0x97, 0x3E, 0xBF,
             0x75, 0xA2, 0x2D, 0x27, 0x38, 0x5B, 0x4C, 0xFB,
             0x11, 0xEB, 0x34, 0xAD, 0xA3, 0x73, 0xE5, 0xA6,
             0x71, 0x28, 0x37, 0x50, 0x90, 0xE7, 0x00, 0x8D,
             0xEE, 0xA8, 0xC7, 0x39, 0x07, 0xEA, 0x44, 0x44,
             0xBA, 0xB4, 0x0D, 0xCE, 0xA1, 0x4A, 0xD7, 0xA1,
             0xA8, 0x78, 0xD4, 0x92, 0x8D, 0xD1, 0x9D, 0x91 },
           /* exponent2 */
           511,
           { 0x41, 0x99, 0x79, 0x16, 0x16, 0x72, 0x21, 0x3E,
             0x0A, 0xB7, 0xB9, 0x77, 0x37, 0xD9, 0x92, 0x89,
             0x9E, 0x5C, 0x4D, 0x31, 0x06, 0xB8, 0x5E, 0x71,
             0x5D, 0x1B, 0x3A, 0xAE, 0x84, 0x29, 0x62, 0xD2,
             0x54, 0x4F, 0xB2, 0xAF, 0xA9, 0x80, 0x97, 0x4E,
             0x53, 0x85, 0x12, 0xBD, 0x0C, 0x27, 0xCF, 0x48,
             0xEA, 0x72, 0x17, 0xAA, 0xE0, 0x37, 0x74, 0x22,
             0xC8, 0x20, 0x3D, 0x27, 0xFD, 0x45, 0x96, 0xE5 }

Кодированная форма ключа RSA-1024.

   -----BEGIN RSA PRIVATE KEY-----
   MIICXQIBAAKBgQCw0YNSqI9T1VFvRsIOejZ9feiKz1SgGfbe9Xq5tEzt2yJCsbyg
   +xtcuCswNhdqY5A1ZN7G60HbL4/Hh/TlLhFJ4zNHVylz9mDDx3yp4IIcK2lb566d
   fTD0B5EQ9Iqub4twLUdLKQCBfyhmJJvsEqKxm4J4QWgI+Brh/Pm3d4piPwIDAQAB
   AoGASC6fj6TkLfMNdYHLQqG9kOlPfys4fstarpZD7X+fUBJ/H/7y5DzeZLGCYAIU
   +QeAHWv6TfZIQjReW7Qy00RFJdgwFlTFRCsKXhG5x+IB+jL0Grr08KbgPPDgy4Jm
   xirRHZVtU8lGbkiZX+omDIU28EHLNWL6rFEcTWao/tERspECQQDp2G5Nw0qYWn7H
   Wm9Up1zkUTnkUkCzhqtxHbeRvNmHGKE7ryGMJEk2RmgHVstQpsvuFY4lIUSZEjAc
   DUFJERhFAkEAwZH6O1ULORp8sHKDdidyleYcZU8L7y9Y3OXJYqELfddfBgFUZeVQ
   duRmJj7ryu0g0uurOTE+i8VnMg/ostxiswJBAOc64Dd8uLJWKa6uug+XPr91oi0n
   OFtM+xHrNK2jc+WmcSg3UJDnAI3uqMc5B+pERLq0Dc6hStehqHjUko3RnZECQEGZ
   eRYWciE+Cre5dzfZkomeXE0xBrhecV0bOq6EKWLSVE+yr6mAl05ThRK9DCfPSOpy
   F6rgN3QiyCA9J/1FluUCQQC5nX+PTU1FXx+6Ri2ZCi6EjEKMHr7gHcABhMinZYOt
   N59pra9UdVQw9jxCU9G7eMyb0jJkNACAuEwakX3gi27b
   -----END RSA PRIVATE KEY-----

Ключ RSA-2048 testRSA2048.

           /* n */
           2048,
           { 0xB0, 0xF9, 0xE8, 0x19, 0x43, 0xA7, 0xAE, 0x98,
             0x92, 0xAA, 0xDE, 0x17, 0xCA, 0x7C, 0x40, 0xF8,
             0x74, 0x4F, 0xED, 0x2F, 0x81, 0x48, 0xE6, 0xC8,
             0xEA, 0xA2, 0x7B, 0x7D, 0x00, 0x15, 0x48, 0xFB,
             0x51, 0x92, 0xAB, 0x28, 0xB5, 0x6C, 0x50, 0x60,
             0xB1, 0x18, 0xCC, 0xD1, 0x31, 0xE5, 0x94, 0x87,
             0x4C, 0x6C, 0xA9, 0x89, 0xB5, 0x6C, 0x27, 0x29,
             0x6F, 0x09, 0xFB, 0x93, 0xA0, 0x34, 0xDF, 0x32,
             0xE9, 0x7C, 0x6F, 0xF0, 0x99, 0x8C, 0xFD, 0x8E,
             0x6F, 0x42, 0xDD, 0xA5, 0x8A, 0xCD, 0x1F, 0xA9,
             0x79, 0x86, 0xF1, 0x44, 0xF3, 0xD1, 0x54, 0xD6,
             0x76, 0x50, 0x17, 0x5E, 0x68, 0x54, 0xB3, 0xA9,
             0x52, 0x00, 0x3B, 0xC0, 0x68, 0x87, 0xB8, 0x45,
             0x5A, 0xC2, 0xB1, 0x9F, 0x7B, 0x2F, 0x76, 0x50,
             0x4E, 0xBC, 0x98, 0xEC, 0x94, 0x55, 0x71, 0xB0,
             0x78, 0x92, 0x15, 0x0D, 0xDC, 0x6A, 0x74, 0xCA,
             0x0F, 0xBC, 0xD3, 0x54, 0x97, 0xCE, 0x81, 0x53,
             0x4D, 0xAF, 0x94, 0x18, 0x84, 0x4B, 0x13, 0xAE,
             0xA3, 0x1F, 0x9D, 0x5A, 0x6B, 0x95, 0x57, 0xBB,
             0xDF, 0x61, 0x9E, 0xFD, 0x4E, 0x88, 0x7F, 0x2D,
             0x42, 0xB8, 0xDD, 0x8B, 0xC9, 0x87, 0xEA, 0xE1,
             0xBF, 0x89, 0xCA, 0xB8, 0x5E, 0xE2, 0x1E, 0x35,
             0x63, 0x05, 0xDF, 0x6C, 0x07, 0xA8, 0x83, 0x8E,
             0x3E, 0xF4, 0x1C, 0x59, 0x5D, 0xCC, 0xE4, 0x3D,
             0xAF, 0xC4, 0x91, 0x23, 0xEF, 0x4D, 0x8A, 0xBB,
             0xA9, 0x3D, 0x39, 0x05, 0xE4, 0x02, 0x8D, 0x7B,
             0xA9, 0x14, 0x84, 0xA2, 0x75, 0x96, 0xE0, 0x7B,
             0x4B, 0x6E, 0xD9, 0x92, 0xF0, 0x77, 0xB5, 0x24,
             0xD3, 0xDC, 0xFE, 0x7D, 0xDD, 0x55, 0x49, 0xBE,
             0x7C, 0xCE, 0x8D, 0xA0, 0x35, 0xCF, 0xA0, 0xB3,
             0xFB, 0x8F, 0x9E, 0x46, 0xF7, 0x32, 0xB2, 0xA8,
             0x6B, 0x46, 0x01, 0x65, 0xC0, 0x8F, 0x53, 0x13 },
           /* e */
           17,
           { 0x01, 0x00, 0x01 },
           /* d */
           2047,
           { 0x41, 0x18, 0x8B, 0x20, 0xCF, 0xDB, 0xDB, 0xC2,
             0xCF, 0x1F, 0xFE, 0x75, 0x2D, 0xCB, 0xAA, 0x72,
             0x39, 0x06, 0x35, 0x2E, 0x26, 0x15, 0xD4, 0x9D,
             0xCE, 0x80, 0x59, 0x7F, 0xCF, 0x0A, 0x05, 0x40,
             0x3B, 0xEF, 0x00, 0xFA, 0x06, 0x51, 0x82, 0xF7,
             0x2D, 0xEC, 0xFB, 0x59, 0x6F, 0x4B, 0x0C, 0xE8,
             0xFF, 0x59, 0x70, 0xBA, 0xF0, 0x7A, 0x89, 0xA5,
             0x19, 0xEC, 0xC8, 0x16, 0xB2, 0xF4, 0xFF, 0xAC,
             0x50, 0x69, 0xAF, 0x1B, 0x06, 0xBF, 0xEF, 0x7B,
             0xF6, 0xBC, 0xD7, 0x9E, 0x4E, 0x81, 0xC8, 0xC5,
             0xA3, 0xA7, 0xD9, 0x13, 0x0D, 0xC3, 0xCF, 0xBA,
             0xDA, 0xE5, 0xF6, 0xD2, 0x88, 0xF9, 0xAE, 0xE3,
             0xF6, 0xFF, 0x92, 0xFA, 0xE0, 0xF8, 0x1A, 0xF5,
             0x97, 0xBE, 0xC9, 0x6A, 0xE9, 0xFA, 0xB9, 0x40,
             0x2C, 0xD5, 0xFE, 0x41, 0xF7, 0x05, 0xBE, 0xBD,
             0xB4, 0x7B, 0xB7, 0x36, 0xD3, 0xFE, 0x6C, 0x5A,
             0x51, 0xE0, 0xE2, 0x07, 0x32, 0xA9, 0x7B, 0x5E,
             0x46, 0xC1, 0xCB, 0xDB, 0x26, 0xD7, 0x48, 0x54,
             0xC6, 0xB6, 0x60, 0x4A, 0xED, 0x46, 0x37, 0x35,
             0xFF, 0x90, 0x76, 0x04, 0x65, 0x57, 0xCA, 0xF9,
             0x49, 0xBF, 0x44, 0x88, 0x95, 0xC2, 0x04, 0x32,
             0xC1, 0xE0, 0x9C, 0x01, 0x4E, 0xA7, 0x56, 0x60,
             0x43, 0x4F, 0x1A, 0x0F, 0x3B, 0xE2, 0x94, 0xBA,
             0xBC, 0x5D, 0x53, 0x0E, 0x6A, 0x10, 0x21, 0x3F,
             0x53, 0xB6, 0x03, 0x75, 0xFC, 0x84, 0xA7, 0x57,
             0x3F, 0x2A, 0xF1, 0x21, 0x55, 0x84, 0xF5, 0xB4,
             0xBD, 0xA6, 0xD4, 0xE8, 0xF9, 0xE1, 0x7A, 0x78,
             0xD9, 0x7E, 0x77, 0xB8, 0x6D, 0xA4, 0xA1, 0x84,
             0x64, 0x75, 0x31, 0x8A, 0x7A, 0x10, 0xA5, 0x61,
             0x01, 0x4E, 0xFF, 0xA2, 0x3A, 0x81, 0xEC, 0x56,
             0xE9, 0xE4, 0x10, 0x9D, 0xEF, 0x8C, 0xB3, 0xF7,
             0x97, 0x22, 0x3F, 0x7D, 0x8D, 0x0D, 0x43, 0x51 },
           /* p */
           1024,
           { 0xDD, 0x10, 0x57, 0x02, 0x38, 0x2F, 0x23, 0x2B,
             0x36, 0x81, 0xF5, 0x37, 0x91, 0xE2, 0x26, 0x17,
             0xC7, 0xBF, 0x4E, 0x9A, 0xCB, 0x81, 0xED, 0x48,
             0xDA, 0xF6, 0xD6, 0x99, 0x5D, 0xA3, 0xEA, 0xB6,
             0x42, 0x83, 0x9A, 0xFF, 0x01, 0x2D, 0x2E, 0xA6,
             0x28, 0xB9, 0x0A, 0xF2, 0x79, 0xFD, 0x3E, 0x6F,
             0x7C, 0x93, 0xCD, 0x80, 0xF0, 0x72, 0xF0, 0x1F,
             0xF2, 0x44, 0x3B, 0x3E, 0xE8, 0xF2, 0x4E, 0xD4,
             0x69, 0xA7, 0x96, 0x13, 0xA4, 0x1B, 0xD2, 0x40,
             0x20, 0xF9, 0x2F, 0xD1, 0x10, 0x59, 0xBD, 0x1D,
             0x0F, 0x30, 0x1B, 0x5B, 0xA7, 0xA9, 0xD3, 0x63,
             0x7C, 0xA8, 0xD6, 0x5C, 0x1A, 0x98, 0x15, 0x41,
             0x7D, 0x8E, 0xAB, 0x73, 0x4B, 0x0B, 0x4F, 0x3A,
             0x2C, 0x66, 0x1D, 0x9A, 0x1A, 0x82, 0xF3, 0xAC,
             0x73, 0x4C, 0x40, 0x53, 0x06, 0x69, 0xAB, 0x8E,
             0x47, 0x30, 0x45, 0xA5, 0x8E, 0x65, 0x53, 0x9D },
           /* q */
           1024,
           { 0xCC, 0xF1, 0xE5, 0xBB, 0x90, 0xC8, 0xE9, 0x78,
             0x1E, 0xA7, 0x5B, 0xEB, 0xF1, 0x0B, 0xC2, 0x52,
             0xE1, 0x1E, 0xB0, 0x23, 0xA0, 0x26, 0x0F, 0x18,
             0x87, 0x55, 0x2A, 0x56, 0x86, 0x3F, 0x4A, 0x64,
             0x21, 0xE8, 0xC6, 0x00, 0xBF, 0x52, 0x3D, 0x6C,
             0xB1, 0xB0, 0xAD, 0xBD, 0xD6, 0x5B, 0xFE, 0xE4,
             0xA8, 0x8A, 0x03, 0x7E, 0x3D, 0x1A, 0x41, 0x5E,
             0x5B, 0xB9, 0x56, 0x48, 0xDA, 0x5A, 0x0C, 0xA2,
             0x6B, 0x54, 0xF4, 0xA6, 0x39, 0x48, 0x52, 0x2C,
             0x3D, 0x5F, 0x89, 0xB9, 0x4A, 0x72, 0xEF, 0xFF,
             0x95, 0x13, 0x4D, 0x59, 0x40, 0xCE, 0x45, 0x75,
             0x8F, 0x30, 0x89, 0x80, 0x90, 0x89, 0x56, 0x58,
             0x8E, 0xEF, 0x57, 0x5B, 0x3E, 0x4B, 0xC4, 0xC3,
             0x68, 0xCF, 0xE8, 0x13, 0xEE, 0x9C, 0x25, 0x2C,
             0x2B, 0x02, 0xE0, 0xDF, 0x91, 0xF1, 0xAA, 0x01,
             0x93, 0x8D, 0x38, 0x68, 0x5D, 0x60, 0xBA, 0x6F },
           /* u */
           1020,
           { 0x0A, 0x81, 0xD8, 0xA6, 0x18, 0x31, 0x4A, 0x80,
             0x3A, 0xF6, 0x1C, 0x06, 0x71, 0x1F, 0x2C, 0x39,
             0xB2, 0x66, 0xFF, 0x41, 0x4D, 0x53, 0x47, 0x6D,
             0x1D, 0xA5, 0x2A, 0x43, 0x18, 0xAA, 0xFE, 0x4B,
             0x96, 0xF0, 0xDA, 0x07, 0x15, 0x5F, 0x8A, 0x51,
             0x34, 0xDA, 0xB8, 0x8E, 0xE2, 0x9E, 0x81, 0x68,
             0x07, 0x6F, 0xCD, 0x78, 0xCA, 0x79, 0x1A, 0xC6,
             0x34, 0x42, 0xA8, 0x1C, 0xD0, 0x69, 0x39, 0x27,
             0xD8, 0x08, 0xE3, 0x35, 0xE8, 0xD8, 0xCB, 0xF2,
             0x12, 0x19, 0x07, 0x50, 0x9A, 0x57, 0x75, 0x9B,
             0x4F, 0x9A, 0x18, 0xFA, 0x3A, 0x7B, 0x33, 0x37,
             0x79, 0xED, 0xDE, 0x7A, 0x45, 0x93, 0x84, 0xF8,
             0x44, 0x4A, 0xDA, 0xEC, 0xFF, 0xEC, 0x95, 0xFD,
             0x55, 0x2B, 0x0C, 0xFC, 0xB6, 0xC7, 0xF6, 0x92,
             0x62, 0x6D, 0xDE, 0x1E, 0xF2, 0x68, 0xA4, 0x0D,
             0x2F, 0x67, 0xB5, 0xC8, 0xAA, 0x38, 0x7F, 0xF7 },
           /* exponent1 */
           1020,
           { 0x09, 0xED, 0x54, 0xEA, 0xED, 0x98, 0xF8, 0x4C,
             0x55, 0x7B, 0x4A, 0x86, 0xBF, 0x4F, 0x57, 0x84,
             0x93, 0xDC, 0xBC, 0x6B, 0xE9, 0x1D, 0xA1, 0x89,
             0x37, 0x04, 0x04, 0xA9, 0x08, 0x72, 0x76, 0xF4,
             0xCE, 0x51, 0xD8, 0xA1, 0x00, 0xED, 0x85, 0x7D,
             0xC2, 0xB0, 0x64, 0x94, 0x74, 0xF3, 0xF1, 0x5C,
             0xD2, 0x4C, 0x54, 0xDB, 0x28, 0x71, 0x10, 0xE5,
             0x6E, 0x5C, 0xB0, 0x08, 0x68, 0x2F, 0x91, 0x68,
             0xAA, 0x81, 0xF3, 0x14, 0x58, 0xB7, 0x43, 0x1E,
             0xCC, 0x1C, 0x44, 0x90, 0x6F, 0xDA, 0x87, 0xCA,
             0x89, 0x47, 0x10, 0xC3, 0x71, 0xE9, 0x07, 0x6C,
             0x1D, 0x49, 0xFB, 0xAE, 0x51, 0x27, 0x69, 0x34,
             0xF2, 0xAD, 0x78, 0x77, 0x89, 0xF4, 0x2D, 0x0F,
             0xA0, 0xB4, 0xC9, 0x39, 0x85, 0x5D, 0x42, 0x12,
             0x09, 0x6F, 0x70, 0x28, 0x0A, 0x4E, 0xAE, 0x7C,
             0x8A, 0x27, 0xD9, 0xC8, 0xD0, 0x77, 0x2E, 0x65 },
           /* exponent2 */
           1024,
           { 0x8C, 0xB6, 0x85, 0x7A, 0x7B, 0xD5, 0x46, 0x5F,
             0x80, 0x04, 0x7E, 0x9B, 0x87, 0xBC, 0x00, 0x27,
             0x31, 0x84, 0x05, 0x81, 0xE0, 0x62, 0x61, 0x39,
             0x01, 0x2A, 0x5B, 0x50, 0x5F, 0x0A, 0x33, 0x84,
             0x7E, 0xB7, 0xB8, 0xC3, 0x28, 0x99, 0x49, 0xAD,
             0x48, 0x6F, 0x3B, 0x4B, 0x3D, 0x53, 0x9A, 0xB5,
             0xDA, 0x76, 0x30, 0x21, 0xCB, 0xC8, 0x2C, 0x1B,
             0xA2, 0x34, 0xA5, 0x66, 0x8D, 0xED, 0x08, 0x01,
             0xB8, 0x59, 0xF3, 0x43, 0xF1, 0xCE, 0x93, 0x04,
             0xE6, 0xFA, 0xA2, 0xB0, 0x02, 0xCA, 0xD9, 0xB7,
             0x8C, 0xDE, 0x5C, 0xDC, 0x2C, 0x1F, 0xB4, 0x17,
             0x1C, 0x42, 0x42, 0x16, 0x70, 0xA6, 0xAB, 0x0F,
             0x50, 0xCC, 0x4A, 0x19, 0x4E, 0xB3, 0x6D, 0x1C,
             0x91, 0xE9, 0x35, 0xBA, 0x01, 0xB9, 0x59, 0xD8,
             0x72, 0x8B, 0x9E, 0x64, 0x42, 0x6B, 0x3F, 0xC3,
             0xA7, 0x50, 0x6D, 0xEB, 0x52, 0x39, 0xA8, 0xA7 }

Кодированная форма ключа RSA-2048.

   -----BEGIN RSA PRIVATE KEY-----
   MIIEowIBAAKCAQEAsPnoGUOnrpiSqt4XynxA+HRP7S+BSObI6qJ7fQAVSPtRkqso
   tWxQYLEYzNEx5ZSHTGypibVsJylvCfuToDTfMul8b/CZjP2Ob0LdpYrNH6l5hvFE
   89FU1nZQF15oVLOpUgA7wGiHuEVawrGfey92UE68mOyUVXGweJIVDdxqdMoPvNNU
   l86BU02vlBiESxOuox+dWmuVV7vfYZ79Toh/LUK43YvJh+rhv4nKuF7iHjVjBd9s
   B6iDjj70HFldzOQ9r8SRI+9NirupPTkF5AKNe6kUhKJ1luB7S27ZkvB3tSTT3P59
   3VVJvnzOjaA1z6Cz+4+eRvcysqhrRgFlwI9TEwIDAQABAoIBAEEYiyDP29vCzx/+
   dS3LqnI5BjUuJhXUnc6AWX/PCgVAO+8A+gZRgvct7PtZb0sM6P9ZcLrweomlGezI
   FrL0/6xQaa8bBr/ve/a8155OgcjFo6fZEw3Dz7ra5fbSiPmu4/b/kvrg+Br1l77J
   aun6uUAs1f5B9wW+vbR7tzbT/mxaUeDiBzKpe15GwcvbJtdIVMa2YErtRjc1/5B2
   BGVXyvlJv0SIlcIEMsHgnAFOp1ZgQ08aDzvilLq8XVMOahAhP1O2A3X8hKdXPyrx
   IVWE9bS9ptTo+eF6eNl+d7htpKGEZHUxinoQpWEBTv+iOoHsVunkEJ3vjLP3lyI/
   fY0NQ1ECgYEA3RBXAjgvIys2gfU3keImF8e/TprLge1I2vbWmV2j6rZCg5r/AS0u
   pii5CvJ5/T5vfJPNgPBy8B/yRDs+6PJO1GmnlhOkG9JAIPkv0RBZvR0PMBtbp6nT
   Y3yo1lwamBVBfY6rc0sLTzosZh2aGoLzrHNMQFMGaauORzBFpY5lU50CgYEAzPHl
   u5DI6Xgep1vr8QvCUuEesCOgJg8Yh1UqVoY/SmQh6MYAv1I9bLGwrb3WW/7kqIoD
   fj0aQV5buVZI2loMomtU9KY5SFIsPV+JuUpy7/+VE01ZQM5FdY8wiYCQiVZYju9X
   Wz5LxMNoz+gT7pwlLCsC4N+R8aoBk404aF1gum8CgYAJ7VTq7Zj4TFV7Soa/T1eE
   k9y8a+kdoYk3BASpCHJ29M5R2KEA7YV9wrBklHTz8VzSTFTbKHEQ5W5csAhoL5Fo
   qoHzFFi3Qx7MHESQb9qHyolHEMNx6QdsHUn7rlEnaTTyrXh3ifQtD6C0yTmFXUIS
   CW9wKApOrnyKJ9nI0HcuZQKBgQCMtoV6e9VGX4AEfpuHvAAnMYQFgeBiYTkBKltQ
   XwozhH63uMMomUmtSG87Sz1TmrXadjAhy8gsG6I0pWaN7QgBuFnzQ/HOkwTm+qKw
   AsrZt4zeXNwsH7QXHEJCFnCmqw9QzEoZTrNtHJHpNboBuVnYcoueZEJrP8OnUG3r
   UjmopwKBgAqB2KYYMUqAOvYcBnEfLDmyZv9BTVNHbR2lKkMYqv5LlvDaBxVfilE0
   2riO4p6BaAdvzXjKeRrGNEKoHNBpOSfYCOM16NjL8hIZB1CaV3WbT5oY+jp7Mzd5
   7d56RZOE+ERK2uz/7JX9VSsM/LbH9pJibd4e8mikDS9ntciqOH/3
   -----END RSA PRIVATE KEY-----

Ключ RSA-4096 testRSA4096.

           /* n */
           4096,
           { 0xB3, 0x8B, 0x49, 0x60, 0xE6, 0x3B, 0xE6, 0xA8,
             0xDB, 0xA8, 0x9A, 0x82, 0x97, 0x8E, 0xF1, 0xF6,
             0x32, 0x44, 0xE5, 0x57, 0x7D, 0x8C, 0xF5, 0x86,
             0x16, 0xD5, 0xCA, 0x57, 0x59, 0xD4, 0x9C, 0xC8,
             0xD9, 0x36, 0xC3, 0x38, 0xAA, 0x3C, 0xB9, 0xB1,
             0x11, 0xC1, 0x49, 0x7E, 0x5B, 0x51, 0xAF, 0x69,
             0x2F, 0x26, 0x11, 0xE6, 0x89, 0xF7, 0x67, 0x54,
             0x80, 0xC0, 0xB0, 0xF4, 0xC3, 0x65, 0x4F, 0x43,
             0xAF, 0x85, 0xFE, 0x8C, 0x8A, 0xD7, 0x34, 0xE0,
             0x42, 0xA8, 0xAD, 0xA0, 0x5F, 0xD7, 0x65, 0x08,
             0xE0, 0x0B, 0xA0, 0xF7, 0x56, 0xC3, 0x44, 0x3B,
             0xBE, 0x83, 0x3E, 0xA7, 0xD1, 0x00, 0xD4, 0xFB,
             0x36, 0x7E, 0xEB, 0xD6, 0x0B, 0xDB, 0x64, 0x86,
             0x77, 0xFC, 0x7D, 0xEB, 0x94, 0x24, 0x4D, 0xAD,
             0x1A, 0xF8, 0xEE, 0xD1, 0xC6, 0x58, 0x12, 0xC0,
             0x3E, 0x7C, 0x73, 0xF7, 0xF3, 0x58, 0xE9, 0x41,
             0xBC, 0x66, 0x45, 0x8F, 0xF7, 0xBB, 0x97, 0xA4,
             0x9A, 0x98, 0xA1, 0x18, 0x07, 0xE0, 0x2C, 0x1A,
             0x3B, 0x9A, 0xD3, 0x3A, 0x57, 0x3A, 0xE1, 0x80,
             0xE1, 0xFF, 0x43, 0x2A, 0xE5, 0x58, 0x0C, 0xC9,
             0xCA, 0xBF, 0xAB, 0x60, 0x2F, 0x32, 0x5B, 0xCD,
             0xA0, 0x97, 0xE8, 0x7B, 0xC7, 0xA6, 0xD7, 0x4E,
             0x34, 0xA8, 0x7D, 0x60, 0x8A, 0x43, 0xFE, 0xB2,
             0xE4, 0xFF, 0xF1, 0xF4, 0xB8, 0xE7, 0x68, 0x6A,
             0x98, 0x47, 0x5D, 0xB5, 0x1A, 0x6E, 0xBD, 0x08,
             0x17, 0x2A, 0x57, 0x41, 0x77, 0x49, 0x24, 0x8B,
             0x21, 0x55, 0xC8, 0xB9, 0x06, 0xE0, 0xD5, 0x40,
             0xE8, 0xCB, 0x28, 0xF4, 0xC0, 0x0A, 0xDC, 0x9F,
             0xE4, 0x75, 0x8A, 0x1A, 0xC3, 0x64, 0xAB, 0x39,
             0xE4, 0xE1, 0x55, 0x28, 0x98, 0x54, 0x44, 0x15,
             0x3F, 0xEE, 0xC6, 0xAD, 0x4C, 0x53, 0x48, 0xB2,
             0xE3, 0x8F, 0xF5, 0x50, 0xF5, 0xFA, 0x58, 0x33,
             0x97, 0x93, 0x37, 0x30, 0xC8, 0x08, 0x81, 0xBF,
             0x11, 0xEE, 0xE8, 0xFE, 0x38, 0x6D, 0x5B, 0x51,
             0x28, 0x49, 0xA9, 0x83, 0x99, 0x43, 0xAB, 0xF3,
             0xD9, 0x72, 0x20, 0x76, 0x97, 0xB8, 0xEC, 0x24,
             0x11, 0xA2, 0x61, 0x9D, 0x55, 0xCA, 0x04, 0x23,
             0x3C, 0x5A, 0x2C, 0xED, 0xC6, 0xF2, 0x86, 0xD8,
             0x29, 0xD0, 0xE8, 0x37, 0x20, 0x7B, 0x76, 0x52,
             0x9A, 0xA2, 0x44, 0x87, 0x21, 0x26, 0x8D, 0xC0,
             0x15, 0x0B, 0xB7, 0xB0, 0x7E, 0x73, 0x31, 0x3A,
             0x71, 0x3E, 0x58, 0x95, 0xBA, 0xAF, 0x3A, 0xDF,
             0xFA, 0x60, 0x39, 0x58, 0xC5, 0x67, 0xF8, 0x5C,
             0xF2, 0x5B, 0x1D, 0x80, 0xA2, 0x77, 0x56, 0xA3,
             0x0D, 0x1A, 0x50, 0xA1, 0xE4, 0x69, 0x8E, 0xDA,
             0x9A, 0x12, 0x2B, 0xB0, 0xAA, 0x7A, 0x60, 0xF7,
             0xCD, 0x22, 0x6C, 0xB1, 0x16, 0x5C, 0xFC, 0xF9,
             0xCA, 0x83, 0x0A, 0x60, 0x6C, 0xC0, 0xFB, 0x14,
             0x87, 0xF2, 0x49, 0xE5, 0xE0, 0xC7, 0x1C, 0x88,
             0x62, 0x6C, 0x57, 0x12, 0x80, 0x81, 0xDE, 0x76,
             0xC1, 0x23, 0x84, 0xB6, 0xD4, 0x48, 0xB6, 0x7F,
             0x0E, 0x71, 0x23, 0xAE, 0xEF, 0x74, 0xA8, 0x85,
             0x96, 0x03, 0x74, 0x75, 0x54, 0x83, 0xF2, 0x90,
             0xA7, 0xDE, 0x66, 0x46, 0x5E, 0x22, 0x7B, 0x2B,
             0x17, 0x31, 0x8F, 0x8A, 0x49, 0x05, 0x2B, 0x01,
             0x45, 0xFB, 0xA2, 0x83, 0x77, 0x2B, 0xC2, 0x9A,
             0x5B, 0x58, 0x12, 0xAC, 0xCE, 0xE3, 0xAB, 0x62,
             0x81, 0x70, 0x19, 0xE5, 0x48, 0x07, 0xF2, 0x88,
             0x97, 0x12, 0xB7, 0xB8, 0xF3, 0x03, 0xBA, 0x5F,
             0xE1, 0x47, 0xF9, 0xC2, 0xF3, 0x43, 0x4A, 0xB7,
             0x03, 0xC1, 0xD9, 0x46, 0x73, 0x43, 0x82, 0xA0,
             0xA3, 0x53, 0xF4, 0xE0, 0xCB, 0xBE, 0xA2, 0x6A,
             0x4B, 0xBF, 0x21, 0xCE, 0x9E, 0xB5, 0xE7, 0x9D,
             0x47, 0x57, 0xD7, 0xDE, 0x02, 0x7F, 0x20, 0xE5 },
           /* e */
           17,
           { 0x01, 0x00, 0x01 },
           /* d */
           4095,
           { 0x6A, 0xD1, 0xB0, 0xBB, 0x7C, 0xDF, 0x20, 0x91,
             0x4F, 0xF6, 0x94, 0xCE, 0xA3, 0x7B, 0x01, 0x4B,
             0xD7, 0x86, 0x93, 0xE8, 0x24, 0xA3, 0x4B, 0xA4,
             0x16, 0x4B, 0xE5, 0xD1, 0x68, 0x79, 0x8D, 0x3A,
             0x15, 0xB9, 0x76, 0x16, 0x6D, 0x7A, 0x29, 0x84,
             0x46, 0xAA, 0xF7, 0x9D, 0xBC, 0x98, 0xF1, 0xC2,
             0xA3, 0xB1, 0x83, 0xAE, 0xE4, 0x60, 0x94, 0x52,
             0x7B, 0x33, 0xA9, 0x54, 0x46, 0x38, 0x2D, 0x1B,
             0x78, 0xFF, 0x40, 0x7D, 0xBF, 0x50, 0xE0, 0x7D,
             0x98, 0x4B, 0x20, 0xD9, 0xAC, 0x8B, 0xCA, 0xE9,
             0xA7, 0xDA, 0x63, 0x4F, 0x24, 0x88, 0x92, 0x3C,
             0xF5, 0x50, 0xC2, 0x63, 0x37, 0x7E, 0xC6, 0x38,
             0x1B, 0xA9, 0x11, 0x88, 0xCC, 0x8F, 0x1F, 0xD4,
             0xBC, 0xE8, 0x34, 0xC6, 0x86, 0xE1, 0xBE, 0x71,
             0x01, 0xFE, 0x1E, 0xA0, 0x21, 0xE0, 0x5E, 0x6F,
             0x8F, 0xFD, 0x9D, 0x45, 0x64, 0xBB, 0x7E, 0x33,
             0x84, 0xF2, 0x57, 0xEA, 0x9A, 0x9A, 0x3A, 0x53,
             0x4D, 0x43, 0x07, 0x7C, 0xF3, 0x9A, 0x94, 0xC2,
             0x9A, 0xB9, 0xB7, 0x78, 0x1B, 0x53, 0xC5, 0xBC,
             0x57, 0x38, 0xF6, 0x6E, 0x3B, 0xFA, 0xD1, 0xC8,
             0xF0, 0xDE, 0x6E, 0x08, 0x90, 0xAB, 0xE6, 0x60,
             0x85, 0x6E, 0x3B, 0x7C, 0x01, 0x41, 0xAB, 0x11,
             0x35, 0x55, 0x15, 0x1A, 0xED, 0xC8, 0x1C, 0x6D,
             0xB4, 0xBE, 0xED, 0xE6, 0x0A, 0x68, 0x6B, 0x00,
             0x18, 0x4F, 0x45, 0x5A, 0x2D, 0x3A, 0xBB, 0x2E,
             0x68, 0x11, 0xE1, 0xCD, 0xEA, 0x39, 0x53, 0x0B,
             0x8F, 0xAE, 0xA8, 0xF8, 0x24, 0x36, 0x79, 0xC9,
             0xDF, 0x76, 0x97, 0x8C, 0x5E, 0x01, 0x58, 0x57,
             0xAC, 0xA5, 0x9D, 0x9F, 0xE4, 0xA6, 0x2D, 0x15,
             0x09, 0xAE, 0x62, 0x6A, 0xFF, 0x8E, 0x0A, 0xDF,
             0x95, 0xA4, 0xEB, 0x01, 0x49, 0xCA, 0xB7, 0x12,
             0xEF, 0x3E, 0xC3, 0xD6, 0x02, 0x32, 0x8A, 0x6C,
             0x50, 0x21, 0xBA, 0x1B, 0x35, 0xB8, 0x58, 0x3D,
             0x9A, 0x90, 0x40, 0x55, 0x03, 0xF5, 0xFA, 0x0F,
             0x42, 0x4C, 0x72, 0x86, 0x23, 0xFC, 0x81, 0xD3,
             0xDD, 0x7B, 0xFF, 0x1B, 0xF7, 0x8C, 0x8E, 0x2E,
             0xBD, 0x03, 0xA5, 0x11, 0x2D, 0xEB, 0x65, 0x89,
             0x98, 0x6E, 0x49, 0xBD, 0x30, 0x07, 0x1A, 0xD8,
             0x41, 0xA3, 0xCC, 0xA8, 0x07, 0x6C, 0xCF, 0xC7,
             0x94, 0x63, 0x30, 0xB1, 0xFD, 0x1C, 0x21, 0x2A,
             0xD3, 0xEB, 0xD3, 0x7D, 0x9A, 0x4D, 0x0A, 0x96,
             0x95, 0xB8, 0x16, 0x8A, 0x08, 0x89, 0x32, 0x7D,
             0x52, 0x6F, 0x16, 0xD1, 0x56, 0x37, 0xFA, 0x9D,
             0xBF, 0x04, 0xB0, 0xB8, 0x3D, 0xD8, 0xB5, 0xC4,
             0x05, 0x2D, 0xC5, 0x38, 0xB6, 0xCA, 0xE9, 0xC9,
             0x2E, 0xC9, 0x70, 0x10, 0x7A, 0x2F, 0x1E, 0xE4,
             0xD4, 0x7A, 0x65, 0xCC, 0xA5, 0xB9, 0x59, 0x6E,
             0x42, 0x74, 0x91, 0x9B, 0xE7, 0xD1, 0xEC, 0x90,
             0xE4, 0x50, 0xFE, 0x58, 0x58, 0xDC, 0x2E, 0x01,
             0xE8, 0x4E, 0xBD, 0x92, 0x07, 0xD8, 0xEA, 0x20,
             0xFA, 0x37, 0x14, 0x0E, 0x89, 0xD0, 0x10, 0xD6,
             0x50, 0x1F, 0x22, 0x61, 0x97, 0x18, 0x04, 0xDE,
             0x73, 0x68, 0x0F, 0xE6, 0x1C, 0x23, 0x5C, 0x8F,
             0x4E, 0x63, 0x1F, 0xF0, 0x6D, 0xBD, 0xEE, 0x66,
             0x6D, 0xBB, 0x9A, 0xFB, 0xFD, 0xA3, 0xB9, 0x71,
             0xC3, 0x29, 0x0D, 0x7B, 0xDE, 0xF5, 0xC5, 0x78,
             0x5A, 0x07, 0x1B, 0xE9, 0x4A, 0xE1, 0x8A, 0x0B,
             0x2E, 0xD8, 0xAE, 0x67, 0x9A, 0xBA, 0xA6, 0x10,
             0x85, 0x28, 0xA8, 0x5E, 0x31, 0x7F, 0x87, 0xA8,
             0x99, 0xC5, 0x89, 0xF4, 0xA8, 0xAD, 0x42, 0x90,
             0xA6, 0xCA, 0x1E, 0xF9, 0xF1, 0x4D, 0x8D, 0x0A,
             0x7A, 0x66, 0xDC, 0x75, 0x0B, 0x69, 0xB1, 0x9C,
             0xB2, 0x58, 0x28, 0xC3, 0xEA, 0xF0, 0x42, 0x21,
             0x5C, 0x09, 0xAA, 0xD4, 0xA9, 0x54, 0xE8, 0x55 },
           /* p */
           2048,
           { 0xE0, 0x41, 0xBD, 0xF1, 0xC9, 0xB5, 0x69, 0xAC,
             0xF5, 0xE8, 0x02, 0x2D, 0x21, 0x1B, 0x87, 0x1B,
             0x5F, 0x29, 0x21, 0x41, 0xA5, 0x89, 0xFD, 0x0F,
             0x6D, 0xCB, 0x59, 0x47, 0x6B, 0x1C, 0x1D, 0xA4,
             0x01, 0x8D, 0xD7, 0xA1, 0xE1, 0x08, 0x39, 0x32,
             0x74, 0x5E, 0xF3, 0xC6, 0x6C, 0xF7, 0xFF, 0x31,
             0x3E, 0xED, 0x4C, 0xB1, 0x68, 0x1D, 0xEF, 0x9D,
             0x29, 0xCC, 0x3F, 0xE8, 0x7A, 0xF7, 0xAD, 0x19,
             0xE9, 0xEF, 0x34, 0x56, 0x62, 0xC9, 0xC4, 0xF4,
             0xE6, 0xE7, 0x07, 0xAA, 0x4E, 0x99, 0x49, 0x63,
             0x4C, 0x08, 0x64, 0x71, 0xA5, 0x5B, 0x67, 0x46,
             0xC2, 0xAE, 0xEF, 0x87, 0x71, 0xEF, 0x21, 0xA2,
             0xEE, 0x8A, 0xB4, 0xDE, 0xC4, 0xC2, 0x04, 0x3C,
             0x70, 0xCF, 0xBA, 0x89, 0xE5, 0xEB, 0x2F, 0x62,
             0xEA, 0x07, 0xC7, 0x4B, 0xD4, 0x16, 0x67, 0x69,
             0x12, 0xA9, 0x58, 0x9F, 0xB3, 0xED, 0x70, 0x28,
             0x8F, 0x8A, 0x03, 0xD1, 0x91, 0xC5, 0x8A, 0x88,
             0x96, 0xE8, 0xB2, 0x0F, 0x1E, 0xDE, 0x91, 0x80,
             0xCE, 0xD3, 0x03, 0x59, 0xF7, 0x5F, 0x48, 0xAF,
             0xE9, 0x7C, 0x46, 0xEE, 0x59, 0xC9, 0x27, 0x1E,
             0x71, 0x37, 0x55, 0x4A, 0xD7, 0x05, 0x56, 0x17,
             0x84, 0x8F, 0xD3, 0x04, 0x1C, 0xD6, 0x30, 0x47,
             0xF6, 0x46, 0x2C, 0x0E, 0x66, 0xE1, 0x83, 0x9F,
             0x63, 0xC6, 0x12, 0xD4, 0xA3, 0x57, 0xF5, 0xE5,
             0x76, 0x35, 0x6A, 0xAA, 0xE7, 0xC6, 0x4A, 0xC0,
             0xBF, 0xD9, 0xD6, 0x5E, 0xDF, 0x4B, 0x2F, 0x34,
             0xDA, 0xDB, 0xDF, 0x69, 0x06, 0x20, 0xC8, 0x95,
             0xCA, 0x44, 0xD9, 0x61, 0xDA, 0x05, 0xB1, 0x36,
             0x2B, 0x4A, 0xD5, 0xDA, 0xAC, 0xB9, 0x0F, 0xF5,
             0x86, 0x33, 0x5E, 0xCD, 0x7E, 0x1D, 0x7A, 0x16,
             0x00, 0xCB, 0x1A, 0xB3, 0x72, 0x69, 0x5B, 0x6E,
             0xC7, 0x71, 0x76, 0x21, 0xDB, 0xBE, 0x93, 0x57 },
           /* q */
           2048,
           { 0xCC, 0xF5, 0x51, 0x29, 0xD3, 0xB9, 0x24, 0xC8,
             0x38, 0xA7, 0x6C, 0xD3, 0x69, 0xD4, 0x6E, 0x9C,
             0xB8, 0x13, 0xFE, 0x3B, 0x39, 0xBA, 0xF1, 0xEB,
             0x10, 0x18, 0x47, 0xD3, 0x1D, 0x09, 0x13, 0x50,
             0x03, 0xAB, 0x2F, 0xC2, 0x39, 0x43, 0x1C, 0xDA,
             0x6E, 0x99, 0x08, 0x88, 0x3D, 0xE8, 0xA0, 0x54,
             0x6E, 0x35, 0x28, 0x37, 0xD4, 0xEB, 0x95, 0xCB,
             0x41, 0xD8, 0xEE, 0xC1, 0x4A, 0x66, 0xCD, 0x38,
             0xC2, 0x24, 0x7E, 0x82, 0xA3, 0x94, 0x39, 0x29,
             0x27, 0xBB, 0xF5, 0x70, 0xA8, 0x65, 0x5E, 0x0F,
             0x2A, 0xC2, 0x43, 0xE5, 0xFB, 0x87, 0x6F, 0xD2,
             0x0B, 0x48, 0x76, 0x73, 0xA2, 0x77, 0x2D, 0xA9,
             0x70, 0xC1, 0xDF, 0x47, 0xA3, 0x2D, 0xEA, 0x8A,
             0x75, 0xE7, 0x09, 0x54, 0x73, 0x22, 0x9C, 0x69,
             0x3C, 0x88, 0x6A, 0x31, 0x6D, 0x2C, 0xEC, 0xBF,
             0x03, 0x59, 0x7B, 0x04, 0xCA, 0x9E, 0xCA, 0xBD,
             0xA3, 0x36, 0x6E, 0x07, 0x64, 0x88, 0x05, 0x9B,
             0x24, 0x59, 0x6F, 0x5D, 0xF6, 0xE8, 0x56, 0x97,
             0xDB, 0xE6, 0x2A, 0xB2, 0xF8, 0xCC, 0x71, 0xAC,
             0x7F, 0x74, 0x3B, 0x64, 0x12, 0x6D, 0x01, 0xF2,
             0xB3, 0x61, 0x27, 0x16, 0xEC, 0xA7, 0x69, 0x75,
             0xE5, 0x14, 0xED, 0x4D, 0x78, 0xA3, 0x22, 0x90,
             0xBE, 0x0A, 0x82, 0xF1, 0x44, 0x14, 0x99, 0x2B,
             0xD1, 0x80, 0x3D, 0xAD, 0xC9, 0x83, 0xDD, 0xF2,
             0x76, 0xD2, 0xCA, 0xE1, 0xA0, 0xA9, 0x03, 0xF9,
             0x1E, 0x78, 0xBE, 0x3C, 0x0B, 0xCA, 0xF5, 0x8F,
             0x3C, 0xE9, 0x8D, 0x12, 0x3A, 0xA6, 0xC8, 0x5F,
             0x65, 0x51, 0xC5, 0x70, 0x07, 0xFE, 0x47, 0x7A,
             0xC8, 0x7E, 0x03, 0x8B, 0x9A, 0x94, 0xAC, 0xC6,
             0x20, 0xDE, 0x12, 0x25, 0x81, 0x05, 0x34, 0x4A,
             0x0C, 0xFB, 0x37, 0x65, 0x50, 0x5E, 0x8E, 0x7E,
             0xC8, 0x6A, 0xC0, 0x86, 0xF6, 0x55, 0x64, 0x23 },
           /* u */
           2048,
           { 0xD1, 0x0C, 0x91, 0x8D, 0xA9, 0xF2, 0x6D, 0xA9,
             0x4D, 0xFF, 0x3B, 0x09, 0x24, 0x3C, 0x8C, 0xC3,
             0xD4, 0x39, 0x02, 0x6D, 0xE6, 0x2B, 0x9E, 0x9F,
             0x37, 0xAC, 0x60, 0xBB, 0xD7, 0xA9, 0x52, 0xCB,
             0x07, 0x84, 0x94, 0xBD, 0x73, 0x7E, 0xCC, 0x3A,
             0x65, 0x0C, 0x93, 0xC4, 0x2E, 0xD7, 0xF6, 0x49,
             0x02, 0x07, 0xAE, 0x99, 0x6B, 0x3C, 0xD1, 0xFF,
             0x1F, 0x4D, 0x63, 0x9D, 0x61, 0xDD, 0xD1, 0xE7,
             0x12, 0x8D, 0x56, 0x3C, 0x1C, 0x16, 0xC8, 0xB3,
             0x9D, 0x94, 0xD5, 0xDE, 0x5E, 0x93, 0x7F, 0xE6,
             0x5A, 0x38, 0xB8, 0x19, 0xE4, 0x69, 0xF8, 0x8C,
             0x3C, 0xE0, 0x25, 0x21, 0xE2, 0xAD, 0xA9, 0xE3,
             0x46, 0xE6, 0xA1, 0xBD, 0x51, 0x27, 0xC7, 0xBD,
             0xB2, 0x1D, 0xA2, 0xC6, 0x11, 0xE3, 0x5F, 0x6C,
             0x89, 0xE7, 0xDD, 0x66, 0xA0, 0x66, 0xCB, 0x23,
             0x3E, 0xF9, 0x6B, 0xAD, 0x1A, 0xD3, 0x99, 0x94,
             0x0C, 0xAD, 0x05, 0x5A, 0xDF, 0x5C, 0x58, 0x79,
             0xF8, 0x30, 0xA8, 0x08, 0x3C, 0xA6, 0xD6, 0xC0,
             0x58, 0x58, 0xC2, 0x66, 0x03, 0x0A, 0x33, 0xBF,
             0xB4, 0xAD, 0x83, 0xB5, 0xCC, 0x92, 0x9F, 0x2F,
             0x6C, 0xA2, 0x1E, 0x50, 0x29, 0x54, 0x2B, 0x8A,
             0xEB, 0xE7, 0x6B, 0x69, 0x44, 0xE1, 0x86, 0x3E,
             0x39, 0x47, 0x3B, 0x6E, 0xD9, 0xAD, 0x92, 0x6A,
             0x7D, 0xBF, 0xE2, 0xC7, 0x28, 0xE2, 0x3C, 0x74,
             0xF6, 0x9B, 0xB0, 0xE0, 0x54, 0xF1, 0x9F, 0x14,
             0x6C, 0xE1, 0x9E, 0x1D, 0x23, 0x6B, 0x65, 0x34,
             0x30, 0xA7, 0x1D, 0xC4, 0xA7, 0x4A, 0xE2, 0x0E,
             0x0D, 0x14, 0x13, 0x31, 0x66, 0xA1, 0x8A, 0xDF,
             0x6E, 0xF7, 0xFE, 0xD9, 0x5C, 0xC4, 0x64, 0x35,
             0xFF, 0x4C, 0x96, 0x23, 0x2B, 0xD5, 0x64, 0x03,
             0xCC, 0x39, 0xFB, 0x16, 0xAD, 0xF2, 0x24, 0xB4,
             0xFD, 0xEB, 0x8A, 0xBA, 0xF4, 0x91, 0x31, 0xBF },
           /* exponent1 */
           2046,
           { 0x2F, 0x7C, 0x1C, 0x31, 0x37, 0x69, 0xCF, 0x6F,
             0x8D, 0x3E, 0x4C, 0x3F, 0xAC, 0x13, 0xFD, 0x1E,
             0xC1, 0x9E, 0x9E, 0xE9, 0x1C, 0x99, 0x44, 0x59,
             0x61, 0x01, 0x3E, 0xED, 0x4D, 0x73, 0xCD, 0x9E,
             0xED, 0xA9, 0x50, 0x30, 0x79, 0xCA, 0xD8, 0xF9,
             0xA3, 0x04, 0x7C, 0x0F, 0xD7, 0x01, 0x08, 0x2B,
             0x30, 0x4C, 0xE5, 0x01, 0x67, 0xAF, 0x77, 0x0E,
             0x4B, 0x4C, 0x71, 0x77, 0xD3, 0x99, 0xE0, 0x30,
             0x6D, 0x85, 0x76, 0x0A, 0x98, 0xAE, 0x6A, 0xA3,
             0x04, 0xC5, 0x84, 0xAC, 0xFE, 0x29, 0x9D, 0x0D,
             0x86, 0x8A, 0xFC, 0x61, 0xC8, 0x06, 0xBB, 0xAE,
             0x93, 0x08, 0xA1, 0xB5, 0x87, 0x5D, 0x80, 0x3C,
             0xD4, 0xCF, 0xD0, 0x0E, 0x9F, 0x91, 0x09, 0x7E,
             0x96, 0xD0, 0x95, 0x8A, 0x1F, 0x82, 0x16, 0x2D,
             0x96, 0xAA, 0x80, 0xFB, 0xC0, 0x73, 0xE1, 0xFF,
             0xB0, 0xB0, 0xE5, 0x10, 0x23, 0xF4, 0x31, 0xDC,
             0x94, 0xD0, 0x3F, 0x90, 0xBF, 0x92, 0x19, 0x8C,
             0x64, 0x8F, 0xEF, 0x2C, 0x1E, 0x78, 0x38, 0x4D,
             0x12, 0xFE, 0x41, 0x66, 0x6A, 0x67, 0xE5, 0xA7,
             0x42, 0x04, 0x4B, 0xAC, 0xAA, 0x9C, 0x5A, 0x49,
             0x2A, 0xE5, 0xF1, 0x8C, 0x80, 0x4D, 0x23, 0xF6,
             0xA4, 0xDE, 0x23, 0x6B, 0x6A, 0x83, 0xBC, 0x03,
             0x70, 0xD5, 0x58, 0xFC, 0xCF, 0xB2, 0x0E, 0xC1,
             0xD0, 0x49, 0x9F, 0xB1, 0x20, 0xC9, 0x3E, 0x4B,
             0x11, 0x25, 0xAC, 0x69, 0x75, 0xDC, 0x59, 0xF5,
             0xC8, 0x69, 0xE2, 0xE7, 0x81, 0xD6, 0x94, 0xAF,
             0x57, 0x6C, 0x59, 0x39, 0x0E, 0xD0, 0x20, 0x48,
             0xFF, 0x64, 0x66, 0xB7, 0x3E, 0x88, 0x18, 0x07,
             0x05, 0x51, 0xBA, 0x48, 0xAC, 0x6C, 0x1F, 0x41,
             0xF8, 0xE1, 0xA5, 0xC0, 0x53, 0x65, 0x00, 0x75,
             0xEA, 0x43, 0x17, 0x6B, 0x49, 0xDD, 0x9F, 0x3B,
             0xAC, 0xC5, 0x8C, 0xA3, 0x0C, 0xB9, 0xA4, 0xCF },
           /* exponent2 */
           2047,
           { 0x57, 0x5A, 0x87, 0x09, 0x28, 0xAF, 0xD4, 0x39,
             0x71, 0xCC, 0x09, 0xD9, 0xE1, 0x55, 0x24, 0xFF,
             0xAE, 0x84, 0xF6, 0xEA, 0x0F, 0x24, 0xDA, 0x4E,
             0xB1, 0x41, 0x67, 0xFB, 0x56, 0x78, 0xB3, 0xBE,
             0x7A, 0x91, 0xCF, 0x7D, 0x1C, 0x22, 0xBA, 0x7D,
             0x6E, 0x7D, 0xD2, 0xE1, 0x1E, 0x61, 0xB3, 0x53,
             0xC8, 0xD4, 0xE7, 0x1B, 0x44, 0xA8, 0x53, 0xE3,
             0x99, 0x60, 0xF8, 0x01, 0x71, 0xD0, 0x76, 0xCF,
             0x26, 0x0F, 0x9F, 0xCB, 0xD6, 0x24, 0x2A, 0x68,
             0x9C, 0x02, 0xC4, 0x0D, 0x0B, 0xF8, 0x88, 0x2A,
             0x36, 0xB3, 0x2D, 0x75, 0x2B, 0xCB, 0x01, 0xA1,
             0xA8, 0x25, 0x6E, 0x36, 0xC2, 0x9B, 0xC0, 0xDE,
             0x62, 0xAC, 0x7E, 0x99, 0x6D, 0xB6, 0xF8, 0x2B,
             0xA3, 0x2C, 0xA1, 0x11, 0x59, 0x30, 0xFB, 0x30,
             0xEF, 0x17, 0xC5, 0x0A, 0xE3, 0xD9, 0x2D, 0xDE,
             0x0B, 0x73, 0x6B, 0xB7, 0x13, 0x14, 0xB2, 0x9C,
             0x38, 0x9F, 0xCE, 0x2D, 0x60, 0x6F, 0x88, 0xD4,
             0x22, 0x9D, 0xEB, 0x95, 0x44, 0xD2, 0xA9, 0x75,
             0x77, 0xC7, 0x95, 0x93, 0x49, 0xEE, 0xF8, 0xD3,
             0xE8, 0x4E, 0x85, 0xB1, 0x95, 0x18, 0xD8, 0xA7,
             0xB4, 0x44, 0x48, 0x00, 0xC1, 0x44, 0x68, 0xF2,
             0x52, 0x7C, 0xA4, 0xD7, 0x4B, 0xFF, 0x5B, 0x90,
             0x0D, 0x2F, 0x35, 0xB7, 0xD6, 0xA8, 0x60, 0xD0,
             0x08, 0x2E, 0x7C, 0x1B, 0x41, 0xB3, 0xEE, 0x38,
             0x94, 0xE4, 0x2A, 0x8C, 0x17, 0x89, 0x71, 0xA4,
             0x0F, 0x94, 0xAE, 0x9F, 0xB0, 0xF7, 0x03, 0xC9,
             0xD4, 0xD0, 0x45, 0xCB, 0xEB, 0x2B, 0x82, 0x63,
             0x06, 0x2F, 0xDF, 0xD2, 0x6B, 0xD5, 0xB8, 0x69,
             0x60, 0x62, 0x34, 0xE8, 0x9F, 0x2D, 0x96, 0xA5,
             0xAB, 0x04, 0x7A, 0xFF, 0x79, 0x09, 0xDA, 0xCB,
             0x64, 0xD4, 0xFD, 0x3B, 0x35, 0x11, 0xD7, 0xF1,
             0xB9, 0x41, 0xA6, 0x64, 0xDF, 0x40, 0x6D, 0xB9 }

Кодированная форма ключа RSA-4096.

   -----BEGIN RSA PRIVATE KEY-----
   MIIJKAIBAAKCAgEAs4tJYOY75qjbqJqCl47x9jJE5Vd9jPWGFtXKV1nUnMjZNsM4
   qjy5sRHBSX5bUa9pLyYR5on3Z1SAwLD0w2VPQ6+F/oyK1zTgQqitoF/XZQjgC6D3
   VsNEO76DPqfRANT7Nn7r1gvbZIZ3/H3rlCRNrRr47tHGWBLAPnxz9/NY6UG8ZkWP
   97uXpJqYoRgH4CwaO5rTOlc64YDh/0Mq5VgMycq/q2AvMlvNoJfoe8em1040qH1g
   ikP+suT/8fS452hqmEddtRpuvQgXKldBd0kkiyFVyLkG4NVA6Mso9MAK3J/kdYoa
   w2SrOeThVSiYVEQVP+7GrUxTSLLjj/VQ9fpYM5eTNzDICIG/Ee7o/jhtW1EoSamD
   mUOr89lyIHaXuOwkEaJhnVXKBCM8WiztxvKG2CnQ6Dcge3ZSmqJEhyEmjcAVC7ew
   fnMxOnE+WJW6rzrf+mA5WMVn+FzyWx2AondWow0aUKHkaY7amhIrsKp6YPfNImyx
   Flz8+cqDCmBswPsUh/JJ5eDHHIhibFcSgIHedsEjhLbUSLZ/DnEjru90qIWWA3R1
   VIPykKfeZkZeInsrFzGPikkFKwFF+6KDdyvCmltYEqzO46tigXAZ5UgH8oiXEre4
   8wO6X+FH+cLzQ0q3A8HZRnNDgqCjU/Tgy76iaku/Ic6eteedR1fX3gJ/IOUCAwEA
   AQKCAgBq0bC7fN8gkU/2lM6jewFL14aT6CSjS6QWS+XRaHmNOhW5dhZteimERqr3
   nbyY8cKjsYOu5GCUUnszqVRGOC0beP9Afb9Q4H2YSyDZrIvK6afaY08kiJI89VDC
   Yzd+xjgbqRGIzI8f1LzoNMaG4b5xAf4eoCHgXm+P/Z1FZLt+M4TyV+qamjpTTUMH
   fPOalMKaubd4G1PFvFc49m47+tHI8N5uCJCr5mCFbjt8AUGrETVVFRrtyBxttL7t
   5gpoawAYT0VaLTq7LmgR4c3qOVMLj66o+CQ2ecnfdpeMXgFYV6ylnZ/kpi0VCa5i
   av+OCt+VpOsBScq3Eu8+w9YCMopsUCG6GzW4WD2akEBVA/X6D0JMcoYj/IHT3Xv/
   G/eMji69A6URLetliZhuSb0wBxrYQaPMqAdsz8eUYzCx/RwhKtPr032aTQqWlbgW
   igiJMn1SbxbRVjf6nb8EsLg92LXEBS3FOLbK6ckuyXAQei8e5NR6ZcyluVluQnSR
   m+fR7JDkUP5YWNwuAehOvZIH2Oog+jcUDonQENZQHyJhlxgE3nNoD+YcI1yPTmMf
   8G297mZtu5r7/aO5ccMpDXve9cV4Wgcb6Urhigsu2K5nmrqmEIUoqF4xf4eomcWJ
   9KitQpCmyh758U2NCnpm3HULabGcslgow+rwQiFcCarUqVToVQKCAQEA4EG98cm1
   aaz16AItIRuHG18pIUGlif0PbctZR2scHaQBjdeh4Qg5MnRe88Zs9/8xPu1MsWgd
   750pzD/oevetGenvNFZiycT05ucHqk6ZSWNMCGRxpVtnRsKu74dx7yGi7oq03sTC
   BDxwz7qJ5esvYuoHx0vUFmdpEqlYn7PtcCiPigPRkcWKiJbosg8e3pGAztMDWfdf
   SK/pfEbuWcknHnE3VUrXBVYXhI/TBBzWMEf2RiwOZuGDn2PGEtSjV/XldjVqqufG
   SsC/2dZe30svNNrb32kGIMiVykTZYdoFsTYrStXarLkP9YYzXs1+HXoWAMsas3Jp
   W27HcXYh276TVwKCAQEAzPVRKdO5JMg4p2zTadRunLgT/js5uvHrEBhH0x0JE1AD
   qy/COUMc2m6ZCIg96KBUbjUoN9TrlctB2O7BSmbNOMIkfoKjlDkpJ7v1cKhlXg8q
   wkPl+4dv0gtIdnOidy2pcMHfR6Mt6op15wlUcyKcaTyIajFtLOy/A1l7BMqeyr2j
   Nm4HZIgFmyRZb1326FaX2+YqsvjMcax/dDtkEm0B8rNhJxbsp2l15RTtTXijIpC+
   CoLxRBSZK9GAPa3Jg93ydtLK4aCpA/keeL48C8r1jzzpjRI6pshfZVHFcAf+R3rI
   fgOLmpSsxiDeEiWBBTRKDPs3ZVBejn7IasCG9lVkIwKCAQAvfBwxN2nPb40+TD+s
   E/0ewZ6e6RyZRFlhAT7tTXPNnu2pUDB5ytj5owR8D9cBCCswTOUBZ693DktMcXfT
   meAwbYV2CpiuaqMExYSs/imdDYaK/GHIBruukwihtYddgDzUz9AOn5EJfpbQlYof
   ghYtlqqA+8Bz4f+wsOUQI/Qx3JTQP5C/khmMZI/vLB54OE0S/kFmamflp0IES6yq
   nFpJKuXxjIBNI/ak3iNraoO8A3DVWPzPsg7B0EmfsSDJPksRJaxpddxZ9chp4ueB
   1pSvV2xZOQ7QIEj/ZGa3PogYBwVRukisbB9B+OGlwFNlAHXqQxdrSd2fO6zFjKMM
   uaTPAoIBAFdahwkor9Q5ccwJ2eFVJP+uhPbqDyTaTrFBZ/tWeLO+epHPfRwiun1u
   fdLhHmGzU8jU5xtEqFPjmWD4AXHQds8mD5/L1iQqaJwCxA0L+IgqNrMtdSvLAaGo
   JW42wpvA3mKsfplttvgroyyhEVkw+zDvF8UK49kt3gtza7cTFLKcOJ/OLWBviNQi
   neuVRNKpdXfHlZNJ7vjT6E6FsZUY2Ke0REgAwURo8lJ8pNdL/1uQDS81t9aoYNAI
   LnwbQbPuOJTkKowXiXGkD5Sun7D3A8nU0EXL6yuCYwYv39Jr1bhpYGI06J8tlqWr
   BHr/eQnay2TU/Ts1EdfxuUGmZN9AbbkCggEBANEMkY2p8m2pTf87CSQ8jMPUOQJt
   5iuenzesYLvXqVLLB4SUvXN+zDplDJPELtf2SQIHrplrPNH/H01jnWHd0ecSjVY8
   HBbIs52U1d5ek3/mWji4GeRp+Iw84CUh4q2p40bmob1RJ8e9sh2ixhHjX2yJ591m
   oGbLIz75a60a05mUDK0FWt9cWHn4MKgIPKbWwFhYwmYDCjO/tK2DtcySny9soh5Q
   KVQriuvna2lE4YY+OUc7btmtkmp9v+LHKOI8dPabsOBU8Z8UbOGeHSNrZTQwpx3E
   p0riDg0UEzFmoYrfbvf+2VzEZDX/TJYjK9VkA8w5+xat8iS0/euKuvSRMb8=
   -----END RSA PRIVATE KEY-----

2.2. Ключи DLP

Ниже представлены общеизвестные тестовые ключи для алгоритмов на основе DLP, таких как DSA, DH, Elgamal.

Ключ DLP-1024 testDLP1024.

           /* p */
           1018,
           { 0x03, 0x0C, 0xDF, 0xC3, 0x8F, 0xC3, 0xE4, 0x21,
             0x27, 0x90, 0xB0, 0xA4, 0x1E, 0x45, 0xB4, 0xE4,
             0xE8, 0x80, 0xDE, 0x8A, 0xBF, 0xD3, 0xAE, 0xCA,
             0x0B, 0x23, 0x8F, 0xB6, 0xCD, 0x73, 0x0C, 0xC3,
             0x18, 0x76, 0x93, 0x36, 0xD5, 0xB1, 0x80, 0xB2,
             0x80, 0x2A, 0x01, 0xBE, 0x4B, 0xC1, 0xAB, 0x84,
             0xFC, 0xE2, 0xFF, 0x48, 0x9B, 0x50, 0xC2, 0xD2,
             0x9D, 0xE9, 0x1E, 0xC0, 0xE6, 0x5B, 0x60, 0x64,
             0xFD, 0x0D, 0xE5, 0x37, 0xEA, 0xBA, 0x1C, 0x6C,
             0xDD, 0x27, 0xDC, 0x30, 0x30, 0x48, 0x1E, 0x8B,
             0xB9, 0x60, 0xAA, 0x8B, 0x8A, 0xEF, 0x93, 0x35,
             0x30, 0xE6, 0xB1, 0xCC, 0x51, 0x60, 0xBB, 0xFA,
             0xAF, 0x85, 0x0F, 0xF6, 0x57, 0x81, 0x12, 0x33,
             0x7D, 0x53, 0x03, 0x4E, 0x41, 0x63, 0xDC, 0x65,
             0x03, 0xBD, 0xF8, 0x89, 0x25, 0x81, 0x14, 0x1F,
             0xAB, 0x82, 0x55, 0xB6, 0xD9, 0x72, 0x7B, 0xB3 },
           /* q */
           160,
           { 0xEC, 0x41, 0xB9, 0xC0, 0x62, 0x1D, 0x5B, 0xDC,
             0xAF, 0x11, 0xD5, 0x19, 0x8F, 0x72, 0x08, 0x88,
             0x2E, 0x65, 0xBB, 0xDF },
           /* g */
           1017,
           { 0x01, 0x64, 0x87, 0xAC, 0xCF, 0xCD, 0x95, 0x50,
             0x51, 0xE0, 0x6E, 0x1C, 0x5B, 0xEF, 0x45, 0x2C,
             0x12, 0x63, 0xC7, 0x5D, 0x2B, 0x36, 0x50, 0x4F,
             0xB4, 0x27, 0x57, 0x35, 0xC2, 0x83, 0x32, 0x0B,
             0x63, 0xAC, 0x91, 0xC6, 0xF4, 0x02, 0x09, 0x32,
             0x53, 0x1C, 0xAB, 0x04, 0xB1, 0xCD, 0x72, 0xFD,
             0xF2, 0x9D, 0xE2, 0x4E, 0x27, 0x17, 0x97, 0xA7,
             0xDD, 0x21, 0x97, 0x67, 0x69, 0x31, 0xF9, 0x33,
             0x1D, 0x1F, 0x59, 0xEE, 0xE5, 0xBA, 0x2C, 0x7D,
             0x54, 0xAE, 0x13, 0x5C, 0x7F, 0x79, 0x41, 0x37,
             0xD8, 0xD8, 0x0E, 0xB6, 0x29, 0x28, 0x8E, 0x26,
             0x8A, 0x3B, 0xEB, 0xD2, 0x1F, 0x16, 0xA4, 0x03,
             0xF1, 0xD5, 0xDA, 0xD8, 0x3C, 0x1C, 0x47, 0x80,
             0x17, 0xA3, 0xCD, 0x26, 0x6F, 0x1B, 0xA4, 0x9B,
             0x89, 0x0D, 0xC0, 0x89, 0x21, 0x2E, 0x72, 0x26,
             0x1D, 0xA3, 0x67, 0xAF, 0x80, 0x3B, 0x02, 0x50 },
           /* x */
           157,
           { 0x11, 0xED, 0x99, 0x78, 0x5A, 0x81, 0x3A, 0x1B,
             0x0E, 0x96, 0xEC, 0xD3, 0x8D, 0x7F, 0x9B, 0xCE,
             0x9E, 0xBF, 0xD6, 0xFA },
           /* y */
           1018,
           { 0x02, 0x20, 0xB9, 0x42, 0xC2, 0x5C, 0x44, 0xDA,
             0x52, 0xB0, 0xD1, 0x76, 0x82, 0xEA, 0xC4, 0x36,
             0xEA, 0x7E, 0x81, 0xEC, 0x9F, 0x76, 0xE1, 0x05,
             0x75, 0x32, 0xAA, 0x67, 0xEA, 0xDD, 0x04, 0xAD,
             0xB8, 0xFD, 0x61, 0x81, 0xBA, 0x0B, 0x25, 0xF2,
             0x84, 0xDA, 0xAA, 0xAA, 0x05, 0xF3, 0xC8, 0x40,
             0x34, 0xD4, 0x17, 0xD3, 0x7B, 0x6E, 0x0A, 0x63,
             0x31, 0x8A, 0x0A, 0x79, 0x1F, 0x1D, 0x0D, 0xD4,
             0xF6, 0x8A, 0xFA, 0xE3, 0x35, 0xAA, 0x5D, 0xBE,
             0xA3, 0xF2, 0xF6, 0xD6, 0xDD, 0x73, 0x09, 0x26,
             0x24, 0x7F, 0xDC, 0x4D, 0x1B, 0x82, 0xDF, 0x8C,
             0x2D, 0x87, 0xAE, 0x8D, 0x36, 0xAD, 0xB9, 0xDD,
             0x25, 0x13, 0x57, 0x8E, 0x8B, 0x99, 0xAA, 0x6A,
             0x0E, 0xDF, 0x67, 0x5F, 0xFC, 0x2F, 0xDE, 0xB6,
             0x4B, 0x26, 0xE5, 0xBE, 0xD8, 0x53, 0x2D, 0xFD,
             0x98, 0x11, 0x0F, 0xCF, 0xC9, 0xED, 0xF9, 0x38 }

Кодированная форма ключа DLP-1024.

   -----BEGIN DSA PRIVATE KEY-----
   MIIBuQIBAAKBgAMM38OPw+QhJ5CwpB5FtOTogN6Kv9Ouygsjj7bNcwzDGHaTNtWx
   gLKAKgG+S8GrhPzi/0ibUMLSnekewOZbYGT9DeU36rocbN0n3DAwSB6LuWCqi4rv
   kzUw5rHMUWC7+q+FD/ZXgRIzfVMDTkFj3GUDvfiJJYEUH6uCVbbZcnuzAhUA7EG5
   wGIdW9yvEdUZj3IIiC5lu98CgYABZIesz82VUFHgbhxb70UsEmPHXSs2UE+0J1c1
   woMyC2Oskcb0AgkyUxyrBLHNcv3yneJOJxeXp90hl2dpMfkzHR9Z7uW6LH1UrhNc
   f3lBN9jYDrYpKI4mijvr0h8WpAPx1drYPBxHgBejzSZvG6SbiQ3AiSEuciYdo2ev
   gDsCUAKBgAIguULCXETaUrDRdoLqxDbqfoHsn3bhBXUyqmfq3QStuP1hgboLJfKE
   2qqqBfPIQDTUF9N7bgpjMYoKeR8dDdT2ivrjNapdvqPy9tbdcwkmJH/cTRuC34wt
   h66NNq253SUTV46LmapqDt9nX/wv3rZLJuW+2FMt/ZgRD8/J7fk4AhQR7Zl4WoE6
   Gw6W7NONf5vOnr/W+g==
   -----END DSA PRIVATE KEY-----

Ключ DLP-2048 testDLP2048.

           /* p */
           2042,
           { 0x03, 0x2D, 0xD5, 0x53, 0x7D, 0x33, 0x7A, 0x91,
             0x34, 0x37, 0xD3, 0x5E, 0xA3, 0x43, 0x3D, 0xB0,
             0xE7, 0xB7, 0x21, 0x29, 0x8F, 0xBA, 0x87, 0x27,
             0xF2, 0xF9, 0xBE, 0x85, 0x6D, 0x6A, 0x14, 0x6B,
             0x92, 0x98, 0x8D, 0x50, 0x82, 0xF2, 0xC5, 0x72,
             0xB7, 0x70, 0x37, 0x63, 0xE8, 0x24, 0x54, 0xA7,
             0xA4, 0xA2, 0x25, 0x9B, 0x29, 0xAC, 0xE9, 0xB0,
             0xBC, 0x9B, 0x4B, 0x4D, 0x98, 0x5D, 0x6A, 0x9C,
             0x8C, 0xB6, 0x30, 0xE4, 0xE0, 0x9F, 0x48, 0x07,
             0x9F, 0x1B, 0xE8, 0x07, 0x69, 0x71, 0xDE, 0x92,
             0x68, 0x56, 0x70, 0xB9, 0x4C, 0xC9, 0x68, 0x7D,
             0xDC, 0x23, 0x3B, 0x30, 0xAF, 0x22, 0x94, 0xB0,
             0x30, 0xA6, 0xB4, 0x97, 0xF6, 0x46, 0xF9, 0x4E,
             0x1C, 0x17, 0xE8, 0x3A, 0x90, 0x4C, 0x2C, 0x1B,
             0x68, 0x44, 0x10, 0xCE, 0x04, 0x8F, 0xD9, 0xCD,
             0x64, 0x05, 0xA1, 0x4A, 0xA6, 0x8C, 0x2B, 0x8F,
             0x7F, 0x8B, 0xD0, 0x6E, 0x9F, 0x64, 0xC4, 0xBB,
             0x69, 0xCC, 0xBF, 0xBC, 0x80, 0x56, 0xAE, 0x41,
             0x4A, 0x8B, 0x2E, 0x35, 0xD6, 0x20, 0x5C, 0xDE,
             0xFB, 0x2A, 0x24, 0xA3, 0x79, 0xB8, 0xA1, 0x16,
             0x17, 0x50, 0x95, 0xFF, 0x57, 0xFF, 0x61, 0x55,
             0x12, 0x86, 0x86, 0xD9, 0x9B, 0x8E, 0x1F, 0x24,
             0x44, 0x63, 0x12, 0x71, 0xF0, 0x9C, 0x33, 0x4F,
             0x37, 0x22, 0x45, 0x2F, 0xE9, 0x26, 0x3F, 0xC3,
             0x34, 0x9E, 0x6F, 0x33, 0x07, 0xA6, 0x75, 0x4F,
             0xFD, 0x89, 0xD4, 0x43, 0x27, 0x38, 0x7D, 0xFD,
             0x40, 0x18, 0xA0, 0x2A, 0xEA, 0x6E, 0xF4, 0xC6,
             0x36, 0xA7, 0x69, 0xE7, 0xCE, 0xB7, 0x37, 0x19,
             0x19, 0x72, 0x49, 0xA8, 0x41, 0xA3, 0x0B, 0xE0,
             0xC4, 0xBE, 0x8E, 0xCB, 0x10, 0x7F, 0x38, 0x02,
             0xDC, 0x45, 0x83, 0xF8, 0xE0, 0x12, 0x94, 0xD5,
             0x2B, 0x62, 0x13, 0x67, 0xBD, 0x0C, 0x19, 0x53 },
           /* q */
           225,
           { 0x01, 0x95, 0x09, 0xB2, 0xED, 0xA8, 0x3B, 0x08,
             0x82, 0x73, 0x1B, 0x3F, 0xE8, 0x9C, 0x2E, 0xF6,
             0x9D, 0xB8, 0xD8, 0x36, 0x12, 0x34, 0x5D, 0x1A,
             0x66, 0xA5, 0x83, 0xB9, 0x11 },
           /* g */
           2040,
           { 0xAC, 0x5D, 0x12, 0x0E, 0x46, 0xD2, 0xBA, 0xD6,
             0x87, 0x88, 0x47, 0xCC, 0xE8, 0x70, 0xA6, 0x9E,
             0xDC, 0xAD, 0xC8, 0x6C, 0x85, 0x9C, 0x49, 0xBA,
             0xF7, 0xAD, 0xE4, 0x1E, 0xD9, 0x36, 0x8E, 0xC2,
             0x3B, 0x64, 0x54, 0xFB, 0x60, 0xEA, 0xDA, 0xAC,
             0xC6, 0x64, 0x2A, 0x6F, 0xDD, 0x32, 0x2B, 0x99,
             0xAB, 0x14, 0x75, 0x81, 0xB2, 0x1B, 0xEB, 0xE0,
             0x62, 0x94, 0xE3, 0x82, 0x0B, 0xC5, 0x56, 0xFA,
             0x54, 0x11, 0xB3, 0x1C, 0x37, 0x3B, 0x39, 0xA6,
             0x7D, 0x51, 0x8A, 0x54, 0x77, 0x13, 0x41, 0x5C,
             0x67, 0xAC, 0xEF, 0x18, 0xBC, 0x6B, 0xA9, 0x4C,
             0x95, 0x60, 0x0C, 0xB5, 0xBD, 0xA8, 0x3C, 0x84,
             0xAD, 0x58, 0xE5, 0x49, 0x1D, 0x26, 0x26, 0x1E,
             0xD4, 0xE5, 0x35, 0xAD, 0xB2, 0x2E, 0x35, 0xB0,
             0x6C, 0xC2, 0xB4, 0xC8, 0x9D, 0xA2, 0xDC, 0x63,
             0xE2, 0x9E, 0xDA, 0x06, 0xF0, 0x13, 0x80, 0x72,
             0x46, 0x55, 0x89, 0x32, 0xE9, 0xF2, 0xDC, 0x8B,
             0x93, 0x2E, 0x6B, 0x84, 0xB4, 0x07, 0xF5, 0x71,
             0x50, 0x9D, 0x06, 0xF7, 0x94, 0x30, 0xE9, 0x5D,
             0x46, 0xB2, 0xD0, 0x26, 0x14, 0x28, 0x84, 0x17,
             0x99, 0x98, 0x86, 0xA6, 0x71, 0x45, 0xED, 0x74,
             0x6A, 0x0C, 0xA8, 0xC0, 0x44, 0x41, 0x03, 0xF5,
             0x03, 0xE6, 0xBB, 0xE7, 0x45, 0x61, 0xC3, 0xAC,
             0xD1, 0x9A, 0xE5, 0x7A, 0x82, 0x67, 0xA1, 0xBC,
             0x3C, 0x49, 0x30, 0x83, 0xBB, 0x16, 0xC5, 0x97,
             0xA8, 0xAC, 0x99, 0x81, 0xFB, 0x70, 0x45, 0x87,
             0x17, 0xFB, 0x64, 0x9C, 0xA4, 0x61, 0xD4, 0x70,
             0xB4, 0xB3, 0x5E, 0x3E, 0x98, 0x64, 0xFA, 0x1A,
             0x59, 0x9B, 0xC0, 0x1E, 0x6F, 0xE9, 0x93, 0x0A,
             0x51, 0xF5, 0x79, 0xB0, 0x84, 0x01, 0x74, 0x25,
             0xB8, 0xD0, 0xA1, 0x02, 0x3F, 0xAE, 0xDD, 0xDC,
             0x57, 0xD1, 0xCE, 0x56, 0x25, 0x1C, 0xDA },
           /* x */
           223,
           { 0x64, 0x05, 0xBC, 0xDE, 0xB4, 0xF7, 0x68, 0x29,
             0x02, 0x23, 0xCE, 0x5D, 0xB5, 0x2A, 0x8A, 0x30,
             0xC2, 0x8A, 0xDC, 0x78, 0x02, 0xD9, 0x68, 0x1E,
             0xDC, 0xB4, 0x34, 0xE5 },
           /* y */
           2042,
           { 0x02, 0x30, 0x37, 0xB2, 0xD9, 0xC9, 0x9E, 0x75,
             0x3F, 0xD2, 0x79, 0xBF, 0xFC, 0xDE, 0xE9, 0x92,
             0x9C, 0x9B, 0xA1, 0xDE, 0xAA, 0x97, 0x0B, 0x03,
             0x72, 0xAF, 0x73, 0x35, 0xE5, 0x50, 0x21, 0x37,
             0x42, 0x99, 0xF3, 0x61, 0x02, 0x7C, 0x8D, 0x65,
             0xD5, 0x7A, 0xFB, 0x4D, 0x3C, 0xCD, 0x2B, 0x47,
             0x24, 0xB5, 0x3F, 0x09, 0xEB, 0xE2, 0x8C, 0xBF,
             0x49, 0x9F, 0x6B, 0x4F, 0x86, 0x33, 0x49, 0x19,
             0x8B, 0x24, 0xB2, 0xAB, 0x0D, 0x4C, 0xEC, 0xB6,
             0xC4, 0xFD, 0x7E, 0x67, 0x2D, 0x4B, 0x2A, 0xCA,
             0x9D, 0x39, 0xE3, 0xAE, 0x20, 0xF8, 0xEC, 0xD7,
             0xFD, 0x77, 0x10, 0x7C, 0xE5, 0x4A, 0x66, 0xDD,
             0xEE, 0x97, 0x44, 0xE4, 0x8C, 0xF8, 0xDD, 0x6B,
             0xA9, 0xA5, 0x28, 0xC7, 0x51, 0xF0, 0x08, 0xC6,
             0x6F, 0x19, 0x2A, 0x20, 0x4E, 0xC7, 0xF9, 0x38,
             0x76, 0x91, 0x01, 0x79, 0xB1, 0x31, 0x1D, 0x97,
             0x5B, 0x49, 0x25, 0xC5, 0x69, 0x90, 0x29, 0xFB,
             0xD1, 0x14, 0xA5, 0xE7, 0x90, 0x19, 0x0A, 0x4D,
             0x38, 0x9B, 0x94, 0x8F, 0x8F, 0x57, 0x6A, 0x8E,
             0x45, 0xA5, 0x6B, 0xE0, 0xD4, 0xFD, 0x6C, 0xEA,
             0x63, 0x1C, 0x5F, 0x53, 0x7E, 0xF9, 0x18, 0x59,
             0x8E, 0x30, 0x52, 0x2F, 0x93, 0x64, 0x50, 0x66,
             0x18, 0xC0, 0x45, 0x84, 0xCA, 0x6F, 0xD0, 0x75,
             0x12, 0x12, 0x21, 0xA4, 0x60, 0xF9, 0x80, 0xC5,
             0x4F, 0x80, 0x1D, 0x7D, 0x6D, 0x21, 0x9D, 0xF2,
             0xA1, 0xDB, 0xEA, 0x3C, 0x8A, 0x03, 0xA0, 0x9F,
             0x6B, 0xE9, 0x1B, 0xB6, 0x29, 0x6D, 0x79, 0x1A,
             0x2A, 0x83, 0x80, 0xE8, 0x9D, 0x0C, 0xDD, 0x26,
             0xF7, 0x66, 0x3E, 0x06, 0x9A, 0x83, 0x31, 0x49,
             0xAD, 0x44, 0x2B, 0x2C, 0x13, 0x98, 0x87, 0x71,
             0xF6, 0x54, 0xB8, 0x1F, 0x50, 0xE0, 0xD7, 0x26,
             0x42, 0x47, 0xD6, 0x78, 0xEA, 0xEB, 0xB0, 0xF9 }

Кодированная форма ключа DLP-2048.

   -----BEGIN DSA PRIVATE KEY-----
   MIIDTAIBAAKCAQADLdVTfTN6kTQ3016jQz2w57chKY+6hyfy+b6FbWoUa5KYjVCC
   8sVyt3A3Y+gkVKekoiWbKazpsLybS02YXWqcjLYw5OCfSAefG+gHaXHekmhWcLlM
   yWh93CM7MK8ilLAwprSX9kb5ThwX6DqQTCwbaEQQzgSP2c1kBaFKpowrj3+L0G6f
   ZMS7acy/vIBWrkFKiy411iBc3vsqJKN5uKEWF1CV/1f/YVUShobZm44fJERjEnHw
   nDNPNyJFL+kmP8M0nm8zB6Z1T/2J1EMnOH39QBigKupu9MY2p2nnzrc3GRlySahB
   owvgxL6OyxB/OALcRYP44BKU1StiE2e9DBlTAh0BlQmy7ag7CIJzGz/onC72nbjY
   NhI0XRpmpYO5EQKCAQAArF0SDkbSutaHiEfM6HCmntytyGyFnEm6963kHtk2jsI7
   ZFT7YOrarMZkKm/dMiuZqxR1gbIb6+BilOOCC8VW+lQRsxw3OzmmfVGKVHcTQVxn
   rO8YvGupTJVgDLW9qDyErVjlSR0mJh7U5TWtsi41sGzCtMidotxj4p7aBvATgHJG
   VYky6fLci5Mua4S0B/VxUJ0G95Qw6V1GstAmFCiEF5mYhqZxRe10agyowERBA/UD
   5rvnRWHDrNGa5XqCZ6G8PEkwg7sWxZeorJmB+3BFhxf7ZJykYdRwtLNePphk+hpZ
   m8Aeb+mTClH1ebCEAXQluNChAj+u3dxX0c5WJRzaAoIBAAIwN7LZyZ51P9J5v/ze
   6ZKcm6HeqpcLA3KvczXlUCE3QpnzYQJ8jWXVevtNPM0rRyS1Pwnr4oy/SZ9rT4Yz
   SRmLJLKrDUzstsT9fmctSyrKnTnjriD47Nf9dxB85Upm3e6XROSM+N1rqaUox1Hw
   CMZvGSogTsf5OHaRAXmxMR2XW0klxWmQKfvRFKXnkBkKTTiblI+PV2qORaVr4NT9
   bOpjHF9TfvkYWY4wUi+TZFBmGMBFhMpv0HUSEiGkYPmAxU+AHX1tIZ3yodvqPIoD
   oJ9r6Ru2KW15GiqDgOidDN0m92Y+BpqDMUmtRCssE5iHcfZUuB9Q4NcmQkfWeOrr
   sPkCHGQFvN6092gpAiPOXbUqijDCitx4AtloHty0NOU=
   -----END DSA PRIVATE KEY-----

Ключ DLP-4096 testDLP4096.

           /* p */
           4086,
           { 0x31, 0xD2, 0x55, 0x5F, 0xB2, 0xE8, 0x89, 0xF3,
             0x20, 0x83, 0x78, 0x79, 0x5A, 0xF4, 0x88, 0x5B,
             0x62, 0xD0, 0x13, 0x58, 0xBD, 0xF1, 0x17, 0xC0,
             0xB8, 0xAD, 0x4D, 0x22, 0xBE, 0x62, 0xCC, 0x93,
             0x34, 0x5B, 0x6E, 0xA8, 0xFC, 0x54, 0x0B, 0x56,
             0x8F, 0x50, 0x95, 0xBB, 0xA0, 0x90, 0x3E, 0xC5,
             0xEE, 0xD8, 0xC6, 0xAE, 0x52, 0x5D, 0x9A, 0xA7,
             0xE4, 0x99, 0x79, 0xF0, 0x8E, 0x6C, 0x4E, 0xDB,
             0xF5, 0x6A, 0x93, 0x29, 0x09, 0xA0, 0x6B, 0x6D,
             0x1E, 0x07, 0x57, 0x95, 0x3F, 0x90, 0x5B, 0x55,
             0x52, 0x99, 0x31, 0x5F, 0x42, 0x48, 0xF5, 0x4B,
             0x81, 0xEF, 0x5F, 0x05, 0x4D, 0x8D, 0x82, 0x4E,
             0x12, 0xAE, 0xAB, 0x82, 0x4B, 0x2C, 0x2F, 0x4C,
             0x5E, 0xDE, 0x04, 0x60, 0x30, 0xDC, 0x3B, 0x16,
             0xC2, 0x80, 0x59, 0x56, 0x85, 0xCA, 0x38, 0xC6,
             0xE7, 0x13, 0xD8, 0x2E, 0x4D, 0x1B, 0xFC, 0xD3,
             0x3D, 0x87, 0xDE, 0x26, 0x95, 0x4B, 0xA0, 0x05,
             0xBC, 0x42, 0x17, 0x77, 0x39, 0xB2, 0x0F, 0x1E,
             0x46, 0x13, 0x80, 0x79, 0xED, 0xE5, 0x91, 0x64,
             0xCE, 0x67, 0x23, 0xE3, 0x51, 0xE4, 0xB2, 0xFC,
             0xD5, 0x0D, 0x6E, 0xAB, 0xB4, 0x5D, 0xA8, 0x8F,
             0xA4, 0xCD, 0x56, 0x24, 0x8A, 0xEA, 0x44, 0xAA,
             0x2E, 0x41, 0xB8, 0xFF, 0x28, 0xBD, 0x37, 0x88,
             0x00, 0x8C, 0x2E, 0xEF, 0x4B, 0xE1, 0x90, 0xA0,
             0xAB, 0x5D, 0x7D, 0x80, 0x3C, 0x9A, 0xBE, 0xD7,
             0xC7, 0xB7, 0x74, 0xB5, 0x0F, 0xA8, 0x38, 0x0D,
             0xD7, 0xFE, 0x2B, 0x3D, 0x84, 0x85, 0xA3, 0xD8,
             0x80, 0xEF, 0x51, 0xD5, 0x6B, 0x41, 0x1F, 0x73,
             0xE6, 0x59, 0xE7, 0x9E, 0x0B, 0xFF, 0x32, 0x14,
             0x53, 0x57, 0x3E, 0xC5, 0x0D, 0x9D, 0xD4, 0xD0,
             0xAE, 0xCA, 0x30, 0x9D, 0x39, 0xE4, 0x38, 0x86,
             0x27, 0x95, 0x03, 0xEF, 0x94, 0x98, 0x51, 0xE3,
             0xD4, 0xDC, 0x71, 0xAB, 0xF3, 0xA7, 0x88, 0x63,
             0xB9, 0x75, 0xC1, 0x06, 0x24, 0xCB, 0x51, 0x73,
             0x4C, 0xDB, 0x58, 0x2A, 0x3A, 0x48, 0xC6, 0xD7,
             0x08, 0x47, 0x83, 0x6E, 0x80, 0x8B, 0x0E, 0x22,
             0x48, 0xB8, 0xFA, 0x8A, 0x8C, 0x55, 0xA3, 0x57,
             0xE8, 0x30, 0x54, 0xD6, 0x48, 0xB2, 0xCC, 0xA5,
             0xB8, 0xA3, 0xB1, 0x68, 0x91, 0xAD, 0x52, 0x35,
             0x6E, 0x92, 0x87, 0x1A, 0xF5, 0x99, 0xA5, 0x6E,
             0x90, 0xC9, 0x34, 0x33, 0xA5, 0x4A, 0x52, 0xFD,
             0x42, 0xE2, 0xBE, 0x65, 0x15, 0xC8, 0xCE, 0xC3,
             0x73, 0x94, 0x07, 0x0C, 0x26, 0xCA, 0xC5, 0xCA,
             0x8C, 0x26, 0x1D, 0x2D, 0x50, 0x21, 0x88, 0x6B,
             0xB9, 0x4C, 0x4E, 0x99, 0xFA, 0x78, 0xD2, 0x53,
             0x7C, 0xCA, 0xF5, 0xA1, 0x92, 0xC9, 0xC2, 0xAF,
             0x77, 0xA0, 0x78, 0x33, 0x45, 0x1F, 0x12, 0x2D,
             0xA9, 0xE6, 0xFD, 0x7B, 0x83, 0x92, 0x12, 0x9E,
             0xE4, 0x9A, 0x56, 0x07, 0x5F, 0x1A, 0x37, 0x05,
             0x00, 0x4C, 0x06, 0xBD, 0x36, 0x7F, 0xBF, 0xCB,
             0x9A, 0x07, 0x4A, 0x02, 0xE1, 0x65, 0x25, 0x27,
             0x2D, 0xF9, 0xD3, 0x33, 0xCB, 0x91, 0x9B, 0x5B,
             0x61, 0x14, 0x07, 0xF7, 0xF7, 0xA4, 0xD9, 0xE1,
             0x1E, 0xD2, 0x85, 0xA4, 0x75, 0x95, 0xEA, 0x74,
             0x0C, 0xBF, 0xA1, 0x6B, 0xD2, 0xFB, 0xB8, 0x0A,
             0xD2, 0xA5, 0xE6, 0x36, 0x04, 0x47, 0x80, 0x8B,
             0x1E, 0xC5, 0x07, 0x58, 0xB8, 0x56, 0xF6, 0xDC,
             0xA4, 0x25, 0xD9, 0x36, 0xB4, 0x9E, 0xEA, 0x5B,
             0x7E, 0xAA, 0x40, 0x79, 0xA3, 0x15, 0x3D, 0xED,
             0x32, 0x12, 0x76, 0x4D, 0x00, 0x06, 0xF0, 0x09,
             0x36, 0x28, 0x4B, 0x96, 0xD6, 0x8B, 0xC9, 0x74,
             0xFD, 0xAF, 0x77, 0xB6, 0x45, 0x78, 0x36, 0x38,
             0xC5, 0x1E, 0xB1, 0x18, 0x8A, 0x91, 0x72, 0xA0,
             0x37, 0xDE, 0x49, 0xDA, 0x48, 0x1A, 0x9B },
           /* q */
           305,
           { 0x01, 0xFF, 0x30, 0x36, 0x06, 0x89, 0x3F, 0x53,
             0xBE, 0x41, 0x12, 0xF9, 0x60, 0x18, 0xF9, 0x9C,
             0xCF, 0xB9, 0x67, 0x82, 0x7E, 0x49, 0x40, 0x36,
             0x98, 0x2F, 0xAF, 0x24, 0x06, 0xD2, 0x5D, 0x8B,
             0xCC, 0x52, 0x48, 0xDB, 0x2B, 0xCB, 0x13 },
           /* g */
           4085,
           { 0x19, 0x89, 0x03, 0x1B, 0x12, 0xB8, 0x83, 0x5D,
             0x66, 0x5C, 0x9F, 0x42, 0x31, 0x05, 0x24, 0xA0,
             0x64, 0x9E, 0xEC, 0x4C, 0x2C, 0x4A, 0xBA, 0xAC,
             0xAD, 0x5D, 0x54, 0x8C, 0xE0, 0xFA, 0xF5, 0x3E,
             0xCA, 0x38, 0x67, 0xAA, 0xE6, 0x18, 0x7D, 0x5F,
             0x63, 0xC0, 0xF6, 0x6B, 0x56, 0xE8, 0x00, 0xAD,
             0x5D, 0x09, 0x58, 0x8C, 0xA4, 0x25, 0xBC, 0xE6,
             0xBD, 0x33, 0x97, 0x6B, 0xBA, 0xC9, 0x68, 0x63,
             0xD1, 0xC2, 0x6E, 0x4F, 0x48, 0x27, 0x67, 0x05,
             0x63, 0xFB, 0x9C, 0xA5, 0x16, 0x5C, 0x3C, 0x9F,
             0x14, 0x1D, 0x2E, 0x7D, 0x77, 0xA6, 0x11, 0x95,
             0x55, 0x4D, 0x9C, 0xE6, 0xA3, 0x25, 0xB9, 0x34,
             0x2A, 0x5F, 0x0A, 0xDE, 0x00, 0x7E, 0xED, 0x69,
             0xF3, 0x2C, 0x78, 0x67, 0x8C, 0x5F, 0x30, 0x2C,
             0xAF, 0x97, 0x62, 0xFC, 0xC0, 0xD6, 0x22, 0xD2,
             0xBF, 0xA5, 0xFF, 0x72, 0x4B, 0x59, 0x49, 0x21,
             0x1C, 0x66, 0x2E, 0xD3, 0xD8, 0x14, 0x1E, 0xAF,
             0xAB, 0xB6, 0x28, 0x65, 0xC2, 0xF2, 0xA6, 0x44,
             0xA5, 0xDC, 0x34, 0x0F, 0x24, 0x0F, 0x73, 0x61,
             0x53, 0x3C, 0x65, 0x64, 0xCD, 0x9E, 0x33, 0xB6,
             0x58, 0xC1, 0x39, 0x71, 0xEC, 0xDA, 0x66, 0x2E,
             0x1C, 0x79, 0xB5, 0x88, 0x7E, 0xA2, 0x46, 0x1E,
             0x35, 0xA6, 0xBA, 0x2B, 0xD0, 0x20, 0x80, 0xF8,
             0xE5, 0xC6, 0xC8, 0xBE, 0x7B, 0xFB, 0xB9, 0x6C,
             0xF4, 0x1F, 0x07, 0xD5, 0xBD, 0xC9, 0x65, 0x00,
             0xB5, 0x6C, 0x53, 0x4B, 0x70, 0x36, 0x99, 0x56,
             0x8F, 0x70, 0x0B, 0x9A, 0xD5, 0xEF, 0xFC, 0x1E,
             0xE8, 0xBE, 0x2F, 0x70, 0x39, 0x50, 0xAC, 0xD3,
             0xB8, 0x8C, 0x24, 0x3F, 0x82, 0xA2, 0xE9, 0xF5,
             0x01, 0xE3, 0x87, 0x84, 0x4E, 0x77, 0xAA, 0x90,
             0x2D, 0xC0, 0xD7, 0xD9, 0x6E, 0xBE, 0x4E, 0x4B,
             0xC8, 0xB3, 0xAB, 0x09, 0x64, 0xAC, 0x28, 0xB1,
             0x54, 0xCD, 0x15, 0x35, 0xA4, 0x06, 0x55, 0x40,
             0x83, 0x39, 0x8E, 0x0B, 0xE6, 0xAC, 0x9B, 0x26,
             0xFF, 0x9A, 0xF4, 0xC2, 0xCD, 0xA9, 0x55, 0x17,
             0x51, 0x15, 0x2F, 0xBD, 0x4C, 0xC2, 0xD7, 0xF1,
             0x9A, 0x9E, 0x7F, 0x41, 0xA5, 0x6E, 0xBB, 0xEF,
             0x3C, 0xD5, 0x1D, 0xF6, 0xB1, 0x08, 0x48, 0x06,
             0x15, 0xA8, 0xF3, 0xED, 0x99, 0x9F, 0xEC, 0x7F,
             0x0F, 0x3C, 0x53, 0x87, 0x55, 0x27, 0x70, 0x74,
             0xB3, 0xA8, 0x0D, 0x4B, 0x6A, 0x84, 0x71, 0x26,
             0xE1, 0xB9, 0xDF, 0xE2, 0x38, 0x96, 0xF5, 0xB1,
             0x97, 0x53, 0x83, 0x9B, 0x18, 0xA7, 0xE6, 0x69,
             0x3E, 0x9F, 0xB1, 0x3D, 0x11, 0x58, 0xA3, 0xAB,
             0xAF, 0x4E, 0x04, 0x62, 0x7D, 0xEB, 0x96, 0x12,
             0xD9, 0x59, 0x4D, 0x33, 0x26, 0x1A, 0xE5, 0x93,
             0x67, 0xFF, 0xCA, 0xDE, 0xC3, 0xB5, 0xAF, 0xFF,
             0xCB, 0xDF, 0xED, 0x45, 0x0B, 0x53, 0x8B, 0xC8,
             0xD8, 0x8D, 0x29, 0x8E, 0xDD, 0x27, 0xB3, 0x36,
             0xE8, 0xF5, 0xEE, 0x6D, 0x46, 0x1F, 0x57, 0x40,
             0x3B, 0xB4, 0x6D, 0xBC, 0x04, 0xB6, 0xD9, 0x00,
             0xC7, 0x48, 0x72, 0x8D, 0xE7, 0x8F, 0x68, 0x8F,
             0xCD, 0x9A, 0x90, 0x29, 0x4E, 0xEA, 0x95, 0xE7,
             0xCE, 0x48, 0x2A, 0x39, 0xB0, 0x62, 0xE8, 0x04,
             0xFC, 0xCB, 0x6E, 0xF7, 0xD1, 0x35, 0x94, 0xB9,
             0x35, 0x0E, 0xC2, 0x0F, 0xB5, 0x02, 0xA8, 0x4C,
             0x4E, 0x30, 0x96, 0xC5, 0x90, 0xAA, 0x29, 0x63,
             0x78, 0x79, 0x0D, 0x81, 0x9E, 0xC2, 0xC5, 0x0D,
             0xD5, 0xF5, 0x46, 0xF5, 0xE3, 0xE4, 0xD9, 0x69,
             0xEC, 0x33, 0xDA, 0x45, 0x52, 0x14, 0xD7, 0xA0,
             0x5C, 0xAA, 0xF8, 0x87, 0xB5, 0xE8, 0x9B, 0x09,
             0xE6, 0xB2, 0xCF, 0x0D, 0x56, 0x43, 0xC3, 0x85,
             0x48, 0x01, 0x8A, 0x87, 0x7B, 0x5A, 0x17, 0x72,
             0x40, 0x2B, 0x4B, 0x29, 0xF3, 0x5C, 0x8B },
           /* x */
           305,
           { 0x01, 0xA7, 0x77, 0x11, 0xB8, 0x9D, 0x45, 0x53,
             0x27, 0x29, 0x01, 0xBA, 0x09, 0x5A, 0x7F, 0xFC,
             0x14, 0x9C, 0x8C, 0x05, 0xB0, 0x2F, 0xDD, 0x04,
             0x0D, 0xC9, 0x98, 0x97, 0x11, 0x5B, 0xCE, 0xC3,
             0xE6, 0x14, 0xF2, 0x55, 0x7F, 0x9C, 0x0C },
           /* y */
           4086,
           { 0x2A, 0x49, 0x11, 0x73, 0x18, 0x65, 0x11, 0x4B,
             0x8A, 0x6C, 0x6F, 0x8E, 0x40, 0x7D, 0x55, 0xC3,
             0x9A, 0xB7, 0x10, 0xBB, 0x45, 0xCA, 0xBA, 0x94,
             0xE6, 0xB1, 0x85, 0x87, 0xD2, 0x8F, 0x9C, 0x6C,
             0x69, 0x4C, 0x01, 0x9A, 0x09, 0xB2, 0x6F, 0x44,
             0x8C, 0x2A, 0x33, 0x55, 0xA5, 0x67, 0xB1, 0xA0,
             0xC8, 0x61, 0x82, 0x2E, 0x19, 0xC6, 0xFA, 0xDE,
             0x8C, 0x43, 0xAA, 0x61, 0xC3, 0xBF, 0x39, 0xB6,
             0x95, 0xE2, 0xA2, 0x74, 0x55, 0x2F, 0xE8, 0x5C,
             0x76, 0x5B, 0x8A, 0x1E, 0xF7, 0x8D, 0x1B, 0x42,
             0x97, 0xEF, 0x4C, 0x31, 0x3F, 0xE8, 0xDB, 0xF2,
             0x22, 0x11, 0x30, 0xC5, 0xEE, 0x91, 0xF9, 0xE3,
             0xD3, 0xBB, 0xF2, 0x9C, 0xC4, 0x7B, 0x1B, 0xAB,
             0xAF, 0x17, 0x9C, 0xBA, 0x8B, 0xD4, 0x5B, 0xA9,
             0x61, 0xD7, 0x0A, 0xB6, 0xBD, 0x7A, 0xA0, 0x75,
             0xFB, 0x2A, 0x15, 0x33, 0x14, 0xFC, 0x3B, 0x2C,
             0x3B, 0x89, 0x86, 0x6E, 0x68, 0x2C, 0x7A, 0x95,
             0x8D, 0x3B, 0x78, 0x87, 0xF0, 0xD7, 0xD8, 0xF4,
             0x0D, 0xF5, 0x5E, 0x6E, 0x51, 0x5D, 0x1F, 0xBB,
             0x88, 0x77, 0x8E, 0xAF, 0x8E, 0xF1, 0xE8, 0xF3,
             0x11, 0x9A, 0x74, 0x98, 0x80, 0x66, 0x7C, 0xA8,
             0xEC, 0xC4, 0x6B, 0xFA, 0x10, 0xBA, 0xC4, 0x67,
             0x4B, 0x77, 0xB9, 0x4E, 0xB0, 0xE9, 0x2A, 0x76,
             0xA6, 0xC0, 0x81, 0x59, 0xD1, 0xF4, 0x06, 0xB6,
             0x68, 0x5F, 0xE8, 0x5B, 0x41, 0xA8, 0xD8, 0x04,
             0x93, 0x91, 0x8A, 0xF5, 0x29, 0x9A, 0x1C, 0x6A,
             0x11, 0x3D, 0xE2, 0xF9, 0x74, 0x27, 0xCD, 0x87,
             0xC4, 0xBA, 0x28, 0x2A, 0x65, 0x5D, 0x6A, 0x4E,
             0xE7, 0x15, 0x01, 0x2E, 0x0C, 0x75, 0x0C, 0xC3,
             0xB1, 0xE5, 0xC0, 0xF2, 0x2B, 0xC8, 0x2A, 0xD2,
             0x3E, 0xB4, 0xC0, 0xEC, 0xF4, 0x80, 0xAC, 0xB7,
             0xD7, 0x31, 0x21, 0x57, 0xDB, 0xB7, 0xE0, 0xE5,
             0x23, 0x78, 0xE9, 0xFF, 0x46, 0xEE, 0xEF, 0x04,
             0xAF, 0x47, 0x4F, 0x2C, 0x4C, 0x55, 0xDF, 0xFF,
             0xCF, 0x79, 0x8B, 0x90, 0x3F, 0x49, 0xEA, 0x43,
             0xD0, 0x60, 0xEF, 0x23, 0xED, 0x7D, 0x63, 0x89,
             0x7B, 0xCB, 0x2F, 0xF1, 0x39, 0xAB, 0x0D, 0x80,
             0x5F, 0xF7, 0x85, 0x87, 0xCC, 0xE6, 0xF1, 0xF2,
             0xCE, 0x39, 0x07, 0xBB, 0xDA, 0x5A, 0x67, 0x39,
             0xCF, 0x62, 0x47, 0x2C, 0xA2, 0x11, 0x85, 0x18,
             0xDA, 0xFE, 0x90, 0x7C, 0x4B, 0xEA, 0x88, 0xDC,
             0xAE, 0x39, 0x01, 0x07, 0x3A, 0xB6, 0xCC, 0x60,
             0xA5, 0x60, 0xC9, 0xA4, 0xD6, 0x33, 0x1E, 0x29,
             0xF8, 0x8A, 0xFE, 0xB9, 0x99, 0xA6, 0x4A, 0xE4,
             0xDB, 0xC7, 0xBF, 0x02, 0x22, 0xA9, 0xD4, 0x19,
             0x3A, 0x20, 0xE8, 0x1B, 0x40, 0x30, 0xF3, 0x28,
             0xE3, 0xA9, 0xCB, 0x7C, 0x92, 0x62, 0x04, 0x98,
             0x47, 0x4F, 0xCB, 0x64, 0xDA, 0xE1, 0xBB, 0xD7,
             0x9E, 0x4A, 0x9C, 0x04, 0x76, 0x47, 0x5E, 0xF0,
             0xF9, 0xAB, 0x5E, 0x89, 0xAE, 0x4D, 0x5A, 0xAE,
             0x9F, 0x87, 0x60, 0x21, 0xFA, 0x0B, 0xB2, 0x82,
             0x17, 0xCF, 0x27, 0x8D, 0x3A, 0xE9, 0xED, 0xDC,
             0x1C, 0x57, 0xBE, 0x5E, 0x17, 0xDC, 0x0D, 0x94,
             0x8E, 0x02, 0xFC, 0x05, 0xFE, 0xDF, 0x74, 0x07,
             0x05, 0xD8, 0xDC, 0xDC, 0x9D, 0x4B, 0x9C, 0xE6,
             0x80, 0x93, 0x65, 0x74, 0x94, 0x01, 0x5E, 0x05,
             0x17, 0x78, 0x96, 0xF1, 0x29, 0xFD, 0xFF, 0xB5,
             0xFF, 0x4A, 0xF5, 0x7C, 0x64, 0xD1, 0x51, 0xEC,
             0xEC, 0x8E, 0x74, 0x7B, 0x72, 0x67, 0xFA, 0x2D,
             0x8C, 0xF5, 0x97, 0x5E, 0x84, 0xC2, 0xEF, 0xAC,
             0x18, 0xDF, 0x16, 0xF2, 0xD8, 0x98, 0x0C, 0xE4,
             0x09, 0xC0, 0x3A, 0x1B, 0xC2, 0xB9, 0x5B, 0x34,
             0x34, 0x18, 0x98, 0xC6, 0xA5, 0xC6, 0x28, 0x54,
             0xB8, 0x53, 0x33, 0xE1, 0x4A, 0xA8, 0xE9 }

Кодированная форма ключа DLP-4096.

   -----BEGIN DSA PRIVATE KEY-----
   MIIGXgIBAAKCAf8x0lVfsuiJ8yCDeHla9IhbYtATWL3xF8C4rU0ivmLMkzRbbqj8
   VAtWj1CVu6CQPsXu2MauUl2ap+SZefCObE7b9WqTKQmga20eB1eVP5BbVVKZMV9C
   SPVLge9fBU2Ngk4SrquCSywvTF7eBGAw3DsWwoBZVoXKOMbnE9guTRv80z2H3iaV
   S6AFvEIXdzmyDx5GE4B57eWRZM5nI+NR5LL81Q1uq7RdqI+kzVYkiupEqi5BuP8o
   vTeIAIwu70vhkKCrXX2APJq+18e3dLUPqDgN1/4rPYSFo9iA71HVa0Efc+ZZ554L
   /zIUU1c+xQ2d1NCuyjCdOeQ4hieVA++UmFHj1Nxxq/OniGO5dcEGJMtRc0zbWCo6
   SMbXCEeDboCLDiJIuPqKjFWjV+gwVNZIssyluKOxaJGtUjVukoca9ZmlbpDJNDOl
   SlL9QuK+ZRXIzsNzlAcMJsrFyowmHS1QIYhruUxOmfp40lN8yvWhksnCr3egeDNF
   HxItqeb9e4OSEp7kmlYHXxo3BQBMBr02f7/LmgdKAuFlJSct+dMzy5GbW2EUB/f3
   pNnhHtKFpHWV6nQMv6Fr0vu4CtKl5jYER4CLHsUHWLhW9tykJdk2tJ7qW36qQHmj
   FT3tMhJ2TQAG8Ak2KEuW1ovJdP2vd7ZFeDY4xR6xGIqRcqA33knaSBqbAicB/zA2
   Bok/U75BEvlgGPmcz7lngn5JQDaYL68kBtJdi8xSSNsryxMCggH/GYkDGxK4g11m
   XJ9CMQUkoGSe7EwsSrqsrV1UjOD69T7KOGeq5hh9X2PA9mtW6ACtXQlYjKQlvOa9
   M5drusloY9HCbk9IJ2cFY/ucpRZcPJ8UHS59d6YRlVVNnOajJbk0Kl8K3gB+7Wnz
   LHhnjF8wLK+XYvzA1iLSv6X/cktZSSEcZi7T2BQer6u2KGXC8qZEpdw0DyQPc2FT
   PGVkzZ4ztljBOXHs2mYuHHm1iH6iRh41pror0CCA+OXGyL57+7ls9B8H1b3JZQC1
   bFNLcDaZVo9wC5rV7/we6L4vcDlQrNO4jCQ/gqLp9QHjh4ROd6qQLcDX2W6+TkvI
   s6sJZKwosVTNFTWkBlVAgzmOC+asmyb/mvTCzalVF1EVL71Mwtfxmp5/QaVuu+88
   1R32sQhIBhWo8+2Zn+x/DzxTh1UncHSzqA1LaoRxJuG53+I4lvWxl1ODmxin5mk+
   n7E9EVijq69OBGJ965YS2VlNMyYa5ZNn/8rew7Wv/8vf7UULU4vI2I0pjt0nszbo
   9e5tRh9XQDu0bbwEttkAx0hyjeePaI/NmpApTuqV585IKjmwYugE/Mtu99E1lLk1
   DsIPtQKoTE4wlsWQqiljeHkNgZ7CxQ3V9Ub14+TZaewz2kVSFNegXKr4h7Xomwnm
   ss8NVkPDhUgBiod7WhdyQCtLKfNciwKCAf8qSRFzGGURS4psb45AfVXDmrcQu0XK
   upTmsYWH0o+cbGlMAZoJsm9EjCozVaVnsaDIYYIuGcb63oxDqmHDvzm2leKidFUv
   6Fx2W4oe940bQpfvTDE/6NvyIhEwxe6R+ePTu/KcxHsbq68XnLqL1FupYdcKtr16
   oHX7KhUzFPw7LDuJhm5oLHqVjTt4h/DX2PQN9V5uUV0fu4h3jq+O8ejzEZp0mIBm
   fKjsxGv6ELrEZ0t3uU6w6Sp2psCBWdH0BrZoX+hbQajYBJORivUpmhxqET3i+XQn
   zYfEuigqZV1qTucVAS4MdQzDseXA8ivIKtI+tMDs9ICst9cxIVfbt+DlI3jp/0bu
   7wSvR08sTFXf/895i5A/SepD0GDvI+19Y4l7yy/xOasNgF/3hYfM5vHyzjkHu9pa
   ZznPYkcsohGFGNr+kHxL6ojcrjkBBzq2zGClYMmk1jMeKfiK/rmZpkrk28e/AiKp
   1Bk6IOgbQDDzKOOpy3ySYgSYR0/LZNrhu9eeSpwEdkde8PmrXomuTVqun4dgIfoL
   soIXzyeNOunt3BxXvl4X3A2UjgL8Bf7fdAcF2NzcnUuc5oCTZXSUAV4FF3iW8Sn9
   /7X/SvV8ZNFR7OyOdHtyZ/otjPWXXoTC76wY3xby2JgM5AnAOhvCuVs0NBiYxqXG
   KFS4UzPhSqjpAicBp3cRuJ1FUycpAboJWn/8FJyMBbAv3QQNyZiXEVvOw+YU8lV/
   nAw=
   -----END DSA PRIVATE KEY-----

2.3. Ключи ECDLP

Ниже представлены общеизвестные тестовые ключи для алгоритмов на основе ECDLP, таких как ECDSA и ECDH.

Ключ P256 testECCP256.

           /* qx */
           256,
           { 0x42, 0x25, 0x48, 0xF8, 0x8F, 0xB7, 0x82, 0xFF,
             0xB5, 0xEC, 0xA3, 0x74, 0x44, 0x52, 0xC7, 0x2A,
             0x1E, 0x55, 0x8F, 0xBD, 0x6F, 0x73, 0xBE, 0x5E,
             0x48, 0xE9, 0x32, 0x32, 0xCC, 0x45, 0xC5, 0xB1 },
           /* qy */
           256,
           { 0x6C, 0x4C, 0xD1, 0x0C, 0x4C, 0xB8, 0xD5, 0xB8,
             0xA1, 0x71, 0x39, 0xE9, 0x48, 0x82, 0xC8, 0x99,
             0x25, 0x72, 0x99, 0x34, 0x25, 0xF4, 0x14, 0x19,
             0xAB, 0x7E, 0x90, 0xA4, 0x2A, 0x49, 0x42, 0x72 },
           /* d */
           256,
           { 0xE6, 0xCB, 0x5B, 0xDD, 0x80, 0xAA, 0x45, 0xAE,
             0x9C, 0x95, 0xE8, 0xC1, 0x54, 0x76, 0x67, 0x9F,
             0xFE, 0xC9, 0x53, 0xC1, 0x68, 0x51, 0xE7, 0x11,
             0xE7, 0x43, 0x93, 0x95, 0x89, 0xC6, 0x4F, 0xC1 }

Кодированная форма ключа P256.

   -----BEGIN EC PRIVATE KEY-----
   MHcCAQEEIObLW92AqkWunJXowVR2Z5/+yVPBaFHnEedDk5WJxk/BoAoGCCqGSM49
   AwEHoUQDQgAEQiVI+I+3gv+17KN0RFLHKh5Vj71vc75eSOkyMsxFxbFsTNEMTLjV
   uKFxOelIgsiZJXKZNCX0FBmrfpCkKklCcg==
   -----END EC PRIVATE KEY-----

Ключ P384 testECCP384.

           /* qx */
           384,
           { 0x5B, 0x09, 0x01, 0xB8, 0x85, 0x23, 0x29, 0x6E,
             0xB9, 0x19, 0xD5, 0x0F, 0xFA, 0x1A, 0x9C, 0xB3,
             0x74, 0xBC, 0x4D, 0x40, 0x95, 0x86, 0x28, 0x2B,
             0xFE, 0xCA, 0x11, 0xB1, 0xD9, 0x5A, 0xDB, 0xB5,
             0x47, 0x34, 0xAF, 0x57, 0x0B, 0xF8, 0x2B, 0x72,
             0x28, 0xCF, 0x22, 0x6B, 0xCF, 0x4C, 0x25, 0xDD },
           /* qy */
           384,
           { 0xBC, 0xFE, 0x3B, 0x1A, 0x3A, 0xD3, 0x94, 0x30,
             0xEF, 0xF7, 0x63, 0xE1, 0xD6, 0x8D, 0x2E, 0x15,
             0x1D, 0x91, 0x72, 0x0B, 0x77, 0x95, 0xB5, 0x8D,
             0xA6, 0xB3, 0x46, 0x39, 0x61, 0x3A, 0x8F, 0xB9,
             0xB5, 0xA8, 0xDA, 0x48, 0xC6, 0x74, 0x71, 0x17,
             0xF9, 0x91, 0x9E, 0x84, 0x24, 0xF3, 0x7E, 0xC8 },
           /* d */
           384,
           { 0xE2, 0x56, 0x33, 0x28, 0xDF, 0xAB, 0xF6, 0x81,
             0x88, 0x60, 0x6B, 0x91, 0x32, 0x42, 0x81, 0xC1,
             0xD5, 0x8A, 0x44, 0x56, 0x43, 0x1B, 0x09, 0xD5,
             0x10, 0xB3, 0x5F, 0xEC, 0xC9, 0xF3, 0x07, 0xCA,
             0x18, 0x22, 0x84, 0x6F, 0xA2, 0x67, 0x13, 0x71,
             0xA9, 0xA8, 0x1B, 0xAC, 0x0E, 0x35, 0x74, 0x9D }

Кодированная форма ключа P384.

   -----BEGIN EC PRIVATE KEY-----
   MIGkAgEBBDDiVjMo36v2gYhga5EyQoHB1YpEVkMbCdUQs1/syfMHyhgihG+iZxNx
   qagbrA41dJ2gBwYFK4EEACKhZANiAARbCQG4hSMpbrkZ1Q/6GpyzdLxNQJWGKCv+
   yhGx2VrbtUc0r1cL+CtyKM8ia89MJd28/jsaOtOUMO/3Y+HWjS4VHZFyC3eVtY2m
   s0Y5YTqPubWo2kjGdHEX+ZGehCTzfsg=
   -----END EC PRIVATE KEY-----

Ключ P521 testECCP521.

           /* qx */
           521,
           { 0x01, 0xD0, 0xFD, 0x72, 0x57, 0xA8, 0x4C, 0x74,
             0x7F, 0x56, 0x25, 0x75, 0xC0, 0x73, 0x85, 0xDB,
             0xEB, 0xF2, 0xF5, 0x2B, 0xEA, 0x58, 0x08, 0x3D,
             0xB8, 0x2F, 0xDD, 0x15, 0x31, 0xD8, 0xAA, 0xE3,
             0xCC, 0x87, 0x5F, 0xF0, 0x2F, 0xF7, 0xFA, 0x2D,
             0xA2, 0x60, 0xD8, 0xEB, 0x62, 0xD6, 0xD2, 0xF5,
             0xD6, 0x49, 0x27, 0x8E, 0x32, 0x17, 0x36, 0xA0,
             0x62, 0x8C, 0xBB, 0xB3, 0x03, 0x08, 0xB6, 0xE6,
             0x18, 0xDB },
           /* qy */
           521,
           { 0xF6, 0x2A, 0xD2, 0x04, 0xC6, 0x46, 0x03, 0x59,
             0xBC, 0x81, 0x8A, 0xB8, 0x96, 0x1B, 0xF0, 0xF0,
             0xFC, 0x0E, 0xC5, 0xAA, 0xE8, 0xA4, 0x28, 0x17,
             0x3C, 0xE5, 0x6F, 0x00, 0xDE, 0x9B, 0x15, 0x7C,
             0x1E, 0x5C, 0x82, 0xC6, 0x4F, 0x56, 0x2F, 0xCA,
             0xDE, 0xFC, 0x4A, 0x4C, 0x28, 0xF6, 0xD3, 0x42,
             0xCF, 0x3E, 0xF6, 0x16, 0xFC, 0x82, 0xD3, 0x3B,
             0x72, 0x85, 0xC9, 0x21, 0xF2, 0xBF, 0x36, 0xFD,
             0xD8 },
           /* d */
           521,
           { 0x01, 0xD9, 0x24, 0xDC, 0xCA, 0x0A, 0x88, 0x7F,
             0x8D, 0x99, 0x76, 0x7A, 0x37, 0xD8, 0x74, 0xE6,
             0x37, 0xA1, 0x2C, 0xCB, 0x47, 0x7D, 0x6E, 0x08,
             0x66, 0x53, 0x56, 0x69, 0x4D, 0x68, 0xB7, 0x65,
             0x5E, 0x50, 0x69, 0x63, 0x8F, 0xDE, 0x7B, 0x45,
             0xC8, 0x54, 0x01, 0x3D, 0xC7, 0x7A, 0x35, 0xB1,
             0x86, 0x55, 0xB8, 0x4C, 0x96, 0x6A, 0x60, 0x22,
             0x0D, 0x40, 0xF9, 0x1E, 0xD9, 0xF5, 0x14, 0x58,
             0x02, 0xEA }

Кодированная форма ключа P521.

   -----BEGIN EC PRIVATE KEY-----
   MIHcAgEBBEIB2STcygqIf42Zdno32HTmN6Esy0d9bghmU1ZpTWi3ZV5QaWOP3ntF
   yFQBPcd6NbGGVbhMlmpgIg1A+R7Z9RRYAuqgBwYFK4EEACOhgYkDgYYABAHQ/XJX
   qEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3+i2iYNjrYtbS9dZJJ44y
   FzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7FquikKBc85W8A3psVfB5c
   gsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92A==
   -----END EC PRIVATE KEY-----

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

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

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

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

Авторы ожидают неизбежных CVE (Common Vulnerabilities and Exposures).

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

Peter Gutmann
University of Auckland
Department of Computer Science
Auckland
New Zealand
Email: pgut001@cs.auckland.ac.nz
 
Corey Bonnell
DigiCert
Email: corey.bonnell@digicert.com

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

nmalykh@protokols.ru


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

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

3В оригинале – IETF Contributions. Прим. перев.

4В оригинале – IETF Standards Process. Прим. перев.

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

RFC 9498 The GNU Name System

Independent Submission                                   M. Schanzenbach
Request for Comments: 9498                              Fraunhofer AISEC
Category: Informational                                      C. Grothoff
ISSN: 2070-1721                                    Berner Fachhochschule
                                                                  B. Fix
                                                             GNUnet e.V.
                                                           November 2023

The GNU Name System

Система имён GNU

PDF

Аннотация

Этот документ содержит техническую спецификацию системы имён GNU (GNU Name System или GNS). GNS является децентрализованным и устойчивым к цензуре протоколом распознавания доменных имён, являющийся альтернативой протоколам системы доменных имён (Domain Name System или DNS), повышающий степень приватности.

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

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

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

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

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

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

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

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

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

1. Введение

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

В терминологии системы доменных имён (Domain Name System или DNS) [RFC1035] GNS примерно соответствует идее развёртывания локальной корневой зоны (см. [RFC8806]), отличаясь тем, что разрешаются дополнительные (альтернативные) корни и не предполагается, что все внедрения будут использовать одну и ту же или какую-то конкретную корневую зону. В эталонной реализации GNS пользователи могут автономно и свободно передавать полномочия (делегировать) по управлению именами в зоны через локальную конфигурацию. В GNS предполагается, что каждый пользователь контролирует свою установку. В соответствии с рекомендациями параграфа 9.10 пользователям следует избегать путаницы в способах распознавания имён.

Распознавание имён и распространение зон основано на принципе именования домашних питомцев, где пользователи могут назначать зонам локальные имена. В основе GNS лежат идеи простой распределенной инфраструктуры защиты (Simple Distributed Security Infrastructure) [SDSI], позволяющей децентрализованно сопоставлять идентификаторы защиты с запоминаемыми именами. Одно из первых академических описаний криптографических идей, лежащих в основе GNS, приведено в [GNS].

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

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

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

2. Термины

Apex Label – метка вершины

Этот тип метки служит для публикации записей о ресурса в зона, которые можно распознать без предоставления конкретной метки. Это метод GNS для реализации того, что в DNS называется вершиной зоны (zone apex) [RFC4033]. Метка вершины представляется с использованием символа U+0040 (@).

Application – приложение

Компонент, применяющий реализацию GNS для преобразования имён в записи и обработки их содержимого.

Blinded Zone Key – слепой ключ зоны

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

Extension Label – метка расширения

Тип метки, служащий для указания полномочной зоны, в которой находится запись. Метки расширения применяются в основном при перенаправлениях, когда цель перенаправления указана относительно полномочной зоны из записи о перенаправлении (см. параграф 5.2). Метка расширения представляется символом U+002B (+).

Label Separator – разделитель меток

Для разделения меток в именах применяется символ точки U+002E (.). В GNS каждый разделитель в имени указывает передачу полномочий (делегирование) в другую зону, за исключением зоны доменов верхнего уровня (zone Top-Level Domain или zTLD, см. ниже) и коробочных (boxed) записей (см. параграф 5.3.3).

Label – метка

Метки GNS соответствуют определению из [RFC8499]. Метки являются строками UTF-8 в нормализованной форме C (Unicode Normalization Form C или NFC) [Unicode-UAX15]. Метки вершины и расширения имеют особое значение в протоколе распознавания, заданном далее в этом документе. Администраторы зон могут с помощью процедур регистрации запретить некоторые метки, которые легко спутать с другими (см. параграф 9.4).

Name – имя

Имя в GNS является доменным именем в соответствии с [RFC8499] – строка UTF-8 [RFC3629], представляющая собой упорядоченный набор меток через символ-разделитель. Имена распознаются, начиная с правой метки. GNS не вносит ограничений на размер имён и меток, однако приложения могут обеспечивать совместимость размеров имён и меток с DNS и, в частности, с именами на национальных языках (Internationalized Domain Names for Applications или IDNA) [RFC5890]. В духе [RFC5895] приложения могут предварительно обрабатывать имена и метки для обеспечения совместимости с DNS или поддержки определённых ожиданий пользователей, например, соответствия [Unicode-UTS46]. Имя GNS может быть неотличимо от имени DNS поэтому приложения и разработчики должны осторожно относиться к обработке имён GNS (см. параграф 9.10). Для предотвращения ложной интерпретации имён а примерах этого документа как (зарезервированных) имён DNS, здесь применяется суффикс .gns.alt в соответствии с [RFC9476], включенный также в реестр GANA .alt Subdomains [GANA].

Resolver – распознаватель

Компонент реализации GNS, обеспечивающий рекурсивное распознавание имён на основе логики из раздела 7.

Resource Record – запись о ресурсе

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

Start Zone – стартовая зона

Для распознавания любого конкретного имени GNS нужно определить для него исходную стартовую зону (Start Zone). Стартовую зону можно задать явно как часть имени с помощью zTLD или определить через локальной сопоставление суффиксов с зонами (см. параграф 7.1).

Top-Level Domain (TLD) – домен верхнего уровня

Самая правая часть в имени GNS называется GNS TLD и может состоять из одной или нескольких меток. В отличие от DNS TLD (см. [RFC8499]), в GNS не предполагается использование одной глобальной корневой зоны всеми пользователями. Вместо этого GNS TLD (за исключением zTLD, см. параграф 4.1) обычно являются частью конфигурации локального распознавателя (см. параграф 7.1) и может не быть глобально уникальным.

Zone – зона

Зона GNS содержит полномочные (authoritative) сведения (записи о ресурсах). Зона однозначно идентифицируется её ключом. В отличие от зон DNS зонам GNS не требуется иметь запись SOA под меткой вершины (apex).

Zone Key – ключ зоны

Ключ, однозначно указывающий зону. Обычно это открытый ключ из асимметричной пары. Однако устоявшийся технический термин «открытый ключ» (public key) вводит в заблуждение, поскольку в зоне GNS ключ может быть общим секретом, который не следует раскрывать неуполномоченным сторонам.

Zone Key Derivation Function – функция вывода ключа зоны

Функция вывода ключа зоны (zone key derivation function или ZKDF) скрывает ключ зоны при использовании метки.

Zone Publisher – издатель зоны

Компонент реализации GNS, обеспечивающие управление и публикацию локальной зоны, как указано в разделе 6.

Zone Owner – владелец зоны

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

Zone Top-Level Domain (zTLD)

GNS zTLD – это последовательность меток GNS в конце имени GNS. zTLD кодирует тип и ключ зоны (см. параграф 4.1). Благодаря статистической уникальности ключей зон, zTLD уникальны в глобальном масштабе. Последовательность меток zTLD можно отличить от обычной последовательности меток TLD лишь при попытке декодировать метки в тип и ключ зоны.

Zone Type – тип зоны

Тип зоны GNS определяет систему шифрования и формат двоичного кодирования ключа зоны, спрятанных ключей зоны и криптографических подписей.

3. Обзор

Система именования GNS имеет три базовых свойства, указанных ниже.

Глобальность на основе концепции zTLD

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

Запоминающиеся имена зон

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

Защищённое сопоставление имён с записями

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

Далее в документе применяется термин «исполнитель» (implementer) для обозначения разработчика реализации GNS, включающей распознаватель, издатель зоны и поддерживающие конфигурации, такие как Start Zone (параграф 7.1).

3.1. Имена и зоны

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

   example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884

Рассмотрим случай, где пользователь локально настроил имя pet.gns.alt для зоны с записью example, представленной выше. Имя example.pet.gns.alt будет указывать на ту же запись, что и глобально уникальное имя, приведённое выше, но распознавание имён будет работать лишь в локальной системе, где настроено имя pet.gns.alt.

Делегирование имён (petname) и последующее его распознавание основано на идеях из простой распределенной инфраструктуры защиты (Simple Distributed Security Infrastructure) [SDSI]. В GNS любой пользователь может создать и поддерживать любое число зон (см. раздел 4), если его система поддерживает реализацию издателя зон. Для каждой зоны её тип определяет соответствующий набор криптографических операций и формат передачи зашифрованных данных, открытых ключей и подписей. Зона может быть заполнена её владельцем отображениями меток на записи о ресурсах (см. раздел 5). Метка может отображаться на запись о делегировании, в результате чего соответствующий субдомен делегируется в другую зону. В явном виде разрешена циклическая передача полномочий, включая делегирование субдомена в его непосредственно родительскую зону. Для поддержки (унаследованных) приложений и облегчения использования имён (petname) GNS определяет вспомогательные типы записей с дополнение к поддержке имеющихся записей DNS.

3.2. Публикация сведений о привязке

Содержимое зоны шифруется и подписывается перед публикацией в удалённом хранилище ключей и значений (см. параграф 6), как показано на рисунке 1. В этом процессе уникальная идентификация зоны скрывается от сети за счёт применения привязки ключей. Привязка позволяет создавать подписи для содержимого зоны, используя «ослеплённую» пару открытого и секретного ключа. Эта привязка реализуется использованием детерминированного вывода ключа из исходного ключа зоны и соответствующего секретного ключа с использованием значений меток в качестве входных данных для вывода коэффициентов сокрытия. В частности, владелец зоны может вывести ослеплённые секретные ключи для каждого набора записей, опубликованного под меткой, а распознаватель может вывести соответствующие ослеплённые открытые ключи. Предполагается, что реализации GNS используют децентрализованные сущности удалённого хранения, такие как распределенные хэш-таблицы (distributed hash table или DHT) для обеспечения доступности внутри сети без необходимости в выделенной инфраструктуре. Спецификация такого распределенного или децентрализованного хранилища выходит за рамки этого документа. Возможные реализации включают варианты, основанные на [RFC7363], [Kademlia] или [R5N].

      Хост A           |    Удалённое    |      Хост B
                       |    хранилище    |
                       |                 |
                       |    +---------+  |
                       |   /         /|  |
             Публикация|  +---------+ |  |Публикация
+-----------+ записей  |  |         | |  | записей  +-----------+
| Издатель  |----------|->|Хранилище| |<-|----------| Издатель  |
| зоны      |          |  |записей  | |  |          | зоны      |
+-----------+          |  |         |/   |          +-----------+
     A                 |  +---------+    |               A
     |                 |                 |               |
  +---------+          |                 |           +---------+
 /   |     /|          |                 |          /    |    /|
+---------+ |          |                 |         +---------+ |
|         | |          |                 |         |         | |
|Локальные| |          |                 |         |Локальные| |
|  зоны   | |          |                 |         |  зоны   | |
|         |/           |                 |         |         |/
+---------+            |                 |         +---------+

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


Реализацию издателя зон следует предоставлять как часть реализации GNS, чтобы пользователи могли создавать и поддерживать зоны. Если такая функциональность не реализована, имена все равно могут быть распознаны при настройке ключей зоны для начальной установки распознавания имён (см. параграф 7) или имена имеют суффикс zTLD.

3.3. Распознавание имён

Для поиска по именам GNS приложения используют распознаватели. Начиная с настраиваемой стартовой зоны, имена распознаются путём рекурсивного следования передаче полномочий, как показано на рисунке 2. Для каждой метки в имени распознаватель GNS извлекает соответствующий набор записей с уровня хранения (см. раздел 7). Без знания значений меток и ключей зон разные выведенные ключи невозможно связать с исходным ключом зоны и друг с другом. Это препятствует перечислению зон (за исключением дорогостоящих атак с перебором через сеть) – для подтверждения привязки (affiliation) запроса или соответствующего набора шифрованных записей к конкретной зоне нужно знать ключ зоны и мету, которые не раскрываются протоколом удалённому хранилищу. В то же время, ослепленный ключ зоны и цифровые подписи, связанные с каждым набором шифрованных записей, позволяют распознавателям и «забывчивому» (oblivious) удалённому хранилищу проверять целостность опубликованных сведений без раскрытия данных об исходной зоне и наборах записей.

                              Локальный хост        |   Удалённое 
                                                    |   хранилище
                                                    |
                                                    |    +---------+
                                                    |   /         /|
                                                    |  +---------+ |
+-----------+ Поиск    +--------------+ Рекурсивное |  |         | |
|           | имени    |              |распознавание|  |Хранилище| |
|Приложение |--------->|Распознаватель|-------------|->|записей  | |
|           |<---------|              |<------------|--|         |/
+-----------+Результаты+--------------+Промежуточные|  +---------+
                              A        результаты   |
                              |                     |
                           +---------+              |
                          /   |     /|              |
                         +---------+ |              |
                         |         | |              |
                         |Стартовые| |              |
                         |  зоны   | |              |
                         |         |/               |
                         +---------+                |

Рисунок . Высокоуровневое представление процесса распознавания GNS.


4. Зоны

Зона GNS однозначно указывается её типом (ztype) и ключом. Каждую зону можно указывать её zTLD (параграф 4.1) – строки, представляющей тип и ключ зоны. Тип ztype является уникальным 32-битовым числом – номером типа записи о ресурсе, указывающим запись о делегировании в реестре GANA GNS Record Types [GANA]. Значение ztype является уникальным идентификатором для набора криптографических функций зоны и формат типа записи о делегировании. В каждой регистрации ztype должны указываться перечисленные ниже наборы криптографических функций.

   KeyGen() -> d, zkey
Создает новый секретный ключ d и соответствующий открытый ключ зоны (zkey).
   ZKDF(zkey, label) -> zkey'
ZKDF скрывает ключ зоны zkey, используя метку. Значения zkey и zkey’ должны быть не связываемыми. Кроме того, сокрытие zkey с разными значениями метки должно давать разные, не связываемые значения zkey’.
   S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext
Функция симметричного шифрования, шифрующая открытый текст на основе ключевого материала, выведенного из zkey, метки и времени завершения срока действия. Для использования возможностей кэширования, повышающих производительность некоторых базовых систем хранения данных, в частности, DHT, рекомендуется применять детерминированную схему шифрования.
   S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext
Симметричная функция дешифрования, расшифровывающая шифротекст на основе ключевого материала, выведенного из ключа зоны, метки и времени завершения срока действия.
   Sign(d, message) -> signature
Функция для подписания сообщения с использованием секретного ключа d, дающая невоспроизводимую цифровую подпись. Для использования возможностей кэширования, повышающих производительность некоторых базовых систем хранения данных, в частности, DHT, рекомендуется применять детерминированную схему шифрования.
   Verify(zkey, message, signature) -> boolean
Функция, проверяющая создание подписи с использованием секретного ключа d, соответствующего ключу зоны zkey, где d,zkey := KeyGen(). Функция возвращает значение TRUE, если подпись действительна, и FALSE в противном случае.
   SignDerived(d, label, message) -> signature
Функция для подписания сообщения (обычно зашифрованных данных записи), которое можно проверить с помощью производного ключа зоны zkey’ := ZKDF(zkey, label). Для использования возможностей кэширования, повышающих производительность некоторых базовых систем хранения данных, в частности, DHT, рекомендуется применять детерминированную схему шифрования.
   VerifyDerived(zkey', message, signature) -> boolean
Функция, проверяющая создание подписи с использованием производного ключа зоны zkey’ := ZKDF(zkey, label). Функция возвращает значение TRUE, если подпись действительна, и FALSE в противном случае. В зависимости от применяемой схемы подписания эта функция может быть идентична функции Verify().

Криптографические функции стандартных ztype задаются соответствующими записями делегирования, как описано в параграфе 5.1. Для поддержки криптографической гибкости в будущем могут определяться дополнительные типы ztype или обновляться ztype, заданные в этом документе. Все ztype должны регистрироваться как выделенные типы записей делегирования в реестре GANA GNS Record Types [GANA]. При определении новых типов записей применяются соображения безопасности, представленные в этом документе, в частности, из параграфа 9.3.

4.1. Домен верхнего уровня для зоны (zTLD)

Строка zTLD кодирует тип и ключ зоны в суффиксе доменного имени и служит уникальной в глобальном масштабе ссылкой на зону в процессе распознавания имён. zTLD создаётся путём кодирования двоичной конкатенации типа и ключа зоны (см. рисунок 3). Для кодирования служит вариант Crockford Base32 [CrockfordB32], называемый Base32GNS. Символы кодирования и декодирования для Base32GNS (включая этот вариант) даны в таблице 4 (Приложение C). Функции кодирования и декодирования на основе таблицы 4 называются Base32GNS-Encode и Base32GNS-Decode, соответственно.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |      ZONE KEY         /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Двоичное представление zTLD.


Поле ZONE TYPE должно кодироваться с сетевым порядком байтов. Формат ZONE KEY целиком зависит от ZONE TYPE. Таким образом zTLD кодируется и декодируется, как показано ниже.

   zTLD := Base32GNS-Encode(ztype||zkey)
   ztype||zkey := Base32GNS-Decode(zTLD)

Здесь || указывает конкатенацию.

zTLD можно использовать «как есть» в качестве крайней справа метки в имени GNS. Если приложение хочет обеспечить совместимость имён с DNS, оно может представлять zTLD размером не более 63 символов без изменения, а более длинные zTLD разбиваются символом-разделителем на более короткие метки (старшие байты конкатенации ztype||zkey должны включаться в правую метку полученной в результате строки, а младшие – в левую). Это позволяет распознавателю определить ztype и размер zTLD по правой метке, а затем определить число меток в zTLD. Реализации GNS должны поддерживать деление zTLD на метки, размер которых совместим с DNS. Например, zTLD из 130 символов можно представить как zTLD[126..129].zTLD[63..125].zTLD[0..62]

4.2. Отзыв зоны

Для отзыва ключа зоны должно быть опубликовано отзывающее сообщение, которое должно подписываться с применением секретного ключа зоны. Отзывающее сообщение широковещательно передаётся в сеть. Спецификация механизма широковещательной отправки выходит за рамки этого документа. Один из возможных механизмов широковещательной передачи в распределенную сеть реализован в [GNUnet]. Как вариант, отзывающие сообщения могут распространяться через распределенный реестр (ledger) или доверенный центральный сервер. Для предотвращения лавинных атак сообщение об отзыве должно включать доказательство работы (proof of work или PoW). Сообщение об отзыве, включая PoW, может создаваться заранее для поддержки своевременного отзыва.

Во всех приведённых ниже случаях Argon2id указывает функцию вывода ключа по паролю, заданную в [RFC9106]. Для расчёта PoW алгоритм применяется с указанными ниже параметрами.

S

Затравка (salt) в форме неизменной 16-байтовой строки GnsRevocationPow.

t

Число итераций (3).

m

Размер памяти в KiB (1024).

T

Размер выходного хэша в байтах (64)

p

Параметр распараллеливания (1)

v

Версия алгоритма (0x13)

y

Тип алгоритма (Argon2id) (2)

X

Не используется.

K

Не используется.
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      POW                      |
+-----------------------------------------------+
|                   TIMESTAMP                   |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат данных PoW.


На рисунке 4 показан формат данных P, по которым рассчитывается PoW.

POW

64-битовое значение, которое является решением для PoW (сетевой порядок байтов).

TIMESTAMP

64-битовое значение абсолютной даты расчёта отзывающего сообщения (время с полуночи 1 января 1970 г. UTC в микросекндах) с сетевым порядком байтов.

ZONE TYPE

32-битовый идентификатор типа зоны (сетевой порядок байтов).

ZONE KEY

256-битовый открытый ключ zkey отзываемой зоны. Формат передачи значения определяется ZONE TYPE.

Обычно схемы PoW требуют найти одно значение POW, для которого результат хэширования даёт в начале определённое число нулей, далее называемое сложностью PoW. Чтобы сократить разброс по времени, требуемому для расчёта PoW, при корректном отзыве GNS требуется найти некоторое число разных PoW (Z, как указано ниже), в среднем имеющих не менее D нулей в начале.

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

Z

Требуемое число PoW (неизменное значение 32).

D

Нижний предел средней сложности (неизменное значение 22).

EPOCH

Одна эпоха (неизменное значение, указывающее 365 дней в микросекундах).

Формат передачи сообщения об отзыве показан на рисунке 5.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      TTL                      |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_0                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      ...                      |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    POW_(Z-1)                  |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
/                   SIGNATURE                   /
/                                               /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи сообщения с отзывом.


TIMESTAMP

64-битовое значение абсолютной даты расчёта отзывающего сообщения (время с полуночи 1 января 1970 г. UTC в микросекндах) с сетевым порядком байтов. Это же значение применяется при индивидуальном расчёте PoW.

TTL

64-битовое значение срока действия записи в микросекундах с сетевым порядком байтов. Для этого поля следует устанавливать значение EPOCH * 1,1. При среднем числе нулей в начале D’ значение поля можно увеличить до (D’-D+1)*EPOCH*1,1. Валидаторы могут отклонять при получении сообщения с большим или меньшим значением.

POW_i

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

ZONE TYPE

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

ZONE KEY

Открытый ключ (zkey ) отзываемой зоны, применяемый также для проверки SIGNATURE.

SIGNATURE

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

Подпись сообщения об отзыве охватывает 32-битовый заголовок, предшествующий полям TIMESTAMP, ZONE TYPE и ZONE KEY и включающий размер ключа и назначение подписи. Формат передачи показан на рисунке 6.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE (0x03)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |     ZONE KEY          /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи данных отзыва для подписи.


SIZE

32-битовое значение (с сетевым порядком байтов) размера подписанных данных в байтах.

PURPOSE

32-битовый флаг назначения подписи. Это поле должно имет значение 3 и указывается в сетевом порядке байтов. Значение указывает контекст, в котором создаётся подпись, чтобы предотвратить повторное использование в других частях протокола, которые могут включать будущие расширения. Значение поля соответствует записи в реестре GANA GNUnet Signature Purposes [GANA].

TIMESTAMP

См. описание поля в определении сообщения об отзыве.

ZONE TYPE

См. описание поля в определении сообщения об отзыве.

ZONE KEY

См. описание поля в определении сообщения об отзыве.

Для проверки отзыва должны выполняться указанные ниже действия.

  1. Подпись должна проверяться с ключом зоны.

  2. Набору значение POW недопустимо иметь дубликаты (подтверждается строго монотонным ростом значений).

  3. Среднее число нулей в начале D’ для предоставленных значений POW должно быть не меньше D. Разработчикам недопустимо использовать целочисленный тип данных для расчёта и представления D’.

Поле TTL в сообщении об отзыве является информационным. Отзыв может быть отброшен без проверки значений POW или подписи, если TTL (в сочетании с TIMESTAMP) указывает, что срок действия отзыва уже истёк. Фактический срок действия отзыва должен определяться проверкой числа нулей в начале значений POW. Срок действия рассчитывается как (D’-D+1)*EPOCH*1,1. Значение EPOCH расширено на 10% чтобы преодолеть неточность синхронизации часов. Срок действия, добавленный к значению метки времени создания TIMESTAMP, указывает дату и время, когда отзыв становится устаревшим.

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

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

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

5. Записи о ресурсах

Реализации GNS следует предоставлять механизм для создания и поддержки локальных зон, а также механизм сохранения записей о ресурсах (например, локальную базу данных). Новая локальная зоня создаётся путём выбора типа и создания ключевой пары зоны. Если такой механизм не реализован, записи не могут публиковаться в хранилище (см. раздел 6), а распознавание имён будет возможно лишь для нелокальных Start Zone (параграф 7.1).

Запись GNS о ресурсе содержит данные конкретной записи в зона. Формат записи приведён на рисунке 7.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|    SIZE   |   FLAGS   |          TYPE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      DATA                     /
/                                               /
/                                               /

Рисунок . Формат передачи записи о ресурсе.


EXPIRATION

64-битовое значение абсолютной даты завершения срока действия записи (время с полуночи 1 января 1970 г. UTC в микросекндах) с сетевым порядком байтов.

SIZE

16-битовое значение размера поля DATA в байтах (сетевой порядок байтов).

FLAGS

16-битовое поле, указывающее особые свойства записи. Семантика отдельных битов описана ниже.

TYPE

32-битовое значение типа записи о ресурсе с сетевым порядком байтов. Это может быть один из типов записей GNS о ресурсах, определённых в разделе 5, тип записи DNS в соответствии с [RFC1035] или иной дополнительно стандартизованный тип записи DNS о ресурсе. Отметим, что значения меньше 216 зарезервированы для 16-битовых типов записей о ресурсах DNS, выделенных IANA [RFC6895]. Значения больше 216 выделяются через реестр GANA GNS Record Types [GANA].

DATA

Данные записи о ресурсе (переменный размер). Содержимое данных определяет тип записи о ресурсе.
0           13            14      15
+--------...+-------------+-------+---------+
| Reserved  |SUPPLEMENTAL |SHADOW |CRITICAL |
+--------...+-------------+-------+---------+

Рисунок . Форма передачи флагов записи о ресурсе.


Поле FLAGS служит для указания особых свойств записи. Создающее запись о ресурсе приложение должно установить для всех битов FLAGS значение 0, если оно не понимает или не хочет установить соответствующий флаг. Поскольку в будущем могут быть заданы новые флаги, приложение или реализация, не понимающие флаг должны игнорировать его. Однако все реализации должны понимать флаги SHADOW и CRITICAL, заданные ниже. Действительно любое сочетание указанных ниже флагов. Структура 16-битового поля FLAGS показана на рисунке 8.

CRITICAL

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

SHADOW

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

SUPPLEMENTAL

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

5.1. Запись делегирования зоны

В этом параграфе задаётся исходный набор типов записей делегирования зон. Каждой реализации следует поддерживать все определённые здесь типы и можно поддерживать любое число записей делегирования из реестра GANA GNS Record Types [GANA]. Отсутствие поддержки какого-либо типа приведёт к отказам при распознавании, если в процессе встретится соответствующая зона. Это может быть оправданным выбором, если некоторые типы записей делегирования сочтены криптографически незащищёнными. Записи делегирования зон недопустимо сохранять или публиковать под меткой вершины (apex). Значение типа записи делегирования совпадает с соответствующим ztype. Значение ztype определяет криптографические примитивы для делегируемой зоны. Содержимое записи делегирования зоны включает открытый ключ делегируемой зоны. В записи делегирования зоны должен быть установлен флаг CRITICAL и она должна быть единственной не дополнительной (non-supplemental) записью под меткой. Могут быть другие неактивные записи того же типа с установленным флагом SHADOW для упрощения плавной смены ключей.

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

5.1.1. PKEY

В GNS делегирование метки в зону типа PKEY представляется записью PKEY. Формат передачи PKEY DATA показан на рисунке 9.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи PKEY.


PUBLIC KEY

256-битовый открытый ключ Ed25519.

Для зон PKEY ключевой материал выводится с использованием параметров кривой «скрученного» (twisted) представления Edwards для Curve25519 [RFC7748] (причина выбора этой кривой описана в параграфе 9.3) со схемой ECDSA [RFC6979]. Для криптографических примитивов зон PKEY используются приведённые ниже обозначения.

d

256-битовый секретный ключ Ed25519 (секретный зажатый скаляр).

zkey

Открытый ключ зоны Ed25519, соответствующий d.

p

Простое число (prime) edwards25519, как задано в [RFC7748], т. е. 2255 – 19.

G

Генератор группы (X(P),Y(P)) с X(P),Y(P) edwards25519 в соответствии с [RFC7748].

L

Порядок подгруппы prime-order edwards25519 в соответствии с [RFC7748].

KeyGen()

Генерация секретного скаляра d и точки кривой zkey := d*G (G – генератор группы эллиптической кривой), как задано в параграфе 2.2 [RFC6979], представляет функцию KeyGen().

Тип и ключ зоны PKEY имеют размер 4 + 32 байтов. Это означает, что zTLD всегда будет помещаться в одну метку и дополнительного преобразования не требуется. С учётом метки вывод zkey’ функции ZKDF(zkey, label) рассчитывается для зон PKEY, как показано ниже.

   ZKDF(zkey, label):
     PRK_h := HKDF-Extract("key-derivation", zkey)
     h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
     zkey' := (h mod L) * zkey
     return zkey'

Криптосистема PKEY использует основанную на HMAC функцию вывода ключа (HKDF) в соответствии с [RFC5869], применяя SHA-512 [RFC6234] в фазе извлечения и SHA-256 [RFC6234] в фазе преобразования (expansion). PRK_h – это ключевой материал, полученный с помощью HKDF, где применяется строка key-derivation в качестве затравки (salt) и ключ зоны в качестве исходного ключевого материала. 512-битовый результат преобразования HKDF (h) должен интерпретироваться с сетевым порядком байтов. Входные данные преобразования – это конкатенация метки и строки gns. Умножение zkey на h в функции ZKDF() является точечным умножением, а умножение d на h в SignDerived() – скалярным.

Функции Sign() и Verify() для зон PKEY реализованы с использованием 512-битовых детерминированных подписей ECDSA, как указано в [RFC6979]. Те же функции могут применяться для производных ключей.

   SignDerived(d, label, message):
     zkey := d * G
     PRK_h := HKDF-Extract("key-derivation", zkey)
     h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
     d' := (h * d) mod L
     return Sign(d', message)

Подпись действительна для производного открытого ключа zkey’ := ZKDF(zkey, label), если выполняется

   VerifyDerived(zkey', message, signature):
     return Verify(zkey', message, signature)

Функции S-Encrypt() и S-Decrypt() используют AES в режиме счётчика, как задано в [MODES] (CTR-AES256)

   S-Encrypt(zkey, label, expiration, plaintext):
     PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
     PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
     K := HKDF-Expand(PRK_k, label, 256 / 8)
     NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
     BLOCK_COUNTER := 0x0000000000000001
     IV := NONCE || expiration || BLOCK_COUNTER
     return CTR-AES256(K, IV, plaintext)

   S-Decrypt(zkey, label, expiration, ciphertext):
     PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
     PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
     K := HKDF-Expand(PRK_k, label, 256 / 8)
     NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
     BLOCK_COUNTER := 0x0000000000000001
     IV := NONCE || expiration || BLOCK_COUNTER
     return CTR-AES256(K, IV, ciphertext)

Ключ K и вектор инициализации (Initialization Vector или IV) счётчика выводятся из метки записи и ключа зоны zkey с использованием HKDF, как задано в [RFC5869]. В фазе извлечения применяется SHA-512 [RFC6234], а в фазе преобразования (expansion) – SHA-256 [RFC6234]. Выходной ключевой материал – это 32 байта (256 битов) для симметричного ключа и 4 байта (32 бита) для NONCE. Симметричный ключ K – это 256-битовый ключ AES [RFC3826].

Значение nonce объединяется с 64-битовым IV и 32-битовым счётчиком блоков, как задано в [RFC3686]. Счет блоков начинаяется с 1 и значение инкрементируется при генерации каждой следующей части потока ключей. Счётчик блоков – это 32-битовое целое число с сетевым порядком байтов. Формат IV счётчика, применемого в функциях S-Encrypt() и S-Decrypt(), показан на рисунке 10.

0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+
|      BLOCK COUNTER    |
+-----+-----+-----+-----+

Рисунок . Структура Counter IV при использовании в S-Encrypt() и S-Decrypt().


5.1.2. EDKEY

В GNS делегирование метки в зону типа EDKEY представляется записью EDKEY (рисунок 11).

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи EDKEY DATA.


PUBLIC KEY

256-битовый ключ зоны EdDSA.

Для зон EDKEY ключевой материал выводится с использованием параметрой кривой «скрученного» представления Edwards для Curve25519 [RFC7748] (или Ed25519) со схемой Ed25519 [ed25519], как указано в [RFC8032]. Для криптографических примитивов зон EDKEY используются приведённые ниже обозначения.

d

256-битовый секретный ключ EdDSA.

a

Целое число, выведенное из d с использованием хэш-функции SHA-512 в соответствии с [RFC8032].

zkey

Открытый ключ EdDSA, соответствующий d. Ключ определяется как точка кривой a*G, где G – генератор группы эллиптической кривой, как задано в [RFC8032].

p

Простое число (prime) edwards25519, как задано в [RFC7748], т. е. 2255 – 19.

G

Генератор группы (X(P),Y(P)) с X(P),Y(P) edwards25519 в соответствии с [RFC7748].

L

Порядок подгруппы prime-order edwards25519 в соответствии с [RFC7748].

KeyGen()

Генерация секретного скаляра d и связанного открытого ключа zkey := a*G (G – генератор группы эллиптической кривой, а a – целое число, полученное из d с помощью хэш-функции SHA-512) в соответствии с параграфом 5.1.5 в [RFC8032] представляет функцию KeyGen().

Тип и ключ зоны EDKEY имеют размер 4 + 32 байтов. Это означает, что zTLD всегда будет помещаться в одну метку и дополнительного преобразования не требуется.

Создание EDKEY с ZKDF основано на [Tor224]. Как указано выше для KeyGen(), расчёт выполняется на основе d с использованием хэш-функции SHA-512, как задано в параграфе 5.1.5 [RFC8032]. С учётом метки вывод функции ZKDF рассчитывается, как показано ниже.

   ZKDF(zkey, label):
     /* Расчёт коэффициент ослепления */
     PRK_h := HKDF-Extract("key-derivation", zkey)
     h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
     /* Обеспечение h == h mod L */
     h := h mod L

     zkey' := h * zkey
     return zkey'

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

Криптосистема EDKEY использует HKDF в соответствии с [RFC5869], применяя SHA-512 [RFC6234] в фазе извлечения и HMAC-SHA-256 [RFC6234] в фазе преобразования. Ключевой материал PRK_h выводится с помощью HKDF, где строка key-derivation служит затравкой, а ключ зоны – исходным ключевым материалом. Фактором ослепления h является 512-битовый результат преобразования HKDF. Входом для преобразования служит конкатенация метки и строки gns. Результат HKDF должен «зажиматься» и интерпретироваться в сетевом порядке байтов. 256-битовое целое число a соответствет 256-битовому секретному ключу d. Умножение zkey на h является точечным.

Процедуры Sign(d, message) и Verify(zkey, message, signature) должны быть реализованы в соответствии с [RFC8032].

Подписи для зон EDKEY используют секретный производный скаляр d’ и это не соответствует [RFC8032]. Поскольку севретный ключ, соответствующий секретному производному скаляру, неизвестен, невозможно детерминированно вывести часть подписи R в соответствии с [RFC8032]. Вместо этого генерация подписи для любого данного сообщения и секретного ключа зоны должна выполняться путём расчёта nonce из 32 старших байтов преобразования секретного ключа d и коэффициента ослепления h. Значение nonce затем хэшируется с сообщением, давая значение r. Таким образом, полный путь вывода включается в расчёт значения подписи R, гарантируя, что он не будет использован повторно для двух разных путей вывода или сообщений.

   SignDerived(d, label, message):
     /* Преобразование ключа */
     dh := SHA-512(d)
     /* Зажатие EdDSA */
     a := dh[0..31]
     a[0] := a[0] & 248
     a[31] := a[31] & 127
     a[31] := a[31] | 64
     /* Расчёт zkey, соответствующего d */
     zkey := a * G

     /* Расчёт коэффициент ослепления */
     PRK_h := HKDF-Extract("key-derivation", zkey)
     h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
     /* Обеспечение h == h mod L */
     h := h mod L

     d' := (h * a) mod L
     nonce := SHA-256(dh[32..63] || h)
     r := SHA-512(nonce || message)
     R := r * G
     S := r + SHA-512(R || zkey' || message) * d' mod L
     return (R,S)

Подпись (R,S) действительна для производного открытого ключа zkey’ := ZKDF(zkey, label) при выполнении условия

   VerifyDerived(zkey', message, signature):
     (R,S) := signature
     return S * G == R + SHA-512(R, zkey', message) * zkey'

Функции S-Encrypt() и S-Decrypt() используют XSalsa20 в соответствии с [XSalsa20] и функцию шифрования XSalsa20-Poly1305.

   S-Encrypt(zkey, label, expiration, plaintext):
     PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
     PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
     K := HKDF-Expand(PRK_k, label, 256 / 8)
     NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
     IV := NONCE || expiration
     return XSalsa20-Poly1305(K, IV, plaintext)

   S-Decrypt(zkey, label, expiration, ciphertext):
     PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
     PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
     K := HKDF-Expand(PRK_k, label, 256 / 8)
     NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
     IV := NONCE || expiration
     return XSalsa20-Poly1305(K, IV, ciphertext)

Результатом функции шифрования XSalsa20-Poly1305 является шифротекст, за которым следует 128-битовый тег аутентификации. Поэтому размер шифрованных данных увеличивается на 16 байтов тега проверки подлинности.

Ключ K и IV счётчика выводятся из метки записи и ключа зоны zkey с использованием HKDF, как задано в [RFC5869]. В фазе извлечения применяется SHA-512 [RFC6234], а в фазе преобразования (expansion) – SHA-256 [RFC6234]. Выходной ключевой материал – это 32 байта (256 битов) для симметричного ключа и 16 байтов (128 битов) для NONCE. Симметричный ключ K – это 256-битовый ключ XSalsa20 [XSalsa20]. Дополнительные данные аутентификации (additional authenticated data или AAD) не используются.

Значение nonce объединяется с 8-байтовым IV, который указывает срок действия блока записей ресурсов в сетевом порядке байтов. Формат передачи получаемого счётчика (IV) приведён на рисунке 12.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     NONCE                     |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Counter Block Initialization Vector.


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

Записи перенаправления служат для перенаправления процесса распознавания. Каждой реализации следует поддерживать все типы заданных здесь записей перенаправления и можно поддерживать любое число дополнительных записей перенаправления из реестра GANA GNS Record Types [GANA]. В записях перенаправления должен быть установлен флаг CRITICAL. Отказ от поддержки тех или иных типов записей может приводить к отказам при распознавании. Это может быть оправданным выбором, если некоторые типы записей перенаправления сочтены небезопасными или у приложения есть причины не поддерживать перенаправление в DNS, например, из-за сложности или небезопасности. Записи перенаправления недопустимо сохранять или публиковать под меткой вершины.

5.2.1. REDIRECT

Запись REDIRECT является эквивалентом GNS записи CNAME в DNS. Запись REDIRECT должна быть единственной не дополнительной (non-supplemental) записью под меткой. Могут быть другие неактивные записи того же типа с установленным флагом SHADOW для упрощения плавной смены ключей. Другие записи не разрешены. Детали обработки REDIRECT описаны в параграфе 7.3.1, формат REDIRECT DATA показан на рисунке 13.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   REDIRECT NAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи REDIRECT DATA.


REDIRECT NAME

Имя для продолжения работы (обычное или относительное). Относительные имена в GNS обозначаются меткой расширения + (U+002B) справа. Строка использует кодировку UTF-8 и завершается null-символом.

5.2.2. GNS2DNS

Запись GNS2DNS передаёт распознавание в DNS. Запись содержит DNS-имя распознавания в DNS, а затем – сервер DNS. Оба имени указываются в формате, заданном в [RFC1034] для имён DNS. Можно размещать несколько записей GNS2DNS под одной меткой. Под той же меткой могут присутствовать записи DNSSEC DS или иные записи, служащие для защиты соединения с сервером DNS. Могут быть другие неактивные записи того же типа (типов) с установленным флагом SHADOW для упрощения плавной смены ключей. Формат GNS2DNS DATA приведён на рисунке 14.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      NAME                     |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 DNS SERVER NAME               |
/                                               /
/                                               /
|                                               |
+-----------------------------------------------+

Рисунок . Формат передачи GNS2DNS DATA.


NAME

Имя для продолжения распознавания в DNS (кодировка UTF-8 и null-символ в конце).

DNS SERVER NAME

Используемый сервер DNS, указанный адресом IPv4 (через точки), адресом IPv6 (через двоеточия) или именем DNS. Это может быть также относительное имя GNS с символом + в качестве правой метки. Реализация должна проверять синтаксис строки для адресов IP в соответствии с подходящей нотацией перед проверкой относительного имени GNS. Если все три проверки дают отрицательный результат строка должна считаться именем DNS. Строка указывается в кодировке UTF-8 и завершается null-символом.

Примечание. Если приложение использует имена DNS полученные из записей GNS2DNS в запросе DNS, оно должно сначала преобразовать их в представление, совместимое с IDNA [RFC5890].

5.3. Вспомогательные записи

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

5.3.1. LEHO

Запись LEHO (LEgacy HOstname) служит подсказкой для унаследованных имён хостов. Приложения могут применять GNS при поиске адресов IPv4 или IPv6 для служб Internet, однако для подключения к таким службам может потребоваться передавать через транспортный протокол не только IP-адрес и порт, но и каноническое имя DNS для службы. В GNS записи с унаследованными именами предоставляют приложениям имя DNS, требуемое для соединения с такой службой. Наиболее распространенным случаем является работа с виртуальными хостами HTTP и TLS Server Name Indication [RFC6066], где имя DNS должно быть представлено в заголовке Host для HTTP и в согласовании TLS, соответственно. Имя GNS в таких случаях может не работать, поскольку оно может оказаться не уникальным глобально. Кроме того, даже если неуникальность не вызывает проблем, унаследованные службы могут просто не знать о GNS.

Предполагается, что запись LEHO будет встречаться вместе с записями A (IPv4) или AAAA (IPv6). Формат LEHO DATA показан на рисунке 15.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 LEGACY HOSTNAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи LEHO DATA.


LEGACY HOSTNAME

Строка UTF-8 (без null-символа в конце), представляющая унаследованное имя хоста.

Примечание. Если приложение использует значение LEHO в заголовке запроса HTTP (например, Host), оно должно преобразовываться в представление, соответствующее IDNA [RFC5890].

5.3.2. NICK

Записи с псевдонимами (nickname) могут применяться администраторами для публикации меток/. Которые зона предпочитает использовать в ссылках. Это является предложением для других зон в части выбора метки при создании записи делегирования (параграф 5.1), содержащей ключ зоны. Эту запись следует сохранять лишь локально под меткой вершины @, но её можно возвращать в наборе записей под любой меткой как дополнительную запись. В параграфе 7.3.5 описано, как распознаватель должен обрабатывать дополнительные и не дополнительные записи NICK. Форма NICK DATA показан на рисунке 16.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                  NICKNAME                     |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи NICK DATA.


NICKNAME

Строка UTF-8 (без null-символа в конце), представляющая предпочтительную метку зоны. Строка должна быть действительной меткой GNS.

5.3.3. BOX

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

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PROTO   |    SVC    |       TYPE            |
+-----------+-----------------------------------+
|                 RECORD DATA                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи BOX DATA.


Эта общая стратегия несовместима с особыми метками, используемыми в DNS для записей SRV и TLSA. Поэтому в GNS определён формат записи BOX для упаковки записей SRV и TLSA со включением в набор записей метки, с которой они связаны. Например, запись TLSA для _https._tcp.example.org будет сохранена в записи example.org как запись BOX с сервисом (SVC) 443 (https), протоколом (PROTO) 6 (tcp) и TYPE TLSA (см. [RFC2782]). Запись BOX DATA показана на рисунке 17.

PROTO

16-битовое значение номера протокола с сетевым порядком байтов. Значения меньше 28 зарезервированы для 8-битовых номеров протоколов IP, выделенных IANA [RFC5237] (например, 6 для TCP). Значения больше 28 выделяются через реестр GANA GNUnet Overlay Protocols [GANA].

SVC

16-битовое значение сервиса для коробочной записи с сетевым порядком байтов. Для TCP и UDP это номер порта.

TYPE

32-битовый идентификатор типа коробочной записи с сетевым порядком байтов.

RECORD DATA

Поле переменного размер, содержащее формат DATA типа TYPE. Для значений TYPE меньше 216 форма совпадает с двоичным форматом соответствующего типа записи в DNS.

6. Кодирование записей для удалённого хранилища

Любой API, позволяющий хранить блок под 512-битовым ключом и извлекать из ключа 1 или несколько блоков, можно применять в реализации как удалённое хранилище. Чтобы быть полезным и обеспечивать поддержку определённого кодирования для делегирования зон, API должен разрешать хранение блоков размером не менее 176 байтов и следует разрешать блоки размером 1024 байта и более. Далее предполагается реализация в хранилище процедур

   PUT(key, block)
   GET(key) -> block

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

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

Все записи о ресурсах из одной зоны используют общую метку, шифруются и публикуются вместе в одном блоке записи о ресурсах (RRBLOCK) на удалённом хранилище под ключом q, как показано на рисунке 18. Реализации GNS недопустимо включать в блоки просроченные записи о ресурсах. Реализация должна использовать процедуру хранилища PUT при изменении наборов записи для обновления содержимого зоны. Реализация должна гарантировать, что поля EXPIRATION в RRBLOCK монотонно возрастают при каждом изменении, даже когда наименьший оставшийся срок действия записи не увеличивается.

                            Локальный хост        |   Удалённое 
                                                  |   хранилище
                                                  |
                                                  |    +---------+
                                                  |   /         /|
                                                  |  +---------+ |
+------------+                                    |  |         | |
|            |       +-----------+PUT(q, RRBLOCK) |  |Хранилище| |
|Пользователь|       | Издатель  |----------------|->|записей  | |
|            |       | зоны      |                |  |         |/
+------------+       +-----------+                |  +---------+
     |                     A                      |
     |                     | Записи зон,          |
     |                     | сгруппированные      |
     |                     | по меткам            |
     |                 +---------+                |
     |Создание,       /    |    /|                |
     |удаление и     +---------+ |                |
     |обновление     |         | |                |
     |локальных зон  |Локальные| |                |
     +-------------->|зоны     | |                |
                     |         |/                 |
                     +---------+                  |

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


Вывод ключа зоны и создание блока записи описано в следующих параграфах и показано на рисунке 19.

+----------+ +-------+ +------------+ +-------------+
| Zone Key | | Label | | Record Set | | Private Key |
+----------+ +-------+ +------------+ +-------------+
    |          |            |               |
    |          |            v               |
    |          |           +-----------+    |
    |          +---------->| S-Encrypt |    |
    +----------|---------->+-----------+    |
    |          |               |    |       |
    |          |               |    v       v
    |          |               |   +-------------+
    |          +---------------|-->| SignDerived |
    |          |               |   +-------------+
    |          |               |        |
    |          v               v        v
    |      +------+        +--------------+
    +----->| ZKDF |------->| Record Block |
           +------+        +--------------+
              |
              v
           +------+        +-------------+
           | Hash |------->| Storage Key |
           +------+        +-------------+

Рисунок . Обзор создания Storage Key и Record Block.


6.1. Ключ хранилища

Ключ хранилища выводится из ключа зоны и соответствующей метки записей. Требование знать ключ и метку в сочетании с аналогично выведенными симметричными секретными ключами и скрытыми ключами зон обеспечивает конфиденциальность запросов (см. параграф 3.5 в [RFC8324]). С учётом метки ключ хранилища q выводится как

   q := SHA-512(ZKDF(zkey, label))

label

Строка UTF-8, под которой публикуются записи ресурсов.

zkey

Ключ зоны.

q

512-битовый ключ хранилища, с которым публикуется блок данных ресурса. Это хэш SHA-512 [RFC6234] от выведенного ключа зоны.

6.2. Текстовые данные записей (RDATA)

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

RDATA служит для кодирования таких групп записей GNS. Двоичный формат RDATA показан на рисунке 20.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 EXPIRATION                    |
+-----+-----+-----+-----+-----+-----+-----+-----+
|    SIZE   |    FLAGS  |        TYPE           |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      DATA                     /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|    SIZE   |    FLAGS  |        TYPE           |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     DATA                      /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     PADDING                   /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи RDATA.


EXPIRATION, SIZE, TYPE, FLAGS, DATA

Определения этих полей представлены под рисунком 7 в разделе 5.

PADDING

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

6.3. Блок записей о ресурсах

Записи о ресурсах, сгруппированные в RDATA, шифруются с помощью функции S-Encrypt(), определяемой типом зоны, к которой относятся записи, добавляется префикс метаданных и все вместе помещается в блок записей о ресурсах (RRBLOCK) для удалённого хранилища. Формат передачи GNS RRBLOCK показан на рисунке 21.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          SIZE         |    ZONE TYPE          |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                  ZONE KEY                     /
/                  (BLINDED)                    /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи RRBLOCK.


SIZE

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

ZONE TYPE

32-битовое значение ztype с сетевым порядком байтов.

ZONE KEY (BLINDED)

Ослепленный (скрытый) ключ зоны ZKDF(zkey, label) для использования при проверке SIGNATURE. Размер и формат ослеплённого ключа зависит от ztype.

SIGNATURE

Подпись, охватывающая поля EXPIRATION и BDATA, как показано на рисунке 22. Размер и формат подписи зависит от ztype. Подпись создаётся с помощью функции SignDerived() в криптосистеме зоны (см. раздел 4).

EXPIRATION

Указывает время завершения срока действия RRBLOCK, когда шифрованный блок следует удалить из хранилища и кэшей, поскольку он, скорей всего, устарел. Однако приложения могут продолжать использовать отдельные не устаревшие записи, пока срок их действия не завершится. Для определения срока действия RRBLOCK сначала должен определяться максимальный срока действия среди записей каждого типа в RRBLOCK, включая теневые записи. Затем берётся минимальное из полученных значений. Окончательным временем завершения срока действия будет большее из (1) прежнего значения EXPIRATION в предыдущем RRBLOCK (при наличии) для того же ключа хранилища + 1 и (2) рассчитанного минимального времени завершения срока действия для содержащихся в блоке типов записей. Это обеспечивает строгую монотонность (см. параграф 9.3). Срок завершения указывает 64-битовым значением абсолютной даты в микросекундах с полуночи (0 часов) 1 января 1970 г. в часовом поясе UTC с сетевым порядком байтов.

BDATA

Зашифрованные данные RDATA, полученные с помощью функции S-Encrypt() с ключом зоны, меткой и датой завершения срока действия в качестве дополнительных входных данных. Окончательный размер и содержимое определяется функцией S-Encrypt() для ztype.

Подпись для открытого ключа охватывает 32-битовый псевдозаголовок, размещаемый перед полями EXPIRATION и BDATA. Формат передачи показан на рисунке 22.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE (0x0F)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

Рисунок . Формат передачи при создании подписи RRBLOCK.


SIZE

32-битовое значение размера подписанных данных в байтах с сетевым порядком байтов.

PURPOSE

32-битовый флаг назначения подписи с сетевым порядком байтов. Это поле должно иметь значение 15 и указывает контекст, в котором создаётся подпись, чтобы её можно было повторно использовать в других частях протокола, которые могут включать возможные будущие расширения. Значение поля соответствует записи в реестре GANA GNUnet Signature Purposes [GANA].

EXPIRATION

См. определение одноимённого поля для сообщения RRBLOCK.

BDATA

См. определение одноимённого поля для сообщения RRBLOCK.

7. Распознавание имени

                           Локальный                  |   Удалённое 
                           хост                       |   хранилище
                                                      |
                                                      |    +---------+
                                                      |   /         /|
                                                      |  +---------+ |
+-----------+ (1) Поиск+--------------+               |  |         | |
|           | имени    |              | (3a) GET(q)   |  |Хранилище| |
|Приложение |----------|Распознаватель|---------------|->| записей | |
|           |<---------|              |<--------------|--|         |/
+-----------+ (4)      +--------------+ (3b) RRBLOCK  |  +---------+
                 Записи        A                      |
                               |                      |
        (2) Определение        |                      |
            Start Zone         |                      |
                               |                      |
                            +---------+               |
                           /   |     /|               |
                          +---------+ |               |
                          |         | |               |
                          |Стартовые| |               |
                          |  зоны   | |               |
                          |         |/                |
                          +---------+                 |

Рисунок . Процесс рекурсивного распознавания GNS.


Имена в GNS распознаются путём рекурсивных запросов к хранилищам записей. Рекурсия в этом контексте означает, что распознаватель не предоставляет приложению промежуточных результатов запроса и должен ответить запрашиваемой записью о ресурсе или сообщением об ошибке, если распознавание не удалось. На рисунке 23 показано, как приложение запрашивает поиск имени GNS (1). Приложение может указать распознавателю желаемый тип записи, затем определяется Start Zone (2) и начинается процесс рекурсивного распознавания. Здесь желаемый тип записи служит для управления процессом. Например, если запрашивается тип записи делегирования зоны, распознавание метки вершины для этой зоны должно пропускаться, так как нужная запись уже найдена. Детали инициирования процесса распознавания и обработки результата преобразования в каждой итерации (3a,3b) рассматриваются в последующих параграфах. Приложение в конечном итоге получает результат поиска (4). Реализациям недопустимо фильтровать возвращаемые наборы записей о ресурсах в соответствии с желаемым типом записи. Такую фильтрацию обычно выполняет приложение.

7.1. Стартовая зона

Распознавание имени GNS начинается с идентификации суффикса Start Zone, после чего начинается рекурсивное распознавание остальной части имени (параграф 7.2). Имеется два типа суффиксов Start Zone – zTLD и локальные сопоставления суффиксов с зонами. Выбор подходящего сопоставления суффиксов с зонами полностью отдаётся администратору или пользователю локальной системы. Это решает задачу создания единой иерархии с централизованно управляемым корнем и связанную с ней задачу распространения и поддержки корневых серверов DNS (смю параграф 3.12 и 3.10 в [RFC8324]).

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

   www.example.<zTLD>
   => Start Zone: zkey типа ztype
   => Имя для распознавания из Start Zone: www.example

Для имён без суффикса zTLD распознаватель должен определять Start Zone по локальному сопоставлению суффиксов с зонами. Эти сопоставления должны быть настраиваемыми через локальный файл конфигурации или базу данных пользователем или администратором системы. Суффикс может состоять из нескольких меток GNS через разделители. Если распознаваемому имени соответствует несколько суффиксов, должен выбираться самый длинный из них. Размерам суффиксов из двух результатов недопустимо быть равными. Это указывает ошибочную настройку и реализация должна возвращать ошибку. Ниже приведён ненормативный пример отображения Start Zone.

   www.example.xyz.gns.alt
   локальные отображения суффиксов:
   xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
   example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
   example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
   ...
   => Start Zone: zkey1
   => Имя для распознавания из Start Zone: www

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

7.2. Рекурсия

На каждом этапе рекурсивного распознавания имеется ключ полномочной хоны zkey и имя для распознавания. Имя может быть пустым и в этом случае оно интерпретируется как метка вершины зоны @. Исходно полномочной зоной является стартовая – Start Zone. Далее операции выполняются рекурсивно в показанном ниже порядке.

  1. Извлечение из имени правой метки для поиска.

  2. Расчёт q с использованием метки и zkey, как указано в параграфе 6.1.

  3. Выполнение запроса GET(q) к хранилищу для извлечения RRBLOCK.

  4. Проверка того, что (a) срок действия блока не истек, (b) хэш SHA-512 производного ключа полномочной зоны zkey’ из RRBLOCK совпадает со значением q в запросе и (c) подпись действительна. Если любое из этих условий не выполняется, RRBLOCK должен игнорироваться и поиск (если это применимо) GET(q) в хранилище должен продолжаться для извлечения других RRBLOCK.

  5. Получение RDATA путём расшифровки BDATA из RRBLOCK с использованием функции S-Decrypt(), определяемой типом зоны (фактически обращение процесса, описанного в параграфе 6.3).

После расшифровки корректно сформированного блока выполняется обработка записей из RDATA.

7.3. Обработка записей

Обработка выполняется только для действительных записей. Для фильтрации непригодных записей распознаватель должен проверить в записях хотя бы поля срока действия и FLAGS. Просроченные записи распознаватель должен отбрасывать, а записи с флагами SHADOW и SUPPLEMENTAL могут исключаться из рассмотрения. Если распознаватель встречает запись с флагом CRITICAL и неподдерживаемым типом, распознавание должно прерываться с возвратом ошибки. В описание ошибки следует включать сведения, указывающие, что критическая запись не может быть обработана. Реализация может не указывать причину отказа, но это осложнит пользователям поиск неполадок. Дальнейшие действия зависят от контекста, в котором происходит распознавание имени.

Вариант 1

Если после фильтрации в наборе осталась лишь 1 запись REDIRECT, остаток имени помещается перед REDIRECT DATA и выполняется распознавание имени для результата (см. параграф 7.3.1).

Вариант 2

Если после фильтрации в наборе остались только записи GNS2DNS, распознавание продолжается в DNS (см. параграф 7.3.2).

Вариант 3

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

Вариант 4

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

Вариант 5

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

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

7.3.1. REDIRECT

Если оставшееся имя не пусто и желаемым типом записи является REDIRECT, распознавание завершается записью REDIRECT. Если правой частью REDIRECT NAME является метка расширения (U+002B, +), распознавание продолжается в GNS с новым именем в текущей зоне. В иных случаях результирующее имя распознаётся через принятый по умолчанию в операционной системе процесс распознавания имён. Это может вызывать процесс распознавания имён GNS при соответствующей настройке системы. Если распознавание продолжается в DNS, имя сначала должно приводиться в совместимое с IDNA представление [RFC5890].

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

7.3.2. GNS2DNS

Распознаватель возвращает записи GNS2DNS при выполнении трёх указанных ниже условий.

  1. Распознаватель встречает одну или несколько записей GNS2DNS.

  2. Оставшаяся часть имени пуста.

  3. Желаемым типом записи является GNS2DNS.

В иных случаях предполагается, что распознаватель сначала узнает IP-адреса указанных серверов имён DNS. Имя DNS должно преобразовываться в совместимое с IDNA представление [RFC5890] для распознавания в DNS. Записи GNS2DNS могут включать численные адреса IPv4 или IPv6, позволяя распознавателю пропустить этот шаг. Имена серверов DNS сами могут быть именами GNS или DNS. Если правой меткой в имени сервера DNS является метка расширения (U+002B, +), остальная часть имени интерпретируется относительно зоны записи GNS2DNS. Если имя сервера DNS завершается меткой, представляющей ключ зоны, имя сервера DNS распознаётся по ключу зоны GNS.

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

Если под меткой имеются записи DNSSEC DS или иные записи, служащие для защиты соединений с серверами DNS, распознавателю DNS следует использовать их для защиты соединения с сервером DNS.

После определения IP-адресов серверов DNS имя DNS из записи GNS2DNS добавляется в конец оставшейся части имени для распознавания и для результата выполняется распознавание путём запросов к серверам имён DNS. Синтезированное имя должно быть преобразовано в совместимое с IDNA представление [RFC5890] для распознавания в DNS. Если такое преобразование невозможно, распознавание должно прерываться с возвратом ошибки. В описание ошибки следует включать сведения, указывающие, что критическая запись не может быть обработана. Реализация может не указывать причину отказа, но это осложнит пользователям поиск неполадок.

Поскольку указанные серверы DNS могут оказаться полномочными, распознаватель GNS должен поддерживать рекурсивное распознавание DNS и эту функцию недопустимо делегировать полномочным серверам DNS. Приложению возвращается первый успешный результат рекурсивного распознавания. Кроме того, распознавателю следует возвращать запрошенное имя DNS как дополнительную запись LEHO (см. параграф 5.3.1) с относительным сроком действия в 1 час.

После перехода из GNS в DNS с помощью записи GNS2DNS «возврата» уже не будет. Распознавание (возможно, рекурсивное) имени DNS недопустимо делегировать обратно в GNS и следует применять только спецификации DNS. Например, имена из записей DNS CNAME распознавателям, поддерживающим DNS и GNS, недопустимо считать именами GNS.

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

7.3.3. BOX

При получении записи BOX распознаватель GNS должен распаковать её, если распознаваемое имя продолжается _SERVICE._PROTO. В ином случае запись BOX остаётся нетронутой. Таким образом, записи TLSA (и SRV) не требуют отдельного сетевого запроса и записи TLSA становятся неотделимыми от соответствующих адресных записей.

7.3.4. Записи делегирования зон

Когда распознаватель встречает запись делегирования поддерживаемого типа (например, PKEY или EDKEY) и оставшаяся часть имени не пуста, распознавание продолжается рекурсивно для оставшейся части имени в зоне GNS, указанной записью делегирования.

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

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

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

7.3.5. NICK

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

Различие между дополнительными и не дополнительными записями NICK позволяет приложению сопоставить запись с полномочной зоной, например,

   Query: alice.example.gns.alt (type=A)
   Result:
   A: 192.0.2.1
   NICK: eve (non-supplemental)

Здесь возвращённая запись NICK является не дополнительной. Для приложения это означает, что NICK относится к зоне alice.example.gns.alt и публикуется под меткой вершины вместе с записью A. Запись NICK интерпретируется как «зона, заданная alice.example.gns.alt, хочет, чтобы её указывали как eve». Рассмотрим другой пример

   Query: alice.example.gns.alt (type=AAAA)
   Result:
   AAAA: 2001:db8::1
   NICK: john (supplemental)

Здесь запись NICK помечена как дополнительная. Это означает, что NICK относится к зоне example.gns.alt и публикуется под меткой alice вместе с записью AAAA. Запись NICK интерпретируется как «зона, заданная example.gns.alt, хочет, чтобы её указывали как john». Это различие полезно и для других записей, публикуемых как дополнительные.

8. Другие языки и кодировка символов

Все имена в GNS используют кодировку UTF-8 [RFC3629]. Метки должны канонизироваться с использованием нормализованной формы C (Normalization Form C или NFC) [Unicode-UAX15]. Это не относится к именам DNS в записях DNS, таких как CNAME, которые могут использовать другие языки в соответствии со спецификацией IDNA [RFC5890].

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

9.1. Доступность

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

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

9.2. Стойкость

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

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

В части криптостойкости при возникновении необходимости в новой криптосхеме (например, ECDSA на основе Ed25519 для записей PKEY) её можно просто ввести через новый тип записей. Администраторы зон могут поменять тип для будущих записей делегирования. Прежний тип записи остаётся и зоны могут постепенно (итерациями) переходить на обновлённые ключи. Чтобы реализации корректно выдавали сообщения об ошибках при обнаружении неподдерживаемого ztype, имеющиеся и будущие записи делегирования должны иметь флаг CRITICAL.

9.3. Криптография

Приведённые ниже соображения служат основой для выбора ztype, заданных в этом документе. Эти же соображения применимы при задании новых ztype в соответствии с разделом 4.

Ключи зон GNS PKEY используют ECDSA на основе Ed25519. Это нетрадиционный выбор, поскольку ECDSA обычно применяется с другими кривыми. Однако стандартизованные кривые ECDSA проблематичны по ряду причин, как указано в статьях Curve25519 и EdDSA [RFC7748] [ed25519]. Применение EdDSA напрямую также невозможно, поскольку для секретного ключа применяется хэш-функция, нарушающая линейность, от которой зависит сокрытие ключа в GNS. Неизвестно, чтобы кто-то предполагал, что применение Ed25519 вместо другой распространённой кривой аналогичного размера снижало бы безопасность ECDSA. В GNS применяются 256-битовые кривые, поэтому зашифрованные (открытые) ключи помещаются в одну метку DNS, что удобно для применения.

Для обеспечения неотличимости (indistinguishability) шифротекста нужно внимательно относиться к выбору IV в блоке счётчика. В описываемом решении IV всегда включает время завершения срока действия блока записей. Когда приложения хранят записи с относительным сроком действия, монотонность обеспечивается неявно, поскольку при каждой публикации блока в хранилище его значение IV уникально, так как время завершения срока действия рассчитывается динамически и монотонно возрастает с течением системного времени. Тем не менее, реализация должна гарантировать, что при уменьшении относительного срока действия время завершения срока действия следующего блока записей должно быть позже последнего опубликованного блока. Для записей с абсолютным сроком действия реализация должна гарантировать, что время завершения срока действия всегда увеличивается при изменении данных в записи. Например, время завершения срока действия может увеличиться при передаче на 1 мксек, даже если пользователь не запрашивал изменений. В случае удаления всех записей о ресурсах под меткой реализация должна отследить последнее абсолютное время завершения срока действия последнего опубликованного блока ресурсов. Реализация может задать и использовать специальный тип записи в качестве «надгробия» сохраняющего последнее абсолютное время завершения срока действия, но затем должна принять меры для предотвращения публикации блока с таким надгробием. При добавлении новых записей под этой меткой позднее реализация должна гарантировать, что срок их действия завершается после опубликованного последним блока. Для обеспечения монотонного роста времени завершения срока действия реализация должна локально хранить запись последнего времени по системным часам, чтобы создать монотонные часы при переводе системных часов назад.

9.4. Смягчение злоупотреблений

Имена GNS – это строки UTF-8, поэтому GNS сталкивается с проблемами подделки имён, похожими на проблемы подделки в DNS, связанные с доменными именами на местных языках. В DNS злоумышленники могут регистрировать схожие визуально или на слух имена для организации фишинговых атак. Администраторы зон GNS должны учитывать это и принимать правила для смягчения таких атак.

DNS может применяться для борьбы с нелегальным содержимым в Internet путём изъятия соответствующих доменов. Однако такие же механизмы могут применяться для государственной цензуры. Предотвращение таких возможностей стало одной из причин разработки GNS, где домены TLD не являются счётными. Стартовая зона (Start Zone) распознавателя задаётся локально, поэтому изъятие доменов сложно и неэффективно в GNS.

9.5. Поддержка зон

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

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

Хотя реализации, соблюдающие эту спецификацию, будут совместимы, при подключении двух реализаций к разным удаленным хранилищам они будут недоступны друг другу. Это может привести к состоянию, когда в глобальном пространстве имён имеется запись для определённого имени, но реализация не взаимодействует с удаленным хранилищем, где размещён соответствующий блок, и поэтому не способна распознать имя. Это похоже на ситуацию с расщеплением горизонта (split-horizon) в DNS. Используемый объект удалённого хранилища скорей всего будет зависеть от контекста конкретного приложения, применяющего распознавание GNS. Например, одним из приложений является распознавание скрытых служб в сети Tor [TorRendSpec], что предполагает использование маршрутизаторов Tor в качестве удалённых хранилищ. Реализации «агрегированных» сущностей удалённого хранения возможны, но предполагаются исключительными случаями, нежели нормой.

9.6. DHT как удалённое хранилище

Этот документ не задаёт свойств базового удалённого хранилища, требуемых для любой реализации GNS. Важно отметить, что такие свойства реализация GNS наследует напрямую. Это включает свойства защиты и другие не функциональные свойства, такие как расширяемость и производительность. Разработчикам следует очень внимательно относится к выбору DHT для использования в качестве удалённого хранилища в реализации GNS. Имеются DHT с разумными характеристиками безопасности и производительности [R5N]. Следует также учитывать, что реализации GNS, основанные на разных наложенных DHT, вряд ли будут доступны друг другу.

9.7. Отзывы

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

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

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

9.8. Приватность зоны

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

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

9.9. Управление зонами

Хотя система DNS является распределенной, на практике она полагается для обеспечения глобальной уникальности имён на централизованных, доверенных регистраторов. По мере осознания центральной роли DNS в Internet различные организации используют свои возможности (в том числе юридические) для атак на DNS, создавая угрозы глобальной доступности и целостности информации в Internet. Широкое обсуждение этого вопроса выходит за рамки документа, а об исследованиях и анализе можно прочитать в свежих научных работах, включая [SecureNS].

GNS предназначена обеспечить защищённую и повышающую уровень приватности альтернативу протоколу распознавания имён DNS, особенно при наличии цензуры или манипулирования информацией. В частности, решаются проблемы DNS, связанные с приватностью запросов. Однако в зависимости от управления корневой зоной любое развёртывание столкнётся с проблемой единой иерархии с централизованно управляемым корнем и связанной с этим проблемой распространения и поддержки корневых серверов DNS, рассмотренными в параграфах 3.12 и 3.10 [RFC8324]. В DNS эти проблемы напрямую связаны с централизованным управлением корневой зоной Корпорацией по назначению имён и значений в Internet (Internet Corporation for Assigned Names and Numbers или ICANN), которое позволяет обеспечивать глобальную уникальность имён.

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

Любая реализация GNS может предоставлять принятую по умолчанию модель управления в форме начального сопоставления Start Zone.

9.10. Неоднозначность пространства имён

Технически можно применять протокол GNS для распознавания имён в глобальном пространстве DNS, однако для этого требуется стандартизация применения GNS для этого частного случая соответствующими органами управления и заинтересованными сторонами (например, IETF и ICANN). Эта возможность предполагает, что имена GNS могут быть не отличимыми от имён DNS в соответствующем общем формате отображения [RFC8499] или специальных форматах доменных имён [RFC6761], если конфигурация Start Zone сопоставляет глобальные суффиксы DNS с зонами GNS. Для приложений выбор системы для распознавания данного имени будет неоднозначным. Это создаёт риск при попытке распознавания через DNS имени GNS, как отмечено в [RFC8244]. В этом случае имя GNS может быть раскрыто в процессе распознавания DNS. Для предотвращения раскрытия запрашиваемых имён GNS рекомендуется понимающим GNS приложениям пытаться распознать имя в GNS до применения других методов (с учётом возможных сопоставлений суффиксов с зонами и zTLD). Предполагается, что сопоставления суффиксов с зонами настраиваются локальным администратором, поэтому распознавание в GNS будет соответствовать ожиданиям пользователя, даже если имя можно распознать в DNS. Если для имени нет сопоставления суффиксов с зонами и не найдено zTLD, распознавание можно продолжить с другими методами, такими как DNS. Если сопоставление для имени имеется или имя заканчивается zTLD, оно должно распознаваться с применением GNS и распознавание недопустимо продолжать с другими методами, независимо от результата распознавания GNS.

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

Для случаев, когда имена GNS можно спутать с именами других механизмов распознавания (в частности, DNS), следует применять домен .gns.alt. В случаях использования ловушек (sinkhole) для блокировки вредоносных сайтов или обслуживания доменов DNS через GNS для обхода цензуры GNS можно намеренно применять таким образом, чтобы мешать распознаванию другими системами.

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

10.1. Реестр GNUnet Signature Purposes

Агентство GANA [GANA] поддерживает реестр назначений подписей GNUnet Signature Purposes (таблица 1).

Таблица . Реестр GANA GNUnet Signature Purposes.

 

Назначение

Имя

Документ

Комментарий

3

GNS_REVOCATION

RFC 9498

Отзыв ключа зоны GNS

15

GNS_RECORD_SIGN

RFC 9498

Подпись набора записей GNS

 

10.2. Реестр GNS Record Types

GANA [GANA] поддерживает реестр GNS Record Types, каждая запись которого включает указанные ниже поля.

Name

Имя типа записи (строка букв и цифр ASCII без учёта регистра). Для записей делегирования выделенное значение представляет ztype зоны.

Number

32-битовое целое число больше 65535.

Comment

Необязательное краткое описание назначения типа на английском языке (кодировка UTF-8).

Contact

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

References

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

Регистрация выполняется по мере подачи запросов (First Come First Served), похожей на одноимённую процедуру из [RFC8126] и описывающей действия, предпринимаемые GANA.

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

  • Уполномоченные участники GANA для рецензирования заявок доступны по адресу <gns-registry@gnunet.org>.

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

Агентство GANA выделило номера для типов записей, определённых в этом документе, в реестре GNS Record Types (таблица 2).

Таблица . Реестр GANA GNS Record Types.

 

Значение

Имя

Контактные данные

Документ

Комментарии

65536

PKEY

gns-registry@gnunet.org

RFC 9498

Делегирование зоны GNS (PKEY)

65537

NICK

gns-registry@gnunet.org

RFC 9498

Псевдоним зоны GNS

65538

LEHO

gns-registry@gnunet.org

RFC 9498

Унаследованное имя хоста GNS

65540

GNS2DNS

gns-registry@gnunet.org

RFC 9498

Делегирование в DNS

65541

BOX

gns-registry@gnunet.org

RFC 9498

Коробочные записи

65551

REDIRECT

gns-registry@gnunet.org

RFC 9498

Запись перенаправления

65556

EDKEY

gns-registry@gnunet.org

RFC 9498

Делегирование зоны GNS (EDKEY)

 

10.3. Реестр субдоменов .alt

GANA [GANA] поддерживает реестр .alt Subdomains, который могут (но не обязаны) принимать во внимание конкретные исполнители. Реестр не утверждён IETF или ICANN и никак не связан с ними. Содержимое реестра указано ниже.

Label

Метка субдомена в формате DNS «буквы, цифры, дефис» (letters, digits, hyphen или LDH) заданном в параграфе 2.3.1 [RFC5890]).

Description

Необязательное краткое описание назначения типа на английском языке (кодировка UTF-8).

Contact

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

References

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

Регистрация выполняется по мере подачи запросов (First Come First Served), похожей на одноимённую процедуру из [RFC8126] и описывающей действия, предпринимаемые GANA.

  • Добавление записей возможно после рецензирования любым полномочным участником GANA с регистрацией выделения уникальных субдоменов в порядке поступления запросов. Рецензенты отвечают за соответствие выбранного значения Subdomain назначению субдомена.

  • Уполномоченные участники GANA для рецензирования заявок доступны по адресу <alt-registry@gnunet.org>.

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

Агентство GANA выделило заданный этим документом субдомен в реестре .alt Subdomains (таблица 3).

Таблица . Реестр GANA .alt Subdomains Registry.

 

Метка

Контактные данные

Документ

Описание

gns

alt-registry@gnunet.org

RFC 9498

Субдомен .alt для GNS

 

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

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

12. Статус реализации и внедрения

Имеются две реализации, соответствующие данной спецификации, одна из которых написана на языке C, другая – на Go. Реализация на C, являющаяся частью проекта GNUnet [GNUnetGNS], является оригинальной и эталонной. Реализация на Go [GoGNS] демонстрирует совместимость двух реализаций GNS, работающих на основе одного базового хранилища DHT. В настоящее время в одноранговой (peer-to-peer) сети GNUnet [GNUnet] активно внедряется GNS на основе DHT [R5N]. Реализация Go [GoGNS] использует это для построения на основе GNUnet DHT служб, доступных любому партнёру GNUnet. Это показывает, как реализации GNS могут подключаться к имеющемуся развёртыванию и участвовать в распознавании имён и публикации зон.

Суверенная (self-sovereign) система идентификации re:claimID [reclaim] применяется в GNS для выборочного обмена атрибутами отождествлений и аттестатами с третьими сторонами.

Инструмент Ascension [Ascension] облегчает перевод зон DNS в зоны GNS путём трансляции информации, полученной из зоны DNS, в зону GNS.

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

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

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

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

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

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

[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3686] Housley, R., “Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)”, RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>.

[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, “The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model”, RFC 3826, DOI 10.17487/RFC3826, June 2004, <https://www.rfc-editor.org/info/rfc3826>.

[RFC5237] Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field”, BCP 37, RFC 5237, DOI 10.17487/RFC5237, February 2008, <https://www.rfc-editor.org/info/rfc5237>.

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

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

[RFC5895] Resnick, P. and P. Hoffman, “Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008”, RFC 5895, DOI 10.17487/RFC5895, September 2010, <https://www.rfc-editor.org/info/rfc5895>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6895] Eastlake 3rd, D., “Domain Name System (DNS) IANA Considerations”, BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC6979] Pornin, T., “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)”, RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, “Elliptic Curves for Security”, RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.

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

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

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

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

[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications”, RFC 9106, DOI 10.17487/RFC9106, September 2021, <https://www.rfc-editor.org/info/rfc9106>.

[GANA] GNUnet e.V., “GNUnet Assigned Numbers Authority (GANA)”, 2023, <https://gana.gnunet.org/>.

[MODES] Dworkin, M., “Recommendation for Block Cipher Modes of Operation: Methods and Techniques”, NIST Special Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December 2001, <https://doi.org/10.6028/NIST.SP.800-38A>.

[CrockfordB32] Crockford, D., “Base 32”, March 2019, <https://www.crockford.com/base32.html>.

[XSalsa20] Bernstein, D. J., “Extending the Salsa20 nonce”, 2011, <https://cr.yp.to/papers.html#xsalsa>.

[Unicode-UAX15] Davis, M., Whistler, K., and M. Dürst, “Unicode Standard Annex #15: Unicode Normalization Forms”, Revision 31, The Unicode Consortium, Mountain View, September 2009, <https://www.unicode.org/reports/tr15/tr15-31.html>.

[Unicode-UTS46] Davis, M. and M. Suignard, “Unicode Technical Standard #46: Unicode IDNA Compatibility Processing”, Revision 31, The Unicode Consortium, Mountain View, September 2023, <https://www.unicode.org/reports/tr46>.

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

[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, “SOCKS Protocol Version 5”, RFC 1928, DOI 10.17487/RFC1928, March 1996, <https://www.rfc-editor.org/info/rfc1928>.

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

[RFC6066] Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC7363] Maenpaa, J. and G. Camarillo, “Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)”, RFC 7363, DOI 10.17487/RFC7363, September 2014, <https://www.rfc-editor.org/info/rfc7363>.

[RFC8324] Klensin, J., “DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?”, RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>.

[RFC8806] Kumari, W. and P. Hoffman, “Running a Root Server Local to a Resolver”, RFC 8806, DOI 10.17487/RFC8806, June 2020, <https://www.rfc-editor.org/info/rfc8806>.

[RFC6761] Cheshire, S. and M. Krochmal, “Special-Use Domain Names”, RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.

[RFC8244] Lemon, T., Droms, R., and W. Kumari, “Special-Use Domain Names Problem Statement”, RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.

[RFC9476] Kumari, W. and P. Hoffman, “The .alt Special-Use Top-Level Domain”, RFC 9476, DOI 10.17487/RFC9476, September 2023, <https://www.rfc-editor.org/info/rfc9476>.

[TorRendSpec] Tor Project, “Tor Rendezvous Specification – Version 3”, commit b345ca0, June 2023, <https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt>.

[Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, “Next-Generation Hidden Services in Tor”, Appendix A.2 (“Tor’s key derivation scheme”), November 2013, <https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135>.

[SDSI] Rivest, R. L. and B. Lampson, “SDSI – A Simple Distributed Security Infrastructure”, October 1996, <https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367>.

[Kademlia] Maymounkov, P. and D. Mazières, “Kademlia: A Peer-to-peer Information System Based on the XOR Metric”, DOI 10.1007/3-540-45748-8_5, 2002, <https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf>.

[ed25519] Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B-Y. Yang, “High-speed high-security signatures”, DOI 10.1007/s13389-012-0027-1, 2011, <https://ed25519.cr.yp.to/ed25519-20110926.pdf>.

[GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, “A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System”, 13th International Conference on Cryptology and Network Security (CANS), DOI 10.13140/2.1.4642.3044, October 2014, <https://sci-hub.st/10.1007/978-3-319-12280-9_9>.

[R5N] Evans, N. S. and C. Grothoff, “R5N: Randomized Recursive Routing for Restricted-Route Networks”, 5th International Conference on Network and System Security (NSS), DOI 10.1109/ICNSS.2011.6060022, September 2011, <https://sci-hub.st/10.1109/ICNSS.2011.6060022>.

[SecureNS] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, “Toward secure name resolution on the Internet”, Computers and Security, Volume 77, Issue C, pp. 694-708, DOI 10.1016/j.cose.2018.01.018, August 2018, <https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018>.

[GNUnetGNS] GNUnet e.V., “gnunet.git – GNUnet core repository”, 2023, <https://git.gnunet.org/gnunet.git>.

[Ascension] GNUnet e.V., “ascension.git – DNS zones to GNS migrating using incremental zone transfer (AXFR/IXFR)”, 2023, <https://git.gnunet.org/ascension.git>.

[GNUnet] GNUnet e.V., “The GNUnet Project (Home Page)”, 2023, <https://gnunet.org>.

[reclaim] GNUnet e.V., “re:claimID – Self-sovereign, Decentralised Identity Management and Personal Data Sharing”, 2023, <https://reclaim.gnunet.org>.

[GoGNS] Fix, B., “gnunet-go (Go GNS)”, commit 5c815ba, July 2023, <https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns>.

[nsswitch] GNU Project, “System Databases and Name Service Switch (Section 29)”, <https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html>.

Приложение A. Использование и переход

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

A.1. Распространение зон

Чтобы стать владельцем зоны, достаточно создать ключ зоны и соответствующий секретный ключ с помощью реализации GNS. С этого момента владелец зоны может управлять записями о ресурсах GNS в базе данных локальной зоны. Затем записи можно опубликовать через реализацию GNS, как описано в разделе 6. Чтобы другие пользователи могли распознать (resolve) записи о ресурсах, сначала нужно распространить соответствующие сведения о зоне. Владелец зоны может раскрыть ключ зоны и метки лишь ограниченному кругу пользователей или сделать их доступными для всех. Совместное использование данных зоны ограниченным кругом пользователей позволяет не только сохранить приватность зоны и записей, но и установить строгие доверительные отношения. Например, банк может отправить своему клиенту письмо с QR-кодм, содержащим GNS-зону банка. Это позволить отсканировать QR-код и установить прочную связь с зоной банка, а также, например, с IP-адресом web-интерфейса банка.

Большинство служб Internet, вероятно, пожелает сделать свои зоны доступными широкому кругу наиболее эффективным способом. Во-первых, разумно предположить, что зоны с высоким уровнем доверия и репутации будут, скорей всего, включены в сопоставления суффиксов с зонами в реализациях. Поэтому распространение зоны через делегирование под такими зонами может стать жизнеспособным способом распространения зон. Например, можно предположить, что организации, подобные ICANN и регистраторам TLD для стран, также будут поддерживать зоны GNS и предоставлять услуги по регистрации и делегированию.

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

A.2. Конфигурация Start Zone

Предполагается, что пользователь установит реализацию GNS, если она ещё не представлена такими средствами, как операционная система или браузер. Вполне вероятна поставка реализации с принятой по умолчанию конфигурацией Start Zone. Это означает, что пользователь сможет распознавать имена GNS, завершающиеся zTLD или суффиксом из сопоставления суффиксов с зонами, на основе заданной по умолчанию конфигурации Start Zone. На этом этапе пользователь может удалить или изменить принятые по умолчанию настройки.

  • Удаление сопоставлений суффиксов с зонами может потребоваться при утрате доверия пользователя к владельцу зоны, включённой в сопоставление. Например, это может быть связано с небрежной политикой регистрации, приводящей к фишингу. Изменение сопоставлений или добавление новых позволяет устранить «перфорацию» пространства имён, которая может возникнуть в результате удаления, или просто установить прочные доверительные отношения. Однако для этого пользователю нужно знать ключи соответствующих зон. Эти сведения должны получаться по отдельному каналу (out of band), как показано в Приложении A.1 (банк может отправить пользователю письмо с QR-кодом, содержащим GNS-зону банка и пользователь сканирует QR-код, добавляя новое сопоставление суффикса с именем для этого банка). Другие примеры включают сканирование сведений о зоне с дружественного устройства, витрины магазина или из рекламы. Уровень доверия к соответствующей зоне зависит от контекста и, вероятно, будет разным у пользователей. Доверие к зоне, представленной письмом из банка, к которому может быть приложена кредитная карта, будет отличаться от доверия к зоне из случайной рекламы на улице. Однако уровень доверия сразу же виден пользователю и может быть отражён в локальном именовании.

  • Пользователям, которые являются клиентами, следует облегчать изменение конфигурации Start Zone, например, предоставляя считыватель QR-кода или иные механизмы импорта. В идеале реализации нужно следовать передовому опыту с учётом применимых соображений из раздела 9. Формализация этого выходит за рамки этой спецификации.

A.3. Глобально уникальные имена и Web

Виртуальный хостинг HTTP и указание имени сервера TLS (SNI) широко распространены в Web. Клиенты HTTP предоставляют имя DNS в поле Host заголовка HTTP или при согласовании TLS. Это позволяет серверу HTTP обслуживать указанный виртуальный хост с соответствующим сертификатом TLS. Для этого требуется глобальная уникальность имён DNS.

В GNS не все имена уникальны в глобальном масштабе, однако запись о ресурсе GNS можно представить конкатенацией метки GNS и zTLD зоны. Глобальные имена GNS неудобны для запоминания, но их можно использовать в упомянутых выше случаях. Рассмотри имя GNS www.example.gns.alt, введённое в понимающем GNS клиенте HTTP. Сначала www.example.gns.alt распознаётся в GNS с возвратом набора записей, затем клиент HTTP определяет виртуальный хост, как описано ниже.

При наличии в наборе записи LEHO (параграф 5.3.1) с www.example.com клиент HTTP использует это имя в поле заголовка HTTP Host.

   GET / HTTP/1.1
   Host: www.example.com

Если записи LEHO нет, требуется дополнительное распознавание GNS, чтобы проверить, указывает ли www.example.gns.alt на запись делегирования зоны, что подразумевает публикацию исходно распознанного набора записей под меткой вершины. Если это так, уникальное имя GNS является просто zTLD-представлением делегированной зоны

   GET / HTTP/1.1
   Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W

Если записи делегирования зоны для www.example.gns.alt нет, уникальное имя GNS является конкатенацией левой метки (например, www) и zTLD-представления зоны

   GET / HTTP/1.1
   Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W

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

Если клиент HTTP является браузером, использование уникального имени GNS для виртуального хоста или TLS SNI не обязательно показывать пользователю. Например, в поле ввода URL может указываться имя www.example.gns.alt, даже когда в поле заголовка Host используется иное уникальное имя.

A.4. Пути перехода

Распознавание DNS встроено во многие имеющиеся программные компоненты – чаще всего в операционные системы и клиенты HTTP. Здесь рассмотрены возможные пути перехода к распознаванию имён GNS для тех и других.

Одним из способов эффективного распознавания имён GNS является реализация серверов DNS с поддержкой GNS. Для локальных запросов DNS применяется перенаправление или явная настройка на распознавание таким локальным сервером (DNS-to-GNS). Этот сервер DNS пытается интерпретировать все входящие запросы для имён как запросы распознавания GNS. Если для имени не найдено Start Zone и имя не завершается zTLD, сервер пытается распознать это имя в DNS. В иных случаях имя распознаётся в GNS, полученный набор записей преобразуется в пакет отклика DNS, который возвращается запрашивающему. Реализация сервера DNS-to-GNS представлена в [GNUnet]. Похожий подход обеспечивается использованием расширений операционной системы, таких как NSS [nsswitch], позволяющих администратору системы настроить подключаемые модули (plugin) для распознавания имён. Модуль GNS nsswitch можно применять аналогично использованию сервера DNS-to-GNS. Совместимая с glibc реализация модуля nsswitch для GNS представлена в [GNUnet].

Эти методы обычно подходят и для клиентов HTTP, однако эти клиенты обычно применяются в сочетании с TLS. Для проверки сертификатов TLS (в частности, SNI) нужна дополнительная логика в клиентах HTTP при работе с именами GNS (Приложение A.3). Такую функциональность в целях перехода можно обеспечить с помощью локального прокси SOCKS5 [RFC1928] с поддержкой GNS для распознавания доменных имён. Прокси SOCKS5, как и сервер DNS-to-GNS, может распознавать имена GNS и DNS. При запросе соединения TLS по имени GNS прокси SOCKS5 может прервать завершить соединение TLS и сам организовать защищённое соединение с нужным хостом, используя для этого записи LEHO и TLSA из набора записей для имени GNS. Прокси должен предоставить клиенту HTTP локально доверенный сертификат для имени GNS, для чего обычно нужно создать и настроить локальную привязку доверия в браузере. Реализация SOCKS5-прокси представлена в [GNUnet].

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

B.1. Пример распознавания AAAA

  1.                               Локальный хост          |   Удалённое 
                                                          |   хранилище
                                                          |    +---------+
                                                          |   /         /|
                                                          |  +---------+ |
    +-----------+ (1)      +--------------+               |  |         | |
    |           |          |              |      (4,6)    |  |Хранилище| |
    |Приложение |----------|Распознаватель|---------------|->| записей | |
    |           |<---------|              |<--------------|--|         |/
    +-----------+ (8)      +--------------+      (5,7)    |  +---------+
                              A                           |
                              |                           |
                        (2,3) |                           |
                              |                           |
                           +---------+                    |
                          /   v     /|                    |
                         +---------+ |                    |
                         |         | |                    |
                         |Стартовые| |                    |
                         |  зоны   | |                    |
                         |         |/                     |
                         +---------+                      |

    Рисунок . Пример распознавания адреса IPv6.


    Поиск записи AAAA для имени www.example.gnu.gns.alt.

  2. Определение Start Zone для www.example.gnu.gns.alt.

  3. Start Zone: zkey0, остаток: www.example.

  4. Расчёт q0=SHA512(ZKDF(zkey0, “example”)) и инициирование GET(q0).

  5. Извлечение и расшифровка RRBLOCK, состоящего из одной записи PKEY с zkey1.

  6. Расчёт q1=SHA512(ZKDF(zkey1, “www”)) и инициирование GET(q1).

  7. Извлечение RRBLOCK с одной записью AAAA содержащей адрес IPv6 2001:db8::1.

  8. Возврат набора записей приложению.

B.2. Пример распознавания с REDIRECT

  1.                               Локальный хост          |   Удалённое 
                                                          |   хранилище
                                                          |    +---------+
                                                          |   /         /|
                                                          |  +---------+ |
    +-----------+ (1)      +--------------+               |  |         | |
    |           |          |              |    (4,6,8)    |  |Хранилище| |
    |Приложение |----------|Распознаватель|---------------|->| записей | |
    |           |<---------|              |<--------------|--|         |/
    +-----------+ (10)     +--------------+    (5,7,9)    |  +---------+
                              A                           |
                              |                           |
                        (2,3) |                           |
                              |                           |
                           +---------+                    |
                          /   v     /|                    |
                         +---------+ |                    |
                         |         | |                    |
                         |Стартовые| |                    |
                         |  зоны   | |                    |
                         |         |/                     |
                         +---------+                      |

    Рисунок . Пример распознавания адреса IPv6 с Redirect.


    Поиск записи AAAA для имени www.example.tld.gns.alt.

  2. Определение Start Zone для www.example.tld.gns.alt.

  3. Start Zone: zkey0, остаток: www.example.

  4. Расчёт q0=SHA512(ZKDF(zkey0, “example”)) и инициирование GET(q0).

  5. Извлечение и расшифровка RRBLOCK, состоящего из одной записи PKEY с zkey1.

  6. Расчёт q1=SHA512(ZKDF(zkey1, “www”)) и инициирование GET(q1).

  7. Извлечение и расшифровка RRBLOCK, состоящего из одной записи REDIRECT с www2.+.

  8. Расчет q2=SHA512(ZKDF(zkey1, “www2”)) и инициирование GET(q2).

  9. Извлечение и расшифровка RRBLOCK, состоящего из одной записи AAAA с адресом IPv6 2001:db8::1.

  10. Возврат набора записей приложению.

B.3. Пример распознавания GNS2DNS

  1.                               Локальный хост          |   Удалённое 
                                                          |   хранилище
                                                          |    +---------+
                                                          |   /         /|
                                                          |  +---------+ |
    +-----------+ (1)      +--------------+               |  |         | |
    |           |          |              |      (4)      |  |Хранилище| |
    |Приложение |----------|Распознаватель|---------------|->| записей | |
    |           |<---------|              |<--------------|--|         |/
    +-----------+ (8)      +--------------+      (5)      |  +---------+
                               A    A                     |
                               |    |    (6,7)            |
                         (2,3) |    +----------+          |
                               |               |          |
                               |               v          |
                            +---------+    +------------+ |
                           /   v     /|    |Системный   | |
                          +---------+ |    |распозн. DNS| |
                          |         | |    +------------+ |
                          |Стартовые| |                   |
                          |  зоны   | |                   |
                          |         |/                    |
                          +---------+                     |

    Рисунок . Пример распознавания адреса IPv6 с DNS Handover.


    Поиск записи AAAA для имени www.example.gnu.gns.alt.

  2. Определение Start Zone для www.example.gnu.gns.alt.

  3. Start Zone: zkey0, остаток: www.example.

  4. Расчёт q0=SHA512(ZKDF(zkey0, “example”)) и инициирование GET(q0).

  5. Извлечение и расшифровка RRBLOCK, состоящего из одной записи GNS2DNS с именем example.com и адресом IPv4 сервера DNS 192.0.2.1.

  6. Использование системного распознавателя для поиска записи AAAA по DNS-имени www.example.com.

  7. Получение отклика DNS с одной записью AAAA содержащей адрес IPv6 2001:db8::1.

  8. Возврат набора записей приложению.

Приложение C. Base32GNS

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

В таблице 4 показаны символы кодирования и декодирования для каждого значения. Каждый символ кодируется 5 битами. Например, символ A или a декодируется в 5-битовое значение, а 5-блок со значением 18 кодируется символом J. Если размер строки байтов для кодирования не кратен 5 битам, строка дополняется нулями. Для повышения отказоустойчивости при распознавании символов буква U должна декодироваться в то же значение, что и буква V.

Таблица . Алфавит Base32GNS с дополнительным символом кодирования U.

 

Значение символа

Символ декодирования

Символ кодирования

0

0 O o

0

1

1 I i L l

1

2

2

2

3

3

3

4

4

4

5

5

5

6

6

6

7

7

7

8

8

8

9

9

9

10

A a

A

11

B b

B

12

C c

C

13

D d

D

14

E e

E

15

F f

F

16

G g

G

17

H h

H

18

J j

J

19

K k

K

20

M m

M

21

N n

N

22

P p

P

23

Q q

Q

24

R r

R

25

S s

S

26

T t

T

27

V v U u

V

28

W w

W

29

X x

X

30

Y y

Y

31

Z z

Z

 

Приложение D. Тестовые векторы

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

D.1. Кодирование и декодирование Base32GNS

Ниже приведены тестовые векторы для кодирования Base32GNS, применяемого с zTLD (входные строки не содержат null-символ).

   Base32GNS-Encode:
     Входная строка: Hello World
     Выходная строка: 91JPRV3F41BPYWKCCG

     Входные байты: 474e55204e616d652053797374656d
     Выходная строка: 8X75A82EC5PPA82KF5SQ8SBD

   Base32GNS-Decode:
     Входная строка: 91JPRV3F41BPYWKCCG
     Выходная строка: Hello World

     Входная строка: 91JPRU3F41BPYWKCCG
     Выходная строка: Hello World

D.2. Наборы записей

Тестовые векторы включают наборы записей разных типов с флагами для зон PKEY и EDKEY. Включены метки с символами UTF-8 для демонстрации меток на других языках.

(1) Зона PKEY с меткой ASCII и записью делегирования.

   Секретный ключ зоны (d, big-endian):
     50 d7 b6 52 a4 ef ea df
     f3 73 96 90 97 85 e5 95
     21 71 a0 21 78 c8 e7 d4
     50 fa 90 79 25 fa fd 98

   Идентификатор зоны (ztype|zkey):
     00 01 00 00 67 7c 47 7d
     2d 93 09 7c 85 b1 95 c6
     f9 6d 84 ff 61 f5 98 2c
     2c 4f e0 2d 5a 11 fe df
     b0 c2 90 1f

   zTLD:
   000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W

   Метка:
     74 65 73 74 64 65 6c 65
     67 61 74 69 6f 6e

   Число записей (integer): 1

   Запись 0 := (
     EXPIRATION: 8143584694000000 us
     00 1c ee 8c 10 e2 59 80

     DATA_SIZE:
     00 20

     TYPE:
     00 01 00 00

     FLAGS:   00 01

     DATA:
     21 e3 b3 0f f9 3b c6 d3
     5a c8 c6 e0 e1 3a fd ff
     79 4c b7 b4 4b bb c7 48
     d2 59 d0 a0 28 4d be 84
   )

   RDATA:
     00 1c ee 8c 10 e2 59 80
     00 20 00 01 00 01 00 00
     21 e3 b3 0f f9 3b c6 d3
     5a c8 c6 e0 e1 3a fd ff
     79 4c b7 b4 4b bb c7 48
     d2 59 d0 a0 28 4d be 84

   Шифрование NONCE|EXPIRATION|BLOCK COUNTER:
     e9 0a 00 61 00 1c ee 8c
     10 e2 59 80 00 00 00 01

   Ключ шифрования (K):
     86 4e 71 38 ea e7 fd 91
     a3 01 36 89 9c 13 2b 23
     ac eb db 2c ef 43 cb 19
     f6 bf 55 b6 7d b9 b3 b3

   Ключ хранилища (q):
     4a dc 67 c5 ec ee 9f 76
     98 6a bd 71 c2 22 4a 3d
     ce 2e 91 70 26 c9 a0 9d
     fd 44 ce f3 d2 0f 55 a2
     73 32 72 5a 6c 8a fb bb
     b0 f7 ec 9a f1 cc 42 64
     12 99 40 6b 04 fd 9b 5b
     57 91 f8 6c 4b 08 d5 f4

   ZKDF(zkey, label):
     18 2b b6 36 ed a7 9f 79
     57 11 bc 27 08 ad bb 24
     2a 60 44 6a d3 c3 08 03
     12 1d 03 d3 48 b7 ce b6

   Производный секретный ключ (d', big-endian):
     0a 4c 5e 0f 00 63 df ce
     db c8 c7 f2 b2 2c 03 0c
     86 28 b2 c2 cb ac 9f a7
     29 aa e6 1f 89 db 3e 9c

   BDATA:
     0c 1e da 5c c0 94 a1 c7
     a8 88 64 9d 25 fa ee bd
     60 da e6 07 3d 57 d8 ae
     8d 45 5f 4f 13 92 c0 74
     e2 6a c6 69 bd ee c2 34
     62 b9 62 95 2c c6 e9 eb

   RRBLOCK:
     00 00 00 a0 00 01 00 00
     18 2b b6 36 ed a7 9f 79
     57 11 bc 27 08 ad bb 24
     2a 60 44 6a d3 c3 08 03
     12 1d 03 d3 48 b7 ce b6
     0a d1 0b c1 3b 40 3b 5b
     25 61 26 b2 14 5a 6f 60
     c5 14 f9 51 ff a7 66 f7
     a3 fd 4b ac 4a 4e 19 90
     05 5c b8 7e 8d 1b fd 19
     aa 09 a4 29 f7 29 e9 f5
     c6 ee c2 47 0a ce e2 22
     07 59 e9 e3 6c 88 6f 35
     00 1c ee 8c 10 e2 59 80
     0c 1e da 5c c0 94 a1 c7
     a8 88 64 9d 25 fa ee bd
     60 da e6 07 3d 57 d8 ae
     8d 45 5f 4f 13 92 c0 74
     e2 6a c6 69 bd ee c2 34
     62 b9 62 95 2c c6 e9 eb

(2) Зона PKEY с меткой UTF-8 и тремя записями.

   Секретный ключ зоны (d, big-endian):
     50 d7 b6 52 a4 ef ea df
     f3 73 96 90 97 85 e5 95
     21 71 a0 21 78 c8 e7 d4
     50 fa 90 79 25 fa fd 98

   Идентификатор зоны (ztype|zkey):
     00 01 00 00 67 7c 47 7d
     2d 93 09 7c 85 b1 95 c6
     f9 6d 84 ff 61 f5 98 2c
     2c 4f e0 2d 5a 11 fe df
     b0 c2 90 1f

   zTLD:
   000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W

   Метка:
     e5 a4 a9 e4 b8 8b e7 84
     a1 e6 95 b5

   Число записей (integer): 3

   Запись 0 := (
     EXPIRATION: 8143584694000000 us
     00 1c ee 8c 10 e2 59 80

     DATA_SIZE:
     00 10

     TYPE:
     00 00 00 1c

     FLAGS:   00 00

     DATA:
     00 00 00 00 00 00 00 00
     00 00 00 00 de ad be ef
   )

   Запись 1 := (
     EXPIRATION: 17999736901000000 us
     00 3f f2 aa 54 08 db 40

     DATA_SIZE:
     00 06

     TYPE:
     00 01 00 01

     FLAGS:   00 00

     DATA:
     e6 84 9b e7 a7 b0
   )

   Запись 2 := (
     EXPIRATION: 11464693629000000 us
     00 28 bb 13 ff 37 19 40

     DATA_SIZE:
     00 0b

     TYPE:
     00 00 00 10

     FLAGS:   00 04

     DATA:
     48 65 6c 6c 6f 20 57 6f
     72 6c 64
   )

   RDATA:
     00 1c ee 8c 10 e2 59 80
     00 10 00 00 00 00 00 1c
     00 00 00 00 00 00 00 00
     00 00 00 00 de ad be ef
     00 3f f2 aa 54 08 db 40
     00 06 00 00 00 01 00 01
     e6 84 9b e7 a7 b0 00 28
     bb 13 ff 37 19 40 00 0b
     00 04 00 00 00 10 48 65
     6c 6c 6f 20 57 6f 72 6c
     64 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00

   Шифрование NONCE|EXPIRATION|BLOCK COUNTER:
     ee 96 33 c1 00 1c ee 8c
     10 e2 59 80 00 00 00 01

   Ключ шифрования (K):
     fb 3a b5 de 23 bd da e1
     99 7a af 7b 92 c2 d2 71
     51 40 8b 77 af 7a 41 ac
     79 05 7c 4d f5 38 3d 01

   Ключ хранилища (q):
     af f0 ad 6a 44 09 73 68
     42 9a c4 76 df a1 f3 4b
     ee 4c 36 e7 47 6d 07 aa
     64 63 ff 20 91 5b 10 05
     c0 99 1d ef 91 fc 3e 10
     90 9f 87 02 c0 be 40 43
     67 78 c7 11 f2 ca 47 d5
     5c f0 b5 4d 23 5d a9 77

   ZKDF(zkey, label):
     a5 12 96 df 75 7e e2 75
     ca 11 8d 4f 07 fa 7a ae
     55 08 bc f5 12 aa 41 12
     14 29 d4 a0 de 9d 05 7e

   Производный секретный ключ (d', big-endian):
     0a be 56 d6 80 68 ab 40
     e1 44 79 0c de 9a cf 4d
     78 7f 2d 3c 63 b8 53 05
     74 6e 68 03 32 15 f2 ab

   BDATA:
     d8 c2 8d 2f d6 96 7d 1a
     b7 22 53 f2 10 98 b8 14
     a4 10 be 1f 59 98 de 03
     f5 8f 7e 7c db 7f 08 a6
     16 51 be 4d 0b 6f 8a 61
     df 15 30 44 0b d7 47 dc
     f0 d7 10 4f 6b 8d 24 c2
     ac 9b c1 3d 9c 6f e8 29
     05 25 d2 a6 d0 f8 84 42
     67 a1 57 0e 8e 29 4d c9
     3a 31 9f cf c0 3e a2 70
     17 d6 fd a3 47 b4 a7 94
     97 d7 f6 b1 42 2d 4e dd
     82 1c 19 93 4e 96 c1 aa
     87 76 57 25 d4 94 c7 64
     b1 55 dc 6d 13 26 91 74

   RRBLOCK:
     00 00 00 f0 00 01 00 00
     a5 12 96 df 75 7e e2 75
     ca 11 8d 4f 07 fa 7a ae
     55 08 bc f5 12 aa 41 12
     14 29 d4 a0 de 9d 05 7e
     08 5b d6 5f d4 85 10 51
     ba ce 2a 45 2a fc 8a 7e
     4f 6b 2c 1f 74 f0 20 35
     d9 64 1a cd ba a4 66 e0
     00 ce d6 f2 d2 3b 63 1c
     8e 8a 0b 38 e2 ba e7 9a
     22 ca d8 1d 4c 50 d2 25
     35 8e bc 17 ac 0f 89 9e
     00 1c ee 8c 10 e2 59 80
     d8 c2 8d 2f d6 96 7d 1a
     b7 22 53 f2 10 98 b8 14
     a4 10 be 1f 59 98 de 03
     f5 8f 7e 7c db 7f 08 a6
     16 51 be 4d 0b 6f 8a 61
     df 15 30 44 0b d7 47 dc
     f0 d7 10 4f 6b 8d 24 c2
     ac 9b c1 3d 9c 6f e8 29
     05 25 d2 a6 d0 f8 84 42
     67 a1 57 0e 8e 29 4d c9
     3a 31 9f cf c0 3e a2 70
     17 d6 fd a3 47 b4 a7 94
     97 d7 f6 b1 42 2d 4e dd
     82 1c 19 93 4e 96 c1 aa
     87 76 57 25 d4 94 c7 64
     b1 55 dc 6d 13 26 91 74

(3) Зона EDKEY с меткой ASCII и записью делегирования.

   Секретный ключ зоны (d):
     5a f7 02 0e e1 91 60 32
     88 32 35 2b bc 6a 68 a8
     d7 1a 7c be 1b 92 99 69
     a7 c6 6d 41 5a 0d 8f 65

   Идентификатор зоны (ztype|zkey):
     00 01 00 14 3c f4 b9 24
     03 20 22 f0 dc 50 58 14
     53 b8 5d 93 b0 47 b6 3d
     44 6c 58 45 cb 48 44 5d
     db 96 68 8f

   zTLD:
   000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW

   Метка:
     74 65 73 74 64 65 6c 65
     67 61 74 69 6f 6e

   Число записей (integer): 1

   Запись 0 := (
     EXPIRATION: 8143584694000000 us
     00 1c ee 8c 10 e2 59 80

     DATA_SIZE:
     00 20

     TYPE:
     00 01 00 00

     FLAGS:   00 01

     DATA:
     21 e3 b3 0f f9 3b c6 d3
     5a c8 c6 e0 e1 3a fd ff
     79 4c b7 b4 4b bb c7 48
     d2 59 d0 a0 28 4d be 84
   )

   RDATA:
     00 1c ee 8c 10 e2 59 80
     00 20 00 01 00 01 00 00
     21 e3 b3 0f f9 3b c6 d3
     5a c8 c6 e0 e1 3a fd ff
     79 4c b7 b4 4b bb c7 48
     d2 59 d0 a0 28 4d be 84

   Шифрование NONCE|EXPIRATION:
     98 13 2e a8 68 59 d3 5c
     88 bf d3 17 fa 99 1b cb
     00 1c ee 8c 10 e2 59 80

   Ключ шифрования (K):
     85 c4 29 a9 56 7a a6 33
     41 1a 96 91 e9 09 4c 45
     28 16 72 be 58 60 34 aa
     e4 a2 a2 cc 71 61 59 e2

   Ключ хранилища (q):
     ab aa ba c0 e1 24 94 59
     75 98 83 95 aa c0 24 1e
     55 59 c4 1c 40 74 e2 55
     7b 9f e6 d1 54 b6 14 fb
     cd d4 7f c7 f5 1d 78 6d
     c2 e0 b1 ec e7 60 37 c0
     a1 57 8c 38 4e c6 1d 44
     56 36 a9 4e 88 03 29 e9

   ZKDF(zkey, label):
     9b f2 33 19 8c 6d 53 bb
     db ac 49 5c ab d9 10 49
     a6 84 af 3f 40 51 ba ca
     b0 dc f2 1c 8c f2 7a 1a

   nonce := SHA-256(dh[32..63] || h):
     14 f2 c0 6b ed c3 aa 2d
     f0 71 13 9c 50 39 34 f3
     4b fa 63 11 a8 52 f2 11
     f7 3a df 2e 07 61 ec 35

   Производный секретный ключ (d', big-endian):
     3b 1b 29 d4 23 0b 10 a8
     ec 4d a3 c8 6e db 88 ea
     cd 54 08 5c 1d db 63 f7
     a9 d7 3f 7c cb 2f c3 98

   BDATA:
     57 7c c6 c9 5a 14 e7 04
     09 f2 0b 01 67 e6 36 d0
     10 80 7c 4f 00 37 2d 69
     8c 82 6b d9 2b c2 2b d6
     bb 45 e5 27 7c 01 88 1d
     6a 43 60 68 e4 dd f1 c6
     b7 d1 41 6f af a6 69 7c
     25 ed d9 ea e9 91 67 c3

   RRBLOCK:
     00 00 00 b0 00 01 00 14
     9b f2 33 19 8c 6d 53 bb
     db ac 49 5c ab d9 10 49
     a6 84 af 3f 40 51 ba ca
     b0 dc f2 1c 8c f2 7a 1a
     9f 56 a8 86 ea 73 9d 59
     17 50 8f 9b 75 56 39 f3
     a9 ac fa ed ed ca 7f bf
     a7 94 b1 92 e0 8b f9 ed
     4c 7e c8 59 4c 9f 7b 4e
     19 77 4f f8 38 ec 38 7a
     8f 34 23 da ac 44 9f 59
     db 4e 83 94 3f 90 72 00
     00 1c ee 8c 10 e2 59 80
     57 7c c6 c9 5a 14 e7 04
     09 f2 0b 01 67 e6 36 d0
     10 80 7c 4f 00 37 2d 69
     8c 82 6b d9 2b c2 2b d6
     bb 45 e5 27 7c 01 88 1d
     6a 43 60 68 e4 dd f1 c6
     b7 d1 41 6f af a6 69 7c
     25 ed d9 ea e9 91 67 c3

(4) Зона EDKEY с меткой UTF-8 и тремя записями.

   Секретный ключ зоны (d):
     5a f7 02 0e e1 91 60 32
     88 32 35 2b bc 6a 68 a8
     d7 1a 7c be 1b 92 99 69
     a7 c6 6d 41 5a 0d 8f 65

   Идентификатор зоны (ztype|zkey):
     00 01 00 14 3c f4 b9 24
     03 20 22 f0 dc 50 58 14
     53 b8 5d 93 b0 47 b6 3d
     44 6c 58 45 cb 48 44 5d
     db 96 68 8f

   zTLD:
   000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW

   Метка:
     e5 a4 a9 e4 b8 8b e7 84
     a1 e6 95 b5

   Число записей (integer): 3

   Запись 0 := (
     EXPIRATION: 8143584694000000 us
     00 1c ee 8c 10 e2 59 80

     DATA_SIZE:
     00 10

     TYPE:
     00 00 00 1c

     FLAGS:   00 00

     DATA:
     00 00 00 00 00 00 00 00
     00 00 00 00 de ad be ef
   )

   Запись 1 := (
     EXPIRATION: 17999736901000000 us
     00 3f f2 aa 54 08 db 40

     DATA_SIZE:
     00 06

     TYPE:
     00 01 00 01

     FLAGS:   00 00

     DATA:
     e6 84 9b e7 a7 b0
   )

   Запись 2 := (
     EXPIRATION: 11464693629000000 us
     00 28 bb 13 ff 37 19 40

     DATA_SIZE:
     00 0b

     TYPE:
     00 00 00 10

     FLAGS:   00 04

     DATA:
     48 65 6c 6c 6f 20 57 6f
     72 6c 64
   )

   RDATA:
     00 1c ee 8c 10 e2 59 80
     00 10 00 00 00 00 00 1c
     00 00 00 00 00 00 00 00
     00 00 00 00 de ad be ef
     00 3f f2 aa 54 08 db 40
     00 06 00 00 00 01 00 01
     e6 84 9b e7 a7 b0 00 28
     bb 13 ff 37 19 40 00 0b
     00 04 00 00 00 10 48 65
     6c 6c 6f 20 57 6f 72 6c
     64 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00

   Шифрование NONCE|EXPIRATION:
     bb 0d 3f 0f bd 22 42 77
     50 da 5d 69 12 16 e6 c9
     00 1c ee 8c 10 e2 59 80

   Ключ шифрования (K):
     3d f8 05 bd 66 87 aa 14
     20 96 28 c2 44 b1 11 91
     88 c3 92 56 37 a4 1e 5d
     76 49 6c 29 45 dc 37 7b

   Ключ хранилища (q):
     ba f8 21 77 ee c0 81 e0
     74 a7 da 47 ff c6 48 77
     58 fb 0d f0 1a 6c 7f bb
     52 fc 8a 31 be f0 29 af
     74 aa 0d c1 5a b8 e2 fa
     7a 54 b4 f5 f6 37 f6 15
     8f a7 f0 3c 3f ce be 78
     d3 f9 d6 40 aa c0 d1 ed

   ZKDF(zkey, label):
     74 f9 00 68 f1 67 69 53
     52 a8 a6 c2 eb 98 48 98
     c5 3a cc a0 98 04 70 c6
     c8 12 64 cb dd 78 ad 11

   nonce := SHA-256(dh[32..63] || h):
     f8 6a b5 33 8a 74 d7 a1
     d2 77 ea 11 ff 95 cb e8
     3a cf d3 97 3b b4 ab ca
     0a 1b 60 62 c3 7a b3 9c

   Производный секретный ключ (d', big-endian):
     17 c0 68 a6 c3 f7 20 de
     0e 1b 69 ff 3f 53 e0 5d
     3f e5 c5 b0 51 25 7a 89
     a6 3c 1a d3 5a c4 35 58

   BDATA:
     4e b3 5a 50 d4 0f e1 a4
     29 c7 f4 b2 67 a0 59 de
     4e 2c 8a 89 a5 ed 53 d3
     d4 92 58 59 d2 94 9f 7f
     30 d8 a2 0c aa 96 f8 81
     45 05 2d 1c da 04 12 49
     8f f2 5f f2 81 6e f0 ce
     61 fe 69 9b fa c7 2c 15
     dc 83 0e a9 b0 36 17 1c
     cf ca bb dd a8 de 3c 86
     ed e2 95 70 d0 17 4b 82
     82 09 48 a9 28 b7 f0 0e
     fb 40 1c 10 fe 80 bb bb
     02 76 33 1b f7 f5 1b 8d
     74 57 9c 14 14 f2 2d 50
     1a d2 5a e2 49 f5 bb f2
     a6 c3 72 59 d1 75 e4 40
     b2 94 39 c6 05 19 cb b1

   RRBLOCK:
     00 00 01 00 00 01 00 14
     74 f9 00 68 f1 67 69 53
     52 a8 a6 c2 eb 98 48 98
     c5 3a cc a0 98 04 70 c6
     c8 12 64 cb dd 78 ad 11
     75 6d 2c 15 7a d2 ea 4f
     c0 b1 b9 1c 08 03 79 44
     61 d3 de f2 0d d1 63 6c
     fe dc 03 89 c5 49 d1 43
     6c c3 5b 4e 1b f8 89 5a
     64 6b d9 a6 f4 6b 83 48
     1d 9c 0e 91 d4 e1 be bb
     6a 83 52 6f b7 25 2a 06
     00 1c ee 8c 10 e2 59 80
     4e b3 5a 50 d4 0f e1 a4
     29 c7 f4 b2 67 a0 59 de
     4e 2c 8a 89 a5 ed 53 d3
     d4 92 58 59 d2 94 9f 7f
     30 d8 a2 0c aa 96 f8 81
     45 05 2d 1c da 04 12 49
     8f f2 5f f2 81 6e f0 ce
     61 fe 69 9b fa c7 2c 15
     dc 83 0e a9 b0 36 17 1c
     cf ca bb dd a8 de 3c 86
     ed e2 95 70 d0 17 4b 82
     82 09 48 a9 28 b7 f0 0e
     fb 40 1c 10 fe 80 bb bb
     02 76 33 1b f7 f5 1b 8d
     74 57 9c 14 14 f2 2d 50
     1a d2 5a e2 49 f5 bb f2
     a6 c3 72 59 d1 75 e4 40
     b2 94 39 c6 05 19 cb b1

D.3. Отзыв зоны

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

   Секретный ключ зоны (d, big-endian):
     6f ea 32 c0 5a f5 8b fa
     97 95 53 d1 88 60 5f d5
     7d 8b f9 cc 26 3b 78 d5
     f7 47 8c 07 b9 98 ed 70

   Идентификатор зоны (ztype|zkey):
     00 01 00 00 2c a2 23 e8
     79 ec c4 bb de b5 da 17
     31 92 81 d6 3b 2e 3b 69
     55 f1 c3 77 5c 80 4a 98
     d5 f8 dd aa

   zTLD:
   000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8

   Сложность (базовая 5, эпохи 2): 7

   Подписанное сообщение:
     00 00 00 34 00 00 00 03
     00 05 ff 1c 56 e4 b2 68
     00 01 00 00 2c a2 23 e8
     79 ec c4 bb de b5 da 17
     31 92 81 d6 3b 2e 3b 69
     55 f1 c3 77 5c 80 4a 98
     d5 f8 dd aa

   Доказательство:
     00 05 ff 1c 56 e4 b2 68
     00 00 39 5d 18 27 c0 00
     38 0b 54 aa 70 16 ac a2
     38 0b 54 aa 70 16 ad 62
     38 0b 54 aa 70 16 af 3e
     38 0b 54 aa 70 16 af 93
     38 0b 54 aa 70 16 b0 bf
     38 0b 54 aa 70 16 b0 ee
     38 0b 54 aa 70 16 b1 c9
     38 0b 54 aa 70 16 b1 e5
     38 0b 54 aa 70 16 b2 78
     38 0b 54 aa 70 16 b2 b2
     38 0b 54 aa 70 16 b2 d6
     38 0b 54 aa 70 16 b2 e4
     38 0b 54 aa 70 16 b3 2c
     38 0b 54 aa 70 16 b3 5a
     38 0b 54 aa 70 16 b3 9d
     38 0b 54 aa 70 16 b3 c0
     38 0b 54 aa 70 16 b3 dd
     38 0b 54 aa 70 16 b3 f4
     38 0b 54 aa 70 16 b4 42
     38 0b 54 aa 70 16 b4 76
     38 0b 54 aa 70 16 b4 8c
     38 0b 54 aa 70 16 b4 a4
     38 0b 54 aa 70 16 b4 c9
     38 0b 54 aa 70 16 b4 f0
     38 0b 54 aa 70 16 b4 f7
     38 0b 54 aa 70 16 b5 79
     38 0b 54 aa 70 16 b6 34
     38 0b 54 aa 70 16 b6 8e
     38 0b 54 aa 70 16 b7 b4
     38 0b 54 aa 70 16 b8 7e
     38 0b 54 aa 70 16 b8 f8
     38 0b 54 aa 70 16 b9 2a
     00 01 00 00 2c a2 23 e8
     79 ec c4 bb de b5 da 17
     31 92 81 d6 3b 2e 3b 69
     55 f1 c3 77 5c 80 4a 98
     d5 f8 dd aa 08 ca ff de
     3c 6d f1 45 f7 e0 79 81
     15 37 b2 b0 42 2d 5e 1f
     b2 01 97 81 ec a2 61 d1
     f9 d8 ea 81 0a bc 2f 33
     47 7f 04 e3 64 81 11 be
     71 c2 48 82 1a d6 04 f4
     94 e7 4d 0b f5 11 d2 c1
     62 77 2e 81

Ниже приведён пример отзыва для зоны EDKEY

   Секретный ключ зоны (d):
     5a f7 02 0e e1 91 60 32
     88 32 35 2b bc 6a 68 a8
     d7 1a 7c be 1b 92 99 69
     a7 c6 6d 41 5a 0d 8f 65

   Идентификатор зоны (ztype|zkey):
     00 01 00 14 3c f4 b9 24
     03 20 22 f0 dc 50 58 14
     53 b8 5d 93 b0 47 b6 3d
     44 6c 58 45 cb 48 44 5d
     db 96 68 8f

   zTLD:
   000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW

   Сложность (базовая 5, эпохи 2): 7

   Подписанное сообщение:
     00 00 00 34 00 00 00 03
     00 05 ff 1c 57 35 42 bd
     00 01 00 14 3c f4 b9 24
     03 20 22 f0 dc 50 58 14
     53 b8 5d 93 b0 47 b6 3d
     44 6c 58 45 cb 48 44 5d
     db 96 68 8f

   Доказательство:
     00 05 ff 1c 57 35 42 bd
     00 00 39 5d 18 27 c0 00
     58 4c 93 3c b0 99 2a 08
     58 4c 93 3c b0 99 2d f7
     58 4c 93 3c b0 99 2e 21
     58 4c 93 3c b0 99 2e 2a
     58 4c 93 3c b0 99 2e 53
     58 4c 93 3c b0 99 2e 8e
     58 4c 93 3c b0 99 2f 13
     58 4c 93 3c b0 99 2f 2d
     58 4c 93 3c b0 99 2f 3c
     58 4c 93 3c b0 99 2f 41
     58 4c 93 3c b0 99 2f fd
     58 4c 93 3c b0 99 30 33
     58 4c 93 3c b0 99 30 82
     58 4c 93 3c b0 99 30 a2
     58 4c 93 3c b0 99 30 e1
     58 4c 93 3c b0 99 31 ce
     58 4c 93 3c b0 99 31 de
     58 4c 93 3c b0 99 32 12
     58 4c 93 3c b0 99 32 4e
     58 4c 93 3c b0 99 32 9f
     58 4c 93 3c b0 99 33 31
     58 4c 93 3c b0 99 33 87
     58 4c 93 3c b0 99 33 8c
     58 4c 93 3c b0 99 33 e5
     58 4c 93 3c b0 99 33 f3
     58 4c 93 3c b0 99 34 26
     58 4c 93 3c b0 99 34 30
     58 4c 93 3c b0 99 34 68
     58 4c 93 3c b0 99 34 88
     58 4c 93 3c b0 99 34 8a
     58 4c 93 3c b0 99 35 4c
     58 4c 93 3c b0 99 35 bd
     00 01 00 14 3c f4 b9 24
     03 20 22 f0 dc 50 58 14
     53 b8 5d 93 b0 47 b6 3d
     44 6c 58 45 cb 48 44 5d
     db 96 68 8f 04 ae 26 f7
     63 56 5a b7 aa ab 01 71
     72 4f 3c a8 bc c5 1a 98
     b7 d4 c9 2e a3 3c d9 34
     4c a8 b6 3e 04 53 3a bf
     1a 3c 05 49 16 b3 68 2c
     5c a8 cb 4d d0 f8 4c 3b
     77 48 7a ac 6e ce 38 48
     0b a9 d5 00

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

Авторы благодарят всех рецензентов за комментарии. Спасибо D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear, and R. Salz за их глубокие и подробные технические обзоры. Спасибо J. Yao и J. Klensin за анализ применимости для других языков. Спасибо Dr. J. Appelbaum за предложение имени GNU Name System и Dr. Richard Stallman за одобрение его использования. Спасибо T. Lange и M. Wachs за ранний вклад в разработку и реализацию GNS. Спасибо NLnet и NGI DISCOVERY за финансирование работы над GNU Name System.

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

Martin Schanzenbach
Fraunhofer AISEC
Lichtenbergstrasse 11
85748 Garching
Germany
Email: martin.schanzenbach@aisec.fraunhofer.de
 
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
Email: christian.grothoff@bfh.ch
 
Bernd Fix
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany
Email: fix@gnunet.org

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

nmalykh@protokols.ru


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