Internet Engineering Task Force (IETF)                  M. Pritikin, Ed.
Request for Comments: 7030                           Cisco Systems, Inc.
Category: Standards Track                                    P. Yee, Ed.
ISSN: 2070-1721                                             AKAYLA, Inc.
                                                         D. Harkins, Ed.
                                                          Aruba Networks
                                                            October 2013

Enrollment over Secure Transport

Зачисление через защищённый транспорт

PDF

Аннотация

Этот документ описывает зачисление (регистрацию) клиентов с использованием управления сертификатами через сообщения CMS (Certificate Management over CMS или CMC) по защищённому транспорту. Этот профиль называется зачислением через защищённый транспорт (Enrollment over Secure Transport или EST) и описывает простой но полнофункциональный протокол управления сертификатами, ориентированный на клиентов инфраструктуры открытых ключей (Public Key Infrastructure или PKI), которым нужно получать сертификаты клиентов и соответствующие сертификаты удостоверяющих центров (Certification Authority или CA). Протокол также поддерживает генерируемые клиентом или CA пары ключей (открытый и секретный).

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

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

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

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

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

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

Этот документ описывает зачисление сертификатов для клиентов с использованием сообщений CMC [RFC5272] по защищённому транспорту. Протокол EST описывает применение протокола защиты транспортного уровня (Transport Layer Security или TLS) 1.1 [RFC4346], 1.2 [RFC5246] или будущей версии и протокола передачи гипертекста (Hypertext Transfer Protocol или HTTP) [RFC2616] для обеспечения аутентифицированных каналов с проверкой полномочий для запросов и откликов PKI [RFC5272].

Архитектурно служба EST размещается между CA и клиентом и выполняет несколько функций, традиционно выделенных роли агентства по регистрации (Registration Authority или RA) в PKI. Природа взаимодействия между сервером EST и CA не рассматривается в этом документе.

EST применяет модель протокола управления сертификатами (Certificate Management Protocol или CMP) [RFC4210] для обновления сертификата CA, но не использует синтаксис и протокол сообщений CMP. Серверы EST расширяемы в части задания новых функций, обеспечивающих дополнительные возможности, отсутствующие в CMC [RFC5272], и этот документ задаёт два таких расширения — одно для запроса атрибутов Certificate Signing Request, другое для запроса созданных сервером ключей.

Протоколы
+--------------------------------------------+
|                                            |
| Сообщения с запросами и откликами EST      |
|                                            |
+--------------------------------------------+
|                                            |
| HTTP для передачи сообщений и сигнализации |
|                                            |
+--------------------------------------------+
|                                            |
| TLS для защиты транспорта                  |
|                                            |
+--------------------------------------------+
|                                            |
| TCP для транспорта                         |
|                                            |
+--------------------------------------------+

Рисунок 1. Уровни EST.

EST указывает способы защищённой передачи сообщений по протоколу HTTP через TLS (HTTPS) [RFC2818], где заголовки и типы носителей HTTP используются в сочетании с TLS. HTTPS работает по протоколу TCP и этот документ не задаёт EST через HTTP/DTLS³/UDP⁴. При подходящей спецификации для комбинации HTTP, DTLS, UDP не возникает требований к EST, которые мешали бы работе на основе такого стека. На рисунке 1 показаны уровни EST.

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

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

Предполагается, что читатель знаком с терминами и концепциями, описанными в стандарте криптографии с открытым ключом (Public Key Cryptography Standard или PKCS) #10 [RFC2986], HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], TLS [RFC4346]. В дополнение к терминологии, заданной в CMC [RFC5272], здесь определён ещё ряд терминов.

EST CA

Third-Party Trust Anchor — сторонняя привязка доверия

Explicit Trust Anchor — явная привязка доверия

Implicit Trust Anchor — неявная привязка доверия

Certificate-Less TLS — TLS без сертификатов

2. Обзор вариантов применения

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

Клиенты и серверы EST настраиваются с использованием сведений, обеспечивающих взаимную проверку подлинности и предоставление полномочий. Конкретные данные инициализации зависят от доступных клиенту и серверу методов и могут включать общие секреты, имена и местоположение сетевых служб (например, URI⁵ [RFC3986]), сведения о привязках доверия (например, сертификат CA или хэш сертификата TA), ключи и сертификаты зачисления. В зависимости от принятой на предприятии практики закупок и управления сетью часть инициализации может выполнять производитель до поставки клиентского оборудования и программ. В этом случае производитель может предоставлять предприятию данные, такие как привязки доверия, по защищённой процедуре, но это выходит за рамки документа.

Распространение привязок доверия и других сертификатов возможно через сервер EST, однако о подлинности таких данных нельзя судить без наличия автономного (out-of-band) механизма их проверки.

В параграфах 2.1 — 2.3 очень точно отражён текст приложения «Сценарии» из [RFC6403] с изменениями, подходящими для этого профиля. В параграфах 2.1 — 2.6 рассмотрен набор функций EST (см. Рисунок 5) и представлен информационный обзор возможностей EST.

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

Клиент инициирует защищённую TLS сессию HTTP с сервером EST.

Запрашивается конкретный сервис EST на основе части URI, использованного для сессии.

Клиент и сервер проверяют подлинность друг друга.

Клиент проверяет полномочия сервера на обслуживание клиента.

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

Сервер действует по запросу клиента.

2.1. Получение сертификатов CA

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

В этом документе предполагается, что EST CA имеет сертификат, используемый клиентом для проверки подписанных объектов, выпущенных CA, например, сертификатов и списков отзыва сертификатов (certificate revocation list или CRL), и отличия сертификата от применяемого для проверки подписей сертификатов и CRL, используемых, когда взаимодействия протокола EST требуют дополнительного шифрования.

Клиент EST проверяет подлинность и сферу полномочий сервера EST при запросе текущих сертификатов CA. Ниже перечислены доступные варианты, описанные в параграфах 3.3.1. Аутентификация сервера на основе TLS и 3.3.3. Взаимная аутентификация TLS без сертификатов.

• Проверка соответствия HTTPS URI сервера EST сертификату сервера EST с использованием Implicit TA (как при обычном обмене HTTPS). Это позволяет клиенту и серверу EST использовать имеющиеся TA, которые могут быть известны клиенту EST.

• Клиент может использовать ранее распространённую привязку доверия, связанную с сервером EST. Это позволяет клиенту EST использовать имеющийся (возможно, более старый) сертификат CA для запроса текущего сертификата CA.

• При начальной загрузке клиент EST может полагаться на взаимную аутентификацию, выполняемую конечным пользователем в соответствии с параграфом 4.1.1. Распространение сертификатов CA при начальной загрузке.

• Клиент может использовать привязку общих свидетельств (credential) к конкретному серверу EST с шифрами TLS без применения сертификатов.

Проверка подлинности клиента не требуется для этого обмена, поэтому он тривиально поддерживается сервером EST.

2.2. Исходное зачисление

После аутентификации сервера EST и проверки его полномочий на предоставление услуг клиенту EST-клиент может получить сертификат для себя, передавая этому серверу запрос на зачисление.

Сервер EST аутентифицирует и предоставляет полномочия клиенту EST, как указано в параграфах 3.2. Уровень HTTP, 3.3.3. Взаимная аутентификация TLS без сертификатов, 3.7. Полномочия клиента. Описанные в нормативном тексте методы, упомянутые в этом обзоре, включают:

• TLS с ранее выданным сертификатом клиента (например, имеющийся сертификат от EST CA);

• TLS с ранее установленным сертификатом (например, сертификат, установленный производителем или выпущенным сторонней организацией);

• TLS без сертификатов (например, общее свидетельство, распространённое по отдельному каналу);

• HTT с использованием имени и пароля, распространённых по отдельному каналу (out-of-band).

2.2.1. Аутентификация TLS с сертификатом

Если у клиента EST имеется установленные ранее сертификат, выпущенный сторонним CA, этот сертификат может применяться для проверки подлинности запроса клиентом сертификата у сервера EST (если CA признается этим сервером). Клиент EST отвечает сообщение сервера EST с запросом сертификата TLS с использованием уже имеющегося у него сертификата. Сервер EST проверяет этот сертификат и предоставит полномочия клиенту, как указано в параграфе 3.3.2. Аутентификация клиента на основе TLS.

2.2.2. Аутентификация TLS без сертификата

Клиент и сервер EST могут проверить подлинность друг друга с применением шифров TLS без сертификатов (3.3.3. Взаимная аутентификация TLS без сертификатов).

2.2.3. Аутентификация клиента на основе HTTP

Сервер EST может запросить предоставление клиентом EST имени пользователя и пароля с использованием методов аутентификации HTTP Basic или Digest (3.2.3. Аутентификация клиента на основе HTTP). Такой подход желателен, если подлинность клиента EST не удалось проверить при согласовании TLS (3.3.2. Аутентификация клиента на основе TLS) или правила сервера EST требуют для аутентификации дополнительных сведений, как указано в параграфе 3.2.3. В любом случае аутентификация на основе HTTP выполняется только через транспорт с защитой TLS (3.3. Уровень TLS).

2.3. Повторный выпуск сертификата клиента

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

Когда текущий сертификат клиента EST может служть для аутентификации клиента TLS (3.3.2. Аутентификация клиента на основе TLS), клиент представляет этот сертификат серверу EST для своей аутентификации. Когда перевыпущенный сертификат клиента EST не подходит для аутентификации клиента TLS, можно использовать любой метод аутентификации, применённый для начального зачисления. Например, если у клиента имеется дополнительный сертификат, выданный EST CA, который можно использовать для аутентификации клиента TLS, подойдёт этот сертификат. Сообщение с запросом сертификата включает те же значения Subject и SubjectAltName, что и текущий сертификат. Замена имени запрашивается в соответствии с параграфом 4.2.2. Простое перезачисление клиентов.

2.4. Генерация ключей на сервере

Клиент EST может запросить генерируемый сервером сертификат и ключи (4.4. Генерация ключей на стороне сервера).

2.5. Сообщения Full PKI Request

Сообщения Full PKI Request [RFC5272] могут доставляться через EST с использованием функции запроса полного CMC (Full CMC Request). Это даёт доступ к функциям, не предоставляемым простым зачислением (Simple Enrollment). Сообщения Full PKI Request определены в параграфах 3.2 и 4.2 [RFC5272]. Использование EST для транспортировки этих сообщений описано в параграфе 4.3. Полные сообщения CMC.

2.6. Запрос атрибутов CSR

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

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

3. Устройство и уровни протокола

На рисунке 2 представлено расширение рисунка 1, описывающее использование уровней. Каждый из аспектов более подробно рассматривается ниже.

+----------------------------------------------------+
|                                                    |
| Типы сообщений                                     |
|   - сообщения Simple PKI (с proof-of-possession)   |
|   - извлечение сертификата CA                      |
|   - сообщения Full PKI (необязательно)             |
|     (содержат proof-of-possession)                 |
|   - запрос атрибутов CSR (необязательно)           |
|   - запрос созданного сервером ключа (необязат.)   |
|                                                    |
+----------------------------------------------------+
|                                                    |
| HTTP                                               |
|   - заголовки HTTP и URI для управления            |
|      - заголовки Content-Type задают тип сообщения |
|      - заголовки для ошибок и управления           |
|      - URI для выбора функций                      |
|   - аутентификация Basic или Digest (необязательно)|
|                                                    |
+----------------------------------------------------+
|                                                    |
| TLS для защиты транспорта                          |
|   - аутентификация сервера EST                     |
|   - аутентификация клиента EST (необязательно)     |
|   - обеспечивает целостность и конфиденциальность  |
|     коммуникаций                                   |
|   - представляет сведения о привязке [RFC5929]     |
|     каналов со связыванием proof-of-identity с     |
|     proof-of-possession на основе сообщ. (необяз.) |
|                                                    |
+----------------------------------------------------+

Рисунок 2. Использование протоколов на уровнях EST.

Задание HTTPS как защищённого транспорта для сообщений зачисления вносит два «уровня» передачи сообщений аутентификации и управления — TLS и HTTP. Уровень TLS обеспечивает защиту целостности и конфиденциальности транспорта. Подтверждение идентификации (proof-of-identity) обеспечивается аутентификацией согласования TLS и может обеспечиваться также заголовками уровня HTTP. Тип сообщения и связанные с ошибками и управлением сообщения включаются в заголовки HTTP.

В CMC (параграф 3.1 в [RFC5272]) отмечено, что «Simple PKI Request недопустимо применять, если нужно включение proof-of-identity». Поскольку уровни TLS и HTTP могут подтверждать идентификацию для клиентов и серверов EST, применяются типы сообщений Simple PKI.

Обмен сертификатами на уровне TLS обеспечивает метод проверки полномочий для запросов зачисления клиента с использованием имеющихся сертификатов. Такие сертификаты могут быть выпущены CA (у которого клиент запрашивает сертификат) или другой инфраструктурой PKI (например, свидетельство IEEE 802.1AR IDevID⁷ [IDevID]).

Доказательство владения (proof-of-possession или POP) отличается от proof-of-identity и включается в сообщения типа Simple PKI, как описано в параграфе 3.4. Подтверждение владения. Связывание proof-of-identity и proof-of-possession описано в параграфе 3.5. Связывание отождествления и сведений POP.

Этот документ также задаёт транспорт для CMC [RFC5272], который соответствует протоколам доставки CMC (CMC Transport Protocols) [RFC5273]. Механизмы CMC POP и proof-of-identity заданы в CMC, а описанные здесь механизмы могут применяться вместе с ними в сообщениях Full PKI.

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

Рисунок 3.Сертификаты и их применение.

Рисунок 4.Базы привязок доверия и их использование.

3.1. Уровень приложений

Клиент EST должен быть способен генерировать и анализировать сообщения Simple PKI (4.2. Функции для запроса сертификатов клиентами). Генерация и разбор сообщений Full PKI необязательны (4.3. Полные сообщения CMC). Клиент также должен быть способен запрашивать сертификаты CA у сервера EST и анализировать полученные «плохие» сертификаты (4.1. Распространение сертификатов CA). Запрос атрибутов CSR и анализ возвращённого списка атрибутов необязательны (4.5. Атрибуты CSR).

Детали настройки клиентских приложений EST выходят за рамки обсуждения протокола, но нужны для понимания предварительных условий инициирования протокольных операций. Рекомендуется настроить для клиента EST базы данных TA (3.3.1. Аутентификация сервера на основе TLS) или секретный ключ (3.3.3. Взаимная аутентификация TLS без сертификатов). Соответствующие этому стандарту реализации должны обеспечивать возможность указания Explicit TA. Для удобства пользователей можно задать «отпечаток» Explicit TA для начальной загрузки (4.1.1. Распространение сертификатов CA при начальной загрузке). Настройка базы данных Implicit TA, возможно, путём её включения в дистрибутив клиента EST или из операционной системы, обеспечивает гибкость наряду с предостережениями, указанными в разделе 6. Вопросы безопасности. Соответствующие этому стандарту реализации должны обеспечивать возможность отключения использования базы данных Implicit TA.

Клиент EST настраивается с информацией, достаточной для формирования URI сервера EST. Это может быть полный сегмент пути к операции (например, https://www.example.com/.well-known/est/arbitraryLabel1 или https://www.example.com/.well-known/est/), для клиента EST может быть задан кортеж, состоящей из части полномочий (authority) в URI вместе с необязательной меткой (например, www.example.com:80 или arbitraryLabel1) или просто связанная с полномочиями часть URI.

3.2. Уровень HTTP

HTTP применяется для доставки сообщений EST. Идентификаторы URI определены для обработки каждого типа носителя (т. е. типа сообщения), как описано в параграфе 3.2.2. HTTP URI для управления. HTTP также применяется для служб аутентификации клиентов при недоступности аутентификации TLS по причине отсутствия сертификата, подходящего для TLS (3.2.3. Аутентификация клиента на основе HTTP). Аутентификация HTTP может также дополнять аутентификацию TLS, если сервер EST хочет получить дополнительные сведения, как указано в параграфе 2.2.3. Аутентификация клиента на основе HTTP. Запрошенные типы носителей служат для передачи сообщений EST, как показано на рисунке 6.

HTTP 1.1 [RFC2616] и выше поддерживает постоянные соединения. Как указано в параграфе 8.1 RFC 2616, постоянные соединения могут служить для снижения нагрузки на сеть и сократить обработку, связанную с множеством запросов HTTP. EST не требует и не исключает постоянных соединений HTTP.

3.2.1. Заголовки HTTP для управления

Значение HTTP Status служит для передачи сведений об успехе или отказе функции EST. Аутентификация HTTP применяется клиентом при запросе от сервера.

Тип носителя в заголовке HTTP Content-Type указывает, какое сообщение EST передаётся. Типы носителей, используемые EST, указаны в параграфе 3.2.4. Типы сообщений.

Перенаправления HTTP (коды 3xx) на тот же web-источник (см. [RFC6454]) клиенту следует обрабатывать без ввода от пользователя, если для исходного соединения применены все нужные проверки безопасности (3.3. Уровень TLS и 3.6. Полномочия сервера). Клиент инициирует новое соединение TLS и выполняет все применимые проверки безопасности при перенаправлении на другой web-источник. Перенаправления на другие web-источники требуют от клиента EST получить от пользователя ввод для запросов не-GET или HEAD, как указано в [RFC2616]. Если клиент уже имеет сгенерированный CSR, включающий отождествление привязки и сведения POP (3.5. Связывание отождествления и сведений POP), CSR нужно создать заново для встраивания tls-unique из новой перенаправленной сессии. Отметим, что пару ключей заново создавать не требуется. Клиент получает нагрузку, связанную с интерфейсом и обработкой и администраторам серверов EST рекомендуется учитывать это.

В [RFC2616] сказано: «HTTP не использует поле Content-Transfer-Encoding (CTE) из RFC 2045», тем не менее, этот документ задаёт использование поля Content-Transfer-Encoding со значением base64 в параграфах 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2 и приложениях A.1 — A.4. HTTP является бинарно чистым транспортом, поэтому не требуется указывать это для основанных на HTTP протоколах, таких как EST. Реализациям серверов EST следует опускать заголовок Content- Transfer-Encoding, если они заранее знают, что клиенты EST не полагаются на это поле. Клиентам EST следует предполагать, что заголовок Content-Transfer-Encoding будет отсутствовать, если он заранее не согласован с сервером EST. Механизм такого согласования выходит за рамки этого документа.⁸

3.2.2. HTTP URI для управления

Сервер EST должен поддерживать использование префикса пути /.well-known/, как задано в [RFC5785], и зарегистрированное имя est. Таким образом, действительный путь URI сервера EST начинается с https://www.example.com/.well-known/est. Каждую операцию EST задаёт суффикс пути (Рисунок 5).

Рисунок 5.Операции и соответствующие суффиксы URI.

В конце рабочего пути указывается префикс (Рисунок 5) для формирования URI, используемого с HTTP GET или POST для выполнения желаемой операции EST. Примером абсолютного пути URI для операции /cacerts является /.well-known/est/cacerts. Для извлечения сертификатов CA клиент EST будет использовать строку запроса HTTP

   GET /.well-known/est/cacerts HTTP/1.1

Для запроса нового сертификата клиент EST будет использовать строку

   POST /.well-known/est/simpleenroll HTTP/1.1

Использование разных рабочих путей упрощает реализацию серверов, которые не выполняют аутентификацию клиентов при распространении откликов /cacerts.

Сервер EST может предоставлять услуги множеству CA, на что указывает необязательный добавочный сегмент пути между зарегистрированным именем приложения и рабочим путём. Для предотвращения конфликтов недопустимо совпадение метки CA с любым заданным сегментом рабочего пути. Сервер EST должен предоставлять услуги независимо от наличия дополнительного сегмента пути. Ниже показаны 3 действительных URI.

1. https://www.example.com/.well-known/est/cacerts

2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts

3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts

В этой спецификации различие между зачислением и обновлением (сменой ключей) явно указывается HTTP URI. При запросе операций /fullcmc в CMC [RFC5272] применяются одинаковые сообщения для обновления сертификата и замены ключей.

Сервер EST может предоставлять дополнительные услуги с использованием других URI.

3.2.3. Аутентификация клиента на основе HTTP

Сервер EST может запросить проверку подлинности клиента на основе HTTP. Этот запрос может быть дополнением к успешной аутентификации TLS (3.3.2. Аутентификация клиента на основе TLS), если правила сервера EST требуют дополнительной проверки (например, сервер EST может потребовать от клиента EST «знать» пароль в дополнение к «наличию» клиентского сертификата). Аутентификация клиента на основе HTTP может быть заданным правилами резервным требованием сервера EST в ситуациях, где клиент EST не смог завершить аутентификацию TLS (это может возникать при первом зачислении клиента EST или невозможности применения доступных клиенту EST сертификатов для аутентификации TLS).

Аутентификация HTTP Basic и Digest должна выполняться только по протоколу TLS 1.1 [RFC4346] или более новой версии. Шифры NULL и anon применять недопустимо, поскольку они не обеспечивают конфиденциальности и не поддерживают взаимной аутентификации с сертификатами и без них, соответственно. Как указано в Certificate Management over CMS (CMC): Transport Protocols [RFC5273], серверу «недопустимо предполагать, что клиент поддерживает какой-либо тип аутентификации HTTP, такой как cookie, Basic или Digest». Клиентам следует поддерживать механизмы Basic и Digest.

Серверы, желающие применять аутентификацию Basic и Digest отвергают запрос HTTP, используя определённый в HTTP заголовок отклика WWW-Authenticate (параграф 14.47 в [RFC2616]). Предполагается, что клиент повторит запрос, используя подходящий заголовок Authorization Request (параграф 3.2.2 в [RFC2617]), если он способен применять аутентификацию Basic или Digest. Если клиент не может повторить запрос или не поддерживает аутентификацию Basic и Digest, он должен прервать соединение.

Клиент может указать пустую строку имени пользователя («»), если он представляет пароль, не связанный с именем.

Поддержка аутентификации клиента на основе HTTP влияет на безопасность, как отмечено в разделе 6. Вопросы безопасности. Клиенту недопустимо отвечать на запрос сервером аутентификации HTTP, пока он не предоставил полномочий серверу EST в соответствии с параграфом 3.6. Полномочия сервера.

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

Этот документ использует для сообщений имеющиеся типы носителей, заданные FTP и HTTP [RFC2585], application/pkcs10 [RFC5967], CMC [RFC5272]. Для согласованности с [RFC5273] каждый тип сообщений EST использует заголовок HTTP Content-Type с соответствующим типом носителя.

Рисунок 6. Сообщения EST и соответствующие типы носителей.

3.3. Уровень TLS

TLS обеспечивает аутентификацию, что позволяет принять решение о предоставлении полномочий (authorization). Сервер и клиент EST отвечают за согласование приемлемого набора шифров и взаимную проверку подлинности. Аутентификация TLS обычно выполняется с использованием сертификатов [RFC5280], но возможна и без применения таковых, когда ни клиент, ни сервер не представляют сертификат (3.3.3. Взаимная аутентификация TLS без сертификатов). Сервер EST должен аутентифицироваться в процессе согласования TLS, если только клиент не запросил распространение сертификатов CA при начальной загрузке (параграф 4.1.1) или Full CMC (параграф 4.3).

HTTPS [RFC2818] задаёт передачу сообщений HTTP через TLS. Протокол HTTPS должен применяться. Для всех взаимодействий EST должен использоваться протокол TLS 1.1 [RFC4346] (или более новой версии). Следует поддерживать возобновление сессий TLS [RFC5077].

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

3.3.1. Аутентификация сервера на основе TLS

Должна поддерживаться аутентификация сервера TLS с применением сертификатов. Клиент EST проверяет подлинность сервера EST в соответствии с согласованным набором шифров. Ниже приведены сведения для случая шифров с сертификатами, таких как обязательный в TLS 1.1 [RFC4346] шифр TLS_RSA_WITH_3DES_EDE_CBC_SHA. Проверка сертификатов должна выполняться в соответствии с [RFC5280]. Сертификат сервера EST должен соответствовать профилю [RFC5280].

Клиент проверяет пригодность сертификата сервера TLS с использованием своей базы Explicit TA, а при включённой базе Implicit TA — также с её использованием. Клиент должен различать применение баз Explicit TA и Implicit TA в процессе проверки подлинности для поддержки надлежащего контроля полномочий. Клиент EST должен проверять полномочия в соответствии с параграфом 3.6. Полномочия сервера. Если проверка сертификата завершается отказом, клиент может следовать процедуре, описанной в параграфе 4.1.1. Распространение сертификатов CA при начальной загрузке.

3.3.2. Аутентификация клиента на основе TLS

Аутентификация клиента TLS является рекомендуемым методом отождествления клиентов EST. Можно применять аутентификацию на основе HTTP (3.2.3. Аутентификация клиента на основе HTTP). Сервер EST проверяет подлинность клиента EST в соответствии с согласованным набором шифров. Ниже приведены сведения для случая шифров с сертификатами, таких как обязательный в TLS 1.1 [RFC4346] шифр TLS_RSA_WITH_3DES_EDE_CBC_SHA. Сервер EST должен поддерживать аутентификацию клиентов на основе сертификатов.

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

Проверка сертификатов должна выполняться в соответствии с [RFC5280]. Сертификат клиента EST должен соответствовать профилю [RFC5280].

Сервер проверяет пригодность сертификата клиента TLS с использованием своей базы Explicit TA, а при включённой базе Implicit TA — также с её использованием. Сервер должен различать применение баз Explicit TA и Implicit TA в процессе проверки подлинности для поддержки надлежащего контроля полномочий. Сервер EST должен проверять полномочия в соответствии с параграфом 3.7. Полномочия клиента.

Если клиент не поддерживает аутентификацию TLS, он должен поддерживать аутентификацию на основе HTTP (3.2.3. Аутентификация клиента на основе HTTP) или аутентификацию TLS ьез сертификатов (3.3.3. Взаимная аутентификация TLS без сертификатов).

3.3.3. Взаимная аутентификация TLS без сертификатов

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

При использовании взаимной аутентификации без сертификатов TLS для развёртывания, шифронабор должен быть основан на протоколе, устойчивом к атакам по словарю, и протокол должен иметь нулевое раскрытие (zero knowledge). Для этого подходят шифры TLS-SRP⁹, т. е. шифры с _SRP_ в имени, указанные в параграфе 2.7 [RFC5054]. В разделе указаны характеристики шифров, подходящих для взаимной аутентификации без сертификатов при зачислении.

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

3.4. Подтверждение владения

Как указано в параграфе 2.1 CMC [RFC5272], доказательство владения (proof-of-possession или POP) «относится к значению, которое можно использовать для подтверждения того, что секретный ключ, соответствующий открытому ключу, находится во владении конечным объектом и может использоваться им».

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

3.5. Связывание отождествления и сведений POP

Политика сервера будет определять, должны ли клиенты использовать описанный в этом параграфе механизм. Эта спецификация предоставляет метод связывания отождествления и подтверждения владения за счёт включения сведений о текущей аутентифицированной сессии TLS в подписанный запрос сертификации. Клиент может определить, требует ли сервер связывания отождествления и POP, проверив отклик с атрибутами CSR (4.5.2. Отклик с атрибутами CSR). Независимо от такого отклика, клиентам следует связывать отождествление и POP путём встраивания уникальных значения tls-unique в запрос сертификации. Если клиент включил такую информацию, сервер должен проверять её. Сервер EST может отвергать запросы без tls-unique в соответствии со своими правилами.

Связывание отождествления и POP подтверждает серверу, что аутентифицированный клиент TLS владеет секретным ключом, связанным с запросом сертификации и может подписать запрос сертификации после организации сессии TLS. Это служит альтернативой методу «связывания отождествления и сведений POP», заданному в разделе 6 [RFC5272] и доступному при использовании сообщений Full PKI.

Клиент, генерирующий CSR, получает значение tls-unique от подсистемы TLS, как описано в Channel Bindings for TLS [RFC5929]. Операции клиента EST между получением значения tls-unique путём генерации CSR с текущим tls-unique и последующей проверкой этого значения сервером EST являются «фазами прикладного протокола в процессе аутентификации на уровне приложения». Эти операции защищены механизмом функциональной совместимости, описанных в примечаниях по функциональной совместимости (параграф 3.1) Channel Bindings for TLS [RFC5929].

При повторном согласовании должен применяться механизм TLS secure_renegotiation [RFC5746].

Значение tls-unique кодируется в формате base64 в соответствии с разделом 4 [RFC4648] и результирующая строка помещается в поле challenge-password запроса сертификации ([RFC2985], параграф 5.4.1). Размер поля challenge-password ограничен 255 байтами (параграф 7.4.9 в [RFC5246] указывает, что ни в одном наборе шифров этой проблемы не возникает). Если атрибут challenge-password отсутствует, клиент не включает необязательных сведений channel-binding (наличие challenge-password указывает включение tls-unique).

Если сервер EST использует внутреннюю (back-end) инфраструктуру для обработки, рекомендуется сообщать результаты такой проверки. Например, для этого можно использовать CMC [RFC5272] RA POP Witness Control в сообщении CMC Full PKI Request или сервер EST может использовать аутентифицированного в TLS клиента EST как элемент доверенной архитектуры, который не пересылает недействительные запросы. Подробное обсуждение этого выходит за рамки документа.

При отклонении запроса отклик сервера EST аналогичен отклику, описанному для запросов на зачисление (4.2.3. Отклик на простое зачисление или перезачисление). если включается отклик Full PKI, должно устанавливаться CMCFailInfo = popFailed. При включении сообщения об отклонении для человека в нем следует приводить информативный текст, указывающий необходимость привязки отождествления к сведениям POP.

3.6. Полномочия сервера

Клиент должен проверять полномочия сервера EST до восприятия каких-либо откликов или ответа на запросы аутентификации HTTP. Метод проверки полномочий зависит от метода аутентификации сервера. При использовании для аутентификации базы данных Explicit TA применяется параграф 3.6.1, при использовании Implicit TA — параграф 3.6.2. Успешная аутентификация с использованием шифров без сертификата предполагает, проверку полномочий сервера. Клиент может выполнять начальную загрузку в соответствии с параграфом 4.1.1 в случае отказа при проверке.

3.6.1. Клиент, использующий базу Explicit TA

Когда клиент EST применяет базу данных Explicit TA для проверки сертификата сервера EST, он должен проверить указанный URI или последнее перенаправление HTTP для URI на предмет соответствия отождествления правилам, заданным в параграфе 6.4 [RFC6125] или сертификат сервера EST должен содержать расширение использования ключей id-kp-cmcRA [RFC6402].

3.6.2. Клиент, использующий базу Implicit TA

Когда клиент EST применяет базу данных Implicit TA для проверки сертификата сервера EST, он должен проверить указанный URI или последнее перенаправление HTTP для URI на предмет соответствия отождествления правилам, заданным в параграфе 6.4 [RFC6125]. Представленный URI или последнее перенаправление HTTP для URI обеспечивает основу для предоставления полномочий и аутентифицированное отождествление сервера подтверждает полномочия сервера.

3.7. Полномочия клиента

Решение о выдаче сертификата клиенту всегда контролируется локальной политикой CA, которая отражается в конфигурации сервера EST. Данный документ не задаёт ограничений для такой политики. EST предоставляет серверу EST доступ к аутентифицированному отождествлению каждого клиента, например, к клиентскому сертификату TLS в дополнение к любым свидетельствам аутентификации HTTP для поддержки реализации такой политики.

Если сертификат клиента был выпущен EST CA и включает расширение использования ключа id-kp-cmcRA [RFC6402], клиент является агентством регистрации (Registration Authority или RA), как описано в [RFC5272] и [RFC6402]. В этом случае серверу EST следует применять политику предоставления полномочий, совместимую с клиентом RA. Например, при обработке запросов /simpleenroll сервер EST может быть настроен на восприятие сведений о привязке POP, которые не относятся к текущей сессии TLS, поскольку аутентифицированный EST клиент RA проверил эти сведения, выступая сервером EST (3.5. Связывание отождествления и сведений POP). Доступны более конкретные механизмы RA при использовании клиентом EST методов /fullcmc.

4. Детали протокольного обмена

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

4.1. Распространение сертификатов CA

Клиент EST может запросить копии текущих сертификатов CA. Эта функция обычно выполняется до прочих функций EST.

4.1.1. Распространение сертификатов CA при начальной загрузке

Возможно, что на клиенте не настроена база данных Implicit TA, которая позволяет при начальной загрузке установить базу данных Explicit TA, как описано в параграфе 4.1.3. Отклик с сертификатами CA. В этом параграфе описан другой метод, с помощью которого минимально настроенный клиент EST может заполнить свою базу данных Explicit TA.

Если клиентское приложение EST не задало базы данных (ни Explicit TA, ни Implicit TA), начальная проверка подлинности и полномочий сервера TLS завершается отказом. Клиент может продолжить согласование TLS для доступа к методу /cacerts или /fullcmc. Если клиент EST продолжает использовать неаутентифицированное соединение, он должен извлечь данные содержимого HTTP из отклика (4.1.3. Отклик с сертификатами CA или 4.3.2. Полный отклик CMC) и привлечь пользователя (человека) к проверке полномочий сертификата CA с использованием внешних (out-of-band) данных, таких как отпечаток (fingerprint) сертификата CA (например, хэш SHA-256 или SHA-512 [SHS] всего сертификата CA). В отклике /fullcmc это будет элемент управления Publish Trust Anchors (параграф 6.15 в CMC [RFC5272]) внутри отклика Full PKI, который должен быть принят вручную. Пользователь должен подобающим образом проверить данные TA или предоставить при настройке данные отпечатка, требуемые для их проверки.

На запросы аутентификации HTTP недопустимо отвечать, если сервер не был аутентифицирован в соответствии с параграфом 3.3.1. Аутентификация сервера на основе TLS или не использована аутентификация без сертификатов, как указано в параграфе 3.3.3. Взаимная аутентификация TLS без сертификатов.

Клиент EST использует отклик /cacerts для организации базы данных Explicit TA с целью последующей аутентификации TLS для сервера EST. Клиентам EST недопустимо участвовать в другом протокольном обмене, пока не будет получен отклик /cacerts и организована новая сессия TLS (с аутентификацией по сертификатам TLS).

4.1.2. Запрос сертификатов CA

Клиенты EST запрашивают сведения из базы EST CA TA для CA (в форме сертификатов) через сообщение HTTPS GET с использованием пути к операции /cacerts. Клиенты и серверы EST должны поддерживать функцию /cacerts. Клиентам следует запрашивать актуальный (up-to-date) отклик до истечения срока действия сохранённых сведений, чтобы обеспечить актуальность базы данных EST CA TA. Серверу EST не следует требовать проверки подлинности и полномочий клиента для отклика на такие запросы.

Клиент должен аутентифицировать сервер EST, как указано в параграфе 3.3.1. Аутентификация сервера на основе TLS для аутентификации по сертификатам или 3.3.3. Взаимная аутентификация TLS без сертификатов при аутентификации без сертификатов и проверять полномочия сервера в соответствии с параграфом 3.6. Полномочия сервера или следовать процедуре, описанной в 4.1.1. Распространение сертификатов CA при начальной загрузке.

4.1.3. Отклик с сертификатами CA

В случае успеха отклик сервера должен иметь код HTTP 200. Другие коды говорят об ошибке и клиент должен прервать протокол.

Отклик об успехе должен быть certs-only CMC Simple PKI Response ([RFC5272]), содержащим сертификаты, описанные в следующем параграфе. Используется HTTP content-type application/pkcs7-mime. Отклик Simple PKI передаётся с Transfer-Encoding¹⁰ base64 [RFC2045].

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

Серверу EST следует включать три сертификата Root CA Key Update (OldWithOld, OldWithNew, NewWithOld) в цепочку отклика. Они определены в параграфе 4.4 CMP [RFC4210]. Клиент EST должен быть способен обработать эти сертификаты в отклике. Последний самоподписанный сертификат EST CA (например, NewWithNew) имеет наибольшее значение NotAfter. Если сервер EST не включает сертификаты в отклик, по завершении срока действия сертификата EST CA клиентам EST потребуется повторная инициализация в PKI с начальным распространением сертификатов CA (4.1.1. Распространение сертификатов CA при начальной загрузке), требующим участия пользователя.

После внешней (out-of-band) проверки все остальные сертификаты должны быть проверены с использованием обычной проверки пути [RFC5280] (свежий сертификат CA служит в качестве TA) до их использования при построении путей для проверки сертификатов.

Клиент EST должен сохранить извлечённый сертификат EST CA в базе данных Explicit TA для последующей аутентификации сервера EST. Клиенту EST следует отключить применение записей Implicit TA для этого сервера EST, когда доступна запись Explicit TA. Если клиент отключил базу Implicit TA, а сертификат сервера EST был проверен с использованием записи этой базы, клиент должен включать расширение Trusted CA Indication в будущие сессии TLS [RFC6066]. Это указывает серверу, что теперь приемлем лишь сертификат сервера EST, аутентифицируемый записью базы Explicit TA (иначе сервер EST может продолжить использование сертификата, проверяемого лишь с отключённой базой Implicit TA).

Клиенту EST следует также делать сведения сертификата CA доступными для программ конечного объекта с целью использования при проверке сертификатов партнёра.

4.2. Функции для запроса сертификатов клиентами

Клиенты EST запрашивают сертификат у сервера EST с помощью HTTPS POST, используя значение пути к операции /simpleenroll. Клиенты EST запрашивают обновление или смену ключей имеющихся сертификатов с помощью HTTP POST, используя путь /simplereenroll. Серверы EST должны поддерживать функции /simpleenroll и /simplereenroll.

Клиентам рекомендуется получать текущие сертификаты CA, как описано в параграфе 4.1. Распространение сертификатов CA, до вызова функций запроса сертификатов. Это обеспечивает клиенту возможность проверить сертификат сервера EST. Клиент должен проверить подлинность сервера EST в соответствии с параграфом 3.3.1, если применяется аутентификация по сертификатам, или в соответствии с параграфом 3.3.3 при аутентификации без сертификатов. Клиент должен проверить полномочия сервера в соответствии с параграфом 3.6.

Сервер должен проверять подлинность клиента в соответствии с параграфом 3.3.2 при использовании аутентификации по сертификатам или в соответствии с параграфом 3.3.3, если применяется необязательная аутентификация без сертификатов. Сервер должен проверять полномочия клиента в соответствии с параграфом 3.7. Сервер EST должен проверять значение tls-unique в соответствии с параграфом 3.5, если оно представлено клиентом.

Сервер может воспринять запрос сертификата для проверки администратором вручную (в параграфе 4.2.3 описано использование для таких случаев отклика HTTP 202, передаваемого клиенту EST).

4.2.1. Простое зачисление клиентов

При отправке HTTPS POST для /simpleenroll клиент должен включать Simple PKI Request, как указано в параграфе 3.1 [RFC5272] (т. е. PKCS #10 Certification Request [RFC2986]).

Подпись запроса сертификации (Certification Signing Request или CSR) обеспечивает подтверждение владения секретным ключом клиента серверу EST. Если расширение CSR KeyUsage указывает, что секретный ключ может применяться для создания цифровых подписей, клиент должен создать подпись CSR с использованием этого ключа. Если ключ может служить для создания цифровых подписей, но запрошенное расширение CSR KeyUsage запрещает генерацию цифровых подписей, подпись CSR все равно можно создать с использованием секретного ключа, но ключ недопустимо применять для иных операций с подписью (в соответствии с рекомендациями по подтверждению владения для RA или CA, как описано в [SP-800-57-Part-1]). Использование операций /fullcmc предоставляет доступ к расширенным методам подтверждения владения, которые применяются в случае невозможности использования пары ключей для генерации цифровой подписи (см. 4.3. Полные сообщения CMC).

Здесь применяется тип носителя (content-type) HTTP application/pkcs10. Формат сообщения задан в [RFC5967] с Transfer-Encoding¹ base64 [RFC2045].

Если подлинность клиента EST проверена с ранее установленным сертификатом от стороннего CA (см. 2.2.1. Аутентификация TLS с сертификатом ), клиент может включить в CSR атрибут ChangeSubjectName, как указано в [RFC6402], для запроса смены subjectName и SubjectAltName в новом сертификате.

Клиент EST может запрашивать дополнительные сертификаты даже при использовании имеющегося сертификата при аутентификации клиента TLS. Например, клиент может использовать имеющийся сертификат для аутентификации клиента TLS при запросе сертификата, который не может применяться для проверки подлинности клиента TLS.

4.2.2. Простое перезачисление клиентов

Клиенты EST обновляют сертификаты или их ключи с помощью HTTPS POST, используя путь к операции /simplereenroll.

В запросе сертификата применяется такой же формат, как в запросе simpleenroll с тем же типом носителя HTTP (content-type). Поле Subject в запросе и расширение SubjectAltName должны быть идентичны соответствующим полям в сертификате, который обновляется или меняет ключи. В CSR может быть включён атрибут ChangeSubjectName, определённый в [RFC6402], для запроса смены этих полей в новом сертификате.

Если Subject Public Key Info в запросе сертификации совпадает со значением в текущем сертификате клиента, сервер EST обновляет клиентский сертификат. Если сведения об открытом ключе в запросе сертификации отличаются от данных в текущем сертификате клиента, сервер EST обновляет ключи клиентского сертификата.

4.2.3. Отклик на простое зачисление или перезачисление

Если зачисление успешно, отклик сервера должен содержать код отклика HTTP 200 с типом носителя application/pkcs7-mime.

Откликом об успехе должен быть CMC Simple PKI Response, содержащий только выпущенные сертификаты, как определено в [RFC5272]. Применяется тип носителя HTTP application/pkcs7-mime с параметром smime-type certs-only, как задано в [RFC5273].

При возникновении проблемы сервер должен отвечать кодом ошибки 4xx или 5xx HTTP [RFC2616]. В данные отклика может включаться Simple PKI Response с типом носителя HTTP application/pkcs7-mime (4.3.2. Полный отклик CMC) для передачи отклика об ошибке. Если тип носителя не указан, данные отклика должны содержать понятный человеку текст сообщения об ошибке с объяснением причины отклонения запроса (например, указание неполноты атрибутов CSR). Сервер может использовать тип носителя text/plain [RFC2046] для предназначенных человеку сообщений об ошибках.¹¹

Ответ сервера с кодом HTTP 202 [RFC2616] указывает, что запрос воспринят для обработк, но отклик ещё не доступен. Сервер должен включить заголовок Retry-After, как определено для кода HTTP 503 и может также включить информацию, понятную человеку. Клиент должен ждать по меньшей мере в течение retry-after, прежде чем повторять тот же запрос. Клиент повторяет изначальный запрос на зачисление по истечении времени retry-after. Клиенту следует записывать такие события в журнал или информировать о них конечного пользователя. Сервер отвечает за поддержку всех состояний, требуемых для распознавания и обработки операций повтора, поскольку клиент такие состояния не поддерживает и просто повторяет один запрос, пока не получит другой код отклика. Все остальные коды обрабатываются в соответствии с HTTP [RFC2616].

Если клиент закрывает соединения TLS, ожидая завершения Retry-After, он инициирует новое соединение TLS и выполняет все применимые проверки безопасности. Если клиент уже создал CSR с привязкой отождествления к данным POP (3.5. Связывание отождествления и сведений POP), потребуется создать CSR заново с включением tls-unique из новой, перенаправленной сессии. Отметим, что пару ключей заново создавать не требуется. Обработка и интерфейс нагружают клиента и администраторам серверов EST рекомендуется учитывать это.

Клиент EST может сделать отклик с сертификатом и связанным с ним секретным ключом доступным для использования программами конечного объекта в качестве сертификата конечного объекта.

4.3. Полные сообщения CMC

Клиент EST может запросить сертификат у сервера EST с помощью HTTPS POST с путём к операции /fullcmc. Поддержка функции /fullcmc для клиента и сервера является необязательной.

4.3.1. Полный запрос CMC

Если HTTP POST с /fullcmc не является действительным Full PKI Request, сервер должен отвергнуть сообщение. Используется тип носителя HTTP application/pkcs7-mime с параметром smime-type CMC-request, как указано в [RFC5273]. Телом сообщения является двоичное представление PKI Request с Transfer-Encoding¹² base64 [RFC2045].

4.3.2. Полный отклик CMC

При успешном зачислении отклик сервера должен включать код HTTP 200 с типом носителя application/pkcs7-mime, как указано в [RFC5273]. Данные отклика включают Simple PKI Response с параметром smime-type certs-only или Full PKI Response с smime-type CMC-response, как указано в параграфе 3.2.1 [RFC5751]. Телом сообщения является двоичное представление PKI Response с Transfer-Encoding2 base64 [RFC2045].

При отклонении запроса сервер должен указать код HTTP 4xx или HTTP 5xx. Для любого отклика CMC об ошибке в данные отклика должен быть включён отклик CMC с типом носителя application/pkcs7-mime.

Остальные коды обрабатываются в соответствии с параграфом 4.2.3 или HTTP [RFC2616]. Например, клиент интерпретирует код HTTP 404 или 501, чтобы указать, что эта служба не реализована.

4.4. Генерация ключей на стороне сервера

Клиент EST может запросить секретный ключ и связанный с ним сертификат у сервера EST, используя HTTPS POST с путём к операции /serverkeygen. Поддержка функции /serverkeygen не обязательна.

Клиент должен проверить подлинность сервера EST в соответствии с параграфом 3.3.1, если применяется аутентификация по сертификатам, или в соответствии с параграфом 3.3.3 при аутентификации без сертификатов. Клиент должен проверить полномочия сервера в соответствии с параграфом 3.6.

Сервер должен проверять подлинность клиента в соответствии с параграфом 3.3.2 при использовании аутентификации по сертификатам или в соответствии с параграфом 3.3.3, если применяется необязательная аутентификация без сертификатов. Сервер EST по своему усмотрению применяет проверку полномочий или логику, чтобы определить, следует ли предоставлять секретный ключ и сертификат.

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

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

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

4.4.1. Запрос генерации ключа на стороне сервера

Запрос сертификата делается через HTTPS POST с использованием того же формата, как для расширений пути /simpleenroll и /simplereenroll с таким же типом носителя и транспортным кодированием.

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

Если клиент хочет получить секретный ключ с шифрованием, внешним по отношению к транспорту TLS, применяемому EST, и дополняющим его, или правила требуют доставки ключа в такой форме, клиент должен включить в CSR атрибут, указывающий ключ шифрования. Поддерживается симметричное и асимметричное шифрование, как описано ниже. Клиент должен также включить в CSR атрибут SMIMECapabilities (параграф 2.5 в [RFC2633]) для указания алгоритмов шифрования ключей, которые клиент желает применять.

Клиента настоятельно рекомендуется запрашивать защиту возвращаемого секретного ключа с использованием CMS EnvelopedData в дополнение к предоставляемой TLS защите для предотвращения несанкционированного раскрытия.

4.4.1.1. Запрос симметричного шифрования секретного ключа

Для указания симметричного ключа шифрования созданного сервером секретного ключа клиент должен включить атрибут DecryptKeyIdentifier (параграф 2.2.5 в [RFC4108]), задающий идентификатор секретного ключа, который будет применяться для шифрования. Хотя этот атрибут изначально предназначался для указания секретного ключа из микрокода (firmware), он полностью соответствует требованиям к указанию секретного ключа для шифрования созданного секретного (private) ключа. Если у сервера нет секретного ключа, соответствующего указанному идентификатору, запрос должен прерываться с возвратом клиенту ошибки. Распространение ключа, указанного DecryptKeyIdentifier, генератору ключей выходит за рамки этого документа.

4.4.1.2. Запрос асимметричного шифрования секретного ключа

Для указания асимметричного ключа шифрования созданного сервером секретного ключа клиент должен включить атрибут AsymmetricDecryptKeyIdentifier в форме id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { id-aa 54 }. Значение атрибута asymmetric-decrypt-key-identifier имеет тип ASN.1 AsymmetricDecryptKeyIdentifier ::= OCTET STRING (представление ASN.1 задано в [X.680]). Если у сервера нет секретного ключа, соответствующего указанному идентификатору, запрос должен прерываться с возвратом клиенту ошибки. Распространение ключа, указанного AsymmetricDecryptKeyIdentifier, генератору ключей выходит за рамки этого документа. Если указанный ключ связан с сертификатом X.509, этот ключ должен явно поддерживать keyTransport или keyAgreement или его использование должно быть неограниченным.

4.4.2. Отклик при генерации ключей на стороне сервера

При успешном запросе отклик сервера должен иметь код HTTP 200 с типом носителя multipart/mixed из двух частей — секретный ключ и данные сертификата. Формат возвращаемых данных секретного ключа зависит от секретного ключа, применяемого для дополнительного шифрования (сверх TLS). Если дополнительное шифрование не применяется, данные секретного ключа должны помещаться в application/pkcs8 с кодированием base64 DER-представления [X.690] PrivateKeyInfo с Transfer-Encoding¹³ base64 [RFC2045].

При использовании дополнительного шифрования секретный ключ помещается в CMS SignedData. Данные SignedData подписываются создавшей секретный ключ стороной, которая может быть сервером EST или EST CA. Дополнительная защита SignedData обеспечивается размещением в CMS EnvelopedData, как описано в разделе 4 [RFC5958]. Далее показано использование EncryptedData в зависимости от заданного клиентом типа ключа защиты.

• Если клиент указал ключ симметричного шифрования для защиты созданного сервером секретного ключа, содержимое EnvelopedData шифруется с использованием указанного в запросе ключа. Поле EnvelopedData RecipientInfo должно указывать метод управления ключами шифрования kekri. Для версии указывается значение 4, идентификатор ключа шифрования ключей (kekid) имеет значение DecryptKeyIdentifier из параграфа 4.4.1.1, в keyEncryptionAlgorithm указывается один из алгоритмов переноса ключа (key wrap), которые клиент включил в возможности SMIMECapabilities, сопровождающие запрос, encryptedKey содержит зашифрованный ключ.

• Если клиент указал подходящий для транспортных операций ключ асимметричного шифрования для защиты созданного сервером секретного ключа, содержимое EnvelopedData шифруется с использованием сгенерированного случайного симметричного ключа. Для ключа симметричного шифрования следует обеспечивать криптостойкость, эквивалентную стойкости указанного клиентом асимметричного ключа. Поле EnvelopedData RecipientInfo должно указывать метод управления ключами шифрования KeyTransRecipientInfo (ktri). В KeyTransRecipientInfo поле RecipientIdentifier (rid) содержит значение subjectKeyIdentifier, копируемое из атрибута, определённого в параграфе 4.4.1.2, или сервер определяет связанное значение issuerAndSerialNumber из атрибута, версия выводится из выбора rid [RFC5652], в keyEncryptionAlgorithm указывается один из алгоритмов переноса ключей (key wrap), указанных клиентом в возможностях SMIMECapabilities, сопровождающих запрос, encryptedKey содержит ключ шифрования.

• Если клиент указал подходящий для операций согласования ключей ключ асимметричного шифрования для защиты созданного сервером секретного ключа, содержимое EnvelopedData шифруется с использованием сгенерированного случайного симметричного ключа. Для ключа симметричного шифрования следует обеспечивать криптостойкость, эквивалентную стойкости указанного клиентом асимметричного ключа. Поле EnvelopedData RecipientInfo должно указывать метод управления ключами шифрования KeyAgreeRecipientInfo (kari). В KeyAgreeRecipientInfo тип, версия, источник и ключевой материал пользователя (ukm) такие же как в [RFC5652], в keyEncryptionAlgorithm указывается один из алгоритмов переноса ключа (key wrap), включённых клиентом в возможности SMIMECapabilities, сопровождающие запрос. Идентификатор ключа получателя копируется из атрибута, определённого в параграфе 4.4.1.2, в subjectKeyIdentifier или сервер определяет IssuerAndSerialNumber в соответствии со значением, представленным в атрибуте.

Во всех трёх вариантах дополнительного шифрования EnvelopedData возвращается в отклике как application/pkcs7-mime с параметром smime-type server-generated-key и Transfer-Encoding base64.

Данные сертификата передаются в application/pkcs7-mime и точно соответствуют отклику с сертификатом для /simpleenroll.

Когда запрос отвергается, сервер должен указать ошибку HTTP 4xx или HTTP 5xx. Если тип носителя не задан, данные отклика должны быть понятным человеку текстом сообщения об ошибке.¹⁴

4.5. Атрибуты CSR

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

Серверу EST не следует требовать проверки подлинности или полномочий клиента для ответа на этот запрос.

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

4.5.1. Запрос атрибутов CSR

Клиент EST запрашивает у CA список желаемых атрибутов CSR, передавая серверу EST сообщение HTTPS GET с путём к операции /csrattrs.

4.5.2. Отклик с атрибутами CSR

Если заданные локально правила для аутентифицированного клиента EST указывают предоставление CSR Attributes Response, отклик сервера должен включать код HTTP 200. Код HTTP 204 или 404 говорит о недоступности CSR Attributes Response. Независимо от кода отклика сервер EST и CA могут отклонять любые последующие запросы на зачисление по любой причине, например, из-за неполноты атрибутов CSR в запросе.

Отклики на запросы атрибутов должны представляться с типом носителя application/csrattrs и Transfer-Encoding¹⁵ base64 [RFC2045]. Синтаксис тела application/csrattrs показан ниже.

AttrOrOID ::= CHOICE {
      oid OBJECT IDENTIFIER, 
      attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet}
}16

Сервер EST может включать OID или атрибуты [RFC2986], включения которых в запрос сертификации он требует от клиента. Клиент должен игнорировать любые неизвестные OID и атрибуты. Когда сервер кодирует атрибуты CSR в форме пустой последовательности (SEQUENCE), это означает отсутствие у сервера конкретных сведений, которые он желает видеть в запросе клиента (эта функциональность эквивалентна коду отклика HTTP 204 или 404).

Если CA требуется определённая криптосистема или использование определённой схемы подписи (например, сертификация открытого ключа на основе некой эллиптической кривой или подпись с использованием определённого хэш-алгоритма), он должен предоставить сведения об этом в CSR Attribute Response. Если серверу EST требуется привязка отождествления к сведениям POP (3.5. Связывание отождествления и сведений POP), он должен включить challengePassword OID в CSR Attributes Response.

Структуре CSR Attributes Response следует максимально отражать структуру CSR в запросе. Запросы на использование определённой схемы подписи (например, конкретной хэш-функции) представляются как OID для отражения в SignatureAlgorithm структуры CSR. Запросы на использование определённой криптосистемы (например, сертификация открытого ключа на основе некой эллиптической кривой) представляются как атрибут для отражения в AlgorithmIdentifier структуры SubjectPublicKeyInfo с типом, указывающим алгоритм, и значениями с конкретными параметрами этого алгоритма. Запросы информативных сведений от клиента выполняются с помощью атрибута, который представляется как атрибуты CSR с типом, указывающим extensionRequest [RFC2985], и значениями, задающими конкретные атрибуты, которые желательно включить в расширения результирующего сертификата.

Последовательность — это собой DER¹⁷-представление [X.690] с кодированием base64 (раздел 4 в [RFC4648]). Полученный в результате текст формирует тело application/csrattr без заголовков. Например, если CA хочет от клиента запрос на сертификацию, содержащий challengePassword (указывает запрос привязки отождествления к сведениям POP, см. параграф 3.5), extensionRequest [RFC2307] с MAC¹⁸-адресом клиента, применение эллиптической кривой secp384r1 и подписи с хэш-функцией SHA384, это может иметь вид

         OID:        challengePassword (1.2.840.113549.1.9.7)
         Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                     value = macAddress (1.3.6.1.1.1.1.22)
         Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                     value = secp384r1 (1.3.132.0.34)
         OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)

Кодирование в ASN.1 SEQUENCE даёт

       30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
       02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
       09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
       03

Последующее кодирование base64 представляет ASN.1 SEQUENCE в форме

       MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
       BgcrBgEBAQEWBggqhkjOPQQDAw==

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

В параграфе 4.4.1.2 дано определение OID, зарегистрированного в arc, делегированном IANA рабочей группе PKIX. Агентство IANA обновило реестр общеизвестных URI в соответствии с шаблоном из [RFC5785].

      URI suffix: est
      Change controller: IETF

Агентство IANA обновило реестр Application Media Types в соответствии с шаблоном из [RFC6838]. Субтип носителя для атрибутов CSR в CSR Attributes Response указывается в форме application/csrattrs.

       Type name: application
       Subtype name: csrattrs
       Required parameters: None
       Optional parameters: None
       Encoding considerations: binary;
       Security Considerations:
         Clients request a list of attributes that servers wish to be in
         certification requests.  The request/response is normally done
         in a TLS-protected tunnel.
       Interoperability considerations: None
       Published specification: This memo.
       Applications which use this media type: Enrollment over Secure
       Transport (EST)
       Additional information:
         Magic number(s): None
         File extension: .csrattrs
       Person & email address to contact for further information:
         Dan Harkins <dharkins@arubanetworks.com>
       Restrictions on usage: None
       Author: Dan Harkins <dharkins@arubanetworks.com>
       Intended usage: COMMON
       Change controller: The IESG <iesg@ietf.org>

Тип носителя application/pkcs7-mime задаёт необязательный параметр smime-type [RFC5751] с набором конкретных значений. Этот документ добавляет server-generated-key как значение параметра для Server-side Key Generation Response.

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

Поддержка аутентификации Basic, как задано в HTTP [RFC2617], разрешает серверу доступ к паролю клиента в открытом виде (cleartext). Это обеспечивает поддержку унаследованных баз «имя-пароль», но раскрывает пароли серверу EST. Применение PIN или одноразовых паролей позволяет смягчить последствия такого раскрытия и клиентам EST рекомендуется применять такие свидетельства лишь один раз для получения сертификата клиента (который будет применяться при последующем взаимодействии с сервером EST).

При использовании клиентом базы Implicit TA для проверки сертификата (3. Устройство и уровни протокола) проверка полномочий выполняется в соответствии с параграфом 3.6.2. В такой ситуации клиент подтверждает, что сервер является ответчиком, сертифицированным третьей стороной, но невозможно проверить полномочия ответчика выступать в качестве RA для PKI, куда клиент пытается зачислиться. Клиентам, использующим базу Implicit TA рекомендуется применять только основанную на TLS аутентификацию клиента (для предотвращения раскрытия сведения при аутентификации клиента на основе HTTP). Таким клиентам рекомендуется включать в запросы привязку отождествления к сведениям POP (3.5. Связывание отождествления и сведений POP), чтобы такие запросы не пересылались реальному серверу EST злоумышленником MITM¹⁹. Рекомендуется тщательно контролировать базу данных Implicit TA, применяемую для аутентификации сервера EST, чтобы снизить шансы стороннего CA со слабой практикой сертификации стать доверенным. Отключение базы Implicit TA после успешного получения отклика с распространением сертификатов CA (4.1.3. Отклик с сертификатами CA) снижает уязвимость первого обмена TLS.

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

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

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

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

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

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

Шифры TLS, имена которых включают _EXPORT_ или _DES_, применять недопустимо. Такие шифры не обеспечивают достаточного уровня защиты — 40-битовая криптография в 2013 г. уже не обеспечивала приемлемой защиты, а алгоритм DES сочтён устаревшим.

Как описано в параграфе 6.7 CMC [RFC5272]: «Для ключей, которые могут служить ключами подписи, подписывание запроса сертификата с помощью секретного ключа служит подтверждением владения (POP) парой ключей». Включение tls-unique в запрос сертификации связывает POP с подтверждением отождествления TLS, обеспечивая выполнение операции POP в активной сессии TLS. Для сервера это означает, что аутентифицированный клиент имеет доступ к секретному ключу. Если известно, что аутентифицированный клиент обладает определёнными возможностями, такими как аппаратная защита свидетельств (credential) аутентификации и хранения ключей, это усиливает допущение, но не служит доказательством.

Метод генерации ключей на стороне сервера позволяет доставлять ключи клиенту через соединение TLS без защиты на прикладном уровне. Распространение материала секретных ключей по своей природе связано с риском. При распространении секретных ключей используется согласованный для TLS шифр. Ключи не защищаются предпочтительным методом упаковки ключей, таким как AES Key Wrap [RFC3394], или как указано в [RFC5958], поскольку шифрование секретного ключа в дополнение к обеспечиваемому транспортом TLS является необязательным. Серверам EST рекомендуется не поддерживать эту операцию по умолчанию. Клиентам рекомендуется не запрашивать эту услугу, пока нет убедительных операционных преимуществ. Применение базы Implicit TA не рекомендуется при генерации ключей на стороне сервера. Рекомендуется использовать CMS Server-Side Key Generation Response.

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

Правила кодирования ASN.1 (например, DER и BER) имеют структуру TLV²⁰ и легко создать вредоносное содержимое с некорректным полем размера, что может приводить к переполнению буфера. Правила кодирования ASN.1 разрешают произвольную глубину вложенности, что позволяет создавать вредоносное содержимое для переполнения стека. Интерпретаторам структур ASN.1 следует учитывать указанные проблемы и принимать соответствующие меры для защиты от переполнения буфера и стека, а также вредоносного содержимого в целом.

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

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

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2585] Housley, R. and P. Hoffman, «Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP», RFC 2585, May 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication», RFC 2617, June 1999.

[RFC2633] Ramsdell, B., «S/MIME Version 3 Message Specification», RFC 2633, June 1999.

[RFC2986] Nystrom, M. and B. Kaliski, «PKCS #10: Certification Request Syntax Specification Version 1.7», RFC 2986, November 2000.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[RFC4108] Housley, R., «Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages», RFC 4108, August 2005.

[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, «Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)», RFC 4210, September 2005.

[RFC4346] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1», RFC 4346, April 2006.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, «Transport Layer Security (TLS) Session Resumption without Server-Side State», RFC 5077, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5272] Schaad, J. and M. Myers, «Certificate Management over CMS (CMC)», RFC 5272, June 2008.

[RFC5273] Schaad, J. and M. Myers, «Certificate Management over CMS (CMC): Transport Protocols», RFC 5273, June 2008.

[RFC5274] Schaad, J. and M. Myers, «Certificate Management Messages over CMS (CMC): Compliance Requirements», RFC 5274, June 2008.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC5652] Housley, R., «Cryptographic Message Syntax (CMS)», STD 70, RFC 5652, September 2009.

[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, «Transport Layer Security (TLS) Renegotiation Indication Extension», RFC 5746, February 2010.

[RFC5751] Ramsdell, B. and S. Turner, «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification», RFC 5751, January 2010.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, «Defining Well-Known Uniform Resource Identifiers (URIs)», RFC 5785, April 2010.

[RFC5929] Altman, J., Williams, N., and L. Zhu, «Channel Bindings for TLS», RFC 5929, July 2010.

[RFC5958] Turner, S., «Asymmetric Key Packages», RFC 5958, August 2010.

[RFC6066] Eastlake, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011.

[RFC6125] Saint-Andre, P. and J. Hodges, «Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)», RFC 6125, March 2011.

[RFC6402] Schaad, J., «Certificate Management over CMS (CMC) Updates», RFC 6402, November 2011.

[RFC6454] Barth, A., «The Web Origin Concept», RFC 6454, December 2011.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, January 2013.

[X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, «Abstract Syntax Notation One (ASN.1): Specification of basic notation», November 2008, <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.

[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, «ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)», November 2008, <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.

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

[IDevID] IEEE Standards Association, «IEEE 802.1AR Secure Device Identifier», December 2009, <http://standards.ieee.org/findstds/standard/802.1AR-2009.html>.

[RFC2307] Howard, L., «An Approach for Using LDAP as a Network Information Service», RFC 2307, March 1998.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[RFC2985] Nystrom, M. and B. Kaliski, «PKCS #9: Selected Object Classes and Attribute Types Version 2.0», RFC 2985, November 2000.

[RFC3394] Schaad, J. and R. Housley, «Advanced Encryption Standard (AES) Key Wrap Algorithm», RFC 3394, September 2002.

[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, «Using the Secure Remote Password (SRP) Protocol for TLS Authentication», RFC 5054, November 2007.

[RFC5967] Turner, S., «The application/pkcs10 Media Type», RFC 5967, August 2010.

[RFC6403] Zieglar, L., Turner, S., and M. Peck, «Suite B Profile of Certificate Management over CMS», RFC 6403, November 2011.

[SHS] National Institute of Standards and Technology, «Secure Hash Standard (SHS)», Federal Information Processing Standard Publication 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.

[SP-800-57-Part-1] National Institute of Standards and Technology, «Recommendation for Key Management — Part 1: General (Revision 3)», July 2012, <http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.

Приложение A. Примеры сообщений (ненормативные)

В этом приложении рассмотрены варианты применения с подробным описанием сообщений на каждом уровне TLS.

A.1. Получение сертификатов CA

Ниже представлен пример действительного обмена /cacerts. В процессе начального согласования TLS клиент может игнорировать необязательный «запрос сертификата», созданный сервером, и обрабатывать вместо этого запрос HTTP GET.

   GET /.well-known/est/cacerts HTTP/1.1
   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
   Host: 192.0.2.1:8085
   Accept: */*

В ответ сервер передаёт текущие сертификаты CA.

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Transfer-Encoding21: base64
   Content-Length: 4246

   MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
   +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
   EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
   WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
   AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
   HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
   K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
   EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
   3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
   9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
   Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
   Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
   uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
   KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
   X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
   KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
   x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
   MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
   bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
   VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
   CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
   loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
   9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
   btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
   CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
   lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
   HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
   oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
   q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
   zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
   sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
   R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
   GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
   XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
   c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
   GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
   ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
   2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
   4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
   EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
   7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
   pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
   BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
   gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
   BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
   2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
   iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
   cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
   DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
   c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
   ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
   DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
   DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
   Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
   Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
   SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
   PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
   NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
   AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
   arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
   GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
   9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
   VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
   OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
   NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
   jM0MAGNDEW+1oQAxAA==

A.2. Атрибуты CSR

Ниже приведён пример действительного обмена /csrattrs. При таком обмене клиент EST аутентифицирует себя с применением имеющегося сертификата, выпущенного CA, которому сервер EST предоставляет услуги. Исходное согласование идентично представленному в примере исходного зачисления. Запрос HTTP GET имеет вид

   GET /.well-known/est/csrattrs HTTP/1.1
   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
   Host: 192.0.2.1:8085
   Accept: */*

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

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/csrattrs
   Transfer-Encoding22: base64
   Content-Length: 171

   MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
   CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
   OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC

A.3. Зачисление и повторное зачисление

В следующем примере показан обмен /simpleenroll. Сообщения с данными для /simplereenroll аналогичны. В процессе обмена клиент EST использует распространённые по отдельному каналу (out-of-band) имя пользователя и пароль для аутентификации себя на сервере EST. Это обычно поведение HTTP WWW-Authenticate, включённое здесь для информации. При использовании имеющегося сертификата клиента TLS сервер может не запрашивать заголовок HTTP WWW-Authenticate, например, в операции /simplereenroll.

При начальном согласовании TLS клиент может игнорировать необязательный «запрос сертификата», созданный сервером, и обрабатывать вместо этого запрос HTTP POST. В отклике на исходную попытку HTTP POST сервер запрашивает у клиента WWW-Authenticate (это возможно даже при использовании клиентом сертификата, как указано в нормативном тексте выше).

   HTTP/1.1 401 Unauthorized
   Content-Length: 0
   WWW-Authenticate: Digest qop="auth", realm="estrealm",
   nonce="1368141352"

В последующий запрос HTTP POST включается имя пользователя и пароль вместе с полным содержимым application/pkcs10.

   POST /.well-known/est/simpleenroll HTTP/1.1
   Authorization: Digest username="estuser", realm="estrealm", nonc
   e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
   TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
   b16db20f75f22"
   Host: 192.0.2.1:8085
   Accept: */*
   Content-Type: application/pkcs10
   Transfer-Encoding1: base64
   Content-Length: 882

   MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
   MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
   eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
   XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
   MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
   hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
   tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
   AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
   AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
   wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
   VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
   5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
   cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
   PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==

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

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime; smime-type=certs-only
   Transfer-Encoding1: base64
   Content-Length: 1122

   MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
   BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
   cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
   A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
   DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
   ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
   Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
   6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
   J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
   rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
   AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
   scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
   a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
   4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
   o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
   QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
   rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
   R4POrT2xz8ChADEA

A.4. Генерация ключа сервером

Следующий пример представляет действительный обмен /serverkeygen, в котором клиент EST аутентифицирует себя, используя имеющийся сертификат, выданный CA, которому сервер EST предоставляет услуги. Исходное согласование идентично приведённому в примере зачисления. HTTP POST имеет вид

   POST /.well-known/est/serverkeygen HTTP/1.1
   Host: 192.0.2.1:8085
   Accept: */*
   Expect: 100-continue
   Content-Type: application/pkcs10
   Transfer-Encoding23: base64
   Content-Length: 963

   MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
   bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
   ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
   3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
   RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
   sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
   4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
   5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
   ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
   cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
   L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
   GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
   gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
   veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
   M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==

Поскольку атрибут DecryptKeyIdentifier не включён в этот запрос, отклик не содержит дополнительного шифрования сверх TLS. Отклик сервера EST имеет вид

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
   Content-Length: 3219

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

   --estServerExampleBoundary
   Content-Type: application/pkcs8
   Content-Transfer-Encoding: base64

   MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
   Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
   F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
   rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
   IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
   Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
   FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
   KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
   BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
   JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
   IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
   GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
   p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
   SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
   fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
   srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
   BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
   RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
   vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
   eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
   wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
   Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
   zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
   4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
   fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
   pM7PYH/x4BiBmgQ3bhOqTp4H
   --estServerExampleBoundary
   Content-Type: application/pkcs7-mime; smime-type=certs-only
   Content-Transfer-Encoding: base64

   MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID
   FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
   cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG
   A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq
   hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y
   VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD
   t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8
   mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ
   9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw
   To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw
   UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4
   MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA
   A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj
   rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe
   XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa
   E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m
   s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC
   1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA==
   --estServerExampleBoundary--

Это эпилог, который также игнорируется.

Приложение B. Участники работы и благодарности

Редакторы документа благодарны Stephen Kent, Vinod Arjun, Jan Vilhuber, Sean Turner, Russ Housley и другим за их отклики и прототипы ранних версий документа. Спасибо авторам [RFC6403], на основе которого была создана эта спецификация.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          J. Abley
Request for Comments: 7043                                     Dyn, Inc.
Category: Informational                                     October 2013
ISSN: 2070-1721

Записи RR в DNS для адресов EUI-48 и EUI-64

Resource Records for EUI-48 and EUI-64 Addresses in the DNS

PDF

Аннотация

48-битовые идентификаторы EUI¹-48 и 64-битовые EUI-64 представляют собой форматы адресов, заданных IEEE для использования в различных сетях L2, например, Ethernet.

В этом документе описаны два новых типа записей о ресурсах DNS — EUI48 и EUI64, служащие для представления адресов Ethernet в DNS.

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

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

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

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

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

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

Авторские права (Copyright (c) 2013) принадлежат 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]. Эти базовые спецификации определяют множество типов записей о ресурсах (RR⁵), а в последующих документах определены дополнительные типы. Каждый определенный тип RR обеспечивает способ представления в DNS неких конкретных данных.

Расширенные уникальные идентификаторы EUI-48 [EUI48] и EUI-64 [EUI64] представляют собой форматы адресов, заданные IEEE для использования в разных сетях L2, например Ethernet.

В этом документе определены два новых типа RR — EUI48 и EUI64, используемые для представления адресов EUI-48 и EUI-64 в DNS.

Возможны потенциально важные последствия для конфиденциальности (приватности) в результате неразборчивой публикации адресов канального уровня в DNS (раздел 8). В соответствии с этим документом адреса EUI-48 и EUI-64 не следует публиковать в DNS общего пользования. Документ задает функционально совместимое кодирование этих типов адресов для использования в пространствах имен частных DNS, где проблемы конфиденциальности могут быть ограничены и смягчены.

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

В этом документе слова типа должен и может для описания требований к использованию зарегистрированных типов RR выделены шрифтом. Значение этих слов в данном документе совпадает с описанным в [RFC2119]. Хотя такое выделение обычно используется при задании нормативных требований в стандартах IETF, их использование в данном документе не предполагает, что документ задает какой-либо стандарт.

3. EUI48 RR

Запись о ресурсах EUI48 используется для хранения одного адреса EUI-48 в DNS.

Поле Type для EUI48 RR имеет значение 108 (десятичное).

Запись EUI48 RR не зависит от класса.

EUI48 RR не имеет специальных требований к сроку действия (TTL⁶).

3.1. Формат передачи EUI48 RDATA

RDATA для EUI48 RR состоит из одного 6-октетного поля Address, кодируемого с сетевым (big-endian) порядком.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          EUI-48 Address                       |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2. Формат представления EUI48 RR

Поле Address должно представляться в форме 6 двухзначных шестнадцатеричных чисел, разделенных символами дефиса (hyphen). Шестнадцатеричные цифры от A до F можно указывать в любом регистре.

3.3. Пример

Приведенная ниже EUI48 RR содержит индивидуальный адрес EUI-48 со значением 00-00-5e-00-53-2a.

     host.example. 86400 IN EUI48 00-00-5e-00-53-2a

4. EUI64 RR

Запись о ресурсах EUI64 используется для хранения одного адреса EUI-64 в DNS.

Поле Type для EUI64 RR имеет значение 109 (десятичное).

Запись EUI64 RR не зависит от класса.

EUI64 RR не имеет специальных требований TTL.

4.1. Формат передачи EUI64 RDATA

RDATA для EUI64 RR состоит из одного 8-октетного поля Address, кодируемого с сетевым (big-endian) порядком.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          EUI-64 Address                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. Формат представления EUI64 RR

Поле Address должно представляться в форме 8 двухзначных шестнадцатеричных чисел, разделенных символами дефиса (hyphen). Шестнадцатеричные цифры от A до F можно указывать в любом регистре.

4.3. Пример

Приведенная ниже EUI64 RR содержит индивидуальный адрес EUI-64 со значением 00-00-5e-ef-10-00-00-2a.

     host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a

5. Пример использования — отслеживание адреса IP в сети DOCSIS

Пользователи канадских кабельных сетей Internet получают адреса IP от сервера DHCP, обеспечиваемого кабельной компанией. В случаях когда кабельная компания обеспечивает соединения «последней мили» от имени другой компании (реселлера), сервер DHCP выдает адреса из пула, предоставленного реселлером. Реселлер имеет информацию об адресах EUI-48 модемов DOCSIS, предоставленных пользователям, но не имеет информации о выделенных им адресах IP. Для того, чтобы реселлер мог отображать выделенные пользователям адреса IP на адреса EUI-48 (и следовательно, отождествление абонентов), кабельная компания может предоставлять информацию от сервера DHCP, которая указывает отображение (EUI-48, IP).

Канадские кабельные компании должны [NTRE038D] делать это отображение адресов доступным через DNS. Зоны, содержащие соответствующую информацию, публикуются на серверах DNS, доступ к которым разрешен лишь реселлерам, соответствующим конкретным множествам абонентов. Информация об адресах абонентов не публикуется а общедоступных DNS.

Имеющиеся схемы DNS для представления отображений (EUI-48, IP), используемых канадскими кабельными компаниями, разнообразны и неэффективны. В отсутствие типа RR для прямого кодирования адресов EUI-48 адреса разными способами кодируются в имена владельцев и публикуются в записях TXT.

Представленная в этом документе спецификация облегчает более эффективное, согласованное и надежное представление отображений (EUI-48, IP) по сравнению со всеми, доступными ранее.

6. Протокол DNS

Спецификация новых типов RR в этом документе не оказывает влияния на преобразование адресов в каких-либо имеющихся сетевых процессах или протоколах. Предложения или спецификации для изменения или дополнения процессов или протоколов преобразования адресов с помощью этих типов RR должны включать обнаружение и обслуживание всех адресных конфликтов или обработку использования множества EUI48/EUI64 RR.

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

Агентство IANA выделило тип RR со значением 108 (десятичное) для EUI48 и со значением 109 (десятичное) для EUI64. Соответствующие записи в субреестре Resource Record (RR) TYPEs (http://www.iana.org/assignments/dns-parameters/) содержат приведенные ниже данные.

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

Существуют проблемы приватности при публикации адресов канального уровня в DNS. Адреса EUI-48 и EUI-64со сброшенным (0) битом Local/Global [RFC7042] (в [RFC4291] этот бит называется universal/local) предназначены для представления уникальных идентификаторов подключенного к сети оборудования, несмотря на неоднократно отмеченные случаи дублирования в результате ошибок производителей, неправомерного использования идентификаторов OUI⁷ и подмены адресов при настройке сетевых интерфейсов. Публикация адресов EUI-48 или EUI-64 в DNS может вызывать проблемы приватности за счет появления уникальных отслеживаемых идентификаторов, которые в некоторых случаях могут быть постоянными.

Хотя адреса IP и имена DNS для сетевых устройств обычно меняются с течением времени, адреса EUI-48 и EUI-64 на тех же устройствах обычно более стабильны (во многих случаях просто неизменны). Публикация адресов EUI-48, связанных с пользовательскими устройствами, с возможностью сопоставить эти адреса с назначенными адресами IP позволит отслеживать поведение этих пользователей посторонними лицами независимо от места и способа подключения пользователя к Internet. Это может приводить к потере конфиденциальности (приватности) пользователя.

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

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

В соответствии с рекомендациями этого документа адреса EUI-48 и EUI-64 не следует публиковать в DNS общего пользования.

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

Автор благодарит участников работы — Olafur Gudmundsson, Mark Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake III, Randy Bush, John Klensin.

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

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

[EUI48] IEEE, «Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48)», <http://standards.ieee.org/develop/regauth/tut/eui48.pdf>.

[EUI64] IEEE, «Guidelines for 64-bit Global Identifier (EUI-64)», November 2012, <http://standards.ieee.org/develop/regauth/tut/eui64.pdf>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC7042] Eastlake 3rd, D. and J. Abley, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 7042, October 2013.

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

[NTRE038D] CRTC Interconnection Steering Committee (CISC) Network Working Group, «Implementation of IP Address Tracking in DOCSIS Networks (TIF18)», NTRE038D Consensus Report, October 2006, <http://www.crtc.gc.ca/public/cisc/nt/NTRE038D.doc>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

Адрес автора

Joe Abley

Dyn, Inc.

470 Moore Street

London, ON N6C 2C2

Canada

Phone: +1 519 670 9327

EMail: jabley@dyn.com

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 7042                                        Huawei
BCP: 141                                                        J. Abley
Obsoletes: 5342                                                Dyn, Inc.
Updates: 2153                                               October 2013
Category: Best Current Practice
ISSN: 2070-1721

Регистрация в IANA и использование в протоколах и документации IETF параметров IEEE 802

IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

PDF

Аннотация

Некоторые протоколы IETF используют форматы кадров Ethernet и параметры IEEE 802. В этом документе рассматривается использование таких параметров в протоколах IETF, описано выделение агентством IANA значений IANA OUI¹ и приведены некоторые значения для использования в документации. Данный документ заменяет RFC 5342.

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

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

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

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

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

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

Некоторые протоколы IETF используют Ethernet и другие, связанные с IEEE 802 форматы кадров и параметры [IEEE802]. К ним относятся идентификаторы MAC⁴ и протоколов.

В этом документе рассмотрены вопросы распределения агентством IANA кодов под эгидой IANA OUI. Рассмотрены также некоторые другие применения в IETF кодов IEEE 802 и представлен ряд значений для использования в документации. Как отмечено в [RFC2606] и [RFC5737], использование резервных кодов для документации и примеров снижает вероятность конфликтов и путаницы по причине дублирования кодов, предназначенных для развертывания.

Документ [RFC5226] включен в данный документ за исключением случаев возникновения явных противоречий. В этом документе используется термин «Ратификация IESG» (IESG Ratification), описанный в параграфе 5.1. Эта процедура отличается от «Одобрения IESG» (IESG Approval) в [RFC5226].

1.1. Используемые обозначения

В документе используются 16-ричные обозначения. Каждый октет (8-битовый байт) представляется двумя шестнадцатеричными цифрами, задающими октет как целое число без знака. Последовательные октеты разделяются символами дефиса. С документ используется принятый IETF порядок битов, хотя в физических средах IEEE [802.3] используется порядок передачи битов октета от младшего к старшему (т. е. обратный принятому в IETF порядку).

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

   AFN    Address Family Number [RFC4760] - номер семейства адресов.
   EUI    Extended Unique Identifier - расширенный уникальный идентификатор.
   IAB    Individual Address Block - индивидуальный адресный блок.
   MAC    Media Access Control - управление доступом к среде.
   OUI    Organizationally Unique Identifier - уникальный идентификатор организации.
   RRTYPE Тип записи DNS о ресурсе [RFC6895].
   **     Возведение в степень. Например, 2**24 означает 2 в степени 24.

1.2. Отличия от RFC 5342

• Добавлены MAC-адреса и протокол на базе IANA OUI, а также другие значения для использования в документации и язык написания разделов Security Considerations (вопросы безопасности).

• Исключены все требования для параллельного выделения значений для индивидуальной (unicast) и групповой (multicast) адресации без запроса. Такие требования были включены в [RFC5342] для упрощения учета в IANA, но практика показала их неудобство.

• Пересмотрен информационный материал о правилах выделения значений IEEE с учетом [RAC-OUI].

• Добавлены AFN и RRTYPE для 48- и 64-битовых MAC.

1.3. IEEE Registration Authority

Изначально регистрация параметров Ethernet обеспечивалась Xerox Corporation, а в настоящее время это делает IEEE Registration Authority и параметры доступны на web-странице http://standards.ieee.org/regauth/

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

Списки некоторых значений и их держателей можно загрузить с сайта IEEE Registration Authority.

1.4. IANA OUI

Агентству IANA выделен идентификатор OUI 00-00-5E.

В настоящее время нет выделено OUI для документации, но ниже приведены коды для документации под эгидой IANA OUI.

2. Идентификационные параметры Ethernet

В параграфе 2.1 рассмотрены MAC-идентификаторы EUI-48⁵, их связь с OUI и другими префиксами, а также назначение под эгидой IANA OUI. В параграфе 2.2 описано то же самое для идентификаторов EUI-64. В параграфе 2.3 рассматриваются другие идентификаторы IETF MAC, используемые под эгидой IANA OUI.

В [RAC-OUI] отмечено, что комитет IEEE Registration Authority изучает возможность определения нового идентификатора EUI-128.

2.1. 48-битовые идентификаторы MAC, OUI и другие префиксы

48-битовые MAC-адреса чаще всего используются в качестве идентификаторов интерфейсов Ethernet. Уникальные в глобальном масштабе идентификаторы этого типа называют также EUI-48. Идентификатор EUI-48 делится на трехоктетный идентификатор OUI и дополнительные 3 октета, выделяемые держателем OUI, но может использоваться более длинный префикс организации за счет сокращения числа дополнительных битов, чтобы общий размер идентификатора составлял 48 битов. Например, IEEE выделял блоки IAB⁶, где первые 36 битов связаны с держателем IAB, который самостоятельно контролирует оставшиеся 12 битов. Однако идентификаторы IAB становятся достоянием истории, а более длинные префиксы будут доступны в [RAC-OUI].

Процедуры и правила IEEE для выделения значений идентификаторов, связанных с IEEE 802, описаны в документе [802_O&A], который время от времени пересматривается.

Два бита первого октета EUI-48 имеют в MAC-адресах специальное значение — Group (01) и Local (02). OUI и более длинные префиксы MAC назначаются с нулевым значением бита Local и не заданным значением бита Group. Групповые идентификаторы могут создаваться путем установки бита Group, а индивидуальные — путем его сброса (0).

Бит Local имеет значение 0 для уникальных в глобальном масштабе идентификаторов EUI-48, назначаемых держателем OUI или владельцем более длинного префикса. Если бит Local установлен (1), идентификатор считается в IEEE 802 локальным и находящимся под контролем местного сетевого администратора, однако могут быть выпущены рекомендации IEEE Registration Authority по управлению пространством локальных адресов. Если бит Local установлен, держатель OUI не имеет каких-либо особых полномочий применительно к первым 3 октетам идентификаторов MAC, соответствующим его OUI.

Для 48-битовых MAC-адресов выделены AFN и DNS RRTYPE (параграф 5.2).

2.1.1. Назначение EUI-48 под эгидой IANA OUI

Значение OUI 00-00-5E было выделено агентству IANA, как отмечено в параграфе 1.4. Это позволяет задать 2²⁴ групповых идентификаторов EUI-48 от 01-00-5E-00-00-00 до 01-00-5E-FF-FF-FF и 2²⁴ индивидуальных EUI-48 от 00-00-5E-00-00-00 до 00-00-5E-FF-FF-FF.

Из числа этих идентификаторов EUI-48 выделены блоки, в которых агентство IANA выделило идентификаторы для документации.

Блоки по 2⁸ индивидуальных адресов

00-00-5E-00-00-00 — 00-00-5E-00-00-FF

резерв с выделением по процедуре IESG Ratification (параграф 5.1).

00-00-5E-00-01-00 — 00-00-5E-00-01-FF

выделены для протокола VRRP⁷ [RFC5798].

00-00-5E-00-02-00 — 00-00-5E-00-02-FF

выделены для протокола IPv6 VRRP [RFC5798].

00-00-5E-00-52-00 — 00-00-5E-00-52-FF

используются для очень мелких назначений (уже распределены 3 из 256 значений).

00-00-5E-00-53-00 — 00-00-5E-00-53-FF

выделены для использования в документации.

Групповые идентификаторы

01-00-5E-00-00-00 — 01-00-5E-7F-FF-FF

2²³ для групповой адресации IPv4 [RFC1112].

01-00-5E-80-00-00 — 01-00-5E-8F-FF-FF

2²⁰ для групповой адресации MPLS [RFC5332].

01-00-5E-90-00-00 — 01-00-5E-90-00-FF

2⁸ адресов используются для очень мелких назначений (уже распределены 4 из 256 значений).

01-00-5E-90-10-00 — 01-00-5E-90-10-FF

2⁸ адресов для документации.

Более подробную и актуальную информацию можно найти в реестре Ethernet Numbers на сайте http://www.iana.org.

2.1.2. EUI-48 для документации

Приведенные ниже блоки идентификаторов выделены для использования в документации

00-00-5E-00-53-00 - 00-00-5E-00-53-FF для индивидуальных адресов;
01-00-5E-90-10-00 - 01-00-5E-90-10-FF для групповых адресов.

2.1.3. Вопросы назначения EUI-48 в IANA

Назначение идентификаторов EUI-48 под эгидой имеющегося или будущих IANA OUI (параграф 5.4) должно удовлетворять всем приведенным ниже требованиям.

• Блок должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Блок должен иметь размер, равный степени 2, начиная с границы, равной или превышающей степень 2, включая выделение одного (2⁰) идентификатора.

• Недопустимо использование для обхода требований к производителям получать собственные блоки идентификаторов от IEEE.

• Блок должен быть документирован в Internet-Draft или RFC.

Кроме того, должны выполняться приведенные ниже правила (описание процедур дано в параграфе 5.1):

мелкие и средние блоки идентификаторов EUI-48 размером 1, 2, 4, …, 32768, 65536 (2⁰, 2¹, 2², …, 2¹⁵, 216) выделяются по процедуре Expert Review (параграф 5.1);

крупные блоки из 131072 (2¹⁷) и более идентификаторов EUI-48 выделяются по процедуре IESG Ratification (параграф 5.1).

В [RFC5342] требовалось одновременное выделение индивидуальных и групповых идентификаторов в некоторых случаях, даже при использовании приложением лишь одного типа. Это требование было признано непрактичным и отменено в данном документе.

2.2. 64-битовые идентификаторы MAC

В IEEE также определена система 64-битовых идентификаторов MAC, включая EUI-64. Идентификаторы EUI-64 в настоящее время используются:

• в измененной форме для создания некоторых идентификаторов интерфейсов IPv6, как описано в параграфе 2.2.1;

• в IEEE Std 1394 (называется также FireWire и i.Link);

• в IEEE Std 802.15.4 (называется также ZigBee);

• в [InfiniBand].

Добавления 5-октетного (40 битов) расширения к 3-октетному OUI или более короткого расширения к более длинному префиксу [RAC-OUI] с общим размером 64 бита создает идентификатор EUI-64 под эгидой данного OUI или более длинного префикса. Как и для EUI-48 первый октет содержит биты Group и Local с таким же назначением.

Для 64-битовых MAC-адресов были выделены AFN и DNS RRTYPE (параграф 5.2).

Приведенное ниже описание почти полностью относится к «модифицированной» форме идентификаторов EUI-64, однако любой, кто назначает такие идентификаторы, может использовать также не измененную форму в качестве идентификаторов MAC на каналах, использующих такие 64-битовые идентификаторы для интерфейсов.

2.2.1. Использование модифицированных идентификаторов EUI-64 в IPv6

Идентификаторы MAC-64 используются в виде младших 64 битов некоторых адресов IPv6 (параграф 2.5.1 и Приложение A в [RFC4291], а также Приложение A в [RFC5214]). При таком использовании идентификатор MAC-64 изменяется путем инвертирования бита Local/Global для формирования «модифицированного идентификатора IETF EUI-64». Ниже показан идентификатор Modified EUI-64 для IANA OUI, где aa-bb-cc-dd-ee — биты расширения.

      02-00-5E-aa-bb-cc-dd-ee

В первом октете указано значение 02 вместо 00, поскольку в идентификаторах Modified EUI-64 значение бита Local/Global обратно по сравнению с идентификаторами EUI-48. Это уникальные в глобальном масштабе значения, содержащие бит 02 в первом октете, тогда как сброшенный бит означает локально назначенные адреса.

Бит Local/Global был инвертирован для того, чтобы упростить сетевым операторам создание идентификаторов с локальной значимостью. Таким образом такие измененные идентификаторы EUI-64, как 1, 2 и т. п. (без ведущих нулей) являются локальными. Без изменения локальные идентификаторы должны бы были меть вид 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02 и т. п.

Как и для идентификаторов MAC-48 бит 01 в первом октете указывает групповой идентификатор.

Когда два первых октета расширения в идентификаторе Modified EUI-64 имеют значение FF-FE, оставшаяся часть расширения представляет собой 24-битовое значение, выделенное держателем OUI для EUI-48. Например,

      02-00-5E-FF-FE-yy-yy-yy

или

      03-00-5E-FF-FE-yy-yy-yy

где yy-yy-yy является частью (глобального группового или индивидуального идентификатора EUI-48), которая назначена владельцем OUI (IANA в данном случае). Таким образом, любой держатель одного или множества идентификаторов EUI-48 из IANA OUI имеет также такое же число идентификаторов Modified EUI-64, которые могут формироваться путем вставки октетов FF-FE посередине их идентификаторов EUI-48 и обращения бита Local/Global.

Примечание. [EUI-64] определяет биты FF-FF как используемые для создания идентификатора IEEE EUI-64 из MAC-48. Данный документ говорит, что значение FF-FE используется для идентификаторов EUI-48. IETF использует только FF-FE для создания идентификаторов Modified EUI-64 из 48-битовых идентификаторов станций Ethernet независимо от того, являются они идентификаторами EUI-48 или MAC-48. Идентификаторы EUI-48 и локальные идентификаторы MAC-48 синтаксически эквивалентны и это не вызывает проблем на практике.

Кроме того, некоторые идентификаторы Modified EUI-64 под эгидой IANA OUI зарезервированы для держателей адресов IPv4 в форме

      02-00-5E-FE-xx-xx-xx-xx

где xx-xx-xx-xx — 32-битовый адрес IPv4. Владелец адреса IPv4 имеет индивидуальный и групповой адрес EUI-64. Модифицированные идентификаторы EUI-64 из диапазона

      02-00-5E-FE-F0-00-00-00 - 02-00-5E-FE-FF-FF-FF-FF

по сути дела зарезервированы для ожидаемой спецификации адресов IPv4 класса E. Однако для идентификаторов Modified EUI-64 на базе адресов IPv4 бит Local/Global следует устанавливать в соответствии с глобальной или локальной значимостью адреса IPv4 (принимайте во внимание, что в идентификаторах Modified EUI-64 значение бита Local/Global обратно по сравнению с исходными идентификаторами MAC-64).

2.2.2. Вопросы назначения EUI-64 в IANA

Ниже приведена таблица, показывающая зарезервированные, назначенные и доступные идентификаторы Modified EUI-64 для IANA OUI. Как было указано выше, соответствующие MAC-адреса могут быть определены путем дополнения бита 02 в первом октете. Во всех случаях блок групповых 64-битовых MAC-адресов, сформированных путем дополнения бита 01 в первом октете, имеет такой же статус, как и соответствующий блок индивидуальных 64-битовых адресов, показанный ниже.

02-00-5E-00-00-00-00-00 - 02-00-5E-0F-FF-FF-FF-FF резерв
02-00-5E-10-00-00-00-00 - 02-00-5E-10-00-00-00-FF выделено для использования в документации
02-00-5E-10-00-00-01-00 - 02-00-5E-EF-FF-FF-FF-FF доступно для распределения
02-00-5E-F0-00-00-00-00 - 02-00-5E-FD-FF-FF-FF-FF резерв
02-00-5E-FE-00-00-00-00 - 02-00-5E-FE-FF-FF-FF-FF выделено держателям адресов IPv4 (см. выше)
02-00-5E-FF-00-00-00-00 - 02-00-5E-FF-FD-FF-FF-FF резерв
02-00-5E-FF-FE-00-00-00 - 02-00-5E-FF-FE-FF-FF-FF выделено для EUI-48 под IANA OUI (см. выше)
02-00-5E-FF-FF-00-00-00 - 02-00-5E-FF-FF-FF-FF-FF резерв

Назначение из зарезервированных диапазонов идентификаторов, показанных выше, выполняется по процедуре IESG Ratification (параграф 5.1). Назначение идентификаторов IANA EUI-64 под эгидой IANA OUI должно происходить в соответствии с приведенными ниже правилами.

• Блок должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Блок должен иметь размер, равный степени 2, начиная с границы, равной или превышающей степень 2, включая выделение одного (2⁰) идентификатора.

• Недопустимо использование для обхода требований к производителям получать собственные блоки идентификаторов от IEEE.

• Блок должен быть документирован в Internet-Draft или RFC.

Кроме того, должны выполняться приведенные ниже правила (описание процедур дано в параграфе 5.1):

мелкие и средние блоки идентификаторов EUI-48 размером 1, 2, 4, …, 32768, 65536 (2⁰, 2¹, 2², …, 2¹⁵, 216) выделяются по процедуре Expert Review (параграф 5.1);

крупные блоки из 131072 (2¹⁷) и более идентификаторов EUI-48 выделяются по процедуре IESG Ratification (параграф 5.1).

2.2.3. EUI-64 Для документации

Ниже перечислены не модифицированные 64-битовые MAC-адреса для использования в документации. Созданные из IPv4 адреса основаны на адресах IPv4 для документации [RFC5737], а созданные на основе MAC адреса — на адресах EUI-48 для документации.

Индивидуальные

      00-00-5E-EF-10-00-00-00 - 00-00-5E-EF-10-00-00-FF общего назначения

      00-00-5E-FE-C0-00-02-00 - 00-00-5E-FE-C0-00-02-FF 
      00-00-5E-FE-C6-33-64-00 - 00-00-5E-FE-C6-33-64-FF 
      00-00-5E-FE-CB-00-71-00 - 00-00-5E-FE-CB-00-71-FF выведенные из IPv4

      00-00-5E-FF-FE-00-53-00 - 00-00-5E-FF-FE-00-53-FF выведенные из EUI-48

      00-00-5E-FE-EA-C0-00-02 
      00-00-5E-FE-EA-C6-33-64 
      00-00-5E-FE-EA-CB-00-71 групповые адреса IPv4 на основе индивидуальных IPv4 [RFC6034]

Групповые

      01-00-5E-EF-10-00-00-00 - 01-00-5E-EF-10-00-00-FF общего назначения

      01-00-5E-FE-C0-00-02-00 - 01-00-5E-FE-C0-00-02-FF 
      01-00-5E-FE-C6-33-64-00 - 01-00-5E-FE-C6-33-64-FF 
      01-00-5E-FE-CB-00-71-00 - 01-00-5E-FE-CB-00-71-FF выведенные из IPv4

      01-00-5E-FE-EA-C0-00-02 
      01-00-5E-FE-EA-C6-33-64 
      01-00-5E-FE-EA-CB-00-71 групповые адреса IPv4 на основе индивидуальных IPv4 [RFC6034]

      01-00-5E-FF-FE-90-10-00 - 01-00-5E-FF-FE-90-10-FF выведенные из EUI-48

2.3. Другие идентификаторы MAC-48, используемые IETF

Два других блока идентификаторов MAC-48 используются IETF, как описано ниже.

2.3.1. Идентификаторы с префиксом 33-33

Все групповые идентификаторы MAC-48 с префиксом 33-33 (т. е. 2³² групповых идентификаторов MAC из диапазона 33-33-00-00-00-00 — 33-33-FF-FF-FF-FF) используются в соответствии с [RFC2464] для групповой адресации IPv6. Во всех этих идентификаторах бит Group (младший бит первого октета) установлен для обеспечения корректной работы с имеющимся оборудованием. Бит Local также установлен и используется для этой цели в сетях IPv6.

Историческое примечание. При разработке IPv6 было решено использовать 3 для неизвестных значений и примеров, а 3333 Coyote Hill Road, Palo Alto, California является адресом PARC (исследовательский центр Palo Alto, ранее Xerox PARC). Спецификация Ethernet была разработана Digital Equipment Corporation, Intel Corporation и Xerox Corporation. Протокол Ethernet до IEEE [802.3] иногда называют DIX Ethernet (по первым буквам компаний).

2.3.2. Серия CF

В информационном [RFC2153] заявлено, что 3-октетные значения от CF-00-00 до CF-FF-FF будут выделены в качестве OUI, распределяемых IANA производителям программ для применения в PPP [RFC1661] и других приложениях, где от производителя не требуется наличие выделенного IEEE значения OUI. Следует отметить, что при использовании в качестве префиксов MAC-48 в этих значениях будут установлены биты Local и Group, тогда как в выделенных IEEE значениях OUI эти биты сброшены. Бит Group не имеет смысла в PPP. В [RFC2153] сказано: «Серия CF0000 была выбрана, чтобы соответствовать PPP NLPID ‘CF’, для мнемонического удобства.»

      CF-00-00 резерв, указывается IANA как групповой идентификатор
      CF-00-00-00-00-00 используется для тестов Ethernet.

За долгие годы использования серии CF было выделено лишь несколько значений (см. Ethernet Numbers <http://www.iana.org/assignments/ethernet-numbers> и PPP Numbers <http://www.iana.org/assignments/ppp-numbers>).

2.3.2.1. Отличия от RFC 2153

Раздел IANA Considerations в [RFC2153] был обновлен, как показано ниже, путем одобрения [RFC5342] (без технических изменений):

• использование этих идентификаторов основано на отмененных назначениях IANA;

• агентству IANA дана инструкция не выделять в дальнейшем значений из серии CF.

3. Протокольные параметры Ethernet

Параметры протокола Ethernet позволяют указать содержимое кадра, например, IPv4 или IPv6.

Концепция была расширена путем добавления «тегов». Тег в этом смысле является префиксом, тип которого указывается значением Ethertype, затем может следовать другой тег Ethertype или индикатор протокола LSAP⁸ для «основного» тела кадра, как описано ниже. Традиционно в мире [802_O&A] теги имеют фиксированный размер и не включают кодирования этого размера. Обрабатывающее кадр устройство в общем случае не может безопасно обрабатывать содержимое кадра после Ethertype, если значение этого поля не понятно. Примером является C-Tag (ранее Q-Tag) [802.1Q], который указывает VLAN и приоритет для кадра.

Имеется два типа параметров идентификации протокола, которые могут появляться в кадрах Ethernet после начальных идентификаторов MAC-48 для получателя и отправителя.

Ethertype

Этот 16-битовый идентификатор появляется в виде двух начальных октетов после MAC-адресов получателя и отправителя (или после тега) и рассматривается как целое число без знака со значением не меньше 0x0600.

LSAP

Эти 8-битовые идентификаторы протокола попарно присутствуют в кадре сразу после 16-битового (2 октета) поля размера кадра, который в свою очередь следует за MAC получателя и отправителя (или за тегом). Размер при его рассмотрении как целого числа без знака, будет меньше 0x5DC или может быть ошибочно принят за Ethertype. Поля LSAP присутствуют в паре, где одно предназначено для индикации обработчика протокола у отправителя, второе — у получателя, однако случаи применения двух разных обработчиков достаточно редки.

Значение Ethertype и LSAP не назначаются IANA, они находятся в ведении IEEE Registration Authority (параграф 1.3 и Приложение B). Однако LSAP и Ethertype имеют механизмы расширения, поэтому они могут быть использованы с 5-октетными идентификаторами протоколов Ethernet под эгидой OUI, включая назначенные IANA значения для IANA OUI.

При использовании формата IEEE 802 LLC⁹ (SNAP¹⁰) [802_O&A] для кадра основанный на OUI идентификатор протокола может быть представлен в виде

      xx-xx-AA-AA-03-yy-yy-yy-zz-zz

где xx-xx — размер кадра, который, как отмечено выше, должен быть достаточно малым для предотвращения путаницы с Ethertype. AA — идентификаторы LSAP, которые указывают использование формата (иногда называются SAP¹¹), 03 — октет управления LLC, указывающий службу дейтаграмм, yy-yy-yy — OUI, а zz-zz — номер протокола для данного OUI, назначаемый владельцем OUI. Нечетный 5-октетный размер для таких идентификаторов протоколов на базе OUI был выбран для того, чтобы вместе с октетом управления LLC (03) обеспечивалось выравнивание по 16-битовой границе.

При использовании Ethertype для индикации основного содержимого кадра доступно специальное значение OUI Extended Ethertype 88-B7. В этом случае начало тела кадра будет иметь вид

      88-B7-yy-yy-yy-zz-zz

где yy-yy-yy и zz-zz имеют такой смысл как для описанного выше формата SNAP.

В рамках SNAP возможно использование любого Ethertype, которое помещается в поле zz-zz после OUI 00-00-00

      xx-xx-AA-AA-03-00-00-00-zz-zz

где zz-zz означает Ethertype.

Отметим, что в настоящее время синтаксические возможности протокола 802 достаточно мощны для поддержки цепочек неограниченной длины. Необходимость поддержки таких цепочек не очевидна, но [802_O&A] требует поддерживать

         xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz

хотя это можно более эффективно выразить простой вставкой 00-00-00-88-B7 посредине.

Помимо маркировки содержимого кадра тип протокола 802 появляется в сообщениях NBMA¹² NHRP¹³ [RFC2332]. В таких сообщениях указываются двухоктетные значения Ethertype и типа протокола на базе OUI.

3.1. Назначение протокола Ethernet для IANA OUI

Двухоктетные номера протоколов для IANA OUI доступны в виде

      xx-xx-AA-AA-03-00-00-5E-qq-qq

где qq-qq — номер протокола.

Число таких назначений составляет 2¹⁶ номеров протоколов из диапазона 00-00-5E-00-00 — 00-00-5E-FF-FF (см. [IANA]). Крайние значения диапазона 00-00-5E-00-00 и 00-00-5E-FF-FF зарезервированы и могут быть выделены лишь по процедуре IESG Ratification (параграф 5.1). Новые назначение номеров протоколов SNAP SAP (qq-qq) для IANA OUI должны соответствовать приведенным ниже требованиям.

• Номер должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Номер должен быть документирован в Internet-Draft или RFC.

• Такие номера не выделяются для протоколов, имеющих Ethertype (поскольку они могут быть выражены указанием OUI, включающим только 0 перед Ethertype, как описано выше).

В дополнение к этому должна выполняться процедура Expert Review (или IESG Ratification для двух резервных значений), как описано в параграфе 5.1.

3.2. Номер протокола для документации

Номер протокола 0x0042 для IANA OUI (т. е. 00-00-5E-00-42) служит для использования в документации.

4. Другие параметры на основе OUI

Некоторые протоколы IEEE 802 и другие протоколы имеют основанные на OUI параметры, не описанные выше. Такие параметры обычно включают OUI и один октет дополнительного значения. Обычно их называют «фирменными» параметрами (vendor specific, хотя точнее было бы сказать organization specific). Эти параметры имеют вид

      yy-yy-yy-zz

где yy-yy-yy — OUI, zz — дополнительное значение. Примером может служить селектор шифра (Cipher Suite Selector) в IEEE [802.11].

Значения могут выделяться под эгидой IANA OUI для таких параметров на базе OUI по процедуре Expert Review за исключением значений, в которых дополнительный октет содержит только 0 или только 1 (0x00 — 00-00-5E-00 и 0xFF — 00-00-5E-FF), поскольку эти значения зарезервированы и выделяются по процедуре IESG Ratification (параграф 5.1). Кроме того, значение 0x42 (00-00-5E-42) выделено для использования в документации.

Назначение прочих параметров на базе IANA OUI должно быть связано со стандартизацией (IETF Standard или другая работа IETF, связанная со стандартом) и документировано в Internet-Draft или RFC. При первоначальном выделении значения конкретного параметра этого типа создается реестр IANA для этого и последующих значений данного параметра под эгидой IANA OUI. Имя реестра будет назначать эксперт.

Если для назначения такого параметра требуются другие правила, соответствующий RFC серии BCP или Standards Track должен быть выпущен заново или обновлен с учетом этих правил.

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

Этот документ целиком посвящен вопросам IANA по выделению значений параметров Ethernet для IANA OUI и связанным с этим вопросам.

Поскольку этот документ является заменой [RFC5342], ссылки на [RFC5342] в реестрах IANA заменены ссылками на данный документ. Кроме того, все ссылки на [DOC-ADDR] в реестрах, которые включены в данный документ, также заменены ссылками на этот документ.

Документ не создает новых реестров IANA.

Документ выделяет значения MAC-адресов для документации. Эти значения были выделены ранее в [DOC-ADDR], поэтому, как отмечено выше, все ссылки в реестрах на [DOC-ADDR] заменены ссылками на этот документ.

Единственным дополнительным назначением, сделанным в этом документе, является номер протокола для документации (параграф 5.6).

Документ не меняет выполненных ранее назначений.

5.1. Рецензия экспертов и ратификация IESG

В этом параграфе описаны процедуры Expert Review и IESG Ratification для MAC, протоколов и других параметров на базе IANA OUI. Экспертом здесь будем называть одного или нескольких лиц, назначенных и работающих в интересах IESG.

Процедура Expert Review, описанная здесь, полностью соответствует процедуре IANA Expert Review из [RFC5226].

Пространства, из которых выделяются значения, хотя и конечны, но достаточно велики, поэтому рецензии экспертов достаточно для выделения значений. Идея состоит в том, чтобы эксперт обеспечивал упрощенный контроль для небольших назначений идентификаторов EUI, обращая повышенное внимание на выделение блоков среднего размера для EUI, идентификаторов протоколов и других параметров на базе IANA OUI. Тем не менее, имеет смысл выделять очень большие части пространства идентификаторов MAC (отметим, что имеющиеся назначения включают один блок в половину доступного пространства групповых IANA EUI-48 и один блок размером в 1/16 этого пространства). В таких случаях и при выделении резервных значений должна применяться ратификация IESG после процедуры Expert Review в соответствии с приведенным ниже описанием.

Заявитель заполняет соответствующий шаблон из Приложения A и отправляет его в IANA по адресу <iana@iana.org>.

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

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

Для процедуры Expert Review:

Если IANA получает одобрение и запрошенные значения доступны, IANA выделяет эти значения.

Для процедуры IESG Ratification:

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

5.2. AFN и RRTYPE для MAC-адресов

Агентство IANA выделило значения номеров семейств адресов (AFN) для MAC-адресов, показанные в таблице.

Агентство IANA выделило значения DNS RRTYPE [RFC6895] для MAC-адресов, показанные в таблице.

EUI48

0x006C

EUI64

0x006D

5.3. Информационная Web-страница IANA

IANA поддерживает на своем сайте информационные списки значений Ethertype, OUI и групповых адресов, назначенных под эгидой OUI, отличающихся от IANA OUI. Этот информационный реестр называется IEEE 802 Numbers. Агентство IANA добавило в этот список значения Ethertype из Приложения B, которые не были включены ранее. IANA обновит этот реестр в соответствии с изменениями, представленными экспертом.

5.4. Нехватка OUI

Когда пространство индивидуальных или групповых идентификаторов EUI-48 для OUI 00-00-5E будет заполнено на 90% или более, IANA следует запросить дополнительное значение OUI в IEEE Registration Authority для распределения в рамках IANA. Заполнение пространства следует контролировать назначенному эксперту или экспертом и уведомлять IANA о нехватке свободного пространства.

5.5. Таблица MAC-адресов IANA OUI

В таблицах IANA Unicast 48-bit MAC Addresses и IANA Multicast 48-bit MAC Addresses были изменены лишь ссылки, как указано в начале раздела 5.

5.6. Таблица и назначение номеров протоколов SNAP

Таблица идентификаторов протоколов SNAP (SNAP PROTOCOL Ids) переименована в SNAP Protocol Numbers (номера протоколов SNAP). Вместо PID используется номер протокола (Protocol Number).

Агентство IANA выделило значение 0x0042 в качестве номера протокола SNAP под эгидой IANA OUI для использования в документации.

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

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

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

В [RFC7043] рассмотрены вопросы безопасности при хранении MAC-адресов в DNS.

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

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

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

David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, Dan Romascanu.

RFC 5342:

Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton, Lars Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie Kaufman, Erik Nordmark, Dan Romascanu, Geoff Thompson, Mark Townsley.

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

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

[802_O&A] «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2001, 8 March 2002.

«IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture / Amendment 1: Ethertypes for Prototype and Vendor-Specific Protocol Development», IEEE Std 802a-2003, 18 September 2003.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

[802.1Q] «IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks», IEEE Std 802.1Q-2011, 31 August 2011.

[802.3] «IEEE Standard for Ethernet», IEEE Std 802.3-2012, 28 December 2012.

[802.11] «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-2012, 29 March 2012.

[DOC-ADDR] Abley, J., «EUI-48 and EUI-64 Address Assignments for use in Documentation», Work in Progress, March 2013.

[EUI-64] IEEE Registration Authority, «Guidelines for 64-bit Global Identifier (EUI-64(TM))», <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>, November 2012.

[IANA] Internet Assigned Numbers Authority, <http://www.iana.org>.

[IEEE802] IEEE 802 LAN/MAN Standards Committee, <http://www.ieee802.org>.

[InfiniBand] InfiniBand Trade Association, «InfiniBand Architecture Specification Volume 1», November 2007.

[RAC-OUI] Parsons, G., «OUI Registry Restructuring», Work in Progress, September 2013.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC1661] Simpson, W., Ed., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[RFC2153] Simpson, W., «PPP Vendor Extensions», RFC 2153, May 1997.

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, «NBMA Next Hop Resolution Protocol (NHRP)», RFC 2332, April 1998.

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, December 1998.

[RFC2606] Eastlake 3rd, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, June 1999.

[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, «Etymology of «Foo»», RFC 3092, April 1 2001.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, January 2007.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, March 2008.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, «MPLS Multicast Encapsulations», RFC 5332, August 2008.

[RFC5342] Eastlake 3rd, D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», BCP 141, RFC 5342, September 2008.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, March 2010.

[RFC6034] Thaler, D., «Unicast-Prefix-Based IPv4 Multicast Addresses», RFC 6034, October 2010.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, April 2013.

[RFC7043] Abley, J., «Resource Records for EUI-48 and EUI-64 Addresses in the DNS», RFC 7043, October 2013.

Приложение A. Шаблоны

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

A.1. Шаблон для выделения идентификатора или блока EUI-48/EUI-64

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны)
Применение: (краткое описание использования параметра типа «Foo Protocol» [RFC3092])
Документ: (ID или RFC, задающий приложение, для которого выделяется идентификатор или блок идентификаторов).
Тип используемого приложением идентификатора: EUI-48 или EUI-64:
Размер запрашиваемого блока: (должен быть степенью 2, включая 1 идентификатор)
Тип: индивидуальный, групповой или оба.

A.2. Шаблон для номера протокола на базе IANA OUI

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны)
Применение: (краткое описание использования кода типа «Foo Protocol»)
Документ: (ID или RFC, задающий приложение, для которого выделяется идентификатор протокола).
Примечание: (дополнительная информация).

A.3. Шаблон для прочих параметров на базе IANA OUI

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны).
Протокол, в котором используется запрошенное значение параметра на базе OUI: (типа выбора шифра в IEEE 802.11).
Применение: (краткое описание использования кода типа «Foo Cipher Suite» [RFC3092]).
Документ: (ID или RFC, задающий приложение, для которого выделяется параметр на базе IANA OUI).
Примечание: (дополнительная информация).

Приложение B. Значения Ethertype

В этом приложении указаны некоторые значения Ethertype, заданные для протоколов IETF или IEEE 802 и известные на момент публикации. Актуальный список доступен на сайте IANA [IANA]. Может быть полезна также страница IEEE Registration Authority для значений Ethertype http://standards.ieee.org/regauth/ethertype/eth.txt. См. Также раздел 3 выше.

B.1. Некоторые значения Ethertype, заданные IETF

0x0800  Internet Protocol Version 4 (IPv4)
0x0806  Address Resolution Protocol (ARP)
0x0808  Frame Relay ARP
0x22F3  TRILL
0x22F4  L2-IS-IS
0x8035  Reverse Address Resolution Protocol (RARP)
0x86DD  Internet Protocol Version 6 (IPv6)
0x880B  Point-to-Point Protocol (PPP)
0x880C  General Switch Management Protocol (GSMP)
0x8847  MPLS
0x8848  MPLS with upstream-assigned label
0x8861  Multicast Channel Allocation Protocol (MCAP)
0x8863  PPP over Ethernet (PPPoE) Discovery Stage
0x8864  PPP over Ethernet (PPPoE) Session Stage
0x893B  TRILL Fine Grained Labeling (FGL)
0x8946  TRILL RBridge Channel

B.2. Некоторые значения IEEE 802 Ethertype

0x8100  IEEE Std 802.1Q   Customer VLAN Tag Type (C-Tag14) (изначально Wellfleet)
0x8808  IEEE Std 802.3    Ethernet Passive Optical Network (EPON)
0x888E  IEEE Std 802.1X   Управление доступом в сеть на уровне порта
0x88A8  IEEE Std 802.1Q   Идентификатор тега Service VLAN (S-Tag)
0x88B5  IEEE Std 802      Ethertype для локальных экспериментов
0x88B6  IEEE Std 802      Ethertype для локальных экспериментов
0x88B7  IEEE Std 802      OUI Extended Ethertype
0x88C7  IEEE Std 802.11   Pre-Authentication (802.11i)
0x88CC  IEEE Std 802.1AB  Протокол определения канального уровня (LLDP15)
0x88E5  IEEE Std 802.1AE  Media Access Control Security
0x88F5  IEEE Std 802.1Q   Multiple VLAN Registration Protocol (MVRP)
0x88F6  IEEE Std 802.1Q   Multiple Multicast Registration Protocol (MMRP)
0x890D  IEEE Std 802.11   Fast Roaming Remote Request (802.11r)
0x8917  IEEE Std 802.21   Media Independent Handover Protocol
0x8929  IEEE Std 802.1Qbe Multiple I-SID Registration Protocol
0x8940  IEEE Std 802.1Qbg Протокол ECP (используется также в 802.1BR)

Приложение C. Номер протокола для документации

Ниже приведен шаблон, на основе которого был назначен номер протокола, основанного на IANA OUI, для использования в документации (см. раздел 3 и Приложение A.2.)

Имя заявителя: Donald E. Eastlake 3rd
Электронная почта: d3e3e3@gmail.com
Телефон заявителя: 1-508-333-2270
Применение: документация
Документ: данный документ
Примечание: запрошено значение 0x0042

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

Donald E. Eastlake 3rd

Huawei Technologies

155 Beaver Street

Milford, MA 01757

USA

Phone: +1-508-634-2066

EMail: d3e3e3@gmail.com

Joe Abley

Dyn, Inc.

470 Moore Street

London, ON N6C 2C2

Canada

Phone: +1 519 670 9327

EMail: jabley@dyn.com

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                    B. Claise, Ed.
Request for Comments: 7011                           Cisco Systems, Inc.
STD: 77                                                 B. Trammell, Ed.
Obsoletes: 5101                                               ETH Zurich
Category: Standards Track                                      P. Aitken
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                          September 2013

Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information

Спецификация протокола IPFIX для обмена информацией о потоках

PDF

Аннотация

Этот документ задаёт протокол экспорта сведений о потоках IP (IP Flow Information Export илиIPFIX), служащий для передачи информации о потоках трафика через сеть. Для передачи сведений Traffic Flow от экспортирующего процесса сборщику (Collecting Process) требуется общее представление потоков данных и стандарт для их передачи. Этот документ описывает как данные и шаблоны IPFIX передаются по разным транспортным протоколам IPFIX Exporting Process к IPFIX Collecting Process. Этот документ заменяет RFC 5101.

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

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

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

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

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

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

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

1.1. Отличия от RFC 5101

Этот документ отменяет выпуск Proposed Standard спецификации протокола IPFIX [RFC5101]. Заданный здесь протокол способен взаимодействовать с протоколом [RFC5101]. Ниже указаны отличия данного документа от предшественника.

• Исправлены все технические и редакционные ошибки в [RFC5101].

• Поскольку реестр [IANA-IPFIX] сейчас является нормативным для всех определений информационных элементов (см. [RFC7012]), определения информационных элементов в разделе 4 заменены ссылками на этот реестр.

• Уточнено кодирование типов данных dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds и dateTimeNanoseconds, а также связанно с ним кодирование поля IPFIX Message Header Export Time, особенно в части эпохи, на которой основаны типы данных для временных меток.

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

• Уточнено кодирование, особенно в разделе 6. Связь с информационной моделью, указанием использования сетевого порядка байтов для всех значений IPFIX.

• Упрощено управление шаблонами (раздел 8. Управление шаблонами). Спецификация смягчена по сравнению с [RFC5101], особенно в части отказов при повторном использовании Template ID. Исключены ненужные крайние случаи при управлении шаблонами. Новый язык управления шаблонами совместим с языком [RFC5101], насколько поведение было определено в прежней спецификации.

• Параграф 11.3. Взаимная проверка подлинности был улучшен со ссылками на современную практику взаимной аутентификации в TLS, исключены ссылки на Punycode, поскольку это описано в [RFC6125].

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

• Добавлен раздел 12. Вопросы управления.

1.2. Обзор документов IPFIX

Протокол IPFIX обеспечивает сетевым администраторам доступ к информации IP Flow. Архитектура экспорта сведений IP Flow из процесса экспорта (Exporting Process) в процесс-коллектор (Collecting Process) определена в [RFC5470] в соответствии с требованиями [RFC3917]. Этот документ определяет как записи (Record) и шаблоны (Template) IPFIX передаются по разным транспортным протоколам из процессов экспорта в коллекторы.

В настоящее время определены 4 оптимизации и расширения IPFIX: метод экономии полосы для протокола IPFIX [RFC5473], эффективный метод экспорта двухсторонних потоков [RFC5103], метод определения и экспорта комплексных структур данных [RFC6313] и спецификация протокола для посредников (IPFIX Mediator) [IPFIX-MED-PROTO] на основе IPFIX Mediation Framework [RFC6183].

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

Формальное описание информационных элементов IPFIX (IPFIX Information Element) — их имён, типов данных и дополнительной семантики — дано в [RFC7012]. Реестр элементов поддерживает IANA [IANA-IPFIX]. Встроенный (inline) экспорт сведений о типах информационных элементов задан в [RFC5610].

Модель выбора пакетов и отчётов [RFC5474] позволяет элементам сети выбирать подмножество пакетов статистически или иным методом и экспортировать поток отчётов по выбранным пакетам в коллектор. Набор методов отбора пакетов, стандартизованных протоколом выборки (Packet Sampling или PSAMP), описан в [RFC5475]. Протокол PSAMP [RFC5476], использующий IPFIX как протокол экспорта, задаёт экспорт сведений о пакетах из процесса экспорта PSAMP (Exporting Process) в коллектор PSAMP. Вместо экспорта отчётов о пакетах (PSAMP Packet Report) входными данными для генерации записей о потоках IPFIX (Flow Record) может служить поток выбранных пакетов. Как и IPFIX, протокол PSAMP имеет формальное описание информационных элементов (имена, типы, дополнительная семантика). Информационная модель PSAMP определена в [RFC5477].

В [RFC6615] задан модуль MIB для мониторинга, а в [RFC6728] — модель данных для настройки и мониторинга совместимых с IPFIX и PSAMP сетевых устройств по протоколу настройки сети (Network Configuration Protocol или NETCONF). В [RFC6727] задан модуль PSAMP MIB как расширение модуля IPFIX SELECTOR MIB из [RFC6615].

В части разработки [RFC5153] содержит рекомендации по реализации и применению протокола IPFIX, а [RFC5471] — рекомендации по тестированию. В [RFC5472] описано, какие типы приложений могут использовать протокол IPFIX и предоставляемую информацию, а также связь модели IPFIX с другими моделями и архитектурой.

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

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

Определения базовых терминов, таких как Traffic Flow, Exporting Process, Collecting Process, Observation Points и т. п., семантически идентичны применяемым в документе с требованиями к IPFIX [RFC3917]. Некоторые термины описаны более подробно для более чёткого определения протокола. Определены дополнительные термины, нужные для протокола. Определения данного документа и [RFC5470] эквивалентны, определения, связанные лишь с протоколом IPFIX, представлены только здесь. Сводка терминов в параграфе 2.1 даёт краткий обзор связей между терминами.

Observation Point — точка наблюдения

Observation Domain — домен наблюдения

Packet Treatment — обработка (трактовка) пакетов

Traffic Flow или Flow — поток трафика или поток

1. одного или нескольких полей пакета (например, IP-адрес получателя), полей транспортного заголовка (например, номер целевого порта) или полей прикладного заголовка (например, RTP [RFC3550]);
2. одного или нескольких параметров самого пакета (например, число меток MPLS);
3. одного или нескольких полей, выведенных при обработке (Treatment) пакета (например, next-hop IP, выходной интерфейс и т. п.).

Flow Key — ключ потока

1. относится к заголовку пакета (например, IP-адрес получателя);
2. является свойством самого пакета (например, размер пакета);
3. выводится при обработке пакета (например, номер автономной системы AS)

Flow Record — запись о потоке

Metering Process — процесс измерения

Exporting Process — процесс экспорта

Exporter — экспортёр

IPFIX Device — устройство IPFIX

Collecting Process — процесс сбора

Collector — коллектор (сборщик)

Template — шаблон

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

Message Header — заголовок сообщения

Template Record — шаблонная запись

Data Record — запись с данными

Options Template Record — запись с шаблоном опций

Set — набор

Template Set — набор шаблонов

Options Template Set — набор шаблонов опций

Data Set — набор данных

Information Element — информационный элемент

Transport Session — транспортная сессия

2.1. Сводка терминов

На рисунке A показана сводка терминов IPFIX и связей между ними.

+------------------+---------------------------------------------+
|                  |                Содержимое                   |
|                  +--------------------+------------------------+
|       Set        |      Template      |         Record         |
+------------------+--------------------+------------------------+
|     Data Set     |          -         |     Data Record(s)     |
+------------------+--------------------+------------------------+
|   Template Set   | Template Record(s) |           -            |
+------------------+--------------------+------------------------+
| Options Template |  Options Template  |           -            |
|       Set        |      Record(s)     |                        |
+------------------+--------------------+------------------------+

Рисунок A. Сводная таблица терминов.

Data Set состоит из записей Data Record без включения шаблонов (Template Record). Записи Data Record определяются Template Record или Options Template Record.

Набор шаблонов (Template Set) содержит лишь записи Template Record.

Набор шаблонов опций (Options Template Set) содержит только записи Options Template Record.

3. Формат сообщений IPFIX

Сообщение IPFIX состоит из заголовка Message Header, за которым могут следовать наборы Set, любого из 3 возможных типов Data Set, Template Set, Options Template Set. Формат сообщения IPFIX показан на рисунке B.

+----------------------------------------------------+
| Message Header                                     |
+----------------------------------------------------+
| Set                                                |
+----------------------------------------------------+
| Set                                                |
+----------------------------------------------------+
 ...
+----------------------------------------------------+
| Set                                                |
+----------------------------------------------------+

Рисунок B. Формат сообщения IPFIX.

Рассмотрим примеры сообщений IPFIX.

1. IPFIX Message с чередующимися Template, Data, Options Template Sets, как показано на рисунке C. Наборы Template и Options Template передаются «по запросу» перед первым Data Set, структуру которого они задают.

2. +--------+--------------------------------------------------------+
   |        | +----------+ +---------+     +-----------+ +---------+ |
   |Message | | Template | | Data    |     | Options   | | Data    | |
   | Header | | Set      | | Set     | ... | Template  | | Set     | |
   |        | |          | |         |     | Set       | |         | |
   |        | +----------+ +---------+     +-----------+ +---------+ |
   +--------+--------------------------------------------------------+

   Рисунок C. Сообщение IPFIX, пример 1.

   
   Сообщение, содержащее лишь наборы данных, передаётся после указания и передачи процессу сборки подходящих Template Record, как показано на рисунке D.

3. +--------+----------------------------------------------+
   |        | +---------+     +---------+      +---------+ |
   |Message | | Data    |     | Data    |      | Data    | |
   | Header | | Set     | ... | Set     | ...  | Set     | |
   |        | +---------+     +---------+      +---------+ |
   +--------+----------------------------------------------+

   Рисунок D. Сообщение IPFIX, пример 2.

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

+--------+-------------------------------------------------+
|        | +----------+     +----------+      +----------+ |
|Message | | Template |     | Template |      | Options  | |
| Header | | Set      | ... | Set      | ...  | Template | |
|        | |          |     |          |      | Set      | |
|        | +----------+     +----------+      +----------+ |
+--------+-------------------------------------------------+

Рисунок E. Сообщение IPFIX, пример 3.

3.1. Формат заголовка сообщения

Формат заголовка сообщений IPFIX показан на рисунке F.

 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 Number          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Export Time                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Observation Domain ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок F. Формат заголовка сообщения IPFIX.

Каждое поле Message Header экспортируется с сетевым порядком байтов. Поля заголовка описаны ниже.

Version

Length

Export Time

Sequence Number

Observation Domain ID

3.2. Формат спецификатора поля

Производителям нужна возможность определять фирменные (proprietary) информационные элементы, потому, что они, например, поставляют ещё не стандартизованную продукцию или информационный элемент является коммерчески важным. В этом параграфе определён формат спецификаторов полей (Field Specifier) для зарегистрированных IANA [IANA-IPFIX] и фирменных информационных элементов.

Информационные элементы указываются идентификаторами. Значение бита Enterprise = 0 указывает Information Element из реестра [IANA-IPFIX] и полю Enterprise Number присутствовать недопустимо. При Enterprise = 1 соответствующий информационный элемент считается фирменным (enterprise-specific) и поле Enterprise Number должно присутствовать. Примеры этого представлены в приложении A.2.2.

Формат Field Specifier представлен на рисунке G.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|  Information Element ident. |        Field Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Enterprise Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок G. Формат спецификатора поля.

E

Information Element identifier

Field Length

Enterprise Number

3.3. Формат Set и Set Header

Set — базовый термин для набора записей с похожей структурой. Имеется три типа наборов: Template Set, Options Template Set, Data Set, каждый из которых включает Set Header и хотя бы одну запись. Определения Set Format и Set Header Format приведены в следующих параграфах.

3.3.1. Формат Set

Формат Set показан на рисунке H. Записи могут иметь тип Template Record, Options Template Record, Data Record. недопустимо смешивать типы записей в Set.

+--------------------------------------------------+
| Set Header                                       |
+--------------------------------------------------+
| record                                           |
+--------------------------------------------------+
| record                                           |
+--------------------------------------------------+
 ...
+--------------------------------------------------+
| record                                           |
+--------------------------------------------------+
| Padding (необязательно)                          |
+--------------------------------------------------+

Рисунок H. Формат Set.

Set Header

Record

Padding

3.3.2. Формат Set Header

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID               |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок I. Формат заголовка Set.

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

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

Set ID

Length

3.4. Форматы записей

IPFIX определяет 3 формата записей, описанных в последующих параграфах: Template Record, Options Template Record, Data Record.

3.4.1. Формат Template Record

Одним из важных элементов формата записей IPFIX является Template Record. Шаблоны значительно повышают гибкость формата записей, поскольку позволяют процессам сбора обрабатывать сообщения IPFIX без обязанности знать интерпретацию всех Data Record. Template Record содержит комбинацию идентификаторов информационных элементов, выделенных IANA или созданных предприятием (enterprise-specific).

Формат Template Record показан на рисунке J и включает Template Record Header, а также хотя бы 1 спецификатор. Формат спецификатора показан на рисунке G.

+--------------------------------------------------+
| Template Record Header                           |
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+
 ...
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+

Рисунок J. Формат Template Record.

Формат Template Record Header показан на рисунке K.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Template ID (> 255)      |         Field Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок K. Формат заголовка Template Record.

Template ID

Field Count

На рисунке L дан пример Template Set с выделенными IANA и фирменными информационными элементами. Они содержат Set Header, Template Header и несколько Field Specifier. Информационные элементы с id.s 1.2 и 2.1 присутствуют в [IANA-IPFIX] (бит Enterprise = 0) и для них не указывается Enterprise Number.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 2           |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Template ID = 256        |         Field Count = N       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 |        Field Length 1.1       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Enterprise Number  1.1                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 |        Field Length 1.2       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ...               |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N |        Field Length 1.N       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Enterprise Number  1.N                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Template ID = 257        |         Field Count = M       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 |        Field Length 2.1       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 |        Field Length 2.2       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Enterprise Number  2.2                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ...               |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M |        Field Length 2.M       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Enterprise Number  2.M                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Padding (необязательно)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок L. Пример Template Set.

3.4.2. Формат Options Template Record

Благодаря понятию области действия (scope), Options Template Record даёт экспортёру возможность предоставить сборщику дополнительные сведения, что было бы невозможно при использовании лишь Flow Record.

Описания Options Template для метаданных отчётов о процессах измерения и экспорта IPFIX приведены в разделе 4. Требования к отчётам.

3.4.2.1. Область действия

Область действия (scope), доступная лишь в Options Template Set, даёт контекст сообщённых Information Element в Data Record. Областью действия является один или несколько информационных элементов, заданных в Options Template Record. Процессам сбора следует поддерживать в качестве области действия по меньшей мере информационные элементы observationDomainId, exportingProcessId, meteringProcessId, templateId, lineCardId, exporterIPv4Address, exporterIPv6Address и ingressInterface. Протокол IPFIX не препятствует использованию для области действия любых информационных элементов, однако некоторые элементы (например, информационные элементы счётчиков) не имеют смысла в таком качестве.

Заголовок сообщения IPFIX Message Header уже содержит идентификатор домена наблюдения. Отличный от 0 Observation Domain ID можно считать неявным указанием области действия для Data Records в сообщении IPFIX.

В Options Template Record можно указать несколько полей Scope, комбинация которых будет задавать область действия. Например, при указании meteringProcessId и templateId областью действия будет данный шаблон для данного процесса измерения. Если разный порядок полей Scope может менять семантику записи, процесс экспорта должен сохранять порядок полей Scope. Например, в контексте PSAMP [RFC5476] при определении первым полем Scope функции фильтрации, а вторым — функции выборки порядок полей будет иметь значение. Применение сначала функции отбора, а затем функции фильтра может давать иные Data Record, нежели в случае исходного порядка.

3.4.2.2. Формат Options Template Record

Записи Options Template Record могут содержать произвольные комбинации идентификаторов элементов (выделенных IANA и фирменных). Формат Options Template Record показан на рисунке M и включает Template Record Header, а также 1 или несколько Field Specifier (см. Рисунок G).

+--------------------------------------------------+
| Options Template Record Header                   |
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+
 ...
+--------------------------------------------------+
| Field Specifier                                  |
+--------------------------------------------------+

Рисунок M. Формат записи Options Template.

Формат заголовка Options Template Record приведён на рисунке N.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Template ID (> 255)   |         Field Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Scope Field Count        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок N. Формат заголовка Options Template Record.

Template ID

Field Count

Scope Field Count

Рисунок O показывает пример Options Template Set с информационными элементами IANA и enterprise-specific. Он включает Set Header, Options Template Header и несколько Field Specifier.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 3           |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Template ID = 258     |         Field Count = N + M   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = N     |0|  Scope 1 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope 1 Field Length      |0|  Scope 2 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope 2 Field Length      |             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            ...                |1|  Scope N Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope N Field Length      |   Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...  Scope N Enterprise Number  |1| Option 1 Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option 1 Field Length      |  Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number  |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ...               |0| Option M Infor. Element id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Option M Field Length     |    Padding (необязательно)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок O. Пример Options Template Set.

3.4.3. Формат Data Record

Записи Data Record передаются в Data Set. Формат Data Record показан на рисунке P и включает хотя бы одно поле Field Value. Template ID, к которому относятся Field Value, указывается в поле заголовка Set ID, например, Set ID = Template ID.

+--------------------------------------------------+
| Field Value                                      |
+--------------------------------------------------+
| Field Value                                      |
+--------------------------------------------------+
 ...
+--------------------------------------------------+
| Field Value                                      |
+--------------------------------------------------+

Рисунок P. Формат Data Record.

Отметим, что Field Value не обязаны иметь размер 16 битов и кодируются в соответствии с типом данных, как указано в [RFC7012].

Интерпретация формата Data Record возможна лишь в случае доступности у сборщика записи Template Record, соответствующей Template ID.

На рисунке Q приведён пример Data Set с заголовком Set Header и несколькими полями Field Value.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Set ID = Template ID        |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 1 - Field Value 3    |             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 2 - Field Value 3    |             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 3 - Field Value 1    |   Record 3 - Field Value 2    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 3 - Field Value 3    |             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |    Padding (необязательно)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок Q. Data Set с записями Data Record.

4. Требования к отчётам

Некоторые конкретные Options Template и Options Template Record требуются для предоставления дополнительных сведений о Flow Record и Metering Process.

Могут быть реализованы Options Template и Options Template Record определённые в параграфах, которые налагают некоторые ограничения на реализации процессов измерения и экспорта. В том случае Options Template следует реализовать с соответствии с этими параграфами. В этих конкретных IPFIX Options Template всегда задаётся минимальный набор информационных элементов, но с конкретных шаблонах могут применяться дополнительные информационные элементы.

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

4.1. Шаблон опций статистики измерений

Metering Process Statistics Options Template задаёт структуру Data Record для статистических отчётов процесса измерения. В него следует включать указанные ниже информационные элементы, как задано в [IANA-IPFIX].

(scope) observationDomainId

(scope) meteringProcessId

exportedMessageTotalCount

exportedFlowRecordTotalCount

exportedOctetTotalCount

Процессу экспорта следует экспортировать Data Record, указанную в Metering Process Statistics Options Template на регулярной основе или в соответствии с некими правилами экспорта, для чего следует обеспечивать возможность настройки.

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

4.2. Шаблон опций статистики надёжности процесса измерения

Metering Process Reliability Statistics Options Template задаёт структуру Data Record для отчёта о недостаточной надёжности процесса измерения. В него следует включать указанные ниже информационные элементы, как задано в [IANA-IPFIX].

(scope) observationDomainId

(scope) meteringProcessId

ignoredPacketTotalCount

ignoredOctetTotalCount

время, когда был проигнорирован первый пакет

время, когда был проигнорирован последний пакет

Процессу экспорта следует экспортировать Data Record, заданную Metering Process Reliability Statistics Options Template на регулярной основе или в соответствии с некими правилами экспорта, для чего следует обеспечивать возможность настройки.

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

Поскольку Metering Process Reliability Statistics Options Template содержит два информационных элемента с идентичными временными метками, а порядок информационных элементов в Template Record не гарантируется, процесс сбора интерпретирует интервал игнорирования пакетов как диапазон между двумя значениями. Учёт перехода через максимум рассмотрен в параграфе 5.2. Поддержка перехода временных меток через максимум.

4.3. Шаблон опций статистики надёжности процесса экспорта

Exporting Process Reliability Statistics Options Template задаёт структуру Data Record для отчёта о недостаточной надёжности процесса экспорта. В него следует включать указанные ниже информационные элементы, как задано в [IANA-IPFIX].

(scope) Exporting Process Identifier

notSentFlowTotalCount

notSentPacketTotalCount

notSentOctetTotalCount

время, когда был отброшен первый поток

время, когда был отброшен последний поток

Процессу экспорта следует экспортировать Data Record, заданную Exporting Process Reliability Statistics Options Template на регулярной основе или в соответствии с некими правилами экспорта, для чего следует обеспечивать возможность настройки.

Поскольку Exporting Process Reliability Statistics Options Template содержит два информационных элемента с идентичными временными метками, а порядок информационных элементов в Template Record не гарантируется, процесс сбора интерпретирует интервал игнорирования пакетов как диапазон между двумя значениями. Учёт перехода через максимум рассмотрен в параграфе 5.2. Поддержка перехода временных меток через максимум.

4.4. Шаблон опций ключей потока

Flow Keys Options Template задаёт структуру Data Record для Flow Key в отчётах о потоках. Flow Keys Data Record расширяет конкретную Template Record, указанную templateId. Запись Template расширяется путём указания информационных элементов, содержащихся в соответствующих Data Record, описывающих свойства потока, которые служат ключами (Flow Key) для потока в отчёте.

В Flow Keys Options Template следует включать указанные ниже информационные элементы, как задано в [IANA-IPFIX]

(scope) templateId

flowKeyIndicator

5. Вопросы синхронизации

5.1. Export Time и Flow Record Time в сообщении IPFIX

Поле Export Time Message Header в сообщении IPFIX указывает время, когда IPFIX Message Header покидает Exporter, с использованием того же формата кодирования, как в абстрактном типе данных dateTimeSeconds [RFC7012], т. е. в секундах с начала эпохи UNIX (1 января 1970 г., 00:00 UTC) в форме 32-битового целого числа без знака.

Некоторые информационные элементы, связанные со временем, могут указываться смещением от Export Time. Например, Data Record, требующие микросекундной точности, могут экспортировать время начала и завершения потока в информационных элементах flowStartMicroseconds и flowEndMicroseconds, которые указывают время эпохи NTP (1 января 1900 г., 00:00 UTC) в 64-битовом поле. Другим решением является экспорт flowStartDeltaMicroseconds и flowEndDeltaMicroseconds в Data Record с указанием времени начала и завершения отрицательным смещением от Export Time в форме 32-битового целого числа без знака. Это снижает требования к пропускной способности для экспорта за счёт уменьшения временных меток на 4 байта, но повышает нагрузку на экспортёра, поскольку Exporting Process требуется рассчитывать flowStartDeltaMicroseconds и flowEndDeltaMicroseconds для каждой Data Record в сообщении IPFIX.

Нужно отметить, что временные метки на основе Export Time вносят некоторые ограничения для Data Record в сообщении IPFIX. В примере с информационными элементами flowStartDeltaMicroseconds и flowEndDeltaMicroseconds запись Data Record может включать лишь метки из интервала 71 минуту до Export Time, поскольку иначе размер метки начала выйдет за пределы 32-битового значения смещения.

5.2. Поддержка перехода временных меток через максимум

Абстрактный тип данных dateTimeSeconds [RFC7012] и поле Export Time Message Header (5.1. Export Time и Flow Record Time в сообщении IPFIX) кодируются 32-битовыми целыми числами без знака в секундах с начала эпохи UNIX (1 января 1970 г., 00:00 UTC), как задано в [POSIX.1]. Эти поля достигнут максимума 7 февраля 2106 в 06:28:16 UTC.

Для поддержки использования протокола IPFIX после этой даты процессу экспорта следует экспортировать значения dateTimeSeconds и поле Export Time Message Header как число секунд с начала эпохи UNIX (1 января 1970 г., 00:00 UTC) по модулю 232. Процессам сбора следует использовать текущую дату или иной контекст для подобающей интерпретации значений dateTimeSeconds и поля Export Time Message Header.

Аналогичные соображения применимы и к основанным на эпохе NTP абстрактным типам dateTimeMicroseconds и dateTimeNanoseconds [RFC7012]. Процессу экспорта Exporting Process следует экспортировать значения dateTimeMicroseconds и dateTimeNanoseconds, как будто эра NTP [RFC5905] задана неявно, а процессам сбора следует использовать текущую дату или иной контекст для определения эры NTP, чтобы должным образом интерпретировать значения dateTimeMicroseconds и dateTimeNanoseconds в полученных Data Record.

Абстрактный тип dateTimeMilliseconds будет достигать максимума приблизительно через 500 миллиардов лет и спецификация поведения этого типа в более позднее время оставлена для будущей версии этой спецификации.

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

6. Связь с информационной моделью

Как и в IPFIX Message Header и Set Header, значения информационных элементов [RFC7012], кроме типов string и octetArray, кодируются в каноническом формате с сетевым порядком байтов (big-endian).

6.1. Кодирование типов данных IPFIX

В последующих параграфах определено кодирование типов данных из [RFC7012].

6.1.1. Интегральные типы

Интегральные типы unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, signed64 должны кодироваться с использованием канонического формата с каноническим порядком байтов. Интегральные типы со знаком представляются как дополнение до 2.

6.1.2. Адресные типы

Адресные типы macAddress, ipv4Address, ipv6Address должны кодироваться так же, как интегральные с размером 6, 4 и 16 октетов, соответственно, и сетевым порядком байтов.

6.1.3. float32

Данные типа float32 должны кодироваться как числа с плавающей точкой IEEE binary32 в соответствии с [IEEE.754.2008] с сетевым порядком байтов, как указано в параграфе 3.6 [RFC1014]. Отметим, что на машинах с прямым порядком байтов (little-endian) требуется соответствующая перестановка байтов перед экспортом. Метод перестановки может зависеть от платформы.

6.1.4. float64

Данные типа float64 должны кодироваться как числа с плавающей точкой IEEE binary64 в соответствии с [IEEE.754.2008] с сетевым порядком байтов, как указано в параграфе 3.6 [RFC1014]. Отметим, что на машинах с прямым порядком байтов (little-endian) требуется соответствующая перестановка байтов перед экспортом. Метод перестановки может зависеть от платформы.

6.1.5. boolean

Логический тип данных (boolean) задан в соответствии с TruthValue в [RFC2579] и кодируется 1-октетным целым числом в соответствии с параграфом 6.1.1. Значение 1 указывает истину (true), 2 — ложь (false). Все прочие значения остаются неопределёнными.

6.1.6. string и octetArray

Тип данных string представляет строки конечной длины из разрешённых символов Unicode. Тип string должен кодироваться в формате UTF-8 [RFC3629]. Строки передаются как массив (возможно пустой) октетов с использованием информационных элементов переменного размера. Процессу экспорта IPFIX недопустимо передавать сообщения IPFIX, содержащие некорректные строки UTF-8 для информационных элементов типа string, процессам сбора следует обнаруживать и игнрировать такие значения. Дополнительная информация представлена в [UTF8-EXPLOIT].

Для типа octetArray не задано правил кодирования, он представляет необработанный (raw) массив (возможно пустой) октетов, интерпретация которых задаётся определением информационного элемента.

6.1.7. dateTimeSeconds

Тип dateTimeSeconds выражается 32-битовым целым числом без знака с сетевым порядком байтов, указывает число секунд с начала эпохи UNIX (1 января 1970 г., 00:00 UTC), как указано в [POSIX.1]. dateTimeSeconds кодируется аналогично полю IPFIX Message Header Export Time и может представлять даты с 1 января 1970 г. до 7 февраля 2106 без перехода через максимум (см. параграф 5.2. Поддержка перехода временных меток через максимум).

6.1.8. dateTimeMilliseconds

Тип dateTimeMilliseconds выражается 64-битовым целым числом без знака с сетевым порядком байтов, указывает число секунд с начала эпохи UNIX (1 января 1970 г., 00:00 UTC), как указано в [POSIX.1] и может представлять даты с 1 января 1970 г. приблизительно на 500 миллиардов лет без перехода через максимум.

6.1.9. dateTimeMicroseconds

Тип dateTimeMicroseconds выражается 64-битовым целым числом без знака, кодируемым в формате NTP Timestamp, как указано в разделе 6 [RFC5905]. Это поле состоит из двух 32-битовых целых чисел без знака — Seconds (секунды) и Fraction (доли секунды). Поле Seconds указывает число секунд с начала эпохи NTP (1 января 1900 г., 00:00 UTC). Поле Fraction указывает доли секуды в единицах 1/(2³²) секунды (приблизительно 233 пикосекунды). Значение может представлять даты от 1 января 1900 г. до 8 февраля 2036 г. в текущей эре NTP (см. параграф 5.2. Поддержка перехода временных меток через максимум).

Отметим, что типы dateTimeMicroseconds и dateTimeNanoseconds используют идентичное кодирование. Тип dateTimeMicroseconds предназначен лишь для представления временных меток с микросекундным разрешением, поэтому младшим 11 битам (2¹¹ x 233 пксек = 0,477 мксек) поля Fraction следует иметь значение 0 и они должны игнорироваться во всех информационных элементах этого типа.

6.1.10. dateTimeNanoseconds

Тип dateTimeNanoseconds выражается 64-битовым полем, кодируемым в соответствии с форматом NTP Timestamp, как указано в разделе 6 [RFC5905]. Это поле состоит из двух 32-битовых целых чисел без знака — Seconds (секунды) и Fraction (доли секунды). Поле Seconds указывает число секунд с начала эпохи NTP (1 января 1900 г., 00:00 UTC). Поле Fraction указывает доли секуды в единицах 1/(2³²) секунды (приблизительно 233 пикосекунды). Значение может представлять даты от 1 января 1900 г. до 8 февраля 2036 г. в текущей эре NTP (см. параграф 5.2. Поддержка перехода временных меток через максимум).

Отметим, что типы dateTimeMicroseconds и dateTimeNanoseconds. Для интерпретации поля Fraction в типе dateTimeNanoseconds ограничений не задано.

6.2. Кодирование с сокращённым размером

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

Например, информационная модель задаёт octetDeltaCount как тип unsigned64, для которого нужно 64 бита, однако экспортёр, который никогда не передаёт значения больше 4294967295, может выбрать представление unsigned32.

Такое поведение экспортёр указывает заданием в Template размера, который меньше, чем заданный для типа информационного элемента. В приведённом примере экспортёр будет указывать в шаблоне размер 4 вместо 8.

Кодирование с сокращённым размером можно применять для типов unsigned64, signed64, unsigned32, signed32, unsigned16, signed16, при этом должно сохраняться наличие или отсутствие знака. Сокращать размер можно на любое число октетов по сравнению с исходным, пока результат устраивает, т. е. отбрасываются лишь нули в старших битах. Например, unsigned64 можно сократить до 7, 6, 5, 4, 3, 2 или 1 октета.

Кодирование с сокращённым размером можно применять для преобразования float64 в float32. Тип float32 не только имеет меньший размер за счёт сокращения размера мантиссы, но и точность его ниже. После преобразования float64 размер сокращается до 4 октетов.

Сокращение размера недопустимо для других типов из [RFC7012], которые предполагают фиксированный размер, поскольку эти типы имеют внутреннюю структуру (как ipv4Address или dateTimeMicroseconds) или ограниченные диапазоны, которые не подходят для сокращенного размера (например, dateTimeMilliseconds).

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

7. Информационные элементы переменного размера

Механизм IPFIX Template оптимизирован для информационных элементов фиксированного размера [RFC7012]. Для элементов с переменным размером должен использоваться описанный здесь механизм передачи размера для выделенных IANA и фирменных информационных элементов.

В Template Set для Information Element Field Length указывается зарезервированное значение 65535, указывающее процессу сборки, что размер информационного элемента будет указан в самом элементе.

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

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)|          Information Element                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 ... продолжается при необходимости            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок R. Информационный элемент (IE) переменного размера до 255 октетов.

Размер можно указать также 3 октетами перед информационным элементом, что позволяет указывать размеры больше 255 октетов. В этом случае первый октет поля Length должен иметь значение 255, а фактический размер в октетах указывается вторым и третьим октетом, как показано на рисунке S.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      255      |      Length (0 - 65535)       |       IE      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 ... продолжается при необходимости            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок S. Информационный элемент (IE) переменного размера до 65535 октетов.

Октеты размера (1 или 3 октета в начале) недопустимо учитывать в поле размера информационного элемента.

8. Управление шаблонами

В этом разделе описано управление шаблонами Template и Options Template в процессах экспорта и сбора. Цель управления шаблонами состоит в обеспечении, насколько это возможно, наличия у процессов экспорта и сбора согласованного представления о шаблонах Template и Options Template, применяемых для кодирования идекодирования записей в процессах экспорта и сбора. Достижение этой цели сложняется двумя факторами — 1) необходимость поддержки неоднократного использования Template ID в транспортной сессии и 2) необходимость поддержки передачи шаблонов без гарантии доставки при использовании UDP для доставки сообщений IPFIX.

Заданные здесь механизмы управления шаблонами применимы для экспорта сообщений IPFIX в SCTP, TCP или UDP. Дополнительное рассмотрение для протоколов SCTP и UDP приведено в параграфах 8.3 и 8.4, соответственно.

Процесс экспорта назначает и поддерживает значения Template ID на уровне транспортной сессии и домена наблюдений. Созданной заново Template Record процесс экспорта назначает свободное значение Template ID. Процесс сбора должен сохранять всю принятую информацию о Template Record на протяжении каждой транспортной сессии, пока она не будет использована снова или отозвана, как описано в парагафе 8.1, или завершится срок действия при использовании UDP, как указано в параграфе 8.4, чтобы иметь возможность интерпретировать соответствующие записи Data Record.

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

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

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

Процессу экспорта следует передавать Template Set и Options Template Set до любого Data Sets, использующего этот (Options) Template ID, чтобы обеспечить сборщику наличие Template Record до получения первой Data Record. Записи Data Record, соответствующие Template Record могут помещаться в те же и/или последующие сообщения IPFIX. Однако процессу сбора недопустимо предполагать, что Data Set и сответствующий Template Set (Options Template Set) экспортируется в том же сообщении IPFIX.

Хотя Collecting Process обычно получает записи Template Record от процесса экспорта до получения Data Record, это бывает не всегда, например, в результате нарушения порядка или при перезапуске Collecting Process по протоколу UDP. В таких случаях Collecting Process может буферизовать записи Data Record, для которых у него нет шаблонов, в ожидании описывающих их записей Template Record. Однако следует отметить, что при наличии отзыва или переопределения шаблона (8.1. Отзыв и переопределение шаблонов) это может приводить к некорректной интерпретации записей Data Record.

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

Шаблоны Options Template и Template, относящиеся к взаимозависимым записям (например, с общими свойствами, как описано в [RFC5473]), следует передавать в одном сообщении IPFIX.

8.1. Отзыв и переопределение шаблонов

Шаблоны, которые Exporting Process больше не будет применять, можно отозвать с помощью Template Withdrawal. После получения Template Withdrawal процесс сбора должен прекратить использование шаблона при интерпретации последующих Data Set. Отметим, что этот механизм не применим при использовании для сообщений IPFIX транспорта UDP (см. 8.4. Дополнительные вопросы управления шаблонами для UDP).

Template Withdrawal включает Template Record для отзываемого Template ID с Field Count = 0 (Рисунок T).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Set ID = (2 или 3)      |          Length = 16          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Template ID N        |        Field Count = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Template ID ...      |        Field Count = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Template ID M        |        Field Count = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок T. Формат отзыва шаблона.

Поле Set ID должно иметь значение 2 для Template Set Withdrawal или 3 для Options Template Set Withdrawal. Можно отозвать несколько Template ID в одном Template Withdrawal, в этом случае можно применять заполнение.

Template Withdrawal можно чередовать с Template Set, Options Template Set и Data Set в сообщении IPFIX. В этом случае Template и Template Withdrawal нужно интерпретировать в порядке их размещения в сообщении IPFIX. Процессу экспорта не следует передавать Template Withdrawal, пока не пройдёт время, достаточное для получения и обработки Data Record, описываемых отзываемым шаблоном (см. 8.2. Действия по управлению последовательными шаблонами).

Завершение транспортной сессии неявно отзывает все использованные в этой сессии шаблоны и нужно передать шаблоны снова в последующих сессиях между Exporting Process и Collecting Process. Это применимо только для SCTP и TCP, случай для протокола UDP описан в параграфах 8.4. Дополнительные вопросы управления шаблонами для UDP и 10.3.4. Организация и разрыв сессий.

Для данного домена наблюдения можно отозвать все шаблоны с помощью All Templates Withdrawal, как показано на рисунке U, а Options Template можно отозвать с помощью All Options Templates Withdrawal (Рисунок V).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Set ID = 2        |          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Template ID = 2       |        Field Count = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок U. Формат All Templates Withdrawal Set.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Set ID = 3        |          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Template ID = 3       |        Field Count = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок V. Формат Options All Templates Withdrawal Set.

Template ID можно применять снова для новых шаблонов, передавая Template Record или Options Template Record для данного Template ID после отзыва шаблона.

Если Collecting Process получает Template Withdrawal для Template или Options Template, которые на были сохранены, это указывает на ошибку или некорректную реализацию Exporting Process. Получение и обработка Data Record остаются возможными, но процесс сбора должен игнорировать Template Withdrawal, а ошибку следует записать.

Если Collecting Process получает новую запись Template Record или Options Template для уже выделенного Template ID и этот Template или Options Template идентичен уже полученному, следует записать в журнал повторную передачу — это не ошибка и не влияет на интерпретацию записей Data Record.

Если Collecting Process получает новую запись Template или Options Template для уже выделенного Template ID и Template или Options Template отличается от уже имеющегося, это указывает на ошибку или некорректную реализацию Exporting Process. Продолжение приёма и однозначной интерпретации Data Record для этого Template ID больше не возможны и процессу сбора следует записать ошибку. Дальнейшие действия Collecting выходят за рамки допумента.

8.2. Действия по управлению последовательными шаблонами

Поскольку нет гарантий упорядоченной доставки сообщений IPFIX через потоки SCTP или по протоколу UDP, процесс экспорта должен упорядочивать все действия по управлению шаблонами (т. е. обработку Template для новых шаблонов и Template Withdrawal для отзыва) с использованием поля Export Time в заголовке сообщения IPFIX.

Процессу экспорта недопустимо экспортировать Data Set, описанный новым шаблоном, в сообщении IPFIX с Export Time до Export Time в заголовке сообщения IPFIX с этим шаблоном. Если новый шаблон или описываемый им Data Set присутствует в том же сообщении IPFIX, Template Set с шаблоном должен размещаться в сообщении до Data Set.

Процессу экспорта недопустимо экспортировать Data Set, описываемые отозванным шаблоном в сообщениях IPFIX с Export Time после Export Time сообщения IPFIX с Template Withdrawal для этого шаблона.

Иными словами, шаблон описывает записи Data Record, содержащиеся в сообщениях IPFIX, когда Export Time в этих сообщениях находится в интервале между конкретным временем начала и завершения (включительно). Время старта — это Export Time в сообщении IPFIX Message с Template Record, а время завершения может быть одним из двух — если шаблон отозван во время сессии, — это Export Time сообщения IPFIX с Template Withdrawal для шаблона, в иных случаях — это завершение транспортной сессии.

Даже при упорядоченной передаче сообщения IPFIX с действиями по управлению шаблонами могут приходить в процесс сбора с нарушением порядка, например, при передаче по UDP или в разных потоках SCTP. С учётом этого Template Withdrawal и последующее повтороное использование Template ID могут значительно усложнить проблему определения срока действия шаблона в Collecting Process. Процесс сбора может реализовать буфер и использовать Export Time для устранения неоднозначности порядка действий по управлению шаблонами. Приреализации такого буфера его следует делать настраиваемым для обеспечения задержки порядка максимальной задержки из-за переупорядочения, возникающей в процессе сбора. Отметим для этого случая, что время (часы) Collecting Process не имеет значения, поскольку сравниваются лишь значения Export Time в сообщениях.

8.3. Дополнительные вопросы управления шаблонами для SCTP

Этот параграф применим только к SCTP и при возникновении противоречий с разделом 8 или параграфом 8.1, сведения, приведённые здесь, имеют более высокий приоритет.

Template Set и Options Template Set можно передавать в любом потоке SCTP. Data Set, переданные в данном потоке SCTP Stream могут быть представлены записями Template Record экспортированными в любом потоке SCTP.

Template Set и Options Template Set должны передаваться надёжно с использованием упорядоченной доставки SCTP.

Template Withdrawal можно передавать в любом потоке SCTP и они должны передаваться надёжно с использованием упорядоченной доставки SCTP. Template ID можно применять снова путём передачи Template Withdrawal и/или новой Template Record в потоке SCTP, отличном от того, где был передан исходный шаблон.

Дополнительные вопросы управления шаблонами рассмотрены в [RFC6526], где задано расширения для явных шаблонов каналов с потоками SCTP. В обмен на более строгие правила назначения Template Record потокам SCTP это расширение позволяет быстро и надёжно применять повторные Template ID и определять потерю Data Record на уровне шаблона.

8.4. Дополнительные вопросы управления шаблонами для UDP

Этот параграф применим только к UDP и при возникновении противоречий с разделом 8 или параграфом 8.1, сведения, приведённые здесь, имеют более высокий приоритет.

Поскольку UDP не имеет метода надёжной передачи шаблонов, процессы экспорта, применяющие транспорт UDP, должны повторять передачу каждого активного шаблона с регулярными интервалами. Интервал повтора должен быть настраиваемым, например, через параметры templateRefreshTimeout и optionsTemplateRefreshTimeout, как указано в [RFC6728]. Принятые по умолчанию значения этих параметров зависят от реализации и развёртывания.

Перед экспортом любой записи Data Record, описываемой данной Template Record или Options Template Record, особенно в случае повтрного использования Template ID, как описано в параграфе 8.1, процессу экспорта следует передать несколько копий Template Record в отдельных сообщениях IPFIX, чтобы помочь в их гарантированном получении процессом сбора.

Для снижения расхода ресурсов на шаблоны, которые Exporting Process уже не использует, процесс сбора может задать срок действия каждого шаблона, полученного в транспортной сессии. Если Exporting Process не обновит шаблон в течение этого срока, процесс сбора может отбросить шаблон. Срок действия шаблона в Collecting Process можно задать параметром конфигурации или вывести из интервала периодического повтора передачи шаблонов от процесса экспорта. Во втором случае срок действия по умолчанию следует делать не меньше 3-кратного интервала повтора.

Процессу экспорта недопустимо передавать Template Withdrawal (параграф 8.1) по UDP, а процесс сбора должен игнорировать такой отзыв, полученный по UDP. Template ID могут повторно использоваться процессом экспорта путём экспорта нового шаблона с Template ID не раньше завершение 3-кратного интервала повтора передачи, иначе повторное использование Template ID может вести к некорректной интерпретации Data Record.

При получении процессом сбора новой Template Record или Options Template Record по UDP для уже выделенного Template ID с Template или Options Template идентичным уже полученному, не следует записывать повтор в системный журнал, поскольку это обычная операция обновления шаблона по протоколу UDP.

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

Поскольку Template ID в каждый момент уникальны для сессии UDP и домена наблюдения, процессу сбора следует поддерживать для всех текущих Template Record и Options Template Record набор сведений <устройство IPFIX, порт отправителя UDP у экспортера, IP-адрес сборщика, порт получателя UDP у сборщика, Observation Domain ID, Template ID, определение шаблона, время последнего получения>.

9. Коллектор

Здесь описана обработка протокола IPFIX в процессе сбора, общая для всех транспортных протоколов. Дополнительное рассмотрение для SCTP и UDP приведено в параграфах 9.2 и 9.3, соответственно. Управление шаблонами в процессе сбора рассмотрено в разделе 8.

Collecting Process должен слушать запросы от Exporting Process на организацию соединений (ассоциаций) для запуска новой транспортной сессии.

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

Процесс сбора должен воспринимать заполнение в Data Record и Template Record. Размер заполнения определяет разность Set Length и Set Header (4 октета для Set ID и Set Length) по модулю минимального размера записи, выеденному из Template Record.

Протокол IPFIX имеет поле Sequence Number в заголовке экспорта, которое увеличивается на число IPFIX Data Record в сообщении IPFIX. Сборщик может обнаруживать потерю, нарушение порядка и дубликаты сообщений IPFIX по этим номерам. Сборщику следует поддерживать механизм записи для фактов нарушения порядка сообщений IPFIX. Такое нарушение может возникать при нехватке у экспортёра ресурсов, когда тот не может передать сообщение в момент его создания, перегрузке в сети между экспортером и сборщиком, нехватке ресурсов у сборщика, когда тот не может обработать сообщения IPFIX в момент прибытия, нарушении порядка приема, дублировании пакетов или атаке с внедрением ложных сообщений.

9.1. Обработка процессом сборки сообщений IPFIX с ошибками формата

Если Collecting Process получает сообщение IPFIX с ошибкой формата, он должен отбросить сообщение и следует записать ошибку. Неверно сформированными считаются сообщения IPFIX, которые невозможно интерпретировать из-за бессмысленных значений размера (например, информационный элемент переменного размера превышает размер Set, размер Set больше сообщения IPFIX или сообщение IPFIX короче IPFIX Message Header) или резервного значения Version (это может указывать применение будущей версии IPFIX, но на практике чаще всего связано с передачей процессу сбора данных, не относящихся к IPFIX). Заполнение в Set не нарушает формат сообщения IPFIX.

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

• разрыв соединения TCP или SCTP;

• использование окна получателя для снижения нагрузки на сеть от плохо работающего процесса экспорта;

• буферизацию и сохранение некорректных сообщений IPFIX для последующей диагностики;

• попытки ресинхронизировать поток, например, как описано в параграфе 10.3 [RFC5655].

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

9.2. Процесс сбора по протоколу SCTP

Exporting Process может запрашивать и поддерживать несколько потоков в ассоциации SCTP, а процесс сбора должен поддерживать создание множества потоков SCTP.

9.3. Процесс сбора по протоколу UDP

Транспортная сессия для сообщений IPFIX по протоколу UDP определяется с точки зрения процесса экспорта и примерно соответствует времени, в течение которого данный Exporting Process передаёт сообщения IPFIX через UDP данному процессу сбора. Поскольку это сложно обнаружить в процессе сбора, тот может отбросить всё состояние транспортной сессии при отсутствии сообщений IPFIX от данного Exporting Process в данной транспортной сессии в течение настраиваемого интервала бездействия.

Процессу сбора следует воспринимать Data Record без связанной Template Record (или других определений, таких как общие свойства), требуемой для декодирования Data Record. Если записи Template Record или иные определения не были получены к моменту приёма Data Record, процесс сбора может на короткое время сохранить Data Record и декодировать их по получении Template Record или иных определений, сравнивая Export Time в сообщениях IPFIX, содержащих Template Record, с временем в сообщениях с Data Record, как указано в параграфе 8.2. Отметим, что этот механизм может вести к некорректной интерпретации записей в случае повторного использования Template ID или иных идентификаторов с ограниченным сроком действия.

10. Транспортный протокол

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

16-битовое поле Length в IPFIX Message Header ограничивает размер сообщений IPFIX до 65535 октетов, включая заголовок. Процесс сбора должен поддерживать обработку сообщений IPFIX размером до 65535 октетов.

Хотя процессы экспорта и сбора могут поддерживать несколько транспортных протоколов, транспортные сессии привязаны к одному протоколу. Процессу экспорта или сбора недопустимо переносить состояние транспортной сессии между сессиями, использующими разный транспорт для одной пары Exporting Process и Collecting Process. Иными словами, Exporting Process (или Collecting Process) с поддержкой нескольких транспортных протоколов концептуально является несколькими процессами экспорта (сбора), по одному на протокол.

10.1. Соответствие транспорту и применение транспорта

Для соответствия спецификации должна быть реализована поддержка SCTP [RFC4960] с расширением Partially Reliable SCTP (PR-SCTP), заданным в [RFC3758]. Можно также реализовать поддержку UDP [UDP] и/или TCP [TCP].

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

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

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

По умолчанию Collecting Process слушает соединения SCTP, TCP, UDP на порту 4739 и защищённые соединения SCTP, TCP, UDP — на порту 4740 (см. 11. Вопросы безопасности). Exporting Process по умолчанию пытается соединиться с одним из этих портов. Должна обеспечиваться возможность настройки экспортёра и сборщика на работу через другой порт.

10.2. SCTP

Ниже описана работа IPFIX по протоколу SCTP [RFC4960] с расширением PR-SCTP [RFC3758].

10.2.1. Предотвращение перегрузок

SCTP обеспечивает требуемый уровень предотвращения перегрузок по своему устройству. SCTP детектирует перегрузку на сквозном пути между IPFIX Exporting Process и IPFIX Collecting Process, ограничивая соответственно скорость передачи. Когда у IPFIX Exporting Process есть записи для экспорта, но обнаружена временная невозможность передачи по SCTP, экспортёр может подождать некоторое время до повтора передачи или отбросить запись. В последнем случае отброшенные данные экспорта следует учитывать, чтобы можно было указать объем отброшенных данных с использованием механизма, описанного в параграфе 4.3.

10.2.2. Надёжность

Транспортный протокол SCTP надёжен по определению, но может доставлять сообщения с частичной надёжностью [RFC3758].

Применение надёжной передачи SCTP для экспорта IPFIX само по себе не гарантирует доставки всех записей Data Record. Если на канале между процессами экспорта и сбора возникает перегрузка или требуется значительное число повторов передачи, выходные очереди в процессе экспорта могут заполниться и Exporting Process может приостановить, экспортировать или отбросить сообщения IPFIX. Если записи Data Record отбрасываются, потеря данных должна быть отражена в IPFIX Sequence Number.

10.2.3. MTU

SCTP обеспечивает требуемую для сообщений IPFIX фрагментацию на основе определения Path MTU (PMTU).

10.2.4. Организация и разрыв ассоциаций

Процесс экспорта IPFIX инициирует ассоциацию SCTP с IPFIX Collecting Process. Exporting Process может организовать более одной ассоциации (bundle в терминах SCTP) с процессом сбора.

Exporting Process может поддерживать более 1 ассоциации с разными процессами сбора (возможно, на одном хосте).

При отключении процесса экспорта (shut down), ему следует прервать (shut down) ассоциации SCTP.

Если Collecting Process больше не ждёт сообщений IPFIX, ему следует отключить (shut down) свою сторону ассоциации. Процессу сбора следует принимать и обрабатывать сообщения IPFIX, пока Exporting Process не закроет ассоциацию на своей стороне.

Если Collecting Process обнаруживает аномально прерванную ассоциацию SCTP, он должен продолжать прослушивание на предмет создания новой ассоциации.

Если Exporting Process обнаруживает аномально прерванную ассоциацию SCTP с процессом сбора, ему следует попытаться восстановить её.

Тайм-ауты для ассоциаций следует делать настраиваемыми.

10.2.5. Восстановление при отказах

Если Collecting Process не подтверждает попытку процесса экспорта создать ассоциацию, SCTP будет пытаться автоматически создать её, экспоненциально увеличивая интервал повтора. Экспортёр может сделать запись в журнале при возникновении тайм-аута SCTP. Значение тайм-аута следует делать настраиваемым для экспортёра.

Exporting Process может создать резервную (backup) ассоциацию SCTP с процессом сбора, если на том поддерживается восстановление при отказах.

10.2.6. Потоки

Exporting Process может запросить более 1 SCTP Stream на ассоциацию и каждый из этих потоков может служить для передачи сообщений IPFIX, содержащих Data Set, Template Set, Options Template Set. В зависимости от требований приложения Exporting Process может передавать Data Set с полной или частичной надёжностью, используя упорядоченную или неупорядоченную доставку в любом потоке SCTP, организованном при создании ассоциации SCTP.

IPFIX Exporting Process может использовать определение сервиса PR-SCTP в соответствии с разделом 4 [RFC3758] для поддержки частичной надёжности передачи сообщений IPFIX, содержащих лишь Data Set. Однако процессу экспорта следует помечать такие сообщения для повтора передачи, пока позволяют ресурсы и иные ограничения.

10.3. UDP

Ниже описана работа IPFIX по протоколу UDP [UDP].

10.3.1. Предотвращение перегрузок

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

10.3.2. Надёжность

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

Процессу сбора следует выявлять потери и переупорядочение записей IPFIX Data Record по разрывам в порядковых номерах IPFIX. В случае UDP порядковый номер IPFIX содержит общее число (по модуля 2³²) IPFIX Data Record, переданных в транспортной сессии до получения этого сообщения IPFIX. Сборщику следует контролировать нарушение порядка, потерю и дублирование сообщений IPFIX, отслеживая значения Sequence Number.

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

10.3.3. MTU

Максимальный размер экспортируемых сообщений должен быть настраиваемым, чтобы общий размер пакетов не превышал PMTU. Если значение PMTU не известно, следует задавать максимальный размер пакета в 512 октетов.

10.3.4. Организация и разрыв сессий

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

10.3.5. Восстановление при отказах и дублирование сессий

Поскольку UDP не использует явных соединений, процесс экспорта не может узнать у транспортного протокола о том, что Collecting Process больше не может принимать сообщения IPFIX, поэтому невозможно вызвать механизм восстановления. Однако Exporting Process может дублировать сообщение IPFIX нескольким процессам сбора.

10.4. TCP

Ниже описана работа IPFIX по протоколу TCP [TCP].

10.4.1. Предотвращение перегрузок

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

Когда у Exporting Process имеются записи Data Record для экспорта, но буфер передачи заполнен и экспортёр хочет избежать блокировки, он может принять решение об отбрасывании некоторых Data Record. Отброшенные записи должны учитываться, чтобы их номера можно было потом указать в отчёте, как описано в параграфе 4.3.

10.4.2. Надёжность

TCP обеспечивает надёжную доставку от процесса экспорта в процесс сбора.

10.4.3. MTU

TCP предоставляет потоковые услуги, а не дейтаграммы или пакетный сервис. Сообщения IPFIX при передаче по TCP разделяются по значению поля Length в заголовке сообщения IPFIX. Exporting Process может выбрать любой дозволенный размер для сообщения IPFIX, поскольку TCP выполняет сегментацию.

Exporting Process может выбирать размер сообщений IPFIX меньше разрешённого максимум для своевременного экспорта записей Data Record.

10.4.4. Организация и разрыв соединений

IPFIX Exporting Process инициирует соединение TCP с процессом сбора. Exporting Process может поддерживать более 1 активного соединения с разными процессами сбора (возможно, на одном хосте). Exporting Process может поддерживать более 1 активного соединения с одним процессом сбора для предотвращения блокировки head-of-line в доменах наблюдения.

Экспортёр может записывать в системный журнал случаи тайм-аута при организации соединения TCP. Значение тайм-аута следует делать настраиваемым для экспортёра.

При выключении Exporting Process (shut down), процессу экспорта следует разорвать (shut down) соединение TCP.

Когда Collecting Process больше не ждёт сообщения IPFIX, ему следует завершить соединение. Процессу сбора следует продолжать чтение сообщений IPFIX Message, пока Exporting Process не закроет свою сторону.

Если Collecting Process обнаруживает, что соединение TCP с Exporting Process разорвано аварийно, он должен продолжать прослушивание новых соединений.

Если Exporting Process обнаруживает, что соединение TCP с Collecting Process прервано аварийно, ему следует пытаться восстановить соединение. Число попыток и тайм-аут для восстановления следует делать настраиваемыми. В принятой по умолчанию конфигурации процессу экспорта недопустимо пытаться восстанавливать соединение чаще 1 раза в минуту.

10.4.5. Восстановление при отказах

Если Collecting Process не подтверждает попытку процесса экспорта создать соединение, TCP будет пытаться автоматически организовать его, экспоненциально увеличивая интервал повтора. Экспортёр может сделать запись в журнале при возникновении тайм-аута TCP. Значение тайм-аута следует делать настраиваемым для экспортёра.

Exporting Process может создать резервное (backup) соединение TCP с процессом сбора, если на том поддерживается восстановление при отказах.

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

Соображения по безопасности для протокола IPFIX были получены в результате анализ потенциальных угроз, отмеченных в разделе «Вопросы безопасности» документа с требованиями к IPFIX [RFC3917]. Требования безопасности для IPFIX указаны ниже.

1. Должен обеспечиваться механизм защиты конфиденциальности данных IPFIX, передаваемых процессом экспорта процессу сбора, для предотвращения раскрытия записей Flow Record, передаваемых через IPFIX.

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

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

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

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

Сообщения IPFIX могут содержать сведения, представляющие ценность для злоумышленника, включая данные конфигурации сети, а также трафик конечных пользователей и содержимое пакетов, поэтому должны приниматься меры по ограничению доступа. Когда информационный элемент включает пользовательские данные (payload), его следует передавать процессу сбора с применением защиты от перехвата. Подходящие для этого меры включают прямые соединения «точка-точка», недоступные для атакующих, или использование шифрования. Collecting Process отвечает за обеспечение удовлетворительного уровня защиты собираемых данных, включая при необходимости шифрование и/или обезличивание данных в отчётах (см. 11.8. Вопросы приватности собранных данных).

11.1. Применимость TLS и DTLS

Протоколы защиты на транспортном уровне TLS (Transport Layer Security) [RFC5246] и DTLS (Datagram Transport Layer Security) [RFC6347] разработаны для защиты конфиденциальности и целостности, а также проверки подлинности, требуемых протоколу IPFIX, без необходимости использования заранее распределенных ключей.

Процессы экспорта и сбора IPFIX, использующие TCP, должны поддерживать TLS версии 1.1 и следует поддерживать TLS версии 1.2 [RFC5246], включая обязательные для каждой версии шифры. Процессы экспорта и сбора IPFIX, использующие UDP или SCTP, должны поддерживать DTLS версии 1.0 и следует поддерживать DTLS версии 1.2 [RFC6347], включая обязательные для каждой версии шифры³.

Отметим, что DTLS выбран механизмом защиты для SCTP. Хотя привязка TLS для SCTP определена в [RFC3436], она требует, чтобы все взаимодействия выполнялись через надёжные двухсторонние потоки, а также требует одно соединение TLS на поток, что несовместимо с обоснованием выбора SCTP в качестве транспортного протокола IPFIX.

Отметим, что при использовании DTLS имеется уязвимость MITM (man-in-the-middle), которой нет в TLS, позволяющая незаметно для отправителя и получателя удалять сообщения из потока. Кроме того, при использовании DTLS с SCTP атакующий может внедрять данные управления SCTP и отключать (shut down) ассоциации SCTP, вызывая потерю сообщений IPFIX, если они буферизованы вне ассоциации SCTP. Методы преодоления этих уязвимостей описаны в [RFC6083].

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

При использовании DTLS с SCTP или UDP следует применять расширение Heartbeat [RFC6520], особенно в долгосрочных транспортных сессиях, для сохранения статуса активности сессии.

Процессам экспорта и сбора недопустимо запрашивать, предлагать или применять любую версию уровня защищённого сокета (Secure Socket Layer или SSL), а также версии TLS до 1.1 по причине уязвимостей в ранних версиях TLS (см. Приложение E в [RFC5246]).

11.2. Применение

IPFIX Exporting Process инициирует связь с IPFIX Collecting Process и действует как клиент TLS или DTLS в соответствии с [RFC5246] и [RFC6347], а IPFIX Collecting Process выступает как сервер TLS или DTLS. Клиент DTLS создаёт защищённое соединение SCTP с портом 4740 сервера DTLS при использовании транспорта SCTP, с портом TCP 4740 сервера TLS при использовании транспорта TCP и с портом UDP 4740 сервера DTLS для транспорта UDP.

11.3. Взаимная проверка подлинности

При использовании TLS или DTLS процессы экспорта и сбора IPFIX следует идентифицировать по сертификатам с DNS-ID, как описано в параграфе 6.4 [RFC6125], включение Common Name (CN-ID) в сертификаты, указывающие процессы экспорта и сбора IPFIX, не рекомендуется.

Для предотвращения MITM-атак со стороны самозванных процессов экспорта или сбора (восприятие или экспорт данных неуполномоченной стороны) должна применяться взаимная аутентификация при использовании TLS и DTLS. Процессы экспорта должны сверять ссылочные идентификаторы процессов сбора, которым они экспортируют сообщения IPFIX, а процессы сбора должны сверять ссылочные идентификаторы процессов экспорта, от которых они получают сообщения IPFIX, с сохранёнными сертификатами. Процессу экспорта недопустимо экспортировать данные в непроверенные Collecting Process, а процессам сбора недопустимо воспринимать сообщения IPFIX от непроверенных Exporting Process.

Процессы экспорта и сбора должны поддерживать проверку сертификатов по явно уполномоченному списку партнёров, указанных Common Name, и следует поддерживать проверку ссылочных идентификаторов на соответствие DNS-ID или CN-ID с поиском партнёра через DNS (lookup).

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

11.4. Защита от DoS-атак

Злоумышленник может организовать атаку на службы (denial-of-service или DoS) системы IPFIX напрямую, отправляя большой объём трафика процессам сбора или опосредованно, создавая большой объем измеряемого трафика.

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

SCTP поддерживает механизм обмена cookie, предназначенный для защиты от истощения состояний SCTP при DoS-атаках. В TCP имеется механизм SYN cookie для смягчения таких атак, который следует применять всем процессам сбора, воспринимающим соединения TCP. В DTLS также имеется механизм cookie для защиты от истощения состояний серверов DTLS.

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

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

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

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

11.5. Когда DTLS или TLS не подходит

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

Современные реализации TCP и SCTP устойчивы к атакам со вставкой вслепую (см. [RFC4960] и [RFC6528]), однако в UDP такой защиты нет. По этой причине доставка сообщений IPFIX по протоколу UDP без DTLS не защищена и такой трафик следует выносить в отдельную сеть.

11.6. Запись атак на IPFIX

Процессы сбора IPFIX должны обнаруживать возможную потерю и вставку сообщений IPFIX, отслеживая IPFIX, и следует поддерживать механизм записи для указания в отчёте нарушивших порядок сообщений. Отметим, что атакующий может воспользоваться обработкой переупорядоченных соединений в процессе сбора, поэтому следует соблюдать осторожность при такой обработке. Например, Collecting Process, просто сбрасывающий ожидаемый порядковый номер при получении большего Sequence Number, может быть временно «ослеплен» преднамеренной вставкой больших порядковых номеров.

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

Процессам экспорта и сбора IPFIX следует обнаруживать и записывать любые попытки сброса ассоциации SCTP или соединения TCP.

11.7. Защита коллектора

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

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

Разработчикам сборщиков следует уделять особое внимание кодировке UTF-8 в данных типа string, поскольку интерпретация UTF-8 с некорректным форматом может вести к уязвимости (см. 6.1.6. string и octetArray).

11.8. Вопросы приватности собранных данных

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

12. Вопросы управления

В [RFC6615] задан модуль MIB, определяющий управляемые объекты для мониторинга устройств IPFIX, включая базовую конфигурацию. Эта база MIB может служить для измерения влияния экспорта IPFIX на контролируемую сеть и включает таблицы, охватывающие транспортные сессии, определение кэша, точки наблюдения, Template и Options Template, свойства экспорта (восстановление, балансировка, дубликаты) и статистику экспорта по процессам, сессиям и шаблонам.

С точки зрения эксплуатации важная функция этого модуля обеспечивается таблицей Transport Session Statistical, указывающей скорость (байт/сек), с которой коллектор получает сообщения IPFIX, переданные экспортером. Особый интерес представляет таблица Transport Session Statistical из параграфа 5.8.1 этого модуля MIB, раскрывающая скорость сбора или экспорта сообщений IPFIX, которая позволяет измерить полосу для экспорта IPFIX.

В [RFC6727] описаны расширения модуля IPFIX-SELECTOR-MIB, заданного в [RFC6615], и указаны управляемые объекты для предоставления сведений о применяемых функциях отбора пакетов и их параметрах (фильтрация и выборка).

Поскольку IPFIX-SELECTOR-MIB [RFC6615] и PSAMP-MIB [RFC6727] содержат объекты, доступные лишь для чтения, они не подходят для настройки устройств IPFIX. В [RFC6728] задана модель данных конфигурации для протоколов IPFIX и PSAMP, использующая протокол настройки сети (Network Configuration Protocol или NETCONF). Эта модель охватывает процессы выбора, кэширование, а также процессы экспорта и сбора в устройствах IPFIX и PSAMP и описана диаграммами классов унифицированного языка моделирования UML (Unified Modeling Language), а также задана формально с помощью YANG. Данные конфигурации представлены на расширяемом языке разметки (Extensible Markup Language или XML).

Несколько механизмов, заданных с протоколом IPFIX могут помочь в отслеживании и сокращении полосу, используемой для экспорта IPFIX:

• метод экономии пропускной способности при экспорте избыточной информации в IPFIX [RFC5473];

• эффективный метод для экспорта двухсторонних потоков [RFC5103];

• метод определения и экспорта комплексных структур данных [RFC6313].

Кроме того, можно применять PSAMP [RFC5474] для экспорта пакетов, собранных статистическими и иными методами, которые могут быть применимы для многих областей мониторинга, где подходит и IPFIX. PSAMP также обеспечивает контроль влияния на измеряемую сеть через скорость выборки. Набор методов отбора пакетов (выборка, фильтрация, обработка), стандартизованных в PSAMP, описан в [RFC5475]. PSAMP также задаёт явно определяемый предел скорости экспорта в параграфе 8.4 [RFC5474].

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

Агентство IANA обновило реестр IPFIX Information Elements [IANA-IPFIX], заменив все ссылки на RFC 5101 ссылками на данный документ.

Сообщения IPFIX включают два поля с выделяемыми значениями. Это IPFIX Version Number с номером версии протокола IPFIX, который применяется при экспорте сообщений IPFIX, и поле IPFIX Set ID, указывающее тип каждого набора информации в сообщении IPFIX.

Информационные элементы, применяемые в IPFIX и субреестры значений информационных элементов управляются IANA [IANA-IPFIX], как и Private Enterprise Number, используемые в фирменных информационных элементах [IANA-PEN]. Данный документ не меняет эти реестры.

Значение IPFIX Version Number = 0x000a (10) зарезервировано для протокола IPFIX, заданного этим документом. Значения 0 и 1 для Set ID не используются по историческим причинам [RFC3954]. Значение Set ID = 2 зарезервировано для Template Set, Set ID = 3 — для Options Template Set. Остальные значения Set ID (4 — 255) зарезервированы на будущее. Значения Set ID > 255 применяются для Data Set.

Новые значения в реестрах IPFIX Version Number и IPFIX Set IDs выделяются по процедуре Standards Action [RFC5226], т. е. требуется документ RFC категории Standards Track, одобренный IESG.

Приложение A. Примеры кодирования IPFIX

В этом ненормативном приложении представлены примеры кодирования IPFIX.

Рассмотрим пример сообщения IPFIX, содержащего Template Set, Data Set (3 Data Record), Options Template Set и ещё Data Set (2 Data Record, связанные с предшествующим Options Template Record). Сообщение IPFIX будет иметь вид

+--------+------------------------------------------. . .
|        | +--------------+ +------------------+
|Message | | Template     | | Data             |
| Header | | Set          | | Set              |   . . .
|        | | (1 Template) | | (3 Data Record)  |
|        | +--------------+ +------------------+
+--------+------------------------------------------. . .

     . . .-------------------------------------------+
           +------------------+ +------------------+ |
           | Options          | | Data             | |
    . . .  | Template Set     | | Set              | |
           | (1 Template)     | | (2 Data Record)  | |
           +------------------+ +------------------+ |
     . . .-------------------------------------------+

A.1. Пример заголовка сообщения

 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 = 0x000a          |         Length = 152          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Export Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Observation Domain ID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2. Примеры Template Set

A.2.1. Template Set с информационными элементами IANA

Нужно передать в отчёте перечисленные ниже информационные элементы.

• Адрес отправителя IPv4: sourceIPv4Address [IANA-IPFIX] размером 4 октета.
• Адрес получателя IPv4: sourceIPv4Address [IANA-IPFIX] размером 4 октета.
• Адрес next-hop (IPv4): ipNextHopIPv4Address [IANA-IPFIX] размером 4 октета.
• Число пакетов в потоке: packetDeltaCount [IANA-IPFIX] размером 4 октета.
• Число октетов в потоке: octetDeltaCount [IANA-IPFIX] размером 4 октета.

Template Set будет иметь вид

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 2            |      Length = 28 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 256         |       Field Count = 5         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    packetDeltaCount = 2     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    octetDeltaCount = 1      |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.2. Template Set с фирменными информационными элементами

Нужно передать в отчёте перечисленные ниже информационные элементы.

• Адрес отправителя IPv4: sourceIPv4Address [IANA-IPFIX] размером 4 октета.
• Адрес получателя IPv4: sourceIPv4Address [IANA-IPFIX] размером 4 октета.
• Фирменный Information Element с фирменными сведениями типа 15 и размером 4 октета
• Число пакетов в потоке: packetDeltaCount [IANA-IPFIX] размером 4 октета.
• Число октетов в потоке: octetDeltaCount [IANA-IPFIX] размером 4 октета.

Template Set будет иметь вид

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 2            |      Length = 32 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 257         |       Field Count = 5         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. = 15|       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Enterprise number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    packetDeltaCount = 2     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    octetDeltaCount = 1      |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3. Пример Data Set

В этом примере отчёт содержит три записи Flow Record, как показано в таблице. Дополнение здесь не требуется.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 256         |          Length = 64          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.12                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.254                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.1                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             5009                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            5344385                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.27                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.23                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.2                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              748                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             388934                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.56                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.65                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.3                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               5                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              6534                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4. Примеры Options Template Set

A.4.1. Пример Options Template Set с информационными элементами IANA

На уровне линейной платы (в маршрутизаторе с 2 платами) передаются указанные ниже информационные элементы.

• Общее число сообщений IPFIX: exportedMessageTotalCount [IANA-IPFIX] размером 2 октета.
• Общее число экспортируемых потоков: exportedFlowRecordTotalCount [IANA-IPFIX] размером 2 октета.

Линейная плата представлена элементом lineCardId [IANA-IPFIX] в поле Scope. Options Template Set имеет вид

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 3            |          Length = 24          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 258         |        Field Count = 3        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |0|     lineCardId = 141        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Scope 1 Field Length = 4    |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 2        |           Padding             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.2. Options Template Set с фирменными информационными элементами

На уровне линейной платы (в маршрутизаторе с 2 платами) передаются указанные ниже информационные элементы.

• Общее число сообщений IPFIX: exportedMessageTotalCount [IANA-IPFIX] размером 2 октета.
• Зависящее от предприятия число экспортируемых потоков с типом 42 и размером 4 октета.

Линейная плата представлена элементом lineCardId [IANA-IPFIX] в поле Scope. Options Template Set имеет вид

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 3            |          Length = 28          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 259         |        Field Count = 3        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |0|     lineCardId = 141        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Scope 1 Field Length = 4    |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 2        |1|Information Element id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |       Enterprise number     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...      Enterprise number      |           Padding             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.3. Options Template Set с фирменным полем Scope

В этом примере нужно экспортировать те же сведения, что и в примере приложения A.4.1

• Общее число сообщений IPFIX: exportedMessageTotalCount [IANA-IPFIX] размером 2 октета.
• Общее число экспортируемых потоков: exportedFlowRecordTotalCount [IANA-IPFIX] размером 2 октета.

На этот раз данные относятся к фирменной области действия, указанной фирменным информационным элементом с номером 123. Options Template Set имеет вид

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 3            |          Length = 28          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 260         |        Field Count = 3        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |1|Scope 1 Infor. El. id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Scope 1 Field Length = 4   |       Enterprise Number     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...       Enterprise Number     |0|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 2        |           Padding             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.4. Data Set с фирменным полем Scope

В этом примере передаются две записи Data Record.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Set ID = 260             |         Length = 20           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               1                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             345               |            10201              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               2                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             690               |            20402              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5. Примеры информационных элементов переменного размера

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       5       |        5-октетный Information Element         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5.1. Пример информационного элемента переменного размера (< 255 октетов)

A.5.2. Пример элемента переменного размера с 3-октетным кодированием

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      255      |             1000              |    IE ...     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              1000-октетный Information Element                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                              ...                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ... IE            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

[IANA-IPFIX] IANA, «IP Flow Information Export (IPFIX) Entities», <http://www.iana.org/assignments/ipfix/>.

[RFC1014] Sun Microsystems, Inc., «XDR: External Data Representation Standard», RFC 1014, June 1987.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, «Transport Layer Security over Stream Control Transmission Protocol», RFC 3436, December 2002.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, «Stream Control Transmission Protocol (SCTP) Partial Reliability Extension», RFC 3758, May 2004.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, June 2010.

[RFC6125] Saint-Andre, P. and J. Hodges, «Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)», RFC 6125, March 2011.

[RFC6347] Rescorla, E. and N. Modadugu, «Datagram Transport Layer Security Version 1.2», RFC 6347, January 2012.

[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, «Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension», RFC 6520, February 2012.

[RFC7012] Claise, B., Ed., and B. Trammell, Ed., «Information Model for IP Flow Information Export (IPFIX)», RFC 7012, September 2013.

[TCP] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[UDP] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

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

[IEEE.754.2008] Institute of Electrical and Electronics Engineers, «IEEE Standard for Floating-Point Arithmetic», IEEE Standard 754, August 2008.

[IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, «Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators», Work in Progress, July 2013.

[IANA-PEN] IANA, «Private Enterprise Numbers», <http://www.iana.org/assignments/enterprise-numbers/>.

[POSIX.1] IEEE 1003.1-2008, «IEEE Standard for Information Technology — Portable Operating System Interface (POSIX(R))», 2008.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, July 2003.

[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, «Requirements for IP Flow Information Export (IPFIX)», RFC 3917, October 2004.

[RFC3954] Claise, B., Ed., «Cisco Systems NetFlow Services Export Version 9», RFC 3954, October 2004.

[RFC5101] Claise, B., Ed., «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information», RFC 5101, January 2008.

[RFC5103] Trammell, B. and E. Boschi, «Bidirectional Flow Export Using IP Flow Information Export (IPFIX)», RFC 5103, January 2008.

[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, «IP Flow Information Export (IPFIX) Implementation Guidelines», RFC 5153, April 2008.

[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, «Architecture for IP Flow Information Export», RFC 5470, March 2009.

[RFC5471] Schmoll, C., Aitken, P., and B. Claise, «Guidelines for IP Flow Information Export (IPFIX) Testing», RFC 5471, March 2009.

[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, «IP Flow Information Export (IPFIX) Applicability», RFC 5472, March 2009.

[RFC5473] Boschi, E., Mark, L., and B. Claise, «Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports», RFC 5473, March 2009.

[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, «A Framework for Packet Selection and Reporting», RFC 5474, March 2009.

[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, «Sampling and Filtering Techniques for IP Packet Selection», RFC 5475, March 2009.

[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, «Packet Sampling (PSAMP) Protocol Specifications», RFC 5476, March 2009.

[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, «Information Model for Packet Sampling Exports», RFC 5477, March 2009.

[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, «Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements», RFC 5610, July 2009.

[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, «Specification of the IP Flow Information Export (IPFIX) File Format», RFC 5655, October 2009.

[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, «Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)», RFC 6083, January 2011.

[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, «IP Flow Information Export (IPFIX) Mediation: Framework», RFC 6183, April 2011.

[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, «Export of Structured Data in IP Flow Information Export (IPFIX)», RFC 6313, July 2011.

[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, «IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream», RFC 6526, March 2012.

[RFC6528] Gont, F. and S. Bellovin, «Defending against Sequence Number Attacks», RFC 6528, February 2012.

[RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, «Definitions of Managed Objects for IP Flow Information Export», RFC 6615, June 2012.

[RFC6727] Dietz, T., Ed., Claise, B., and J. Quittek, «Definitions of Managed Objects for Packet Sampling», RFC 6727, October 2012.

[RFC6728] Muenz, G., Claise, B., and P. Aitken, «Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols», RFC 6728, October 2012.

[UTF8-EXPLOIT] Davis, M. and M. Suignard, «Unicode Technical Report #36: Unicode Security Considerations», The Unicode Consortium, July 2012.

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

Спасибо Ganesh Sadasivan за существенный вклад на ранних этапах спецификации протокола, Juergen Quittek за координацию между IPFIX и PSAMP, Nevil Brownlee, Dave Plonka и Andrew Johnson за подробные рецензии, Randall Stewart и Peter Lei за их опыт и вклад для SCTP, Martin Djernaes за первый отзыв по разделу SCTP, Michael Behringer и Eric Vyncke за советы и знания в части безопасности, Michael Tuexen за помощь в разделе DTLS, Elisa Boschi за вклад в улучшение раздела SCTP, Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, Sue Hares и многим другим за технические обзоры и отклики. Отдельная благодарность Adrian Farrel за внимание к аспектам управления и эксплуатации.

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

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        Y. Sheffer
Request for Comments: 6989                                      Porticor
Updates: 5996                                                 S. Fluhrer
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                                July 2013

Дополнительные тесты Diffie-Hellman для протокола IKEv2

Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)

PDF

Аннотация

Этот документ добавляет несколько обязательных тестов, требуемых для защищенной работы протокола обмена ключами IKE¹ версии 2 (IKEv2) с группами эллиптических кривых. Не требуется вносить какие-либо изменения в реализации IKE, использующие модульные экспоненциальные группы, отличающиеся от некоторых редко используемых групп DSA². Этот документ служит обновлением спецификации протокола IKEv2, опубликованной в RFC 5996.

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

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

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

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

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

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

IKEv2 [RFC5996] включает организацию общего секрета с использованием протокола Diffie-Hellman (DH) и последующей проверкой подлинности (аутентификацией) двух партнеров. Существующие реализации обычно применяют модульные экспоненциальные (MODP) группы DH, типа определенных в [RFC3526].

IKEv2 не требует выполнения каких-либо тестов партнером, получившим открытый ключ DH от другого партнера. Это очень хорошо для большинства групп MODP. Для других же групп DH, где партнеры неоднократно используют значения DH во множестве сессий IKE, отказ получателя от проверки может создавать потенциальные уязвимости (см. параграф 4.1). В частности, это относится к группам EC⁵, использование которых становится все более популярным. В этом документе определены тесты для нескольких типов групп DH.

В дополнение к этому документ описывает другую возможную атаку, относящуюся к повторному использованию ключей DH — timing attack. Этот дополнительный материал заимствован из [RFC2412].

Данный документ обновляет [RFC5996] за счет добавления требований безопасности, применимых ко многим реализациям протокола.

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

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

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

В этом разделе описаны тесты, которые должны выполняться партнерами IKE при получении элементов данных KE⁶. Проверки рекомендуются для всех реализаций, но требуются только для тех, в которых многократно используются секретные ключи DH (см. определение в [RFC5996], параграф 2.12). Эти тесты относятся к получателям элементов данных KE и описывают как должны выполняться проверка полученных данных. Тесты описаны по группам DH.

2.1. Группы Sophie Germain Prime MODP

Эти группы в настоящее время являются наиболее широко применяемыми. Для всех таких групп значение (p-1)/2 также является простым числом. Приведенная здесь информация относится ко всем таким группам MODP. Каждый получатель должен удостовериться, что открытое значение партнёра r удовлетворяет условию (1 < r < p-1). Как указано в параграфе 2.2 работы [Menezes], после такой проверки еще сохраняется возможность утечки одного бита секретного показателя при многократном использовании ключей DH. Такой размер потенциальной утечки считается несущественным.

Конкретные группы, входящие в это семейство, указаны в разделе 5.

2.2. Группы MODP с малыми подгруппами

В [RFC5114] определены модульные экспоненциальные группы с малыми подгруппами, каждая из которых имеет композит (p-1)/2. В параграфе 2.1 работы [Menezes] описаны некоторые утечки информации в результате атак на малые подгруппы при многократном использовании секретного значения DH.

Такие утечки можно предотвратить, если получатель выполняет проверку открытого значения партнера, однако такая проверка требует ресурсов (приблизительно столько же, сколько экономится за счет многократного использования секретных значений DH). Стандарт NIST ([NIST-800-56A], параграф 5.6.2.4) требует выполнения этой проверки, следовательно при желании соответствовать этому стандарту проверка должна выполняться.

С учетом отмеченного выше реализация IKE должна выбрать один из двух приведенных ниже вариантов.

• Должна проверяться принадлежность открытого значения партнера диапазону (1 < r < p-1) и выполнение условия r^q = 1 mod p (q — размер подгруппы, указанный в определяющем ее документе RFC). После этого можно повторно использовать секретные значения DH. Этот вариант обеспечивает соответствие требованиям [NIST-800-56A].

• Не допускается многократное использование секретных значений DH (т. е., секретное значение DH для каждого обмена DH должно генерироваться из свежего вывода криптографически защищенного генератора случайных чисел) и должна проверяться принадлежность открытого значения партнера диапазону (1 < r < p-1). Этот вариант лучше подходит для тех случаев, когда соответствие [NIST-800-56A] не требуется.

Конкретные группы, входящие в это семейство, указаны в разделе 5.

2.3. Группы эллиптических кривых

IKEv2 может применяться с группами эллиптических кривых, определенных над полем GF(p) [RFC5903] [RFC5114]. Согласно параграфу 2.3 [Menezes], возможна некоторая утечка информации. Принимающая сторона должна убедиться в пригодности открытого ключа своего партнера, т. е. параметры x и y из открытого ключа партнера должны удовлетворять уравнению кривой y² = x³ + ax + b mod p (где для групп 19, 20 и 21 значение a=-3 (mod p), а все остальные значения a, b и p для группы указаны в определяющем группу RFC).

Отметим, что дополнительная проверка того, что значение открытого ключа не является точкой на бесконечности, не требуется, поскольку IKE (см. раздел 7 в [RFC5903]) не позволяет закодировать такое значение.

Конкретные группы, входящие в это семейство, указаны в разделе 5.

2.4. Обновление реализаций

Существующие реализации IKEv2 с группами ECDH⁷ могут быть обновлены для включения описанных здесь тестов, даже если они не применяют многократно ключи DH. Тесты можно рассматривать, как проверку «здравомыслия», позволяющую предотвратить попытки обработки входных данных, которая не предусмотрена реализацией.

Реализации ECDH с возможностью повторного использования ключей DH должны включать описанные выше проверки.

2.5. Поведение протокола

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

Если такая ошибка происходит в процессе обмена IKE_SA_INIT, получатель должен отбросить сообщение с непригодными данными KE и недопустимо использовать это сообщение при создании защищенной связи IKE (SA⁸).

Если в реализации поддерживается устойчивое к DoS поведение, предложенное в параграфе 2.4 [RFC5996], она может просто игнорировать ошибочные сообщения с запросами или откликами и продолжать ожидать следующего сообщения с действительными данными KE.

Если реализация не поддерживает устойчивое к DoS поведение и в запросе IKE_SA_INIT указаны непригодные данные KE, реализация может передать уведомление об ошибке INVALID_SYNTAX и удалить организуемую связь IKE SA. Если же непригодные данные KE были получены в отклике IKE_SA_INIT, реализация может просто удалить созданную наполовину IKE SA и заново инициировать обмен.

Если непригодные данные KE получены в процессе обмена CREATE_CHILD_SA (или любого другого обмена после организации IKE SA) и непригодные данные KE были в запросном сообщении, отвечающая сторона (Responder) должна передать уведомление об ошибке INVALID_SYNTAX и сбросить IKE SA. Если непригодные данные KE получены в отклике, принявший это сообщение инициатор (Initiator) должен незамедлительно удалить IKE SA путем отправки уведомления IKE SA Delete в качестве нового обмена. В таких случаях очевидно наличие ошибки в реализации отправителя и сброс IKE SA упрощает обнаружение такой ошибки.

3. Побочные каналы

В дополнение к атакам на малые подгруппы (small-subgroup) существует также возможность timing-атак на партнеров IKE, которые повторно используют значения секретов Diffie-Hellman. Это атака с побочным каналом (side-channel), уязвимость к которой зависит от деталей реализации и модели угроз.

Оставшаяся часть этого параграфа заимствована из раздела 5 [RFC2412] с незначительными разъяснениями. Эта атака остается применимой к реализациям IKEv2, а также группам MODP и ECDH. Отметим также, что для представленных в проективной форме групп EC доступны более эффективные контрмеры, но их рассмотрение выходит за рамки этого документа.

Атаки с координацией (Timing), в которых может быть восстановлено значение показателя (exponent), использованного в расчетах Diffie-Hellman, описаны Paul Kocher [Kocher]. Для противодействия таким атакам в реализациях должны применяться меры сокрытия последовательности операций, вовлеченных в расчеты.

Одним из возможных методов борьбы с такими атаками является использование «фактора ослепления» (blinding factor). В этом методе элемент группы r выбирается случайным образом и рассчитывается его мультипликативная инверсия по модулю p (обозначим это r_inv). Значение r_inv можно рассчитать расширенным методом Эвклида (Extended Euclidean Method), используя r и p в качестве входных значений. Когда выбран показатель x, рассчитывается также значение r_inv^x. Затем, вычисляя (g^y)^x, реализация будет выполнять приведенную ниже последовательность расчетов.

      A = r*gy
      B = Ax = (r*gy)x = (rx)(g(xy))
      C = B*r_invx = (rx)(r(-1*x))(g(xy)) = g(xy)

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

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

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

4.1. Повторное использование ключа DH и множество партнеров

В этом параграфе описан вариант атаки, которую можно предотвратить с помощью описанных выше тестов.

Предположим, что IKE-партнер Alice поддерживает защищенные связи IKE с Bob и Eve. Alice использует один ключ ECDH для обеих SA, что разрешается с учетом некоторых ограничений. Если Alice не выполняет этих тестов, Eve получит возможность передать некорректно сформированный открытый ключ, с помощью которого она сможет определить секретный ключ Alice (как описано в разделе 2 [Menezes]). Поскольку ключ является общим для двух защищенных связей Eve сможет получить ключ IKE SA между Alice и Bob.

4.2. Многократное использование ключа DH — варианты

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

1. Ключи DH используются для множества соединений (IKE SA) с одним партнером и для соединений с другими партнерами.

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

3. Ключи DH используются повторно лишь в том случае, когда они не были применены в завершенном обмене (например, когда партнер ответил уведомлением INVALID_KE_PAYLOAD).

Описанные в этом документе атаки small-subgroup и timing применимы по крайней мере к вариантам 1 и 2.

4.3. Группы, не охватываемые данным RFC

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

Одним из типов являются четно-характеристические эллиптические кривые (even-characteristic elliptic curve). Сейчас эти кривые имеют сомножители (cofactor) больше 1 и это ведет к возможности утечки информации. Имеется несколько способов предотвращения такой утечки, включая выполнение тестов, аналогичных тесту из параграфа 2.2 или настройки операции ECDH для предотвращения утечки (типа ECC CDH⁹, где общим секретом реально является hxyG). Поскольку подходящие тесты зависят от способа определения группы, описать из заранее невозможно.

4.4. Поведение при отказе теста

Рекомендованное в параграфе 2.5 поведение соответствует базовой обработке ошибок в процессе обмена IKE_SA_INIT, описанной в параграфе 2.21.1 [RFC5996]. Отправитель не обязан передавать уведомления об ошибках и получатель не может зависеть от таких уведомлений, поскольку его подлинность не проверена и фактически это могут быть попытки организации DoS-атаки на соединение. Таким образом, уведомления полезны лишь для поиска ошибок при отладке реализаций.

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

Ситуация с отказом при обмене CREATE_CHILD_SA иная, поскольку здесь все защищено IKE SA. Партнеры здесь аутентифицированы и могут полагаться на уведомления об ошибках. Более подробное описание обработки ошибок в таких случаях приведено в параграфе 2.21.3 [RFC5996].

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

Агентство IANA добавило колонку Recipient Tests (Тесты у получателя) в реестр Transform Type 4 — Diffie-Hellman Group Transform IDs для IKEv2 [IANA-IKEv2-Registry].

Включенные в эту колонку значения приведены в таблице.