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 | Оставить комментарий

RFC 9511 Attribution of Internet Probes

Internet Engineering Task Force (IETF)                         É. Vyncke
Request for Comments: 9511                                         Cisco
Category: Informational                                        B. Donnet
ISSN: 2070-1721                                                J. Iurman
                                                     Université de Liège
                                                           November 2023

Attribution of Internet Probes

Установление авторства пробных пакетов Internet

PDF

Аннотация

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

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

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

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

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

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

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

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

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. Введение

Большинство измерительных исследований (например, [LARGE_SCALE], [RFC7872], [JAMES]) включает отправку через общедоступную сеть Internet пакетов IP (иногда с заголовками расширения или L4), которые могут адресоваться как к сотрудничающим, так и не сотрудничающим сторонам. Такие пакеты в документе называются зондами или пробами.

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

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

  • что собой представляет незапрошенных пробный пакет;

  • каково назначение зонда;

  • к кому обращаться за дополнительной информацией (это наиболее важно).

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

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

2. Описание пробных пакетов

В этом разделе описаны способы описания (идентификации) проных пакетов их источником.

2.1. URI описания

Этот документ определяет Probe Description URI как URI с одной из указанных ниже ссылок.

  • Файл описания зонда (Probe Description File, параграф 2.2), как определено в разделе 8, например, “https://example.net/.well-known/probing.txt”;

  • Адрес электронной почты, например mailto:lab@example.net;

  • Номер телефона, например, tel:+1-201-555-0123.

2.2. Файл описания зонда

Как указано в разделе 8, файл описания зонда должен быть доступен по ссылке /.well-known/probing.txt и должен иметь формат, заданный в разделе 4 [RFC9116]. В файл следует указывать поля, заданные в разделе 2 [RFC9116] и перечисленные ниже.

  • Canonical

  • Contact

  • Expires

  • Preferred-Languages

В описание измерения следует также включать поле Description. В соответствии с форматом, заданным в разделе 4 [RFC9116], это поле должно быть одной строкой без символов прерывания строки.

2.2.1. Пример

   # Канонический URI (if при наличии)
   Canonical: https://example.net/measurement.txt

   # Адрес для контактов
   Contact: mailto:lab@example.net

   # Срок действия
   Expires: 2023-12-31T18:37:07z

   # Языки
   Preferred-Languages: en, es, fr

   # Описание пробного пакета
   Description: Одна строка, описывающая пробные пакеты.

3. Автономное указание авторства

Возможность установить автора зонда основана на создании специальной ссылки URI, включающей адрес источника, как указано в [RFC8615]. Например, для зонда с адресом источника 2001:db8:dead::1 URI создаётся, как показано ниже.

  • Если имеется обратная запись DNS для 2001:db8:dead::1, например, example.net, URI описания пробы будет иметь вид https://example.net/.well-known/probing.txt. Обратной записи DNS следует быть единственной, а при наличии нескольких записей идентичные файлы описания пробы следует обеспечивать для каждой из них.

  • В ином случае (или в дополнение) URI описания имеет вид https://[2001:db8:dead::1]/.well-known/probing.txt.

Созданный идентификатор URI должен указывать файл описания пробы (см. параграф 2.2).

Национальный центр кибербезопасности Великобритании (UK National Cyber Security Centre [NCSC]) использует похожую форму указания авторства. Они сканируют на предмет уязвимостей все подключённые в Internet системы в Великобритании и публикуют сведения в [NCSC_SCAN_INFO], указывая адрес web-страницы в обратной записи DNS.

4. Указание авторства в пакетах

Другим вариантом является включение URI описания пробы в сами пробные пакеты, напримр, как указано ниже.

  • Включение в поле данных пакетов ICMPv6 echo request [RFC4443].

  • Включение в поле данных пакетов ICMPv4 echo request [RFC0792].

  • Включение в данные (payload) дейтаграмм UDP datagram [RFC0768], если после транспортного протокола нет другого протокола вышележащего уровня.

  • Включение в данные (payload) сегмента TCP [RFC9293], если после транспортного протокола нет другого протокола вышележащего уровня.

  • Включение с опцию PadN внутри заголовка Hop-by-Hop или Destination Options пакета IPv6 [RFC8200].

URI описания зонда должен начинаться с первого октета данных (payload) и навершаться октетом 0x00 (null). Если URI описания невозможно поместить в начало данных, ему должен предшествовать октет 0x00. Вставка Probe Description URI может исказить измерение, если размер пакета превысит MTU. Некоторые примеры приведены в Приложении A.

Использовать «магическую строку» (специальный уникальный маркер) для указания наличия Probe Description URI не рекомендуется, поскольку некоторые транзитные узлы могут применять для таких пакетов особую обработку.

Указание автоства в пакетах применлось в [JAMES].

5. Эксплуатационные и технические вопросы

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

Преимуществом автономного (out-of-band) метода является независимость результатов зондирования от указания автора зондов (т. е. запуска web-сервера на зондирующем устройстве). Однако в некоторых случаях применение этого метода может оказаться невозможным, например, при работе через NAT, слишком большом числе конечных точек для запуска web-серверов, неизвестности IP-адреса источника зондов (например, зонды RIPE Atlas [RIPE_ATLAS] передаются с адресов, не принадлежащих владельцу зонда), динамических адресах отправителя и т. п.

Основным достоинством метода in-band является возможность работы в тех ситуациях, когда метод out-of-band недоступен (см. выше). Основной недостаток заключается в возможности искажения измерений из-за того, что пакеты с Probe Description URI могут отбрасываться. Например, можно включать данные в сегменты TCP с флагом SYN [RFC9293], однако это может изменить способ их обработки, т. е. сегменты TCP SYN с Probe Description URI могут быть отброшены. Другим примером является включение Probe Description URI в опцию PadN заголовка Hop-by-Hop или Destination Options. В параграфе 2.1.9.5 [RFC4942] (Informational RFC) сказано, что в опцию PadN следует включать только нули и размер опции следует длать не более 8 октетов, что ограничивает её применения для атрибутирования зондов. Если опция PadN не следует этим рекомендациям, предлагается рассмотреть возможность отбрасывания пакетов. Например, ядро Linux, начиная с версии 3.5, следует этой рекомендации и отбрасывает такие пакеты.

Сочетание обоих методов может быть использовано как способ косвенной «аутентификации» Probe Description URI в пробном пакете (in-band) за счёт сопоставления с методом out-of-band (например, поиск обратной записи в DNS). Хотя сам метод out-of-band меньше подвержен подделкам, сочетание с in-band обеспечивает более полное решение.

6. Вопросы этики

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

Однако следует учитывать и другие соображения, от содержимого данных (например, корректности их кодирования) до скорости передачи (см. [IPV6_TOPOLOGY] и [IPV4_TOPOLOGY], где рассмотрено влиения скорости тестов). Эти вопросы выходят за рамки данного документа.

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

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

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

Поскольку Probe Description URI передаётся в открытом виде, а чтение файла Probe Description File доступно всем, не следует раскрывать персональные данные (Personally Identifiable Information или PII) в адресе электронной почты или телефонном номере – лучше указывать групповой или общий адрес и номер телефона. Кроме того, в файл описания зондов можно включить вредоносные данные (например, ссылку), поэтому не следует слепо доверять этим файлам.

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

Агентство IANA включило приведённый ниже суффикс URI в реестр Well-Known URIs в соответствии с [RFC8615].

   URI Suffix:  probing.txt
   Change Controller:  IETF
   Reference:  RFC 9511
   Status:  permanent

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

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

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0792] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8615] Nottingham, M., “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.

[RFC9116] Foudil, E. and Y. Shafranovich, “A File Format to Aid in Security Vulnerability Disclosure”, RFC 9116, DOI 10.17487/RFC9116, April 2022, <https://www.rfc-editor.org/info/rfc9116>.

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

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

[ANRW_PAPER] Fiebig, T., “Crisis, Ethics, Reliability & a measurement.network – Reflections on Active Network Measurements in Academia”, DOI 10.1145/3606464.3606483, July 2023, <https://pure.mpg.de/rest/items/item_3517635/component/file_3517636/content>.

[IPV4_TOPOLOGY] Beverly, R., “Yarrp’ing the Internet: Randomized High-Speed Active Topology Discovery”, DOI 10.1145/2987443.2987479, November 2016, <http://www.cmand.org/papers/yarrp-imc16.pdf>.

[IPV6_TOPOLOGY] Beverly, R., Durairajan, R., Plonka, D., and J. Rohrer, “In the IP of the Beholder: Strategies for Active IPv6 Topology Discovery”, DOI 10.1145/3278532.3278559, October 2018, <http://www.cmand.org/papers/beholder-imc18.pdf>.

[JAMES] Vyncke, É., Léas, R., and J. Iurman, “Just Another Measurement of Extension header Survivability (JAMES)”, Work in Progress, Internet-Draft, draft-vyncke-v6ops-james-03, 9 January 2023, <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-03>.

[LARGE_SCALE] Donnet, B., Raoult, P., Friedman, T., and M. Crovella, “Efficient Algorithms for Large-Scale Topology Discovery”, DOI 10.1145/1071690.1064256, DOI 10.1145/1071690.1064256, June 2005, <https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.

[NCSC] UK NCSC, “The National Cyber Security Centre”, <https://www.ncsc.gov.uk/>.

[NCSC_SCAN_INFO] UK NCSC, “NCSC Scanning information”, <https://www.ncsc.gov.uk/information/ncsc-scanning-information>.

[RFC4942] Davies, E., Krishnan, S., and P. Savola, “IPv6 Transition/Co-existence Security Considerations”, RFC 4942, DOI 10.17487/RFC4942, September 2007, <https://www.rfc-editor.org/info/rfc4942>.

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, “Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World”, RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.

[RIPE_ATLAS] RIPE Network Coordination Centre (RIPE NCC), “RIPE Atlas”, <https://atlas.ripe.net/>.

[SCAPY] “Scapy”, <https://scapy.net/>.

Приложение A. Примеры указания авторства через сеть

Ниже приведено несколько примеров, созданных с помощью генератора [SCAPY] и приведённых в формате tcpdump.

Пакет IP с Description URI внутри заголовка расширения Destination Options

   IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
   Flags [S], seq 0, win 8192, length 0

   0x0000:  6000 0000 0044 3c40 2001 0db8 dead 0000  `....D<@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 0605 012c 6874 7470  ...........,http
   0x0030:  733a 2f2f 6578 616d 706c 652e 6e65 742f  s://example.net/
   0x0040:  2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62  .well-known/prob
   0x0050:  696e 672e 7478 7400 edce 829a 0000 0000  ing.txt.........
   0x0060:  0000 0000 5002 2000 2668 0000            ....P...&h..

Пакет IP с URI в поле данных пакета TCP SYN

   IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
   Flags [S], seq 0:23, win 8192, length 23

   0x0000:  6000 0000 002b 0640 2001 0db8 dead 0000  `....+.@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 3cdd 829a 0000 0000  ........<.......
   0x0030:  0000 0000 5002 2000 c9b7 0000 6d61 696c  ....P.......mail
   0x0040:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
   0x0050:  6574 00                                  et.

Пакет IP echo request с другим URI в разделе данных ICMP ECHO_REQUEST

   IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
   seq 0, length 28

   0x0000:  6000 0000 001c 3a40 2001 0db8 dead 0000  `.....:@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 8000 2996 0000 0000  ..........).....
   0x0030:  7465 6c3a 2b31 2d32 3031 2d35 3535 2d30  tel:+1-201-555-0
   0x0040:  3132 3300                                123.

Пакет IPv4 echo request с URI в разделе данных ICMP ECHO_REQUEST

   IP 192.0.2.1 > 198.51.10.1: ICMP echo request, id 0, seq 0, length 31

   0x0000:  4500 0033 0001 0000 4001 8e93 c000 0201  E..3....@.......
   0x0010:  c633 0a01 0800 ea74 0000 0000 6d61 696c  .3d....t....mail
   0x0020:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
   0x0030:  6574 00                                  et.

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

Авторы благодарны Alain Fiocco, Fernando Gont, Ted Hardie, Mehdi Kouhen, Mark Townsley за полезные дискуссии, а также Raphael Leas – за раннюю реализацию.

Авторы также признательны за полезные рецензии и комментарии от Warren Kumari, Jen Linkova, Mark Nottingham, Prapanch Ramamoorthy, Tirumaleswar Reddy.K, Andrew Shaw, Magnus Westerlund.

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

Éric Vyncke
Cisco
De Kleetlaan 6A
1831 Diegem
Belgium
Email: evyncke@cisco.com
 
Benoît Donnet
Université de Liège
Belgium
Email: benoit.donnet@uliege.be
 
Justin Iurman
Université de Liège
Belgium
Email: justin.iurman@uliege.be

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

nmalykh@protokols.ru


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

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

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

RFC 9505 A Survey of Worldwide Censorship Techniques

Internet Research Task Force (IRTF)                           J. L. Hall
Request for Comments: 9505                              Internet Society
Category: Informational                                      M. D. Aaron
ISSN: 2070-1721                                               CU Boulder
                                                         A. Andersdotter
                                                                        
                                                                B. Jones
                                                                        
                                                             N. Feamster
                                                               U Chicago
                                                               M. Knodel
                                       Center for Democracy & Technology
                                                           November 2023

A Survey of Worldwide Censorship Techniques

Обзор методов цензуры в мире

PDF

Аннотация

В этом документе описаны технические механизмы сетевой цензуры, применяемые режимами по всему миру для блокировки или нарушения трафика Internet. Целью документа является ознакомление разработчиков, внедренцев и пользователей протоколов Internet со свойствами и механизмами, применяемые для цензурирования доступа конечных пользователей к информации. Документ не содержит предложений по рассмотрению отдельных протоколов и является лишь информационным, предназначенным служить справкой. Документ является результатом работы исследовательской группы IRTF по повышению и оценке приватности (Privacy Enhancement and Assessment или PEARG).

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

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

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Privacy Enhancements and Assessmentsв рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

Цензурой называют подавление сочтённых нежелательными, вредными, деликатными или неудобными [WP-Def-2020] субъектом, обладающий властью (например, правительством, организацией или частным лицом). Хотя цензоры, занимающиеся соответствующими делами, должны делать это с помощью правовых, военных или иных мер, этот документ сосредоточен на технических механизмах, применяемых для цензуры в сети.

Документ описывает технические механизмы, которые режимы с цензурой по всему миру применяют для блокировки и ограничения трафика Internet. В [RFC7754] обсуждается блокировка и фильтрация с точки зрения влияния на архитектуру Internet, а не на доступ конечных пользователей к содержимому и услугам. Расширяются и академические исследования обхода цензуры (см. обзорную статью [Tschantz-2016]), результаты которых приводятся здесь для информирования разработчиков протоколов и их реализаций.

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

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

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

Здесь описывается три элемента цензуры в Internet – предписания (prescription), идентификация (identification) и вмешательство (interference). Документ содержит три основных раздела в соответствии с этими элементами. Предписания – это процесс, с помощью которого цензоры определяют, какие типы материалов следует подвергать цензуре (например, классификация порносайтов как нежелательных). Идентификация – это процесс, с помощью которого цензоры классифицируют конкретный трафик, или идентификаторы трафика для блокировки или ограничения (например, принимается решение о нежелательности web-страниц, содержащих sex в заголовке HTTP, или трафика от URL www.sex.example). Вмешательство – это процесс, с помощью которого цензоры вмешиваются во взаимодействие и предотвращают доступ к недозволенным материалам путём блокирования доступа или ухудшения соединения (например, за счёт реализации технического решения, способного идентифицировать заголовки HTTP или URL и обеспечивать для недозволенных материалов полную или частичную недоступность).

3. Технические предписания

Предписания – это процесс выяснения что цензоры хотели бы заблокировать [Glanville-2008]. Обычно цензоры собирают сведения «для блокирования» в списки блокировки (blocklist), базы хешей изображений [ekr-2021] или применяют эвристическую оценку содержимого в реальном масштабе времени [Ding-1999]. Некоторые национальные сети устроены для более естественного функционирования в качестве точек контроля [Leyba-2019]. Есть признаки применения сетевыми цензорами методов вероятностного машинного обучения [Tang-2016]. В некоторых юрисдикциях активными направлениями исследований в части выявления содержимого, представляющегося аморальным или коммерчески вредным для компаний или потребителей, являются сканирование web (crawling) и машинное обучение [SIDN-2020].

Обычно в списках блокировки имеется несколько элементов – ключевое слово, доменное имя, протокол или адрес IP. Блокирование по ключевым словам и именам доменов выполняется на прикладном уровне (например, HTTP), для блокирования по протоколам часто применяется глубокий просмотр пакетов (deep packet inspection или DPI) для определения запрещённых протоколов, блокирование по IP обычно выполняется по адресам IP в заголовках IPv4/IPv6. Некоторые цензоры используют присутствие определённых ключевых слов для подключения более жёстких списков блокировки [Rambert-2021] или более щадящего отношения к содержимому [Knockel-2021].

Механизмы создания списков блокировки могут быть разными. Цензоры могут приобретать у частных компаний программы контроля содержимого, позволяющие фильтровать трафик из широких категорий, которые хотелось бы заблокировать, таких как азартные игры или порнография [Knight-2005]. В таких случаях эти частные службы пытаются классифицировать каждый сомнительный (semi-questionable) web-сайт для обеспечения возможности блокировки по метатегам. Аналогичным способом настраиваются эвристические системы для сопоставления оценок с категориями нежелательного или спорного содержимого.

В странах, заинтересованных в сохранении определённого политического контроля, обычно имеются министерства или организации, поддерживающие списки блокировок. Примерами являются Министерство промышленности и информационных технологий (Ministry of Industry and Information Technology) в Китае, Министерство культуры и мусульманского наставничества (Ministry of Culture and Islamic Guidance) в Иране, организации, занимающиеся вопросами авторских прав во Франции [HADOPI] и защитой прав потребителей в Евросоюзе (EU) [Reda-2017].

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

4. Техническая идентификация

4.1. Точки контроля

Цензура Internet происходит во всех частях топологии сети. Это может быть реализовано в самой сети 9например, на локальном или транзитном канале), на серверной стороне коммуникаций (например, web-хосты, облачные провайдеры, сети доставки содержимого), в экосистеме вспомогательных служб (например, DNS или удостоверяющий центр), на стороне клиента (например, в пользовательском устройстве, таком как смартфон, переносный или настольный компьютер, программы, выполняемые на устройствах). Важным аспектом повсеместного технического перехвата является необходимость полагаться на программы или оборудование для перехвата интересующего цензора содержимого. Имеются различные физические и логические точки контроля, где серверы могут применять механизмы перехвата. Некоторые из таких точек перечислены ниже.

Магистраль Internet

Если цензор контролирует элементы сетевой инфраструктуры Internet, такие как международные шлюзы в регионе или точки обмена трафиком (Internet Exchange Point или IXP), эти точки могут служит для фильтрации нежелательного трафика в регион или из него путём перехвата пакетов и отображения (mirroring) портов. Цензура на шлюзах наиболее эффективна для контроля потока информации между регионом и остальной частью Internet, не неэффективна для идентификации содержимого между пользователями внутри региона, который следует реализовать в точках обмена трафиком или иных точках агрегирования. Некоторые национальные сети эффективно реализуют точки «дросселирования» (choke) и иного контроля [Leyba-2019].

Internet-провайдеры (ISP)

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

Организации

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

Сети распространения содержимого (CDN)

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

УЦ (CA) в инфраструктуре открытых ключей (PKI)

Органы, выпускающие криптографически защищённые ресурсы, могут быть значимыми точками контроля. CA, выдающий держателям доменов сертификаты для TLS/HTTPS (Web PKI) а также региональные или локальные регистраторы (Regional/ Local Internet Registry или RIR/LIR) выдающие полномочия на создание маршрутов (Route Origin Authorization или ROA) операторам BGP, могут быть вынуждены выпускать неконтролируемые сертификаты, что может приводить к компрометации (т. е. позволять программам цензоров осуществлять идентификацию и вмешательство так, где раньше это было невозможно). CA можно также вынудить к отзыву сертификатов. Это может приводить к недобросовестной маршрутизации трафика, возможности перехвата TLS или невозможности защищённого взаимодействия между легитимным отправителем и получателем потока трафика.

Службы

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

Сайты содержимого

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

Персональные устройства

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

На всех уровнях сетевой иерархии механизмы фильтрации, применяемые для цензурирования нежелательного трафика, по сути, одинаковы – цензор или напрямую указывает нежелательное содержимое с помощью описанных ниже идентификаторов и применяет блокировку или формовку (например, как описано ниже для предотвращения или затруднения доступа) или передаёт выполнение этих функций другому субъекту, не являющемуся цензором (например, частной компании). Идентификация нежелательного трафика может происходить на прикладном, транспорном или сетевом уровне стека IP. Цензоры часто сосредоточены на web-трафике, поэтому связанные с ним протоколы фильтруются предсказуемыми способами (параграфы 4.2.1 и 4.2.2). Например, подрывное изображение может пройти через фильтр ключевых слов, однако если потом это изображение будет сочтено нежелательным, цензор может внести в список блокировки IP-адрес сайта-провайдера.

4.2. Прикладной уровень

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

4.2.1. Идентификация заголовков запросов HTTP

Заголовок HTTP содержит много полезных для идентификации трафика сведений. Хотя единственным обязательным полем заголовка запроса HTTP (начиная с HTTP/1.1) является host, поле метода HTTP требуется для выполнения каких-либо полезных действий. Поэтому для вездесущей цензуры чаще всего применяются поля method и host. Цензор может просматривать (sniff) трафик и идентифицировать конкретное доменное имя (host), а обычно и имя страницы (напрмиер, GET /page). Этот метод идентификации обычно применяется в паре с идентификацией транспортных заголовков (см. параграф 4.3.1) для повышения надёжности.

Компромиссы. Идентификация заголовков запросов HTTP технически проста и может быть легко реализована на уровне магистрали или ISP. Нужное для этого оборудование дёшево и легко доступно, что делает его привлекательным, когда важную роль играет бюджет и масштабы. Протокол защищённой доставки гипертекста HTTPS (Hypertext Transport Protocol Secure) шифрует соответствующие поля запросов и откликов, поэтому для фильтрации HTTPS нужна ещё идентификация транспорта (см. параграф 4.3.1). Однако некоторые контрмеры могут тривиально преодолеть простые формы идентификации заголовков запросов HTTP. Например, взаимодействующие конечные точки (web-сервер и клиент) могут шифровать или иным способом скрывать (obfuscate) поле host в запросе, что может помешать методам сопоставления по значению поля host в заголовке запроса.

Примеры из практики. Исследования механизмов цензуры выявили факты фильтрации по заголовкам HTTP и/или URL во многих странах, включая Бангладеш, Бахрейн, Китай, Индию, Иран, Малайзию, Пакистан, Россию, Саудовскую Аравию, Южную Корею, Тайланд, Турцию [Verkamp-2012] [Nabi-2013] [Aryan-2013]. Цензоры часто покупают коммерческие технологии [Dalek-2013], сочетающие идентификацию заголовков запросов HTTP и транспортных заголовков для фильтрации конкретных URL. Dalek с соавторами [Dalek-2013] и Jones с соавторами [Jones-2014] выявили использование таких решений на практике.

4.2.2. Идентификация заголовков откликов HTTP

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

Компромиссы. Как и методы идентификации заголовков запросов HTTP, методы идентификации трафика HTTP общеизвестны, дешёвы и сравнительно просты в реализации. Однако при использовании HTTPS они бесполезны, поскольку HTTPS шифрует отклик и его заголовки.

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

Примеры из практики. А 2009 г. Jong Park с соавторами в университете New Mexico показали, что китайский межсетевой экран Great Firewall of China (GFW) использует идентификацию заголовков в откликах [Crandall-2010]. Однако Jong Park и др. обнаружили, что GFW прекратил это в процессе изучения. Ввиду перекрытия фильтрации по откликам HTTP и ключевым словам (см. параграф 4.2.4), можно предположить с достаточным основанием, что большинство цензоров полагается на фильтрацию потоков TCP по ключевым словам, а не фильтрацию откликов HTTP.

4.2.3. Защита на транспортном уровне (TLS)

Как и для HTTP, цензоры применяют множество методов для цензурирования TLS (и HTTPS). Большинство из этих методов основано на поле индикации имени сервера (Server Name Indication или SNI), включая цензурирование SNI, зашифрованных SNI (Encrypted SNI или ESNI) и пропущенных SNI. Цензоры могут также отслеживать содержимое HTTPS по сертификатам серверов. Отметим, что TLS 1.3 выступает как защитный компонент в протоколе QUIC.

4.2.3.1. Индикация имени сервера (SNI)

В зашифрованных соединениях TLS могут участвовать серверы, на которых размещается множество виртуальных серверов с одним сетевым адресом и клиент должен указать в сообщении ClientHello доменное имя, с которым он хочет соединиться (чтобы сервер мог ответить подходящим сертификатом TLS), используя расширение TLS SNI [RFC6066]. В TLS на основе протокола TCP сообщения ClientHello не шифруются. При использовании протокола QUIC сообщение ClientHello шифруется, но это не обеспечивает его эффективной защиты, поскольку начальные ключи шифрования выводятся с использованием значения, доступного в линии. Поскольку SNI часто передаётся в открытом виде (как и передаваемые в ответ поля сертификата), цензоры и программы фильтрации могут использовать его в целях блокировки, фильтрации или вмешательства путём сброса соединений с доменами, соответствующими запретному содержимому (например, bad.foo.example можно фильтровать, а good.foo.example – пропускать) [Shbair-2015]. В рабочей группе TLS предпринимаются усилия по стандартизации шифрования SNI [RFC8744] [TLS-ESNI] и недавние исследования дают многообещающие результаты при использовании ESNI в условиях фильтрации по SNI [Chai-2019] в некоторых странах.

Одним из популярных способов избежать идентификации цензорами является подстановка домена (domain fronting) [Fifield-2015]. Чтобы избежать идентификации приложения указывают в расширении SNI подставное имя домена, а настоящее указывают в заголовке host, защищённом HTTPS. Видимое значение SNI указывает разрешенный домен, а заблокированный скрывается в зашифрованном заголовке приложения. Некоторые службы шифрованных сообщений полагались на подстановку доменов в странах, использующих фильтрацию по SNI. Эти службы использовали для прикрытия домены, на уровне которых задавать блокирование нежелательно. Однако компании, владеющие большинством популярных доменов, перенастроили свои программы так, чтобы предотвратить такие злоупотребления. Возможно в будущем удастся достичь похожих результатов путём шифрования SNI.

Компромиссы. Некоторые клиенты не передают расширение SNI (например, клиенты, поддерживающие лишь SSL, но не TLS), что делает указанный метод неэффективным (см. параграф 4.2.3.3). Кроме того, для этого метода нужен глубокий просмотр пакетов (DPI), что может быть дорогостоящим в плане вычислительных ресурсов и инфраструктуры, особенно при использовании с протоколом QUIC, где для DPI требуется извлечение ключа и расшифровка ClientHello, чтобы прочесть SNI. Неаккуратная настройка блокировки по SNI может приводить к избыточной блокировке трафика, например, в результате случайной блокировки домена второго уровня вроде populardomain.example. В случае применения ESNI давление на цензуру может быть перенесено в другие точки вмешательства, такие как поставщики содержимого и приложений.

Примеры из практики. Имеется множество фирм, предлагающих средства фильтрации на основе SNI [Trustwave-2015] [Sophos-2023] [Shbair-2015]. Правительства Китая, Египта, Ирана, Катара, Южной Кореи, Турции, Туркменистана и Объединенных Арабских Эмиратов широко применяют фильтрацию и блокировку SNI [OONI-2018] [OONI-2019] [NA-SK-2019] [CitizenLab-2018] [Gatlan-2019] [Chai-2019] [Grover-2019] [Singh-2019]. Блокировка SNI для трафика QUIC впервые была отмечена в России в марте 2022 г. [Elmenhorst-2022].

4.2.3.2. Зашифрованные SNI (ESNI)

С учётом утечки данных SNI естественной реакцией является шифрование поля, что и было сделано в TLS 1.3 с помощью шифрованных приветствий клиента (Encrypted Client Hello или ECH). До ECH для предотвращения утечек, вызываемых SNI, применялось расширение ESNI, где шифровалось само поле SNI. К сожалению, цензоры могут настроиться на блокировку соединений, использующих ESNI. Это гарантированно вызовет избыточную блокировку, но может иметь смысл для цензоров, пока ESNI ещё не получили широкого распространения внутри страны. ECH является новым стандартом для защиты всего TLS ClientHello, но ещё не получил широкого распространения.

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

Примеры из практики. В 2020 г. в Китае началось цензурирование всех применений ESNI [Bock-2020b], даже для безобидных соединений. Механизм цензуры ESNI в Китае отличается от механизма для соединений на основе SNI, что позволяет предположить развёртывание новых промежуточных устройств специально для соединений ESNI.

4.2.3.3. Отсутствие SNI

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

Компромиссы. Блокирование всех соединений без поля SNI ведёт к избыточной блокировке, однако соединения без SNI на практике встречаются сравнительно редко.

Примеры из практики. В прошлом исследователи наблюдали в России блокировку цензорами соединений без поля SNI [Bock-2020b].

4.2.3.4. Сертификат отклика сервера

В процессе согласования TLS после TLS ClientHello сервер будет отвечать сертификатом TLS. Этот сертификат содержит домен, к которому пытается обратиться клиент, открывая дополнительную возможность для цензуры. Этот метод не будет работать с TLS 1.3, где сертификат шифруется.

Компромиссы. Цензура на основе сертификатов сервера требует методов DPI, что может быть более ресурсоёмким по сравнению с другими методами. Кроме того, сертификат в согласовании TLS передаётся позже по сравнению с полем SNI, что требует от цензора отслеживать соединение дольше.

Примеры из практики. Исследователи наблюдали, как Reliance Jio ISP в Индии использует поля отклика с сертификатом для цензурирования соединений [Satija-2021].

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

Правительства многих стран вынуждают поставщиков содержимого вводить самоцензуру или создают правовую базу, в рамках которой распространители содержимого (content distributor) стимулируются следовать предпочтениям по ограничению содержимого от внешних агентов [Boyle-1997]. По причине обширности сферы применения такой цензуры распространителями содержимого считаются любые службы, предоставляющие услуги пользователю, от web-сайтов до хранилищ локально установленных программ.

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

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

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

Компромиссы. Предоставляя распространителям содержимого средства идентификации ограниченного содержимого или его поставщиков, цензоры могут получать новые сведения за счёт политического капитала компаний, которые они заставляют или поощряют участвовать в цензуре. Например, цензор может получить представление о содержимом шифрованного трафика, вынудив web-сайты идентифицировать содержимое, на которое наложены ограничения. Принуждение распространителей содержимого влиять на пользователей, категории пользователей, содержимое и его поставщиков в части применения самоцензуры является дополнительным средством для цензоров (см. параграф 6.2). Компромисс при инструментальном воздействии на распространение содержимого сильно зависит от поставщика содержимого и требуемой поддержки. Типичная проблема заключается в том, что целевые наборы ключевых слов или категорий слишком широки и создают риск избыточной блокировки или не проходят достаточно строгой правовой проверки перед обязательным применением (см. стр. 8 в [EC-2012]).

Примеры из практики. Исследователи обнаружили идентификацию ключевых слов поставщиками содержимого от платформ обмена мгновенными сообщениями [Senft-2013] до поисковых систем [Rushe-2014] [Cheng-2010] [Whittaker-2013] [BBC-2013] [Condliffe-2013]. Для демонстрации распространённости этого типа идентификации ключевых слов следует рассмотреть цензуру в поисковых системах.

Цензура поисковых систем демонстрирует идентификацию ключевых слов поставщиками содержимого и может носить как региональный, так и планетарный характер. Иногда реализация бывает добровольной, но обычно она основана на законах и правилах страны, где работает поисковая машина. Списки блокировки по ключевым словам, скорей всего, поддерживаются провайдерами поисковых систем. Известно, что в Китае от провайдеров поисковых машин требуют «добровольно» поддерживать списки блокировки поисковых слов для получения и сохранения лицензии поставщика содержимого (Internet Content Provider или ICP) [Cheng-2010]. Очевидно, что такие списки поддерживает каждый провайдер поисковой машины, судя по незначительным вариациям перехватываемого поиска [Zhu-2011] [Whittaker-2013]. В Великобритании подталкивают поисковые системы к самоцензуре, угрожая судебным разбирательством в случае отказа – Google и Microsoft согласились блокировать более 100 000 запросов в Великобритании, чтобы помочь в борьбе со злоупотреблениями [BBC-2013] [Condliffe-2013]. Законодательство Европейского союза и США требует изменять результаты поиска в ответ на претензии в части авторских прав, торговых знаков, защиты данных и дискредитации [EC-2012].

Сложность обнаружения идентификации ключевых слов зависит от поисковой выдачи. В некоторых случаях специализированный или пустой результат позволяет легко обнаружить блокировку, но более тонкую цензуру заметить сложнее. В феврале 2015 г. поисковую машину Bing компании Microsoft обвинили в цензуре китайского содержимого за пределами Китая [Rushe-2014], поскольку выдача Bing различалась для запросов на китайском и английском языке. Однако не исключено, что цензура самой большой базы китайских пользователей поиска – Китая – исказила результаты так, что более популярные в Китае результаты (без цензуры) оказались более популярны у говорящих на китайском языке и за пределами Китая.

Дистанцирование дистрибьюторов содержимого от некоторых категорий пользователей произошло, например, в Испании в результате конфликта движения за независимость Каталонии с испанской правовой презумпцией унитарного государства [Lomas-2019]. Организаторы соревнования по киберспорту (E-sport) отмежевались от ведущих игроков, выразивших свои политические взгляды в связи с протестами 2019 г. в Гонконге [Victor-2019] (см. параграф 5.3.1).

4.2.5. DPI-идентификация

К DPI технически относится любой анализ пакетов глубже адресов IP и номеров портов и в последние годы это стало реализуемо вычислительными средствами в качестве механизма цензуры [Wagner-2009]. В отличие от других методов, DPI восстанавливает (reassemble) сетевые потоки для проверки разделов данных приложения, а не только заголовков, поэтому часто служит для идентификации ключевых слов. DPI отличается от других методов идентификации использованием дополнительных методов идентификации содержимого, например, размера и временных характеристик пакетов. Для предотвращения значительного влияния на QoS в DPI обычно анализируются копии данных, а исходные пакеты маршрутизируются обычным путем. Трафик обычно расщепляется отображающим коммутатором или оптическим разветвителем (splitter) и анализируется кластером машин, на которых работают системы обнаружения вторжений (Intrusion Detection System или IDS), настроенные для цензуры.

Компромиссы. DPI является одним из наиболее дорогих маханизмов идентификации и сильно влияет на QoS [Porter-2005]. При использовании для фильтрации ключевых слов в потока TCP системы DPI могут приводить к избыточной блокировке. Как и другие мтоды, DPI мало подходит для шифрованных данных, хотя для идентификации трафика DPI может использовать для идентификации трафика нешифруемые элементы потока шифрованных данных (например, SNI в TLS) или метаданные шифрованного потока (например, размеры пакетов, которые различаются для текстовых и видео-потоков). Дополнительные сведения о фильтрации по SNI приведены в параграфе 4.2.3.1.

Дополнительные сведения могут быть получены при сравнении некоторых нешифруемых элементов согласования TLS с аналогичными элементами данных из известных источников. Такая практика, называемая «отпечатками TLS» (fingerprinting), позволяет вероятностно идентифицировать операционные системы сторон, браузеры и приложения на основе конкретных комбинаций версии TLS, шифров, опций сжатия и т. п., передаваемых в сообщениях ClientHello, путём сравнения с похожими сигнатурами нешифрованного трафика [Husak-2016].

Несмотря на отмеченные сложности, DPI является мощным методом идентификации и широко применяется на практике. Великий китайский брандмауэр GFW – крупнейшая система цензуры в мире – использует DPI для обнаружения запретного содержимого в HTTP и DNS, а также внедрения в соединения пакетов TCP RST и негативных откликов DNS [Crandall-2010] [Clayton-2006] [Anonymous-2014].

Примеры из практики. В ряде исследований были обнаружены свидетельства применения DPI для цензуры содержимого и воздействия на него. Clayton с соавторами, Crandal и др., Anonymous и Khattak с соавторами исследовали GFW [Crandall-2010] [Clayton-2006] [Anonymous-2014]. Khattak с соавтоорами даже исследовали брандмауэр для обнаружения деталей реализации, таких как число хранимых состояний [Khattak-2013]. Проект Tor заявляет, что Китай, Иран, Эфиопия и другие страны наверняка применяли DPI для блокировки протокола obfs2 [Wilde-2012]. Малайзию обвиняют в использовании целевой инспекции DPI в сочетании с DDoS для идентификации и последующей атаки на материалы оппозиции [Wagstaff-2013]. Представляется вероятным, что организации, не блокирующие содержимое в реальном масштабе времени, могут применять DPI для сортировки и классификации собранного трафика с использованием высокоскоростной обработки пакетов [Hepting-2011].

4.3. Транспортный уровень

4.3.1. Неглубокая проверка пакетов и идентификация заголовков транспорта

Среди методов поверхностной проверки пакетов идентификация транспортных заголовков является наиболее распространенной, надежной и предсказуемой. Транспортные заголовки содержат несколько бесценных элементов информации, которые наиболее очевидны для успешной маршрутизации трафика – адреса IP и номера портов отправителя и получателя. Поля IP отправителя и получателя ценны вдвойне, поскольку они не только позволяют цензору блокировать нежелательное содержимое по IP, но и дают цензору возможность определить адрес пользователя, передающего запрос, и адрес вызываемой службы, по которому в большинстве случаев можно определить посещенный домен [Patil-2019]. Номер порта полезен для списков разрешённых приложений.

Сочетание адресов IP, портов и сведений о протоколе в транспортном заголовке позволяет цензору использовать поверхностную инспекцию пакетов для идентификации конкретных конечных точек TCP или UDP. Блокировка конечных точек UDP наблюдалась в контексте блокирования QUIC [Elmenhorst-2021].

Компромиссы. Идентификация заголовков популярна из-за её простоты, доступности и надёжности. Идентификация заголовков тривиально реализуется в некоторых маршрутизаторах, но сложна для реализации в маршрутизаторах магистралей и ISP, поэтому там она обычно реализуется с помощью DPI. Включение IP в список блокировки эквивалентно установке конкретного маршрута в маршрутизаторе (например, маршрута /32 для IPv4 или /128 для IPv6). Однако из-за ограниченного размера таблицы потоков этот в список блокировки невозможно включить более нескольких тысяч IP. Кроме того, такая блокировка является достаточно грубой и часто избыточна для некоторых служб вроде сетей CDN, где содержимое связано с сотнями или тысячами адресов IP. Несмотря на эти недостатки, блокировка по IP очень эффективна, поскольку для её обхода пользователю приходится передавать трафик через прокси. Кроме того, блокировка по IP работает против любых протоколов, работающих на основе IP, например, TCP или QUIC.

Блокровка портов обычно бесполезна, поскольку один порт может использоваться для разных типов содержимого, а приложения могут менять номер порта. Например, большая часть трафика HTTP идёт через порт 80, поэтому цензор не может различить нежелательное и разрешённое содержимое web лишь по номеру порта. HTTPS работает через порт 443, что влечёт для цензова аналогичные последствия, которому, кроме того, доступна лишь часть метаданных. Иногда применяются списки портов, с помощью которых цензор ограничивает взаимодействие (например, разрешается лишь порт 80 для трафика HTTP), и эти списки наиболее эффективны в сочетании с другими методами идентификации. Например, цензор может блокировать принятый по умолчанию порт 443 для HTTPS, вынуждая многих пользователей вернуться к HTTP. В качестве контрпримера можно привести блокировку порта 25 (SMTP), давно применяемую в сетях домашних провайдеров для снижения объёма спама, однако это не позволяет клиентам таких ISP запускать свои почтовые серверы.

4.3.2. Идентификация протокола

Иногда цензоры блокируют некоторые протоколы целиком, используя различные характеристики трафика. Например, Иран снижает производительность трафика протокола HTTPS, препятствующего дальнейшему анализу, чтобы вынудить пользователей перейти на протокол HTTP, который можно анализировать [Aryan-2013]. Простая идентификация протокола будет распознавать трафик TCP через порт 443 как HTTPS, но изощренный анализ статистических свойств данных содержимого и поведения потоков будет более эффективным, даже если порт 443 не используется [Hjelmvik-2010] [Sandvine-2015].

Если цензоры обнаружат средства обхода, они могут блокировать их. Поэтому цензоры, такие как Китай, очень заинтересованы в идентификации протоколов для инструментов обхода цензуры. В последние годы это переросло в соперничество между цензорами и разработчиками средств обхода. Это соперничество привело к разработке в Китае чрезвычайно эффективной методики идентификации протоколов, называемой исследователями активным зондированием (active probing) или активным сканированием (active scanning). При активном зондировании цензоры определяют, используется ли на хосте протокол обхода, пытаясь инициировать взаимодействие с использованием этого протокола. Если хост и цензор успешно согласуют соединение, цензор узнает, что на хосте применяется средство обхода. В Китае используется активное сканирование для эффективного блокирования Tor [Winter-2012].

Компромиссы. Идентификация протокола даёт лишь представление о способе передачи информации, но не о самой информации. Идентификация протокола полезна для обнаружения и блокировки средств обхода (таких как Tor) или трафика, который трудно проанализировать (например, VoIP или SSL), поскольку цензор может предположить, что этот трафик следует блокировать. Однако блоикировка может оказаться избыточной при использовании для популярных протоколов. Методы дороги в вычислительном и финансовом смысле из-за применения статистическго анализа, а также могут быть малоэффективны по причине низкой точности.

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

Примеры из практики. Иденификацию протокола можно легко обнаружить, если она происходит в реальном масштабе времени и блокируется лишь определённый протокол. Однако некоторые типы идентификации протокола, такие как активное сканирование, могут быть более сложны для обнаружения. Идентификация протоколов использовалась Ираном для обнаружения и подавления трафика протокола SSH (Secure Shell), чтобы осложнить его использование [Van-der-Sar-2007], а также Китаем для идентификации и блокировки ретрансляторов Tor [Winter-2012]. Идентификация протоколов применялась также для управления трафиком, например, в 2007 г., когда компания Comcast из США использовала внедрение пакетов TCP RST в потоки для прерывания трафика BitTorrent [Winter-2012]. В 2020 г. Иран развернул фильтр, который разрешал использовать лишь три протокола (DNS, TLS, HTTP) на конкретных портах, подвергая цензуре любые соединения, которые не идентифицированы [Bock-2020]. В 2022 г. Россия, возможно, использовала идентификацию протоколов для блокировки большинства соединений HTTP/3 [Elmenhorst-2022].

4.4. Остаточная цензура

Ещё одной особенностью некоторых современных систем цензуры является остаточная цензура – карательная форма цензуры, при которой после прерывания цензором запретного соединения сохраняется отслеживание последующих соединений, даже если они безвредны [Bock-2021]. Остаточная цензура может принимать разные формы и часто основана на методах технического вмешательства, описанных в следующем разделе. Важным аспектом остаточной цензуры является состав того, что цензор продолжает блокировать после её включения. Имеется три основных варианта – адреса IP у сервера и клиента (2-tuple), адреса сервера и клиента плюс порт сервера (3-tuple), адреса и номера портов у клиента и сервера (4-tuple). Будущие соединения, соответствующие отслеживаемому кортежу будут прерываться цензором [Bock-2021].

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

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

Примеры из практики. В Китае многие годы применялась остаточная цензура 3-tuple в сочетании с цензурой HTTP и исследователи сообщали об аналогичной остаточной цензуре для HTTPS. По всей видимости В Китае применяется сочетание остаточной цензуры 3-tuple и 4-tuple для цензуры HTTPS с использованием ESNI. Некоторые цензоры, (включая Казахстан и Иран), выполняющие цензуру через отбрасывание пакетов, зачастую случайно применяют остаточную цензуру 4-tuple [Bock-2021].

5. Техническое вмешательство

5.1. Прикладной уровень

5.1.1. Вмешательство в DNS

Имеется ряд механизмов, которые цензоры могут применять для блокировки или фильтрации доступа к содержимому путём изменения откликов DNS [AFNIC-2013] [ICANN-SSAC-2012], включая блокировку откликов, в также возврат сообщений об ошибках или некорректных адресов. Отметим, что в настоящее время существует защищённая доставка запросов DNS через HTTPS [RFC8484] и TLS [RFC7858], которая может смягчить помехи для запросов DNS между «заглушкой» (stub) и распознавателем.

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

DNS mangling (мскажение) – это метод перехвата на сетевом уровне, где возвращается некорректный адрес IP в отклике на запрос DNS для запретного адресата. Так поступают, например, в некоторых китайских сетях (авторам неизвестно о других столь же масштабных примерах), где каждый передаваемый запрос DNS проверяется (предположительно с помощью таких технологий, как DPI) и при соответствии списку цензуры на него возвращается ложный отклик. Конечные пользователи могут увидеть действие этого метода, просто передав запрос DNS для любого адреса, не используемого в Китае (см. пример ниже). Если доменное имя не подвергается цензуре, отклика просто не будет, в ином случае возвращается обманный отклик. Ниже приведён пример запросов с помощью утилиты dig у сервера с неиспользуемым в Китае адресом IP 192.0.2.22 для имен www.uncensored.example (нет отклика) и www.censored.example (подвергался цензуре на момент написания, получен обманный адрес IP 198.51.100.0).

   % dig +short +nodnssec @192.0.2.2 A www.uncensored.example
   ;; connection timed out; no servers could be reached

   % dig +short +nodnssec @192.0.2.2 A www.censored.example
   198.51.100.0

Отравление кэшей DNS происходит вне пути и является механизмом вмешательства цензора в отклики полномочных серверов имён DNS рекурсивным распознавателям за счёт более быстрой отправки откликов (с ложными адресами IP) [Halley-2008]. Отравление кэша происходит после того, как серверы имён запрашиваемого сайта распознают запрос и пытаются передать запрашивающему устройству отклик с корректным адресом IP. На пути возврата отклика распознанный адрес IP рекурсивно кэшируется каждым сервером DNS, который ранее пересылал запрос. В процессе кэширования при распознавании нежелательного ключевого слова распознанный адрес IP «отравляется» и возвращается другой адрес IP (или ошибка NXDOMAIN) быстрее, чем мог ответить исходный распознаватель, что ведёт к кэшированию ложено адреса IP (возможно, рекурсивно). Ложные адреса IP обычно направляют в несуществующий домен или на страницу с предупреждением. Как вариант, иранская цензура препятствует взаимодействию, не позволяя передавать отклик [Aryan-2013].

Известны также случаи DNS-обмана (DNS lying), когда цензор требует предоставлять (оператором рекурсивного распознавателя или ISP) отклики DNS, отличающиеся от тех, которые даёт полномочный сервер [Bortzmeyer-2015].

Компромиссы. Эти формы вмешательства в DNS требуют от цензора вынуждать пользователей проходить через контролируемую иерархию DNS (или промежуточную сеть, где цензор является активным всемогущим «атакующим» [RFC7624] для переписывания откликов DNS), чтобы механизм мог работать. Вмешательство в DNS можно обойти, используя другие распознаватели DNS (например, общедоступные DNS), которые могут находиться вне сферы контроля цензора, или технологию виртуальных частных сетей (Virtual Private Network или VPN). Искажение DNS и отравление кэша предполагают возврат некорректных адресов IP при попытках распознавания доменных имён, но в некоторых случаях адресат может быть технически доступен. Например, для протокола HTTP у пользователя может быть другой способ получения IP-адреса нужного сайта и пользователь сможет получить доступ к нему, если сайт настроен на использование по умолчанию для данного IP. Проблема возникает и при блокировке по целям, поскольку иногда пользователи, находящиеся за пределами региона цензуры, будут направляться через серверы DNS или переписывающее DNS оборудование, контролируемые цензором, что вызовет отказы при выполнении запросов. Простота обхода в сочетании с большим риском блокировки содержимого и блокировки по целям делает вмешательство в DNS неполным, сложным и не самым идеальным механизмом цензуры.

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

Ранее для цензуры применялись методы, основанные на передаче запросов DNS в открытом виде (cleartext) через порт 53 [SSAC-109-2020]. С внедрение ширования в DNS (например, DNS через HTTPS [RFC8484]) запросы все чаще передаются через порт 443 вместе с другим трафиком HTTPS или в зашифрованном виде при работе DNS через TLS [RFC7858] (см. параграф 4.3.1).

Примеры из практики. Вмешательство в DNS при подобающей его реализации легко обнаружить по отмеченным выше недостаткам. В марте 2014 г. Турция в течение почти недели полагалась на вмешательство в DNS для блокировки web-сайтов, включая Twitter и YouTube. Простота обхода блокировки привела к росту популярности Twitter, пока турецкие ISP не ввели блокировку по IP для выполнения требований правительства [Zmijewski-2014]. В итоге турецкие ISP стали перехватывать все запросы к международным распознавателям DNS компаний Google и Level 3 [Zmijewski-2014]. Некорректная реализация вмешательства в DNS привела к крупным бедствиям для цензуры. В январе 2014 г. Китай начал направлять все запросы, проходящие через GFW, в домен dongtaiwang.com из-за неподобающей настройки отравления DNS. Этот инцидент считается крупнейшим в истории отказом служб Internet [AFP-2014] [Anon-SIGCOMM12]. В таких странах, как Китай, Турция и США обсуждался вопрос о бликировке целиком доменов верхнего уровня (Top-Level Domain или TLD) [Albert-2011]. Блокировка DNS часто применяется в европейских странах для оборбы с нежелательным содержимым.

  • Насилие (abuse) над детьми (Норвегия, Великобритания, Бельгия, Дания, Финляндия, Франция, Германия, Ирландия, Италия, Мальта, Нидерланды, Польша, Испания, Швеция [Wright-2013] [Eneman-2010]).

  • Азартные игры (Бельгия, Болгария, Чехия, Кипр, Дания, Эстония, Франция, Греция, Венгрия, Италия, Латвия, Литва, Польша, Португалия, Румыния, Словакия, Словения, Испания; параграф 6.3.2 в [EC-gambling-2012], [EC-gambling-2019]).

  • Нарушаюения авторских прав (Все страны Европейской экономической зоны).

  • Разжигание ненависти и экстремизм (Франция [Hertel-2015]).

  • Терроризм (France [Hertel-2015]).

5.2. Транспортный уровень

5.2.1. Снижение производительности

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

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

Примеры из практики. Известно, что Иран сокращает пропускную способность для трафика HTTPS, чтобы шире применялся нешифрованный трафик HTTP [Aryan-2013].

5.2.2. Отбрасывание пакетов

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

Компромиссы. Отбрасывание пакетов наиболее успешно в случаях, когда каждый пакет имеет доступные сведения, связанные с нежелательным содержимым (например, IP-адрес получателя). Одним из недостатков метода является необходимость блокирования всего содержимого, включая разрешённый трафик с тем же адресом IP (например. для для всех блогов или репозиториев GitHub на одном сервере). Известно, что Китай в течение 3 дней отбрасывал все пакеты GitHub из-за одного репозитория с нежелательным содержимым [Anonymous-2013]. Необходимость проверки каждого пакета в близком к реальному масштабе времени делает отбрасывание пакетов проблематичным решением с точки зрения QoS.

Примеры из практики. Отбрасывание пакетов является очень распространённой формой технического вмешательства и поддаётся точному обнаружению из-за оставляемых уникальных следов в тайм-аутах запросов. Замечено, что Great Firewall в Китае использует отбрасывание пакетов в качестве одного из основных технических механизмов цензуры [Ensafi-2013]. Иран применяет отбрасывание пакетов в качестве механизма поддавления SSH [Aryan-2013]. Это лишь два примера из практики повсеместной цензуры. Примечательно, что отбрасывание пакетов в процессе согласования или при работе соединений – это единственный метод технического вмешательства, отмеченный к настоящему времени для протокола QUIC (например, в Индии, Иране, России и Уганде [Elmenhorst-2021] [Elmenhorst-2022]).

5.2.3. Внедрение пакетов RST

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

Протокол QUIC после организации соединения не чувствителен к таким атакам с внедрением пакетов. Хотя в QUIC реализован механизм сброса без учёта состояния, каждая из партнёров воспринимает такой сброс лишь в том случае, когда пакет завершается выданным ранее маркером (stateless reset), который трудно угадать. В процессе согласования QUIC обеспечивает эффективную защиту лишь от злоумышленников вне пути, но уязвим к атакам с внедрением пакетов со стороны злоумышленников, проанализировавших предшествующие пакеты (см. подробности в [RFC9000]).

Компромиссы. Несмотря на неэффективность для протоколов, отличных от TCP (QUIC, IPsec), внедрение пакетов RST имеет ряд преимуществ, которые делают этот метод чрезвычайно популярным для цензуры. Внедрение пакетов RST является вмешательством, позволяющим избежать узких мест QoS, с которыми можно столкнуться при использовании таких методов, как отбрасывание пакетов. Это свойство «внеполосности» (out-of-band) позволяет цензору просматривать копию данных, обычно отображаемую оптическим ответвителем, что делает метод идеальным в сочетании с DPI и идентификацией протоколов [Weaver-2009]. Такой асинхронный вариант часто называют «машиной в стороне» (machine-on-the-side или MOTS). Преимуществом внедрения пакетов RST является также то, что для прерывания соединения достаточно восприятия внедренного пакета лишь одной из двух конечных точек.

Сложность внедрения пакетов RST заключается в подделке «достаточного» объёма данных, чтобы конечная точка сочла пакет RST легитимным, – обычно это включает корректный адрес IP, порт и порядковый номер TCP. Порядковый номер подделать сложней всего, поскольку [RFC9293] указывает, что для восприятия пакета RST ему следует быть упорядоченным, хотя в том же RFC рекомендуется воспринимать пакеты из окна (in-window). Эта рекомендация важна и её выполнение позволяет организовать атаку с внедрением RST вслепую (Blind RST Injection) [Netsec-2011]. Когда номера из окна разрешены, организация вставки RST вслепую становится тривиальной задачей. Хотя термин «внедрение вслепую» предполагает, что у цензора нет никаких конфиденциальных (sensitive) сведений о порядковых номерах потока TCP, в который он внедряется, можно просто перебрать все ~70000 возможных окон. Это особенно полезно для прерывания шифрованных и запутанных (obfuscated) протоколов, таких как SSH и Tor [Gilad]. Некоторые системы обхода цензуры пытаются запутать цензора, заставляя того отслеживать некорректную информацию, что делает внедрение пакетов RST бесполезным [Khattak-2013] [Wang-2017] [Li-2017] [Bock-2019] [Wang-2020].

Внедрение пакетов RST предназначено для сетей с поддержкой состояния, что делает этот метод бесполезным для соединения UDP. Внедрение пакетов RST является одним из наиболее популярных методов цензуры, применяемых в настоящее время, благодаря его универсальности и эффективности для всех типов трафика TCP. Недавние исследования показали, что атаки с внедрением пакетов TCP RST возможны даже при размещении атакующего вне пути [Cao-2016].

Примеры из практики. Как отмечено выше, внедрение пакето RST чаще всего применяется в комбинации с методами, требующими расщепления (отвода) трафика, такими как DPI и идентификация протоколов. В 2007 г. компанию Comcast обвинили в применении внедрения пакетов RST для прерывания трафика, идентифицированного как BitTorrent [Schoen-2007], что привело к постановлению Федеральной комиссии США по связи (US Federal Communications Commission) против Comcast [VonLohmann-2008]. Известно также, что Китай часто применяет внедрение пакетов RST для цензуры. Особенно наглядно это проявляется в прерывании работы шифрованных и запутанных (obfuscated) протоколов, вроде применяемых в Tor [Winter-2012].

5.3. Уровень маршрутизации

5.3.1. Изоляция сетей

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

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

Примеры из практики. Отключение сетей, как правило, происходит лишь во время серьёзных беспорядков, что обусловлено огромными социальными, политическими и экономическими последствиями такого шага. Одним из первых, получивших широкое освещение, случаев стало отключение сети хунтой Мьянмы при подавлении восстания в 2007 г. [Dobie-2007]. Китай отключал сеть в районе Синьцзян во время беспорядков 2009 г., чтобы предотвратить распространение протестов в другие регионы [Heacock-2009]. Наиболее часто отключение сетей применялось во время Арабской весны в Египте и Ливии в 2011 г. [Cowie-2011], в Сирии в 2012 г. [Thomson-2012]. Россия заявила о попытке отключения своих сетей от Internet в апреле 2019 г. в рамках проверки сетевой независимости страны. Сообщалось, что в рамках тестового отключения российские телекоммуникационные компании должны маршрутизировать весь трафик на государственные точки мониторинга [Cimpanu-2019]. Наибольшее число отключений сетей наблюдалось в Индии в 2016 и 2017 гг. [Dada-2017].

5.3.2. Анонсирование обманных маршрутов

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

Компромиссы. Глобальное распространение ложного маршрута к web-сайту может перегрузить ISP, если сайт был популярным. Это не является постоянным решением, поскольку некорректные маршруты BGP с глобальным распространением могут быть исправлены, но маршруты с локальным влиянием (внутри юрисдикции) могут быть исправлены ISP/IXP лишь для локальных пользователей.

Примеры из практики. В 2008 г. компания Pakistan Telecom по требованию правительства Пакистана ввела цензуру для YouTube путём изменения маршрутов BGP для этого сайта. Новые маршруты анонсировались восходящим ISP и не только. В результате вся сеть Internet стала направлять маршруты для YouTube на Pakistan Telecom и это продолжалось в течение многих часов. В 2018 г. почти все службы Google и клиенты Google Cloud (например, Spotify), не могли работать более часа после того, как компания Google потеряла контроль над несколькими миллионами своих адресов IP. Эти префиксы IP некорректно маршрутизировались в China Telecom (государственный китайский ISP) [Google-2018], аналогично захвату BGP для правительственных и военных web-сайтов США компанией China Telecom в 2010 г. ISP в России (2022) и Мьянме (2021) неоднократно пытались захватить один префикс Twitter [Siddiqui-2022].

5.4. Воздействие на других уровнях

5.4.1. Распределенный отказ в обслуживании (DDoS)

Распределенные атаки для отказа в обслуживании (Distributed Denial of Service или DDoS) являются основным механизмом, применяемым «хактивистами» и злонамеренными хакерами. Цензоры в прошлом также применяли DDoS по разным причинам. Существует большое разнообразие атак DDoS [Wikip-DoS]. Однако на верхнем уровне возникает два варианта – «наводнение» (flood) пакетами ведёт к непригодности службы для использования, а атаки с авариями (crash) нацелены на отказ службы, чтобы ресурсы можно было выделить в другом месте без «освобождения» службы.

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

Примеры из практики. В 2012 г. британская организация по разведке сигналов, Штаб правительственной связи (Government Communications Headquarters или GCHQ) использовала DDoS для временной остановки чатов IRC (Internet Relay Chat), посещаемых членами группы Anonymous, с использованием метода Syn Flood DDoS. Этот метод использует согласование TCP для перегрузки сервера-жертвы таким числом запросов, что легитимный трафик сильно замедляется или прекращается [NBC-2014] [CERT-2000]. Сайты-диссиденты часто становятся жертвами DDoS-атак во время политически важных событий, например, DDoS в Бирме [Villeneuve-2011]. Правящие партии в России [Kravtsova-2012], Зимбабве [Orion-2013] и Малайзии [Muncaster-2013] обвинялись в применении DDoS для предотвращения поддержки и доступа к сайтам оппозиции во время выборов. В 2015 г. в Китае была организована DDoS-атака с использованием системы MITM (названной «Великая пушка» – Great Cannon), размещённой на Great Firewall и позволяющей внедрять код JavaScript при посещении китайской поисковой системы, что вело к передаче пользовательскими агентами трафика DDoS на различные сайты [Marczak-2015].

5.4.2. Глубокая цензура

Зачастую цензоры применяют сразу несколько методов, организуя глубокую цензуру (censorship in depth). Такая цензура может иметь разные формы – некоторые цензоры блокируют одно и то же содержимое несколькими методами (например, блокирование домена в DNS, блокирование по IP и HTTP), другие организуют распараллеливание для повышения надёжности (например, применение нескольких разных систем цензуры для блокировки одного и того же домена), третьи могут применять дополнительные системы для снижения возможностей обхода (например, полная блокировка нежелательных протоколов, вынуждающая пользователей переходить на другие протоколы).

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

Примеры из практики. Глубокая цензура сегодня применяется многими крупными государствами. Исследователи отмечают, что Китай развернул крупную систему глубокой цензуры, часто подвергая цензуре по нескольким протоколам один и тот же ресурс [Chai-2019] [Bock-2020b] или реализуя несколько систем цензуры для одного содержимого и протокола [Bock-2021b]. В Иране внедрён дополняющий фильтр протоколов для ограничения использования протоколов на некоторых портах, вынуждающий пользователей применять протоколы, которые система цензуры может фильтровать [Bock-2020].

6. Иные виды вмешательства

6.1. Ручная фильтрация

Иногда ручная настройка является простейшим способом блокировки содержимого. Ручная фильтрация отличается от обычной тактики создания списков блокировки тем, что она не обязательно направлена на конкретный IP или DNS, а удаляет или помечает содержимое. С учётом неточности автоматической фильтрации ручная сортировка содержимого и маркировка нежелательных web-сайтов, блогов и других сред может быть эффективным средством как сама по себе, так и в сочетании с автоматическими методами обнаружения, за которыми следуют действия, требующие подтверждения вручную. Такая фильтрация может выполняться в магистрали или у ISP. Хорошим примером является китайская армия мониторов [BBC-2013b], но чаще ручная фильтрация происходит на институциональном уровне. Для ICP, таких как Google и Weibo, требуется получение лицензии на работу в Китае. Одним из предварительных условий для получения такой лицензии является согласие подписать «добровольное обязательство», известное как Public Pledge on Self-discipline for the Chinese Internet Industry. Неспособность «энергично поддерживать» заявленные возможности может приводить к ответственности ICP за недопустимое (offending) содержимое со стороны правительства Китая [BBC-2013b].

6.2. Самоцензура

Самоцензуру трудно документировать, поскольку она проявляется, прежде всего, в отсутствии нежелательного содержимого. Средства, способствующие самоцензуре, могут потребовать от предполагаемого автора поверить, что выступление повышает для него риск неблагоприятных последствий (технический мониторинг, требования к идентификации и т. п.). Методы навязывания самоцензуры «Репортеров без границ» (Reporters Without Borders) приводятся в ежегодных отчётах World Press Freedom Index [RWB-2020].

6.3. Изъятие сервера

Как уже упоминалось в [Murdoch-2008], серверы должны иметь физическое местоположение где-то в мире. Если нежелательное содержимое размещено в стране, где действует цензура, серверы могут быть изъяты физически или от хостинг-провайдера могут потребовать запрета доступа (если сервер виртуальный и размещён в облачной инфраструктуре, где может не быть фиксированного местоположения.

6.4. Уведомления и удаление содержимого

Во многих странах имеются механизмы, позволяющие частному лицу или иному поставщику содержимого направить держателю хостинга юридический запрос на удаление содержимого. Примеры включают системы, развёрнутые такими компаниями, как Google, для соблюдения «права быть забытым» (Right to be Forgotten) в Европейском союзе [Google-RTBF], правила ответственности для провайдеров электронных платформ [EC-2012], ориентированные на авторские права уведомления и удаление содержимого, предусмотренные разделом 512 Закона США об авторских правах в цифровую эпоху (United States Digital Millennium Copyright Act или DMCA) [DMLP-512].

6.5. Изъятие доменного имени

Доменные имена каталогизируются на серверах имён, управляемых юридическими лицами (регистраторами). Эти реестры можно вынудить передать управление доменом от зарегистрировавшего домен лица кому-либо иному с помощью правовой процедуры, основанной на частных договорах или законе. Изъятие доменного имени все чаще применяется государственными органами и частными организациями для борьбы с распространением нежелательного содержимого [ICANN-2012] [EFF-2017].

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

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

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

В части обхода цензуры рост числа протоколов, применяющих шифрование, является эффективной мерой противодействия некоторым формам цензуры, описанным здесь, однако подробное исследование обхода и шифрования оставлено для другого документа. Кроме того, сообщество разработчиков средств обхода цензуры развивает направление по исследованию подключаемого (pluggable) транспорта, в рамках которого собираются, документируются и совершенствуются методы запутывания (obfuscating) трафика в пути, чтобы сделать его для цензуры неотличимым от других видов трафика [Tor-2019]. Для этих методов будет полезна работа сообщества разработчиков стандартов Internet.

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

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

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

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

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

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

[AFNIC-2013] AFNIC, “Report of the AFNIC Scientific Council: Consequences of DNS-based Internet filtering”, January 2013, <http://www.afnic.fr/medias/documents/conseilscientifique/SC-consequences-of-DNS-based-Internet-filtering.pdf>.

[AFP-2014] AFP, “China Has Massive Internet Breakdown Reportedly Caused By Their Own Censoring Tools”, January 2014, <http://www.businessinsider.com/chinas-internet-breakdown-reportedly-caused-by-censoring-tools-2014-1>.

[Albert-2011] Albert, K., “DNS Tampering and the new ICANN gTLD Rules”, June 2011, <https://opennet.net/blog/2011/06/dns-tampering-and-new-icann-gtld-rules>.

[Anon-SIGCOMM12] Anonymous, “The Collateral Damage of Internet Censorship by DNS Injection”, July 2012, <http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf>.

[Anonymous-2013] Anonymous, “GitHub blocked in China – how it happened, how to get around it, and where it will take us”, January 2013, <https://en.greatfire.org/blog/2013/jan/github-blocked-china-how-it-happened-how-get-around-it-and-where-it-will-take-us>.

[Anonymous-2014] Anonymous, “Towards a Comprehensive Picture of the Great Firewall’s DNS Censorship”, August 2014, <https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf>.

[Aryan-2013] Aryan, S., Aryan, H., and J. A. Halderman, “Internet Censorship in Iran: A First Look”, 2012, <https://jhalderm.com/pub/papers/iran-foci13.pdf>.

[BBC-2013] BBC News, “Google and Microsoft agree steps to block abuse images”, November 2013, <http://www.bbc.com/news/uk-24980765>.

[BBC-2013b] BBC, “China employs two million microblog monitors state media say”, 2013, <https://www.bbc.com/news/world-asia-china-24396957>.

[Bock-2019] Bock, K., Hughey, G., Qiang, X., and D. Levin, “Geneva: Evolving Censorship Evasion Strategies”, DOI 10.1145/3319535.3363189, November 2019, <https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf>.

[Bock-2020] Bock, K., Fax, Y., Reese, K., Singh, J., and D. Levin, “Detecting and Evading Censorship-in-Depth: A Case Study of Iran’s Protocol Filter”, January 2020, <https://geneva.cs.umd.edu/papers/evading-censorship-in-depth.pdf>.

[Bock-2020b] Bock, K., iyouport, Anonymous, Merino, L-H., Fifield, D., Houmansadr, A., and D. Levin, “Exposing and Circumventing China’s Censorship of ESNI”, August 2020, <https://geneva.cs.umd.edu/posts/china-censors-esni/esni/>.

[Bock-2021] Bock, K., Bharadwaj, P., Singh, J., and D. Levin, “Your Censor is My Censor: Weaponizing Censorship Infrastructure for Availability Attacks”, DOI 10.1109/SPW53761.2021.00059, May 2021, <https://geneva.cs.umd.edu/papers/woot21-weaponizing-availability.pdf>.

[Bock-2021b] Bock, K., Naval, G., Reese, K., and D. Levin, “Even Censors Have a Backup: Examining China’s Double HTTPS Censorship Middleboxes”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 1-7, DOI 10.1145/3473604.3474559, August 2021, <https://geneva.cs.umd.edu/papers/foci21.pdf>.

[Bortzmeyer-2015] Bortzmeyer, S., “DNS Censorship (DNS Lies) As Seen By RIPE Atlas”, December 2015, <https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes>.

[Boyle-1997] Boyle, J., “Foucault in Cyberspace: Surveillance, Sovereignty, and Hardwired Censors”, 66 University of Cincinnati Law Review 177-205, 1997, <https://scholarship.law.duke.edu/faculty_scholarship/619/>.

[Cao-2016] Cao, Y., Qian, Z., Wang, Z., Dao, T., Krishnamurthy, S., and L. Marvel, “Off-Path TCP Exploits: Global Rate Limit Considered Dangerous”, August 2016, <https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf>.

[CERT-2000] CERT, “CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks”, 2000, <https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-21+TCP+SYN+Flooding+and+IP+Spoofing+Attacks>.

[Chai-2019] Chai, Z., Ghafari, A., and A. Houmansadr, “On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention”, 2019, <https://www.usenix.org/system/files/foci19-paper_chai_update.pdf>.

[Cheng-2010] Cheng, J., “Google stops Hong Kong auto-redirect as China plays hardball”, June 2010, <http://arstechnica.com/tech-policy/2010/06/google-tweaks-china-to-hong-kong-redirect-same-results/>.

[Cimpanu-2019] Cimpanu, C., “Russia to disconnect from the internet as part of a planned test”, February 2019, <https://www.zdnet.com/article/russia-to-disconnect-from-the-internet-as-part-of-a-planned-test/>.

[CitizenLab-2018] Marczak, B., Dalek, J., McKune, S., Senft, A., Scott-Railton, J., and R. Deibert, “Bad Traffic: Sandvine’s PacketLogic Devices Used to Deploy Government Spyware in Turkey and Redirect Egyptian Users to Affiliate Ads?”, March 2018, <https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/>.

[Clayton-2006] Clayton, R., Murdoch, S.J., and R.N.M. Watson, “Ignoring the Great Firewall of China”, Lecture Notes in Computer Science, Volume 4258, DOI 10.1007/11957454_2, 2006, <https://link.springer.com/chapter/10.1007/11957454_2>.

[Condliffe-2013] Condliffe, J., “Google Announces Massive New Restrictions on Child Abuse Search Terms”, November 2013, <http://gizmodo.com/google-announces-massive-new-restrictions-on-child-abus-1466539163>.

[Cowie-2011] Cowie, J., “Egypt Leaves The Internet”, NANOG 51, February 2011, <https://archive.nanog.org/meetings/nanog51/presentations/Tuesday/LT-Cowie-Egypt%20Leaves%20The%20Internet.pdf>.

[Crandall-2010] Park, J.C. and J. Crandall, “Empirical Study of a National-Scale Distributed Intrusion Detection System: Backbone-Level Filtering of HTML Responses in China”, June 2010, <http://www.cs.unm.edu/~crandall/icdcs2010.pdf>.

[Dada-2017] Dada, T. and P. Micek, “Launching STOP: the #KeepItOn internet shutdown tracker”, September 2017, <https://www.accessnow.org/keepiton-shutdown-tracker/>.

[Dalek-2013] Dalek, J., Haselton, B., Noman, H., Senft, A., Crete-Nishihata, M., Gill, P., and R. J. Deibert, “A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship”, IMC ’13: Proceedings of the 2013 conference on Internet measurement conference, Pages 23-30, DOI 10.1145/2504730.2504763, October 2013, <http://conferences.sigcomm.org/imc/2013/papers/imc112s-dalekA.pdf>.

[Ding-1999] Ding, C., Chi, C. H., Deng, J., and C. L. Dong, “Centralized Content-Based Web Filtering and Blocking: How Far Can It Go?”, IEEE SMC’99 Conference Proceedings, DOI 10.1109/ICSMC.1999.825218, October 1999, <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.3302&rep=rep1&type=pdf>.

[DMLP-512] Digital Media Law Project, “Protecting Yourself Against Copyright Claims Based on User Content”, May 2012, <https://www.dmlp.org/legal-guide/protecting-yourself-against-copyright-claims-based-user-content>.

[Dobie-2007] Dobie, M., “Junta tightens media screw”, BBC News, September 2007, <http://news.bbc.co.uk/2/hi/asia-pacific/7016238.stm>.

[EC-2012] European Commission, “Summary of the results of the Public Consultation on the future of electronic commerce in the Internal Market and the implementation of the Directive on electronic commerce (2000/31/EC)”, January 2012, <https://ec.europa.eu/information_society/newsroom/image/document/2017-4/consultation_summary_report_en_2010_42070.pdf>.

[EC-gambling-2012] European Commission, “Online gambling in the Internal Market Accompanying the document Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions Towards a comprehensive framework for online gambling”, 2012, <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52012SC0345>.

[EC-gambling-2019] European Commission, “Evaluation of regulatory tools for enforcing online gambling rules and channelling demand towards controlled offers”, January 2019, <https://ec.europa.eu/growth/content/evaluation-regulatory-tools-enforcing-online-gambling-rules-and-channelling-demand-towards-1_en>.

[EFF-2017] Malcom, J., Rossi, G., and M. Stoltz, “Which Internet registries offer the best protection for domain owners?”, Electronic Frontier Foundation, July 2017, <https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.pdf>.

[ekr-2021] Rescorla, E., “Overview of Apple’s Client-side CSAM Scanning”, August 2021, <https://educatedguesswork.org/posts/apple-csam-intro/>.

[Elmenhorst-2021] Elmenhorst, K., Schuetz, B., Aschenbruck, N., and S. Basso, “Web Censorship Measurements of HTTP/3 over QUIC”, IMC ’21: Proceedings of the 21st ACM Internet Measurement Conference, Pages 276-282, DOI 10.1145/3487552.3487836, November 2021, <https://dl.acm.org/doi/pdf/10.1145/3487552.3487836>.

[Elmenhorst-2022] Elmenhorst, K., “A Quick Look at QUIC Censorship”, April 2022, <https://www.opentech.fund/news/a-quick-look-at-quic/>.

[Eneman-2010] Eneman, M., “Internet service provider (ISP) filtering of child-abusive material: A critical reflection of its effectiveness”, DOI 10.1080/13552601003760014, June 2010, <https://www.tandfonline.com/doi/abs/10.1080/13552601003760014>.

[Ensafi-2013] Ensafi, R., Knockel, J., Alexander, G., and J.R. Crandall, “Detecting Intentional Packet Drops on the Internet via TCP/IP Side Channels: Extended Version”, DOI 10.48550/arXiv.1312.5739, December 2013, <http://arxiv.org/pdf/1312.5739v1.pdf>.

[Fifield-2015] Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. Paxson, “Blocking-resistant communication through domain fronting”, DOI 10.1515/popets-2015-0009, May 2015, <https://petsymposium.org/2015/papers/03_Fifield.pdf>.

[Gatlan-2019] Gatlan, S., “South Korea is Censoring the Internet by Snooping on SNI Traffic”, February 2019, <https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/>.

[Gilad] Gilad, Y. and A. Herzberg, “Off-Path TCP Injection Attacks”, ACM Transactions on Information and System Security, Volume 16, Issue 4, Article No.: 13, pp. 1-32, DOI 10.1145/2597173, April 2014, <https://doi.org/10.1145/2597173>.

[Glanville-2008] Glanville, J., “The big business of net censorship”, The Guardian, November 2008, <http://www.theguardian.com/commentisfree/2008/nov/17/censorship-internet>.

[Google-2018] “Google Cloud Networking Incident #18018”, November 2018, <https://status.cloud.google.com/incident/cloud-networking/18018>.

[Google-RTBF] Google, Inc., “Search removal request under data protection law in Europe”, 2015, <https://support.google.com/legal/contact/lr_eudpa?product=websearch>.

[Grover-2019] Grover, G., Singh, K., and E. Hickok, Ed., “Reliance Jio is using SNI inspection to block websites”, November 2019, <https://cis-india.org/internet-governance/blog/reliance-jio-is-using-sni-inspection-to-block-websites>.

[HADOPI] Hadopi, “Hadopi | Haute Autorité pour la diffusion des oeuvres et la protection des droits sur internet”, <https://www.hadopi.fr/>.

[Halley-2008] Halley, B., “How DNS cache poisoning works”, October 2008, <https://www.networkworld.com/article/2277316/tech-primers/tech-primers-how-dns-cache-poisoning-works.html>.

[Heacock-2009] Heacock, R., “China shuts down Internet in Xinjiang region after riots”, OpenNet Initiative, July 2009, <https://opennet.net/blog/2009/07/china-shuts-down-internet-xinjiang-region-after-riots>.

[Hepting-2011] Wikipedia, “Hepting v. AT&T”, September 2023, <https://en.wikipedia.org/wiki/Hepting_v._AT%26T&oldid=1175143505>.

[Hertel-2015] Hertel, O., “Comment les autorités peuvent bloquer un site Internet” [How authorities can block a website], March 2015, <https://www.sciencesetavenir.fr/high-tech/comment-les-autorites-peuvent-bloquer-un-site-internet_35828>.

[Hjelmvik-2010] Hjelmvik, E. and W. John, “Breaking and Improving Protocol Obfuscation”, Technical Report No. 2010-05, ISSN 1652-926X, July 2010, <https://www.iis.se/docs/hjelmvik_breaking.pdf>.

[Husak-2016] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, “HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting”, DOI 10.1186/s13635-016-0030-7, February 2016, <https://link.springer.com/article/10.1186/s13635-016-0030-7>.

[ICANN-2012] ICANN Security and Stability Advisory Committee, “Guidance for Preparing Domain Name Orders, Seizures & Takedowns”, January 2012, <https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf>.

[ICANN-SSAC-2012] ICANN Security and Stability Advisory Committee (SSAC), “SAC 056: SSAC Advisory on Impacts of Content Blocking via the Domain Name System”, October 2012, <https://www.icann.org/en/system/files/files/sac-056-en.pdf>.

[Jones-2014] Jones, B., Lee, T-W., Feamster, N., and P. Gill, “Automated Detection and Fingerprinting of Censorship Block Pages”, IMC ’14: Proceedings of the 2014 Conference on Internet Measurement Conference, Pages 299-304, DOI 10.1145/2663716.2663722, November 2014, <http://conferences2.sigcomm.org/imc/2014/papers/p299.pdf>.

[Khattak-2013] Khattak, S., Javed, M., Anderson, P.D., and V. Paxson, “Towards Illuminating a Censorship Monitor’s Model to Facilitate Evasion”, August 2013, <http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12389-foci13-khattak.pdf>.

[Knight-2005] Knight, W., “Iranian net censorship powered by US technology”, June 2005, <https://www.newscientist.com/article/dn7589-iranian-net-censorship-powered-by-us-technology/>.

[Knockel-2021] Knockel, J. and L. Ruan, “Measuring QQMail’s automated email censorship in China”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 8-15, DOI 10.1145/3473604.3474560, April 2021, <https://dl.acm.org/doi/10.1145/3473604.3474560>.

[Kravtsova-2012] Kravtsova, Y., “Cyberattacks Disrupt Opposition’s Election”, The Moscow Times, October 2012, <http://www.themoscowtimes.com/news/article/cyberattacks-disrupt-oppositions-election/470119.html>.

[Leyba-2019] Leyba, K., Edwards, B., Freeman, C., Crandall, J., and S. Forrest, “Borders and gateways: measuring and analyzing national as chokepoints”, COMPASS ’19: Proceedings of the 2nd ACM SIGCAS Conference on Computing and Sustainable Societies, pages 184-194, DOI 10.1145/3314344.3332502, July 2019, <https://doi.org/10.1145/3314344.3332502>.

[Li-2017] Li, F., Razaghpanah, A., Molavi Kakhki, A., Akhavan Niaki, A., Choffnes, D., Gill, P., and A. Mislove, “lib•erate, (n): a library for exposing (traffic-classification) rules and avoiding them efficiently”, DOI 10.1145/3131365.3131376, November 2017, <https://david.choffnes.com/pubs/liberate-imc17.pdf>.

[Lomas-2019] Lomas, N., “Github removes Tsunami Democràtic’s APK after a takedown order from Spain”, October 2019, <https://techcrunch.com/2019/10/30/github-removes-tsunami-democratics-apk-after-a-takedown-order-from-spain/>.

[Marczak-2015] Marczak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, “An Analysis of China’s “Great Cannon””, August 2015, <https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.pdf>.

[Muncaster-2013] Muncaster, P., “Malaysian election sparks web blocking/DDoS claims”, The Register, May 2013, <http://www.theregister.co.uk/2013/05/09/malaysia_fraud_elections_ddos_web_blocking/>.

[Murdoch-2008] Murdoch, S. J. and R. Anderson, “Tools and Technology of Internet Filtering” in “Access Denied: The Practice and Policy of Global Internet Filtering”, DOI 10.7551/mitpress/7617.003.0006, 2008, <https://doi.org/10.7551/mitpress/7617.003.0006>.

[NA-SK-2019] Morgus, R., Sherman, J., and S. Nam, “Analysis: South Korea’s New Tool for Filtering Illegal Internet Content”, March 2019, <https://www.newamerica.org/cybersecurity-initiative/c2b/c2b-log/analysis-south-koreas-sni-monitoring/>.

[Nabi-2013] Nabi, Z., “The Anatomy of Web Censorship in Pakistan”, August 2013, <http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12387-foci13-nabi.pdf>.

[NBC-2014] NBC News, “Exclusive: Snowden Docs Show UK Spies Attacked Anonymous, Hackers”, February 2014, <http://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361>.

[Netsec-2011] n3t2.3c, “TCP-RST Injection”, October 2011, <https://nets.ec/TCP-RST_Injection>.

[OONI-2018] Evdokimov, L., “Iran Protests: DPI blocking of Instagram (Part 2)”, February 2018, <https://ooni.org/post/2018-iran-protests-pt2/>.

[OONI-2019] Singh, S., Filastò, A., and M. Xynou, “China is now blocking all language editions of Wikipedia”, May 2019, <https://ooni.org/post/2019-china-wikipedia-blocking/>.

[Orion-2013] Orion, E., “Zimbabwe election hit by hacking and DDoS attacks”, Wayback Machine archive, August 2013, <https://web.archive.org/web/20130825010947/http://www.theinquirer.net/inquirer/news/2287433/zimbabwe-election-hit-by-hacking-and-ddos-attacks>.

[Patil-2019] Patil, S. and N. Borisov, “What can you learn from an IP?”, Proceedings of the Applied Networking Research Workshop, Pages 45-51, DOI 10.1145/3340301.3341133, July 2019, <https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf>.

[Porter-2005] Porter, T., “The Perils of Deep Packet Inspection”, 2010, <http://www.symantec.com/connect/articles/perils-deep-packet-inspection>.

[Rambert-2021] Rampert, R., Weinberg, Z., Barradas, D., and N. Christin, “Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China”, DOI 10.1145/3442381.3450076, April 2021, <https://www.andrew.cmu.edu/user/nicolasc/publications/Rambert-WWW21.pdf>.

[Reda-2017] Reda, F., “New EU law prescribes website blocking in the name of “consumer protection””, November 2017, <https://felixreda.eu/2017/11/eu-website-blocking/>.

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

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, “Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement”, RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, “Technical Considerations for Internet Service Blocking and Filtering”, RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

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

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

[RFC8744] Huitema, C., “Issues and Requirements for Server Name Identification (SNI) Encryption in TLS”, RFC 8744, DOI 10.17487/RFC8744, July 2020, <https://www.rfc-editor.org/info/rfc8744>.

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

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

[Rushe-2014] Rushe, D., “Bing censoring Chinese language search results for users in the US”, The Guardian, February 2014, <http://www.theguardian.com/technology/2014/feb/11/bing-censors-chinese-language-search-results>.

[RWB-2020] Reporters Without Borders (RSF), “2020 World Press Freedom Index: ‘Entering a decisive decade for journalism, exacerbated by coronavirus'”, April 2020, <https://rsf.org/en/2020-world-press-freedom-index-entering-decisive-decade-journalism-exacerbated-coronavirus>.

[Sandvine-2015] Sandvine, “Internet Traffic Classification: A Sandvine Technology Showcase”, 2015, <https://www.researchgate.net/profile/Nirmala-Svsg/post/Anybody-working-on-Internet-traffic-classification/attachment/59d63a5779197b807799782d/AS%3A405810988503040%401473764287142/download/traffic-classification-identifying-and-measuring-internet-traffic.pdf>.

[Satija-2021] Satija, S. and R. Chatterjee, “BlindTLS: Circumventing TLS-based HTTPS censorship”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 43-49, DOI 10.1145/3473604.3474564, August 2021, <https://sambhav.info/files/blindtls-foci21.pdf>.

[Schoen-2007] Schoen, S., “EFF tests agree with AP: Comcast is forging packets to interfere with user traffic”, October 2007, <https://www.eff.org/deeplinks/2007/10/eff-tests-agree-ap-comcast-forging-packets-to-interfere>.

[Senft-2013] Crete-Nishihata, M., Dalek, J., Hardy, S., Hilts, A., Kleemola, K., Ng, J., Poetranto, I., Senft, A., Sinpeng, A., Sonne, B., and G. Wiseman, “Asia Chats: Analyzing Information Controls and Privacy in Asian Messaging Applications”, November 2013, <https://citizenlab.org/2013/11/asia-chats-analyzing-information-controls-privacy-asian-messaging-applications/>.

[Shbair-2015] Shbair, W. M., Cholez, T., Goichot, A., and I. Chrisment, “Efficiently Bypassing SNI-based HTTPS Filtering”, May 2015, <https://hal.inria.fr/hal-01202712/document>.

[Siddiqui-2022] Siddiqui, A., “Lesson Learned: Twitter Shored Up Its Routing Security”, March 2022, <https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/>.

[SIDN-2020] Moura, G., “Detecting and Taking Down Fraudulent Webshops at the .nl ccTLD”, February 2020, <https://labs.ripe.net/Members/giovane_moura/detecting-and-taking-down-fraudulent-webshops-at-a-cctld>.

[Singh-2019] Singh, K., Grover, G., and V. Bansal, “How India Censors the Web”, DOI 10.48550/arXiv.1912.08590, December 2019, <https://arxiv.org/abs/1912.08590>.

[Sophos-2023] Sophos, “Sophos Firewall: Web filtering basics”, 2023, <https://support.sophos.com/support/s/article/KB-000036518?language=en_US>.

[SSAC-109-2020] ICANN Security and Stability Advisory Committee (SSAC), “SAC109: The Implications of DNS over HTTPS and DNS over TLS”, March 2020, <https://www.icann.org/en/system/files/files/sac-109-en.pdf>.

[Tang-2016] Tang, C., “In-depth analysis of the Great Firewall of China”, December 2016, <https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf>.

[Thomson-2012] Thomson, I., “Syria cuts off internet and mobile communication”, The Register, November 2012, <http://www.theregister.co.uk/2012/11/29/syria_internet_blackout/>.

[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, “TLS Encrypted Client Hello”, Work in Progress, Internet-Draft, draft-ietf-tls-esni-17, 9 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-17>.

[Tor-2019] Tor, “Tor: Pluggable Transports”, 2019, <https://2019.www.torproject.org/docs/pluggable-transports.html.en>.

[Trustwave-2015] Trustwave, “Filter : SNI extension feature and HTTPS blocking”, 2015, <https://www3.trustwave.com/software/8e6/hlp/r3000/files/1system_filter.html>.

[Tschantz-2016] Tschantz, M., Afroz, S., Anonymous, and V. Paxson, “SoK: Towards Grounding Censorship Circumvention in Empiricism”, DOI 10.1109/SP.2016.59, May 2016, <https://oaklandsok.github.io/papers/tschantz2016.pdf>.

[Van-der-Sar-2007] Van der Sar, E., “How To Bypass Comcast’s BitTorrent Throttling”, October 2012, <https://torrentfreak.com/how-to-bypass-comcast-bittorrent-throttling-071021>.

[Verkamp-2012] Verkamp, J. P. and M. Gupta, “Inferring Mechanics of Web Censorship Around the World”, August 2012, <https://www.usenix.org/system/files/conference/foci12/foci12-final1.pdf>.

[Victor-2019] Victor, D., “Blizzard Sets Off Backlash for Penalizing Hearthstone Gamer in Hong Kong”, The New York Times, October 2019, <https://www.nytimes.com/2019/10/09/world/asia/blizzard-hearthstone-hong-kong.html>.

[Villeneuve-2011] Villeneuve, N. and M. Crete-Nishihata, “Open Access: Chapter 8, Control and Resistance, Attacks on Burmese Opposition Media”, January 2011, <http://access.opennet.net/wp-content/uploads/2011/12/accesscontested-chapter-08.pdf>.

[VonLohmann-2008] VonLohmann, F., “FCC Rules Against Comcast for BitTorrent Blocking”, August 2008, <https://www.eff.org/deeplinks/2008/08/fcc-rules-against-comcast-bit-torrent-blocking>.

[Wagner-2009] Wagner, B., “Deep Packet Inspection and Internet Censorship: International Convergence on an ‘Integrated Technology of Control'”, Global Voices Advocacy, 2009, <http://advocacy.globalvoicesonline.org/wp-content/uploads/2009/06/deeppacketinspectionandinternet-censorship2.pdf>.

[Wagstaff-2013] Wagstaff, J., “In Malaysia, online election battles take a nasty turn”, NBC News, May 2013, <https://www.nbcnews.com/tech/tech-news/malaysia-online-election-battles-take-nasty-turn-flna6c9783842>.

[Wang-2017] Wang, Z., Cao, Y., Qian, Z., Song, C., and S.V. Krishnamurthy, “Your State is Not Mine: A Closer Look at Evading Stateful Internet Censorship”, DOI 10.1145/3131365.3131374, November 2017, <https://www.cs.ucr.edu/~zhiyunq/pub/imc17_censorship_tcp.pdf>.

[Wang-2020] Wang, Z., Zhu, S., Cao, Y., Qian, Z., Song, C., Krishnamurthy, S.V., Chan, K.S., and T.D. Braun, “SYMTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery”, DOI 10.14722/ndss.2020.24083, February 2020, <https://www.cs.ucr.edu/~zhiyunq/pub/ndss20_symtcp.pdf>.

[Weaver-2009] Weaver, N., Sommer, R., and V. Paxson, “Detecting Forged TCP Reset Packets”, September 2009, <http://www.icir.org/vern/papers/reset-injection.ndss09.pdf>.

[Whittaker-2013] Whittaker, Z., “1,168 keywords Skype uses to censor, monitor its Chinese users”, March 2013, <http://www.zdnet.com/1168-keywords-skype-uses-to-censor-monitor-its-chinese-users-7000012328/>.

[Wikip-DoS] Wikipedia, “Denial-of-service attack”, March 2016, <https://en.wikipedia.org/w/index.php?title=Denial-of-service_attack&oldid=710558258>.

[Wilde-2012] Wilde, T., “Knock Knock Knockin’ on Bridges Doors”, The Tor Project, July 2012, <https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors>.

[Winter-2012] Winter, P. and S. Lindskog, “How China Is Blocking Tor”, April 2012, <http://arxiv.org/pdf/1204.0447v1.pdf>.

[WP-Def-2020] Wikipedia, “Censorship”, March 2020, <https://en.wikipedia.org/w/index.php?title=Censorship&oldid=943938595>.

[Wright-2013] Wright, J. and Y. Breindl, “Internet filtering trends in liberal democracies: French and German regulatory debates”, DOI 10.14763/2013.2.122, April 2013, <https://policyreview.info/articles/analysis/internet-filtering-trends-liberal-democracies-french-and-german-regulatory-debates>.

[Zhu-2011] Zhu, T., Bronk, C., and D.S. Wallach, “An Analysis of Chinese Search Engine Filtering”, DOI 10.48550/arXiv.1107.3794, July 2011, <http://arxiv.org/ftp/arxiv/papers/1107/1107.3794.pdf>.

[Zmijewski-2014] Zmijewski, E., “Turkish Internet Censorship Takes a New Turn”, Wayback Machine archive, March 2014, <http://web.archive.org/web/20200726222723/ https://blogs.oracle.com/internetintelligence/turkish-internet-censorship-takes-a-new-turn>.

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

В работе над документом принимали участие David Belson, Stéphane Bortzmeyer, Vinicius Fortuna, Gurshabad Grover, Andrew McConachie, Martin Nilsson, Michael Richardson, Patrick Vacek, Chris Wood.

Соавтор документа Hall работал над документом до прихода в Internet Society и вовлеченность в эту организацию указана лишь для идентификации.

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

Joseph Lorenzo Hall
Internet Society
Email: hall@isoc.org
 
Michael D. Aaron
CU Boulder
Email: michael.drew.aaron@gmail.com
 
Amelia Andersdotter
Email: amelia.ietf@andersdotter.cc
 
Ben Jones
Email: ben.jones.irtf@gmail.com
 
Nick Feamster
U Chicago
Email: feamster@uchicago.edu
 
Mallory Knodel
Center for Democracy & Technology
Email: mknodel@cdt.org

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

nmalykh@protokols.ru


1Internet Research Task Force – комиссия по исследовательским задачам Internet.

2Этот адрес из блока, зарезервированного для документации, см. RFC 6890. Прим. перев.

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

RFC 9403 A YANG Data Model for RIB Extensions

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9403                       LabN Consulting, L.L.C.
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                   Futurewei Technologies
                                                           November 2023

A YANG Data Model for RIB Extensions

Модель данных YANG для расширений RIB

PDF

Аннотация

База маршрутной информации (Routing Information Base или RIB) – это список маршрутов и соответствующих административных данных и административного состояния.

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

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

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

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

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

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

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. Введение

Этот документ задаёт модель данных YANG [RFC7950] расширяющую модель данных RIB из модуля YANG ietf-routing [RFC8349] дополнительными атрибутами маршрутов.

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

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

Рассматриваемые в документе модули YANG соответствуют архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

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

В [RFC8342] определены термины:

  • configuration – конфигурация;

  • system state – состояние системы;

  • operational state – рабочее состояние.

В [RFC7950] определены термины:

  • action – действие;

  • augment – дополнение;

  • container – контейнер;

  • container with presence3 – контейнер присутствия;

  • data model – модель данных;

  • data node – узел данных;

  • leaf – лист;

  • list – список;

  • mandatory node – обязательный узел;

  • module – модуль;

  • schema tree – дерево схемы.

В параграфе 5.2 [RFC8349] определён термин RIB.

2.1. Диаграммы деревьев

Деревья в этом документе представлены в нотации [RFC8340].

2.2. Префиксы в именах узлов данных

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

Таблица : Префиксы и соответствующие им модули YANG.

 

Префикс

Модуль YANG

Документ

if

ietf-interfaces

[RFC8343]

rt

ietf-routing

[RFC8349]

v4ur

ietf-ipv4-unicast-routing

[RFC8349]

v6ur

ietf-ipv6-unicast-routing

[RFC8349]

inet

ietf-inet-types

[RFC6991]

ospf

ietf-ospf

[RFC9129]

isis

ietf-isis

[RFC9130]

 

3. Устройство модели

Заданный в этом документе модуль YANG дополняет модули ietf-routing, ietf-ipv4-unicast-routing и ietf-ipv6-unicast-routing, определённые в [RFC8349] и обеспечивающие базу для определения модели данных системы маршрутизации. Вместе с модулем ietf-routing и другими модулями YANG из [RFC8349], базовая модель данных YANG RIB, определённая здесь, служит для реализации и мониторинга RIB.

Модули из [RFC8349] также задают базовую конфигурацию и рабочее состояние для статических маршрутов IPv4 и IPv6. Этот документ задаёт дополнения для статических маршрутов, поддерживающие несколько next hop и дополнительные атрибуты next-hop.

3.1. Теги и предпочтения

Отдельные маршрутные теги поддерживаются как на уровне маршрута, так и на уровне next-hop. Для выбора предпочтительного статического маршрута следующего узла поддерживаются предпочтения по next hop. Ниже приведено дерево с тегамии и предпочтения, дополняющими следующий интервал статических индивидуальных маршрутов IPv4 и IPv6.

     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
             /v4ur:route/v4ur:next-hop/v4ur:next-hop-options
             /v4ur:simple-next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
             /v4ur:route/v4ur:next-hop/v4ur:next-hop-options
             /v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v6ur:ipv6
             /v6ur:route/v6ur:next-hop/v6ur:next-hop-options
             /v6ur:simple-next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v6ur:ipv6
             /v6ur:route/v6ur:next-hop/v6ur:next-hop-options
             /v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
       +--ro metric?            uint32
       +--ro tag*               uint32
       +--ro application-tag?   uint32

3.2. Ремонтный путь

Расчёт быстрой перемаршрутизации (IP Fast Reroute или IPFRR) протоколом маршрутизации заранее определяет ремонтные пути [RFC5714] и эти пути помещаются в RIB.

Следующий узел (next hop) каждого маршрута в RIB дополняется ремонтным путём, как показано ниже.

     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
             /rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
       +--ro repair-path
          +--ro outgoing-interface?   if:interface-state-ref
          +--ro next-hop-address?     inet:ip-address-no-zone
          +--ro metric?               uint32
     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
             /rt:next-hop/rt:next-hop-options/rt:next-hop-list
             /rt:next-hop-list/rt:next-hop:
       +--ro repair-path
          +--ro outgoing-interface?   if:interface-state-ref
          +--ro next-hop-address?     inet:ip-address-no-zone
          +--ro metric?               uint32

4. Дерево модели RIB

Дерево модуля ietf-routing.yang с дополнениями этого документа приведено в Приложении A с нотацией [RFC8340].

5. Модуль YANG RIB Extension

Этот модуль YANG ссылается на [RFC6991], [RFC8343], [RFC8349], [RFC9129], [RFC9130], [RFC5714].

   <CODE BEGINS> file "ietf-rib-extension@2023-11-20.yang"
   module ietf-rib-extension {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension";
     prefix rib-ext;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }
     import ietf-ipv4-unicast-routing {
       prefix v4ur;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }
     import ietf-ipv6-unicast-routing {
       prefix v6ur;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }

     import ietf-ospf {
       prefix ospf;
       reference "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     import ietf-isis {
       prefix isis;
       reference "RFC 9130: YANG Data Model for the IS-IS Protocol";
     }

     organization
       "IETF RTGWG (Routing Area Working Group)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/rtgwg/> 
        WG List:  <mailto:rtgwg@ietf.org> 

        Author:   Acee Lindem
                  <mailto:acee.ietf@gmail.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.qu@futurewei.com>"; 
     description
       "Этот модуль YANG расширяет RIB из модуля YANG ietf-routing
        дополнительными атрибутами маршрутов.

        Модуль YANG соответствует архитектуре NMDA (RFC 8342).

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

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

        Эта версия данного модуля YANG является частью RFC 9403, где
        правовые вопросы рассмотрены более полно.";

     revision 2023-11-20 {
       description
         "Исходная версия.";
       reference
         "RFC 9403: A YANG Data Model for RIB Extensions";
     }

     /* Группировки */

     grouping rib-statistics {
       description
         "Статистика, применяемая для дополнения RIB.";
       container statistics {
         config false;
         description
           "Контейнер для статистики RIB.";
         leaf total-routes {
           type uint32;
           description
             "Полное число маршрутов в RIB.";
         }
         leaf total-active-routes {
           type uint32;
           description
             "Полное число активных маршрутов в RIB. Активными считаются
              маршруты, имеющие предпочтение перед другими маршрутами к
              тому же префиксу получателей.";
         }
         leaf total-route-memory {
           type uint64;
           units "bytes";
           description
             "Память для всех маршрутов RIB.";
         }
         list protocol-statistics {
           description
             "Статистика RIB для протоколов маршрутизации, помещающих
              маршруты в RIB.";
           leaf protocol {
             type identityref {
               base rt:routing-protocol;
             }
             description
               "Протокол маршрутизации, помещающий маршруты в RIB.";
           }
           leaf routes {
             type uint32;
             description
               "Полное число маршрутов в RIB для протокола 
                маршрутизации, указанного узлом protocol.";
           }
           leaf active-routes {
             type uint32;
             description
               "Полное число активных маршрутов в RIB для протокола
                маршрутизации, указанного узлом protocol. Активными 
                считаются маршруты, имеющие предпочтение перед другими 
                маршрутами к тому же префиксу получателей.";
           }
           leaf route-memory {
             type uint64;
             units "bytes";
             description
               "Память для всех маршрутов в RIB для протокола
                маршрутизации, указанного узлом protocol.";
           }
         }
       }
     }

     grouping repair-path {
       description
         "Группировка для ремонтного пути IP Fast Reroute (IPFRR).";
       container repair-path {
         description
           "IPFRR next-hop для ремонтного пути.";
         leaf outgoing-interface {
           type if:interface-state-ref;
           description
             "Имя выходного интерфейса.";
         }
         leaf next-hop-address {
           type inet:ip-address-no-zone;
           description
             "IP-адрес следующего узла.";
         }
         leaf metric {
           type uint32;
           description
             "Метрика ремонтного пути. Хотя этот путь является локальным
              и его метрика не анонсируется наружу, она полезна для
              поиска и устранения неполадок.";
         }
         reference
           "RFC 5714: IP Fast Reroute Framework";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
           + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
           + "v4ur:simple-next-hop" {
       description
         "Дополнение simple-next-hop в индивидуальном маршруте IPv4.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
           + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
           + "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop" {
       description
         "Дополнение конфигурации статического маршрута next-hop-list.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
           + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
           + "v6ur:simple-next-hop" {
       description
         "Дополнение simple-next-hop в индивидуальном маршруте IPv6.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
           + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
           + "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop" {
       description
         "Дополнение конфигурации статического маршрута next-hop-list.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib" {
       description
         "Добавление статистики в RIB.";
       uses rib-statistics;
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route" {
       description
         "Дополнение маршрута с базовыми атрибутами в RIB.";
       leaf metric {
         when "not(derived-from("
           + "../rt:source-protocol, 'ospf:ospf')) "
           + "and not(derived-from( "
           + "../rt:source-protocol, 'isis:isis'))" {
           description
             "Это дополнение действительно лишь для маршрутов, 
              полученных не от протоколов OSPF и IS-IS. Модели YANG
              для OSPF и IS-IS уже включают дополнение metric.";
         }
         type uint32;
         description
           "Метрика — целое число, указывающее стоимость маршрута с
            точки зрения установившего маршрут протокола маршрутизации.
            В общем случае меньшее значение метрики в рамках одного 
            протокола маршрутизации говорит о меньшей стоимости маршрута
            и его предпочтительности по сравнению с большей метрикой.
            Метрика разных протоколов маршрутизации не сравнима.";
       }
       leaf-list tag {
         when "not(derived-from("
           + "../rt:source-protocol, 'ospf:ospf')) "
           + "and not(derived-from( "
           + "../rt:source-protocol, 'isis:isis'))" {
           description
             "Это дополнение действительно лишь для маршрутов, 
              полученных не от протоколов OSPF и IS-IS. Модели YANG
              для OSPF и IS-IS уже включают дополнение tag.";
         }
         type uint32;
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
       leaf application-tag {
         type uint32;
         description
           "Связанный с приложением дополнительный тег, который может
            использоваться приложениями, требующими семантики и/или 
            правил, отличных от принятых для обычных тегов. Например, 
            тег обычно автоматически анонсируется в OSPF AS-External  
            LSA, а связанный с приложением тег не анонсируется неявно.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
           + "rt:simple-next-hop" {
       description
         "Добавление repair-path в simple-next-hop.";
       uses repair-path;
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
           + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
       description
         "Добавление ремонтного пути в next-hop.";
       uses repair-path;
     }
   }
   <CODE ENDS>

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В заданном здесь модуле ietf-rib-extension.yang определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:preference

/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:tag

/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop/rib-ext:preference

/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop/rib-ext:tag

/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:preference

/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:tag

/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop/rib-ext:preference

/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop/rib-ext:tag

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

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/rt:routing/rt:ribs/rt:rib/rib-ext:statistics

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metric

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:tag

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:application-tag

/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop/rib-ext:repair-path

/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop/rib-ext:repair-path

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

Соображения безопасности, рассмотренные в [RFC8349], применимы к расширениям, описанным здесь.

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

Этот документ регистрирует URI в IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-rib-extension
   Registrant Contact:  The IESG.
   XML:  N/A; регистрируемый URI является пространством имён XML.

Агентство IANA зарегистрировало указанный ниже подуль YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-rib-extension
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-rib-extension
   Prefix:  rib-ext
   Reference:  RFC 9403

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

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

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

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

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

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

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

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

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, “A YANG Data Model for Routing Management (NMDA Version)”, RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

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

[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, “YANG Data Model for the OSPF Protocol”, RFC 9129, DOI 10.17487/RFC9129, October 2022, <https://www.rfc-editor.org/info/rfc9129>.

[RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, “YANG Data Model for the IS-IS Protocol”, RFC 9130, DOI 10.17487/RFC9130, October 2022, <https://www.rfc-editor.org/info/rfc9130>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[RFC5714] Shand, M. and S. Bryant, “IP Fast Reroute Framework”, RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

Приложение A. Комбинированное дерево

Ниже представлено комбинированное дерево модулей ietf-routing.yang, ietf-ipv4-unicast-routing.yang, ietf-ipv6-unicast-routing.yang, ietf-rib-extension.yang.

   module: ietf-routing
     +--rw routing
     +--rw router-id?                 yang:dotted-quad {router-id}?
     +--ro interfaces
     |  +--ro interface*   if:interface-ref
     +--rw control-plane-protocols
     |  +--rw control-plane-protocol* [type name]
     |     +--rw type             identityref
     |     +--rw name             string
     |     +--rw description?     string
     |     +--rw static-routes
     |        +--rw v4ur:ipv4
     |        |  +--rw v4ur:route* [destination-prefix]
     |        |     +--rw v4ur:destination-prefix    inet:ipv4-prefix
     |        |     +--rw v4ur:description?          string
     |        |     +--rw v4ur:next-hop
     |        |        +--rw (v4ur:next-hop-options)
     |        |           +--:(v4ur:simple-next-hop)
     |        |           |  +--rw v4ur:outgoing-interface?
     |        |           |  |   if:interface-ref
     |        |           |  +--rw v4ur:next-hop-address?
     |        |           |  |   inet:ipv4-address
     |        |           |  +--rw rib-ext:preference?      uint32
     |        |           |  +--rw rib-ext:tag?             uint32
     |        |           +--:(v4ur:special-next-hop)
     |        |           |  +--rw v4ur:special-next-hop?   enumeration
     |        |           +--:(v4ur:next-hop-list)
     |        |              +--rw v4ur:next-hop-list
     |        |                 +--rw v4ur:next-hop* [index]
     |        |                    +--rw v4ur:index            string
     |        |                    +--rw v4ur:outgoing-interface?
     |        |                    |   if:interface-ref
     |        |                    +--rw v4ur:next-hop-address?
     |        |                    |   inet:ipv4-address
     |        |                    +--rw rib-ext:preference?   uint32
     |        |                    +--rw rib-ext:tag?          uint32
     |        +--rw v6ur:ipv6
     |           +--rw v6ur:route* [destination-prefix]
     |              +--rw v6ur:destination-prefix    inet:ipv6-prefix
     |              +--rw v6ur:description?          string
     |              +--rw v6ur:next-hop
     |                 +--rw (v6ur:next-hop-options)
     |                    +--:(v6ur:simple-next-hop)
     |                    |  +--rw v6ur:outgoing-interface?
     |                    |  |   if:interface-ref
     |                    |  +--rw v6ur:next-hop-address?
     |                    |  |   inet:ipv6-address
     |                    |  +--rw rib-ext:preference?      uint32
     |                    |  +--rw rib-ext:tag?             uint32
     |                    +--:(v6ur:special-next-hop)
     |                    |  +--rw v6ur:special-next-hop?   enumeration
     |                    +--:(v6ur:next-hop-list)
     |                       +--rw v6ur:next-hop-list
     |                          +--rw v6ur:next-hop* [index]
     |                             +--rw v6ur:index              string
     |                             +--rw v6ur:outgoing-interface?
     |                             |   if:interface-ref
     |                             +--rw v6ur:next-hop-address?
     |                             |   inet:ipv6-address
     |                             +--rw rib-ext:preference?     uint32
     |                             +--rw rib-ext:tag?            uint32
     +--rw ribs
        +--rw rib* [name]
           +--rw name                          string
           +--rw address-family                identityref
           +--ro default-rib?                  boolean {multiple-ribs}?
           +--ro routes
           |  +--ro route* []
           |     +--ro route-preference?       route-preference
           |     +--ro next-hop
           |     |  +--ro (next-hop-options)
           |     |     +--:(simple-next-hop)
           |     |     |  +--ro outgoing-interface?
           |     |     |  |   if:interface-ref
           |     |     |  +--ro v4ur:next-hop-address?
           |     |     |  |   inet:ipv4-address
           |     |     |  +--ro v6ur:next-hop-address?
           |     |     |  |   inet:ipv6-address
           |     |     |  +--ro rib-ext:repair-path
           |     |     |     +--ro rib-ext:outgoing-interface?
           |     |     |     |   if:interface-state-ref
           |     |     |     +--ro rib-ext:next-hop-address?
           |     |     |     |   inet:ip-address-no-zone
           |     |     |     +--ro rib-ext:metric?               uint32
           |     |     +--:(special-next-hop)
           |     |     |  +--ro special-next-hop?        enumeration
           |     |     +--:(next-hop-list)
           |     |        +--ro next-hop-list
           |     |           +--ro next-hop* []
           |     |              +--ro outgoing-interface?
           |     |              |   if:interface-ref
           |     |              +--ro v4ur:address?
           |     |              |   inet:ipv4-address
           |     |              +--ro v6ur:address?
           |     |              |   inet:ipv6-address
           |     |              +--ro rib-ext:repair-path
           |     |                 +--ro rib-ext:outgoing-interface?
           |     |                 |   if:interface-state-ref
           |     |                 +--ro rib-ext:next-hop-address?
           |     |                 |   inet:ip-address-no-zone
           |     |                 +--ro rib-ext:metric?         uint32
           |     +--ro source-protocol            identityref
           |     +--ro active?                    empty
           |     +--ro last-updated?              yang:date-and-time
           |     +--ro v4ur:destination-prefix?   inet:ipv4-prefix
           |     +--ro v6ur:destination-prefix?   inet:ipv6-prefix
           |     +--ro rib-ext:metric?            uint32
           |     +--ro rib-ext:tag*               uint32
           |     +--ro rib-ext:application-tag?   uint32
           +---x active-route
           |  +---w input
           |  |  +---w v4ur:destination-address?   inet:ipv4-address
           |  |  +---w v6ur:destination-address?   inet:ipv6-address
           |  +--ro output
           |     +--ro route
           |        +--ro next-hop
           |        |  +--ro (next-hop-options)
           |        |     +--:(simple-next-hop)
           |        |     |  +--ro outgoing-interface?
           |        |     |  |   if:interface-ref
           |        |     |  +--ro v4ur:next-hop-address?
           |        |     |  |   inet:ipv4-address
           |        |     |  +--ro v6ur:next-hop-address?
           |        |     |  |   inet:ipv6-address
           |        |     +--:(special-next-hop)
           |        |     |  +--ro special-next-hop?        enumeration
           |        |     +--:(next-hop-list)
           |        |        +--ro next-hop-list
           |        |           +--ro next-hop* []
           |        |              +--ro outgoing-interface?
           |        |              |   if:interface-ref
           |        |              +--ro v4ur:next-hop-address?
           |        |              |   inet:ipv4-address
           |        |              +--ro v6ur:next-hop-address?
           |        |              |   inet:ipv6-address
           |        +--ro source-protocol            identityref
           |        +--ro active?                    empty
           |        +--ro last-updated?              yang:date-and-time
           |        +--ro v4ur:destination-prefix?   inet:ipv4-prefix
           |        +--ro v6ur:destination-prefix?   inet:ipv6-prefix
           +--rw description?                        string
           +--ro rib-ext:statistics
              +--ro rib-ext:total-routes?              uint32
              +--ro rib-ext:total-active-routes?       uint32
              +--ro rib-ext:total-route-memory?        uint64
              +--ro rib-ext:protocol-statistics* []
                 +--ro rib-ext:protocol?             identityref
                 +--ro rib-ext:routes?    uint32
                 +--ro rib-ext:active-routes?   uint32
                 +--ro rib-ext:route-memory?    uint64

Приложение B. Пример ietf-rib-extension.yang

Ниже представлен пример XML [W3C.REC-xml-20081126] использующий модуль расширения RIB и RFC 8349. Символ \ в конце строки указывает перенос длинной строки [RFC8792].

   <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
     <control-plane-protocols>
       <control-plane-protocol>
         <type>static</type>
         <name>static-routing-protocol</name>
         <static-routes>
           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:\
             ietf-ipv4-unicast-routing">
             <route>
               <destination-prefix>0.0.0.0/0</destination-prefix>
               <next-hop>
                 <next-hop-address>192.0.2.2</next-hop-address>
                 <preference xmlns="urn:ietf:params:xml:ns:yang:\
                   ietf-rib-extension">30</preference>
                 <tag xmlns="urn:ietf:params:xml:ns:yang:\
                   ietf-rib-extension">99</tag>
               </next-hop>
             </route>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:\
             ietf-ipv6-unicast-routing">
             <route>
               <destination-prefix>::/0</destination-prefix>
               <next-hop>
                <next-hop-address>2001:db8:aaaa::1111</next-hop-address>
                <preference xmlns="urn:ietf:params:xml:ns:yang:\
                  ietf-rib-extension">30</preference>
                <tag xmlns="urn:ietf:params:xml:ns:yang:\
                  ietf-rib-extension">66</tag>
               </next-hop>
             </route>
           </ipv6>
         </static-routes>
       </control-plane-protocol>
     </control-plane-protocols>
     <ribs>
       <rib>
         <name>ipv4-primary</name>
         <address-family xmlns:v4ur="urn:ietf:params:xml:ns:yang:\
           ietf-ipv4-unicast-routing">v4ur:ipv4-unicast</address-family>
         <default-rib>true</default-rib>
         <routes>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv4-unicast-routing">0.0.0.0/0</destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>
             </next-hop>
             <route-preference>5</route-preference>
             <source-protocol>static</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv4-unicast-routing">198.51.100.0/24\
             </destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>
               <repair-path xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-rib-extension">
                 <next-hop-address>203.0.113.1</next-hop-address>
                 <metric>200</metric>
               </repair-path>
             </next-hop>
             <route-preference>120</route-preference>
             <source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
               ietf-rip">rip:rip</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
         </routes>
       </rib>
       <rib>
         <name>ipv6-primary</name>
         <address-family xmlns:v6ur="urn:ietf:params:xml:ns:yang:\
           ietf-ipv6-unicast-routing">v6ur:ipv6-unicast</address-family>
         <default-rib>true</default-rib>
         <routes>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv6-unicast-routing">0::/0</destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\
               </next-hop-address>
             </next-hop>
             <route-preference>5</route-preference>
             <source-protocol>static</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv6-unicast-routing">2001:db8:bbbb::/64\
             </destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\
               </next-hop-address>
               <repair-path xmlns="urn:ietf:params:xml:ns:yang:\
                ietf-rib-extension">
                <next-hop-address>2001:db8:cccc::2222</next-hop-address>
                <metric>200</metric>
               </repair-path>
             </next-hop>
             <route-preference>120</route-preference>
             <source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
               ietf-rip">rip:rip</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
         </routes>
       </rib>
     </ribs>
   </routing>

Ниже представлен тот же пример в формате JSON [RFC7951].

   {
    "ietf-routing:routing": {
      "control-plane-protocols": {
        "control-plane-protocol": [
          {
            "type": "static",
            "name": "static-routing-protocol",
            "static-routes": {
              "ietf-ipv4-unicast-routing:ipv4": {
                "route": [
                  {
                    "destination-prefix": "0.0.0.0/0",
                    "next-hop": {
                      "next-hop-address": "192.0.2.2",
                      "ietf-rib-extension:preference": 30,
                      "ietf-rib-extension:tag": 99
                    }
                  }
                ]
              },
              "ietf-ipv6-unicast-routing:ipv6": {
                "route": [
                  {
                    "destination-prefix": "::/0",
                    "next-hop": {
                      "next-hop-address": "2001:db8:aaaa::1111",
                      "ietf-rib-extension:preference": 30,
                      "ietf-rib-extension:tag": 66
                    }
                  }
                ]
              }
            }
          }
        ]
      },
      "ribs": {
        "rib": [
          {
            "name": "ipv4-primary",
            "address-family": "ietf-ipv4-unicast-routing:ipv4-unicast",
            "default-rib": true,
            "routes": {
              "route": [
                {
                  "next-hop": {
                    "ietf-ipv4-unicast-routing:next-hop-address": \
                    "192.0.2.2"
                  },
                  "route-preference": 5,
                  "source-protocol": "static",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv4-unicast-routing:destination-prefix": \
                  "0.0.0.0/0"
                },
                {
                  "next-hop": {
                    "ietf-rib-extension:repair-path": {
                      "next-hop-address": "203.0.113.1",
                      "metric": 200
                    },
                    "ietf-ipv4-unicast-routing:next-hop-address": \
                    "192.0.2.2"
                  },
                  "route-preference": 120,
                  "source-protocol": "ietf-rip:rip",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv4-unicast-routing:destination-prefix": \
                  "198.51.100.0/24"
                }
              ]
            }
          },
          {
            "name": "ipv6-primary",
            "address-family": "ietf-ipv6-unicast-routing:ipv6-unicast",
            "default-rib": true,
            "routes": {
              "route": [
                {
                  "next-hop": {
                    "ietf-ipv6-unicast-routing:next-hop-address": \
                    "2001:db8:aaaa::1111"
                  },
                  "route-preference": 5,
                  "source-protocol": "static",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv6-unicast-routing:destination-prefix": "::/0"
                },
                {
                  "next-hop": {
                    "ietf-rib-extension:repair-path": {
                      "next-hop-address": "2001:db8:cccc::2222",
                      "metric": 200
                    },
                    "ietf-ipv6-unicast-routing:next-hop-address": \
                    "2001:db8:aaaa::1111"
                  },
                  "route-preference": 120,
                  "source-protocol": "ietf-rip:rip",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv6-unicast-routing:destination-prefix": \
                  "2001:db8:bbbb::/64"
                }
              ]
            }
          }
        ]
      }
    }
   }

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

Авторы благодарны Les Ginsberg, Krishna Deevi, Suyoung Yoon за полезные комментарии и предложения. Спасибо Tom Petch, Rob Wilton, Chris Hopps, Martin Björklund, Jeffrey Zhang, Éric Vyncke, Lars Eggert, Bo Wu за их рецензии и комментарии.

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Yingzhen Qu
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.qu@futurewei.com

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

nmalykh@protokols.ru


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

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

3На самом деле в RFC 7950 приведено определение термина presence container. Прим. перев.

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

RFC 9503 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Internet Engineering Task Force (IETF)                    R. Gandhi, Ed.
Request for Comments: 9503                                   C. Filsfils
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                                  M. Chen
                                                                  Huawei
                                                             B. Janssens
                                                                    Colt
                                                                R. Foote
                                                                   Nokia
                                                            October 2023

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Расширения протокола STAMP для сетей с маршрутизацией по сегментам

PDF

Аннотация

Маршрутизация по сегментам (Segment Routing или SR) использует парадигму маршрутизации от источника (source routing). SR подходит к плоскостям пересылки как с многопротокольной коммутацией по меткам (SR-MPLS) так и IPv6 (SRv6). Этот документ задаёт расширения простого протокола двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP), описанного в RFC 8762, в сетях SR с плоскостями пересылки SR-MPLS и SRv6, дополняя расширения, определённые в RFC 8972.

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

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

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

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

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

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. Введение

Маршрутизация по сегментам (SR) использует парадигму маршрутизации от источника для программно-определяемых сетей (Software-Defined Network или SDN). SR подходит для плоскостей пересылки MPLS (SR-MPLS) и IPv6 (SRv6) [RFC8402]. Правила SR Policy, как определено в [RFC9256], применяются для направления трафика по конкретным, заданным пользователем путям, с использованием стека сегментов. Наличие полнофункционального набора инструментов измерения производительности (Performance Measurement или PM) SR является одним важных требований для измерения производительности сети при заключении соглашений об уровне обслуживания (Service Level Agreement или SLA).

Простой протокол двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP) обеспечивает возможности измерения различных показателей производительности в сетях IP [RFC8762] без применения канала управления для предварительной передачи параметров сессии. В [RFC8972] для STAMP определены необязательные расширения в форме TLV. Можно использовать модель данных YANG из [IPPM-STAMP-YANG] для режимов STAMP Session-Sender и STAMP Session-Reflector.

Тестовые пакеты STAMP передаются по пути IP между Session-Sender и Session-Reflector для измерения задержки и потерь пакетов на пути. В сетях SR может быть желательно обеспечить один путь (набор каналов и узлов) между Session-Sender и Session-Reflector пакетов STAMP в обоих направлениях. Это достигается с помощью расширений STAMP [RFC8762] для сетей SR-MPLS и SRv6, как указано в этом документе, с добавлением расширений из [RFC8972].

2. Используемые соглашения

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

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

2.2. Сокращения

MPLS

Multiprotocol Label Switching – многопротокольная коммутация по меткам.

SID

Segment Identifier – идентификатор сегмента.

SR

Segment Routing – маршрутизация по сегментам.

SR-MPLS

Segment Routing over MPLS – SR через MPLS.

SRv6

Segment Routing over IPv6 – SR через IPv6.

SSID

STAMP Session Identifier – идентификатор сессии STAMP.

STAMP

Simple Two-Way Active Measurement Protocol – простой протокол двухсторонних активных измерений.

2.3. Эталонная топология

В показанной ниже эталонной топологии STAMP Session-Sender S1 передаёт тестовый пакет STAMP, а STAMP Session-Reflector R1 возвращает отклик на него. Пакет с откликом может передаваться Session-Sender S1 по тому же или иному пути (набору каналов и узлов), нежели для пакетов в направлении Session-Reflector R1.

S1 добавляет метку передачи T1 и метку приёма T4, R1 – метку приёма T2 и метку передачи T3. Узлы S1 и R1 могут соединены по каналу или пути SR [RFC8402]. Канал может быть физическим или виртуальным, а группой агрегирования каналов (Link Aggregation Group или LAG) [IEEE802.1AX] или членом такой группы. Путь SR может представлять собой SR Policy [RFC9256] на узле S1 (head-end) с узлом R1 (tail-end) в качестве адресата.

              T1                T2
             /                   \
    +-------+    Тестовый пакет   +-------+
    |       | - - - - - - - - - ->|       |
    |   S1  |=====================|   R1  |
    |       |<- - - - - - - - - - |       |
    +-------+   Тестовый отклик   +-------+
             \                   /
              T4                T3

STAMP Session-Sender        STAMP Session-Reflector

Рисунок . Эталонная топология.


3. Destination Node Address TLV

Узлу Session-Sender может потребоваться передача пакетов для Session-Reflector с немаршрутизируемым (т. е. не подходящим в качестве Source Address в пакетах отклика) адресом получателя (Destination Address). Это можно сделать, например, путём инкапсуляции пакетов STAMP в туннельный протокол, как описано в Приложении A.

В [RFC8972] определены тестовые пакеты STAMP Session-Sender и Session-Reflector, которые могут включать необязательные TLV. В этом документе определяется TLV Type (значение 9 для IPv4 и IPv6) для Destination Node Address TLV в пестовых пакетах STAMP [RFC8972]. Формат Destination Node Address 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=9     |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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=9     |         Length=16             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         IPv6 Address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Destination Node Address TLV.


STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Type

Тип (9) для IPv4 Destination Node Address TLV или IPv6 Destination Node Address TLV.

Length

2-октетное значение размера поля Address в октетах (4 для IPv4 и 16 для IPv6).

Destination Node Address TLV указывает адрес Session-Reflector для тестового пакета. Если полученный Destination Node Address является одним из адресов Session-Reflector, его следует указывать как Source Address в заголовке IP тестового пакета-отклика. При передаче Destination Node Address TLV должно указываться значение SSID.

Узел Session-Reflector, распознавший этот TLV, должен установить для флага U [RFC8972] в отклике на тестовый пакет значение 1, если он определил, что не является получателем, указанным в Destination Node Address TLV. В этом случае Session-Reflector не использует полученный Destination Node Address в поле Source Address заголовка IP в пакета отклика. В иных случаях Session-Reflector должен установить для флага U в Destination Node Address TLV пакета-отклика значение 0.

4. Return Path TLV

Для сквозных путей SR узлу Session-Reflector может потребоваться передача откликов в конкретный путь (Return Path). Session-Sender может указать это в тестовых пакетах для Session-Reflector с помощью Return Path TLV. Этот TLV в тестовом пакете от Session-Sender, позволяя не указывать и не поддерживать динамическое состояние сети SR для сессий STAMP на Session-Reflector.

В разделе 4 [RFC8762] заданы два режима поведения Session-Reflector – Stateless (без состояния) и Stateful (с поддержкой состояния). Для режима Stateful на Session-Reflector требуется конфигурация, соответствующая параметрам Session-Sender, включая Source Address, Destination Address, Source UDP Port, Destination UDP Port и, возможно, SSID (если SSID настраивается, а не создаётся автоматически). В этом случае для направления тестовых пакетов можно использовать локальные правила, создающие дополнительные состояния для сессий STAMP на Session-Reflector. При работе в неразборчивом (promiscuous) режиме Stateless Session-Reflector потребуется указать, как возвратить тестовые отклики по конкретному пути, например, для измерений в среде ECMP.

Для каналов узлу Session-Reflector может потребоваться передавать тестовые отклики по тому же (входному) каналу в обратном направлении. Session-Sender может запросить это в тестовых пакетах для Session-Reflector с помощью Return Path TLV.

В [RFC8972] определены тестовые пакеты STAMP с необязательными TLV. Этот документ определяет TLV Type (10) для Return Path TLV, указывающем Return Path для тестового пакета от Session-Sender. Формат Return Path TLV показан на рисунке 3.

 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=10    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Return Path Sub-TLVs                        |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Return Path TLV.


STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Type

Тип (10) для Return Path TLV.

Length

2-октетное значение размера поля Return Path Sub-TLVs в октетах.

Return Path Sub-TLVs

В соответствии с параграфом 4.1.

Узлу Session-Sender недопустимо помещать более одного Return Path TLV в тестовый пакет STAMP. Узел Session-Reflector, поддерживающий такие TLV, должен обрабатывать лишь первый Return Path TLV в тестовом пакете, игнорируя другие при их наличии. Поддерживающий такие TLV узел Session-Reflector должен отвечать с использованием Return Path из полученного от Session-Sender тестового пакета, если при обработке TLV не возникло ошибок.

Узел Session-Reflector, поддерживающий этот TLV, должен установить для флага U [RFC8972] в тестовом отклике значение 1, если он определил, что не может использовать Return Path в тестовом отклике. В иных случаях Session-Reflector должен устанавливать для флага U в отклике значение 0.

4.1. Return Path Sub-TLV

Return Path TLV содержит 1 или несколько Sub-TLV для передачи сведений о запрошенном пути возврата (Return Path). Return Path Sub-TLV может передавать Return Path Control Code, Return Path IP Address или Return Path Segment List.

Флаги STAMP Sub-TLV устанавливаются по процедурам, описанным в [RFC8972].

В Return Path TLV тестового пакета Session-Sender недопустимо включать более одного Control Code Sub-TLV, Return Address Sub-TLV или Return Path Segment List Sub-TLV. В Return Path TLV тестового пакета Session-Sender недопустимо включать сразу Control Code Sub-TLV и Return Address или Return Path Segment List Sub-TLV тестового пакета Session-Sender. В Return Path TLV тестового пакета Session-Sender можно включать сразу Return Address и Return Path Segment List Sub-TLV.

4.1.1. Return Path Control Code Sub-TLV

Формат Control Code Sub-TLV в Return Path TLV показан на рисунке 4.

 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=1      |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Control Code Flags                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Control Code Sub-TLV в Return Path TLV.


Type

Тип (1) для Return Path Control Code. Session-Sender может запросить у Session-Reflector передачу тестовых откликов на основе флагов, указанных в поле Control Code Flags.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера флагов Control Code в октетах (4).

Control Code Flags (32 bits)

Бит 31 (младший) в Reply Request Flag:
0x0 – отклик не запрошен;
0x1 – запршен отклик по тому же каналу.

Остальные биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться при получении.

Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x0, Session-Reflector не передаёт отклика на тестовый пакет узлу Session-Sender и завершает обработку тестового пакета STAMP. В этом случае провидится лишь одностороннее измерение. Session-Reflector может локально передавать показатели производительности через телеметрию, используя сведения из полученного тестового пакета. В этом случае все остальные Return Path Sub-TLV должны игнорироваться.

Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x1, Session-Reflector передаёт отклик на тест в тот же канал, где был принят тестовый пакет, в обратном направлении для Session-Sender. Канал может быть физическим интерфейсом, виртуальным каналом, LAG [IEEE802.1AX] или членом LAG. Все прочие Return Path Sub-TLV в этом случае должны игнорироваться. При использовании членов LAG для указания канала можно применять расширение STAMP для Micro-Session ID TLV, заданное в [STAMP-ON-LAG].

4.1.2. Return Address Sub-TLV

Тестовые отклики STAMP могут передаваться узлу Session-Sender по адресу Return Address в Return Address Sub-TLV всесто Source Address в тестовом пакете от Session-Sender.

Формат Return Address Sub-TLV в Return Path TLV для IPv4 и IPv6 показан на рисунке 5.

 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=2    |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Return IPv4 Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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=2    |         Length=16             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Return IPv6 Address                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Return Address Sub-TLV в Return Path TLV.


Type

Тип (2) для Return IPv4 Address или Return IPv6 Address.
Return Address запрашивает у Session-Reflector отправку тестовых откликов по указанному адресу вместо передачи по Source Address в тестовом пакете от Session-Sender.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера поля Return Address в октетах (4 для IPv4, 16 для IPv6).

4.1.3. Return Path Segment List Sub-TLV

Формат Segment List Sub-TLV в Return Path TLV показан на рисунках 6 и 7. Поля Segment из Segment List Sub-TLV описаны в [RFC8402]. Сегменты должны указываться с использованием сетевого порядка байтов.

Session-Sender должен включать в тестовый пакет лишь один Return Path Segment List Sub-TLV, а в Segment List должен указываться хотя бы один Segment. Session-Reflector должен обрабатывать лишь первый Return Path Segment List Sub-TLV в тестовом пакете, игнорируя прочие Return Path Segment List Sub-TLV, если они меются.

Return Path Segment List Sub-TLV может иметь один из двух типов:

Type (3)

SR-MPLS Label Stack из Return Path;

Type (4)

SRv6 Segment List из Return Path.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера поля Segment List в октетах (значение 0 недопустимо).

4.1.3.1. Return Path SR-MPLS Label Stack Sub-TLV

 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=3    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Segment(1)                     | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Segment(n) (дно стека)         | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат SR-MPLS Label Stack Sub-TLV в Return Path TLV.


SR-MPLS Label Stack содержит список 32-битовых элементов стека (Label Stack Entry или LSE) из 20-битового значения метки, 8-битового поля Time-To-Live (TTL), 3-битового класса трафика (Traffic Class или TC) и 1-битового поля завершения стека (End-of-Stack или S). Размер Sub-TLV должен быть кратным 4. Например, SR-MPLS Label Stack Sub-TLV может передавать лишь одну метку Binding SID Label [PCE-BINDING-LABEL-SID] из Return SR-MPLS Policy. Метка Binding SID Label в Return SR-MPLS Policy является локальной для Session-Reflector. Механизм сигнализации Binding SID Label узлу Session-Sender выходит за рамки этого документа. В качестве другого примера SR-MPLS Label Stack Sub-TLV может включать Path Segment Identifier Label из Return SR-MPLS Policy в Segment List из SR-MPLS Policy.

4.1.3.2. Return Path SRv6 Segment List Sub-TLV
 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=4    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Segment(1) (128 битов IPv6 Address)                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Segment(n) (128 битов IPv6 Address) (дно стека)          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат SRv6 Segment List Sub-TLV в Return Path TLV.


SRv6 Segment List содержит список 128-битовых адресов IPv6, представляющих SRv6 SID. Размер Sub-TLV должен быть кратным 16. Например, Return Path SRv6 Segment List Sub-TLV может содержать лишь один SRv6 Binding SID [PCE-BINDING-LABEL-SID] из Return SRv6 Policy. SRv6 Binding SID из Return SRv6 Policy является локальным для Session-Reflector. Механизм сигнализации SRv6 Binding SID узлу Session-Sender выходит за рамки этого документа. В качестве другого примера Return Path SRv6 Segment List Sub-TLV может включать SRv6 Path Segment Identifier из Return SRv6 Policy в Segment List из SRv6 Policy.

5. Совместимость с TWAMP Light

Этот документ не включает дополнительных соображений о функциональной совместимости с протоколом TWAMP Light в дополнение к описанным в параграфе 4.6 [RFC8762], где рассмотрены два варианта взаимодействия:

  • STAMP Session-Sender с TWAMP Light Session-Reflector;

  • TWAMP Light Session-Sender с STAMP Session-Reflector.

Если любое из заданных здесь расширений STAMP применяется узлом STAMP Session-Sender, TWAMP Light Session-Reflector будет видеть его как поле Packet Padding.

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

Вопросы безопасности, рассмотренные в [RFC8762] и [RFC8972], применимы и к заданным здесь расширениям. В частности, режим аутентификации и защита целостности с использованием хэшированного кода аутентификации сообщений (Hashed Message Authentication Code или HMAC), указанные в параграфе 4.4 [RFC8762], применимы и к описанным здесь процедурам.

STAMP использует общеизвестный номер порта UDP, который может стать целью атаки с отказом в обслуживании (denial of service или DoS) или атаки в пути. Таким образом, соображения безопасности и методы снижения риска, указанные в разделе 6 [RFC8545], применимы и к расширениям STAMP, описанным в этом документе.

При желании атаки можно смягчить с помощью базовых проверок корректности полей временных меток (T2 позднее T1 в эталонной топологии из параграфа 2.3) в принятом Session-Sender отклике на тестовый пакет. packets at the. The minimal state associated with these protocols also limit the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle.

Заданные здесь расширения STAMP предназначены для внедрения в средах с единым административным доменом. В этом случае оператор предоставляет адреса Session-Sender и Session-Reflector, а также Return Path для сессии STAMP. Предполагается, что оператор целостность Return Path и подлинность Session-Reflector на другой стороне.

Заданные здесь расширения STAMP могут использоваться для подмены адресов. Например, Session-Sender может указать IP-адрес Return Path, отличающийся от адреса Session-Sender. Session-Reflector может отбрасывать тестовые пакеты Session-Sender, когда он не может определить, является ли Return Path IP Address локальным для Session-Sender. Чтобы помочь Session-Reflector в этом определении оператор может указывать также Return Path IP Address, например в списке управления доступом.

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

Агентство IANA выделило значения для Destination Address TLV Type и Return Path TLV Type из диапазона IETF Review TLV в реестре STAMP TLV Types [RFC8972], как указано в таблице 1.

Таблица . Типы STAMP TLV.

 

Значение

Описание

Документ

9

Destination Node Address (IPv4 или IPv6)

RFC 9503

10

Return Path

RFC 9503

 

Агентство IANA создало реестр Return Path Sub-TLV Types. Коды из диапазона 1 – 175 нужно выделять по процедуре IETF Review, описанной в [RFC8126]. Коды 176 – 239 выделяются по процедуре First Come First Served из [RFC8126]. Остальные значения распределены в соответствии с таблицей 2.

Таблица . Реестр типов Return Path Sub-TLV.

 

Диапазон

Процедура регистрации

1-175

IETF Review

176-239

First Come First Served

240-251

Experimental Use

252-254

Private Use

 

Агентство IANA выделило указанные ниже значения типов Sub-TLV в реестре Return Path Sub-TLV Types.

Таблица . Типы Return Path Sub-TLV.

 

Значение

Описание

Документ

0

Резерв

RFC 9503

1

Return Path Control Code

RFC 9503

2

Return IPv4 or IPv6 Address

RFC 9503

3

SR-MPLS Label Stack of the Return Path

RFC 9503

4

SRv6 Segment List of the Return Path

RFC 9503

255

Резерв

RFC 9503

 

Агентство IANA создало реестр Return Path Control Code Flags для Return Path Control Code Sub-TLV. Все коды в позициях 31 (младший бит) – 12 этого реестра выделяются по процедуре IETF Review, как указано в [RFC8126]. Коды в позициях 11 – 8 нужно выделять по процедуре First Come First Served из [RFC8126]. Остальные коды распредеелны в соответствии с таблицей 4.

Таблица . Return Path Control Code.

 

Диапазон

Процедура регистрации

31-12

IETF Review

11-8

First Come First Served

7-4

Experimental Use

3-0

Private Use

 

Агентство IANA выделило указанное в таблице 5 значение в реестре Return Path Control Code Flags.

Таблица . флагReturn Path Control Code.

 

Значение

Описание

Документ

31

Reply Request

RFC 9503

 

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

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

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

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

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

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

[IEEE802.1AX] IEEE, “IEEE Standard for Local and metropolitan area networks — Link Aggregation”, IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014, <https://doi.org/10.1109/IEEESTD.2014.7055197>.

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

[PCE-BINDING-LABEL-SID] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., “Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.”, Work in Progress, Internet-Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16>.

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

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

[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., “Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)”, RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.

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

[STAMP-ON-LAG] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, “Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-on-lag-05, 17 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-on-lag-05>.

Приложение A. Пример использования Destination Node Address TLV

Тестовые пакеты STAMP могут инкапсулироваться с 1) SR-MPLS Label Stack и заголовком IPv4, содержащий адрес IPv4 Destination Address из сети 127.0.0/8 или 2) внешним заголовком IPv6, заголовком маршрутизации по сегментам (Segment Routing Header или SRH) и внутренним заголовком IPv6 с IPv6 Destination Address из диапазона ::1/128.

В среде ECMP хэш-функция пересылки может определять путь пересылки с использованием Source Address, Destination Address, портов UDP, метки ротока IPv6 и других полей пакета. Поэтому в IPv4, например, могут применяться разные значения IPv4 Destination Address из сети 127.0.0.0/8 в заголовке IPv4 тестовых пакетов STAMP для оценки разных путей ECMP. В IPv6 для этого могут служить, например, разные значения метки потоков в заголовке IPv6 тестовых пакетов STAMP. В этих случаях тестовые пакеты STAMP могут прийти на узел, не являющийся Session-Reflector для этой сессии STAMP, в ошибочных условиях и такой непредусмотренный узел может передать тестовый отклик с недействительными результатми измерения. Для обнаружения таких ошибок предусмотренный адрес Session-Reflector может передаваться в Destination Node Address TLV.

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

Авторы благодарны Thierry Couture за обсуждение использования измерений производительности при маршрутизации по сегментам. Спасибо также Greg Mirsky, Mike Koldychev, Gyan Mishra, Tianran Zhou, Al Morton, Reshad Rahman, Zhenqiang Li, Frank Brockners, Henrik Nydell, Cheng Li за комментарии и предложения. Спасибо Joel Halpern за рецензию Gen-ART, Martin Duke за рецензию AD и Kathleen Moriarty за рецензию по безопасности. Авторы признательны Robert Wilton, Éric Vyncke, Paul Wouters, John Scudder, Roman Danyliw, Lars Eggert, Erik Kline, Warren Kumari и Jim Guichard за рецензию IESG.

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

Ниже указан человек, внёсший существенный вклад в этот документ.

Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca

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

Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
 
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
 
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
 
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
 
Richard Foote
Nokia
Email: footer.foote@nokia.com

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

nmalykh@protokols.ru

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

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

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

RFC 9484 Proxying IP in HTTP

Internet Engineering Task Force (IETF)                     T. Pauly, Ed.
Request for Comments: 9484                                    Apple Inc.
Updates: 9298                                                D. Schinazi
Category: Standards Track                              A. Chernyakhovsky
ISSN: 2070-1721                                               Google LLC
                                                            M. Kühlewind
                                                           M. Westerlund
                                                                Ericsson
                                                            October 2023

Proxying IP in HTTP

Проксирование IP через HTTP

PDF

Аннотация

В этом документе описывается проксирование IP-пакетов в HTTP. Протокол аналогичен протоколу проксирования UDP через HTTP, но предназначен для передачи произвольных пакетов IP. Более конкретно, документ задаёт протокол, позволяющий клиенту HTTP создать туннель IP через сервер HTTP, выступающий как IP-прокси. Документ обновляет RFC 9298.

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

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

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

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

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

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. Введение

HTTP поддерживает метод CONNECT (параграф 9.3.6 в [HTTP]) для создания туннеля TCP [TCP] с адресатом и аналогичный механизм для UDP [CONNECT-UDP]. Однако эти механизмы не способны туннелировать другие протоколы IP [IANA-PN], а также передавать поля заголовка IP.

В этом документе описывается протокол для туннелирования IP через сервер HTTP, действующий как IP-прокси через HTTP. Это может применяться в разных случаях, например как VPN для удалённого доступа или между сайтами, защищённые связи «точка-точка», туннелирование общего назначения для пакетов.

Проксирование IP работает аналогично проксированию UDP [CONNECT-UDP], при этом сам прокси идентифицируется абсолютным URL, возможно, включающим адресат трафика. Клиенты генерируют такие URL с помощью шаблона URI (URI Template) [TEMPLATE], как описано в разделе 3.

Протокол поддерживает все имеющиеся версии HTTP за счёт применения дейтаграмм HTTP [HTTP-DGRAM]. Для HTTP/2 [HTTP/2] или HTTP/3 [HTTP/3] применяется HTTP Extended CONNECT, как описано в [EXT-CONNECT2] и [EXT-CONNECT3]. Для HTTP/1.x [HTTP/1.1] применяется HTTP Upgrade, как описано в параграфе 7.8 [HTTP].

Этот документ обновляет [CONNECT-UDP] для изменения общеизвестного URI masque (см. параграф 12.3).

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

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

В этом документе термин IP-прокси (IP proxy) обозначает сервер HTTP, отвечающий на запросы проксирования IP. Термин клиент используется как в HTTP, он создаёт запросы на проксирование IP. Посредники HTTP (как определено в параграфе 3.7 [HTTP]) между клиентом и IP-прокси называются просто посредниками (intermediary). Конечными точками проксирования IP (IP proxying endpoint) называются клиенты и IP-прокси.

В документе используется терминология из [QUIC]. При определении в документе типов протоколов применяется формат определений с использованием нотации из параграфа 1.3 в [QUIC]. В спецификации используется кодирование целых чисел с переменным размером из раздела 16 в [QUIC]. Целые числа с переменным размером не требуется кодировать в минимальное число байтов.

Отметим, что в случаях, когда применяемая версия HTTP не поддерживает мультиплексирование потоков (например, HTTP/1.1), термин поток в этом документе относится ко всему соединению.

3. Настройка клиентов

Клиенты настраиваются на использование проксирования IP через HTTP с помощью шаблона URI [TEMPLATE]. Шаблон URI может включать 2 переменные – target и ipproto, см. параграф 4.6. Необязательность переменных нужно учитывать при задании шаблона, чтобы переменная была самоопределяемой или её можно было исключить через синтаксис. Примеры приведены ниже.

https://example.org/.well-known/masque/ip/{target}/{ipproto}/
https://proxy.example.org:4443/masque/ip?t={target}&i={ipproto}
https://proxy.example.org:4443/masque/ip{?target,ipproto}
https://masque.example.org/?user=bob

Рисунок . Примеры шаблонов URI.

Далее перечислены требования к шаблону URI.

  • URI Template должен быть шаблоном не выше уровня 3.

  • Шаблон должен иметь абсолютную форму и должен включать непустые компоненты scheme, authority, и path.

  • Компонент path в URI Template должен начинаться с символа /.

  • Все переменные шаблона должны быть внутри компонентов path или query в URI.

  • URI Template может включать 2 переменные – target и ipproto, а также может содержать другие переменные. При наличии target или ipproto пустые значения в них недопустимы. Клиенты могут использовать символ * для указания шаблона или значений без предпочтения (см. параграф 4.6).

  • В шаблон URI недопустимо включать символы non-ASCII Unicode и должны применяться только символы ASCII из диапазона 0x21-0x7E, включительно (разрешено %-кодирование, см. параграф 2.1 в [URI]).

  • В URI Template недопустимо применять Reserved Expansion (оператор +), Fragment Expansion (оператор #), Label Expansion с Dot-Prefix, Path Segment Expansion с Slash-Prefix, Path-Style Parameter Expansion с Semicolon-Prefix.

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

Как и при проксировании UDP, некоторые конфигурации клиентов для IP-прокси будут разрешать пользователю настраивать только хост и порт прокси. Клиенты с такими ограничениями могут пытаться получить доступ к возможностям IP-прокси, используя принятый по умолчанию шаблон, заданный как https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ip/{target}/{ipproto}/, где $PROXY_HOST и $PROXY_PORT будут иметь настроенные значения для хоста и порта IP-прокси. Внедрениям IP-прокси следует предоставлять сервис, если им нужна совместимость с такими клиентами.

4. Туннелирование IP через HTTP

Для обеспечения возможности создания туннеля для IP по протоколу HTTP в этом документе определён маркер обновления HTTP connect-ip. Создаваемые туннели IP используют капсульный протокол (Capsule Protocol, см. параграф 3.2 в [HTTP-DGRAM]) с дейтаграммами HTTP, формат которых задан в разделе 6.

Для инициирования туннеля IP, связанного с одним потоком HTTP, клиент вводит запрос с маркером обновления connect-ip. При отправке запроса на проксирование IP клиенту нужно выполнить расширение URI Template для задания пути и своих потребностей (query), как описано в разделе 3.

По определению капсульного протокола (параграф 3.2 в [HTTP-DGRAM]) запросы проксирования IP не могут включать содержимого. Точно так же, отклики об успешном проксировании IP не включают содержимого.

При проксировании IP по протоколу HTTP должно применяться шифрование TLS или QUIC (возможен также иной протокол шифрования) для обеспечения конфиденциальности, целостности и аутентификации.

4.1. Работа IP Proxy

Ниже указаны действия при получении запроса на проксирование IP.

  • Если получатель настроен на использование другого сервера HTTP, он будет выступать посредником, пересылая запрос другому серверу HTTP. Отметим, что такому посреднику может потребоваться повторное кодирование запроса, если он пересылает с использованием не той версии HTTP, которая указана в полученном запросе, поскольку кодировка запросов зависит от версии (см. ниже).

  • В иных случаях получатель будет выступать как IP-прокси, который может принять или отвергнуть запрос. В случае восприятия запроса извлекаются исходные переменные target и ipproto из URI, восстановленного по заголовкам запроса, декодируется %-представление и организуется туннель IP.

IP-прокси должны убедиться, что декодированные переменные target и ipproto соответствуют требованиям параграфа 4.6. Если это не так, IP-прокси должен считать запрос некорректным (см. параграф 8.1.1 в [HTTP/2] и 4.1.2 в [HTTP/3]). Если переменная target содержит имя DNS, IP-прокси должен выполнить распознавание (для получения адреса IPv4 и/или IPv6 по записям A, AAAA) до ответа на запрос HTTP. Если при этом возникает ошибка, IP-прокси должен отклонить запрос и следует передать детали отказа в подходящем поле заголовка Proxy-Status [PROXY-STATUS]. Например, при возврате ошибки в процессе распознавания DNS прокси может использовать тип ошибки прокси dns_error из параграфа 2.3.2 в [PROXY-STATUS].

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

Отклик об успешном проксировании IP (см. параграфы 4.3 и 4.5) показывает, что IP-прокси организовал туннель IP и готов передавать данные IP (payload). Любой другой отклик на запрос проксирования говорит об отклонении запроса и клиент должен прервать запрос.

Вместе с откликом об успехе IP-прокси может передать клиенту капсулы для назначения адресов и анонсирования маршрутов (параграф 4.7). Клиент также может назначать адреса и анонсировать маршруты IP-прокси для маршрутизации между сетями.

4.2. Запрос HTTP/1.1

При использовании When using /1.1 [HTTP/1.1] к запросам проксирования IP применяется ряд требований.

  • Нужно использовать метод GET.

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

  • В запрос нужно включать поле заголовка Connection со значением Upgrade (без учёта регистра символов, как указано в параграфе 7.6.1 [HTTP]).

  • В запрос нужно включать поле заголовка Upgrade со значением connect-ip.

Запросы проксирования IP, не соответствующие этим требованиям считаются некорректными, получатель такого запроса должен возвращать ошибку и для отклика следует применять код 400 (Bad Request). Например, если у клиента задан шаблон URI https://example.org/.well-known/masque/ip/{target}/{ipproto}/ и клиент хочет создать туннель для пересылки IP без ограничения цели и протоколов, он может передать показанный ниже запрос.

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Рисунок . Пример запроса HTTP/1.1.

4.3. Отклик HTTP/1.1

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

  • В отклике нужно указывать код статуса HTTP 101 (Switching Protocols).

  • В отклик нужно включать поле заголовка Connection со значением Upgrade (без учёта регистра символов, как указано в параграфе 7.6.1 [HTTP]).

  • В отклик нужно включать 1 поле заголовка Upgrade со значением connect-ip.

  • Нужно соблюдать требования к откликам HTTP, начинающимся с Capsule Protocol (см. параграф 3.2 в [HTTP-DGRAM]).

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

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

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Рисунок . Пример отклика HTTP/1.1.

4.4. Запросы HTTP/2 и HTTP/3

При использовании HTTP/2 [HTTP/2] или r HTTP/3 [HTTP/3] в запросах проксирования IP применяется метод HTTP Extended CONNECT. Этот требует от сервера передавать HTTP Setting, как задано в [EXT-CONNECT2] и [EXT-CONNECT3], а в запросах должны присутствовать поля псевдозаголовка HTTP, соответствующие ряду требований.

  • В поле псевдозаголовка :method нужно указывать значение CONNECT.

  • В поле псевдозаголовка :protocol нужно указывать значение connect-ip.

  • В поле псевдозаголовка :authority нужно указывать значение полномочия IP-прокси.

  • Полям псевдозаголовка :path и :scheme не следует быть пустыми. В них нужно указывать схему и путь из URI Template после преобразования шаблона URI (см. раздел 3). Переменные в URI Template могут определять область действия запроса, например пересылку через туннель всех пакетов IP или проксирование конкретного потока (см. параграф 4.6).

Запрос проксирования IP, не соответствующий этим требованиям, считается некорректным (см. параграф 8.1.1 в [HTTP/2] и 4.1.2 в [HTTP/3]).

Например, если клиент настроен с шаблоном URI https://example.org/.well-known/masque/ip/{target}/{ipproto}/ и хочет создать туннель для пересылки IP без ограничения цели и протоколов, он может передать показанный ниже запрос.


HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

Рисунок . Пример запроса HTTP/2 или HTTP/3.

4.5. Отклики HTTP/2 и HTTP/3

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

  • В отклике нужно указывать код статуса 2xx (Successful).

  • Нужно соблюдать требования к откликам HTTP, начинающимся с Capsule Protocol (см. параграф 3.2 в [HTTP-DGRAM]).

Если какое-либо из этих требований не выполняется, клиент должен считать эту попытку проксирования неудачной и прерывать запрос. Например, любой код 3xx будет считаться отказом, заставляя клиента прервать запрос.

Ниже приведён пример возможного отклика сервера.

HEADERS
:status = 200
capsule-protocol = ?1

Рисунок . Пример отклика HTTP/2 или HTTP/3.

4.6. Ограничение области действия запроса

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

Область действия запроса клиент указывает IP-прокси через переменные target и ipproto в шаблоне URI (см. раздел 3), которые необязательны и при отсутствии принимается шаблонное значение *.

target

Переменная target содержит имя хоста или префикс IP конкретного хоста, с которым клиент хочет обмениваться пакетами. При отсутствии переменной принимается значение *, указывающее, что клиент запрашивает взаимодействие с любым разрешённым хостом. В переменной target можно указывать имена DNS, а также префиксы IPv6 и IPv4. Отметим, что идентификаторы зон адресации IPv6 [IPv6-ZONE-ID] не поддерживаются. Если в target указан префикс IP (адрес IP, за которым может следовать представленный %-кодом символ дробной черты / и размер префикса), запрос будет поддерживать только одну версию IP. Если target указывает имя хоста, предполагается, что IP-прокси выполнит распознавание DNS для определения маршрутов, анонсируемых клиенту. IP-прокси следует передавать капсулу ROUTE_ADVERTISEMENT, включающую маршруты для всех адресом, распознанных для указанного имени хоста, которые доступны IP-прокси и относятся к семейству адресов, для которого IP передаёт также назначенный адрес.

ipproto

Переменная ipproto содержит номер протокола (Internet Protocol Number) из реестра IANA Assigned Internet Protocol Numbers [IANA-PN]. Наличие протокола говорит, что хост хочет использовать для этого запроса только один протокол IP. Если указано значение * или переменная отсутствует, это говорит о запросе клиентом любых протоколов IP. Протокол IP, указанный в переменной ipproto, представляет дозволенное значение следующего заголовка в заголовке IP, передаваемом напрямую в дейтаграммах HTTP (внешние заголовки IP). Трафик ICMP разрешён всегда независимо от значения данного поля.

В терминах IPv6address, IPv4address, reg-name из [URI] переменные target и ipproto должны соответствовать формату, приведённому на рисунке 6, с использованием нотации [ABNF]. Дополнительные требования приведены ниже.

  • Если target содержит адрес или префикс IPv6, для двоеточий (:) должно применяться %-кодирование. Например адрес 2001:db8::42 будет представлен в URI как 2001%3Adb8%3A%3A42.

  • При указании размера префикса IP в target нужно включать символ /) с %-кодированием (%2F). Размер префикса IP должен указываться десятичным целым числом от 0 до размера IP-адреса в битах.

  • Если в target указан префикс IP и его размер строго меньше размера IP-адреса в битах, младшие биты адреса, не входящие в префикс, должны иметь значение 0.

  • Значением ipproto должно быть целое число от 0 до 255 или символ *.

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

Рисунок . Формат переменных URI Template.

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

4.7. Капсулы

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

4.7.1. ADDRESS_ASSIGN

Капсула ADDRESS_ASSIGN (тип 0x01) позволяет конечной точке назначить своему партнёру набор адресов или префиксов IP. Каждая капсула содержит полный список префиксов IP, выделенных в настоящий момент её получателю. Любой из этих адресов может быть указан в поле источника пакетов IP от получателя данной капсулы.

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

Рисунок . Формат капсулы ADDRESS_ASSIGN.

Капсула ADDRESS_ASSIGN может (но не обязана) включать 1 или несколько Assigned Address.

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Рисунок . Формат назначенного адреса.

Поля назначенного адреса (Assigned Address) перечислены ниже.

Request ID

Идентификатор запроса в форме целого числа с переменным размером. Если это назначение адресов размещено в отклике на Address Request (параграф 4.7.2), в поле нужно указывать значение соответствующего поля в запросе. В ином случае в поле нужно помещать значение 0.

IP Version

Версия IP для данного назначения адреса, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

IP Address

Назначенный адрес IP. Если в поле IP Version указано значение 4, поле IP Address нужно делать 32-битовым, а для IP Version = 6 – 128-битовым.

IP Prefix Length

Число битов адреса IP, служащих для задания назначенного префикса , указанное 8-битовым целым числом без знака. Значение должно быть не больше размера поля IP Address в битах. Если размер префикса совпадает с размером адреса, получателю капсулы разрешается передавать пакеты с одним адресом источника. Если размер префикса меньше размера адреса IP, получатель капсулы может передавать пакета с любым адресом из этого префикса в поле источника. Если размер префикса строго меньше размера адреса IP, в младших битах поля IP Address, не охватываемых префиксом, должно быть установлено значение 0.

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

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

В некоторых внедрениях проксирования IP через HTTP конечной точке требуется получить адрес от партнёра до того, как ана узнает адрес источника для своих пакетов. Например, в варианте удалённого доступа в VPN (параграф 8.1) клиент не может передавать пакеты IP, пока не узнает, какой адрес использовать. В таких ситуациях конечная точка, ожидающая назначения адреса, должна передать капсулу ADDRESS_REQUEST. Это не требуется, если конечная точка не нуждается в назначении адреса, например, настроена автономно (out-of-band) со статическим адресом.

Хотя капсулы ADDRESS_ASSIGN обычно передаются в ответ на ADDRESS_REQUEST, конечные точки могут передавать ADDRESS_ASSIGN без запроса.

4.7.2. ADDRESS_REQUEST

Капсула ADDRESS_REQUEST (тип 0x02) позволяет конечной точке запросить у партнёра назначение адресов IP. Капсула позволяет конечной точке опционально указать свои предпочтения в части назначения адресов.

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

Рисунок . Формат капсулы ADDRESS_REQUEST.

Капсула ADDRESS_REQUEST включает 1 или несколько Requested Address.

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Рисунок . Формат запрошенного адреса.

Поля Requested Address указаны ниже.

Request ID

Идентификатор данного запроса в форме целого числа с переменным размером. Каждый запрос от данной конечной точки имеет свой идентификатор. Конечной точке недопустимо использовать Request ID неоднократно и недопустимо указывать значение 0.

IP Version

Версия IP для данного запроса адреса, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

IP Address

Запрашиваемый адрес IP. При IP Version = 4 поле IP Address нужно делать 32-битовым, при IP Version = 6 – 128-битовым.

IP Prefix Length

Размер запрашиваемого префикса IP в битах, указанный 8-битовым целым числом без знака. Значение должно быть не более размера поля IP Address в битах. Если размер префикса строго меньше размера адреса IP, в младших битах поля IP Address, не охватываемых префиксом, должно быть установлено значение 0.

Если адрес IP включает только 0 (0.0.0.0 или ::), это означает, что отправитель лишь запрашивает адрес из данного семейства, не отдавая предпочтения конкретным значениям. В этом случае размер префикса по-прежнему указывает предпочтения отправителя в части размера запрашиваемого префикса.

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

При получении капсулы ADDRESS_REQUEST конечной точке следует выделить своему партнёру 1 или множество адресов IP и ответить капсулой ADDRESS_ASSIGN для информирования того о назначении. Для каждого Requested Address получателю капсулы ADDRESS_REQUEST нужно ответить элементом Assigned Address с соответствующим Request ID. Если запрошенный адрес был выделен, в полях IP Address и IP Prefix Length элемента Assigned Address в отклике нужно указать выделенные значения. Если запрошенный адрес не был назначен, поле IP Address нужно заполнить нулями, а для IP Prefix Length SHALL нужно указать максимальный размер (0.0.0.0/32 или ::/128) для указания того, что адрес не выделен. Отклонённые адреса не следует включать в последующие капсулы ADDRESS_ASSIGN. Отметим, что в том же отклике ADDRESS_ASSIGN могут содержаться другие записи Assigned Address, не соответствующие какому-либо Request ID.

Если конечная точка получает капсулу ADDRESS_REQUEST без Requested Address, она должна прервать поток запроса проксирования IP.

Отметим, что порядок Requested Address не имеет какой-либо семантики, а Request ID служит лишь уникальным идентификатором, не задавая приоритета или важности.

4.7.3. ROUTE_ADVERTISEMENT

Капсула ROUTE_ADVERTISEMENT (тип 0x03) позволяет конечной точке сообщить своему партнёру о готовности маршрутизировать трафик для набора диапазонов адресов IP. Это говорит, что у отправителя капсулы уже есть маршруты к каждому диапазону адресов и уведомляет партнёра, что при отправке получателем капсулы ROUTE_ADVERTISEMENT пакетов IP в один из этих диапазонов в дейтаграммах HTTP, отправитель капсулы перешлёт их по имеющемуся маршруту. Любой из адресов, входящий в один из диапазонов, может быть адресом получателя в пакетах IP, отправляемых получателем капсулы.

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

Рисунок . Формат капсулы ROUTE_ADVERTISEMENT.

Капсула ROUTE_ADVERTISEMENT может (но не обязана) содержать 1 или несколько IP Address Range.

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

Рисунок . Формат диапазона адресов IP.

Поля IP Address Range описаны ниже.

IP Version

Версия IP для данного диапазона, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

Start IP Address и End IP Address

Первый и последний адреса IP в анонсируемом диапазоне. При IP Version = 4 эти поля нужно делать 32-битовыми, при IP Version = 6 – 128-битовыми. Значение Start IP Address должно быть не меньше End IP Address.

IP Protocol

Номер протокола IP для трафика, который может передаваться в этот диапазон, указанный 8-битовым целым числом без знака. Значение 0 разрешает все протоколы, все прочие представляют дозволенные значения следующего заголовка в заголовке IP, передаваемом напрямую в дейтаграммах HTTP (внешние заголовки IP). Трафик ICMP разрешён всегда независимо от значения данного поля.

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

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

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

Если несколько диапазонов, использующих один протокол IP, перекрываются, некоторые реализации маршрутных таблиц могут их отвергать. Для предотвращения перекрытия диапазоны упорядочиваются, это возлагается на отправителя и существенно упрощает проверку у получателя. Если IP Address Range A предшествует IP Address Range B в одной капсуле ROUTE_ADVERTISEMENT, должны соблюдаться приведённые ниже требования.

  • Значение IP Version в A должно быть не больше IP Version в B.

  • Если поля IP Version в A и B совпадают, значение IP Protocol в A должно быть не больше IP Protocol в B.

  • Если поля IP Version и IP Protocol в A и B совпадают, значение End IP Address в A должно быть строго меньше Start IP Address в B.

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

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

4.8. Заголовки расширения IPv6

В области действия запроса (параграф 4.6) и капсуле ROUTE_ADVERTISEMENT (параграф 4.7.3) применяются номера протоколов IP. Эти номера представляют вышележащий уровень (см. раздел 2 в [IPv6] с примерами для TCP и UDP) или заголовки расширения IPv6 (см. раздел 4 в [IPv6] с примерами заголовков Fragment и Options). IP-прокси могут отклонять запросы на область действия для номеров протоколов, которые используются для заголовков расширения. При получении пакетов реализации, поддерживающие установку области действия или маршрутизацию по номеру протокола IP, должны пройти по цепочке расширений для обнаружения самого внешнего номера протокола, не являющегося расширением, для сопоставления с областью действия. Отметим, что в капсулах ROUTE_ADVERTISEMENT используется номер протокола 0 для разрешения всех протоколов. Это не ограничивает маршрут заголовком IPv6 Hop-by-Hop Options (параграф 4.3 в [IPv6]).

5. Идентификаторы контекста

Заданный в этом документе механизм проксирования IP в HTTP позволяет будущим расширениям обмениваться дейтаграммами HTTP с семантикой, отлично от содержимого IP (payload). Некоторые из таких расширений могут дополнять содержимое IP данными или сжимать заголовки IP, а другие – обмениваться данными, которые полностью отделены от содержимого IP. Для этого все дейтаграммы HTTP, связанные с запросами проксирования IP, начинаются с поля Context ID, как описано в разделе 6.

Context ID указывается 62-битовым целым числом (0 262-1). Значения Context ID кодируются с переменным размером, как указано в разделе 16 [QUIC]. Значение 0 зарезервировано для содержимого IP (payload), все прочие выделяются динамически, чётные значения выделяются клиентам, нечётные – прокси. Пространство Context ID привязано к данному запросу HTTP и Context ID с одинаковым значением могут выделяться в разных запросах и иметь разную семантику. Значения Context ID недопустимо повторно выделять в данном запросе HTTP, но для них можно использовать любой порядок. Ограничения на использование чётных и нечётных Context ID введены для избавления от необходимости синхронизации между конечными точками. Однако после назначения Context ID эти ограничения не применяются к использованию идентификатора и его может использовать как клиент, так и IP-прокси, независимо от того, кто назначил идентификатор.

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

6. Формат содержимого дейтаграмм HTTP

Связанные с запросом проксирования IP поля HTTP Datagram Payload в дейтаграммах HTTP (см. [HTTP-DGRAM]) имеют формат, показанный на рисунке 13. Отметим, что при кодировании дейтаграмм HTTP в кадры QUIC DATAGRAM поле Context ID, определённое ниже, следует сразу за полем Quarter Stream ID, которое размещается вв начале содержимого (payload) кадра QUIC DATAGRAM.

IP Proxying HTTP Datagram Payload {
  Context ID (i),
  Payload (..),
}

Рисунок . Формат дейтаграммы HTTP для проксирования IP.

Поля IP Proxying HTTP Datagram Payload описаны ниже.

Context ID

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

Payload

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

Пакеты IP, кодируются с использованием дейтаграмм HTTP с Context ID – 0. В этом случае поле Payload содержит полный пакет IP (от поля IP Version до последнего байта IP payload).

7. Обработка пакетов IP

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

7.1. Канальные операции

Описанные в этом документе туннели для пересылки IP не являются полнофункциональными «интерфейсами» в смысле архитектуры адресации IPv6 [IPv6-ADDR]. В частности, у них может не быть адресов IPv6 link-local. Кроме того, на этих интерфейсах не применяется автоматическая настройка IPv6 без учёта состояния и обнаружение соседей.

При использовании HTTP/2 или HTTP/3 клиент может оптимистично начать отправку проксируемых пакетов IP до получения отклика на ской запрос проксирования, понимая, что IP-прокси может не обработать их, если он ответит отказом или дейтаграммы будут получены IP-прокси до приёма запроса. Поскольку приёмные адреса и маршруты нужны, чтобы знать о возможности передачи пакета через туннель, такие оптимистические пакеты могут отбрасываться IP-прокси, если тот решит предоставить не те адреса или данные маршрутизации, нежели предположил клиент.

Отметим, что в один пакет может быть инкапсулировано несколько проксируемых пакетов IP, поскольку пакет QUIC может включать не один кадр QUIC DATAGRAM. Возможно также разделение проксируемого пакета IP между несколькими инкапсулирующими пакетами, поскольку капсулу DATAGRAM можно распределить между несколькими пакетами QUIC или TCP.

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

Требования этого раздела повторяют требования к маршрутизаторам IP в целом и могут не относиться к реализациям проксирования IP, полагающимися на маршрутизацию внешними программами.

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

В другом направлении при получении конечной точкой пакета IP она проверяет его соответствие маршрутам, сопоставленным с туннелем, и выполняет указанные выше проверки перед отправкой пакета в дейтаграмме HTTP.

При пересылке конечными точками IP-проксирования пакетов IP между разными каналами они декрементируют IP Hop Count (или TTL) при инкапсуляции, но не делают этого при декапсуляции. Иными словами, Hop Count уменьшается непосредственно перед отправкой пакета IP в дейтаграмме HTTP. Это предотвращает петли при наличии маршрутных петель и соответствует вариантам IPsec [IPSEC]. Сказанное не применяется к пакетам IP, созданных самой конечной точкой проксирования IP.

Разработчики должны убедиться, что трафик link-local не пересылается за пределы интерфейса проксирования IP, на котором он был получен. Конечные точки проксирования IP должны также отвечать на пакеты, направленные по групповому адресу link-local.

IPv6 требует на каждом канале значение MTU не менее 1280 байтов [IPv6]. Поскольку при проксировании IP в HTTP пакеты IP передаются в дейтаграммах HTTP, которые, в свою очередь, могут передаваться в кадрах QUIC DATAGRAM, которые не могут фрагментироваться [DGRAM], значение MTU в туннеле IP может быть ограничено MTU соединения QUIC, через которое работает проксирование IP. Это может приводить к нарушению требования IPv6 к минимальному значению MTU. Конечные точки проксирования IP, работающие как маршрутизаторы и поддерживающие IPv6, должны убедиться, что MTU в канале IP-туннеля не менее 1280 байтов (т. е. можно отправлять дейтаграммы HTTP с размером данных не менее 1280 байтов). Это можно обеспечить разными методами.

  • Если обе конечных точки проксирования IP знают об отсутствии на пути посредников HTTP, они могут заполнять (pad) пакеты QUIC INITIAL внешнего соединения QUIC, через которое работает проксирование IP3.

  • Конечные точки проксирования IP могут также передавать пакеты запросов ICMPv6 echo со 1232 байтами данных для определения MTU канала и разрывать туннель при отсутствии ответа. Если у конечных точек нет автономных (out-of-band) средств, гарантирующих достаточность предыдущих методов, они должны применять этот метод. Если конечная точка не знает адреса IPv6 своего партнера, она может передать запрос ICMPv6 echo по групповому адресу link-local для всех узлов (ff02::1).

Если конечная точка использует кадры QUIC DATAGRAM для передачи пакетов IPv6 и обнаруживает, что значение QUIC MTU слишком мало для передачи 1280 байтов, она должна прервать поток запроса проксирования IP.

7.2.1. Сигналы об ошибках

Поскольку конечные точки проксирования IP часто пересылают пакеты IP на другие сетевые интерфейсы, им нужно обрабатывать ошибки в процессе такой пересылки. Например, при пересылке может возникнуть отказ, связанный с отсутствием у конечной точки маршрута к адресату, если она настроена правилами на отклонение префикса адресата, или MTU исходящего канала меньше размера пересылаемого пакета. В таких ситуациях конечным точкам проксирования IP следует использовать ICMP [ICMP] [ICMPv6] для сигнализации ошибок пересылки своему партнёру в пакетах ICMP, передаваемых серез дейтаграммы HTTP. Конечная точка может самостоятельно выбирать подходящие сообщения ICMP для передачи ошибок. Некоторые примеры, актуальные для проксирования IP указаны ниже.

  • Для недействительных адресов источника применяется Destination Unreachable (параграф 3.1 в [ICMPv6]) с кодом 5 Source address failed ingress/egress policy (несоответствие правилам для адреса источника).

  • Для немаршрутизируемых адресов получателей применяется Destination Unreachable (параграф 3.1 в [ICMPv6]) с кодом 0 No route to destination (нет маршрута к получателю) или 1 Communication with destination administratively prohibited (связь с адресатом запрещена административно).

  • Для пакетов, не помещающихся в размер MTU на выходном канале применяется Packet Too Big (параграф 3.2 в [ICMPv6]).

Для получения таких сведений об ошибках конечные точки должны быть готовы принимать пакеты ICMP. Если конечная точка не передаёт капсулы ROUTE_ADVERTISEMENT, например, из-за того, что клиент открывает поток IP через IP-прокси, ей следует обрабатывать проксируемые пакеты ICMP от своего партнёра для получения сведений об ошибках. Отметим, что сообщения ICMP могут приходить с адреса, отличающегося от адреса партнёра и даже извне цели, если применяется установка области действия (см. параграф 4.6).

8. Примеры

IP-проксирование в HTTP позволяет реализовать множество сценариев с использованием преимуществ проксирования и туннелирования пакетов IP. Представленные ниже примеры служат иллюстрациями этого.

8.1. VPN для удалённого доступа

Ниже приведён пример организации туннеля VPN в сеть, где клиент получает набор локальных адресов и может передавать любому удалённому хосту через IP-прокси. Туннель может быть полным или расщепленным.

+--------+ IP A          IP B +--------+           +---> IP D
|        +--------------------+   IP-  | IP C      |
| Клиент | IP-подсеть C <--> ?| прокси +-----------+---> IP E
|        +--------------------+        |           |
+--------+                    +--------+           +---> IP ...

Рисунок . Организация туннеля VPN.


Клиент в этом случае не задаёт для запроса область действия. IP-прокси назначает клиенту адрес IPv4 (192.0.2.11) и туннельный маршрут ко всем адресам IPv4 (0.0.0.0/0). Клиент может взаимодействовать с любым хостом IPv4, используя назначенный адрес в качестве адреса источника.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /vpn
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

   STREAM(44): DATA
   Capsule Type = ADDRESS_REQUEST
   (Request ID = 1
    IP Version = 4
    IP Address = 0.0.0.0
    IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 1
                                  IP Version = 4
                                  IP Address = 192.0.2.11
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 0.0.0.0
                                  End IP Address = 255.255.255.255
                                  IP Protocol = 0) // Any

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated IP Packet

Рисунок . Пример полного туннеля VPN.

Настройка расщеплённого туннеля VPN (клиент имеет доступ лишь к конкретному набору приватных адресов) достаточно похожа. В этом случае анонсируется маршрут 192.0.2.0/24 вместо 0.0.0.0/0.

   [[ От клиента ]]              [[ От IP-прокси ]]

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 192.0.2.42
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 192.0.2.0
                                  End IP Address = 192.0.2.41
                                  IP Protocol = 0) // Any
                                 (IP Version = 4
                                  Start IP Address = 192.0.2.43
                                  End IP Address = 192.0.2.255
                                  IP Protocol = 0) // Any

Рисунок . Пример расщеплённого туннеля VPN.

8.2. VPN между сайтами

Ниже показано, как подключить сеть филиала к корпоративной сети, чтобы све машины этих сетей могли взаимодействовать. В примере клиент проксирования IP подключён к сети филиала 192.0.2.0/24, а IP-прокси – к корпоративной сети 203.0.113.0/24. В сети филиала имеются унаследованные клиенты, которые поддерживают запросы лишь от машин своей подсети, поэтому IP-прокси назначается адрес IP из этой подсети.

192.0.2.1 <--+   +--------+                +-------+   +---> 203.0.113.9
             |   |        +----------------+  IP-  |   |
192.0.2.2 <--+---+ Клиент |проксирование IP| прокси+---+---> 203.0.113.8
             |   |        +----------------+       |   |
192.0.2.3 <--+   +--------+                +-------+   +---> 203.0.113.7

Рисунок . Пример VPN между сайтами.

Клиент в этом случае не задаёт для запроса область действия. IP-прокси назначает клиенту адрес IPv4 (203.0.113.100) и маршрут с расщепленным туннелем в корпоративную сеть (203.0.113.0/24). Клиент назначает IP-прокси адрес IPv4 (192.0.2.200) и маршрут с расщепленным туннелем в сеть филиала (192.0.2.0/24). Это позволяет хостам обеих сетейц взаимодействовать между собой, а IP-прокси – поддерживать устаревшие хосты в сети филиала. Отметим, что конечные точки проксирования IP будут декрементировать IP Hop Count (или TTL) при декапсуляции пересылаемых пакетов, поэтому протоколы, требующие с поле значения 255, не будут работать.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /corp
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

   STREAM(44): DATA
   Capsule Type = ADDRESS_ASSIGN
   (Request ID = 0
   IP Version = 4
   IP Address = 192.0.2.200
   IP Prefix Length = 32)

   STREAM(44): DATA
   Capsule Type = ROUTE_ADVERTISEMENT
   (IP Version = 4
   Start IP Address = 192.0.2.0
   End IP Address = 192.0.2.255
   IP Protocol = 0) // Any

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 203.0.113.100
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 203.0.113.0
                                  End IP Address = 203.0.113.255
                                  IP Protocol = 0) // Any

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated IP Packet

Рисунок . Пример капсулы для VPN между сайтами.

8.3. Пересылка потока IP

В следующем примере показана организация пересылки потоков IP, где клиент запрашивает создание туннеля для пересылки в target.example.com с использванием протокола управлегния потоковой передачей (Stream Control Transmission Protocol или SCTP, протокол IP 132) и получает 1 локальный адрес и удалённый адрес, который можно применять для передачи пакетов. Аналогичный подход можно применять для любого протокола IP, который не так просто проксировать с помощью имеющихся методов HTTP , например, ICMP, ESP4 и т. п.


+--------+ IP A         IP B +--------+
|        +-------------------+   IP-  | IP C
| Клиент |    IP C <--> D    | прокси +---------> IP D
|        +-------------------+        |
+--------+                   +--------+

Рисунок . Организация потока с проксированием.

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

IP-прокси назначает клиенту 1 адрес IPv6 (2001:db8:1234::a) и маршрут к 1 хосту IPv6 (2001:db8:3456::b) с привязкой к протоколу SCTP. Клиент может обмениваться с удаленным хостам пакетами SCTP.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /proxy?target=target.example.com&ipproto=132
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 6
                                  IP Address = 2001:db8:1234::a
                                  IP Prefix Length = 128)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 6
                                  Start IP Address = 2001:db8:3456::b
                                  End IP Address = 2001:db8:3456::b
                                  IP Protocol = 132)

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated SCTP/IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated SCTP/IP Packet

Рисунок . Пример проксирования потока SCTP.

8.4. Одновременное проксирование соединений

В следующем примере показана схема, где клиент проксирует пакеты UDP через IP-прокси для организации одновременных управляющих соединений через IP-прокси, как описано в Happy Eyeballs [HEv2]. Это является вариантом проксируемого потока, но показывает, как проксирование на уровне IP может открывать новые возможности даже для TCP и UDP.

+--------+ IP A         IP B +--------+ IP C
|        +-------------------+        |<------------> IP E
| Клиент |  IP C <--> E      |   IP-  |
|        |     D <--> F      | прокси |
|        +-------------------+        |<------------> IP F
+--------+                   +--------+ IP D

Рисунок . Одновременное проксирование соединений.


Как и в случае проксирования потоков, клиент задаёт имя целевого хоста и протокол IP в области действия своего запроса. Когда IP-прокси выполняет распознавание имён DNS от имени клиента, он может передавать клиенту различные варианты удалённого адреса как отдельные маршруты. Можно также убедиться, что клиенты назначены как адреса IPv4, так и IPv6.

IP-прокси выделяет клиенту адреса IPv4 (192.0.2.3) и IPv6 (2001:db8:1234::a), а также маршруты IPv4 (198.51.100.2) и IPv6 (2001:db8:3456::b), представляющие распознанные адреса целевого хоста, с привязкой к UDP. Клиент может обмениваться пакетами UDP IP с одним из адресов IP-прокси для поддержки Happy Eyeballs через IP-прокси.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /proxy?target=target.example.com&ipproto=17
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 192.0.2.3
                                  IP Prefix Length = 32),
                                 (Request ID = 0
                                  IP Version = 6
                                  IP Address = 2001:db8::1234:1234
                                  IP Prefix Length = 128)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 198.51.100.2
                                  End IP Address = 198.51.100.2
                                  IP Protocol = 17),
                                 (IP Version = 6
                                  Start IP Address = 2001:db8:3456::b
                                  End IP Address = 2001:db8:3456::b
                                  IP Protocol = 17)
   ...

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IPv6 Packet

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IPv4 Packet

Рисунок . Пример одновременных соединений.

9. Вопросы расширяемости

Расширения IP-проксирования в HTTP могут менять поведение описанного механизма. Таким расширениям следует определять новые типы капсул для обмена конфигурационными сведениями, если это требуется. Расширениям, меняющим адресацию, рекомендуется задавать передачу своих капсул расширения до ADDRESS_ASSIGN и вводить их в действие лишь после анализа капсулы ADDRESS_ASSIGN. Это позволяет обеспечить неделимость изменённого назначения адресов. Расширениям, меняющим маршрутизацию, следует вести себя аналогично по отношению к капсулам ROUTE_ADVERTISEMENT.

10. Вопросы производительности

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

При использовании работающим в туннеле протоколом контроля перегрузки (например, [TCP] или [QUIC]), проксируемый трафик будет иметь по меньшей мере два вложенных контроллера перегрузок. При передаче туннелируемых пакетов с использованием кадров QUIC DATAGRAM внешнее соединение HTTP может отключать контроль перегрузки для пакетов, содержащих лишь кадры QUIC DATAGRAM, инкапсулирующие пакеты IP. Разработчикам будет полезно обратиться к рекомендациям параграфа 3.1.11 в [UDP-USAGE].

При использовании работающим в туннеле протоколом восстановления потерь (например, [TCP] или [QUIC]) и работе внешнего соединения HTTP по протоколу TCP проксируемый трафик будет иметь по меньшей мере два вложенных механизма восстановления потерь. Это может снижать производительность, поскольку иногда оба механизма могут независимо передавать повторно одни и те же данные. Для предотвращения этого проксирование IP следует организовывать через HTTP/3, где можно использовать кадры QUIC DATAGRAM.

10.1. MTU

При использовании HTTP/3 с расширением QUIC Datagram [DGRAM] пакеты IP передаются в кадрах QUIC DATAGRAM. Поскольку эти кадры не могут фрагментироваться, в них можно передавать лишь данные, размер которых определяется конфигурацией соединения QUIC и Path MTU (PMTU). Если конечная точка использует кадры QUIC DATAGRAM и пытается маршрутизировать через туннель пакеты IP, которые не помещаются в кадр QUIC DATAGRAM, IP-прокси не следует передавать такие пакеты в капсуле DATAGRAM, поскольку это нарушает сквозные параметры надёжности от которых зависят такие методы, как DPLPMTUD5 [DPLPMTUD]. В этом случае конечной точке следует отбросить пакет IP и передать его отправителю сообщение ICMP Packet Too Big (см. параграф 3.2 в [ICMPv6]).

10.2. ECN

Если конечная точка проксирования IP с соединением, содержащим поток запроса проксирования IP, отключает контроль перегрузки, она не может передавать явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) [ECN] в этом внешнем соединении. Т. е. отправитель QUIC должен помещать во все заголовки IP код Not-ECT6 для пакетов QUIC, на которые не распространяется контроль перегрузок. Конечная точка все ещё может передавать обратную связь ECN в кадрах QUIC ACK_ECN или бите TCP ECN-Echo (ECE), поскольку партнёр мог не отключить контроль перегрузки.

Если контроль перегрузки не отключён на внешнем соединении, рекомендации [ECN-TUNNEL] для передачи маркировки ECN между внутренним и внешним заголовком IP не применяются, поскольку внешнее соединение будет корректно реагировать на перегрузки при использовании ECN. Для внутреннего трафика также можно применять ECN независимо от использования на внешнем соединении.

10.3. Дифференцированное обслуживание

Туннелируемые пакеты IP могут иметь коды дифференцированного обслуживания (Differentiated Services Code Point или DSCP) [DSCP] в поле класса трафика в заголовке IP для запроса определённого поведения на этапах пересылки (per-hop behavior). Если конечная точка проксирования IP настроена как часть домена с дифференцированным обслуживанием, она может дифференцировать трафик на основе этой маркировки. Однако использование HTTP может ограничивать возможности дифференцированной обработки туннелируемых пакетов IP на пути между конечными точками проксирования IP.

Когда в соединении HTTP контролируется перегрузка, маркировка пакетов разными кодами DSCP может приводить к нарушению порядка доставки, а это, в свою очередь, – к плохой работе транспортного контроллера перегрузки. Если туннелируемые пакеты подвергаются контролю перегрузки на внешнем соединении, для них нужно избегать маркировки DSCP, которая не эквивалентна поведению при пересылке. В этом случае конечной точке проксирования IP недопустимо копировать поле DSCP из внутреннего заголовка IP во внешний заголовок. Вместо этого приложение должно использовать отдельные соединения с прокси для каждого кода DSCP. Отметим, что этот документ не задаёт способ связывания области действия запросов с конкертным значением DSCP (оставлено для будущих расширений).

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

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

Предоставление произвольным клиентам возможности создавать туннели, позволяющие передавать данные произвольным хостам независимо от привязки этих туннелей у конкретным хостам, сопряжено со значительными рисками. Злоумышленники могут воспользоваться этой возможностью для отправки трафика, приписывая его IP-прокси. Серверам HTTP, поддерживающим проксирование IP, следует предоставлять эту возможность лишь уполномоченным пользователям. В зависимости от развёртывания возможные механизмы аутентификации включают TLS между конечными точками проксирования IP, аутентификацию на основе HTTP с помощью заголовка HTTP Authorization [HTTP] и даже маркеры носителя (bearer). Прокси могут применять правила для аутентифицированных пользователей, чтобы дополнительно ограничивать поведение клиентов или бороться с возможными злоупотреблениями. Например, прокси могут ограничивать скорость для отдельных клиентов, передающих слишком большой объем трафика через прокси. Можно также ограничивать назначение клиентам адресов и префиксов на основе неких атрибутов клиента, таких как географическое местоположение.

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

Фальсификация IP-адресов источника часто применяется для организации атак с отказом в обслуживании (denial-of-service или DoS). Реализация описанного здесь механизма должна убедиться, что она не будет способствовать таким атакам. В частности, возможны случаи, когда конечная точка знает, что её партнёру разрешено передавать пакеты IP лишь из определённого префикса. Например, это может быть обусловлено получением конфигурационных данных по отдельному каналу (out-of-band) или обобщением разрешённых префиксов через капсулы ADDRESS_ASSIGN. В таких случаях конечные точки должны следовать рекомендациям [BCP38] для предотвращения подмены адреса источника.

Ограничение области действия запроса (параграф 4.6) позволяет двум клиентам использовать один из внешних IP-адресов прокси, если их запросы привязаны к разным номерам протоколов IP. Если прокси получает пакет ICMP, направленный на такой внешний адрес, он может переслать его клиентам. Однако в некоторых пакетах ICMP содержится часть пакета IP, вызвавшего отклик ICMP. Пересылка таких пакетов может привести к случайному раскрытию сведений о клиенте другм клиентам. Для предостврщения этого прокси, пересылающие ICMP по общему для клиентов внешнему адресу, должны проверять вызывающие отклик пакеты внутри ICMP и пересылать пакет ICMP лишь клиенту, для которого область действия соответствует вызвавшему отклик пакету.

Разрабочикам будет полезно ознакомиться с рекомендациями [TUNNEL-SECURITY]. Пскольку известны риски, связанные с некоторыми заголовками расширения IPv6 (например, [ROUTING-HDR]), разработчики должны следовать последним рекомендациям по работе с такими заголовками.

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

Приспосабливающаяся (opportunistic) отправка пакетов IP (параграф 7.1) не разрешается в HTTP/1.x, поскольку сервер может отклонить HTTP Upgrade и пытаться проанализировать пакеты IP как последующие запросы HTTP, что позволит организовать атаку с контрабандой (smuggling) запросов (см. [OPTIMISTIC]). В частности, посреднику, перекодирующему запрос из HTTP/2 или HTTP/3 в HTTP/1.1, недопустимо пересылать полученные капсулы, пока он не проанализировал отклик об успешном проксировании IP.

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

12.1. Регистрация маркера HTTP Upgrade

Агентство IANA включило connect-ip в реестр HTTP Upgrade Tokens (https://www.iana.org/assignments/http-upgrade-tokens).

   Value:  connect-ip
   Description:  Proxying of IP Payloads
   Expected Version Tokens:  None
   References:  RFC 9484

12.2. Создание реестра MASQUE URI Suffixes

В IANA создан реестр MASQUE URI Suffixes (https://www.iana.org/assignments/masque) с процедурой регистрации Expert Review (параграф 4.5 в [IANA-POLICY]). В новый реестр включается сегмент пути, следующий сразу после masque в путях, начинающихся с /.well-known/masque/ (элемент masque зарегистрирован в реестре Well-Known URIs, https://www.iana.org/assignments/well-known-uris).

Новый реестр включает три колонки.

Path Segment – сегмент пути

Строка ASCII с символами, разрешенными для маркеров (см. параграф 5.6.2 в [HTTP]. Записи реестра должны иметь уникальные значения в этой колонке.

Description – описание

Описание записи.

Reference – документ

Необязательная ссылка на описание использования записи.

Исходное содержимое реестра приведено в таблице 1.

Таблица . Реестр MASQUE URI Suffixes.

 

Сегмент пути

Описание

Документ

udp

UDP Proxying

RFC 9298

ip

IP Proxying

RFC 9484

 

Назначенным экспертам для этого реестра рекомендуется одобрять все запросы, если эксперт считает, что (1) запрошенное значение Path Segment не конфликтует с имеющимися и ожидаемыми в будущих работах IETF и (2) вариант использования связан с проксированием.

12.3. Обновление регистрации общеизвестного URI для masque

Агентство IANA обновило запись для суффикса URI masque в реестре Well-Known URIs (https://www.iana.org/assignments/well-known-uris). Обновлено поле Reference указанием на этот документ, а в поле Related Information указано For sub-suffix allocations (см. https://www.iana.org/assignments/masque).

12.4. Регистрация типов капсул HTTP

Агентство IANA добавило указанные в таблице 2 значения в реестр HTTP Capsule Types (https://www.iana.org/assignments/masque).

Таблица . Новые капсулы.

 

Значение

Тип капсулы

0x01

ADDRESS_ASSIGN

0x02

ADDRESS_REQUEST

0x03

ROUTE_ADVERTISEMENT

 

Значения других полей для всех новых записей показаны ниже.

   Status:  permanent
   Reference:  RFC 9484
   Change Controller:  IETF
   Contact:  masque@ietf.org 
   Notes:  None

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

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

[ABNF] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[BCP38] Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.

[DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, “An Unreliable Datagram Extension to QUIC”, RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.

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

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

[EXT-CONNECT2] McManus, P., “Bootstrapping WebSockets with HTTP/2”, RFC 8441, DOI 10.17487/RFC8441, September 2018, <https://www.rfc-editor.org/info/rfc8441>.

[EXT-CONNECT3] Hamilton, R., “Bootstrapping WebSockets with HTTP/3”, RFC 9220, DOI 10.17487/RFC9220, June 2022, <https://www.rfc-editor.org/info/rfc9220>.

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

[HTTP-DGRAM] Schinazi, D. and L. Pardue, “HTTP Datagrams and the Capsule Protocol”, RFC 9297, DOI 10.17487/RFC9297, August 2022, <https://www.rfc-editor.org/