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

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 7719                                         ICANN
Category: Informational                                      A. Sullivan
ISSN: 2070-1721                                                      Dyn
                                                             K. Fujiwara
                                                                    JPRS
                                                           December 2015

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

DNS Terminology

PDF

Аннотация

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

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

Этот документ не относится к категории проектов стандартов и публикуется с информационными целями.

Документ является результатом работы IETF¹ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG². Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

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

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

1. Введение

DNS³ представляет собой простой протокол «запрос-отклик», в котором сообщения запросов и откликов имеют одинаковый формат. Протокол и формат сообщений определены в [RFC1034] и [RFC1035]. В этих документах определены некоторые термины, а в более поздних документах определены другие термины. Трактовка некоторых терминов из RFC 1034 и 1035 с 1987 года изменилась.

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

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

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

Термины в документе организованы по темам. Даны определения некоторых терминов, применяемых в сообществе DNS, но не определенных ранее.

Связанные с DNS термины иногда определяют и другие организации. Например, W3C определяет термин domain (см. https://specs.webplatform.org/url/webspecs/develop/).

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

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

2. Имена

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

В параграфе 3.1 документа [RFC1034] сказано: «Пространство имен имеет структуру дерева. … Каждый узел имеет метку размером от 0 до 63 октетов. … Доменное имя узла представляет собой список меток на пути от узла до корня дерева. … Для упрощения реализации общее число октетов, представляющих доменное имя (т. е., октетов меток и их размеров), ограничено значением 255.⁴» Любая метка в доменном имени может содержать произвольные октеты.

Fully qualified domain name (FQDN) — полное доменное имя

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

Необходимость термина «fully qualified domain name» обусловлена использованием частичных (локальных) доменных имен, когда имя указывается относительно того или иного домена, который не указывается в записи.

Label — метка

Идентификатор отдельного узла в последовательности узлов, идентифицируемой полным доменным именем.

Host name — имя хоста

Этот термин и его эквивалент hostname используются достаточно широко, но не были определены в [RFC1034], [RFC1035], [RFC1123] и [RFC2181]. DNS изначально была развернута в среде Host Table, как описано в [RFC952], и данный термин произошел оттуда. Со временем трактовка термина претерпела изменения. Сейчас термин Host name обычно означает доменное имя в соответствии с правилами параграфа 3.5. Синтаксис имен в [RFC1034]. Напомним, что любая метка в доменном имени может содержать любое октетное значение, именами хостов обычно называют метки, соответствующие правилам для синтаксиса имен, с поправкой на то, что метки могут начинаться с цифр в кодировке ASCII (поправка взята из параграфа 2.1 [RFC1123]).

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

TLD — домен верхнего уровня

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

IDN

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

Subdomain — субдомен

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

Alias — псевдоним

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

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

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

CNAME

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

Public suffix — общественный суффикс, суффикс общего пользования

«Домен, контролируемый публичным регистратором.» ([RFC6265], параграф 5.3). В соответствии с общим определением данный термин означает домен, в котором могут быть зарегистрированы субдомены, и для которого не должны устанавливаться HTTP-куки ([RFC6265]). В доменных именах нет индикации общественного суффикса, его можно определить только с использованием внешних средств. Фактически, общественным суффиксом может быть как домен, так и его субдомены. На момент публикации данного документа рабочая группа IETF DBOUND [DBOUND] занималась вопросами, связанными с общественными суффиксами. Одним из ресурсов для идентификации общественных суффиксов является список PSL⁸, поддерживаемый Mozilla (http://publicsuffix.org/).

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

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

3. Заголовок и коды откликов DNS

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

Некоторые из определенных в [RFC1035] получили сокращенные имена. Имена кодов откликов общего назначения, которые приводятся без числовых значений, включают FORMERR, SERVFAIL, NXDOMAIN (последний называют также «ошибкой в имени» — Name Error). Все значения RCODE перечислены в http://www.iana.org/assignments/dns-parameters, (на сайте используются обозначения строчными и прописными символами, но во многих документах применяются только заглавные буквы).

NODATA

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

Иногда используют термин NXRRSET в качестве синонима NODATA. Однако это ошибка, поскольку NXRRSET является кодом конкретной ошибки, определенным в [RFC2136].

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

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

Referrals — отсылки

Данные из раздела authority неполномочного (non-authoritative) ответа. В параграфе 2.1 [RFC1035] приведено определение «полномочных» данных. Однако отсылки на срезах зон (см. раздел 6) не являются полномочными. Отсылки могут быть записями NS на срезе зоны и их склеивающими записями. Записи NS на родительской стороне среза являются полномочным делегированием, но обычно не трактуются, как полномочные данные. В общем случае отсылка является для сервера способом передачи ответа, говорящим, что сервер не знает ответа, но знает, куда следует направить запрос для получения ответа. Исторически многие полномочные серверы отвечали отсылками к корневым серверам по запросам имен, для которых у них нет полномочий, но такая практика была отменена.

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

RR

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

RRset

Набор записей о ресурсах с одной меткой, классом и типом, но разными данными (определение из [RFC2181]). В некоторых документах используется также обозначение RRSet. Слова «одна метка» (same label) в этом определении означают «одного владельца имен» (same owner name). В дополнение к этому в [RFC2181] сказано, что «значения TTL всех RR в RRSet должны совпадать» (это явно отличается от «отклик на запрос для QTYPE=ANY», что является явным недоразумением).

EDNS

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

OPT

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

Owner

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

Имена полей SOA

В документах DNS, включая определения этого документа, часто указывают поля RDATA записей о ресурсах SOA по именам этих полей. Это поля, определенные в параграфе 3.3.13 [RFC1035]. Именами (в порядке размещения в SOA RDATA) являются MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE и MINIMUM.

Отметим, что значение поля MINIMUM изменено в разделе 4 [RFC2308] и в соответствии с новым определением поле MINIMUM указывает лишь «TTL для негативных откликов». В этом документе используются имена полей вместо их описаний.

TTL

Максимальное «время жизни» записи для ресурса. «TTL представляет собой целое число без знака с минимальным значением 0 и максимальным 2147483647 (т. е., 2³¹ — 1). При передаче это значение следует помещать в младшие биты (31) 32-битового поля TTL, устанавливая для старшего бита (знак) нулевое значение.⁹» (цитата из раздела 8 [RFC2181]).

TTL «задает временной интервал, в течение которого запись может кэшироваться прежде, чем снова возникнет необходимость обращения к источнику данных.» (цитата из параграфа 3.2.1 [RFC1035]) Также это значение «задает временной интервал (в секундах), в течение которого запись может кэшироваться до ее отбрасывания» (цитата из параграфа 4.1.3 [RFC1035]). Несмотря на то, что это значение определено для записи ресурса, TTL в каждой записи RRset должно иметь одинаковое значение ([RFC2181], параграф 5.2).

Причина того, что TTL называется максимальным временем жизни, заключается в том, что операторы кэширования могут сокращать это время в соответствии со своими целями (например, политика может запрещать значение TTL выше некого порога). Если запись удаляется из кэша при незавершенном сроке жизни, значение на деле становится нулевым. Некоторые серверы игнорируют TTL в части RRset (например, когда полномочные данные имеют слишком малое время жизни TTL), хотя это противоречит RFC 1035.

Имеется также концепция «TTL по умолчанию» для зоны, и это значение может быть конфигурационным параметром серверных программ. Оно часто применяется по умолчанию для всего сервера, а принятое по умолчанию значение для зоны указывают с помощью директивы $TTL в файле зоны. Директива $TTL была добавлена в формат первичного файла [RFC2308].

Class independent

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

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

В этом разделе определены термины, используемые для систем, действующих как клиенты и/или серверы DNS.

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

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

Stub resolver — оконечный распознаватель

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

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

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

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

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

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

Этот термин применяется в [RFC1035], но не определен там. В RFC 1123 определен «полносервисный распознаватель» (full-service resolver), который может (не обязательно) быть полным распознавателем [RFC1035]. Этот термин не определен должным образом в каком-либо RFC.

Full-service resolver — полнофункциональный распознаватель

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

Priming

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

Negative caching — кэширование негативных откликов.

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

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

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

Authoritative-only server — сервер, выполняющий лишь функции полномочного

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

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

Действие клиента, запрашивающего копию зоны, и полномочного сервера, передающего требуемую информацию (см. описание зон в разделе 6). Имеется два базовых стандартных способа переноса зон — AXFR (Authoritative Transfer — полномочный перенос) для копирования всей зоны (описан в [RFC5936] и IXFR (Incremental Transfer — инкрементный перенос) для копирования лишь измененных частей зоны (описан в [RFC1995]). Многие системы применяют нестандартные способы переноса зон, выходящие за рамки протокола DNS.

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

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

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

См. secondary server.

Primary server — первичный (основной) сервер

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

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

См. primary server.

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

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

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

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

Hidden master — спрятанный ведущий сервер

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

Forwarding — пересылка

Процесс, в котором один сервер передает запрос DNS с RD=1 другому серверу для преобразования (resolve). Пересылка является функцией распознавателей DNS и отличается от простой ретрансляции запросов вслепую.

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

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

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

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

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

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

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

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

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

Passive DNS — пассивный DNS

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

Anycast

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

6. Зоны

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

Zone — зона

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

Child — потомок

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

Parent — родитель

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

Origin — источник

(a) «Доменное имя, появляющееся наверху зоны (сразу под срезом, отделяющим зону от ее родителя) называется «источником зоны». Имя зоны совпадает с именем домена в источнике зоны.» (цитата из раздела 6 в [RFC2181]). Сейчас термины origin (источник) и apex (вершина зоны, см. ниже) часто используются взаимозаменяемо.

(b) Имя домена, в котором указывается относительное доменное имя в файлах зоны. Обычно рассматривается в контексте $ORIGIN, который является управляющей записью, определенной в параграфе 5.1 [RFC1035] как часть первичного файла зоны. Например, если $ORIGIN имеет значение «example.org.», строка первичного файла www является фактически записью для «www.example.org.».

Apex — вершина

Точка в дереве у владельца SOA и соответствующего полномочного NS RRset. Используется также термин zone apex. [RFC4033] определяет его как «имя на дочерней стороне среза зоны». Apex можно рассматривать как описание структуры дерева в теории данных, а origin является названием того же понятия при реализации в файле зоны. Однако различие поддерживается не всегда и можно встретиться с толкованиями, противоречащими этому определению. [RFC1034] использует термин «верхний узел зоны» (top node of the zone) как синоним apex, но этот термин не получил широкого распространения. Сейчас термины origin (источник, см. выше) и apex (вершина зоны) часто используются взаимозаменяемо.

Zone cut — срез зоны

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

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

Delegation — передача полномочий

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

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

«[Записи о ресурсах], которые не относятся к полномочным данным зоны и являются RR с адресами [серверов имен в субзонах]. Эти RR требуются только в тех случаях, когда имя сервера имен находится «ниже» среза и используются только, как часть отклика со ссылкой.» Без склеивания «может возникнуть ситуация, когда записи NS RR скажут нам, что для получения адреса сервера имен нам следует обратиться к серверу имен, адрес которого мы хотим узнать» (цитата из параграфа 4.2.1 в [RFC1034])

Более позднее определение говорит, что склеивающие записи включают «имена сервером DNS делегированных субзон (записи NS), адресные записи, сопровождающие эти записи NS (A, AAAA и т. п.), а также любые другие «приблудившиеся» данные» (цитата из параграфа 5.4.1 в [RFC2181]). Хотя сегодня склеивание иной раз трактуется с учетом этого более широкого определения, контекст определения [RFC2181] предполагает, что оно относится к склеиванию в самом документе и не обязательно за его пределами.

In-bailiwick — внутренний (в сфере охвата)

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

(b) Данные, для которых сервер является полномочным или имеет полномочия для родителя владельца имени. Эта трактовка термина обычно применяется при рассмотрении релевантности склеивающих записей в отклике. Например, сервер для родительской зоны example.com может отвечать со склеивающими записями для ns.child.example.com. Поскольку зона child.example.com является потомком example.com, склеивающие записи являются in-bailiwick.

Out-of-bailiwick

Антоним для in-bailiwick.

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

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

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

Зона, вершина которой имеет пустую метку. Называется также корнем DNS (DNS root).

Empty non-terminals — пустые нетерминальные имена

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

Delegation-centric zone — ориентированная на делегирование зона

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

Wildcard — шаблон

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

Occluded name — скрытое имя

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

Fast flux DNS — быстрое изменение DNS

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

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

Registry — регистрация, реестр

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

Registrant — регистрант

Человек или организация, от чьего имени имя в зоне зарегистрировано в реестре. Во многих зонах регистрант сам управляет зоной, но в TLD это зачастую не так.

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

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

EPP

Расширяемый протокол предоставления (EPP¹⁰), который обычно применяется для обмена регистрационными данными между реестрами и регистраторами. EPP определен в [RFC5730].

WHOIS

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

RDAP

Протокол доступа к регистрационным данным (RDAP¹¹), определенный в [RFC7480], [RFC7481], [RFC7482], [RFC7483], [RFC7484] и [RFC7485]. Протокол и формат данных RDAP предназначены для замены WHOIS.

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

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

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

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

DNSSEC-aware и DNSSEC-unaware — понимающие и не понимающие DNSSEC

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

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

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

Следует также отметить, что с момента публикации [RFC6840] записи NSEC больше не требуются для подписанных зон и вместо этого подписанная зона может включать записи NSEC3. В [RFC7129] приведено дополнительное обоснование и некий контекст для механизмов NSEC и NSEC3, применяемых DNSSEC для предоставления аутентифицированных откликов об отсутствии (denial-of-existence response).

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

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

NSEC

«Запись NSEC позволяет защищенному распознавателю аутентифицировать негативный отклик в случаях отсутствия имени или типа с использованием того же механизма, который применяется при аутентификации других откликов DNS.» (цитата из параграфа 3.2 в [RFC4033]). Говоря кратко, запись NSEC обеспечивает аутентифицированную информацию об отсутствии.

«Запись NSEC содержит два отдельных элемента — имя следующего владельца (в каноническом порядке для зоны), содержащего полномочные данные, или точка передачи полномочий (делегирования) NS RRset и множество типов RR, присутствующих в имени владельца NSEC RR» (цитата из раздела 4 в RFC 4034).

NSEC3

Как и NSEC, запись NSEC3 обеспечивает аутентифицированный отклик об отсутствии, однако записи NSEC3 смягчают перечисление зон и поддерживают Opt-Out. Записи NSEC3 определены в [RFC5155].

Отметим, что в [RFC6840] сказано, что [RFC5155] «сейчас считается частью семейства документов DNS Security, описанного в разделе 10 [RFC4033]». Это означает, что некоторые определения из более ранних RFC, где упоминаются лишь записи NSEC, вероятно следует относить к NSEC и NSEC3.

Opt-out

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

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

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

Key signing key (KSK) — ключ подписи ключей

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

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

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

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

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

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

Флаг в DNSKEY RDATA, который «может служить для различения ключей, предназначенных быть защищенными точками входа в зону при построении цепочек доверия, т. е. они указываются (будут указываться) родительскими DS RR или будут настроены как доверенные привязки. Поэтому предлагается устанавливать флаг SEP для ключей, служащих KSK, а не для ключей, используемых как ZSK, а в случаях, когда KSK и ZSK не различаются (т. е. для схемы с однотипными подписями), предлагается устанавливать флаг SEP для всех ключей.» (цитата из параграфа 3.2.3 в [RFC6781]). Отметим, что флаг SEP является лишь подсказкой и его наличие или отсутствие не может служить основанием для отказа от применения данной DNSKEY RR в качестве KSK или ZSK при проверке.

DNSSEC Policy (DP) — политика DNSSEC

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

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

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

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

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

Ниже приведены определения из раздела 5 в [RFC4033].

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

Secure — защищенное

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

Insecure — незащищенное

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

Bogus — подделка

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

Indeterminate — неопределенное

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

Ниже приведены определения из параграфа 4.3 в [RFC4035].

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

Secure — защищенное

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

Insecure — незащищенное

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

Bogus — подделка

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

Indeterminate — неопределенное

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

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

Приведенные в этом документе определения не меняют состояния безопасности для DNS.

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

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.

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

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

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

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

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

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

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

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

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006, <http://www.rfc-editor.org/info/rfc4592>.

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

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

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

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

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

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

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

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

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

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

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

[DBOUND] IETF, «Domain Boundaries (dbound) Working Group», 2015, <https://datatracker.ietf.org/wg/dbound/charter/>.

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

[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, DOI 10.17487/RFC0952, October 1985, <http://www.rfc-editor.org/info/rfc952>.

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

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

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

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

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

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

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

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.

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

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

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

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

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

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

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

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

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

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

[RFC7482] Newton, A. and S. Hollenbeck, «Registration Data Access Protocol (RDAP) Query Format», RFC 7482, DOI 10.17487/RFC7482, March 2015, <http://www.rfc-editor.org/info/rfc7482>.

[RFC7483] Newton, A. and S. Hollenbeck, «JSON Responses for the Registration Data Access Protocol (RDAP)», RFC 7483, DOI 10.17487/RFC7483, March 2015, <http://www.rfc-editor.org/info/rfc7483>.

[RFC7484] Blanchet, M., «Finding the Authoritative Registration Data (RDAP) Service», RFC 7484, DOI 10.17487/RFC7484, March 2015, <http://www.rfc-editor.org/info/rfc7484>.

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

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

Авторы выражают благодарность всем авторам связанных с DNS документов RFC. Комментарии Tony Finch, Stephane Bortzmeyer, Niall O’Reilly, Colm MacCarthaigh, Ray Bellis, John Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, John Klensin, David Black и многих других членов рабочей группы DNSOP оказали существенную помощь при подготовке данного документа.

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

Paul Hoffman

ICANN

Email: paul.hoffman@icann.org

Andrew Sullivan

Dyn

150 Dow Street, Tower 2

Manchester, NH 03101

United States

Email: asullivan@dyn.com

Kazunori Fujiwara

Japan Registry Services Co., Ltd.

Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda

Chiyoda-ku, Tokyo 101-0065

Japan

Phone: +81 3 5215 8451

Email: fujiwara@jprs.co.jp

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

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

nmalykh@protokols.ru

Отменен RFC 9110.

Independent Submission                                M-J. Saarinen, Ed.
Request for Comments: 7693                    Queen's University Belfast
Category: Informational                                    J-P. Aumasson
ISSN: 2070-1721                                        Kudelski Security
                                                           November 2015

The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)

Функция BLAKE2 для криптографического хэширования и кодов аутентификации сообщений

PDF

Аннотация

В этом документе описана криптографическая хэш-функция BLAKE2 и приведена спецификация алгоритма, а также исходный код на языке C для сообщества Internet. Имеется два основных варианта BLAKE2 — BLAKE2b, оптимизированная для 64-битовых платформ и BLAKE2s для более мелких систем. BLAKE2 можно напрямую связать с ключом, что делает функцию эквивалентом кода аутентификации сообщения (Message Authentication Code или MAC).

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

Этот документ не является спецификацией какого-либо стандарта Internet и публикуется с информационными целями.

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

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

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

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

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

1. Введение и терминология

Криптографическую функцию BLAKE2 [BLAKE2] разработали Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, Christian Winnerlein. Имеется два основных варианта функции:

• BLAKE2b (или просто BLAKE2) оптимизирована для 64-битовых систем и выдаёт дайджесты от 1 до 64 байтов.

• BLAKE2s оптимизирована для систем от 8 до 32 битов и выдаёт дайджесты от 1 до 32 байтов.

Обе функции BLAKE2b и BLAKE2s считаются очень безопасными и хорошо работают на любой программной или аппаратной платформе. BLAKE2 не требует специальной конструкции HMAC¹ для аутентификации сообщений с ключам, поскольку она включает встроенный механизм ключей.

Хэш-функцию BLAKE2 могут применять алгоритмы цифровых подписей, а также механизмы проверки подлинности и целостности сообщений в таких приложениях, как инфраструктура открытых ключей (Public Key Infrastructure или PKI), защищённые протоколы связи, облачные хранилища, обнаружение вторжений, криминалистические системы, а также системы контроля версий. Набор BLAKE2 представляет собой более эффективную альтернативу американским алгоритмам защищённого хэширования (US Secure Hash Algorithm) SHA и HMAC-SHA [RFC6234]. BLAKE2s-128 особенно подходит для быстрой и более защищённой замены MD5 и HMAC-MD5 в унаследованных приложениях [RFC6151].

Для облегчения реализации в Приложении A представлена трассировка хэширования BLAKE2b-512, а в Приложении B — BLAKE2s-256. Из-за ограниченного размера документ не содержит полного набора тестовых векторов для BLAKE2.

Справочная реализация BLAKE2b на языке C представлена в Приложении C, а BLAKE2s — в Приложении D. Эти реализации можно проверить с помощью более полного тестового модуля из Приложения E.

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

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

2.1. Параметры

В таблице ниже приведены параметры и диапазоны их значений.

2.2. Другие константы и переменные

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

IV[0..7]

SIGMA[0..9]

p[0..7]

m[0..15]

h[0..7]

d[0..dd-1]

t

f

2.3. Арифметические обозначения

Для действительных (вещественных) значений x определены указанные ниже функции.

floor(x)

ceil(x)

frac(x)

Ниже приведены обозначения операций в псевдокоде.

2**n

a ^ b

a mod b

x >> n = floor(x / 2**n)

x << n = (x * 2**n) mod (2**w)

x >>> n = (x >> n) ^ (x << (w — n))

2.4. Интерпретация слов как байтов с порядком Little-Endian

Все математические операции выполняются на 64-битовыми словами в BLAKE2b и 32-битовыми в BLAKE2s. Разрешены также операции над векторами слов. Векторы индексируются от 0, т. е. первым элементом вектора v из n элементов является v[0], последним — v[n — 1]. Все элементы вектора обозначаются v[0..n-1]. Потоки байтов (октетов) интерпретируются как слова с порядком little-endian, где первым является младший байт. Рассмотрим последовательность из восьми шестнадцатеричных байтов

        x[0..7] = 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF

При интерпретации как 32-битового слова с начального адреса в памяти байты x[0..3] имеют численное значение 0x67452301 или 1732584193. При интерпретации как 64-битового слова байты x[0..7] имеют численное значение 0xEFCDAB8967452301 или 17279655951921914625.

2.5. Блок параметров

Слова блока параметров p[0..7] задаются в виде

     смещение байта:    3 2 1 0     (другие байты)
              p[0] = 0x0101kknn     p[1..7] = 0

Байт nn задаёт размер хэша в байтах, второй (little-endian) байт блока параметров (kk) указывает размер ключа в байтах. Установка kk = 00 задаёт хэширование без ключа. Байты 2 и 3 имеют значение 01, остальные байты блока параметров имеют значение 0.

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

2.6. Вектор инициализации

Константа вектора инициализации (Initialization Vector или IV) математически задаётся в виде

IV[i] = floor(2**w * frac(sqrt(prime(i+1))))

где prime(i) — i-е простое число ( 2, 3, 5, 7, 11, 13, 17, 19 ), а sqrt(x) — квадратный корень из x.

Численные значения IV приведены в реализациях Приложений C и D для BLAKE2b и BLAKE2s, соответственно.

Примечание. BLAKE2b IV совпадает с SHA-512 IV, а BLAKE2s IV — с SHA-256 IV (см. [RFC6234]).

2.7. Распорядок сообщения SIGMA

Перестановки порядка слов в сообщении для каждого раунда в BLAKE2b и BLAKE2s определяются SIGMA. В BLAKE2b две дополнительные перестановки для раундов 10 и 11 — это SIGMA[10..11] = SIGMA[0..1].

3. Обработка BLAKE2

3.1. Функция смешивания G

Функция G смешивает 2 входных слова x и y в 4 слова с индексами a, b, c, d в рабочем векторе v[0..15]. Возвращается полностью изменённый вектор. Константы циклического сдвига (R1, R2, R3, R4) указаны в параграф 2.1.

       FUNCTION G( v[0..15], a, b, c, d, x, y )
       
          v[a] := (v[a] + v[b] + x) mod 2**w
          v[d] := (v[d] ^ v[a]) >>> R1
          v[c] := (v[c] + v[d])     mod 2**w
          v[b] := (v[b] ^ v[c]) >>> R2
          v[a] := (v[a] + v[b] + y) mod 2**w
          v[d] := (v[d] ^ v[a]) >>> R3
          v[c] := (v[c] + v[d])     mod 2**w
          v[b] := (v[b] ^ v[c]) >>> R4
       
          RETURN v[0..15]
       
       END FUNCTION.

3.2. Функция сжатия F

Функция сжатия F принимает в качестве аргументов вектор состояния h, вектор блока сообщений m (при необходимости последний блок дополняется нулями до полного размера блока), счётчик смещения t размером 2w битов и флаг индикации финального блока f. При обработке применяется локальный вектор v[0..15]. Функция F возвращает новый вектор состояния. Число раундов r составляет 12 для BLAKE2b и 10 для BLAKE2s. Раунды нумеруются от 0 до r — 1.

       FUNCTION F( h[0..7], m[0..15], t, f )
       
             // Инициализация локального рабочего вектора v[0..15]
             v[0..7] := h[0..7]              // Первая половина из состояния.
             v[8..15] := IV[0..7]            // Вторая половина из IV.
       
             v[12] := v[12] ^ (t mod 2**w)   // Младшее слово смещения.
             v[13] := v[13] ^ (t >> w)       // Старшее слово смещения.
       
             IF f = TRUE THEN                // Флаг последнего блока?
                v[14] := v[14] ^ 0xFF..FF    // Инверсия всех битов.
             END IF.
       
             // Cryptographic mixing
             FOR i = 0 TO r - 1 DO           // 10 или 12 раундов.
             
                // Перестановка выбора слов сообщения для этого раунда.
                s[0..15] := SIGMA[i mod 10][0..15]
             
                v := G( v, 0, 4,  8, 12, m[s[ 0]], m[s[ 1]] )
                v := G( v, 1, 5,  9, 13, m[s[ 2]], m[s[ 3]] )
                v := G( v, 2, 6, 10, 14, m[s[ 4]], m[s[ 5]] )
                v := G( v, 3, 7, 11, 15, m[s[ 6]], m[s[ 7]] )
             
                v := G( v, 0, 5, 10, 15, m[s[ 8]], m[s[ 9]] )
                v := G( v, 1, 6, 11, 12, m[s[10]], m[s[11]] )
                v := G( v, 2, 7,  8, 13, m[s[12]], m[s[13]] )
                v := G( v, 3, 4,  9, 14, m[s[14]], m[s[15]] )
             
             END FOR
       
             FOR i = 0 TO 7 DO               // XOR двух половин.
                h[i] := h[i] ^ v[i] ^ v[i + 8]
             END FOR.
       
             RETURN h[0..7]                  // Новое состояние.
       
       END FUNCTION.

3.3. Данные заполнения и расчёт дайджеста BLAKE2

Реализации BLAKE2b и BLAKE2s на языке C приведены в Приложениях C и D.

Ввод ключа и данных разбивается (с дополнением) на dd блоков сообщения d[0..dd-1] по 16 слов (bb байтов). При использовании секретного ключа (kk > 0) он заполняется нулевыми байтами и устанавливается как d[0]. В ином случае d[0] — это первый блок данных. Финальный блок d[dd-1] дополняется нулями до bb байтов (16 слов).

Число блоков составляет dd = ceil(kk / bb) + ceil(ll / bb). Однако в особом случае пустого сообщения без ключа (kk = 0, ll = 0) устанавливается dd = 1, d[0] состоит из нулей.

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

        FUNCTION BLAKE2( d[0..dd-1], ll, kk, nn )
        
             h[0..7] := IV[0..7]          // Вектор инициализации IV.
        
             // Блок параметров p[0]
             h[0] := h[0] ^ 0x01010000 ^ (kk << 8) ^ nn
        
             // Процесс дополнения ключа и болков данных.
             IF dd > 1 THEN
                    FOR i = 0 TO dd - 2 DO
                           h := F( h, d[i], (i + 1) * bb, FALSE )
                    END FOR.
             END IF.
        
             // Финальный блок.
             IF kk = 0 THEN
                    h := F( h, d[dd - 1], ll, TRUE )
             ELSE
                    h := F( h, d[dd - 1], ll + bb, TRUE )
             END IF.
        
             RETURN первые nn байтов из сассива слов h[] (little-endian).
        
        END FUNCTION.

4. Стандартные наборы параметров и идентификаторы алгоритмов

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

Разработчикам, адаптирующим BLAKE2 к форматам сообщений на основе ASN.1, следует использовать терево OID при x = 1.3.6.1.4.1.1722.12.2. Один и тот же идентификатор OID может применяться при хэшировании с ключом и без ключа, поскольку в последнем случае ключ просто имеет нулевой размер.

          hashAlgs OBJECT IDENTIFIER ::= {
              iso(1) identified-organization(3) dod(6) internet(1)
              private(4) enterprise(1) kudelski(1722) cryptography(12) 2
          }
          macAlgs OBJECT IDENTIFIER ::= {
              iso(1) identified-organization(3) dod(6) internet(1)
              private(4) enterprise(1) kudelski(1722) cryptography(12) 3
          }

          -- Два варианта BLAKE2 --
          blake2b OBJECT IDENTIFIER ::= { hashAlgs 1 }
          blake2s OBJECT IDENTIFIER ::= { hashAlgs 2 }

          -- Идентификаторы BLAKE2b --
          id-blake2b160 OBJECT IDENTIFIER ::= { blake2b 5 }
          id-blake2b256 OBJECT IDENTIFIER ::= { blake2b 8 }
          id-blake2b384 OBJECT IDENTIFIER ::= { blake2b 12 }
          id-blake2b512 OBJECT IDENTIFIER ::= { blake2b 16 }

          -- Идентификаторы BLAKE2s --
          id-blake2s128 OBJECT IDENTIFIER ::= { blake2s 4 }
          id-blake2s160 OBJECT IDENTIFIER ::= { blake2s 5 }
          id-blake2s224 OBJECT IDENTIFIER ::= { blake2s 7 }
          id-blake2s256 OBJECT IDENTIFIER ::= { blake2s 8 }

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

Этот документ предназначен для предоставления удобного доступа сообщества Internet к открытому исходному коду алгоритма криптографического хэширования BLAKE2. Документ не содержит каикх-либо заявлений о безопасности алгоритма. Подробное криптоаналитическое обоснование приведено в [BLAKE] и [BLAKE2].

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

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

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

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

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

[BLAKE] Aumasson, J-P., Meier, W., Phan, R., and L. Henzen, «The Hash Function BLAKE», January 2015, <https://131002.net/blake/book>.

[BLAKE2] Aumasson, J-P., Neves, S., Wilcox-O’Hearn, Z., and C. Winnerlein, «BLAKE2: simpler, smaller, fast as MD5», January 2013, <https://blake2.net/blake2.pdf>.

[FIPS140-2IG] NIST, «Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program», September 2015, <http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf/>.

[RFC6151] Turner, S. and L. Chen, «Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms», RFC 6151, DOI 10.17487/RFC6151, March 2011, <http://www.rfc-editor.org/info/rfc6151>.

[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, <http://www.rfc-editor.org/info/rfc6234>.

Приложение A. Пример расчета BLAKE2b

Вычисляется хэш без ключа для 3 байтов ASCII abc с использованием BLAKE2b-512 и показаны детали расчета.

          m[16] = 0000000000636261 0000000000000000 0000000000000000
                  0000000000000000 0000000000000000 0000000000000000
                  0000000000000000 0000000000000000 0000000000000000
                  0000000000000000 0000000000000000 0000000000000000
                  0000000000000000 0000000000000000 0000000000000000
                  0000000000000000

   (i= 0) v[16] = 6A09E667F2BDC948 BB67AE8584CAA73B 3C6EF372FE94F82B
                  A54FF53A5F1D36F1 510E527FADE682D1 9B05688C2B3E6C1F
                  1F83D9ABFB41BD6B 5BE0CD19137E2179 6A09E667F3BCC908
                  BB67AE8584CAA73B 3C6EF372FE94F82B A54FF53A5F1D36F1
                  510E527FADE682D2 9B05688C2B3E6C1F E07C265404BE4294
                  5BE0CD19137E2179

   (i= 1) v[16] = 86B7C1568029BB79 C12CBCC809FF59F3 C6A5214CC0EACA8E
                  0C87CD524C14CC5D 44EE6039BD86A9F7 A447C850AA694A7E
                  DE080F1BB1C0F84B 595CB8A9A1ACA66C BEC3AE837EAC4887
                  6267FC79DF9D6AD1 FA87B01273FA6DBE 521A715C63E08D8A
                  E02D0975B8D37A83 1C7B754F08B7D193 8F885A76B6E578FE
                  2318A24E2140FC64

   (i= 2) v[16] = 53281E83806010F2 3594B403F81B4393 8CD63C7462DE0DFF
                  85F693F3DA53F974 BAABDBB2F386D9AE CA5425AEC65A10A8
                  C6A22E2FF0F7AA48 C6A56A51CB89C595 224E6A3369224F96
                  500E125E58A92923 E9E4AD0D0E1A0D48 85DF9DC143C59A74
                  92A3AAAA6D952B7F C5FDF71090FAE853 2A8A40F15A462DD0
                  572D17EFFDD37358

   (i= 3) v[16] = 60ED96AA7AD41725 E46A743C71800B9D 1A04B543A01F156B
                  A2F8716E775C4877 DA0A61BCDE4267EA B1DD230754D7BDEE
                  25A1422779E06D14 E6823AE4C3FF58A5 A1677E19F37FD5DA
                  22BDCE6976B08C51 F1DE8696BEC11BF1 A0EBD586A4A1D2C8
                  C804EBAB11C99FA9 8E0CEC959C715793 7C45557FAE0D4D89
                  716343F52FDD265E

   (i= 4) v[16] = BB2A77D3A8382351 45EB47971F23B103 98BE297F6E45C684
                  A36077DEE3370B89 8A03C4CB7E97590A 24192E49EBF54EA0
                  4F82C9401CB32D7A 8CCD013726420DC4 A9C9A8F17B1FC614
                  55908187977514A0 5B44273E66B19D27 B6D5C9FCA2579327
                  086092CFB858437E 5C4BE2156DBEECF9 2EFEDE99ED4EFF16
                  3E7B5F234CD1F804

   (i= 5) v[16] = C79C15B3D423B099 2DA2224E8DA97556 77D2B26DF1C45C55
                  8934EB09A3456052 0F6D9EEED157DA2A 6FE66467AF88C0A9
                  4EB0B76284C7AAFB 299C8E725D954697 B2240B59E6D567D3
                  2643C2370E49EBFD 79E02EEF20CDB1AE 64B3EED7BB602F39
                  B97D2D439E4DF63D C718E755294C9111 1F0893F2772BB373
                  1205EA4A7859807D

   (i= 6) v[16] = E58F97D6385BAEE4 7640AA9764DA137A DEB4C7C23EFE287E
                  70F6F41C8783C9F6 7127CD48C76A7708 9E472AF0BE3DB3F6
                  0F244C62DDF71788 219828AA83880842 41CCA9073C8C4D0D
                  5C7912BC10DF3B4B A2C3ABBD37510EE2 CB5668CC2A9F7859
                  8733794F07AC1500 C67A6BE42335AA6F ACB22B28681E4C82
                  DB2161604CBC9828

   (i= 7) v[16] = 6E2D286EEADEDC81 BCF02C0787E86358 57D56A56DD015EDF
                  55D899D40A5D0D0A 819415B56220C459 B63C479A6A769F02
                  258E55E0EC1F362A 3A3B4EC60E19DFDC 04D769B3FCB048DB
                  B78A9A33E9BFF4DD 5777272AE1E930C0 5A387849E578DBF6
                  92AAC307CF2C0AFC 30AACCC4F06DAFAA 483893CC094F8863
                  E03C6CC89C26BF92

   (i= 8) v[16] = FFC83ECE76024D01 1BE7BFFB8C5CC5F9 A35A18CBAC4C65B7
                  B7C2C7E6D88C285F 81937DA314A50838 E1179523A2541963
                  3A1FAD7106232B8F 1C7EDE92AB8B9C46 A3C2D35E4F685C10
                  A53D3F73AA619624 30BBCC0285A22F65 BCEFBB6A81539E5D
                  3841DEF6F4C9848A 98662C85FBA726D4 7762439BD5A851BD
                  B0B9F0D443D1A889

   (i= 9) v[16] = 753A70A1E8FAEADD 6B0D43CA2C25D629 F8343BA8B94F8C0B
                  BC7D062B0DB5CF35 58540EE1B1AEBC47 63C5B9B80D294CB9
                  490870ECAD27DEBD B2A90DDF667287FE 316CC9EBEEFAD8FC
                  4A466BCD021526A4 5DA7F7638CEC5669 D9C8826727D306FC
                  88ED6C4F3BD7A537 19AE688DDF67F026 4D8707AAB40F7E6D
                  FD3F572687FEA4F1

   (i=10) v[16] = E630C747CCD59C4F BC713D41127571CA 46DB183025025078
                  6727E81260610140 2D04185EAC2A8CBA 5F311B88904056EC
                  40BD313009201AAB 0099D4F82A2A1EAB 6DD4FBC1DE60165D
                  B3B0B51DE3C86270 900AEE2F233B08E5 A07199D87AD058D8
                  2C6B25593D717852 37E8CA471BEAA5F8 2CFC1BAC10EF4457
                  01369EC18746E775

   (i=11) v[16] = E801F73B9768C760 35C6D22320BE511D 306F27584F65495E
                  B51776ADF569A77B F4F1BE86690B3C34 3CC88735D1475E4B
                  5DAC67921FF76949 1CDB9D31AD70CC4E 35BA354A9C7DF448
                  4929CBE45679D73E 733D1A17248F39DB 92D57B736F5F170A
                  61B5C0A41D491399 B5C333457E12844A BD696BE010D0D889
                  02231E1A917FE0BD

   (i=12) v[16] = 12EF8A641EC4F6D6 BCED5DE977C9FAF5 733CA476C5148639
                  97DF596B0610F6FC F42C16519AD5AFA7 AA5AC1888E10467E
                  217D930AA51787F3 906A6FF19E573942 75AB709BD3DCBF24
                  EE7CE1F345947AA4 F8960D6C2FAF5F5E E332538A36B6D246
                  885BEF040EF6AA0B A4939A417BFB78A3 646CBB7AF6DCE980
                  E813A23C60AF3B82

           h[8] = 0D4D1C983FA580BA E9F6129FB697276A B7C45A68142F214C
                  D1A2FFDB6FBB124B 2D79AB2A39C5877D 95CC3345DED552C2
                  5A92F1DBA88AD318 239900D4ED8623B9

   BLAKE2b-512("abc") = BA 80 A5 3F 98 1C 4D 0D 6A 27 97 B6 9F 12 F6 E9
                        4C 21 2F 14 68 5A C4 B7 4B 12 BB 6F DB FF A2 D1
                        7D 87 C5 39 2A AB 79 2D C2 52 D5 DE 45 33 CC 95
                        18 D3 8A A8 DB F1 92 5A B9 23 86 ED D4 00 99 23

Приложение B. Пример расчёта BLAKE2s

Вычисляется хэш без ключа для 3 байтов ASCII abc с использованием BLAKE2b-256 и показаны детали расчета.

          m[16] = 00636261 00000000 00000000 00000000 00000000 00000000
                  00000000 00000000 00000000 00000000 00000000 00000000
                  00000000 00000000 00000000 00000000

   (i=0)  v[16] = 6B08E647 BB67AE85 3C6EF372 A54FF53A 510E527F 9B05688C
                  1F83D9AB 5BE0CD19 6A09E667 BB67AE85 3C6EF372 A54FF53A
                  510E527C 9B05688C E07C2654 5BE0CD19

   (i=1)  v[16] = 16A3242E D7B5E238 CE8CE24B 927AEDE1 A7B430D9 93A4A14E
                  A44E7C31 41D4759B 95BF33D3 9A99C181 608A3A6B B666383E
                  7A8DD50F BE378ED7 353D1EE6 3BB44C6B

   (i=2)  v[16] = 3AE30FE3 0982A96B E88185B4 3E339B16 F24338CD 0E66D326
                  E005ED0C D591A277 180B1F3A FCF43914 30DB62D6 4847831C
                  7F00C58E FB847886 C544E836 524AB0E2

   (i=3)  v[16] = 7A3BE783 997546C1 D45246DF EDB5F821 7F98A742 10E864E2
                  D4AB70D0 C63CB1AB 6038DA9E 414594B0 F2C218B5 8DA0DCB7
                  D7CD7AF5 AB4909DF 85031A52 C4EDFC98

   (i=4)  v[16] = 2A8B8CB7 1ACA82B2 14045D7F CC7258ED 383CF67C E090E7F9
                  3025D276 57D04DE4 994BACF0 F0982759 F17EE300 D48FC2D5
                  DC854C10 523898A9 C03A0F89 47D6CD88

   (i=5)  v[16] = C4AA2DDB 111343A3 D54A700A 574A00A9 857D5A48 B1E11989
                  6F5C52DF DD2C53A3 678E5F8E 9718D4E9 622CB684 92976076
                  0E41A517 359DC2BE 87A87DDD 643F9CEC

   (i=6)  v[16] = 3453921C D7595EE1 592E776D 3ED6A974 4D997CB3 DE9212C3
                  35ADF5C9 9916FD65 96562E89 4EAD0792 EBFC2712 2385F5B2
                  F34600FB D7BC20FB EB452A7B ECE1AA40

   (i=7)  v[16] = BE851B2D A85F6358 81E6FC3B 0BB28000 FA55A33A 87BE1FAD
                  4119370F 1E2261AA A1318FD3 F4329816 071783C2 6E536A8D
                  9A81A601 E7EC80F1 ACC09948 F849A584

   (i=8)  v[16] = 07E5B85A 069CC164 F9DE3141 A56F4680 9E440AD2 9AB659EA
                  3C84B971 21DBD9CF 46699F8C 765257EC AF1D998C 75E4C3B6
                  523878DC 30715015 397FEE81 4F1FA799

   (i=9)  v[16] = 435148C4 A5AA2D11 4B354173 D543BC9E BDA2591C BF1D2569
                  4FCB3120 707ADA48 565B3FDE 32C9C916 EAF4A1AB B1018F28
                  8078D978 68ADE4B5 9778FDA3 2863B92E

   (i=10) v[16] = D9C994AA CFEC3AA6 700D0AB2 2C38670E AF6A1F66 1D023EF3
                  1D9EC27D 945357A5 3E9FFEBD 969FE811 EF485E21 A632797A
                  DEEF082E AF3D80E1 4E86829B 4DEAFD3A

           h[8] = 8C5E8C50 E2147C32 A32BA7E1 2F45EB4E 208B4537 293AD69E
                  4C9B994D 82596786

   BLAKE2s-256("abc") = 50 8C 5E 8C 32 7C 14 E2 E1 A7 2B A3 4E EB 45 2F
                        37 45 8B 20 9E D6 3A 29 4D 99 9B 4C 86 67 59 82

Приложение C. Код реализации BLAKE2b на языке C

C.1. blake2b.h

   <CODE BEGINS>
   // blake2b.h
   // Контекст хэширования и протоктипы API для BLAKE2b

   #ifndef BLAKE2B_H
   #define BLAKE2B_H

   #include <stdint.h>
   #include <stddef.h>

   // контекст состояния
   typedef struct {
       uint8_t b[128];                     // входной буфер
       uint64_t h[8];                      // измененное состояние
       uint64_t t[2];                      // общее число байтов
       size_t c;                           // указатель для b[]
       size_t outlen;                      // размер дайджеста
   } blake2b_ctx;

   // Инициализация контекста хэширования ctx с необязательным ключом key.
   //      1 <= outlen <= 64 даёт размер дайджеста а байтах.
   //      секретный ключ (<= 64 байтов) является необязательным (keylen = 0).
   int blake2b_init(blake2b_ctx *ctx, size_t outlen,
       const void *key, size_t keylen);    // секретный ключ

   // Добавление в хэш inlen байтов из in.
   void blake2b_update(blake2b_ctx *ctx,   // контекст
       const void *in, size_t inlen);      // данные для хэширования

   // Генерация дайджеста сообщения (размер задан в init).
   //      Результат помещается в out.
   void blake2b_final(blake2b_ctx *ctx, void *out);

   // Удобная функция "все в одном".
   int blake2b(void *out, size_t outlen,   // буфер для возврата дайджеста
       const void *key, size_t keylen,     // необязательный секретный ключ
       const void *in, size_t inlen);      // данные для хэширования

   #endif
   <CODE ENDS>

C.2. blake2b.c

   <CODE BEGINS>
   // blake2b.c
   // Простая справочная реализация BLAKE2b.

   #include "blake2b.h"

   // Циклический сдвиг вправо.

   #ifndef ROTR64
   #define ROTR64(x, y)  (((x) >> (y)) ^ ((x) << (64 - (y))))
   #endif

   // Доступ к байтам Little-endian.

   #define B2B_GET64(p)                            \
       (((uint64_t) ((uint8_t *) (p))[0]) ^        \
       (((uint64_t) ((uint8_t *) (p))[1]) << 8) ^  \
       (((uint64_t) ((uint8_t *) (p))[2]) << 16) ^ \
       (((uint64_t) ((uint8_t *) (p))[3]) << 24) ^ \
       (((uint64_t) ((uint8_t *) (p))[4]) << 32) ^ \
       (((uint64_t) ((uint8_t *) (p))[5]) << 40) ^ \
       (((uint64_t) ((uint8_t *) (p))[6]) << 48) ^ \
       (((uint64_t) ((uint8_t *) (p))[7]) << 56))

   // Функция смешивания G.

   #define B2B_G(a, b, c, d, x, y) {   \
       v[a] = v[a] + v[b] + x;         \
       v[d] = ROTR64(v[d] ^ v[a], 32); \
       v[c] = v[c] + v[d];             \
       v[b] = ROTR64(v[b] ^ v[c], 24); \
       v[a] = v[a] + v[b] + y;         \
       v[d] = ROTR64(v[d] ^ v[a], 16); \
       v[c] = v[c] + v[d];             \
       v[b] = ROTR64(v[b] ^ v[c], 63); }

   // Вектор инициализации.

   static const uint64_t blake2b_iv[8] = {
       0x6A09E667F3BCC908, 0xBB67AE8584CAA73B,
       0x3C6EF372FE94F82B, 0xA54FF53A5F1D36F1,
       0x510E527FADE682D1, 0x9B05688C2B3E6C1F,
       0x1F83D9ABFB41BD6B, 0x5BE0CD19137E2179
   };

   // Функция сжатия. Флаг last указывает последний блок.
   static void blake2b_compress(blake2b_ctx *ctx, int last)
   {
       const uint8_t sigma[12][16] = {
           { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 },
           { 14, 10, 4, 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3 },
           { 11, 8, 12, 0, 5, 2, 15, 13, 10, 14, 3, 6, 7, 1, 9, 4 },
           { 7, 9, 3, 1, 13, 12, 11, 14, 2, 6, 5, 10, 4, 0, 15, 8 },
           { 9, 0, 5, 7, 2, 4, 10, 15, 14, 1, 11, 12, 6, 8, 3, 13 },
           { 2, 12, 6, 10, 0, 11, 8, 3, 4, 13, 7, 5, 15, 14, 1, 9 },
           { 12, 5, 1, 15, 14, 13, 4, 10, 0, 7, 6, 3, 9, 2, 8, 11 },
           { 13, 11, 7, 14, 12, 1, 3, 9, 5, 0, 15, 4, 8, 6, 2, 10 },
           { 6, 15, 14, 9, 11, 3, 0, 8, 12, 2, 13, 7, 1, 4, 10, 5 },
           { 10, 2, 8, 4, 7, 6, 1, 5, 15, 11, 9, 14, 3, 12, 13, 0 },
           { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 },
           { 14, 10, 4, 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3 }
       };
       int i;
       uint64_t v[16], m[16];

       for (i = 0; i < 8; i++) {           // инициализация рабочих переменных
           v[i] = ctx->h[i];
           v[i + 8] = blake2b_iv[i];
       }

       v[12] ^= ctx->t[0];                 // младшие 64 бита смещения
       v[13] ^= ctx->t[1];                 // старшие 64 бита смещения
       if (last)                           // флаг последнего блока установлен?
           v[14] = ~v[14];

       for (i = 0; i < 16; i++)            // получение слов little-endian
           m[i] = B2B_GET64(&ctx->b[8 * i]);

       for (i = 0; i < 12; i++) {          // 12 раундов
           B2B_G( 0, 4,  8, 12, m[sigma[i][ 0]], m[sigma[i][ 1]]);
           B2B_G( 1, 5,  9, 13, m[sigma[i][ 2]], m[sigma[i][ 3]]);
           B2B_G( 2, 6, 10, 14, m[sigma[i][ 4]], m[sigma[i][ 5]]);
           B2B_G( 3, 7, 11, 15, m[sigma[i][ 6]], m[sigma[i][ 7]]);
           B2B_G( 0, 5, 10, 15, m[sigma[i][ 8]], m[sigma[i][ 9]]);
           B2B_G( 1, 6, 11, 12, m[sigma[i][10]], m[sigma[i][11]]);
           B2B_G( 2, 7,  8, 13, m[sigma[i][12]], m[sigma[i][13]]);
           B2B_G( 3, 4,  9, 14, m[sigma[i][14]], m[sigma[i][15]]);
       }

       for( i = 0; i < 8; ++i )
           ctx->h[i] ^= v[i] ^ v[i + 8];
   }

   // Инициализация контекста хэширования ctx с необязательным ключом key.
   //      1 <= outlen <= 64 даёт размер дайджеста а байтах.
   //      секретный ключ (<= 64 байтов) является необязательным (keylen = 0).

   int blake2b_init(blake2b_ctx *ctx, size_t outlen,
       const void *key, size_t keylen)        // (keylen=0 - нет ключа)
   {
       size_t i;

       if (outlen == 0 || outlen > 64 || keylen > 64)
           return -1;                      // непригодные параметры

       for (i = 0; i < 8; i++)             // состояние, блок параметров
           ctx->h[i] = blake2b_iv[i];
       ctx->h[0] ^= 0x01010000 ^ (keylen << 8) ^ outlen;

       ctx->t[0] = 0;                      // младшее слово счетчика ввода
       ctx->t[1] = 0;                      // старшее слово счетчика ввода
       ctx->c = 0;                         // указатель внутри буфера
       ctx->outlen = outlen;

       for (i = keylen; i < 128; i++)      // нулевой входной блок
           ctx->b[i] = 0;
       if (keylen > 0) {
           blake2b_update(ctx, key, keylen);
           ctx->c = 128;                   // в конце
       }

       return 0;
   }

   // Добавление в хэш inlen байтов из in.

   void blake2b_update(blake2b_ctx *ctx,
       const void *in, size_t inlen)       // байты данных
   {
       size_t i;

       for (i = 0; i < inlen; i++) {
           if (ctx->c == 128) {            // буфер полон?
               ctx->t[0] += ctx->c;        // увеличение счетчика
               if (ctx->t[0] < ctx->c)     // перенос при переполнении?
                   ctx->t[1]++;            // старшее слово
               blake2b_compress(ctx, 0);   // сжатие (не последнее)
               ctx->c = 0;                 // сброс счётчика в 0
           }
           ctx->b[ctx->c++] = ((const uint8_t *) in)[i];
       }
   }

   // Генерация дайджеста сообщения (размер задан в init).
   //      Результат помещается в out.

   void blake2b_final(blake2b_ctx *ctx, void *out)
   {
       size_t i;

       ctx->t[0] += ctx->c;                // маркировка смещения последнего блока
       if (ctx->t[0] < ctx->c)             // перенос при переполнении
           ctx->t[1]++;                    // старшее слово

       while (ctx->c < 128)                // заполнение нулями
           ctx->b[ctx->c++] = 0;
       blake2b_compress(ctx, 1);           // флаг финального блока = 1

       // преобразование в little-endian и сохранение
       for (i = 0; i < ctx->outlen; i++) {
           ((uint8_t *) out)[i] =
               (ctx->h[i >> 3] >> (8 * (i & 7))) & 0xFF;
       }
   }

   // Удобная функция "все в одном".

   int blake2b(void *out, size_t outlen,
       const void *key, size_t keylen,
       const void *in, size_t inlen)
   {
       blake2b_ctx ctx;

       if (blake2b_init(&ctx, outlen, key, keylen))
           return -1;
       blake2b_update(&ctx, in, inlen);
       blake2b_final(&ctx, out);

       return 0;
   }
   <CODE ENDS>

Приложение D. Код реализации BLAKE2s на языке C

D.1. blake2s.h

   <CODE BEGINS>
   // blake2s.h
   // Контекст хэширования и прототипы API для  BLAKE2s

   #ifndef BLAKE2S_H
   #define BLAKE2S_H

   #include <stdint.h>
   #include <stddef.h>

   // контекст состояния
   typedef struct {
       uint8_t b[64];                      // входной буфер
       uint32_t h[8];                      // измененное состояние
       uint32_t t[2];                      // общее число байтов
       size_t c;                           // указатель для b[]
       size_t outlen;                      // размер дайджеста
   } blake2s_ctx;

   // Initialize the hashing контекст "ctx" with optional key "key".
   //      1 <= outlen <= 32 даёт размер дайджеста а байтах.
   //      секретный ключ (<= 32 байтов) является необязательным (keylen = 0).
   int blake2s_init(blake2s_ctx *ctx, size_t outlen,
       const void *key, size_t keylen);    // секретный ключ

   // Добавление в хэш inlen байтов из in.
   void blake2s_update(blake2s_ctx *ctx,   // контекст
       const void *in, size_t inlen);      // данные для хэширования

   // Генерация дайджеста сообщения (размер задан в init).
   //      Результат помещается в out.
   void blake2s_final(blake2s_ctx *ctx, void *out);

   // Удобная функция "все в одном".
   int blake2s(void *out, size_t outlen,   // буфер для возврата дайджеста
       const void *key, size_t keylen,     // необязательный секретный ключ
       const void *in, size_t inlen);      // данные для хэширования

   #endif
   <CODE ENDS>

D.2. blake2s.c

   <CODE BEGINS>
   // blake2s.c
   // Простая справочная реализация blake2s.

   #include "blake2s.h"

   // Циклический сдвиг вправо.

   #ifndef ROTR32
   #define ROTR32(x, y)  (((x) >> (y)) ^ ((x) << (32 - (y))))
   #endif

   // Доступ к байтам Little-endian.

   #define B2S_GET32(p)                            \
       (((uint32_t) ((uint8_t *) (p))[0]) ^        \
       (((uint32_t) ((uint8_t *) (p))[1]) << 8) ^  \
       (((uint32_t) ((uint8_t *) (p))[2]) << 16) ^ \
       (((uint32_t) ((uint8_t *) (p))[3]) << 24))

   // Функция смешивания G.

   #define B2S_G(a, b, c, d, x, y) {   \
       v[a] = v[a] + v[b] + x;         \
       v[d] = ROTR32(v[d] ^ v[a], 16); \
       v[c] = v[c] + v[d];             \
       v[b] = ROTR32(v[b] ^ v[c], 12); \
       v[a] = v[a] + v[b] + y;         \
       v[d] = ROTR32(v[d] ^ v[a], 8);  \
       v[c] = v[c] + v[d];             \
       v[b] = ROTR32(v[b] ^ v[c], 7); }

   // Вектор инициализации.

   static const uint32_t blake2s_iv[8] =
   {
       0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
       0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
   };

   // Функция сжатия. Флаг last указывает последний блок.
   static void blake2s_compress(blake2s_ctx *ctx, int last)
   {
       const uint8_t sigma[10][16] = {
           { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 },
           { 14, 10, 4, 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3 },
           { 11, 8, 12, 0, 5, 2, 15, 13, 10, 14, 3, 6, 7, 1, 9, 4 },
           { 7, 9, 3, 1, 13, 12, 11, 14, 2, 6, 5, 10, 4, 0, 15, 8 },
           { 9, 0, 5, 7, 2, 4, 10, 15, 14, 1, 11, 12, 6, 8, 3, 13 },
           { 2, 12, 6, 10, 0, 11, 8, 3, 4, 13, 7, 5, 15, 14, 1, 9 },
           { 12, 5, 1, 15, 14, 13, 4, 10, 0, 7, 6, 3, 9, 2, 8, 11 },
           { 13, 11, 7, 14, 12, 1, 3, 9, 5, 0, 15, 4, 8, 6, 2, 10 },
           { 6, 15, 14, 9, 11, 3, 0, 8, 12, 2, 13, 7, 1, 4, 10, 5 },
           { 10, 2, 8, 4, 7, 6, 1, 5, 15, 11, 9, 14, 3, 12, 13, 0 }
       };
       int i;
       uint32_t v[16], m[16];

       for (i = 0; i < 8; i++) {           // инициализация рабочих переменных
           v[i] = ctx->h[i];
           v[i + 8] = blake2s_iv[i];
       }

       v[12] ^= ctx->t[0];                 // младшие 32 бита смещения
       v[13] ^= ctx->t[1];                 // старшие 32 бита смещения
       if (last)                           // флаг последнего блока установлен?
           v[14] = ~v[14];

       for (i = 0; i < 16; i++)            // получение слов little-endian
           m[i] = B2S_GET32(&ctx->b[4 * i]);

       for (i = 0; i < 10; i++) {          // 10 раундов
           B2S_G( 0, 4,  8, 12, m[sigma[i][ 0]], m[sigma[i][ 1]]);
           B2S_G( 1, 5,  9, 13, m[sigma[i][ 2]], m[sigma[i][ 3]]);
           B2S_G( 2, 6, 10, 14, m[sigma[i][ 4]], m[sigma[i][ 5]]);
           B2S_G( 3, 7, 11, 15, m[sigma[i][ 6]], m[sigma[i][ 7]]);
           B2S_G( 0, 5, 10, 15, m[sigma[i][ 8]], m[sigma[i][ 9]]);
           B2S_G( 1, 6, 11, 12, m[sigma[i][10]], m[sigma[i][11]]);
           B2S_G( 2, 7,  8, 13, m[sigma[i][12]], m[sigma[i][13]]);
           B2S_G( 3, 4,  9, 14, m[sigma[i][14]], m[sigma[i][15]]);
       }

       for( i = 0; i < 8; ++i )
           ctx->h[i] ^= v[i] ^ v[i + 8];
   }

   // Инициализация контекста хэширования ctx с необязательным ключом key.
   //      1 <= outlen <= 32 даёт размер дайджеста а байтах.
   //      секретный ключ (<= 32 байтов) необязателен (keylen = 0).

   int blake2s_init(blake2s_ctx *ctx, size_t outlen,
       const void *key, size_t keylen)     // (keylen=0 - нет ключа)
   {
       size_t i;

       if (outlen == 0 || outlen > 32 || keylen > 32)
           return -1;                      // непригодные параметры

       for (i = 0; i < 8; i++)             // состояние, блок параметров
           ctx->h[i] = blake2s_iv[i];
       ctx->h[0] ^= 0x01010000 ^ (keylen << 8) ^ outlen;

       ctx->t[0] = 0;                      // младшее слово счетчика ввода
       ctx->t[1] = 0;                      // старшее слово счетчика ввода
       ctx->c = 0;                         // указатель внутри буфера
       ctx->outlen = outlen;

       for (i = keylen; i < 64; i++)       // нулевой входной блок
           ctx->b[i] = 0;
       if (keylen > 0) {
           blake2s_update(ctx, key, keylen);
           ctx->c = 64;                    // в конце
       }

       return 0;
   }

   // Добавление в хэш inlen байтов из in.

   void blake2s_update(blake2s_ctx *ctx,
       const void *in, size_t inlen)       // байты данных
   {
       size_t i;

       for (i = 0; i < inlen; i++) {
           if (ctx->c == 64) {             // буфер полон?
               ctx->t[0] += ctx->c;        // увеличение счетчика
               if (ctx->t[0] < ctx->c)     // перенос при переполнении?
                   ctx->t[1]++;            // старшее слово
               blake2s_compress(ctx, 0);   // сжатие (не последнее)
               ctx->c = 0;                 // сброс счётчика в 0
           }
           ctx->b[ctx->c++] = ((const uint8_t *) in)[i];
       }
   }

   // Генерация дайджеста сообщения (размер задан в init).
   //      Результат помещается в out.

   void blake2s_final(blake2s_ctx *ctx, void *out)
   {
       size_t i;

       ctx->t[0] += ctx->c;                // маркировка смещения последнего блока
       if (ctx->t[0] < ctx->c)             // перенос при переполнении
           ctx->t[1]++;                    // старшее слово

       while (ctx->c < 64)                 // заполнение нулями
           ctx->b[ctx->c++] = 0;
       blake2s_compress(ctx, 1);           // флаг финального блока = 1

       // преобразование в little-endian и сохранение
       for (i = 0; i < ctx->outlen; i++) {
           ((uint8_t *) out)[i] =
               (ctx->h[i >> 2] >> (8 * (i & 3))) & 0xFF;
       }
   }

   // Удобная функция "все в одном".

   int blake2s(void *out, size_t outlen,
       const void *key, size_t keylen,
       const void *in, size_t inlen)
   {
       blake2s_ctx ctx;
       if (blake2s_init(&ctx, outlen, key, keylen))
           return -1;
       blake2s_update(&ctx, in, inlen);
       blake2s_final(&ctx, out);

       return 0;
   }
   <CODE ENDS>

Приложение E. Код модуля самотестирования BLAKE2b и BLAKE2s

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

Такое тестирование рекомендуется, особенно при реализации для новой конфигурации целевой платформы. Кроме того, некоторые стандарты безопасности (например, FIPS-140) могут требовать самотестирования при включении (Power-On Self Test или POST) каждый раз, когда загружается криптографический модуль [FIPS140-2IG].

   <CODE BEGINS>
   // test_main.c
   // Модули самотестирования для BLAKE2b и BLAKE2s, а также заглушка main().

   #include <stdio.h>

   #include "blake2b.h"
   #include "blake2s.h"

   // Детерминированные последоветельности (генератор Fibonacci).

   static void selftest_seq(uint8_t *out, size_t len, uint32_t seed)
   {
       size_t i;
       uint32_t t, a , b;

       a = 0xDEAD4BAD * seed;              // prime
       b = 1;

       for (i = 0; i < len; i++) {         // заполнение буфера
           t = a + b;
           a = b;
           b = t;
           out[i] = (t >> 24) & 0xFF;
       }
   }

   // Проверка BLAKE2b. При положительном результате возвращает 0.

   int blake2b_selftest()
   {
       // Хэш результатов хэширования
       const uint8_t blake2b_res[32] = {
           0xC2, 0x3A, 0x78, 0x00, 0xD9, 0x81, 0x23, 0xBD,
           0x10, 0xF5, 0x06, 0xC6, 0x1E, 0x29, 0xDA, 0x56,
           0x03, 0xD7, 0x63, 0xB8, 0xBB, 0xAD, 0x2E, 0x73,
           0x7F, 0x5E, 0x76, 0x5A, 0x7B, 0xCC, 0xD4, 0x75
       };
       // наборы параметров
       const size_t b2b_md_len[4] = { 20, 32, 48, 64 };
       const size_t b2b_in_len[6] = { 0, 3, 128, 129, 255, 1024 };

       size_t i, j, outlen, inlen;
       uint8_t in[1024], md[64], key[64];
       blake2b_ctx ctx;

       // 256-битовый хэш для тестирования
       if (blake2b_init(&ctx, 32, NULL, 0))
           return -1;

       for (i = 0; i < 4; i++) {
           outlen = b2b_md_len[i];
           for (j = 0; j < 6; j++) {
               inlen = b2b_in_len[j];

               selftest_seq(in, inlen, inlen);     // хэш без ключа
               blake2b(md, outlen, NULL, 0, in, inlen);
               blake2b_update(&ctx, md, outlen);   // хэш для хэша

               selftest_seq(key, outlen, outlen);  // хэш с ключом
               blake2b(md, outlen, key, outlen, in, inlen);
               blake2b_update(&ctx, md, outlen);   // хэш для хэша
           }
       }

       // расчет и сравнение хэша хэшей
       blake2b_final(&ctx, md);
       for (i = 0; i < 32; i++) {
           if (md[i] != blake2b_res[i])
               return -1;
       }

       return 0;
   }

   // Проверка BLAKE2s. При положительном результате возвращает 0. 

   int blake2s_selftest()
   {
       // Хэш результатов хэширования
       const uint8_t blake2s_res[32] = {
           0x6A, 0x41, 0x1F, 0x08, 0xCE, 0x25, 0xAD, 0xCD,
           0xFB, 0x02, 0xAB, 0xA6, 0x41, 0x45, 0x1C, 0xEC,
           0x53, 0xC5, 0x98, 0xB2, 0x4F, 0x4F, 0xC7, 0x87,
           0xFB, 0xDC, 0x88, 0x79, 0x7F, 0x4C, 0x1D, 0xFE
       };
       // наборы параметров.
       const size_t b2s_md_len[4] = { 16, 20, 28, 32 };
       const size_t b2s_in_len[6] = { 0,  3,  64, 65, 255, 1024 };

       size_t i, j, outlen, inlen;
       uint8_t in[1024], md[32], key[32];
       blake2s_ctx ctx;

       // 256-битовый хэш для тестирования.
       if (blake2s_init(&ctx, 32, NULL, 0))
           return -1;

       for (i = 0; i < 4; i++) {
           outlen = b2s_md_len[i];
           for (j = 0; j < 6; j++) {
               inlen = b2s_in_len[j];

               selftest_seq(in, inlen, inlen);     // хэш без ключа
               blake2s(md, outlen, NULL, 0, in, inlen);
               blake2s_update(&ctx, md, outlen);   // хэш для хэша

               selftest_seq(key, outlen, outlen);  // хэш с ключом
               blake2s(md, outlen, key, outlen, in, inlen);
               blake2s_update(&ctx, md, outlen);   // хэш для хэша
           }
       }

       // расчет и сравнение хэша хэшей.
       blake2s_final(&ctx, md);
       for (i = 0; i < 32; i++) {
           if (md[i] != blake2s_res[i])
               return -1;
       }

       return 0;
   }

   // Драйвер теста.

   int main(int argc, char **argv)
   {
       printf("blake2b_selftest() = %s\n",
            blake2b_selftest() ? "FAIL" : "OK");
       printf("blake2s_selftest() = %s\n",
            blake2s_selftest() ? "FAIL" : "OK");

       return 0;
   }
   <CODE ENDS>

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

Редактор благодарен за поддержку команде [BLAKE2] в составе Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, Christian Winnerlein. Фрагменты [BLAKE] и [BLAKE2] заимствованы с разрешения.

[BLAKE2] базируется на предложении SHA-3 [BLAKE] от Jean-Philippe Aumasson, Luca Henzen, Willi Meier, Raphael C.-W. Phan. BLAKE2, как и BLAKE, опирается на базовый алгоритм, заимствованный из потокового шифра ChaCha, разработанного Daniel J. Bernstein.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                         M. Cullen
Request for Comments: 7652                                    S. Hartman
Updates: 6887                                          Painless Security
Category: Standards Track                                       D. Zhang
ISSN: 2070-1721
                                                                T. Reddy
                                                                   Cisco
                                                          September 2015

PDF

Механизм аутентификации PCP

Port Control Protocol (PCP) Authentication Mechanism

Аннотация

Хост IPv4 или IPv6 может использовать протокол PCP¹ для гибкого управления информацией об отображениях адресов и портов на трансляторах NAT² или межсетевых экранах для коммуникаций с удаленными хостами. Однако неконтролируемое создание или удаление отображений адресов IP в таких сетевых устройствах может вызывать проблемы безопасности и его следует избегать. В некоторых случаях от клиентов может требоваться подтверждение его полномочий на изменение, создание или удаление отображений PCP. В данном документе описывается реализуемый в основной полосе (in-band) механизм аутентификации для PCP, который может применяться в таких случаях. Для аутентификации между устройствами PCP используется расширяемый протокол аутентификации (EAP³).

Данный документ служит обновлением RFC 6887.

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

Этот документ относится к категории проектов стандартов (Internet Standards Track).

Документ является результатом работы IETF⁴ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG⁵. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

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

1 Введение

Используя PCP [RFC6887], приложение может гибко управлять информацией об отображениях адресов IP на своих трансляторах сетевых адресов (NAT) и межсетевых экранах (МСЭ), а также контролировать правила обработки входящих и исходящих пакетов IP. Поскольку устройства NAT и МСЭ играют важную роль в архитектуре сетевой безопасности, возникает множество ситуаций, в которых требуется аутентификация и контроль доступа для предотвращения несанкционированного доступа в таким устройствам. В этом документе определено защитное расширение PCP, которое позволяет серверам PCP аутентифицировать своих клиентов с помощью расширяемого протокола аутентификации (EAP). Сообщения EAP инкапсулируются в сообщения PCP.

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

• потерю сообщений EAP в процессе передачи;

• нарушение порядка доставки сообщений EAP;

• генерацию транспортных ключей;

• защиту целостности и аутентификацию источника данных для сообщений PCP;

• скорость алгоритма.

Описанный в этом документе механизм соответствует требованиям безопасности для расширенной модели угроз (Advanced Threat Model), описанной в базовой спецификации PCP [RFC6887]. Этот механизм может использоваться для защиты PCP в следующих ситуациях:

• на оборудовании защиты (например, корпоративных МСЭ), которое не создает неявных отображений для конкретного трафика;

• на оборудовании (например, CGN⁶ или МСЭ сервис-провайдера), обслуживающем множество административных доменов и не имеющем механизмов безопасной изоляции трафика разных доменов;

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

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

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

Большая часть используемых в документе терминов определена в [RFC6887].

PCP client — клиент PCP

Программный экземпляр PCP, отвечающий за подачу PCP-запросов серверу PCP. В данном документе клиентом PCP считается также партнер EAP [RFC3748] и ответственность за предоставление свидетельств при аутентификации ложится на клиента PCP.

PCP server — сервер PCP

Программный экземпляр PCP, размещенный на управляемом PCP устройстве, который принимает запросы PCP от клиентов PCP и организует в ответ соответствующие состояния. В этом документе сервер PCP объединен с аутентификатором EAP [RFC3748]. Следовательно, при необходимости сервер PCP может проверить свидетельства, представленные клиентом PCP и принять решение о предоставлении клиента доступа по результатам такой проверки.

PCP-Authentication (PA) session — сеанс аутентификации PCP

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

Session partner — партнер по сессии

Реализация PCP, вовлеченная в сеанс PA. Каждая сессия PA включает двух партнеров (клиент и сервер PCP).

PCP device — устройство PCP

Клиент или сервер PCP.

Session lifetime — время жизни сессии

Время жизни, связанное с сеансом PA. Время жизни сессии PA определяет срок действия полномочий, предоставленных клиенту PCP.

PA Security Association (PCP SA) — защищенная связь PCP

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

Master Session Key (MSK) — первичный сеансовый ключ

Ключ, созданный партнерами по сессии PA с использованием метода генерации EAP (например, [RFC5448]).

PCP-Authentication (PA) message — аутентификационное сообщение

Сообщение PCP, содержащее код операции AUTHENTICATION. Сообщение PA, отправленное сервером PCP клиенту PCP будем называть далее сообщением PA-Server, а сообщение PA от клиента к серверу PCP — сообщением PA-Client. Таким образом, сообщения PA-Server представляют собой отклики PCP [RFC6887], а сообщения PA-Client — запросы PCP. В данном документе (параграф 5.5) определена опция PA_AUTHENTICATION_TAG, служащая для защиты целостности и аутентификации источника сообщений PA.

Common PCP message — обычное сообщение PCP

Сообщение PCP, не содержащее кода операции AUTHENTICATION. В этом документе определена опция AUTHENTICATION_TAG, служащая для защиты целостности и аутентификации источника обычных сообщений PCP.

3 Детали протокола

3.1 Инициирование сессии

В начале сессии PA клиент и сервер PCP должны обменяться серией сообщений PA для выполнения аутентификации EAP. Каждое сообщение PA должно содержать код операции AUTHENTICATION и может включать опции для решения тех или иных задач (например, доставка аутентификационных сообщений и управление сессией). Специфические для операции AUTHENTICATION данные включают два поля: Session ID и Sequence Number. Поле Session ID служит для идентификации сессии PA, к которой относится сообщение. Поле Sequence Number применяется для детектирования нарушений порядка доставки и дубликатов сообщений.

3.1.1 Аутентификация по инициативе клиента

Когда клиент PCP намерен заранее инициировать сессию PA с сервером PCP, он передает сообщение PA-Initiation (сообщение PA-Client с кодом результата INITIATION) серверу PCP. В параграфе 5.1 описано изменение формата запросов PCP с учетом кодов результата, используемых механизмом аутентификации PCP. В зависящих от кода операции данных такого сообщения поля Session ID и Sequence Number устанавливаются в 0. Сообщение PA-Client должно также включать опцию NONCE (определена в параграфе 5.3) со случайным значением.

После получения PA-Initiation сервер PCP, если он согласен инициировать сессию PA с клиентом PCP, будет отвечать сообщением PA-Server, которое содержит запрос EAP и код результата AUTHENTICATION_REQUEST. В дополнение к этому сервер должен выделить уникальный идентификатор сессии и поместить его в поле Session ID зависящих от операции данных сообщения PA-Server. В поле Sequence Number устанавливается значение 0. Сообщение PA-Server должно включать опцию NONCE, в которой клиенту возвращается принятое от него одноразовое значение. Это значение используется клиентом для проверки «свежести» полученного сообщения. В последующие сообщения данной сессии PA должен включаться идентификатор сессии.

Клиент                                            Сервер
  PCP                                               PCP
   |-- PA-Initiation ------------------------------->|
   |    (Seq=0, rc=INITIATION, Session ID=0)         |
   |                                                 |
   |<-- PA-Server -----------------------------------|
   |     (Seq=0, Session ID=X, запрос EAP,           |
   |      rc=AUTHENTICATION_REQUEST)                 |
   |                                                 |
   |-- PA-Client ----------------------------------->|
   |    (Seq=1, Session ID=X, отклик EAP,            |
   |     rc=AUTHENTICATION_REPLY)                    |
   |                                                 |
   |<-- PA-Server -----------------------------------|
   |     (Seq=1, Session ID=X, запрос EAP,           |
   |      rc=AUTHENTICATION_REQUEST)                 |

3.1.2 Аутентификация по инициативе сервера

В ситуации, когда сервер PCP получает обычный запрос PCP от клиента, для которого требуется аутентификация, сервер отвергает такой запрос с кодом ошибки AUTHENTICATION_REQUIRED и может отправить незапрошенное сообщение PA-Server для организации сессии PA. Поле Result Code в таком сообщении PA-Server содержит значение AUTHENTICATION_REQUEST. Кроме того, сервер должен выделить для сессии идентификатор (Session ID) и передать его в сообщении PA-Server. Для поля Sequence Number в сообщении PA-Server устанавливается нулевое значение. Если клиент повторит обычный запрос PCP до завершения аутентификации EAP, он получит от сервера отклик с кодом ошибки AUTHENTICATION_REQUIRED. В последующих сообщениях PA данной сессии поле Session ID будет помогать партнерам идентифицировать относящиеся к сессии сообщения. При получении клиентом PCP начального сообщения PA-Server от сервера PCP он может ответить сообщением PA-Client или отбросить запрос без уведомления сервера в соответствии со своей локальной политикой. К сообщению PA-Client может быть добавлена опция NONCE с одноразовым случайным значением. В этом случае сервер в следующем сообщении PA-Server должен вернуть полученное одноразовое значение в опции NONCE.

Клиент                                            Сервер
 PCP                                               PCP
 |-- Обычный запрос PCP -------------------------->|
 |                                                 |
 |<- Обычный отклик PCP ---------------------------|
 |    (rc=AUTHENTICATION_REQUIRED)                 |
 |                                                 |
 |<-- PA-Server -----------------------------------|
 |     (Seq=0, Session ID=X, запрос EAP,           |
 |      rc=AUTHENTICATION_REQUEST)                 |
 |                                                 |
 |-- PA-Client ----------------------------------->|
 |    (Seq=0, Session ID=X, отклик EAP,            |
 |     rc=AUTHENTICATION_REPLY)                    |
 |                                                 |
 |<-- PA-Server -----------------------------------|
 |     (Seq=1, Session ID=X, запрос EAP,           |
 |      rc=AUTHENTICATION_REQUEST)                 |

3.1.3 Аутентификация с применением EAP

В сессии PA запрос EAP передается в сообщении PA-Server, а отклик EAP — в сообщении PA-Client. EAP полагается на услуги нижележащего протокола в плане обеспечения гарантий доставки, нарушение порядка и потерю пакетов в процессе передачи нужно детектировать и исправлять. Следовательно, после отправки сообщения PA-Server сервер PCP не будет передавать в данной сессии PA новых сообщений PA-Server до получения отклика PA-Client с корректным порядковым номером (и наоборот). Если клиент PCP получает сообщение PA с запросом EAP и по той или иной причине не может сразу же создать отклик EAP (например, ждет вмешательства оператора для получения данных, требуемых сообщению EAP, или дополнительных сообщений PA для сборки сообщения EAP из фрагментов), устройство PCP должно ответить сообщением PA-Acknowledgement (сообщение PA с опцией RECEIVED_PAK) для индикации получения запроса. Это не только позволяет избежать ненужных повторов сообщений PA, но и обеспечивает надежную доставку в тех случаях, когда устройству PCP требуется собрать множество сообщений PA с фрагментами запроса EAP для генерации отклика EAP. Число сообщений EAP в обмене между клиентом и сервером PCP зависит от используемого EAP метода аутентификации.

В этой модели клиент и сервер PCP должны применять для аутентификации метод EAP с генерацией ключей. В частности, реализации PCP с аутентификацией должны поддерживать EAP-TTLS⁷ [RFC5281] и следует также поддерживать TEAP⁸ [RFC7170]. Следовательно, после успешного завершения процедуры аутентификации будет генерироваться первичный сеансовый ключ MSK. Если клиент и сервер PCP хотят генерировать транспортный ключ с использованием MSK, они должны согласовать псевдо-случайную функцию (PRF⁹) для создания транспортного ключа и алгоритм MAC¹⁰ для аутентификации источника последующих сообщений PCP. Для решения этой задачи сервер должен добавить набор опций PRF и MAC_ALGORITHM в конец исходного сообщения PA-Server. Каждая опция PRF включает поддерживаемую сервером PRF, а каждая опция MAC_ALGORITHM — поддерживаемый алгоритм MAC. Кроме того, к первому сообщению PA-Server сервер может добавить опцию ID_INDICATOR (см. параграф 5.11), помогающую клиенту выбрать свидетельства (credential). После получения опций клиент PCP должен выбрать PRF и алгоритм MAC, которые он хочет использовать, и добавить соответствующие опции PRF и MAC_ALGORITHM в следующее сообщение PA-Client.

После аутентификации EAP сервер PCP передает сообщение PA-Server для индикации результатов аутентификации EAP и проверки полномочий PCP. При успешной аутентификации EAP в сообщении PA-Server указывается код результата AUTHENTICATION_SUCCEEDED. В этом случае перед отправкой сообщения PA-Server сервер PCP должен обновить PCP SA с указанием MSK и транспортного ключа, а также использовать созданный транспортный ключ для генерации подписи к сообщению. Подпись передается в опции PA_AUTHENTICATION_TAG для PCP Auth. Более подробное описание генерации аутентификационных данных приведено в параграфе 6.1. Кроме того, сообщение PA-Server должно также включать опцию SESSION_LIFETIME (см. параграф 5.9), указывающее срок существования сессии PA (т. е., время жизни MSK). После приема сообщения PA-Server клиенту PCP нужно создать ответное сообщение PA-Client. Если клиент PCP тоже аутентифицировал сервер PCP, в качестве кода результата в сообщении PA-Client указывается AUTHENTICATION_SUCCEEDED. Кроме того, клиенту PCP нужно обновить PCP SA, включив ключ MSK и транспортный ключ и использовать полученный транспортный ключ для защиты сообщения. С этого момента все сообщения PCP в данной сессии будут защищаться с использованием транспортного ключа и алгоритма MAC, указанного в PCP SA. Первое защищенное сообщение PA-Client от клиента должно включать набор опций PRF и MAC_ALGORITHM, полученных от сервера PCP. Сервер PCP проверяет соответствие полученного набора алгоритмов отправленному им для обнаружения атак на снижение уровня защиты. При обнаружении такой атаки сервер должен передать сообщение PA-Server с кодом результата DOWNGRADE_ATTACK_DETECTED и прервать сессию. Если клиент PCP передает обычный запрос PCP в сессии PA без опции AUTHENTICATION_TAG, сервер PCP отвергает такой запрос, возвращая код ошибки AUTHENTICATION_REQUIRED.

Если клиент/сервер PCP не может аутентифицировать партнера по сессии, устройство передает сообщение PA с кодом результата AUTHENTICATION_FAILED. Если аутентификация EAP завершилась успешно, а проверка полномочий — отказом, принимающее решение устройство передает сообщение PA с кодом результата AUTHORIZATION_FAILED. В этих двух случаях после передачи сообщения PA сессия PA должна быть разорвана незамедлительно. Независимые клиенты PCP на хосте могут создавать множество сессий PA с сервером PCP.

3.2 Восстановление потерянной сессии PA

Если сервер PCP сбросил или потерял PCP SA в результате перезапуска, сбоя питания или по иной причине, он передает клиенту PCP незапрошенный отклик ANNOUNCE, как описано в параграфе 14.1.3 [RFC6887]. При получении отклика ANNOUNCE с аномальным значением Epoch Time клиент PCP понимает, что сервер мог потерять состояние. Отклик ANNOUNCE может оказаться поддельным (атака), легитимным или не замеченным клиентом. Эти три случая описаны ниже.

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

  • Если от сервера PCP приходит отклик об успешном завершении с защитой целостности, клиент PCP считает, что у сервера PCP нет потерянной сессии PA, а незапрошенный отклик ANNOUNCE передан атакующим.

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

• В случае, когда сервер PCP потерял PCP SA, но не информировал об этом клиента PCP, а клиент PCP передал запрос PCP с защитой целостности, сервер PCP отвергает такой запрос с кодом ошибки UNKNOWN_SESSION_ID. Клиент PCP в этом случае инициирует полную аутентификацию EAP с сервером PCP (см. параграф 3.1.1) и после ее успешного завершения обновляет PCP SA.

Если клиент PCP сбрасывает или теряет PCP SA в результате перезагрузки, сбоя питания или по иной причине и передает обычный запрос PCP, сервер PCP отвергает такой запрос с кодом ошибки AUTHENTICATION_REQUIRED. Клиент PCP должен выполнить аутентификацию с помощью опции AUTHENTICATION_TAG. Сервер PCP должен обновить PCP SA после успешной аутентификации EAP.

3.3 Прерывание сессии

Сессия PA может быть явно прервана любым из ее участников. Сервер PCP может явно запросить разрыв сессии, передав незапрошенный отклик PA, указывающий разрыв (отклик PA с кодом результата SESSION_TERMINATED). При получении такого сообщения клиент PCP должен ответить сообщением PA с индикацией разрыва сессии и затем удалить соответствующую PCP SA. С учетом возможной потери пакетов сервер PCP может передавать отклик PA о разрыве сессии до 10 раз (с корректировкой значения Epoch Time в каждом сообщении с учетом прошедшего времени), при этом (1) интервал между первым и вторым сообщениями должен быть не менее 250 мсек и (2) при каждом следующем повторе интервал должен увеличиваться по не менее, чем вдвое.

Клиент PCP может явно разорвать сессию путем передачи запроса PA, указывающего разрыв (запрос PA с кодом результата SESSION_TERMINATED). После получения от клиента PCP такого сообщения сервер PCP должен ответить сообщением PA о разрыве сессии и незамедлительно удалить PCP SA. Когда клиент PCP получает отклик PA о разрыве сессии, он должен незамедлительно удалить соответствующую PCP SA.

3.4 Повторная аутентификация сессии

Партнер по сессии может принять решение о повторной аутентификации EAP, если ему нужно обновить PCP SA без инициирования новой сессии PA. Например, повторная аутентификация может возникать в случаях:

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

• достижение максимального значения порядковых номеров (в частности, когда порядковый номер достигает значения 2³² — 2¹⁶, партнер должен повторить аутентификацию).

Если сервер PCP хочет инициировать повторную аутентификацию, он отправляет клиенту PCP сообщение PA-Server с кодом результата RE-AUTHENTICATION, показывающим желание повторной аутентификации. Если клиент считает возможным повтор аутентификации, он передает серверу PCP сообщение PA-Client с кодом результата RE-AUTHENTICATION. После этого партнеры обмениваются сообщениями PA для передачи используемых при повторной аутентификации сообщений EAP. В процессе повторной аутентификации партнеры защищают целостность своих сообщений PA с использованием ключа и алгоритма MAC из текущей PCP SA, Порядковые номера, связанные с этими сообщениями, будут возрастать, как описано в параграфе 6.4. В сообщении PA-Server с запросом EAP указывается код результата AUTHENTICATION_REQUIRED, а в сообщении PA-Client с откликом EAP — AUTHENTICATION_REPLY.

При успешном завершении повторной аутентификации EAP в последнем сообщении PA-Server указывается код результата AUTHENTICATION_SUCCEEDED. В этом случае перед отправкой сообщения PA-Server сервер PCP должен обновить SA и использовать новый ключ для генерации подписи сообщения PA-Server и последующих сообщений PCP. Кроме того, в конце сообщения PA-Server должна добавляться опция SESSION_LIFETIME, показывающая срок действия новой сессии PA. Порядковые номера сообщений PA и PCP должны быть сброшены в 0.

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

В процессе выполнения повторной аутентификации партнеры могут обмениваться в сессии и обычными сообщениями PCP. Такие сообщения должны защищаться с использованием текущей SA, пока не будет создана новая SA. Последовательность обмена сообщениями EAP для повторной аутентификации не меняется в зависимости от инициатора. Если сервер PCP получает запрос повторной аутентификации от клиента PCP после того, как сам сервер отправил подобный запрос, ему следует отбросить свой запрос и ответить на клиентский запрос.

4 Защищенная связь PA

В начале сессии PA каждое устройство PCP должно создать и инициализировать информацию о состоянии для новой защищенной связи PA (PCP SA) с целью поддержки данных о состоянии в течение срока действия сессии PA. Параметры сессии PCP SA включают:

• IP-адрес и номер порта UDP клиента PCP.

• IP-адрес и номер порта UDP сервера PCP.

• Идентификатор сессии.

• Порядковый номер для следующего исходящего сообщения PA.

• Порядковый номер для следующего входящего сообщения PA.

• Порядковый номер для следующего исходящего сообщения PCP.

• Порядковый номер для следующего входящего сообщения PCP.

• Данные из последнего исходящего сообщения.

• Интервал повтора передачи.

• Первичный сеансовый ключ (MSK) созданный с помощью EAP.

• Алгоритм MAC для транспортного ключа, который будет применяться при генерации подписи сообщений PCP.

• Псевдослучайная функция, согласованная при начальном обмене сообщениями PA-Server и PA-Client для создания транспортного ключа.

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

• Случайное значение nonce выбранное клиентом PCP при организации сессии.

• Идентификатор транспортного ключа (key ID).

  Транспортный ключ рассчитывается по формуле

  prf(MSK, «IETF PCP» || Session ID || Nonce || key ID)

  prf — псевдослучайная функция, указанная в опции PRF (параграф 5.7);

  MSK — первичный сеансовый ключ, созданный методом EAP;

  «IETF PCP» — ASCII-представление строки без завершающего null-символа (без кавычек);

  || — оператор конкатенации;

  Session ID — идентификатор сессии, для которой создан ключ MSK;

  Nonce — случайное значение, выбранное клиентом и переданное в начальном сообщении PA-Client;

  Key ID — идентификатор транспортного ключа.

5 Формат пакетов

5.1 Формат пакетов с сообщениями PCP Auth

Формат сообщения PA-Server идентичен формату отклика, описанному в параграфе 7.2 [RFC6887]. В качестве кода результата сообщения PA-Server с запросом EAP должно использоваться значение AUTHENTICATION_REQUEST.

Этот документ меняет трактовку поля Reserved (см. рисунок 1) в заголовке Request, описанного в параграфе 7.1 [RFC6887] для передачи данных, связанных с конкретной операцией.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |   Reserved    |Opcode-specific|
|               | |             |               |   data        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Requested Lifetime (32 бита)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            PCP Client's IP Address (128 битов)                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                  Opcode-specific information                  :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                 (необязательно) PCP Options                   :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

В сообщениях PA-Client (рисунок 2) используется заголовок запроса, показанный на рисунке 1. Специфические для операции данные служат для передачи кода результата (например, INITIATION, AUTHENTICATION_FAILED). Остальные поля рисунка 2 описаны в параграфе 7.1 документа [RFC6887]. В качестве кода результата сообщений PA-Client с откликом EAP должно использоваться значение AUTHENTICATION_REPLY.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |   Reserved    |  Result Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Requested Lifetime (32 бита)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            PCP Client's IP Address (128 битов)                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                  Opcode-specific information                  :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                 (необязательно) PCP Options                   :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат сообщения PA-Client

Поля Lifetime в сообщениях PA-Client и PA-Server устанавливаются в 0 при передаче и игнорируются на приеме.

5.2 Данные операции AUTHENTICATION

Формат специфических для операции AUTHENTICATION данных показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Sequence Number                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Session ID — идентификатор сессии

32-битовый идентификатор сессии PA.

Sequence Number — порядковый номер

32-битовый порядковый номер. Порядковый номер должен увеличиваться с каждым новым (не повторным) исходящим сообщением PA для обеспечения гарантий порядка сообщений PA.

5.3 Опция NONCE

Поскольку идентификатор сессии PA определяется сервером PCP, клиент PCP не знает идентификатора, который будет применяться, на момент отправки сообщения PA-Initiation. Для предотвращения атак с перехватом процесса аутентификации путем отправки обманных сообщений PA-Server клиенту PCP нужно указать случайное значение в поле nonce сообщения PA-Initiation. Сервер PCP будет добавлять это значение nonce в конец своего начального сообщения PA-Server. Если сообщение PA-Server не содержит корректного значение nonce, оно должно быть отброшено без уведомления.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Nonce                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

4.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

4 октета.

Nonce

Случайное 32-битовое значение, которое передается в сообщении PA-Initiation и соответствующем отклике сервера PCP.

5.4 Опция AUTHENTICATION_TAG

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Sequence Number                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Key ID                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Authentication Data (переменный)                |
~                                                               ~
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поскольку в сообщениях PCP общего назначения код операции для аутентификации не предусмотрен, для передачи значений Session ID и Sequence Number в обычных сообщениях PCP используется специальный тег.

Option Code — код опции

5.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

Размер опции AUTHENTICATION_TAG для обычного сообщения PCP (в октетах), включая 12-октетный заголовок и аутентификационные данные переменного размера.

Session ID — идентификатор сессии

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

Sequence Number — порядковый номер

32-битовый порядковый номер. В данной опции порядковый номер требуется инкрементировать для каждого нового (не повторного) обычного сообщения PCP для обеспечения упорядоченной доставки.

Key ID — идентификатор ключа

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

Authentication Data — данные аутентификации

Поле переменного размера, в котором передается код аутентификации (MAC¹¹) для обычного сообщения PCP. Генерация кода зависит от алгоритма, заданного в PCP SA. Поле должно заканчиваться на 32-битовой границе и при необходимости дополняется нулями.

5.5 Опция PA_AUTHENTICATION_TAG

Эта опция служит для аутентификации сообщений PA. В отличие от опции AUTHENTICATION_TAG для обычных сообщений PCP поля Session ID и Sequence Number не используются, поскольку соответствующая информация представлена в поле Opcode-specific information операции AUTHENTICATION.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Key ID                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Authentication Data (переменный)                |
~                                                               ~
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

6.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

Размер опции PA_AUTHENTICATION_TAG¹² для сообщения PCP Auth (в октетах), включая 4-октетный заголовок и аутентификационные данные переменного размера.

Key ID — идентификатор ключа

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

Authentication Data — данные аутентификации

Поле переменного размера, содержащее код аутентификации (MAC) для сообщения PCP Auth. Генерация кода зависит от алгоритма, заданного в PCP SA. Поле должно заканчиваться на 32-битовой границе и при необходимости дополняется нулями.

5.6 Опция EAP_PAYLOAD

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           EAP Message                         |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

7.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

Переменное значение.

EAP Message — сообщение EAP

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

5.7 Опция PRF

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          PRF                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

8.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

4 октета.

PRF — псевдослучайная функция

Псевдослучайная функция, которую отправитель использовал для генерации MSK. Это поле содержит значение, указывающее преобразование типа 2 протокола обмена ключами IKEv2¹³ [RFC7296] [RFC4868]. Реализации PCP должны поддерживать PRF_HMAC_SHA2_256 (transform ID = 5).

5.8 Опция MAC_ALGORITHM

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    MAC Algorithm ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

9.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

4 октета.

MAC Algorithm ID — идентификатор алгоритма MAC

Указывает алгоритм MAC, который отправитель использует для генерации аутентификационных данных. Поле MAC Algorithm ID содержит значение, указывающее преобразование типа 3 протокола обмена ключами IKEv2 [RFC7296] [RFC4868]. Реализации PCP должны поддерживать AUTH_HMAC_SHA2_256_128 (transform ID = 12).

5.9 Опция SESSION_LIFETIME

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Session Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

10.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

4 октета.

Session Lifetime — срок действия сессии

32-битовое целое число из диапазона от 0 до 2³²-1, определяющее срок действия сессии PA в секундах.

5.10 Опция RECEIVED_PAK

Эта опция используется в сообщениях PA-Acknowledgement для индикации приема сообщения PA с порядковым номером.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Received Sequence Number                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

11.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

4 октета.

Received Sequence Number — полученный порядковый номер

Порядковый номер в последнем принятом сообщении PA.

5.11 Опция ID_INDICATOR

Опция ID_INDICATOR используется клиентом PCP для определения свидетельств, которые нужно предъявить серверу PCP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option-Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          ID Indicator                         |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code — код опции

12.

Reserved — резерв

8 битов, которые должны иметь значение 0 при передаче и должны игнорироваться на приеме.

Option-Length — размер опции

Переменное значение.

ID Indicator — индикатор идентификатора

Идентифицирует орган, выдавший свидетельства EAP, которые будут применяться для аутентификации клиента. Это поле недопустимо завершать null-символом и его размер указывается в поле Option-Length. В частности, при получении клиентом опции ID_INDICATOR недопустимо трактовать наличие null-символа в качестве индикатора завершения поля ID Indicator.

Поле должно заканчиваться на 32-битовой границе и при необходимости дополняется нулями. В поле ID Indicator помещается строка в кодировке UTF-8 [RFC3629], соответствующая профилю UsernameCaseMapped для PRECIS IdentifierClass [RFC7613]. Клиент PCP проверяет соответствие поля ID Indicator профилю UsernameCaseMapped для PRECIS IdentifierClass. Клиент PCP применяет правила, приведенные в параграфе 3.2.2 [RFC7613] для отображения поля ID Indicator. Полученную в результате строку клиент PCP сравнивает с хранящимися локально идентификаторами для выбора используемых при аутентификации свидетельств. Две строки считаются при сравнении эквивалентными, если они совпадают в каждом октете.

6 Правила обработки

6.1 Генерация аутентификационных данных

После успешной аутентификации EAP все сообщения PCP в данной сессии PA должны включать тег аутентификации с подписью сообщения PCP для аутентификации источника и защиты целостности.

• Перед генерацией подписи для сообщения PA устройство сначала должно найти PCP SA, соответствующую идентификатору сессии и получить транспортный ключ. Далее устройство добавляет опцию PA_AUTHENTICATION_TAG в конец сообщения PCP Auth. Размер поля Authentication Data определяется алгоритмом MAC, выбранным для сессии. После этого устройство помещает в поле Key ID идентификатор транспортного ключа и устанавливает для поля Authentication Data значение 0. Затем устройство генерирует подпись для всего сообщения PCP (включая заголовок PCP и опцию PA_AUTHENTICATION_TAG), используя транспортный ключ и соответствующий алгоритм MAC. Полученное в результате значение помещается в поле Authentication Data.

• Подобно генерации подписи для сообщения PA перед генерацией подписи для обычного сообщения PCP устройство должно найти PCP SA, соответствующую идентификатору сессии и получает транспортный ключ. Далее устройство добавляет опцию AUTHENTICATION_TAG в конец сообщения PCP. Размер поля Authentication Data определяется используемым в сессии алгоритмом MAC. Далее устройство использует значения, полученные из SA для заполнения полей Session ID, Sequence Number и Key ID, а также устанавливает в поле Authentication Data значение 0. После этого устройство генерирует подпись для всего сообщения PCP (включая заголовок PCP и опцию AUTHENTICATION_TAG), используя транспортный ключ и соответствующий алгоритм MAC. Полученное в результате значение помещается в поле Authentication Data.

6.2 Проверка аутентификационных данных

Когда устройство получает обычное сообщение PCP с опцией AUTHENTICATION_TAG, оно должно использовать поле Session ID из этой опции для нахождения подходящей SA и получения соответствующего транспортного ключа (с использованием Key ID из опции) и алгоритма MAC. Если подходящей SA или транспортного ключа найти не удалось или не корректен порядковый номер (см. параграф 6.5), устройство PCP прекращает обработку сообщения и отбрасывает его без уведомления. После сохранения поля Authentication из опции AUTHENTICATION_TAG устройство заполняет поле Authentication нулями и генерирует подпись для сообщения (включая заголовок PCP и опцию AUTHENTICATION_TAG), используя транспортный ключ и алгоритм MAC. Если полученное значение подписи совпадает с сохраненным, устройство может быть уверено в том, что пакет не был подменен и проверка на этом завершается. Если значения не совпадают, устройство PCP прекращает обработку сообщения и отбрасывает его без уведомления.

Аналогичный процесс выполняется при получении сообщения PA с опцией PA_AUTHENTICATION_TAG для аутентификации PCP. Устройство должно использовать поле Session ID из Opcode для поиска соответствующей SA и получения транспортного ключа (с использованием Key ID из опции) и алгоритма MAC. Если подходящей SA или транспортного ключа не найдено или порядковый номер не корректен (см. параграф 6.4), устройство PCP прекращает обработку сообщения PCP и отбрасывает его без уведомления. После сохранения поля Authentication из опции PA_AUTHENTICATION_TAG устройство заполняет поле Authentication нулями и генерирует подпись для сообщения (включая заголовок PCP и опцию PA_AUTHENTICATION_TAG ), используя транспортный ключ и алгоритм MAC. Если полученное значение подписи совпадает с сохраненным, устройство может быть уверено в том, что пакет не был подменен и проверка на этом завершается. Если значения не совпадают, устройство PCP прекращает обработку сообщения и отбрасывает его без уведомления.

6.3 Правила повтора передачи сообщений PA

Поскольку в обеспечении гарантированной доставки EAP полагается на нижележащие протоколы, после передачи сообщения PA клиенту/серверу PCP недопустимо передавать какие-либо последующие сообщения, пока от партнера не будет получено сообщение PA с подходящим порядковым номером. Если такого сообщения не будет получено, устройство PCP будет повторять передачу последнего сообщения в соответствии с правилами повтора. В данной специфиации используются правила повтора передачи, заданные в параграфе 8.1.1 базовой спецификации PCP [RFC6887]. В базовом протоколе PCP эти правила повтора применяются только клиентами PCP. Однако данная спецификация распространяет политику повтора и на серверы PCP. Если время максимальной продолжительности повторов (в секундах) истекло, а ожидаемого отклика не было получено, устройство будет прерывать сессию и отбрасывать текущую связь SA.

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

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

Когда устройство получает повтор последнего входящего сообщения PA от своего партнера по сессии, оно должно попытаться повторить передачу последнего исходящего сообщения PA. Однако, если дубликат имеет тот же порядковый номер, но отличается от оригинального сообщения, устройство должно отбросить дубликат. Для решения этой задачи устройству может сохранение последнего входящего сообщения и связанных с ним ответных сообщений. Если для оригинала полученного дубликата еще не было отправлено ответных сообщений PA, устройство должно передать сообщение PA-Acknowledgement. Частота повтора откликов на дубликаты сообщений PA должна быть ограничена с целью обеспечения устойчивости к DoS-атакам¹⁴.) Детали такого ограничения выходят за рамки данной спецификации.

6.4 Порядковые номера для сообщений PCP Auth

PCP использует для доставки сигнальных сообщений транспортный протокол UDP, который не обеспечивает гарантий доставки и сохранения порядка следования пакетов. Для обеспечения надежной доставки сообщений EAP при каждом обмене сообщениями PCP в процессе аутентификации EAP в сообщениях должны указываться монотонно возрастающие порядковые номера. В течение сессии PA устройство PCP должно поддерживать два порядковых номера для сообщений PA — один номер для входящих сообщений, другой для исходящих. При генерации исходящего сообщения PA устройство добавляет сохраненное значение порядкового номера в создаваемое сообщение и увеличивает хранящийся для этой SA порядковый номер на 1. При получении от партнера по сессии сообщения PA устройство не будет воспринимать данный пакет если содержащийся в нем порядковый номер не совпадает со входящим порядковым номером, сохраненным устройством. Если полученный порядковый номер корректен, устройство принимает сообщение и увеличивает хранящийся для данной SA входящий порядковый номер на 1.

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

Для сценария повторов сообщений имеется еще одно исключение. Как было отмечено в параграфе 6.3, если устройство PCP не получает какого-либо отклика от партнера по сессии, оно должно повторить последнее отправленное сообщение PA в соответствии с процедурой повтора, описанной в параграфе 8.1.1 [RFC6887]. Исходное сообщение и его дубликат должны быть идентичны (с точностью до бита). При получении устройством такого дубликата сообщения PA от партнера по сессии, оно должно заново передать свое последнее исходящее сообщение PA. В таких случаях повторная передача не ведет к изменению хранящихся порядковых номеров.

6.5 Порядковые номера для обычных сообщений PCP

При транспортировке обычных сообщений PCP в сессии PA устройству PCP требуется поддерживать порядковые номера для исходящих и входящих сообщений PCP. При генерации нового исходящего сообщения PCP устройство PCP помещает в поле Sequence Number в опции AUTHENTICATION_TAG хранящееся для данной SA значение исходящего порядкового номера и увеличивает хранимый номер на 1.

При получении сообщения PCP от партнера по сессии устройство PCP не будет воспринимать такой пакет, если порядковый номер в нем меньше сохраненного устройством значения входящего порядкового номера. Это обеспечивает защиту устройства PCP от атак с повторным использованием перехваченных пакетов (replay attack). При получении корректного порядкового номера устройство PCP воспринимает пакет и помещает номер из него в хранилище входящих порядковых номеров для данной PCP SA.

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

Отметим, что в соответствии с базовой спецификацией PCP [RFC6887] клиент PCP должен выбрать значение nonce для каждого запроса MAP или PEER и это значение nonce возвращается клиенту в отклике. Однако возможно использование клиентом одного значения nonce для множества запросов MAP или PEER что может создавать риск атак с повторным использованием пакетов. Эта проблема решается за счет использования порядковых номеров в откликах PCP.

6.6 Учет MTU

За обработку MTU отвечают методы EAP, поэтому в PCP не требуется специальных средств для обработки MTU. В частности, нижние уровни EAP показывают методы EAP, а также MTU серверов AAA¹⁵ нижележащих уровней. Методы EAP (типа EAP-TLS [RFC5216], TEAP [RFC7170] и т. п.), в которых пакеты вероятно превосходят разумные значения MTU, поддерживают фрагментация и сборку фрагментов. Для прочих методов EAP (например, EAP-GPSK¹⁶ [RFC5433]) предполагается, что размер пакетов никогда не превосходит значение MTU.

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

7 Согласование с IANA

Ниже приведен код операции PCP (PCP Opcode), выделенный из диапазона Standards Action в реестре PCP Opcodes, доступном по ссылке http://www.iana.org/assignments/pcp-parameters.

3 AUTHENTICATION — аутентификация

Ниже перечислены коды результатов PCP, выделенные из диапазона Standards Action в реестре PCP Result Codes, доступном по ссылке http://www.iana.org/assignments/pcp-parameters.

14 INITIATION — инициирование

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

15 AUTHENTICATION_REQUIRED — требуется аутентификация

Отклик с таким кодом передается клиенту в тех случаях, когда требуется аутентификация EAP.

16 AUTHENTICATION_FAILED — отказ при аутентификации

Отклик для клиента об ошибке, связанной с отказом при аутентификации EAP.

17 AUTHENTICATION_SUCCEEDED — успешная аутентификация

Отклик, передаваемый клиенту после успешной аутентификации EAP.

18 AUTHORIZATION_FAILED — отказ при проверке полномочий

Отклик с таким кодом ошибки передается клиенту в тех случаях, когда аутентификация EAP прошла, но проверка полномочий (authorization) завершилась отказом.

19 SESSION_TERMINATED — сессия прервана

Этот код результата указывает партнеру на то, что сессия PA была прервана.

20 UNKNOWN_SESSION_ID — неизвестный идентификатор сессии

Отклик с таким кодом сервер PCP передает в случаях, когда он не обнаруживает сессии PA, связанной с полем Session ID в запросе PA или обычном запросе клиента PCP.

21 DOWNGRADE_ATTACK_DETECTED — обнаружена атака на снижение уровня

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

22 AUTHENTICATION_REQUEST — запрос аутентификации

С помощью этого кода сервер показывает клиенту, что сообщение PA содержит запрос EAP.

23 AUTHENTICATION_REPLY — отклик при аутентификации

Клиенту показывает серверу, что сообщение PA содержит отклик EAP.

В последующих параграфах описаны опции PCP, выделенные из диапазона Standards Action реестра опций PCP, доступного по ссылке http://www.iana.org/assignments/pcp-parameters.

7.1 NONCE

Название: NONCE.

Значение: 4.

Назначение: см. параграф 5.3.

Используется с операцией: AUTHENTICATION.

Размер: 4 октета.

Может присутствовать в: запросах и откликах

Максимальное количество: 1.

7.2 AUTHENTICATION_TAG

Название: AUTHENTICATION_TAG.

Значение: 5.

Назначение: см. параграф 5.4.

Используется с операцией: MAP, PEER, ANNOUNCE.

Размер: переменный

Может присутствовать в: запросах и откликах.

Максимальное количество: 1.

7.3 PA_AUTHENTICATION_TAG

Название: PA_AUTHENTICATION_TAG.

Значение: 6.

Назначение: см. параграф 5.5.

Используется с операцией: AUTHENTICATION.

Размер: переменный

Может присутствовать в: запросах и откликах.

Максимальное количество: 1.

7.4 EAP_PAYLOAD

Название: EAP_PAYLOAD.

Значение: 7.

Назначение: см. параграф 5.6.

Используется с операцией: AUTHENTICATION.

Размер: переменный

Может присутствовать в: запросах и откликах.

Максимальное количество: 1.

7.5 PRF

Название: PRF.

Значение: 8.

Назначение: см. параграф 5.7.

Используется с операцией: AUTHENTICATION.

Размер: 4 октета.

Может присутствовать в: запросах и откликах.

Максимальное количество: с учетом максимального размера сообщений PCP.

7.6 MAC_ALGORITHM

Название: MAC_ALGORITHM.

Значение: 9.

Назначение: см. параграф 5.8.

Используется с операцией: AUTHENTICATION.

Размер: 4 октета.

Может присутствовать в: запросах и откликах.

Максимальное количество: с учетом максимального размера сообщений PCP.

7.7 SESSION_LIFETIME

Название: SESSION_LIFETIME.

Значение: 10.

Назначение: см. параграф 5.9.

Используется с операцией: AUTHENTICATION.

Размер: 4 октета.

Может присутствовать в: откликах.

Максимальное количество: 1.

7.8 RECEIVED_PAK

Название: RECEIVED_PAK.

Значение: 11.

Назначение: см. параграф 5.10.

Используется с операцией: AUTHENTICATION.

Размер: 4 октета.

Может присутствовать в: запросах и откликах.

Максимальное количество: 1.

7.9 ID_INDICATOR

Название: ID_INDICATOR.

Значение: 12.

Назначение: см. параграф 5.11.

Используется с операцией: AUTHENTICATION.

Размер: переменный.

Может присутствовать в: запросах.

Максимальное количество: 1.

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

Как описано в данной спецификации, после успешного завершения процесса аутентификации EAP между двумя устройствами PCP будет экспортироваться ключ MSK. Первичный ключ MSK служит для создания транспортных ключей, используемый при генерации MAC-подписей для последующих сообщений PCP. Однако до момента создания транспортного ключа сообщения PA в сессии PA имеют слабую криптографическую защиту и, если заранее между партнерами не был организован защищенный канал, такие сообщения могут послужить объектом MITM¹⁷ или DoS-атак. Например, начальный обмен сообщениями PA-Server и PA-Client уязвим для атак с подменой (spoofing) поскольку для сообщений не используется аутентификации и защиты целостности. Кроме того, поскольку на этом этапе происходит обмен алгоритмами PRF и MAC, атакующий может предпринять попытку удаления опций PRF и MAC, задающих строгие алгоритмы, из начального сообщения PA-Server и вынудить клиента к выбору более слабых алгоритмов. Следовательно, серверам следует обеспечивать высокую надежность всех поддерживаемых ими алгоритмов PRF и MAC.

Для предотвращения простых DoS-атак устройствам PCP следует генерировать информацию о состоянии, как только это станет возможным для начальных сообщений PA-Server и PA-Client. Выбор метода EAP также очень важен. Выбранный метод EAP должен (1) быть устойчивым к атакам, которые возможны в незащищенной сетевой среде, (2) обеспечивать защиту от атак по словарю и (3) поддерживать организацию сеансовых ключей.

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

9 Литература

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://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, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., «Extensible Authentication Protocol (EAP)», RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.

[RFC4868] Kelly, S. and S. Frankel, «Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec», RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.

[RFC5281] Funk, P. and S. Blake-Wilson, «Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)», RFC 5281, DOI 10.17487/RFC5281, August 2008, <http://www.rfc-editor.org/info/rfc5281>.

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, «Port Control Protocol (PCP)», RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.

[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, «Tunnel Extensible Authentication Protocol (TEAP) Version 1», RFC 7170, DOI 10.17487/RFC7170, May 2014, <http://www.rfc-editor.org/info/rfc7170>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, «Internet Key Exchange Protocol Version 2 (IKEv2)», STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.

[RFC7613] Saint-Andre, P. and A. Melnikov, «Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords», RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.

[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. Cheshire, «Port Control Protocol (PCP) Proxy Function», RFC 7648, DOI 10.17487/RFC7648, September 2015, <http://www.rfc-editor.org/info/rfc7648>.

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

[RFC5216] Simon, D., Aboba, B., and R. Hurst, «The EAP-TLS Authentication Protocol», RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.

[RFC5433] Clancy, T. and H. Tschofenig, «Extensible Authentication Protocol — Generalized Pre-Shared Key (EAP-GPSK) Method», RFC 5433, DOI 10.17487/RFC5433, February 2009, <http://www.rfc-editor.org/info/rfc5433>.

[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, «Improved Extensible Authentication Protocol Method for 3^rd Generation Authentication and Key Agreement (EAP-AKA’)», RFC 5448, DOI 10.17487/RFC5448, May 2009, <http://www.rfc-editor.org/info/rfc5448>.

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

Спасибо Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen, Stephen Farrell и Terry Manderson за их полезные комментарии.

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

Margaret Cullen

Painless Security

356 Abbott Street

North Andover, MA 01845

United States

Phone: +1 781 405 7464

Email: margaret@painless-security.com

URI: http://www.painless-security.com

Sam Hartman

Painless Security

356 Abbott Street

North Andover, MA 01845

United States

Email: hartmans@painless-security.com

URI: http://www.painless-security.com

Dacheng Zhang

Beijing, China

China

Email: zhang_dacheng@hotmail.com

Tirumaleswar Reddy

Cisco Systems, Inc.

Cessna Business Park, Varthur Hobli

Sarjapur Marathalli Outer Ring Road

Bangalore, Karnataka 560103

India

Email: tireddy@cisco.com

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

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

nmalykh@gmail.com

Отменен RFC 9110.

Internet Engineering Task Force (IETF)                      E. Chen, Ed.
Request for Comments: 7606                           Cisco Systems, Inc.
Updates: 1997, 4271, 4360, 4456, 4760,                   J. Scudder, Ed.
         5543, 5701, 6368                               Juniper Networks
Category: Standards Track                                   P. Mohapatra
ISSN: 2070-1721                                         Sproute Networks
                                                                K. Patel
                                                     Cisco Systems, Inc.
                                                             August 2015

Пересмотр обработки ошибок в сообщениях BGP UPDATE

Revised Error Handling for BGP UPDATE Messages

PDF

Аннотация

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

Этот документ служит обновлением для RFC 1997, 4271, 4360, 4456, 4760, 5543, 5701 и 6368.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF¹ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG². Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

В соответствии с базовой спецификацией BGP [RFC4271], узел BGP, получивший сообщение UPDATE с некорректно сформированным атрибутом, должен разорвать сессию, через которую был получен такой атрибут. Такое поведение нежелательно, поскольку сброс сессии будет оказывать влияние не только на маршруты, связанные с некорректным атрибутом, но и на другие приемлемые маршруты, обмен которыми произошел в этой сессии. В случае необязательных переходных атрибутов поведение особенно проблематично и может приводить к уязвимостям защиты. Это связано с тем, что атрибуты могут распространяться без проверки на промежуточных маршрутизаторах, если те не распознают атрибут. В результате могут возникать «туннели атрибутов» и когда атрибут поступит на понимающий его маршрутизатор сброшенная сессия может быть не связана с маршрутизатором, послужившим причиной отказа и сброса. Хуже того, проблемные атрибуты, которые могут быть связаны с одним обновлением от единственного маршрутизатора, на момент обнаружения проблемы могут уже оказаться многократно размноженными и это может приводить к сбросу множества партнерских сессий BGP. В результате ущерб может многократно возрастать.

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

Этот документ частично пересматривает обработку ошибок в сообщениях UPDATE и содержит рекомендации для авторов документов, определяющих новые атрибуты. Кроме того, пересмотрена обработка ошибок для множества имеющихся атрибутов. В частности, пересмотрены процедуры обработки ошибок [RFC1997], [RFC4271], [RFC4360], [RFC4456], [RFC4760], [RFC5543], [RFC5701] и [RFC6368].

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

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

2. Модели обработки ошибок

В этом документе отмечены 4 разных подхода к обработке ошибок в сообщениях BGP UPDATE. Эти методы перечислены ниже в порядке снижения жесткости.

• Сброс сессии — указан в базовой спецификации BGP [RFC4271], при этом передается сообщение NOTIFICATION и сессия разрывается.

• Запрет AFI/SAFI — раздел 7 в [RFC4760] позволяет узлу BGP, обнаружившему в сообщении ошибку для данного AFI/SAFI, «игнорировать все последующие маршруты с данным AFI/SAFI, принятые в этой сессии». Мы называем это «запретом отдельного AFI/SAFI» или «запретом AFI/SAFI».

• Трактовать как отзыв — в этом варианте сообщение UPDATE содержащее связанный с ошибкой атрибут пути, должно трактоваться, как будто все указанные в нем маршруты были отозваны в поле WITHDRAWN ROUTES (или в атрибуте MP_UNREACH_NLRI, если это подходит) сообщения UPDATE, что ведет к удалению этих маршрутов из базы Adj-RIB-In в соответствии с процедурами [RFC4271].

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

3. Пересмотр обработки ошибок BGP UPDATE

Этот раздел вносит множество изменений в параграф 6.3 спецификации [RFC4271]. Трактовка конкретных атрибутов пути рассматривается в разделе 7.

1. Изменяется первый абзац параграфа.

   Старый текст

   Все ошибки, детектируемые при обработке сообщений UPDATE, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

   Новый текст

   Ошибки, детектируемые при обработке сообщений UPDATE и требующие сброса сессии, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

2. Обработка для приведенного ниже случая сохраняется без изменений.

   Если значение поля Withdrawn Routes Length или Total Attribute Length слишком велико (т. е., Withdrawn Routes Length + Total Attribute Length + 23 превосходит значение поля Length в заголовке сообщения), в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

3. Обработка ошибок Attribute Flag изменяется в соответствии с приведенным ниже текстом.

   Старый текст

   Если в любом распознанном атрибуте возникает конфликт флагов (Attribute Flags) и типа атрибута (Attribute Type Code), должно устанавливаться значение Error Subcode = Attribute Flags Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение).

   Новый текст

   Если значение бита Optional или Transitive в поле Attribute Flags конфликтует с его заданным значением, атрибут должен считаться сформированным некорректно с использованием модели «трактовать как отзыв» (treat-as-withdraw), если спецификация атрибута на требует иной обработки некорректных значения Attribute Flags.

4. При отсутствии любого обязательного общеизвестного атрибута³ в сообщении UPDATE должна использоваться модель «трактовать как отзыв» (treat-as-withdraw).

5. Модель «трактовать как отзыв» должна применяться для всех случаев, которые задают сброс сессии и включают любой из атрибутов ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC или LOCAL_PREF.

6. Должно применяться «отбрасывание атрибута» для всех случаев, которые задают сброс сессии и включают атрибут ATOMIC_AGGREGATE или AGGREGATOR.

7. Если атрибут MP_REACH_NLRI или MP_UNREACH_NLRI [RFC4760] в сообщении UPDATE встречается более одного раза, должно быть передано сообщение NOTIFICATION с субкодом ошибки Malformed Attribute List. Если какой-то иной (известный или не распознанный) атрибут встречается в сообщении UPDATE несколько раз, все вхождения, отличающиеся от первого, нужно отбрасывать, продолжая обработку UPDATE.

8. Если в сообщении UPDATE имеется множество связанных с атрибутами ошибок и для их обработки задана одна и та же модель (как описано в разделе 2), должна применяться указанная модель. В остальных случаях должно выбираться наиболее сильное действие.

9. Для поля Withdrawn Routes должна проверяться синтаксическая корректность таким же способом, как для поля NLRI⁴. Этот вопрос дополнительно рассмотрен ниже в параграфе 5.3.

10. В заключение отметим, что для использования модели «трактовать как отзыв» требуется успешно провести анализ всего поля NLRI и/или атрибутов MP_REACH_NLRI и MP_UNREACH_NLRI, который более подробно рассматривается в разделе 5. Если это невозможно, продолжается использование процедур [RFC4271] и/или [RFC4760], а это означает, что должна применяться модель «сброс сессии» (или «запрет AFI/SAFI).

4. Поля размера атрибутов

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

• В первом случае добавление размера последнего атрибута пути будет вызывать превышение Total Attribute Length при анализе вложенных атрибутов.

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

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

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

5. Разбор полей NLRI

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

Для того, чтобы облегчить выделение поля NLRI в сообщении UPDATE с искаженными атрибутами:

• атрибут MP_REACH_NLRI или MP_UNREACH_NLRI (при его наличии) нужно кодировать как самый первый атрибут пути в сообщении UPDATE;

• в сообщение UPDATE недопустимо включать более одного из перечисленных элементов — непустое поле Withdrawn Routes, непустое поле NLRI, атрибут MP_REACH_NLRI, атрибут MP_UNREACH_NLRI.

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

Если используется кодирование [RFC4271], поле NLRI для семейства индивидуальных (unicast) адресов IPv4 передается сразу же вслед за всеми атрибутами в сообщении UPDATE. При получении такого сообщения UPDATE поле NLRI можно определить, используя значения Message Length, Withdrawn Route Length и Total Attribute Length (когда они согласованы), содержащиеся в сообщении, вместо того, чтобы опираться на размеры отдельных атрибутов в сообщении.

5.2. Отсутствие NLRI

[RFC4724] определяет сообщение End-of-RIB (EoR), которое может быть представлено сообщением UPDATE, содержащим лишь атрибут MP_UNREACH_NLRI, которые представляет отсутствие NLRI (это может быть также совсем пустое сообщение UPDATE при использовании «унаследованного» кодирования). Во всех остальных документированных случаях сообщение UPDATE содержит лишь отзываемые маршруты (в поле Withdrawn Routes или атрибуте MP_UNREACH_NLRI) или анонсирует доступные маршруты (в поле NLRI или атрибуте MP_REACH_NLRI).

Таким образом, если встречается сообщение UPDATE, которое включает отличные от MP_UNREACH_NLRI атрибуты пути и не содержит ни одного доступного NLRI, мы не можем быть уверены в успешном разборе NLRI, как того требует раздел 3 в п. (j). По этой причине при наличии в таком сообщении любой ошибки в атрибутах пути и любой ошибки, задающей отличный от attribute discard вариант обработки, должна применяться модель «сброс сессии».

5.3. Синтаксическая корректность полей NLRI

Поле NLRI или Withdrawn Routes нужно считать «синтаксически некорректным», если выполняется любое из приведенных ниже условий.

• Размер любого из включенных NLRI превышает 32.

• При разборе NLRI, содержащихся в поле, размер последнего NLRI превышает размер оставшихся в поле данных.

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

• Размер любого из включенных NLRI не согласуется с данным AFI/SAFI (например, IPv4 NLRI имеет размер больше 32 или IPv6 NLRI больше 128).

• При разборе NLRI в атрибуте размер последнего NLRI превышает размер оставшихся в атрибуте данных.

• Флаг атрибута не соответствуют указанным в [RFC4760].

• Размер атрибута MP_UNREACH_NLRI меньше 3 или размер атрибута MP_REACH_NLRI меньше 5.

5.4. Typed NLRI

Некоторые семейства адресов (например, MCAST-VPN [RFC6514], MCAST-VPLS [RFC7117] EVPN [RFC7432]) имеют типизованные NLRI. Поскольку поддерживаемые семейством типы значений могут быть не выражаемыми в расширении MP-BGP⁵ [RFC4760], возможны ситуации, когда узел BGP анонсирует поддержку данного семейства и подсемейства адресов, хотя он не поддерживает конкретный тип NLRI в AFI/SAFI.

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

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

Хотя вариант обработки ошибок «трактовать как отзыв», определенный в разделе 2, делает все возможное для сохранения корректности BGP, было замечено, что сообщение UPDATE, полученные в сессиях IBGP⁶ и обработанные по этому варианту, могут приводить к несогласованности маршрутизации внутри автономной системы (AS). Последствия этого могут включать долгоживущие маршрутные петли и черные дыры. Это неприятно, однако предполагается, что проблема будет редко возникать на практике и, что более важно, негативное влияние будет существенно меньше чем при использовании вариант «сброс сессии».

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

Даже при отсутствии рассогласования маршрутов вариант «трактовать как отзыв» может приводить к полной недоступности или неоптимальной маршрутизации для адресов, чьи маршруты содержались в затронутом сообщении UPDATE.

Отметим, что «трактовка как отзыва» отличается от полного отбрасывания сообщения UPDATE. Отбрасывание нарушает базовый принцип BGP в части постепенных обновлений (incremental update) и может приводить к сохранению неприемлемых маршрутов.

С учетом упомянутых возможных проблем узел BGP должен обеспечивать возможности отладки для обнаружения и устранения проблем, связанных искажением атрибутов. В число таких возможностей должна входить, по крайней мере, запись в системный журнал вовлеченных в проблему NLRI, а также самих сообщений UPDATE. Эти сообщения UPDATE следует анализировать для обнаружения источника проблем.

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

7. Процедуры обработки ошибок для существующих атрибутов

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

В этом разделе рассматриваются все атрибуты пути, определенные на момент создания документа, для которых не была определена обработка ошибок в соответствии с разделом 8 и которые не помечены как отмененные (deprecated) в реестре BGP Path Attributes [IANA-BGP-ATTRS]. Для атрибутов 17 (AS4_PATH), 18 (AS4_AGGREGATOR), 22 (PMSI_TUNNEL), 23 (Tunnel Encapsulation Attribute), 26 (AIGP), 27 (PE Distinguisher Labels) и 29 (BGP-LS Attribute) применяется обработка ошибок, описанная в разделе 8, поэтому здесь они не рассматриваются. Атрибуты 11 (DPA), 12 (ADVERTISER), 13 (RCID_PATH / CLUSTER_ID), 19 (SAFI Specific Attribute), 20 (Connector Attribute), 21 (AS_PATHLIMIT) и 28 (BGP Entropy Label Capability Attribute) были отменены и также не рассматриваются здесь.

7.1. ORIGIN

Атрибут ORIGIN считается искаженным, если размер атрибута отличается от 1 или значение атрибута не определено [RFC4271].

Сообщения UPDATE с искаженным атрибутом ORIGIN нужно обрабатывать по варианту «трактовать как отзыв».

7.2. AS_PATH

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

• Возникает «переполнение», когда поле Path Segment Length последнего сегмента будет давать значение, выходящее за пределы Attribute Length.

• Имеется «нехватка», когда после финального разобранного сегмента остается лишь один октет (т. е. оставшихся данных не хватает даже для пустого заголовка сегмента).

• Поле Path Segment Length имеет значение 0.

Сообщение UPDATE с искаженным атрибутом AS_PATH нужно обрабатывать по варианту «трактовать как отзыв».

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

7.3. NEXT_HOP

Атрибут считается искаженным, если его размер отличается от 4 [RFC4271].

Сообщение UPDATE с искаженным атрибутом NEXT_HOP нужно обрабатывать по варианту «трактовать как отзыв».

7.4. MULTI_EXIT_DISC

Атрибут считается искаженным, если его размер отличается от 4 [RFC4271].

Сообщение UPDATE с искаженным атрибутом MULTI_EXIT_DISC нужно обрабатывать по варианту «трактовать как отзыв».

7.5. LOCAL_PREF

Обработка ошибок [RFC4271] изменяется как показано ниже:

• если атрибут LOCAL_PREF получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут»;

• когда атрибут LOCAL_PREF получен от внутреннего соседа, его нужно считать искаженным, если размер отличается от 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.6. ATOMIC_AGGREGATE

Атрибут нужно считать искаженным, если его размер отличается от 0 [RFC4271].

Сообщение UPDATE с искаженным атрибутом ATOMIC_AGGREGATE нужно обрабатывать по варианту «отбросить атрибут».

7.7. AGGREGATOR

Ошибки этого атрибута, указанные в [RFC4271], пересмотрены как указано ниже.

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

• размер атрибута не равен 6 (когда поддержка 4-октетных номеров AS не анонсирована партнером и таких номеров не было принято от него [RFC6793]).

• размер атрибута не равен 8 (когда партнер анонсирует и передает 4-октетные номера AS).

Сообщение UPDATE с искаженным атрибутом AGGREGATOR нужно обрабатывать по варианту «отбросить атрибут».

7.8. Community

Обработка ошибок, указанная в [RFC1997], пересмотрена как показано ниже.

• Атрибут Community нужно считать искаженным, если он не кратен 4.

• Сообщение UPDATE с искаженным атрибутом Community нужно обрабатывать по варианту «трактовать как отзыв».

7.9. ORIGINATOR_ID

Обработка ошибок, указанная в [RFC4456], пересмотрена как показано ниже.

• Если атрибут ORIGINATOR_ID получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут».

• Когда атрибут получен от внутреннего соседа, его нужно считать искаженным, если размер отличается от 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.10. CLUSTER_LIST

Обработка ошибок, указанная в [RFC4456], пересмотрена как показано ниже.

• Когда атрибут CLUSTER_LIST получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут».

• Когда атрибут получен от внутреннего соседа, его нужно считать искаженным, если размер не кратен 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.11. MP_REACH_NLRI

Если Length в поле Next Hop Network Address атрибута MP_REACH не соответствует ожидаемому значению, атрибут считается искаженным. Поскольку следующий интервал предшествует в атрибуте полю NLRI, такая ситуация не позволяет надежно определить NLRI, поэтому должен использоваться вариант «сброс сессии» или «запрет AFI/SAFI».

Термин «ожидаемое» не является достаточно точным и относится к размеру адреса следующего интервала для Address Family Identifier или Subsequent Address Family Identifier, который может меняться в зависимости от используемого расширения. Например, при использовании [RFC5549] адрес следующего интервала будет иметь размер 4 или 16.

Дополнительное рассмотрение обработки этого атрибута приведено в разделах 3 и 5.

7.12. MP_UNREACH_NLRI

Обработка этого атрибута рассмотрена в разделах 3 и 5.

7.13. Traffic Engineering

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

7.14. Extended Community

Описанная в [RFC4360] обработка ошибок пересмотрена как показано ниже.

• Атрибут Extended Community нужно считать искаженным, если его размер не кратен 8.

• Сообщение UPDATE с искаженным атрибутом Extended Community нужно обрабатывать по варианту «трактовать как отзыв».

Отметим, что для узлов BGP недопустимо считать ошибкой нераспознанный тип или субтип Extended Community.

7.15. IPv6 Address Specific Extended Community

Описанная в [RFC5701] обработка ошибок пересмотрена как показано ниже.

• Атрибут IPv6 Address Specific Extended Community нужно считать искаженным, если его размер не кратен 20.

• Сообщение UPDATE с искаженным атрибутом IPv6 Address Specific Extended Community нужно обрабатывать по варианту «трактовать как отзыв».

Отметим, что для узлов BGP недопустимо считать ошибкой нераспознанный тип или субтип IPv6 Address Specific Extended Community.

7.16. ATTR_SET

Заключительный параграф раздела 5 в [RFC6368] меняется как показано ниже.

Старый текст

Сообщение UPDATE с искаженным атрибутом ATTR_SET нужно обрабатывать следующим образом. Если флаг Partial установлен, а флаг Neighbor-Complete сброшен, сообщение UPDATE считается отзывом маршрута, как описано в [OPT-TRANS-BGP]. В противном случае (т. е. флаг Partial сброшен или флаг Neighbor-Complete установлен) должна использоваться процедура из базовой спецификации BGP-4 [RFC4271] для случая Optional Attribute Error.

Новый текст

Сообщение UPDATE с искаженным атрибутом ATTR_SET нужно обрабатывать по варианту «трактовать как отзыв».

Кроме того, нормативная ссылка на [OPT-TRANS-BGP] удаляется из [RFC6368].

8. Рекомендации для авторов спецификаций BGP

Документы, задающие новые атрибуты BGP, должны указать, когда атрибут считается ошибочным (искаженным) и как обрабатывать такие ошибки. Допустимые варианты обработки ошибок описаны в разделе 2. Модель «трактовать как отзыв» (treat-as-withdraw) обычно является предпочтительной, а модель «сброс сессии» (session reset) применять не рекомендуется. Авторам документов BGP также рекомендуется прочесть обзор, посвященный необязательным переходным атрибутом в первом абзаце «Введения» настоящего документа. В документы следует также включать рассмотрение отладочных средств, которые могут потребоваться для диагностики в случаях искажения атрибута.

Для любого атрибута, искажение которого обрабатывается по варианту «отбрасывание атрибута» (attribute discard) вместо treat-as-withdraw, важно рассмотреть возможное влияние такого выбора. В частности, если рассматриваемый атрибут влияет или может влиять на выбор или установку маршрута обычно отбрасывание атрибута создает больше опасности, если тщательный анализ не подтверждает обратное. При анализе следует принимать во внимание достижение компромисса между сохранением связности и возникновением побочных эффектов.

Авторы могут ссылаться на примеры в разделе 7.

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

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

Улучшенная обработка ошибок в соответствии с этой спецификацией может оказывать негативное влияние при использовании в будущем для защиты BGP механизмов с неизвестными криптографическими слабостями. Например, при использовании (гипотетического) механизма, который не обеспечивает защиты целостности атакующий может изменять шифротекст, влияя тем самым на поведение получателя и наблюдая за его реакцией. До создания этой спецификации использовался просто разрыв сессии BGP, но использование этой спецификации дает атакующему возможность предпринять множество попыток. Хотя таких механизмов, защищающих лишь конфиденциальность, в настоящее время не применяется, в прошлом были определены механизмы с подобными (не обязательно доступными для использования) уязвимостями [RFC7366]. Рекомендуемый сегодня для предотвращения таких проблем подход заключается в использовании шифров AEAD⁷ [RFC5116] и отбрасывание сообщений, не прошедших проверку.

А других аспектах данная спецификация не меняет параметров безопасности BGP.

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

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

[IANA-BGP-ATTRS] IANA, «BGP Path Attributes», <http://www.iana.org/assignments/bgp-parameters>.

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

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

[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, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, «BGP Extended Communities Attribute», RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.

[RFC4456] Bates, T., Chen, E., and R. Chandra, «BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)», RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, «Graceful Restart Mechanism for BGP», RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.

[RFC5543] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, «BGP Traffic Engineering Attribute», RFC 5543, DOI 10.17487/RFC5543, May 2009, <http://www.rfc-editor.org/info/rfc5543>.

[RFC5701] Rekhter, Y., «IPv6 Address Specific BGP Extended Community Attribute», RFC 5701, DOI 10.17487/RFC5701, November 2009, <http://www.rfc-editor.org/info/rfc5701>.

[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, «Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

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

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

[RFC5549] Le Faucheur, F. and E. Rosen, «Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop», RFC 5549, DOI 10.17487/RFC5549, May 2009, <http://www.rfc-editor.org/info/rfc5549>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, «BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs», RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, «Multicast in Virtual Private LAN Service (VPLS)», RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.

[RFC7366] Gutmann, P., «Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-editor.org/info/rfc7432>.

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

Авторы благодарят Juan Alcaide, Deniz Bahadir, Ron Bonica, Mach Chen, Andy Davidson, Bruno Decraene, Stephen Farrell, Rex Fernando, Jeff Haas, Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Warren Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj Vairavakkalai, Lili Wang и Ondrej Zajicek за их замечания и обсуждение, а также рецензирование этого документа.

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

Enke Chen (редактор)

Cisco Systems, Inc.

Email: enkechen@cisco.com

John G. Scudder (редактор)

Juniper Networks

Email: jgs@juniper.net

Pradosh Mohapatra

Sproute Networks

Email: mpradosh@yahoo.com

Keyur Patel

Cisco Systems, Inc.

Email: keyupate@cisco.com

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                         W. Kumari
Request for Comments: 7607                                        Google
Updates: 4271                                                    R. Bush
Category: Standards Track                      Internet Initiative Japan
ISSN: 2070-1721                                              H. Schiller
                                                                  Google
                                                                K. Patel
                                                           Cisco Systems
                                                             August 2015

Упорядочение обработки AS 0

Codification of AS 0 Processing

PDF

Аннотация

Этот документ обновляет RFC 4271 и запрещает использование номера автономной системы (AS¹) 0 в атрибутах протокола BGP² OPEN, AS_PATH, AS4_PATH, AGGREGATOR и AS4_AGGREGATOR сообщений BGP UPDATE.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF³ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG⁴. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

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

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

1. Введение

AS 0 была указана в реестре IANA Autonomous System Number Registry, как резервная, которую можно использовать для немаршрутизируемых сетей (Reserved — May be use [sic] to identify non-routed networks) [IANA.AS_Numbers].

В [RFC6491] указано использование AS 0 в ROA⁵ для маркирования префикса и всех более конкретных по сравнению с ним префиксов, как не используемых в контексте маршрутизации. Это позволяет держателю ресурса указать, что префикс (и более конкретные префиксы) не следует маршрутизировать, публикуя ROA с AS 0 в качестве единственного источника. В соответствии с этим, реализации BGP должны отказываться от восприятия и распространения маршрутов, содержащих AS 0.

Ни в одной из спецификаций BGP нет четкого запрета использования AS 0. Этот документ исправляет упущение, наиболее значимое для AS_PATH. Здесь представлено изменение обработки ошибок, описанной в параграфах 6.2 и 6.3 [RFC4271], путем задания поведения для случаев присутствия AS 0.

По крайней мере две реализации протокола отбрасывают маршруты с AS 0 и данный документ упорядочивает это.

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

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

2. Поведение

Узлу BGP недопустимо создавать или распространять маршруты с AS 0 в атрибутах AS_PATH, AS4_PATH, AGGREGATOR или AS4_AGGREGATOR.

Сообщения UPDATE, содержащие AS 0 в атрибуте AS_PATH или AGGREGATOR, должны считаться некорректно сформированными и обрабатываться в соответствии с процедурами, указанными в [RFC7606].

Сообщения UPDATE, содержащие AS 0 в атрибуте AS4_PATH или AS4_AGGREGATOR, должны считаться некорректно сформированными и обрабатываться в соответствии с процедурами, указанными в [RFC6793].

Если узел BGP получает 0 в качестве номера партнерской AS в сообщении OPEN, он должен разорвать соединение и передать «сообщение NOTIFICATION с кодом ошибки OPEN Message Error и субкодом Bad Peer AS (см. раздел 6 [RFC4271]). Маршрутизаторам недопустимо инициировать соединение, заявляя AS 0.

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

3. Согласование с IANA

Агентство IANA обновило реестр 16-bit Autonomous System Numbers, указав что AS 0 является просто резервной (Reserved).

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

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

Кроме того, стандартизация поведения в случаях получения AS_PATH (или AS4_PATH) с AS 0 в этом документе делает поведение более определенным.

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

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

[IANA.AS_Numbers] IANA, «Autonomous System (AS) Numbers», <http://www.iana.org/assignments/as-numbers>.

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

[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, <http://www.rfc-editor.org/info/rfc4271>.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, «Revised Error Handling for BGP UPDATE Messages», RFC 7606, DOI 10.17487/RFC7606, July 2015, <http://www.rfc-editor.org/info/rfc7606>.

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

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, «Resource Public Key Infrastructure (RPKI) Objects Issued by IANA», RFC 6491, DOI 10.17487/RFC6491, February 2012, <http://www.rfc-editor.org/info/rfc6491>.

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

Авторы благодарят Elwyn Davies, Enke Chen, Brian Dickson, Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny McPherson, Chris Morrow, iLya, John Scudder, Jeff Tantsura, Daniel Ginsburg и Susan Hares. Если кто-то оказался забытым в этом списке, извините!

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

Warren Kumari

Google

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States

Email: warren@kumari.net

Randy Bush

Internet Initiative Japan

5147 Crystal Springs

Bainbridge Island, WA 98110

United States

Email: randy@psg.com

Heather Schiller

Google

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States

Email: has@google.com

Keyur Patel

Cisco Systems

170 W. Tasman Drive

San Jose, CA 95134

United States

Email: keyupate@cisco.com

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                           K. Lynn
Request for Comments: 7558                                  Verizon Labs
Category: Informational                                      S. Cheshire
ISSN: 2070-1721                                              Apple, Inc.
                                                             M. Blanchet
                                                                Viagenie
                                                              D. Migault
                                                                Ericsson
                                                               July 2015

Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions

Требования к расширяемому обнаружению служб на основе DNS с использованием mDNS

PDF

Аннотация

Обнаружение служб на основе DNS (DNS-SD) через Multicast DNS (mDNS) широко применяется сегодня для обнаружения и распознавания служб и имён на локальном соединении, но здесь рассматривается расширение DNS-SD/mDNS для обнаружения служб за пределами локального канала. Документ содержит постановку задачи и список требований к расширяемому DNS-SD.

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

Документ не содержит спецификации стандартов Internet и публикуется с информационными целями.

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

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

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

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

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

1. Введение

Обнаружение служб на основе DNS [DNS-SD] в сочетании с технологией Multicast DNS [mDNS] широко применяется для обнаружения и распознавания служб и имён на локальном канале. Однако при переходе к многоканальным домашним и кампусным сетям становится явным, что mDNS (по устройству) не работает через маршрутизаторы. DNS-SD может также применяться с обычным (unicast) DNS для обнаружения служб в более широкой (глобальной) области, но такая возможность ещё не получила широкого распространения. Это несоответствие потребностей пользователей и современной практики привело к разработке таких улучшений, как петиция Educause [EP].

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

Решение Multicast DNS в современной форме оптимизировано даже для сетевых технологий, где передача группового трафика обходится сравнительно дорого. Беспроводные сети, такие как Wi-Fi [IEEE.802.11], могут столкнуться проблемами при высоком уровне трафика mDNS по причине значительных издержек на передачу группового трафика. Беспроводные mesh-сети, такие как 6LoWPAN³ [RFC4944], фактически являются многоканальными подсетями [RFC4903], где групповые пакеты должны пересылаться промежуточными узлами. В интересах конечных пользователей, администраторов и производителей следует развивать сотрудничество в контексте IETF для создания эффективного, расширяемого решения с обеспечением совместимости на основе стандартов.

В этом документе содержится постановка задачи и собраны требования для расширяемых решений DNS-SD/mDNS.

1.1. Термины и сокращения

Service — служба, сервис

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

DNS-SD

Обнаружение служб на основе DNS [DNS-SD] — это обычное приложение с записями DNS о ресурсах и сообщениями для более простого именования, обнаружения и определения местоположения служб. При автономном использовании этот термин относится к unicast-протоколу для распределенных сетей.

mDNS

Multicast DNS [mDNS] — это механизм, упрощающий распределенную реализацию функций в стиле DNS (включая DNS-SD) на локальном канале без необходимости применения традиционной инфраструктуры DNS.

SSD

Расширяемое обнаружение служб (Scalable Service Discovery или Scalable DNS-SD) — это будущее расширение DNS-SD (и возможно mDNS) в соответствии с требованиями этого документа.

Scope of Discovery — область обнаружения

Подмножество локального или глобального пространства имён (например, субдомен DNS), являющееся целью данного запроса SSD.

Zero Configuration

Развёртывание SSD, не требующее администрирования (могут быть необязательные функции администрирования).

Incremental Deployment — постепенное развёртывание

Упорядоченный переход по мере развития сети с переходом от DNS-SD/mDNS к SSD.

2. Постановка задачи

Обнаружение служб за пределами локального канала возможно является одной из наиболее важных функций, отсутствующих в модели DNS-SD на основе mDNS (DNS-SD over mDNS или DNS-SD/mDNS). Другие вопросы и требования кратко изложены ниже.

2.1. Именование и обнаружение на нескольких каналах

Список желаемых улучшений DNS-SD/mDNS от сетевых администраторов исследовательского и образовательного сообщества был опубликован в петиции Educause [EP]. Ниже кратко изложены технические аспекты петиции.

• На предприятиях и в учреждениях распространено использование беспроводных каналов для доступа клиентов и кабельной инфраструктуры для серверов, которые обычно относятся к разным подсетям. Анонсирование услуг печати и потоковой передачи multimedia через DNS-SD на основе mDNS в настоящее время не обнаруживается клиентскими устройствами на другом канале. DNS-SD с обычным (unicast) DNS работает при размещении клиентов и серверов на разных каналах, но записи о ресурсах, описывающие службы, должны каким-то способом попадать в пространство имён unicast DNS.

• Записи о ресурсах DNS-SD можно вручную вносить в файл зоны обычного DNS [STATIC], но эту задачу должен выполнять администратор DNS. При динамическом выделении адресов IP устройствам, как это часто бывает при использовании DHCP, эта работа становится слишком трудоёмкой.

• Автоматической добавление записей DNS-SD с использованием DNS Update работает, но требует настройки на сервере DNS возможности использовать DNS Update и установки на устройствах свидетельств DNS Update для выполнения таких обновлений, что оказалось обременительным.

Поэтому нужен механизм заполнения пространства имён DNS соответствующими записями DNS-SD с меньшим объёмом ручного администрирования, нежели обычно требуется для традиционного (unicast) сервера DNS.

Ниже представлена сводка технических требований:

• расширяемость от сотен до тысяч устройств с поддержкой DNS-SD/mDNS в данной среде;

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

• отсутствие значительного роста сетевого трафика (кабельного и беспроводного);

• рентабельность поддержки в масштабе предприятия.

2.2. Беспроводные ЛВС IEEE 802.11

Технология Multicast DNS изначально разрабатывалась для сетей Ethernet, доминировавших тогда на канальном уровне. В сетях Ethernet с общей средой групповые кадры вносят немного дополнительных требований по сравнению с индивидуальными. Однако в сетях 802.11 групповые кадры передаются с низкой скоростью, поддерживаемой всеми приёмниками. На практике это отнимает большую часть «эфирного времени» на передачу группового трафика. Некоторые администраторы блокируют групповой трафик или используют точки доступа, передающие групповые кадры как серию индивидуальных.

Надёжность беспроводных каналов может быть на несколько порядков ниже надёжности кабельных соединений. Для повышения надёжности передачи IEEE 802.11 MAC⁴ требует подтверждения доставки индивидуальных кадров, однако подтверждение доставки групповых кадров не поддерживается. В результате в беспроводных сетях часто наблюдаются более значительные потери групповых кадров, нежели в кабельных каналах.

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

2.3. Сети со слабым питанием и потерями (LLN)

Новые технологии беспроводных mesh-сетей, такие как RPL⁵ [RFC6550] и 6LoWPAN, вызвали несколько проблем для имеющихся систем DNS-SD/mDNS. Во-первых, групповая адресация на канале [RFC4291] определена для ближайших соседей (single-hop). беспроводная mesh-сеть, представляющая одну логическую подсеть, зачастую может включать несколько узлов пересылки [RFC4903], поэтому нужна большая область действия групповой адресации [RFC7346]. Для Multicast DNS область действия намеренно ограничивалась локальным каналом, чтобы не создавать дополнительный групповой трафик вне канала (off-link).

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

3. Базовые варианты применения

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

1. Персональная сеть (Personal Area Network или PAN), простейший пример которой включает 1 сервер и одного клиента, например, переносной компьютер и принтер, на одном канале. PAN без маршрутизаторов могут работать без настройки конфигурации (Zero Configuration Networking) [ZC] с самостоятельным назначением адресов link-local [RFC3927] [RFC4862] и Multicast DNS [mDNS] для обнаружения имён и служб, как это в настоящее время используется в Mac OS X, iOS, Windows [B4W], Android [NSD].

2. Классическая домашняя сеть или hotspot (точка доступа) с приведёнными ниже свойствами.

• • Один выходной маршрутизатор. Сеть может иметь одного или несколько «восходящих» провайдеров или сетей, но весь входящий и выходящий из них трафик проходит через 1 маршрутизатор.

  • Один уровень «иерархии». Общий физический канал или несколько связанных мостами физических каналов для формирования одного логического канала, подключённого к принятому по умолчанию маршрутизатору. Один логический канал обеспечивает 1 домен широковещания, что упрощает использование Multicast DNS на локальном канале, а также ARP, что позволяет ограничиться в такой сети одной подсетью IPv4.

  • Один административный домен. Все узлы контролирует один администратор (не обязательно сетевой).

3. Расширенные домашние сети и сети небольших предприятий [RFC7368]. Похожи на (B), но содержат множество проводных и/или беспроводных каналов, обычно за одним выходным маршрутизатором. Однако узлы пересылки в основном используют самонастройку и не требуют администрирования для протокола маршрутизации. Такие сети обычно не должны требовать и администрирования DNS.

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

5. Сети ВУЗов. Похожи на (D), но администрирование ядра сети и оконечных сетей может быть разным.

6. Mesh-сети, такие как RPL и 6LoWPAN. Многоканальные подсети с префиксами, заданными одним или несколькими граничными маршрутизаторами. Могут включать как элементы сети C, D или E.

4. Требования

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

REQ1

Для случаев A, B, C следует применять режим Zero Configuration. Это предполагает способность клиентов и серверов автоматически определять принятую по умолчанию область анонсирования и поиска служб.

REQ2

Для случаев C, D, E следует обеспечивать способ настройки области обнаружения, поддерживающий диапазон топологически независимых зон (например, от подразделения до кампуса). Эта возможность должна присутствовать в протоколе и отдельные операторы не обязаны использовать её во всех случаях, в частности, для случая C может быть желательным режим Zero Configuration. При доступности нескольких областей должен быть способ перечисления вариантов выбора. Например, для C следует предлагать режим Zero Configuration (1 плоский список ресурсов) или настраиваемый (например, ресурсы, отсортированные по помещениям).

REQ3

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

REQ4

Для случаев C, D, E следует предоставлять возможность поэтапного развёртывания решения.

REQ5

SSD следует основывать на имеющихся протоколах и развёртываниях DNS-SD/mDNS, работающих на локальном канале.

REQ6

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

REQ7

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

REQ8

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

REQ9

SSD следует обеспечивать эффективную работу на основных типах канальных уровней и каналов.

REQ10

В SSD следует учитывать сети, где энергопотребление является важным фактором, например, устройства со слабым питанием или «спящие» устройства.

REQ11

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

REQ12

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

REQ13

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

REQ14

Механизмам SSD следует работать в имеющихся сетях (описанные случаи A — F) без изменений сети на физическом или межсетевом уровне.

REQ15

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

5. Пространства имён

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

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

В SSD следует поддерживать метки на национальных языках в именах экземпляров служб (Service Instance Name), как это делается сегодня в DNS-SD/mDNS. Недопустимо влияние SSD на глобальное пространство имён и инфраструктуру DNS.

Проблему публикации локальных служб в глобальном пространстве имён DNS можно рассматривать как экспорт локальных записей о ресурсах и связанных с ними меток в некую зону DNS. Вопросы определения меток, взаимодействующих в локальном и глобальном пространстве имён, рассматриваются в [INTEROP-LABELS].

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

Поскольку SSD может автоматически собирать записи о ресурсах DNS-SD и публиковать их для широкого доступа, вопросы безопасности будут вероятно включать проблемы, отмеченные в спецификациях Multicast DNS [mDNS] и [DNS-SD]. В последующих параграфах выделены возможные угрозы, возникающие при развёртывании DNS-SD на множестве каналов или автоматическом администрировании DNS-SD.

6.1. Область обнаружения

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

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

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

6.2. Разные пространства имён

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

6.3. Предоставление полномочий

DNSSEC может подтверждать действительность, но не точность записей в файле зоны. Модель доверия в глобальном DNS основана на том, что администраторы (люди) (a) вводят записи о ресурсах в файл зоны вручную или (b) настраивают сервер DNS для аутентификации доверенного устройства (например, сервера DHCP), которое может автоматически поддерживать такие записи.

Самозванец может зарегистрироваться на локальном канале и представиться легитимной службой. Такие «мошеннические» службы могут автоматически регистрироваться в unicast DNS-SD.

6.4. Проверка подлинности

До сих пор принцип plug-and-play в mDNS основывался на физическом подключении. Если устройство видимо через mDNS, оно предполагается доверенным. Однако это вряд ли корректно для чужих сетей. Если имеется риск обмана клиентов путём развёртывания мошеннических служб, следует рассмотреть вопрос аутентификации на уровне приложений. Вопросы проверки подлинности приложений выходят за рамки этого документа.

6.5. Контроль доступа

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

Хотя управление доступом к анонсируемым службам выходит за рамки DNS-SD, следует отметить, что контроль доступа сегодня зачастую обеспечивается инфраструктурой сайта (например, списки управления доступом на маршрутизаторах, межсетевые экраны) и/или соответствующими механизмами служб (например, аутентификация пользователей). Для сетевых принтеров, например, доступ может контролироваться по идентификаторам пользователей с вводом пароля. Программы Apple поддерживают такой контроль доступа для принтеров USB, совместно используемых через Mac OS X Printer Sharing, а также для многих сетевых принтеров. Таким образом, использование имеющихся в службах механизмов защиты (выходят за рамки DNS-SD) не создаёт новых проблем безопасности.

6.6. Вопросы приватности

Мобильные устройства, такие как смартфоны или ноутбуки, могут раскрывать местоположение владельцев при регистрации в разных зонах, что может создавать риски приватности. Таким устройствам недопустимо регистрировать свои службы в произвольных зонах без одобрения (согласия — opt-in) их пользователя. Однако следует обеспечивать возможность настройки одной или нескольких «безопасных» зон, где мобильные устройства могут автоматически регистрировать свои службы.

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

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

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

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

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, DOI 10.17487/RFC3927, May 2005, <http://www.rfc-editor.org/info/rfc3927>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.

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

[RFC4903] Thaler, D., «Multi-Link Subnet Issues», RFC 4903, DOI 10.17487/RFC4903, June 2007, <http://www.rfc-editor.org/info/rfc4903>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, «Transmission of IPv6 Packets over IEEE 802.15.4 Networks», RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks», RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.

[RFC7346] Droms, R., «IPv6 Multicast Address Scopes», RFC 7346, DOI 10.17487/RFC7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>.

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, «IPv6 Home Networking Architecture Principles», RFC 7368, DOI 10.17487/RFC7368, October 2014, <http://www.rfc-editor.org/info/rfc7368>.

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

[B4W] «Bonjour (software)», <http://en.wikipedia.org/wiki/Bonjour_(software)>.

[EP] Badman, L., «Petitioning Apple: From Educause Higher Ed Wireless Networking Admin Group», July 2012, <https://www.change.org/p/from-educause-higher-ed-wireless-networking-admin-group>.

[IEEE.802.11] IEEE Computer Society, «IEEE Standard for Information technology — Telecommunications and information exchange between systems Local and metropolitan area networks — Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE Std 802.11, <http://standards.ieee.org/about/get/802/802.11.html>.

[INTEROP-LABELS] Sullivan, A., «On Interoperation of Labels Between mDNS and DNS», Work in Progress, draft-sullivan-dnssd-mdns-dns-interop-01⁶, October 2014.

[NSD] Android, «NsdManager», <http://developer.android.com/reference/android/net/nsd/NsdManager.html>.

[STATIC] «Manually Adding DNS-SD Service Discovery Records to an Existing Name Server», July 2013, <http://www.dns-sd.org/ServerStaticSetup.html>.

[ZC] Cheshire, S. and D. Steinberg, «Zero Configuration Networking: The Definitive Guide», O’Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.

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

Авторы с благодарностью признают вклад в работу и комментарии от RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, Peter Van Der Stok.

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

Kerry Lynn

Verizon Labs

50 Sylvan Road

Waltham, MA 95014

United States

Phone: +1 781 296 9722

Email: kerry.lynn@verizon.com

Stuart Cheshire

Apple, Inc.

1 Infinite Loop

Cupertino, CA 95014

United States

Phone: +1 408 974 3207

Email: cheshire@apple.com

Marc Blanchet

Viagenie

246 Aberdeen

Quebec, QC G1R 2E1

Canada

Email: Marc.Blanchet@viagenie.ca

URI: http://viagenie.ca

Daniel Migault

Ericsson

8400 Boulevard Decarie

Montreal, QC H4P 2N2

Canada

Phone: +1 514 452 2160

Email: daniel.migault@ericsson.com

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

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

nmalykh@protokols.ru