RFC 9243 A YANG Data Model for DHCPv6 Configuration

Internet Engineering Task Force (IETF)                    I. Farrer, Ed.
Request for Comments: 9243                           Deutsche Telekom AG
Category: Standards Track                                      June 2022
ISSN: 2070-1721

A YANG Data Model for DHCPv6 Configuration

Модель данных YANG для настройки DHCPv6

PDF

Аннотация

Этот документ описывает модель данных YANG для настройки и управления серверами, ретрансляторами и клиентами протокола динамической настройки конфигурации хостов IPv6 (Dynamic Host Configuration Protocol for IPv6 или DHCPv6) (RFC 8415).

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

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

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

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

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

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

Протокол DHCPv6 [RFC8415] служит для предоставления конфигурации и других параметров клиентам сетей IPv6. Этот документ задаёт модуль YANG [RFC7950] для настройки и управления «элементами» DHCPv6 (серверы, ретрансляторы, клиенты), использующими протокол управления сетью (Network Configuration Protocol или NETCONF) [RFC6241] или RESTCONF [RFC8040]. Для каждого элемента задан свой модуль, а «базовый» модуль содержит определения типов (typedef) и группировки (grouping), применяемые модулями элементов. В Приложении A представлены примеры XML для каждого элемента и рассмотрено их взаимодействие.

Модули для ретранслятора и клиента обеспечивают конфигурацию, применяемую к интерфейсам устройств. Это делается с помощью модуля YANG ietf-interfaces [RFC8343] и ссылок interface-refs на соответствующие интерфейсы.

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

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

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

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

1.2. Расширяемость модуля YANG для сервера DHCPv6

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

Однако признано, что настройка и управление для конкретной реализации являются важной частью развёртывания и эксплуатации DHCP. Поэтому в Приложении C приведён пример модуля YANG для настройки зависящих от реализации функций с использованием дополнений (augment) базового модуля ietf-dhcpv6-server.yang.

В DHCPv6 применяется концепция выбора класса (class selection) для сообщений, получаемых сервером. Это идентификация и классификация сообщений на основе большого числа параметров, позволяющая предоставить корректные сведения о подготовке, например, путём выделения префикса из корректного пула или предоставления набора опций, относящихся к реализации клиента конкретным производителем. В процессе разработки этого документа были исследованы реализации и обнаружено, что эти функции существенно различаются, хотя и присущи всем реализациям. Поэтому настройка функции выбора класса не была включена в модуль сервера DHCPv6, чтобы производители могли задать свои модули YANG. В Приложении D приведён пример такого модуля, демонстрирующий объединение с основным модулем ietf-dhcpv6-server.yang.

1.2.1. Определения опций DHCPv6

Было определено множество опций DHCPv6 в дополнение к заданным в [RFC8415]. Поскольку реализации сильно различаются в плане поддержки опций DHCPv6, был принято решение о включении в этот документ лишь опций DHCPv6, определённых в [RFC8415]. Из этих опций для модели были выбраны лишь те, которые требуют настройки оператором. Например, опция OPTION_IA_NA (3) создаётся сервером DHCP по запросу клиента. Содержимое полей опции основано на множестве входных параметров, которые сервер будет применять при получении запроса (например, таймеры, T1/T2, связанные с пулом адресов). В результате для опции нет полей, которые можно настраивать напрямую, и она не включена в модель. В таблице 1 приведены моделируемые опции DHCPv6, элементы, для которых они моделируются, и указаны соответствующие модули YANG.

Таблица 1. Смоделированные опции DHCPv6.

Опция

Server

Relay

Client

Модуль

OPTION_ORO (6) Option Request

X

ietf-dhcpv6-client.yang

OPTION_PREFERENCE (7) Preference

X

ietf-dhcpv6-server.yang

OPTION_AUTH (11) Authentication

X

X

ietf-dhcpv6-common.yang

OPTION_UNICAST (12) Server Unicast

X

ietf-dhcpv6-server.yang

OPTION_RAPID_COMMIT (14) Rapid Commit

X

X

ietf-dhcpv6-common.yang

OPTION_USER_CLASS (15) User Class

X

ietf-dhcpv6-client.yang

OPTION_VENDOR_CLASS (16) Vendor Class

X

ietf-dhcpv6-client.yang

OPTION_VENDOR_OPTS (17) Vendor-specific Information

X

X

ietf-dhcpv6-common.yang

OPTION_INTERFACE_ID (18) Interface-Id Optin

X

ietf-dhcpv6-relay.yang

OPTION_RECONF_MSG (19) Reconfigure Message

X

ietf-dhcpv6-server.yang

OPTION_RECONF_ACCEPT (20) Reconfigure Accept Option

X

X

ietf-dhcpv6-client.yang

OPTION_INFORMATION _REFRESH_TIME (32) Information Refresh Time

X

ietf-dhcpv6-server.yang

OPTION_SOL_MAX_RT (82) sol max rt

X

ietf-dhcpv6-server.yang

OPTION_INF_MAX_RT (83) inf max rt

X

ietf-dhcpv6-server.yang

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

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

Предполагается знакомство читателя с языком моделирования данных YANG [RFC7950].

Модули YANG с этом документе соответствуют архитектуре NMDA [RFC8342]. Символы, применяемые в диаграммах деревьев, описаны в [RFC8340].

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

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

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

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

3.1. Диаграмма дерева сервера DHCPv6

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

   module: ietf-dhcpv6-server
     +--rw dhcpv6-server
        +--rw enabled?             boolean
        +--rw server-duid?         dhc6:duid
        +--rw vendor-config
        +--rw option-sets
        |  +--rw option-set* [option-set-id]
        |     +--rw option-set-id                          string
        |     +--rw description?                           string
        |     +--rw preference-option
        |     |  +--rw pref-value?   uint8
        |     +--rw auth-option
        |     |  +--rw algorithm?                      uint8
        |     |  +--rw rdm?                            uint8
        |     |  +--rw replay-detection?               uint64
        |     |  +--rw (protocol)?
        |     |     +--:(conf-token)
        |     |     |  +--rw token-auth-information?   binary
        |     |     +--:(rkap)
        |     |        +--rw datatype?                 uint8
        |     |        +--rw auth-info-value?          binary
        |     +--rw server-unicast-option
        |     |  +--rw server-address?   inet:ipv6-address
        |     +--rw rapid-commit-option!
        |     +--rw vendor-specific-information-options
        |     |  +--rw vendor-specific-information-option*
        |     |          [enterprise-number]
        |     |     +--rw enterprise-number     uint32
        |     |     +--rw vendor-option-data* [sub-option-code]
        |     |        +--rw sub-option-code    uint16
        |     |        +--rw sub-option-data?   binary
        |     +--rw reconfigure-message-option
        |     |  +--rw msg-type?   uint8
        |     +--rw reconfigure-accept-option!
        |     +--rw info-refresh-time-option
        |     |  +--rw info-refresh-time?   dhc6:timer-seconds32
        |     +--rw sol-max-rt-option
        |     |  +--rw sol-max-rt-value?   dhc6:timer-seconds32
        |     +--rw inf-max-rt-option
        |        +--rw inf-max-rt-value?   dhc6:timer-seconds32
        +--rw class-selector
        +--rw allocation-ranges
           +--rw option-set-id*        leafref
           +--rw valid-lifetime?       dhc6:timer-seconds32
           +--rw renew-time?           dhc6:timer-seconds32
           +--rw rebind-time?          dhc6:timer-seconds32
           +--rw preferred-lifetime?   dhc6:timer-seconds32
           +--rw rapid-commit?         boolean
           +--rw allocation-range* [id]
           |  +--rw id                    string
           |  +--rw description?          string
           |  +--rw network-prefix        inet:ipv6-prefix
           |  +--rw option-set-id*        leafref
           |  +--rw valid-lifetime?       dhc6:timer-seconds32
           |  +--rw renew-time?           dhc6:timer-seconds32
           |  +--rw rebind-time?          dhc6:timer-seconds32
           |  +--rw preferred-lifetime?   dhc6:timer-seconds32
           |  +--rw rapid-commit?         boolean
           |  +--rw address-pools {na-assignment}?
           |  |  +--rw address-pool* [pool-id]
           |  |     +--rw pool-id                    string
           |  |     +--rw pool-prefix
           |  |     |       inet:ipv6-prefix
           |  |     +--rw start-address
           |  |     |       inet:ipv6-address-no-zone
           |  |     +--rw end-address
           |  |     |       inet:ipv6-address-no-zone
           |  |     +--rw max-address-utilization?   dhc6:threshold
           |  |     +--rw option-set-id*             leafref
           |  |     +--rw valid-lifetime?
           |  |     |       dhc6:timer-seconds32
           |  |     +--rw renew-time?
           |  |     |       dhc6:timer-seconds32
           |  |     +--rw rebind-time?
           |  |     |       dhc6:timer-seconds32
           |  |     +--rw preferred-lifetime?
           |  |     |       dhc6:timer-seconds32
           |  |     +--rw rapid-commit?              boolean
           |  |     +--rw host-reservations
           |  |     |  +--rw host-reservation* [reserved-addr]
           |  |     |     +--rw client-duid?          dhc6:duid
           |  |     |     +--rw reserved-addr
           |  |     |     |       inet:ipv6-address
           |  |     |     +--rw option-set-id*        leafref
           |  |     |     +--rw valid-lifetime?
           |  |     |     |       dhc6:timer-seconds32
           |  |     |     +--rw renew-time?
           |  |     |     |       dhc6:timer-seconds32
           |  |     |     +--rw rebind-time?
           |  |     |     |       dhc6:timer-seconds32
           |  |     |     +--rw preferred-lifetime?
           |  |     |     |       dhc6:timer-seconds32
           |  |     |     +--rw rapid-commit?         boolean
           |  |     +--ro active-leases
           |  |        +--ro total-count        uint64
           |  |        +--ro allocated-count    uint64
           |  |        +--ro active-lease* [leased-address]
           |  |           +--ro leased-address
           |  |           |       inet:ipv6-address
           |  |           +--ro client-duid?          dhc6:duid
           |  |           +--ro ia-id                 uint32
           |  |           +--ro allocation-time?
           |  |           |       yang:date-and-time
           |  |           +--ro last-renew-rebind?
           |  |           |       yang:date-and-time
           |  |           +--ro preferred-lifetime?
           |  |           |       dhc6:timer-seconds32
           |  |           +--ro valid-lifetime?
           |  |           |       dhc6:timer-seconds32
           |  |           +--ro lease-t1?
           |  |           |       dhc6:timer-seconds32
           |  |           +--ro lease-t2?
           |  |           |       dhc6:timer-seconds32
           |  |           +--ro status
           |  |              +--ro code?      uint16
           |  |              +--ro message?   string
           |  +--rw prefix-pools {prefix-delegation}?
           |     +--rw prefix-pool* [pool-id]
           |        +--rw pool-id                     string
           |        +--rw pool-prefix
           |        |       inet:ipv6-prefix
           |        +--rw client-prefix-length        uint8
           |        +--rw max-pd-space-utilization?   dhc6:threshold
           |        +--rw option-set-id*              leafref
           |        +--rw valid-lifetime?
           |        |       dhc6:timer-seconds32
           |        +--rw renew-time?
           |        |       dhc6:timer-seconds32
           |        +--rw rebind-time?
           |        |       dhc6:timer-seconds32
           |        +--rw preferred-lifetime?
           |        |       dhc6:timer-seconds32
           |        +--rw rapid-commit?               boolean
           |        +--rw host-reservations
           |        |  +--rw prefix-reservation* [reserved-prefix]
           |        |  |  +--rw client-duid?           dhc6:duid
           |        |  |  +--rw reserved-prefix
           |        |  |  |       inet:ipv6-prefix
           |        |  |  +--rw reserved-prefix-len?   uint8
           |        |  +--rw option-set-id*        leafref
           |        |  +--rw valid-lifetime?
           |        |  |       dhc6:timer-seconds32
           |        |  +--rw renew-time?
           |        |  |       dhc6:timer-seconds32
           |        |  +--rw rebind-time?
           |        |  |       dhc6:timer-seconds32
           |        |  +--rw preferred-lifetime?
           |        |  |       dhc6:timer-seconds32
           |        |  +--rw rapid-commit?         boolean
           |        +--ro active-leases
           |           +--ro total-count        uint64
           |           +--ro allocated-count    uint64
           |           +--ro active-lease* [leased-prefix]
           |              +--ro leased-prefix
           |              |       inet:ipv6-prefix
           |              +--ro client-duid?          dhc6:duid
           |              +--ro ia-id                 uint32
           |              +--ro allocation-time?
           |              |       yang:date-and-time
           |              +--ro last-renew-rebind?
           |              |       yang:date-and-time
           |              +--ro preferred-lifetime?
           |              |       dhc6:timer-seconds32
           |              +--ro valid-lifetime?
           |              |       dhc6:timer-seconds32
           |              +--ro lease-t1?
           |              |       dhc6:timer-seconds32
           |              +--ro lease-t2?
           |              |       dhc6:timer-seconds32
           |              +--ro status
           |                 +--ro code?      uint16
           |                 +--ro message?   string
           +--rw statistics
              +--rw discontinuity-time?          yang:date-and-time
              +--ro solicit-count?               yang:counter32
              +--ro advertise-count?             yang:counter32
              +--ro request-count?               yang:counter32
              +--ro confirm-count?               yang:counter32
              +--ro renew-count?                 yang:counter32
              +--ro rebind-count?                yang:counter32
              +--ro reply-count?                 yang:counter32
              +--ro release-count?               yang:counter32
              +--ro decline-count?               yang:counter32
              +--ro reconfigure-count?           yang:counter32
              +--ro information-request-count?   yang:counter32
              +--ro discarded-message-count?     yang:counter32

     rpcs:
       +---x delete-address-lease {na-assignment}?
       |  +---w input
       |  |  +---w lease-address-to-delete    leafref
       |  +--ro output
       |     +--ro return-message?   string
       +---x delete-prefix-lease {prefix-delegation}?
          +---w input
          |  +---w lease-prefix-to-delete    leafref
          +--ro output
             +--ro return-message?   string

     notifications:
       +---n address-pool-utilization-threshold-exceeded
       |       {na-assignment}?
       |  +--ro pool-id                    leafref
       |  +--ro total-pool-addresses       uint64
       |  +--ro max-allocated-addresses    uint64
       |  +--ro allocated-address-count    uint64
       +---n prefix-pool-utilization-threshold-exceeded
       |       {prefix-delegation}?
       |  +--ro pool-id                     leafref
       |  +--ro total-pool-prefixes         uint64
       |  +--ro max-allocated-prefixes      uint64
       |  +--ro allocated-prefixes-count    uint64
       +---n invalid-client-detected
       |  +--ro message-type?   enumeration
       |  +--ro duid?           dhc6:duid
       |  +--ro description?    string
       +---n decline-received {na-assignment}?
       |  +--ro duid?                 dhc6:duid
       |  +--ro declined-resources* []
       |     +--ro (resource-type)?
       |        +--:(declined-address)
       |        |  +--ro address?   inet:ipv6-address
       |        +--:(declined-prefix)
       |           +--ro prefix?    inet:ipv6-prefix
       +---n non-success-code-sent
          +--ro duid?     dhc6:duid
          +--ro status
             +--ro code?      uint16
             +--ro message?   string

Рисунок 1. Структура модуля данных сервера DHCPv6.

enabled

Включает или отключает функцию сервера DHCPv6.

dhcpv6-server

Контейнер для конфигурации сервера DHCPv6.

server-duid

Каждый сервер должен иметь уникальный идентификатор (DHCP Unique Identifier или DUID) для представления себя клиентам. DUID состоит из 2-октетного поля типа и поля содержимого размером до 128 октетов. В настоящее время определены 4 типа DUID в [RFC8415] и [RFC6355]. DUID можно настроить с использованием формата одного из этих типоа или формата unstructured. Определения типов DUID импортируются из модуля ietf-dhcpv6-common.yang. Ссылки [IANA-HARDWARE-TYPES] и [IANA-PEN] указывают соответствующие типы DUID.

vendor-config

Контейнер для связанных с реализацией узлов YANG для модулей дополнения конфигурации устройства. Пример такого модуля приведён в Приложении C.

option-sets

Сервер можно настроить с множеством наборов опций. Это группы опций DHCPv6 с общими параметрами, которые могут быть предоставлены клиенту по запросу. Поле option-set-id служит для указания набора в конфигурации сервера.

option-set

Конфигурационные параметры для опций DHCPv6. Здесь задан исходный набор определений опций, а дополнительные опции, которые могут относиться также к транслятору или клиенту, импортируются из модуля ietf-dhcpv6-common. При необходимости могут добавляться другие модули опций DHCPv6. Полный список опций DHCPV6 приведён в [IANA-DHCPV6-OPTION-CODES].

class-selector

Служит для размещения зависящих от реализации узлов YANG фирменных для добавляемых селекторов класса. Пример приведён в Приложении D.

allocation-ranges

Для выделения адресов и префиксов применяется иерархическая модель. Контейнер верхнего уровня allocation-ranges содержит глобальные параметры конфигурации. В нем размещается список allocation-range для задания префиксов IPv6 и связанных с ними дополнительных параметров.

address-pools

Применяется для пулов адресов IA_NA (Identity Association for Non-temporary Addresses) и IA_TA (Identity Association for Temporary Addresses) с контейнером для определения резервирований хостов. Здесь же хранится информация о состоянии действующей аренды для каждого пула.

prefix-pools

Указывает пулы, используемые для делегирования префиксов клиентам. Можно также настраивать статическое резервирования для хостов. Делегирование префиксов поддерживают не све реализации серверов DHCPv6, поэтому применяется оператор feature.

Сведения о RPC

delete-address-lease

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

delete-prefix-lease

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

Сведения об уведомлениях

address/prefix-pool-utilization-threshold-exceeded

Выдается когда число выделенных из пула адресов или префиксов превышаетя заданных порог.

invalid-client-detected

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

decline-received

Выдается при получении от клиента сообщения DHCPv6 Decline.

non-success-code-sent

Выдается при наличии статусного сообщения для отказа. Коды статуса берутся из [IANA-DHCPV6-STATUS-CODES].

3.2. Диаграмма дерева ретранслятора DHCPv6

Диаграмма дерева на рисунке 2 иллюстрирует модуль сервера DHCPv6, а также включает базовый модуль из параграфа 4.1. RPC в модуле взяты из [RFC8987].

   module: ietf-dhcpv6-relay
     +--rw dhcpv6-relay
        +--rw enabled?      boolean
        +--rw relay-if* [if-name]
        |  +--rw if-name                if:interface-ref
        |  +--rw enabled?               boolean
        |  +--rw destination-address*   inet:ipv6-address
        |  +--rw link-address?          inet:ipv6-address
        |  +--rw relay-options
        |  |  +--rw auth-option
        |  |  |  +--rw algorithm?                      uint8
        |  |  |  +--rw rdm?                            uint8
        |  |  |  +--rw replay-detection?               uint64
        |  |  |  +--rw (protocol)?
        |  |  |     +--:(conf-token)
        |  |  |     |  +--rw token-auth-information?   binary
        |  |  |     +--:(rkap)
        |  |  |        +--rw datatype?                 uint8
        |  |  |        +--rw auth-info-value?          binary
        |  |  +--rw interface-id-option
        |  |     +--rw interface-id?   binary
        |  +--rw statistics
        |  |  +--rw discontinuity-time?
        |  |  |       yang:date-and-time
        |  |  +--ro solicit-received-count?
        |  |  |       yang:counter32
        |  |  +--ro advertise-sent-count?
        |  |  |       yang:counter32
        |  |  +--ro request-received-count?
        |  |  |       yang:counter32
        |  |  +--ro confirm-received-count?
        |  |  |       yang:counter32
        |  |  +--ro renew-received-count?
        |  |  |       yang:counter32
        |  |  +--ro rebind-received-count?
        |  |  |       yang:counter32
        |  |  +--ro reply-sent-count?
        |  |  |       yang:counter32
        |  |  +--ro release-received-count?
        |  |  |       yang:counter32
        |  |  +--ro decline-received-count?
        |  |  |       yang:counter32
        |  |  +--ro reconfigure-sent-count?
        |  |  |       yang:counter32
        |  |  +--ro information-request-received-count?
        |  |  |       yang:counter32
        |  |  +--ro unknown-message-received-count?
        |  |  |       yang:counter32
        |  |  +--ro unknown-message-sent-count?
        |  |  |       yang:counter32
        |  |  +--ro discarded-message-count?
        |  |          yang:counter32
        |  +--rw prefix-delegation! {prefix-delegation}?
        |     +--ro pd-leases* [ia-pd-prefix]
        |        +--ro ia-pd-prefix           inet:ipv6-prefix
        |        +--ro last-renew?            yang:date-and-time
        |        +--ro client-peer-address?   inet:ipv6-address
        |        +--ro client-duid?           dhc6:duid
        |        +--ro server-duid?           dhc6:duid
        +--rw statistics
           +--ro relay-forward-sent-count?
           |       yang:counter32
           +--ro relay-forward-received-count?
           |       yang:counter32
           +--ro relay-reply-received-count?
           |       yang:counter32
           +--ro relay-forward-unknown-sent-count?
           |       yang:counter32
           +--ro relay-forward-unknown-received-count?
           |       yang:counter32
           +--ro discarded-message-count?
                   yang:counter32

     rpcs:
       +---x clear-prefix-entry {prefix-delegation}?
       |  +---w input
       |  |  +---w lease-prefix    leafref
       |  +--ro output
       |     +--ro return-message?   string
       +---x clear-client-prefixes {prefix-delegation}?
       |  +---w input
       |  |  +---w client-duid    dhc6:duid
       |  +--ro output
       |     +--ro return-message?   string
       +---x clear-interface-prefixes {prefix-delegation}?
          +---w input
          |  +---w interface    -> /dhcpv6-relay/relay-if/if-name
          +--ro output
             +--ro return-message?   string

     notifications:
       +---n relay-event
          +--ro topology-change
             +--ro relay-if-name?
             |       -> /dhcpv6-relay/relay-if/if-name
             +--ro last-ipv6-addr?   inet:ipv6-address

Рисунок 2. Структура модуля данных ретранслятора DHCPv6.

enabled

Включает или отключает функцию ретранслятора DHCPv6.

dhcpv6-relay

Контейнер для конфигурации ретранслятора DHCPv6.

relay-if

Поскольку транслятор может иметь несколько интерфейсов в сторону клиентов, они задаются в списке. Лист if-name служит ключом и имеется interface-ref для подхожящего интерфейса, определённого в модуле ietf-interfaces.

enabled

Включает или выключает функции ретранслятора DHCPv6 на конкретном интерфейсе.

destination-addresses

Список индивидуальных и/или групповых адресов IPv6, куда будут транслироваться клиентские сообщения.

link-address

Значение, помещаемое ретранслятором в поле link-address сообщений Relay-Forward.

prefix-delegation

Поскольку делегирование префиксов поддерживают не все реализации ретрансляторов DHCPv6, применяется оператор feature.

pd-leases

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

relay-options

Параметры конфигурации для опций DHCPv6, которые может передавать ретранслятор. Здесь задан исходный набор применимых опций, а дополнительные опции, которые могут относиться также к клиенту и серверу, импортируются из модуля ietf-dhcpv6-common. Информация для Authentication Option (OPTION_AUTH (11)) взята из [IANA-DHCPV6-AUTH-NAMESPACES] и [RFC3118]. При необходимости могут добавляться другие модули опций DHCPv6 с помощью операторов augment. Полный список опций DHCPV6 приведён в [IANA-DHCPV6-OPTION-CODES].

Сведения о RPC

clear-prefix-entry

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

clear-client-prefixes

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

clear-interface-prefixes

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

Сведения об уведомлениях

topology-change

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

3.3. Диаграмма дерева клиента DHCPv6

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

   module: ietf-dhcpv6-client
     +--rw dhcpv6-client
        +--rw enabled?     boolean
        +--rw client-if* [if-name]
           +--rw if-name                      if:interface-ref
           +--rw enabled?                     boolean
           +--rw interface-duid?              dhc6:duid
           |       {(non-temp-addr or prefix-delegation or temp-addr)
                     and anon-profile}?
           +--rw client-configured-options
           |  +--rw option-request-option
           |  |  +--rw oro-option*   uint16
           |  +--rw rapid-commit-option!
           |  +--rw user-class-option!
           |  |  +--rw user-class-data-instance*
           |  |          [user-class-data-id]
           |  |     +--rw user-class-data-id    uint8
           |  |     +--rw user-class-data?      binary
           |  +--rw vendor-class-option
           |  |  +--rw vendor-class-option-instances*
           |  |          [enterprise-number]
           |  |     +--rw enterprise-number            uint32
           |  |     +--rw vendor-class-data-element*
           |  |             [vendor-class-data-id]
           |  |        +--rw vendor-class-data-id    uint8
           |  |        +--rw vendor-class-data?      binary
           |  +--rw vendor-specific-information-options
           |  |  +--rw vendor-specific-information-option*
           |  |          [enterprise-number]
           |  |     +--rw enterprise-number     uint32
           |  |     +--rw vendor-option-data* [sub-option-code]
           |  |        +--rw sub-option-code    uint16
           |  |        +--rw sub-option-data?   binary
           |  +--rw reconfigure-accept-option!
           +--rw ia-na* [ia-id] {non-temp-addr}?
           |  +--rw ia-id            uint32
           |  +--rw ia-na-options
           |  +--ro lease-state
           |     +--ro ia-na-address?        inet:ipv6-address
           |     +--ro lease-t1?             dhc6:timer-seconds32
           |     +--ro lease-t2?             dhc6:timer-seconds32
           |     +--ro preferred-lifetime?   dhc6:timer-seconds32
           |     +--ro valid-lifetime?       dhc6:timer-seconds32
           |     +--ro allocation-time?      yang:date-and-time
           |     +--ro last-renew-rebind?    yang:date-and-time
           |     +--ro server-duid?          dhc6:duid
           |     +--ro status
           |        +--ro code?      uint16
           |        +--ro message?   string
           +--rw ia-ta* [ia-id] {temp-addr}?
           |  +--rw ia-id            uint32
           |  +--rw ia-ta-options
           |  +--ro lease-state
           |     +--ro ia-ta-address?        inet:ipv6-address
           |     +--ro preferred-lifetime?   dhc6:timer-seconds32
           |     +--ro valid-lifetime?       dhc6:timer-seconds32
           |     +--ro allocation-time?      yang:date-and-time
           |     +--ro last-renew-rebind?    yang:date-and-time
           |     +--ro server-duid?          dhc6:duid
           |     +--ro status
           |        +--ro code?      uint16
           |        +--ro message?   string
           +--rw ia-pd* [ia-id] {prefix-delegation}?
           |  +--rw ia-id                 uint32
           |  +--rw prefix-length-hint?   uint8
           |  +--rw ia-pd-options
           |  +--ro lease-state
           |     +--ro ia-pd-prefix?         inet:ipv6-prefix
           |     +--ro lease-t1?             dhc6:timer-seconds32
           |     +--ro lease-t2?             dhc6:timer-seconds32
           |     +--ro preferred-lifetime?   dhc6:timer-seconds32
           |     +--ro valid-lifetime?       dhc6:timer-seconds32
           |     +--ro allocation-time?      yang:date-and-time
           |     +--ro last-renew-rebind?    yang:date-and-time
           |     +--ro server-duid?          dhc6:duid
           |     +--ro status
           |        +--ro code?      uint16
           |        +--ro message?   string
           +--rw statistics
              +--rw discontinuity-time?          yang:date-and-time
              +--ro solicit-count?               yang:counter32
              +--ro advertise-count?             yang:counter32
              +--ro request-count?               yang:counter32
              +--ro confirm-count?               yang:counter32
              +--ro renew-count?                 yang:counter32
              +--ro rebind-count?                yang:counter32
              +--ro reply-count?                 yang:counter32
              +--ro release-count?               yang:counter32
              +--ro decline-count?               yang:counter32
              +--ro reconfigure-count?           yang:counter32
              +--ro information-request-count?   yang:counter32
              +--ro discarded-message-count?     yang:counter32

     notifications:
       +---n invalid-ia-address-detected
       |       {non-temp-addr or temp-addr}?
       |  +--ro ia-id                 uint32
       |  +--ro ia-na-t1-timer?       uint32
       |  +--ro ia-na-t2-timer?       uint32
       |  +--ro invalid-address?      inet:ipv6-address
       |  +--ro preferred-lifetime?   uint32
       |  +--ro valid-lifetime?       uint32
       |  +--ro ia-options?           binary
       |  +--ro description?          string
       +---n transmission-failed
       |  +--ro failure-type    enumeration
       |  +--ro description?    string
       +---n unsuccessful-status-code
       |  +--ro server-duid    dhc6:duid
       |  +--ro status
       |     +--ro code?      uint16
       |     +--ro message?   string
       +---n server-duid-changed
               {non-temp-addr or prefix-delegation or temp-addr}?
          +--ro new-server-duid         dhc6:duid
          +--ro previous-server-duid    dhc6:duid
          +--ro lease-ia-na?
          |       -> /dhcpv6-client/client-if/ia-na/ia-id
          |       {non-temp-addr}?
          +--ro lease-ia-ta?
          |       -> /dhcpv6-client/client-if/ia-ta/ia-id
          |       {temp-addr}?
          +--ro lease-ia-pd?
                  -> /dhcpv6-client/client-if/ia-pd/ia-id
                  {prefix-delegation}?

Рисунок 3. Структура модуля данных клиента DHCPv6.

enabled

Включает или отключает функцию клиента DHCPv6.

dhcpv6-client

Контейнер для конфигурации клиента DHCPv6.

client-if

Клиент может иметь несколько интерфейсов, запрашивающих конфигурацию через DHCP, они указываются в списке. Лист if-name служит ключом, а interface-ref указывает подходящий интерфейс, заданный в модуле YANG ietf-interfaces.

enabled

Включает или отключает функции клиента DHCPv6 для заданного интерфейса.

client-duid/interface-duid

DUID служит для илентификации клиента сервером или ретранслятором. DUID состоит из 2-октетного поля типа и строки содержимого размером 1-128 октетов. В настоящее время определены 4 типа DUID в [RFC8415] и [RFC6355]. DUID можно настроить с использованием формата одного из этих типоа или формата unstructured. Определения типов DUID импортируются из модуля ietf-dhcpv6-common.yang. Ссылки [IANA-HARDWARE-TYPES] и [IANA-PEN] указывают соответствующие типы DUID. настройка DUID для клиента нужна лишь при запросе адресов или префиксов у сервера. Наличие листьев client-duid или interface-duid определяется включением хотя бы одной из функций (feature) non-temp-addr, temp-addr, prefix-delegation. При включении функции anon-profile [RFC7844] можно настроить уникальный DUID на интерфейсе со включённым DHCP, используя лист interface-duid, для иных случаев применяется глобальный лист client-duid.

client-configured-options

Содержит параметры конфигурации для опций DHCPv6, которые может передавать клиент. Начальный набор опций задан здесь, а дополнительные опции, которые могут также относится к серверу и ретранслятору, импортируются из модуля ietf-dhcpv6-common. При необходимости можно задать дополнительные модули с опциями DHCPv6 с помощью операторов augment. Полный список опций DHCPV6 приведён в [IANA-DHCPV6-OPTION-CODES].

ia-na, ia-ta, ia-pd

Узлы конфигурации для запроса одной или более аренды каждого типа. Доступные лишь для чтения узлы, относящиеся к активной аренде для каждого типа, также размещаются здесь с кодами состояния из [IANA-DHCPV6-STATUS-CODES]. Поскольку эти типы могут поддерживаться не всеми реализациями клиентов DHCPv6, применяются операторы feature. DHCP без поддержки состояния (параграф 6.1 в [RFC8415]) настраивается при отключении всех функций (feature) для адресов и префиксов.

Сведения об уведомлениях

invalid-ia-detected

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

retransmission-failed

This is raised when the retransmission mechanism defined in [RFC8415] has failed.

4. Модули YANG DHCPv6

4.1. Базовый модуль YANG DHCPv6

   <CODE BEGINS> file "ietf-dhcpv6-common@2022-06-20.yang"
   module ietf-dhcpv6-common {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dhcpv6-common";
     prefix dhc6;

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG задаёт базовые компоненты для настройки и
        управления DHCPv6.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

     typedef threshold {
       type uint8 {
         range "1..100";
       }
       description
         "Пороговое значение в процентах.";
     }

     typedef timer-seconds32 {
       type uint32;
       units "seconds";
       description
         "Значение даймера в секундах (32 бита).";
     }

     typedef duid-base {
       type string {
         pattern '([0-9a-fA-F]{2}){3,130}';
       }
       description
         "Каждый сервер и клиент DHCP имеет DUID с 2-октетным полем типа
          и полем содержимого от 1 до 128 октетов. Тип duid-base 
          применяется другими типами с дополнительными ограничениями.

          В настоящее время определены 4 типа DUID (RFC 8415 и 6355) - 
          DUID-LLT, DUID-EN, DUID-LL, DUID-UUID. DUID-unstructured 
          представляет DUID, не соответствующие этим форматам.

          Тип string служит для представления шестнадцатеричных
          значений DUID, чтобы можно было применить ограничения.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11
          RFC 6355: Definition of the UUID-Based DHCPv6 Unique
          Identifier (DUID-UUID), Section 4";
     }

     typedef duid-llt {
       type duid-base {
         pattern '0001'
               + '[0-9a-fA-F]{12,}';
       }
       description
         "DUID типа 1 на основе адреса канального уровня и времени 
          (Link-Layer Address Plus Time или DUID-LLT). Состоит из 2
          октетов типа оборудования, выделенных IANA, 4 октетов времени
          создания DUID (число секунд 1 1 января 2000 г UTC по модулю
          2^32) и адреса канального уровня без разделителей, например,

          | 0001 | 0006 | 28490058 | 00005E005300 |

          Здесь указан тип 1 DUID (0x01), тип оборудования 0x06 (IEEE 
          Hardware Type), время создания 0x28490058 (см. выше) и адрес
          канального уровня 0x5E005300 (EUI-48 00-00-5E-00-53-00).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11.2
          IANA 'Hardware Types' registry
          <https://www.iana.org/assignments/arp-parameters>"; 
     }

     typedef duid-en {
       type duid-base {
         pattern '0002'
               + '[0-9a-fA-F]{8,}';
       }
       description
         "DUID типа 2 на основе Enterprise Number (DUID-EN) 
          производителя. Состоит из 4-октетов Private Enterprise 
          Number, выделенного IANA, и выделенного производителем
          значения. Например, 
          | 0002 | 00007ED9 | 0CC084D303000912 |

          Здесь указано 2 октета типа DUID (0x02), 4 октета 
          Enterprise Number (0x7ED9) и 8 октетов идентификатора
          (0x0CC084D303000912).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11.3
          IANA 'Private Enterprise Numbers' registry
          <https://www.iana.org/assignments/enterprise-numbers>"; 
     }

     typedef duid-ll {
       type duid-base {
         pattern '0003'
               + '([0-9a-fA-F]){4,}';
       }
       description
         "DUID типа 3 на основе адреса канального уровня (DUID-LL).
          Состоит из 2 октетов типа оборудования, выделенных IANA,
          и адреса канального уровня без разделителей. Например,
          | 0003 | 0006 | 00005E005300 |

          Этот пример включает 2 октета типа DUID (0x03), тип 
          оборудования 0x06 (IEEE Hardware Type) и адрес канального
          уровня 0x5E005300 (EUI-48 00-00-5E-00-53-00).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11.4
          IANA 'Hardware Types' registry
          <https://www.iana.org/assignments/arp-parameters>"; 
     }

     typedef duid-uuid {
       type duid-base {
         pattern '0004'
               + '[0-9a-fA-F]{32}';
       }
       description
         "DUID типа 4 на осноые UUID (DUID-UUID). Содержит 16 октетов
          128 битового идентификатора UUID. Например, 
          | 0004 | 9f03b182705747e38a1e422910078642 |

          Этот пример содержит 2 октета типа DUID (0x04) и UUID
          9f03b182-7057-47e3-8a1e-422910078642.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11.5
          RFC 6355: Definition of the UUID-Based DHCPv6 Unique
          Identifier (DUID-UUID)";
     }

     typedef duid-unstructured {
       type duid-base {
         pattern '(000[1-4].*)' {
           modifier "invert-match";
         }
       }
       description
         "Применяется для DUID иных форматов (не 1 — 4), например,
          | 7b6a164d325946539dc540fb539bc430 |

          Здесь применяется произвольное 16-октетное значение. 
          Единственным ограничением является отличие первых 2 октетов
          от 0x01-0x04 во избежание путаницы с типами (duid-llt, 
          duid-en, duid-ll, duid-uuid).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11";
     }

     typedef duid {
       type union {
         type duid-llt;
         type duid-en;
         type duid-ll;
         type duid-uuid;
         type duid-unstructured;
       }
       description
         "Представляет неструктурированный идентификатор DUID.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 11";
     }

     /*
      * Группировки
      */
     grouping status {
       description
         "Сведения о последнем коде состояния, переданном сервером
          или полученным клиентом.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6), Section 7.5.";
       container status {
         description
           "Сведения о коде состояния для успеха или отказа операций,
            запрошенных в сообщениях.";
         leaf code {
           type uint16;
           description
             "Числовой код статуса, представленный в опции. Список кодов
              приведён в реестре Status Codes, доступном по ссылке
              <https://www.iana.org/assignments/dhcpv6-parameters>."; 
         }
         leaf message {
           type string;
           description
             "Строка UTF-8, пригодная для вывода пользователю.
              НЕДОПУСТИМО завершение null-символом.";
         }
       }
     }

     grouping auth-option-group {
       description
         "OPTION_AUTH (11) Authentication Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6), Section 21.11
          RFC 3118: Authentication for DHCP Messages
          IANA 'Dynamic Host Configuration Protocol (DHCP)
          Authentication Option Name Spaces' registry
          <https://www.iana.org/assignments/auth-namespaces>";
       container auth-option {
         description
           "OPTION_AUTH (11) Authentication Option.";
         leaf algorithm {
           type uint8;
           description
             "Алгоритм, применяемый для протокола аутентификации.";
         }
         leaf rdm {
           type uint8;
           description
             "Метод обнаружения повторов (Replay Detection Method или
              RDM), применяемый в этой опции Authentication.";
         }
         leaf replay-detection {
           type uint64;
           description
             "Сведения об обнаружении повтора для RDM.";
         }
         choice protocol {
           description
             "Протокол аутентификации, применяемый в опции. Значения
              1 (отложенная аутентификация) и 2 (Delayed Authentication 
              (устарело)) не применимы и не моделируются.";
           case conf-token {
             leaf token-auth-information {
               type binary;
               description
                 "Значение 0. Сведения для аутентификации, заданные
                  протоколом и алгоритмом, применяются в опции
                  Authentication.";
             }
           }
           case rkap {
             description
               "Значение 3. Для протокола Reconfigure Key Authentication
                (RKAP) обеспечивается защита от неверной настройки
                клиента, вызванная сообщением Reconfigure от враждебного
                сервера DHCP.";
             leaf datatype {
               type uint8 {
                 range "1 .. 2";
               }
               description
                 "Тип данных в поле Value этой опции.
                   1  Reconfigure key (применяется в сообщении Reply).
                   2  дайджест HMAC-MD5 для сообщения (применяется в
                      сообщении Reconfigure).";
             }
             leaf auth-info-value {
               type binary {
                 length "16";
               }
               description
                 "Данные, указанные полем Type (16 октетов).";
             }
           }
         }
       }
     }

     grouping rapid-commit-option-group {
       description
         "OPTION_RAPID_COMMIT (14) Rapid Commit Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.14";
       container rapid-commit-option {
         presence "Разрешать передачу этой опции";
         description
           "OPTION_RAPID_COMMIT (14) Rapid Commit Option.";
       }
     }

     grouping vendor-specific-information-option-group {
       description
         "OPTION_VENDOR_OPTS (17) Vendor-specific Information
          Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6), Section 21.17";
       container vendor-specific-information-options {
         description
           "OPTION_VENDOR_OPTS (17) Vendor-specific Information
            Option.";
         list vendor-specific-information-option {
           key "enterprise-number";
           description
             "Опция Vendor-specific Information может присутствовать
              неоднократно в сообщении. Каждая запись списка задает
              содержимое экземпляра опции.";
           leaf enterprise-number {
             type uint32;
             description
               "Enterprise Number производителя от IANA.";
             reference
               "IANA 'Private Enterprise Numbers' registry
                <https://www.iana.org/assignments/enterprise-numbers>"; 
           }
           list vendor-option-data {
             key "sub-option-code";
             description
               "Опции производителя, интерпретируемые фирменными 
                функциями клиента и сервера.";
             leaf sub-option-code {
               type uint16;
               description
                 "Код субопции.";
             }
             leaf sub-option-data {
               type binary;
               description
                 "Область данных субопции.";
             }
           }
         }
       }
     }

     grouping reconfigure-accept-option-group {
       description
         "OPTION_RECONF_ACCEPT (20) Reconfigure Accept Option.
          Клиент применяет опцию Reconfigure Accept для аносирования
          серверу своего отношения к сообщениям Reconfigure, а сервер -
          для указания клиенту своего отношения к приёму сообщений
          Reconfigure. Без этой опции клиент не принимает сообщения
          Reconfigure по умолчанию. Наличие узла включает опцию.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6), Section 21.20";
       container reconfigure-accept-option {
         presence "Разрешает передачу этой опции";
         description
           "OPTION_RECONF_ACCEPT (20) Reconfigure Accept Option.";
       }
     }
   }
   <CODE ENDS>

4.2. Модуль YANG для сервера DHCPv6

Этот модуль импортирует определения типов из [RFC6991] и модуля из [RFC8343].

   <CODE BEGINS> file "ietf-dhcpv6-server@2022-06-20.yang"
   module ietf-dhcpv6-server {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dhcpv6-server";
     prefix dhc6-srv;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-dhcpv6-common {
       prefix dhc6;
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }
     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG определяет компоненты настройки и 
        управления для серверов DHCPv6.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

     /*
      * Свойства (функции)
      */

     feature na-assignment {
       description
         "Указывает, что сервер DHCPv6 реализует выделение постоянных
          (non-temporary) адресов.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.2";
     }

     feature prefix-delegation {
       description
         "Указывает, что сервер DHCPv6 реализует делегирование 
          префиксов.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.3";
     }

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

     grouping resource-config {
       description
         "Узлы, применяемые на разных уровнях иерархии адресации 
          сервера DHCPv6.";
       leaf-list option-set-id {
         type leafref {
           path "/dhcpv6-server/option-sets/option-set/option-set-id";
         }
         description
           "Поле ID для набора опций DHCPv6 (option-set) для 
            предоставления клиентам с использованием allocation-range.";
       }
       leaf valid-lifetime {
         type dhc6:timer-seconds32;
         description
           "Срок действия Identity Association (IA).";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 12.1";
       }
       leaf renew-time {
         type dhc6:timer-seconds32;
         description
           "Время обновления (T1).";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 4.2";
       }
       leaf rebind-time {
         type dhc6:timer-seconds32;
         description
           "Время перепривязки (T2).";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 4.2";
       }
       leaf preferred-lifetime {
         type dhc6:timer-seconds32;
         description
           "Предпочтительный срок действия IA.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 12.1";
       }
       leaf rapid-commit {
         type boolean;
         description
           "Разрешает обмен цепочками из 2 сообщений.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 5.1";
       }
     }

     grouping lease-information {
       description
         "Сведения о привязке для каждого клиента, получившего
          адрес или префикс IPv6.";
       leaf client-duid {
         type dhc6:duid;
         description
           "DUID клиента.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 11";
       }
       leaf ia-id {
         type uint32;
         mandatory true;
         description
           "IAID клиента.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 12";
       }
       leaf allocation-time {
         type yang:date-and-time;
         description
           "Дата и время предоставления аренды.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 18";
       }
       leaf last-renew-rebind {
         type yang:date-and-time;
         description
           "Время последнего успешного обновление или перепривязки.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 18";
       }
       leaf preferred-lifetime {
         type dhc6:timer-seconds32;
         description
           "Предпочтительный срок действия в секундах.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 6";
       }
       leaf valid-lifetime {
         type dhc6:timer-seconds32;
         description
           "Срок действия аренды в секундах.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 6";
       }
       leaf lease-t1 {
         type dhc6:timer-seconds32;
         description
           "Интервал, после которого клиенту нужно связаться с сервером,
            где были получены адреса из IA_NA, для продления срока
            действия адресов, выделенных для IA_PD.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 4.2";
       }
       leaf lease-t2 {
         type dhc6:timer-seconds32;
         description
           "Интервал, после которого клиенту нужно связаться с любым
            доступным сервером для продления срока действия адресов,
            выделенных IA_PD.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 4.2";
       }
       uses dhc6:status;
     }

     grouping message-statistics {
       description
         "Счётчики для сообщений DHCPv6.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время, последнего разрыва одного или нескольких счётчиков 
            сервера DHCPv6. Если разрывов с последней реинициализации 
            локальной подсистемы управления не было, узел содержит
            время реинициализации локальной подсистемы управления.";
       }
       leaf solicit-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Solicit (1).";
       }
       leaf advertise-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Advertise (2).";
       }
       leaf request-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Request (3).";
       }
       leaf confirm-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Confirm (4).";
       }
       leaf renew-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Renew (5).";
       }
       leaf rebind-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Rebind (6).";
       }
       leaf reply-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Reply (7).";
       }
       leaf release-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Release (8).";
       }
       leaf decline-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Decline (9).";
       }
       leaf reconfigure-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Reconfigure (10).";
       }
       leaf information-request-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Information-request (11).";
       }
       leaf discarded-message-count {
         type yang:counter32;
         config false;
         description
           "Число сообщений, отброшенных по любым причинам.";
       }
     }

     grouping preference-option-group {
       description
         "OPTION_PREFERENCE (7) Preference Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.8";
       container preference-option {
         description
           "OPTION_PREFERENCE (7) Preference Option.";
         leaf pref-value {
           type uint8;
           description
             "Уровень предпочтения для сервера в этом сообщении. 
              1-октетное целое число без знака.";
         }
       }
     }

     grouping server-unicast-option-group {
       description
         "OPTION_UNICAST (12) Server Unicast Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.12";
       container server-unicast-option {
         description
           "OPTION_UNICAST (12) Server Unicast Option.";
         leaf server-address {
           type inet:ipv6-address;
           description
             "128-битовый адрес, по которому клиенту следует передавать
              сообщения, ддоставляемые индивидуально (unicast).";
         }
       }
     }

     grouping reconfigure-message-option-group {
       description
         "OPTION_RECONF_MSG (19) Reconfigure Message Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.19";
       container reconfigure-message-option {
         description
           "OPTION_RECONF_MSG (19) Reconfigure Message Option.";
         leaf msg-type {
           type uint8;
           description
             "5 для Renew, 6 для Rebind, 11 для Information-request.";
         }
       }
     }

     grouping info-refresh-time-option-group {
       description
         "OPTION_INFORMATION_REFRESH_TIME (32) Information Refresh
          Time Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.23";
       container info-refresh-time-option {
         description
           "OPTION_INFORMATION_REFRESH_TIME (32) Information Refresh
            Time Option.";
         leaf info-refresh-time {
           type dhc6:timer-seconds32;
           description
             "Верхняя граница времени ожидания клиентом перед 
              обновлением сведений, полученных от сервера DHCP.";
         }
       }
     }

     grouping sol-max-rt-option-group {
       description
         "OPTION_SOL_MAX_RT (82) SOL_MAX_RT Option (тайм-аут 
          Max Solicit).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.24";
       container sol-max-rt-option {
         description
           "OPTION_SOL_MAX_RT (82) SOL_MAX_RT Option.";
         leaf sol-max-rt-value {
           type dhc6:timer-seconds32;
           description
             "Значение тайм-аута Maximum Solicit.";
         }
       }
     }

     grouping inf-max-rt-option-group {
       description
         "OPTION_INF_MAX_RT (83) INF_MAX_RT Option (тайм-аут Max
           Information-request).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.25";
       container inf-max-rt-option {
         description
           "OPTION_INF_MAX_RT (83) INF_MAX_RT Option.";
         leaf inf-max-rt-value {
           type dhc6:timer-seconds32;
           description
             "Тайм-аут Maximum Information-request.";
         }
       }
     }

     /*
      * Узлы данных
      */

     container dhcpv6-server {
       description
         "Узлы конфигурации для сервера DHCPv6.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 18.3";
       leaf enabled {
         type boolean;
         description
           "Включает функции сервера DHCP.";
       }
       leaf server-duid {
         type dhc6:duid;
         description
           "DUID of the server.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 11";
       }
       container vendor-config {
         description
           "Контейнер для фирменных дополнений и зависящих от
            реализации узлов данных конфигурации.";
       }
       container option-sets {
         description
           "Сервер может разрешать настройку различных наборов опций для
            клиентов, соответствующих определенным параметрам, таким как
            топологическое местоположение и тип клиента. Список 
            option-set содержит набор опций и содержимое, возвращаемое 
            клиентам.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 21";
         list option-set {
           key "option-set-id";
           description
             "Определения YANG для опций DHCPv6 содержатся в отдельных 
              модулях и добавляются в этот контейнер, когда нужно.";
           leaf option-set-id {
             type string;
             description
               "Идентификатор набора опций.";
           }
           leaf description {
             type string;
             description
               "Необязательное поле для дополнительных сведений, 
                относящихся к набору опций.";
           }
           uses preference-option-group;
           uses dhc6:auth-option-group;
           uses server-unicast-option-group;
           uses dhc6:rapid-commit-option-group;
           uses dhc6:vendor-specific-information-option-group;
           uses reconfigure-message-option-group;
           uses dhc6:reconfigure-accept-option-group;
           uses info-refresh-time-option-group;
           uses sol-max-rt-option-group;
           uses inf-max-rt-option-group;
         }
       }
       container class-selector {
         description
           "Серверы DHCPv6 применяют функцию class-selector для
            идентификации и классификации входящих сообщений от клиентов
            для предоставления тем корректной конфигурации. Механизмы
            реализации этой функции различаются в реализациях, поэтому
            их невозможно включить в этот модуль. Контейнер служит для
            дополнений class-selector YANG от разработчиков.";
       }
       container allocation-ranges {
         description
           "Эта модель основана на иерархии выделения адресов и 
            параметров. Верхний уровень является «глобальным» и задаётся 
            как контейнер для всех allocation-ranges. В его иерархии
            размещаются отдельные allocation-ranges.";
         uses resource-config;
         list allocation-range {
           key "id";
           description
             "Диапазоны сетей, указываемые ключом id.";
           leaf id {
             type string;
             mandatory true;
             description
               "Уникальный идентификатор диапазона выделения.";
           }
           leaf description {
             type string;
             description
               "Описание диапазона выделения.";
           }
           leaf network-prefix {
             type inet:ipv6-prefix;
             mandatory true;
             description
               "Префикс сети.";
           }
           uses resource-config;
           container address-pools {
             if-feature "na-assignment";
             description
               "Конфигурация для пулов адресов сервера DHCPv6.";
             list address-pool {
               key "pool-id";
               description
                 "Список пулов адресов для выделения клиентам, 
                  различаемых по pool-id.";
               leaf pool-id {
                 type string;
                 mandatory true;
                 description
                   "Уникальный идентификатор пула.";
               }
               leaf pool-prefix {
                 type inet:ipv6-prefix;
                 mandatory true;
                 description
                   "Префикс IPv6 для пула, которому следует быть в
                    заданном network-prefix, если тот имеется.";
               }
               leaf start-address {
                 type inet:ipv6-address-no-zone;
                 mandatory true;
                 description
                   "Начальный адрес пула IPv6.";
               }
               leaf end-address {
                 type inet:ipv6-address-no-zone;
                 mandatory true;
                 description
                   "Конечный адрес пула IPv6.";
               }
               leaf max-address-utilization {
                 type dhc6:threshold;
                 description
                   "Максимальное число адресов из пула, которые можно
                    выделить одновременно, в процентах от доступного
                    числа адресов (end-address - start-address + 1)
                    с округлением вверх. Служит для установки значения
                    для address-pool-utilization-threshold-exceeded.";
               }
               uses resource-config;
               container host-reservations {
                 description
                   "Конфигурация резервирований хостов из пула.";
                 list host-reservation {
                   key "reserved-addr";
                   description
                     "Список резервирований хостов.";
                   leaf client-duid {
                     type dhc6:duid;
                     description
                       "DUID клиента для резервирования.";
                   }
                   leaf reserved-addr {
                     type inet:ipv6-address;
                     description
                       "Зарезервированный адрес IPv6.";
                   }
                   uses resource-config;
                 }
               }
               container active-leases {
                 config false;
                 description
                   "Состояние для активной аренды клиентов.";
                 leaf total-count {
                   type uint64;
                   mandatory true;
                   description
                     "Общее число адресов в пуле.";
                 }
                 leaf allocated-count {
                   type uint64;
                   mandatory true;
                   description
                     "Число уже выделенных адресов или префиксов пула.";
                 }
                 list active-lease {
                   key "leased-address";
                   description
                     "Список активных аренд адресов.";
                   leaf leased-address {
                     type inet:ipv6-address;
                     description
                       "Запись для активной аренды адреса.";
                   }
                   uses lease-information;
                 }
               }
             }
           }
           container prefix-pools {
             if-feature "prefix-delegation";
             description
               "Конфигурация пулов префиксов сервера DHCPv6.";
             list prefix-pool {
               key "pool-id";
               description
                 "Список префиксов для выделения клиентам, 
                  различаемых по pool-id.";
               leaf pool-id {
                 type string;
                 mandatory true;
                 description
                   "Уникальный идентификатор пула.";
               }
               leaf pool-prefix {
                 type inet:ipv6-prefix;
                 mandatory true;
                 description
                   "Префикс IPv6 для пула, которому следует быть в
                    network-prefix, если тот задан.";
               }
               leaf client-prefix-length {
                 type uint8 {
                   range "1 .. 128";
                 }
                 mandatory true;
                 description
                   "Размер префиксов, делегируемых клиентам.";
               }
               leaf max-pd-space-utilization {
                 type dhc6:threshold;
                 description
                   "Максимальное число префиксов из пула, которые можно
                    выделить одновременно, в процентах от доступного
                    числа префиксов (end-address - start-address + 1)
                    с округлением вверх. Служит для установки значения
                    для prefix-pool-utilization-threshold-exceeded.";
               }
               uses resource-config;
               container host-reservations {
                 description
                   "Конфигурация для резервирований хостов из пула
                    префиксов.";
                 list prefix-reservation {
                   key "reserved-prefix";
                   description
                     "Зарезервированное резервирование префикса.";
                   leaf client-duid {
                     type dhc6:duid;
                     description
                       "DUID клиента для резервирования.";
                   }
                   leaf reserved-prefix {
                     type inet:ipv6-prefix;
                     description
                       "Зарезервированный префикс IPv6.";
                   }
                   leaf reserved-prefix-len {
                     type uint8;
                     description
                       "Размер зарезервированного префикса IPv6.";
                   }
                 }
                 uses resource-config;
               }
               container active-leases {
                 config false;
                 description
                   "Состояние, связанное с активной арендой префиксов 
                    клиентами.";
                 leaf total-count {
                   type uint64;
                   mandatory true;
                   description
                     "Общее число префиксов в пуле.";
                 }
                 leaf allocated-count {
                   type uint64;
                   mandatory true;
                   description
                     "Число уже выделенных из пула префиксов.";
                 }
                 list active-lease {
                   key "leased-prefix";
                   description
                     "Список активных аренд префиксов.";
                   leaf leased-prefix {
                     type inet:ipv6-prefix;
                     description
                       "Запись для активной аренды префикса.";
                   }
                   uses lease-information;
                 }
               }
             }
           }
         }
         container statistics {
           description
             "Счётчики сообщений DHCPv6 для сервера.";
           uses message-statistics;
         }
       }
     }

     /*
      * RPC
      */

     rpc delete-address-lease {
       nacm:default-deny-all;
       if-feature "na-assignment";
       description
         "Удаляет активную аренду адреса из базы данных сервера.
          Это не отзывает адрес у клиента и тот может обновить аренду.";
       input {
         leaf lease-address-to-delete {
           type leafref {
             path "/dhcpv6-server/allocation-ranges/"
                + "allocation-range/address-pools/address-pool"
                + "/active-leases/active-lease/leased-address";
           }
           mandatory true;
           description
             "Адрес IPv6 из удаляемой на сервере активной аренды.";
         }
       }
       output {
         leaf return-message {
           type string;
           description
             "Отклик от сервера. По возможности в сообщение следует
              включать идентификатор языка.";
           reference
             "BCP 18 (RFC 2277) IETF Policy on Character Sets
              and Languages, Section 4.2";
         }
       }
     }

     rpc delete-prefix-lease {
       nacm:default-deny-all;
       if-feature "prefix-delegation";
       description
         "Удаляет активную аренду префикса клиентом из базы сервера.
          Это не отзывает префикс клиента и тот может обновить его.";
       input {
         leaf lease-prefix-to-delete {
           type leafref {
             path "/dhcpv6-server/allocation-ranges/"
                + "allocation-range/prefix-pools/prefix-pool"
                + "/active-leases/active-lease/leased-prefix";
           }
           mandatory true;
           description
             "Префикс IPv6 активной аренды, удаляемой с сервера.";
         }
       }
       output {
         leaf return-message {
           type string;
           description
             "Отклик от сервера. По возможности в сообщение следует
              включать идентификатор языка.";
           reference
             "BCP 18 (RFC 2277) IETF Policy on Character Sets
              and Languages, Section 4.2";
         }
       }
     }

     /*
      * Уведомления
      */

     notification address-pool-utilization-threshold-exceeded {
       if-feature "na-assignment";
       description
         "Использование пула адресов превышает порог, заданный
          max-address-utilization.";
       leaf pool-id {
         type leafref {
           path "/dhcpv6-server/allocation-ranges/"
              + "allocation-range/address-pools/address-pool"
              + "/pool-id";
         }
         mandatory true;
         description
           "Leafref для пула адресов, связанного с уведомлением.";
       }
       leaf total-pool-addresses {
         type uint64;
         mandatory true;
         description
           "Общее число адресов в пуле (end-address -
            start-address + 1).";
       }
       leaf max-allocated-addresses {
         type uint64;
         mandatory true;
         description
           "Максимальное число адресов, которые можно одновременно
            выделить из пула. Это значение может быть меньше общего
            числа адресов. Рассчитывается как max-address-utilization
            (в процентах) от total-pool-addresses с округлением вверх.";
       }
       leaf allocated-address-count {
         type uint64;
         mandatory true;
         description
           "Общее число адресов, выделенных из пула.";
       }
     }

     notification prefix-pool-utilization-threshold-exceeded {
       if-feature "prefix-delegation";
       description
         "Передаётся при превышении порога использования пула, 
          заданного max-pd-space-utilization.";
       leaf pool-id {
         type leafref {
           path "/dhcpv6-server/allocation-ranges"
              + "/allocation-range/prefix-pools/prefix-pool/pool-id";
         }
         mandatory true;
         description
           "Уникальный идентификатор пула.";
       }
       leaf total-pool-prefixes {
         type uint64;
         mandatory true;
         description
           "Общее число префиксов в пуле.";
       }
       leaf max-allocated-prefixes {
         type uint64;
         mandatory true;
         description
           "Максимальное число префиксов, которые можно одновременно
            выделить из пула. Это значение может быть меньше общего
            числа префиксов. Рассчитывается как max-prefix-utilization
            (в процентах) от total-pool-prefixes с округлением вверх.";
       }
       leaf allocated-prefixes-count {
         type uint64;
         mandatory true;
         description
           "Число выделенных из пула префиксов.";
       }
     }

     notification invalid-client-detected {
       description
         "Передаётся при обнаружении сервером непригодного клиента.";
       leaf message-type {
         type enumeration {
           enum solicit {
             description
               "Сообщение Solicit (1).";
           }
           enum request {
             description
               "Сообщение Request (3).";
           }
           enum confirm {
             description
               "Сообщение Confirm (4).";
           }
           enum renew {
             description
               "Сообщение Renew (5).";
           }
           enum rebind {
             description
               "Сообщение Rebind (6).";
           }
           enum release {
             description
               "Сообщение Release (8).";
           }
           enum decline {
             description
               "Сообщение Decline (9).";
           }
           enum info-request {
             description
               "Сообщение Information request (11).";
           }
         }
         description
           "Тип полученного сервером сообщения, вызвавшего ошибку.";
       }
       leaf duid {
         type dhc6:duid;
         description
           "DUID клиента.";
       }
       leaf description {
         type string;
         description
           "Описание события (например, код ошибки или сообщение 
            журнала).";
       }
     }

     notification decline-received {
       if-feature "na-assignment";
       description
         "Передаётся при получении сервером Decline (9) от клиента.";
       leaf duid {
         type dhc6:duid;
         description
           "DUID клиента.";
       }
       list declined-resources {
         description
           "Список отвергнутых адресов и префиксов.";
         choice resource-type {
           description
             "Тип отвергнутого ресурса.";
           case declined-address {
             leaf address {
               type inet:ipv6-address;
               description
                 "Отвергнутый адрес.";
             }
           }
           case declined-prefix {
             leaf prefix {
               type inet:ipv6-prefix;
               description
                 "Отвергнутый префикс.";
             }
           }
         }
       }
     }

     notification non-success-code-sent {
       description
         "Передаётся при отличном от успеха коде состояния.";
       leaf duid {
         type dhc6:duid;
         description
           "DUID клиента.";
       }
       uses dhc6:status;
     }
   }
   <CODE ENDS>

4.3. Модуль YANG для ретранслятора DHCPv6

Этот модуль импортирует определения типов из [RFC6991] и модули из [RFC8341] и [RFC8343].

   <CODE BEGINS> file "ietf-dhcpv6-relay@2022-06-20.yang"
   module ietf-dhcpv6-relay {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dhcpv6-relay";
     prefix dhc6-rly;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-dhcpv6-common {
       prefix dhc6;
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG определяет компоненты настройки и 
        управления для ретрансляторов DHCPv6.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

     /*
      * Свойства (функции)
      */

     feature prefix-delegation {
       description
         "Включается, если ретранслятор работает как делегирующий
          маршрутизатор для префиксов DHCPv6.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.3";
     }

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

     grouping pd-lease-state {
       description
         "State data for the relay.";
       list pd-leases {
         key "ia-pd-prefix";
         config false;
         description
           "Сведения об активном делегировании префикса IA_PD.";
         leaf ia-pd-prefix {
           type inet:ipv6-prefix;
           description
             "Делегированный префикс.";
         }
         leaf last-renew {
           type yang:date-and-time;
           description
             "Время последнего обновления делегированного префикса.";
         }
         leaf client-peer-address {
           type inet:ipv6-address;
           description
             "Партнерский адрес арендующего клиента.";
         }
         leaf client-duid {
           type dhc6:duid;
           description
             "DUID арендующего клиента.";
         }
         leaf server-duid {
           type dhc6:duid;
           description
             "DUID делегирующего сервера.";
         }
       }
     }

     grouping message-statistics {
       description
         "Счётчики для разных типов сообщений DHCPv6.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время, последнего разрыва одного или нескольких счётчиков 
            ретранслятора DHCPv6. Если разрывов после реинициализации 
            локальной подсистемы управления не было, узел содержит
            время реинициализации локальной подсистемы управления.";
       }
       leaf solicit-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Solicit (1).";
       }
       leaf advertise-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Advertise (2).";
       }
       leaf request-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Request (3).";
       }
       leaf confirm-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Confirm (4).";
       }
       leaf renew-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Renew (5).";
       }
       leaf rebind-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Rebind (6).";
       }
       leaf reply-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Reply (7).";
       }
       leaf release-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Release (8).";
       }
       leaf decline-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Decline (9).";
       }
       leaf reconfigure-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Reconfigure (10).";
       }
       leaf information-request-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Information-request (11).";
       }
       leaf unknown-message-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений неизвестного типа.";
       }
       leaf unknown-message-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений неизвестного типа.";
       }
       leaf discarded-message-count {
         type yang:counter32;
         config false;
         description
           "Число сообщений, отброшенных по любой причине.";
       }
     }

     grouping global-statistics {
       description
         "Глобальная статистика для устройства.";
       leaf relay-forward-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Relay-forward (12).";
       }
       leaf relay-forward-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Relay-forward (12).";
       }
       leaf relay-reply-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Relay-reply (13).";
       }
       leaf relay-forward-unknown-sent-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Relay-forward (12) с
            сообщением неизвестного типа.";
       }
       leaf relay-forward-unknown-received-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Relay-forward (12) с
            сообщением неизвестного типа.";
       }
       leaf discarded-message-count {
         type yang:counter32;
         config false;
         description
           "Число сообщений, отброшенных по любой причине.";
       }
     }

     grouping interface-id-option-group {
       description
         "OPTION_INTERFACE_ID (18) Interface-Id Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.18";
       container interface-id-option {
         description
           "OPTION_INTERFACE_ID (18) Interface-Id Option.";
         leaf interface-id {
           type binary;
           description
             "Необрабатываемое (opaque) значение произвольного размера,
              создаваемое агентом ретрансляции для идентификации одного
              из интерфейсов этого агента.";
         }
       }
     }

     /*
      * Узлы данных
      */

     container dhcpv6-relay {
       description
         "Контейнер с узлами данных конфигурации для ретранслятора.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 19";
       leaf enabled {
         type boolean;
         description
           "Глобально включает функцию ретрансляции DHCP.";
       }
       list relay-if {
         key "if-name";
         description
           "Список интерфейсов, настроенных для ретрансляции DHCPv6.";
         leaf if-name {
           type if:interface-ref;
           description
             "interface-ref для интерфейса ретранслятора.";
         }
         leaf enabled {
           type boolean;
           description
             "Включает функцию ретрансляции DHCP на этом интерфейсе.";
         }
         leaf-list destination-address {
           type inet:ipv6-address;
           description
             "На каждом агенте ретрансляции DHCPv6 может быть задан
              список адресов получателей для ретранслируемых сообщений.
              Список может включать индивидуальные, групповые и другие
              действительные адреса.";
         }
         leaf link-address {
           type inet:ipv6-address;
           description
             "Адрес, который сервер может использовать для идентификации
              канала, где расположен клиент.";
         }
         container relay-options {
           description
             "Определения опций DHCPv6, которые может передавать
              ретранслятор, добавляются сюда из других модулей YANG.";
           uses dhc6:auth-option-group;
           uses interface-id-option-group;
         }
         container statistics {
           description
             "Счётчики сообщений DHCPv6 для интерфейса ретранслятора.";
           uses message-statistics;
         }
         container prefix-delegation {
           if-feature "prefix-delegation";
           presence "Разрешает делегирование префиксов для интерфейса.";
           description
             "Контролирует и хранит сведения о статусе делегирования
              префиксов.";
           uses pd-lease-state;
         }
       }
       container statistics {
         description
           "Глобальные счётчики DHCPv6 для ретранслятора.";
         uses global-statistics;
       }
     }

     /*
      * RPC
      */

     rpc clear-prefix-entry {
       nacm:default-deny-all;
       if-feature "prefix-delegation";
       description
         "Очищает запись для активного делегирования префикса на
          ретрансляторе.";
       reference
         "RFC 8987: DHCPv6 Prefix Delegating Relay Requirements,
          Section 4.4";
       input {
         leaf lease-prefix {
           type leafref {
             path "/dhcpv6-relay/relay-if/prefix-delegation"
                + "/pd-leases/ia-pd-prefix";
           }
           mandatory true;
           description
             "Префикс IPv6 активной аренды, удаляемой с ретранслятора.";
         }
       }
       output {
         leaf return-message {
           type string;
           description
             "Отклик от сервера, включающий по возможности идентификатор
              языка.";
           reference
             "BCP 18 (RFC 2277) IETF Policy on Character Sets
              and Languages, Section 4.2";
         }
       }
     }

     rpc clear-client-prefixes {
       nacm:default-deny-all;
       if-feature "prefix-delegation";
       description
         "Очищает все активные записи префиксов для одного клиента.";
       reference
         "RFC 8987: DHCPv6 Prefix Delegating Relay Requirements,
          Section 4.4";
       input {
         leaf client-duid {
           type dhc6:duid;
           mandatory true;
           description
             "DUID клиента.";
         }
       }
       output {
         leaf return-message {
           type string;
           description
             "Отклик от сервера, включающий по возможности идентификатор
              языка.";
           reference
             "BCP 18 (RFC 2277) IETF Policy on Character Sets
              and Languages, Section 4.2";
         }
       }
     }

     rpc clear-interface-prefixes {
       nacm:default-deny-all;
       if-feature "prefix-delegation";
       description
         "Очищает все привязки делегированных префиксов на интерфейсе
          ретранслятора.";
       reference
         "RFC 8987: DHCPv6 Prefix Delegating Relay Requirements,
          Section 4.4";
       input {
         leaf interface {
           type leafref {
             path "/dhcpv6-relay/relay-if/if-name";
           }
           mandatory true;
           description
             "Указывает интерфейс ретранслятора, для которого удаляются 
              все активные привязки делегированных префиксов.";
         }
       }
       output {
         leaf return-message {
           type string;
           description
             "Отклик от сервера, включающий по возможности идентификатор
              языка.";
           reference
             "BCP 18 (RFC 2277) IETF Policy on Character Sets
              and Languages, Section 4.2";
         }
       }
     }

     /*
      * Уведомления
      */

     notification relay-event {
       description
         "Уведомления о событиях ретранслятора DHCPv6.";
       container topology-change {
         description
           "Передаётся при удалении интерфейса с конфигурацией или 
            состоянием DHCPv6 из if:interface-refs.";
         leaf relay-if-name {
           type leafref {
             path "/dhcpv6-relay/relay-if/if-name";
           }
           description
             "Имя удаляемого интерфейса.";
         }
         leaf last-ipv6-addr {
           type inet:ipv6-address;
           description
             "Последний адрес IPv6, настроенный на интерфейсе.";
         }
       }
     }
   }
   <CODE ENDS>

4.4. Модуль YANG для клиента DHCPv6

Этот модуль импортирует определения типов из [RFC6991] и модули из [RFC8343].

   <CODE BEGINS> file "ietf-dhcpv6-client@2022-06-20.yang"
   module ietf-dhcpv6-client {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dhcpv6-client";
     prefix dhc6-clnt;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-dhcpv6-common {
       prefix dhc6;
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG определяет компоненты настройки и 
        управления для клиентов DHCPv6.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

     /*
      * Свойства (функции)
      */

     feature non-temp-addr {
       description
         "Клиент поддерживает выделение постоянных адресов DHCPv6.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.2";
     }

     feature temp-addr {
       description
         "Клиент поддерживает выделение временных адресов DHCPv6.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.5";
     }

     feature prefix-delegation {
       description
         "Клиент реализует делегирование префиксов DHCPv6.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6.3";
     }

     feature anon-profile {
       description
         "Клиент поддерживает профили анонимности DHCP.";
       reference
         "RFC 7844: Anonymity Profiles for DHCP Clients";
     }

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

     grouping message-statistics {
       description
         "Счётчики сообщений DHCPv6.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время, последнего разрыва одного или нескольких счётчиков 
            клиента DHCPv6. Если разрывов после реинициализации 
            локальной подсистемы управления не было, узел содержит
            время реинициализации локальной подсистемы управления.";
       }
       leaf solicit-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Solicit (1).";
       }
       leaf advertise-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Advertise (2).";
       }
       leaf request-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Request (3).";
       }
       leaf confirm-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Confirm (4).";
       }
       leaf renew-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Renew (5).";
       }
       leaf rebind-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Rebind (6).";
       }
       leaf reply-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Reply (7).";
       }
       leaf release-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Release (8).";
       }
       leaf decline-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Decline (9).";
       }
       leaf reconfigure-count {
         type yang:counter32;
         config false;
         description
           "Число принятых сообщений Reconfigure (10).";
       }
       leaf information-request-count {
         type yang:counter32;
         config false;
         description
           "Число переданных сообщений Information-request (11).";
       }
       leaf discarded-message-count {
         type yang:counter32;
         config false;
         description
           "Число сообщений, отброшенных по любой причине.";
       }
     }

     grouping lease-state {
       description
         "Сведения об активной аренде IA_NA.";
       leaf preferred-lifetime {
         type dhc6:timer-seconds32;
         description
           "Предпочтительный срок аренды адреса в секундах.";
       }
       leaf valid-lifetime {
         type dhc6:timer-seconds32;
         description
           "Действительный срок аренды адреса в секундах.";
       }
       leaf allocation-time {
         type yang:date-and-time;
         description
           "Дата и время первой аренды адреса.";
       }
       leaf last-renew-rebind {
         type yang:date-and-time;
         description
           "Время последнего обновления или перепривязки
            арендованного адреса.";
       }
       leaf server-duid {
         type dhc6:duid;
         description
           "DUID сервера аренды.";
       }
       uses dhc6:status;
     }

     grouping option-request-option-group {
       description
         "OPTION_ORO (6) Option Request Option. Клиент ДОЛЖЕН включать
          опцию Option Request в сообщения Solicit, Request, Renew,
          Rebind, Information-request для информирования сервера об
          опциях, которые он хочет получать от сервера.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Sections 21.23, 21.24, 21.25, & 21.7";
       container option-request-option {
         description
           "OPTION_ORO (6) Option Request Option.";
         leaf-list oro-option {
           type uint16;
           description
             "Список запрошенных клиентом опций, указанный кодом опции.
              Список ДОЛЖЕН включать код для опции SOL_MAX_RT (82) при
              включении в сообщения Solicit. Если эта опция передана в
              сообщении Information-request, ДОЛЖНЫ включаться коды
              OPTION_INFORMATION_REFRESH_TIME (32) и INF_MAX_RT (83).";
         }
       }
     }

     grouping user-class-option-group {
       description
         "OPTION_USER_CLASS (15) User Class Option";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.15";
       container user-class-option {
         presence "Настройка опции";
         description
           "OPTION_USER_CLASS (15) User Class Option.";
         list user-class-data-instance {
           key "user-class-data-id";
           min-elements 1;
           description
             "Классы пользователей, в которые входит клиент.";
           leaf user-class-data-id {
             type uint8;
             description
               "Идентификатор данных класса пользователей.";
           }
           leaf user-class-data {
             type binary;
             description
               "Необрабатываемое (opaque) поле, представляющее
                User Class, к которому относится пользователь.";
           }
         }
       }
     }

     grouping vendor-class-option-group {
       description
         "OPTION_VENDOR_CLASS (16) Vendor Class Option.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6), Section 21.16";
       container vendor-class-option {
         description
           "OPTION_VENDOR_CLASS (16) Vendor Class Option.";
         list vendor-class-option-instances {
           key "enterprise-number";
           description
             "Опция Vendor Class может указываться в сообщении не один
              раз. Каждая запись указывает содержимое 1 экземпляра.";
           leaf enterprise-number {
             type uint32;
             description
               "Enterprise Number производителя от IANA.";
           }
           list vendor-class-data-element {
             key "vendor-class-data-id";
             description
               "Классы производителя, в которые входит клиент.";
             leaf vendor-class-data-id {
               type uint8;
               description
                 "Идентификатор данных Vendor Class.";
             }
             leaf vendor-class-data {
               type binary;
               description
                 "Необрабатываемое (opaque) поле, представляющее
                  Vendor Class, к которому относится пользователь.";
             }
           }
         }
       }
     }

     /*
      * Узлы данных
      */
     container dhcpv6-client {
       description
         "Конфигурация и состояние клиента DHCPv6.";
       leaf enabled {
         type boolean;
         default "true";
         description
           "Глобально включает функции клиента DHCP.";
       }
       leaf client-duid {
         if-feature "(non-temp-addr or prefix-delegation "
                  + "or temp-addr) and not anon-profile";
         type dhc6:duid;
         description
           "DUID клиента, который будет применяться на всех
            интерфейсах с поддержкой DHCPv6.";
         reference
           "RFC 8415: Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6), Section 11";
       }
       list client-if {
         key "if-name";
         description
           "Список интерфейсов, для которых клиент запрашивает
            конфигурацию DHCPv6.";
         leaf if-name {
           type if:interface-ref;
           mandatory true;
           description
             "Ссылка на запись интерфейса, к которой относится 
              запрошенная конфигурация.";
         }
         leaf enabled {
           type boolean;
           default "true";
           description
             "Включает функции клиента DHCP для этого интерфейса.";
         }
         leaf interface-duid {
           if-feature "(non-temp-addr or prefix-delegation "
                    + "or temp-addr) and anon-profile";
           type dhc6:duid;
           description
             "DUID клиента для интерфейсов, использующих профили
              анонимности DHCP.";
           reference
             "RFC 7844: Anonymity Profiles for DHCP Clients,
              Section 3";
         }
         container client-configured-options {
           description
             "Определения для опций DHCPv6, которые можно передавать
              клиенту. Дополнительные опции могут добавляться сюда из
              других модулей YANG, когда это нужно.";
           uses option-request-option-group;
           uses dhc6:rapid-commit-option-group;
           uses user-class-option-group;
           uses vendor-class-option-group;
           uses dhc6:vendor-specific-information-option-group;
           uses dhc6:reconfigure-accept-option-group;
         }
         list ia-na {
           if-feature "non-temp-addr";
           key "ia-id";
           description
             "Конфигурация, связанная с IA_NA.";
           reference
             "RFC 8415: Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6), Section 13.1";
           leaf ia-id {
             type uint32;
             description
               "Уникальный идентификатор для IA_NA.";
             reference
               "RFC 8415: Dynamic Host Configuration Protocol
                for IPv6 (DHCPv6), Section 12";
           }
           container ia-na-options {
             description
               "Точка дополнения для опций, которые клиент может
                передавать в поле опций IA_NA в OPTION_IA_NA.";
           }
           container lease-state {
             config false;
             description
               "Сведения об активной аренде IA_NA.";
             leaf ia-na-address {
               type inet:ipv6-address;
               description
                 "Арендуемый адрес.";
             }
             leaf lease-t1 {
               type dhc6:timer-seconds32;
               description
                 "Интервал, по истечении которого клиенту следует 
                  связаться с сервером, где были получены адреса из
                  IA_NA, для продления срока их действия.";
             }
             leaf lease-t2 {
               type dhc6:timer-seconds32;
               description
                 "Интервал, по истечении которого клиенту следует 
                  связаться с любым доступным сервером для продления
                  срока действия адресов, выделенных дляIA_NA.";
             }
             uses lease-state;
           }
         }
         list ia-ta {
           if-feature "temp-addr";
           key "ia-id";
           description
             "Конфигурация, связанная с адресами IA_TA.";
           reference
             "RFC 8415: Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6), Section 13.2";
           leaf ia-id {
             type uint32;
             description
               "Уникальный идентификатор IA_TA.";
             reference
               "RFC 8415: Dynamic Host Configuration Protocol
                for IPv6 (DHCPv6), Section 12";
           }
           container ia-ta-options {
             description
               "Точка для добавления опций, которые клиент может 
                передавать в поле опций IA_TA в OPTION_IA_TA.";
           }
           container lease-state {
             config false;
             description
               "Сведения об активной аренде IA_TA.";
             leaf ia-ta-address {
               type inet:ipv6-address;
               description
                 "Арендуемый адрес.";
             }
             uses lease-state;
           }
         }
         list ia-pd {
           if-feature "prefix-delegation";
           key "ia-id";
           description
             "Конфигурация для IA_PD.";
           reference
             "RFC 8415: Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6), Section 13.3";
           leaf ia-id {
             type uint32;
             description
               "Уникальный идентификатор IA_PD.";
             reference
               "RFC 8415: Dynamic Host Configuration Protocol
                for IPv6 (DHCPv6), Section 12";
           }
           leaf prefix-length-hint {
             type uint8 {
               range "1..128";
             }
             description
               "Рекомендуемое значение размера префикса в сообщениях
                серверу для указания размера делегируемого префикса.";
             reference
               "RFC 8415: Dynamic Host Configuration Protocol
                for IPv6 (DHCPv6), Section 18.2.1";
           }
           container ia-pd-options {
             description
               "Точка для добавления опций, которые клиент может 
                передавать в поле опций IA_PD в OPTION_IA_TA.";
           }
           container lease-state {
             config false;
             description
               "Сведения о делегированном префиксе IA_PD.";
             leaf ia-pd-prefix {
               type inet:ipv6-prefix;
               description
                 "Арендуемый делегированный префикс.";
             }
             leaf lease-t1 {
               type dhc6:timer-seconds32;
               description
                 "Интервал, по истечении которого клиенту следует 
                  связаться с сервером, где были получены адреса из
                  IA_NA, для продления срока действия адресов IA_PD.";
             }
             leaf lease-t2 {
               type dhc6:timer-seconds32;
               description
                 "Интервал, по истечении которого клиенту следует 
                  связаться с любым доступным сервером для продления 
                  срока действия адресов IA_PD.";
             }
             uses lease-state;
           }
         }
         container statistics {
           description
             "Счётчики сообщений DHCPv6 для клиента.";
           uses message-statistics;
         }
       }
     }

     /*
      * Уведомления
      */

     notification invalid-ia-address-detected {
       if-feature "non-temp-addr or temp-addr";
       description
         "Передаётся, когда адрес, полученный в опции IA, сочтен
          недействительным. Причиной может быть дублирование адресов
          или иной недействительный адрес.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 18.2.10.1";
       leaf ia-id {
         type uint32;
         mandatory true;
         description
           "IAID.";
       }
       leaf ia-na-t1-timer {
         type uint32;
         description
           "Значение поля T1 для выделения постоянного адреса
            (OPTION_IA_NA).";
       }
       leaf ia-na-t2-timer {
         type uint32;
         description
           "Значение поля preferred-lifetime для выделения постоянного
            адреса (OPTION_IA_NA).";
       }
       leaf invalid-address {
         type inet:ipv6-address;
         description
           "Адрес IP, сочтённый недействительным.";
       }
       leaf preferred-lifetime {
         type uint32;
         description
           "Значение поля preferred-lifetime в OPTION_IAADDR.";
       }
       leaf valid-lifetime {
         type uint32;
         description
           "Значение поля valid-lifetime в OPTION_IAADDR.";
       }
       leaf ia-options {
         type binary;
         description
           "Копия содержимого поля опций адреса IA.";
       }
       leaf description {
         type string;
         description
           "Описание причины недействительности IA.";
       }
     }

     notification transmission-failed {
       description
         "Передается при отказе передачи или повтора сообщения.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 7.6";
       leaf failure-type {
         type enumeration {
           enum solicit-timeout {
             description
               "Превышен тайм-аут Max Solicit (SOL_MAX_RT).";
           }
           enum request-timeout {
             description
               "Превышен тайм-аут Max Request (REQ_MAX_RT).";
           }
           enum request-retries-exceeded {
             description
               "Превышено число попыток Max Request (REC_MAX_RC).";
           }
           enum confirm-duration-exceeded {
             description
               "Превышена продолжительность Max Confirm (CNF_MAX_RD).";
           }
           enum renew-timeout {
             description
               "Превышен тайм-аут Max Renew (REN_MAX_RT).";
           }
           enum rebind-timeout {
             description
               "Превышен тайм-аут Max Rebind (REB_MAX_RT).";
           }
           enum info-request-timeout {
             description
               "Превышен тайм-аут Max Information-request (INF_MAX_RT)";
           }
           enum release-retries-exceeded {
             description
               "Превышено число попыток Max Release (REL_MAX_RC).";
           }
           enum decline-retries-exceeded {
             description
               "Превышено число попыток Max Decline (DEC_MAX_RT).";
           }
         }
         mandatory true;
         description
           "Описание отказа.";
       }
       leaf description {
         type string;
         description
           "Сведения об отказе, такие как число попыток и значения
            таймеров.";
       }
     }

     notification unsuccessful-status-code {
       description
         "Передаётся при получении клиентом сообщения с кодом
          неудачи в опции Status Code.";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 21.13";
       leaf server-duid {
         type dhc6:duid;
         mandatory true;
         description
           "DUID сервера, передавшего код неудачи.";
       }
       uses dhc6:status;
     }

     notification server-duid-changed {
       if-feature "non-temp-addr or prefix-delegation or "
                + "temp-addr";
       description
         "Передаётся при получении клиентом аренды от сервера, DUID
          которого отличается от сохранённого клиентом (например, в 
          отклике на сообщение Rebind).";
       reference
         "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 18.2.5";
       leaf new-server-duid {
         type dhc6:duid;
         mandatory true;
         description
           "DUID нового сервера.";
       }
       leaf previous-server-duid {
         type dhc6:duid;
         mandatory true;
         description
           "DUID прежнего сервера.";
       }
       leaf lease-ia-na {
         if-feature "non-temp-addr";
         type leafref {
           path "/dhcpv6-client/client-if/ia-na/ia-id";
         }
         description
           "Ссылка на аренду IA_NA.";
       }
       leaf lease-ia-ta {
         if-feature "temp-addr";
         type leafref {
           path "/dhcpv6-client/client-if/ia-ta/ia-id";
         }
         description
           "Ссылка на аренду IA_TA.";
       }
       leaf lease-ia-pd {
         if-feature "prefix-delegation";
         type leafref {
           path "/dhcpv6-client/client-if/ia-pd/ia-id";
         }
         description
           "Ссылка на аренду IA_PD.";
       }
     }
   }
   <CODE ENDS>

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

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

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

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

dhc6-srv/vendor-config

dhc6-srv/allocation-ranges

Атаки на службы (Denial-of-Service или DoS), такие как отключения сервера DHCP или удаление конфигурации пула адресов или префиксов.

dhc6-srv/option-sets

Различные атаки на основе изменения содержимого опций DHCPv6, ведущего к некоторым угрозам безопасности или приватности. Эти опции могут перенаправлять клиентов на серверы, контролируемые злоумышленником, например, путём изменения адреса сервера a DNS в опции DHCP для указания мошеннического сервера.

Ниже перечислены ветви и узлы ieft-dhcpv6-relay.yang, которые могут быть конфиденциальны или уязвимы.

dhc6-rly/relay-if

DoS-атаки на основе запрета функций ретрансляции DHCP или смены destination-address не отсутствующий адрес.

dhc6-rly/relay-if

Изменение destination-address для передачи сообщений мошенническому серверу DHCPv6.

Некоторые из операций RPC в этих модулях YANG могут быть чувствительны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким операциям. Эти RPC используют nacm:default-deny-all. Ниже указзаны операции модуля ieft-dhcpv6-relay.yang, которые могут быть чувствительны или уязвимы.

dhc6-rly/clear-prefix-entry

dhc6-rly/clear-client-prefixes

dhc6-rly/clear-interface-prefixes

Удаление или очистка активной аренды адреса или префикса, вызывающее DoS-атаку, поскольку трафик больше не будет маршрутизироваться клиенту.

Злоумышленник, передающий сообщения DHCPv6, которые заставляют сервер отправлять уведомления invalid-client-detected и decline-received, может организовать DoS-атаку. Такую атаку может смягчить отказ клиента NETCONF от подписки на затронутые атакой уведомления.

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

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

dhc6-srv/allocation-ranges/allocation-range/address-pools/address-pool/active-leases

Информация на сервере о клиентах с активной арендой.

dhc6-rly/relay-if/prefix-delegation/

Информация на ретрансляторе о клиентах с активной арендой.

Сведения, о заданных для сервера пулах адресов и префиксов могут применяться злоумышленниками для сетевой разведки [RFC7707]. Ниже указаны ветви и узлы данных, которые могут применяться для таких целей.

dhc6-srv/allocation-ranges/allocation-range/address-pools/address-pool/pool-prefix

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

dhc6-srv/allocation-ranges/allocation-range/prefix-pools/prefix-pool/pool-prefix

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

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

В [RFC7824] рассмотрены вопросы приватности DHCPv6, которые применимы и здесь.

Вопросы безопасности DHCPv6 рассмотрены [RFC8415]. Соображения безопасности из [RFC7950] применимы и здесь.

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

Этот документ регистрирует 4 URI и 4 модуля YANG.

6.1. Регистрация URI

В соответствии с этим документом агентство IANA зарегистрировало 4 URI в субреестре ns реестра IETF XML Registry [RFC3688].

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

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

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

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

6.2. Регистрация модулей YANG

В соответствии с этим документом агентство IANA зарегистрировало 4 модуля YANG в субреестре YANG Module Names [RFC6020] реестра YANG Parameters.

   name:           ietf-dhcpv6-server
   namespace:      urn:ietf:params:xml:ns:yang:ietf-dhcpv6-server
   maintained by IANA:  N
   prefix:         dhc6-srv
   reference:      RFC 9243

   name:           ietf-dhcpv6-relay
   namespace:      urn:ietf:params:xml:ns:yang:ietf-dhcpv6-relay
   maintained by IANA:  N
   prefix:         dhc6-rly
   reference:      RFC 9243

   name:           ietf-dhcpv6-client
   namespace:      urn:ietf:params:xml:ns:yang:ietf-dhcpv6-client
   maintained by IANA:  N
   prefix:         dhc6-clnt
   reference:      RFC 9243

   name:           ietf-dhcpv6-common
   namespace:      urn:ietf:params:xml:ns:yang:ietf-dhcpv6-common
   maintained by IANA:  N
   prefix:         dhc6
   reference:      RFC 9243

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

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

[BCP18] Alvestrand, H., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, January 1998. <https://www.rfc-editor.org/info/bcp18>

[IANA-DHCPV6-AUTH-NAMESPACES] IANA, «Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces», <https://www.iana.org/assignments/auth-namespaces>.

[IANA-DHCPV6-OPTION-CODES] IANA, «Option Codes», <https://www.iana.org/assignments/dhcpv6-parameters>.

[IANA-DHCPV6-STATUS-CODES] IANA, «DHCPv6 Status Codes», <https://www.iana.org/assignments/dhcpv6-parameters>.

[IANA-HARDWARE-TYPES] IANA, «Hardware Types», <https://www.iana.org/assignments/arp-parameters>.

[IANA-PEN] IANA, «Private Enterprise Numbers», <https://www.iana.org/assignments/enterprise-numbers>.

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

[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., «Authentication for DHCP Messages», RFC 3118, DOI 10.17487/RFC3118, June 2001, <https://www.rfc-editor.org/info/rfc3118>.

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

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

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

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

[RFC6355] Narten, T. and J. Johnson, «Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)», RFC 6355, DOI 10.17487/RFC6355, August 2011, <https://www.rfc-editor.org/info/rfc6355>.

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

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, «Anonymity Profiles for DHCP Clients», RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

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

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

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

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

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

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

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

[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, «DHCPv6 Prefix Delegating Relay Requirements», RFC 8987, DOI 10.17487/RFC8987, February 2021, <https://www.rfc-editor.org/info/rfc8987>.

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

[GROUPINGS-TLS] Watsen, K., «YANG Groupings for TLS Clients and TLS Servers», Work in Progress, Internet-Draft, draft-ietf-netconf-tls-client-server-28, 24 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-28>.

[RFC3319] Schulzrinne, H. and B. Volz, «Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers», RFC 3319, DOI 10.17487/RFC3319, July 2003, <https://www.rfc-editor.org/info/rfc3319>.

[RFC7707] Gont, F. and T. Chown, «Network Reconnaissance in IPv6 Networks», RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>.

[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, «Privacy Considerations for DHCPv6», RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.

Приложение A. Примеры деревьев данных

В этом приложении приведены примеры XML для деревьев данных разных элементов DHCPv6.

A.1. Примеры конфигурации сервера DHCPv6

Приведённый ниже пример показывает базовую конфигурацию сервера, задавая:

  • включение функций сервера DHCP;

  • DUID сервера;

  • набор опций (id=1) с настройкой опции Solicit Max Retry Timeout (SOL_MAX_RT (82));

  • один диапазон сети (2001:db8::/32);

  • один пул адресов, с начальным и конечным адресом, таймерами аренды и option-set-id 1 для указанного выше набора опций.

   <dhcpv6-server
       xmlns="urn:ietf:params:xml:ns:yang:ietf-dhcpv6-server">
     <enabled>true</enabled>
     <server-duid>000200090CC084D303000912</server-duid>
     <vendor-config/>
     <option-sets>
       <option-set>
         <option-set-id>1</option-set-id>
         <description>Example DHCP option set</description>
         <sol-max-rt-option>
           <sol-max-rt-value>3600</sol-max-rt-value>
         </sol-max-rt-option>
       </option-set>
     </option-sets>
     <class-selector/>
     <allocation-ranges>
       <valid-lifetime>54000</valid-lifetime>
       <renew-time>7200</renew-time>
       <rebind-time>32400</rebind-time>
       <preferred-lifetime>43200</preferred-lifetime>
       <allocation-range>
         <id>1</id>
         <description>example-allocation-range</description>
         <network-prefix>2001:db8::/32</network-prefix>
         <option-set-id>1</option-set-id>
         <address-pools>
           <address-pool>
             <pool-id>1</pool-id>
             <pool-prefix>2001:db8:1:1::/64</pool-prefix>
             <start-address>2001:db8:1:1::1000</start-address>
             <end-address>2001:db8:1:1::2000</end-address>
             <max-address-utilization>50</max-address-utilization>
             <option-set-id>1</option-set-id>
           </address-pool>
         </address-pools>
       </allocation-range>
     </allocation-ranges>
   </dhcpv6-server>

Рисунок 4. Пример XML для базовой конфигурации сервера.

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

   <address-pools>
     <address-pool>
       <pool-id>1</pool-id>
       <pool-prefix>2001:db8:1:1::/64</pool-prefix>
       <start-address>2001:db8:1:1::1000</start-address>
       <end-address>2001:db8:1:1::2000</end-address>
       <max-address-utilization>50</max-address-utilization>
       <option-set-id>1</option-set-id>
       <host-reservations>
         <host-reservation>
           <reserved-addr>2001:db8:1:1::1001</reserved-addr>
           <client-duid>00052001db81</client-duid>
           <option-set-id>1</option-set-id>
           <valid-lifetime>604800</valid-lifetime>
           <renew-time>86400</renew-time>
           <rebind-time>172800</rebind-time>
           <preferred-lifetime>345600</preferred-lifetime>
         </host-reservation>
       </host-reservations>
     </address-pool>
   </address-pools>

Рисунок 5. Пример XML для конфигурации сервера с резервированием для хостов.

В следующем фрагменте показан диапазон сети и пул для использования при делегировании префиксов клиентам. В примере каждый клиент получает префикс /56. Для max-pd-space-utilization задано значение 80%, поэтому уведомление prefix-pool-utilization-threshold-exceeded будет передаваться при превышении этого предела.

   <allocation-ranges>
     <allocation-range>
       <id>1</id>
       <description>prefix-pool-example</description>
       <network-prefix>2001:db8::/32</network-prefix>
       <prefix-pools>
         <valid-lifetime>54000</valid-lifetime>
         <renew-time>7200</renew-time>
         <rebind-time>32400</rebind-time>
         <preferred-lifetime>43200</preferred-lifetime>
         <prefix-pool>
           <pool-id>0</pool-id>
           <option-set-id>1</option-set-id>
           <pool-prefix>2001:db8:1::/48</pool-prefix>
           <client-prefix-length>56</client-prefix-length>
           <max-pd-space-utilization>80</max-pd-space-utilization>
         </prefix-pool>
       </prefix-pools>
     </allocation-range>
   </allocation-ranges>

Рисунок 6. Пример XML для конфигурации сервера с делегированием префиксов.

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

Пример показывает, как определения опций можно расширить с помощью дополнения (augmentat). В этом случае OPTION_SIP_SERVER_D (21) SIP Servers Domain-Name List из примера модуля в приложении B добавляется к набору опций сервера.

   <option-sets>
     <option-set>
       <option-set-id>1</option-set-id>
       <description>Example DHCP option set</description>
       <vendor-specific-information-options>
         <vendor-specific-information-option>
           <enterprise-number>32473</enterprise-number>
           <vendor-option-data>
             <sub-option-code>01</sub-option-code>
             <sub-option-data>1234abcd</sub-option-data>
           </vendor-option-data>
           <vendor-option-data>
             <sub-option-code>02</sub-option-code>
             <sub-option-data>abcd1234</sub-option-data>
           </vendor-option-data>
         </vendor-specific-information-option>
       </vendor-specific-information-options>
       <sol-max-rt-option>
         <sol-max-rt-value>3600</sol-max-rt-value>
       </sol-max-rt-option>
       <sip-server-domain-name-list-option
         xmlns="https://example.com/ns/example-dhcpv6-opt-sip-serv">
         <sip-server>
           <sip-serv-id>0</sip-serv-id>
           <sip-serv-domain-name>sip1.example.org</sip-serv-domain-name>
         </sip-server>
         <sip-server>
           <sip-serv-id>1</sip-serv-id>
           <sip-serv-domain-name>sip2.example.org</sip-serv-domain-name>
         </sip-server>
       </sip-server-domain-name-list-option>
     </option-set>
   </option-sets>

Рисунок 7. Пример XML для конфигурации сервера набором опций.

A.2. Пример конфигурации ретранслятора DHCPv6

Следующий пример показывает базовую конфигурацию для одного интерфейса ретранслятора DHCP и его взаимодействие с модулем ietf-interfaces. Показаны два документа XML, один для ietf-interfaces, другой для ietf-dhcpv6-relay, задающие:

  • конфигурацию с применением модуля ietf-interfaces, применяемую для настройки интерфейса ретранслятора;

  • включение функций ретранслятора DHCP глобально и для соответствующего интерфейса;

  • интерфейс с настройкой ретранслятора через interface-ref со ссылкой на модуль ietf-interfaces;

  • два целевых адресов для пересылки входящих сообщений DHCP;

  • значение link-address для передачи пересылаемых сообщений;

  • значение Interface ID Option (OPTION_INTERFACE_ID (18)) лоя включения в пересылаемые сообщения.

   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
     xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
     <interface>
       <name>eth0</name>
       <type>ianaift:ethernetCsmacd</type>
       <description>DHCPv6 Relay Interface</description>
       <enabled>true</enabled>
     </interface>
   </interfaces>

   <dhcpv6-relay xmlns="urn:ietf:params:xml:ns:yang:ietf-dhcpv6-relay">
     <enabled>true</enabled>
     <relay-if>
       <if-name>eth0</if-name>
       <enabled>true</enabled>
       <destination-address>2001:db8:2::1</destination-address>
       <destination-address>2001:db8:2::2</destination-address>
       <link-address>2001:db8:3::1</link-address>
       <relay-options>
         <interface-id-option>
           <interface-id>EXAMPLEINTERFACEID01</interface-id>
         </interface-id-option>
       </relay-options>
     </relay-if>
   </dhcpv6-relay>

Рисунок 8. Пример XML для базовой конфигурации ретранслятора.

A.3. Пример конфигурации клиента DHCPv6

Следующий пример показывает базовую конфигурацию клиента DHCP и его взаимодействие с модулем ietf-interfaces. Показаны два документа XML, один для ietf-interfaces, другой для ietf-dhcpv6-client, задающие:

  • конфигурацию с применением модуля ietf-interfaces, применяемую для настройки интерфейса клиента;

  • включение функций клиента DHCP глобально и для соответствующего интерфейса;

  • интерфейс с настройкой клиента через interface-ref со ссылкой на модуль ietf-interfaces;

  • DUID для интерфейса с DHCPv6;

  • список кодов опций, которые клиент будет запрашивать в своих Option Request Option (OPTION_ORO (6));

  • 1 экземпляр Vendor-specific Information Option (OPTION_VENDOR_OPTS (17)) с 1 элементом данных субопции;

  • запрос постоянного адреса IPv6 (IA_NA) с идентификатором интерфейса ассоциации 1;

  • запрос делегирования префикса IPv6 (IA_PD) с идентификатором интерфейса ассоциации 2.

   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
     xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
     <interface>
       <name>eth0</name>
       <type>ianaift:ethernetCsmacd</type>
       <description>DHCPv6 Relay Interface</description>
       <enabled>true</enabled>
     </interface>
   </interfaces>

   <dhcpv6-client
     xmlns="urn:ietf:params:xml:ns:yang:ietf-dhcpv6-client">
     <enabled>true</enabled>
     <client-if>
       <if-name>eth0</if-name>
       <enabled>true</enabled>
       <interface-duid>000200090CC084D303000913</interface-duid>
       <client-configured-options>
         <option-request-option>
           <oro-option>17</oro-option>
           <oro-option>23</oro-option>
           <oro-option>24</oro-option>
           <oro-option>82</oro-option>
         </option-request-option>
         <vendor-specific-information-options>
           <vendor-specific-information-option>
             <enterprise-number>32473</enterprise-number>
             <vendor-option-data>
               <sub-option-code>1</sub-option-code>
               <sub-option-data>abcd1234</sub-option-data>
             </vendor-option-data>
           </vendor-specific-information-option>
         </vendor-specific-information-options>
       </client-configured-options>
       <ia-na>
         <ia-id>1</ia-id>
       </ia-na>
       <ia-pd>
         <ia-id>2</ia-id>
       </ia-pd>
     </client-if>
   </dhcpv6-client>

Рисунок 9. Пример XML для базовой конфигурации клиента.

Приложение B. Пример добавления определений опций DHCPv6

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

Пример задаёт модуль YANG для OPTION_SIP_SERVER_D (21) и OPTION_SIP_SERVER_D (22) из [RFC3319]. Пример конфигурации XML, показывающий взаимодействие с другими модулями, представлен на рисунке 7.

  • В имени модуля применено сокращённое имя документа, где задан формат опций DHCP.

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

  • Имена опций произведены из зарегистрированных IANA имён путём добавления суффикса -option.

  • В полях description указано соответствующее имя и код опции.

  • В reference указан номер и название RFC с определением опции DHCPv6.

  • Остальные поля соответствуют полям опции DHCP с сохранением порядка из определения. По возможности для полей опции DHCP применяется подходящий тип YANG.

  • Для полей, которые могут иметь несколько значений, применяются узлы list или leaf-list.

В группировках для определений опций применяются операторы augment для добавления в соответствующие модули элементов DHCP (server, relay, client).

   <CODE BEGINS>
   module example-dhcpv6-opt-sip-serv {
     yang-version 1.1;
     namespace "https://example.com/ns/"
             + "example-dhcpv6-opt-sip-serv";
     prefix sip-srv;

     import ietf-inet-types {
       prefix inet;
     }
     import ietf-dhcpv6-server {
       prefix dhc6-srv;
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG содержит опции DHCPv6 из RFC 8415, которые 
        могут применяться серверами DHCPv6.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

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

     grouping sip-server-domain-name-list-option-group {
       description
         "OPTION_SIP_SERVER_D (21) SIP Servers Domain-Name List.";
       reference
         "RFC 3319: Dynamic Host Configuration Protocol
          (DHCPv6) Options for Session Initiation Protocol (SIP)
          Servers";
       container sip-server-domain-name-list-option {
         description
           "OPTION_SIP_SERVER_D (21) SIP Servers Domain Name List
            Option.";
         list sip-server {
           key "sip-serv-id";
           description
             "Информация о сервере SIP.";
           leaf sip-serv-id {
             type uint8;
             description
               "Идентификатор списка серверов SIP.";
           }
           leaf sip-serv-domain-name {
             type inet:domain-name;
             description
               "Доменное имя сервера SIP.";
           }
         }
       }
     }

     grouping sip-server-address-list-option-group {
       description
         "OPTION_SIP_SERVER_A (22) SIP Servers IPv6 Address List.";
       reference
         "RFC 3319: Dynamic Host Configuration Protocol
          (DHCPv6) Options for Session Initiation Protocol (SIP)
          Servers";
       container sip-server-address-list-option {
         description
           "OPTION_SIP_SERVER_A (22) SIP Servers IPv6 Address List
            Option.";
         list sip-server {
           key "sip-serv-id";
           description
             "Информация о сервере SIP.";
           leaf sip-serv-id {
             type uint8;
             description
               "Идентификатор записи списка серверов SIP.";
           }
           leaf sip-serv-addr {
             type inet:ipv6-address;
             description
               "Адрес IPv6 сервера SIP.";
           }
         }
       }
     }

     /*
      * Дополнения
      */

     augment "/dhc6-srv:dhcpv6-server/dhc6-srv:option-sets/"
           + "dhc6-srv:option-set" {
       description
         "Дополняет группировки определений опций для модуля server.";
       uses sip-server-domain-name-list-option-group;
       uses sip-server-address-list-option-group;
     }
   }
   <CODE ENDS>

Корректное место добавления (augment) новых определений опций будет меняться в зависимости от правил использования конкретной опции. Например, для опций, добавляемых в модуль ietf-dhcpv6-server, это будет в большистве случаев /dhc6-srv:dhc6-srv/dhc6-srv:option-sets/dhc6-srv:option-set, чтобы задавать опции в наборах. Однако имеются опции, применимые лишь в определённых вариантах развёртывания, и в таких случаях может оказаться более логичным добавление в группу, подходящую для опции. Одним из таких примеров является опция OPTION_PD_EXCLUDE (67), которая применима лишь вместе с делегированным префиксом, содержащим конкретный префикс. В этом случае для дополнения может лучше подойти /dhc6-srv:dhc6-srv/dhc6-srv:allocation-ranges/dhc6-srv:allocation-range/dhc6-srv:prefix-pools/dhc6-srv:prefix-pool.

Приложение C. Пример фирменного модуля конфигурации сервера

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

В примере определены дополнительные атрибуты сервере, такие как имя и описание. Хранилище записей об аренде задано в контейнере lease-storage, поддерживающем три варианта — память (memfile), MySQL, PostgreSQL. Для каждого из вариантов представлены параметры конфигурации.

Для простоты в примере предполагается, что сервер DHCPv6 совмещён с сервером MySQL или PostgreSQL и может безопасно обслуживать трафик на локальном хосте без криптографической защиты. В реальной среде эти серверы будут вероятно разнесены и потребуется применять TLS для защиты соединений между сервером баз данных и сервером DHCPv6. Модуль YANG для настройки TLS задан в [GROUPINGS-TLS].

В конце модуля имеется оператор augment, добавляющий фирменную конфигурацию из dhcpv6-server-config:config» в точку монтирования /dhcpv6-server:config/dhcpv6-server:vendor-config.

   <CODE BEGINS>
   module example-dhcpv6-server-conf {
     yang-version 1.1;
     namespace "https://example.com/ns/"
             + "example-dhcpv6-server-conf";
     prefix dhc6-srv-conf;

     import ietf-inet-types {
       prefix inet;
     }
     import ietf-interfaces {
       prefix if;
     }
     import ietf-dhcpv6-server {
       prefix dhc6-srv;
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG задаёт компоненты для настройки и управления
        зависящей от производителя или развёртывания функциональностью 
        сервера DHCPv6. Такие функции будут сильно различаться между
        реализациями, поэтому модуль служить лишь примером.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

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

     grouping config {
       description
         "Параметры, требуемые для настройки сервера DHCPv6.";
       container serv-attributes {
         description
           "Базовые атрибуты, требуемые для работы сервера DHCPv6.";
         leaf name {
           type string;
           description
             "Имя сервера DHCPv6.";
         }
         leaf description {
           type string;
           description
             "Описание сервера DHCPv6.";
         }
         leaf ipv6-listen-port {
           type uint16;
           default "547";
           description
             "Порт UDP, прослушиваемый сервером.";
         }
         choice listening-interfaces {
           default "all-interfaces";
           description
             "Интерфейсы или адреса для приёма входящих сообщений.";
           case all-interfaces {
             container all-interfaces {
               presence "true";
               description
                 "Настройка прослушивания входящих сообщений на всех
                  адресах IPv6 (unicast и multicast) всех интерфейсов.";
             }
           }
           case interface-list {
             leaf-list interfaces {
               type if:interface-ref;
               description
                 "Список интерфейсов, на которых сервер будет слушать
                  входящие сообщения. Приниматься будут сообщения
                  по любому действительному адресу IPv6.";
             }
           }
           case address-list {
             leaf-list address-list {
               type inet:ipv6-address;
               description
                 "Список адресов IPv6, на которых сервер будет слушать
                  входящие сообщения DHCPv6.";
             }
           }
         }
         leaf-list interfaces-config {
           type if:interface-ref;
           default "if:interfaces/if:interface/if:name";
           description
             "Список интерфейсов, которые серверу следует слушать.";
         }
         container lease-storage {
           description
             "Способ сохранения сведений об аренде.";
           choice storage-type {
             description
               "Тип хранилища для сведений о аренде.";
             case memfile {
               description
                 "Конфигурация для хранения записей в файле CSV.";
               leaf memfile-name {
                 type string;
                 description
                   "Указывает абсолютный путь к файлу хранилища. Формат
                    записей следует семантике операционной системы.";
               }
               leaf memfile-lfc-interval {
                 type uint64;
                 description
                   "Интервал очистки сервером файла записей (секунды).";
               }
             }
             case mysql {
               leaf mysql-name {
                 type string;
                 description
                   "Имя базы данных MySQL на локальном хосте.";
               }
               leaf mysql-username {
                 type string;
                 description
                   "Имя пользователя для доступа к базе данных.";
               }
               leaf mysql-password {
                 type string;
                 description
                   "Пароль пользователя для доступа к базе данных.";
               }
               leaf mysql-port {
                 type inet:port-number;
                 default "3306";
                 description
                   "Если база данных размещена в другой системе, можно
                    указать номер порта.";
               }
               leaf mysql-lfc-interval {
                 type uint64;
                 description
                   "Интервал очистки сервером базы записей (секунды).";
               }
               leaf mysql-connect-timeout {
                 type uint64;
                 description
                   "Тайм-аут для соединения с базой данных. Для 
                    удалённой базы тайм-аут можно увеличить.";
               }
             }
             case postgresql {
               leaf postgresql-name {
                 type string;
                 description
                   "Имя базы данных PostgreSQL на локальном хосте.";
               }
               leaf postgresql-username {
                 type string;
                 description
                   "Имя пользователя для доступа к базе данных.";
               }
               leaf postgresql-password {
                 type string;
                 description
                   "Пароль пользователя для доступа к базе данных.";
               }
               leaf postgresql-port {
                 type inet:port-number;
                 default "5432";
                 description
                   "Если база данных размещена в другой системе, можно
                    указать номер порта.";
               }
               leaf postgresql-lfc-interval {
                 type uint64;
                 description
                   "Интервал очистки сервером базы записей (секунды).";
               }
               leaf postgresql-connect-timeout {
                 type uint64;
                 description
                   "Тайм-аут для соединения с базой данных. Для 
                    удалённой базы тайм-аут можно увеличить.";
               }
             }
           }
         }
       }
     }

     /*
      * Дополнение
      */

     augment "/dhc6-srv:dhcpv6-server/dhc6-srv:vendor-config" {
       description
         "Добавляет фирменный модуль YANG к ietf-dhcpv6-server.";
       uses config;
     }
   }
   <CODE ENDS>

Приложение D. Пример определения конфигурации селектора класса

Модуль ietf-example-dhcpv6-class-selector служит примером моделирования фирменной конфигурации выбора класса и объединения с модулем ietf-dhcpv6-server из этого документа.

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

В конце примера включен оператор augment для добавления правил выбора класса в иерархию адресации DHCPv6:

  • дополнение конфигурации селектора классов в основной конфигурации сервера DHCPv6;

  • дополнение листьев-списков client-class в allocation-range, address-pool и pd-pool с указанием client-class-name.

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

   <CODE BEGINS>
   module example-dhcpv6-class-select {
     yang-version 1.1;
     namespace "https://example.com/ns/"
             + "example-dhcpv6-class-select";
     prefix dhc6-class-sel;

     import ietf-inet-types {
       prefix inet;
     }
     import ietf-interfaces {
       prefix if;
     }
     import ietf-dhcpv6-common {
       prefix dhc6;
     }
     import ietf-dhcpv6-server {
       prefix dhc6-srv;
     }

     organization
       "IETF Dynamic Host Configuration (DHC) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dhc/> 
        WG List:  <mailto:dhcwg@ietf.org> 
        Author:   Yong Cui <yong@csnet1.cs.tsinghua.edu.cn> 
        Author:   Linhui Sun <lh.sunlinh@gmail.com> 
        Editor:   Ian Farrer <ian.farrer@telekom.de> 
        Author:   Sladjana Zeichlin <sladjana.zechlin@telekom.de> 
        Author:   Zihao He <hezihao9512@gmail.com> 
        Author:   Michal Nowikowski <godfryd@isc.org>"; 
     description
       "Этот модуль YANG задаёт компоненты конфигурации селекторов
        классов клиентов для сервера DHCPv6. Эта функциональность
        существенно различается в реализациях и модуль служит лишь
        примером.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9243: A YANG Data Model for DHCPv6 Configuration";
     }

     /*
      * Группировки
      */
     grouping client-class-id {
       description
         "Определения классификации сообщений клиентов для 
          аутентификации и назначения.";
       leaf client-class-name {
         type string;
         mandatory true;
         description
           "Уникальный идентификатор записей классов клиентов.";
       }
       choice id-type {
         mandatory true;
         description
           "Определения типов идентификаторов класса клиентов.";
         case client-id-id {
           leaf client-id {
             type string;
             mandatory true;
             description
               "Строка идентификатора клиента.";
           }
           description
             "Выбор класса клиента по строковым идентификаторам.";
         }
         case received-interface-id {
           description
             "Выбор класса клиента по входному интерфейсу сообщения
              DHCPv6.";
           leaf received-interface {
             type if:interface-ref;
             description
               "Ссылка на запись для входного интерфейса сообщения
                DHCPv6.";
           }
         }
         case packet-source-address-id {
           description
             "Выбор класса клиента по адресу отправителя сообщения
              DHCPv6.";
           leaf packet-source-address {
             type inet:ipv6-address;
             mandatory true;
             description
               "Адрес отправителя в сообщении DHCPv6.";
           }
         }
         case packet-destination-address-id {
           description
             "Выбор класса клиента по адресу получателя сообщения
              DHCPv6.";
           leaf packet-destination-address {
             type inet:ipv6-address;
             mandatory true;
             description
               "Адрес получателя в сообщении DHCPv6.";
           }
         }
         case relay-link-address-id {
           description
             "Выбор класса клиента по префиксу в поле канального адреса
              в заголовке сообщения агента ретрансляции.";
           leaf relay-link-address {
             type inet:ipv6-prefix;
             mandatory true;
             description
               "Префикс в поле link-address заголовка сообщения агента.";
           }
         }
         case relay-peer-address-id {
           description
             "Выбор класса клиента по полю peer-address в заголовке
              сообщения агента ретрансляции.";
           leaf relay-peer-address {
             type inet:ipv6-prefix;
             mandatory true;
             description
               "Префикс в поле peer-address заголовка сообщения агента";
           }
         }
         case relay-interface-id {
           description
             "Выбор класса клиента по полученному экземпляру
              OPTION_INTERFACE_ID (18).";
           leaf relay-interface {
             type string;
             description
               "Необрабатываемое (opaque) значение произвольного размера
                от агента ретрансляции для указания интерфейса агента.";
           }
         }
         case user-class-option-id {
           description
             "Выбор класса клиента по значению OPTION_USER_CLASS (15) и
              полю user-class-data в этой опции.";
           leaf user-class-data {
             type string;
             mandatory true;
             description
               "Значение User Class для сопоставления.";
           }
         }
         case vendor-class-present-id {
           description
             "Выбор класса клиента по наличию OPTION_VENDOR_CLASS (16)
              в полученном сообщении.";
           leaf vendor-class-present {
             type boolean;
             mandatory true;
             description
               "OPTION_VENDOR_CLASS (16) присутствует в сообщении.";
           }
         }
         case vendor-class-option-enterprise-number-id {
           description
             "Выбор класса клиента по значению поля enterprise-number 
              в OPTION_VENDOR_CLASS (16).";
           leaf vendor-class-option-enterprise-number {
             type uint32;
             mandatory true;
             description
               "Значение поля enterprise-number.";
           }
         }
         case vendor-class-option-data {
           description
             "Выбор класса клиента по значению поля данных в записи
              vendor-class-data для сопоставления с полем 
              enterprise-number в OPTION_VENDOR_CLASS (16).";
           container vendor-class-option-data {
             description
               "Контейнер данных опции Vendor-class.";
             leaf enterprise-number {
               type uint32;
               description
                 "Enterprise Number производителя от IANA.";
             }
             leaf vendor-class-data-id {
               type uint8;
               description
                 "Идентификатор данных Vendor-class.";
             }
             leaf vendor-class-data {
               type string;
               description
                 "Необрабатываемое (Opaque) поле для сопоставления с 
                  данными Vendor-class от клиента.";
             }
           }
         }
         case client-duid-id {
           description
             "Выбор класса клиента по значению принятого DUID клиента.";
           leaf duid {
             type dhc6:duid;
             description
               "DUID клиента.";
           }
         }
       }
     }

     /*
      * Дополнения
      */
     augment "/dhc6-srv:dhcpv6-server/dhc6-srv:class-selector" {
       description
         "Дополнение функций селектора класса для сервера DHCPv6.";
       container client-classes {
         description
           "Добавляемые классы клиентов.";
         list class {
           key "client-class-name";
           description
             "Список идентификаторов класса клиентов, применимых 
              к клиентам, обслуживаемым этим пулом адресов.";
           uses client-class-id;
         }
       }
     }

     augment "/dhc6-srv:dhcpv6-server/"
           + "dhc6-srv:allocation-ranges/dhc6-srv:allocation-range" {
       description
         "Дополнение функций селектора класса к allocation-ranges.";
       leaf-list client-class {
         type leafref {
           path "/dhc6-srv:dhcpv6-server/dhc6-srv:"
              + "class-selector/client-classes/class/client-class-name";
         }
         description
           "Ссылки на классы клиентов.";
       }
     }

     augment "/dhc6-srv:dhcpv6-server/dhc6-srv:"
           + "allocation-ranges/dhc6-srv:allocation-range/dhc6-srv:"
           + "address-pools/dhc6-srv:address-pool" {
       description
         "Дополнение функций селектора класса к address-pools.";
       leaf-list client-class {
         type leafref {
           path "/dhc6-srv:dhcpv6-server/dhc6-srv:"
              + "class-selector/client-classes/class/client-class-name";
         }
         description
           "Ссылки на классы клиентов.";
       }
     }

     augment "/dhc6-srv:dhcpv6-server/dhc6-srv:"
           + "allocation-ranges/dhc6-srv:allocation-range/dhc6-srv:"
           + "prefix-pools/dhc6-srv:prefix-pool" {
       description
         "Дополнение функций селектора класса к prefix-pools.";
       leaf-list client-class {
         type leafref {
           path "/dhc6-srv:dhcpv6-server/dhc6-srv:"
              + "class-selector/client-classes/class/client-class-name";
         }
         description
           "Ссылки на классы клиентов.";
       }
     }
   }
   <CODE ENDS>

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

Авторы прихнательны Qi Sun, Lishan Li, Hao Wang, Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Ted Lemon, Bing Liu, Tom Petch, Acee Lindem, Benjamin Kaduk, Kris Lambrechts, Paul Dumitru за важные комментарии и вклад в работу.

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

Перечисленные ниже люди являются соавторами этого документа.

Yong Cui
Tsinghua University
Beijing,
100084
China
Email: cuiyong@tsinghua.edu.cn
 
Linhui Sun
Tsinghua University
Beijing,
100084
China
Email: lh.sunlinh@gmail.com
 
Sladjana Zechlin
Deutsche Telekom AG
CTO-IPT, Landgrabenweg 151
53227, Bonn
Germany
Email: sladjana.zechlin@telekom.de
 
Zihao He
Tsinghua University
Beijing,
100084
China
Email: hezihao9512@gmail.com
 
Michal Nowikowski
Internet Systems Consortium
Gdansk
Poland
Email: godfryd@isc.org

Адрес автора

Ian Farrer (editor)
Deutsche Telekom AG
S&TI, Landgrabenweg 151
53227 Bonn
Germany
Email: ian.farrer@telekom.de

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

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

nmalykh@protokols.ru

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

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

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

RFC 9244 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry

Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9244                                        Orange
Category: Standards Track                                T. Reddy.K, Ed.
ISSN: 2070-1721                                                   Akamai
                                                                E. Doron
                                                            Radware Ltd.
                                                                 M. Chen
                                                                    CMCC
                                                              J. Shallow
                                                               June 2022

Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry

Телеметрия распределенной сигнализации об угрозах DoS-атак

PDF

Аннотация

Этот документ нацелен на обогащение протокола сигнального канала распределенной сигнализации об угрозе отказа в обслуживании (Distributed Denial-of-Service Open Threat Signaling или DOTS) различными атрибутами телеметрии для оптимального смягчения распределенных атак на службы (Distributed Denial-of-Service или DDoS). Документ задаёт базовый уровень обычного трафика, атрибуты телеметрии трафика атаки, которые DOTS-клиент может передать своему серверу DOTS в запросе на смягчение последствий атаки, атрибуты смягчения атаки, которые сервер DOTS может передать клиенту, атрибуты телеметрии эффективности, которые клиент может передать серверу DOTS. Атрибуты телеметрии могут способствовать системе смягчения атак при выборе методов защиты от DDoS и эффективном смягчении DDoS-атак.

Документ задаёт два модуля YANG для представления типов сообщений телеметрии DOTS и обмена данными данными об отображениях атак по каналу данных DOTS.

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

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

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

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

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

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

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

1. Введение

IT-организации и сервис-провайдеры сталкиваются с распределёнными атаками на службы (Distributed Denial-of-Service или DDoS), которые делятся на две большие категории.

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

    Основой таких атак является передача большого объёма трафика в направлении инфраструктуры жертвы. Обычно объем трафика атаки может составлять от нескольких сотен Мбит/с до сотен Гбит/с и даже Тбит/с. Атаки обычно организуются с использованием бот-сетей (botnet) и рефлекторов для усиления атаки (параграф 3.1 в [RFC4732]), таких как NTP (Network Time Protocol), DNS (Domain Name System), SNMP (Simple Network Management Protocol), SSDP (Simple Service Discovery Protocol).

  2. Атаки прикладного уровня нацелены на разные приложения. Типичными примерами служат атаки на HTTP/HTTPS, DNS, SIP (Session Initiation Protocol), SMTP (Simple Mail Transfer Protocol). Однако для таких атак открыты и все прочие приложения на периметре сети, для которых известны номера применяемых портов.

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

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

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

Протокол сигнального канала Distributed Denial-of-Service Open Threat Signaling (DOTS) [RFC9132] служит для передачи сведений о сетевом ресурсе или сети (части сети), подвергающейся DDoS-атаке. Такая информация передаётся клиентами DOTS одному или нескольким серверам DOTS для принятия соответствующих действий по смягчению последствий со стороны трафика, сочтенного подозрительным. Примеры использования представлены в [RFC8903].

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

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

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

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

В параграфе 11.2 задан модуль YANG, дополняющий канал данных DOTS [RFC8783] сведениями, относящимися к деталям атаки. Совместное использование таких деталей в период «бездействия» предназначено для оптимизации обмена данными по сигнальному каналу DOTS.

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

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

Читателю следует ознакомиться с терминами, определёнными в [RFC8612].

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

Идентификатор установки телеметрии (Telemetry Setup Identifier или tsid) создаётся клиентом DOTS для однозначного указания данных конфигурации телеметрии DOTS (см. 7.1.2. Передача конфигурации телеметрии DOTS).

Идентификатор телеметрии (Telemetry Identifier или tmid) создаётся клиентом DOTS для однозначного указания данных телеметрии DOTS, передаваемыми до или в процессе смягчения атаки (см. 8.2. От клиентов к серверам DOTS).

«Перекрытие» младшей части tsid (или tmid) указывает младшую часть перекрывающихся запросов телеметрии.

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

В документе используются выделенные IANA Enterprise Number, известные как Private Enterprise Numbers и SMI (Structure of Management Information) Network Management Private Enterprise Codes [Private-Enterprise-Numbers].

Значение символов на диаграммах деревьев YANG определено в [RFC8340] и [RFC8791].

В соответствии с соглашениями раздела 2 в [RFC8783] примеры параграфа 8.1.6 используют /restconf как обнаруженный корневой путь RESTCONF API. В этих примерах символ \ в конце строки означает перенос длинной строки в целях форматирования. Предполагается, что такие строки объединяются с удалением символов \, перевода строки и начального пробела в следующей строке.

3. Телеметрия DOTS — обзор и назначение

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

3.1. Улучшение видимости атак

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

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

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

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

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

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

3.2. Улучшенное обнаружение

Телеметрия DOTS может также служить входными данными для определения значений при настройке параметров, доступных на ресурсах смягчения атак. За последние несколько лет технологии обнаружения DdoS-атак развились от детектирования по порогу (когда весь трафик или его определённые части превышают заданный порог) до обнаружения аномалий. В последнем случае требуется поддерживать строгое изучение обычного поведения, а аномалия (или атака) идентифицируется и классифицируется но основе сведений о нормальном трафике и отклонений от него. Статистические алгоритмы и искусственный интеллект (например, машинное обучение) применяются так, что пороги рассчитываются автоматически путём изучения нормального трафика в период «бездействия» (смягчение не применяется). Полученные характеристики обычного трафика называют также базовым уровнем (normal traffic baseline), а атакой считаются случаи, когда фактический трафик жертвы отличается от базового уровня.

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

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

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

Смягчение атак без знания обычного трафика будет в лучшем случае неточным. Это особенно верно для рекурсивной сигнализации (см. параграф 3.2.3 в [RFC8811]). С учётом возможности интеграции клиентов DOTS в самые разные системы и варианты применения, это повышает важность сведений о поведении каждого клиентского домена DOTS, особенно из-за того, что глобальные пороги обнаружения атак практически не реализуются. Каждый клиентский домен DOTS имеет свой уровень трафика и своё поведение. Без сведений о базовых уровнях серверам DOTS в некоторых случаях может быть очень трудно обнаружить и эффективно смягчить атаки.

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

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

3.3. Эффективное ослабление атак

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

В таких случаях для клиентов DOTS важно сообщить серверам DOTS общую пропускную способность каналов, определяющую уровень трафика, который клиентский домен DOTS может воспринять из восходящей сети (провайдера). Необходимо динамически обновлять состояния каналов между агентами DOTS, находящимися в условиях DDoS-атаки (например, при использовании несколькими клиентами DOTS общих физических каналов). Серверу DOTS следует активировать другие механизмы, чтобы гарантированно предотвратить ненамеренное насыщение каналов клиентского домена. Для этого разумным решением будет применение ограничения скорости, описанного в [RFC8783]. Клиент DOTS может указать типы трафика (например, ICMP, UDP, TCP через порт 80), который он предпочитает ограничить. Действиями по ограничению скорости можно управлять по каналу сигнализации [RFC9133] даже при перегрузке «трубы».

4. Внутреннее устройство

4.1. Обзор операций телеметрии

Стек протоколов DOTS делится на две логических части: сигнальный канал [RFC9132] и канал данных [RFC8783]. Это разделение обусловлено совершенно разными требованиями к передаваемому по этим каналам трафику. Сигнальный канал DOTS должен оставаться доступным и пригодным для использования даже в случае атаки, которая, например, может перегрузить одно из направлений охваченных каналов, что делает ненадёжными механизмы на основе подтверждений и настоятельно требует делать сообщения достаточно малыми, чтобы передать в одном пакете IP (параграф 2.2 в [RFC8612]). Напротив, канал данных DOTS доступен для высокоскоростной передачи данных до или после атаки с использованием более традиционных методов доставки (параграф 2.3 в [RFC8612]). Обычно предпочтительно заранее настраивать конфигурацию по каналу данных DOTS, включая настройку псевдонимов для статических или почти статических наборов данных, таких как множество сетевых адресов/префиксов, которые могут быть атакованы. Это помогает оптимизировать использование сигнального канала DOTS для небольших сообщений, которые важно доставить даже во время атаки. Напомним, что для сигнализации и данных DOTS требуются защищённые каналы (раздел 11 в [RFC9132] и раздел 10 в [RFC8783]).

Данные телеметрии имеют аспекты, соответствующие обоим режимам работы (сигнализация и данные). Безусловно необходимо передавать обновляемые сведения о трафике происходящей атаки и целях атаки, чтобы иметь детальные сведения о статусе смягчения и обновлять стратегию защиты от адаптивных атак. Однако полезно также предоставлять службам смягчения картину нормального (базового уровня) трафика в направлении возможных целей атак, чтобы помочь в обнаружении отклонений в поведении трафика при возникновении атак. Кроме того, можно поддерживать «базу данных» с классификацией известных типов атак, чтобы можно было применять краткий идентификатор атаки в период её действия для описания данной атаки. Эта спецификация предусматривает использование канала данных DOTS для последней функции (параграф 8.1.6), но большая часть функций телеметрии реализуется по сигнальному каналу DOTS.

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

Этот документ задаёт расширение протокола сигнального канала DOTS, установка, поддержка и использование которого заданы в [RFC9132].

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

Совокупные данные телеметрии DOTS могут также включаться в сообщения об обновлении эффективности (параграф 9.1) или смягчения (параграф 9.2).

4.2. Поблочная передача

Клиенты DOTS могут использовать поблочную передачу [RFC7959] в соответствии с рекомендациями параграфа 4.4.2 в [RFC9132] для управления размером отклика, когда возвращаемые данные не помещаются в одну дейтаграмму.

Клиенты DOTS могут также применять опцию Block1 протокола CoAP (Constrained Application Protocol) в запросах PUT (параграф 2.5 в [RFC7959]) для инициирования больших передач, но эти передачи Block1 скорее всего приведут к отказу, если входная «труба» заполнена, поскольку для передачи требуется сообщение от сервера для каждого блока, которое скорей всего будет потеряно во входном потоке. Необходимо рассмотреть попытку уместить PUT в одну передачу или разделить PUT на несколько дискретных запросов PUT, каждый из которых умещается в один пакет.

Опции Q-Block1 и Q-Block2 похожи на опции CoAP Block1 и Block2, но обеспечивают надёжную передачу больших блоков данных с меньшим числом обменов пакетами, используя сообщения NON, определённые в [RFC9177]. Реализации DOTS могут рассмотреть использование опций Q-Block1 и Q-Block2 [DOTS-Robust-Blocks].

4.3. Многодомные системы DOTS

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

Соображения, связанные с тем, собирает ли (и как) клиент DOTS ту или иную телеметрию (например, детали атаки), которую он получает от первого сервера DOTS и передаёт её второму серверу, зависят от реализации и развёртывания.

4.4. Вопросы YANG

Сообщения телеметрии между агентами DOTS сериализуются с использованием краткого представления двоичных объектов (Concise Binary Object Representation или CBOR) [RFC8949]. Данные в кодировке CBOR служат для передачи относящихся к каналу сигнализации сообщений, которые содержат параметры запросов и данные откликов, такие как ошибки.

Этот документ задаёт модель YANG [RFC7950] для представления типов сообщений телеметрии DOTS (параграф 11.1). Все параметры в полях данных сигнального канала DOTS отображаются на типы CBOR, как указано в разделе 12. Напомним, что правила отображения данных из модели YANG на CBOR даны в разделе 3 [RFC9132].

Модуль телеметрии (параграф 11.1) не предназначен для использования по протоколам NETCONF (Network Configuration Protocol) и RESTCONF с целью управления серверами DOTS. Он задаёт модель данных и кодирование в соответствии с [RFC8791]. Серверные отклонения (параграф 5.6.3 в [RFC7950]) настоятельно не рекомендуются, поскольку партнерский агент DOTS не может получить список отклонений и могут возникать проблемы совместимости.

Модуль телеметрии DOTS (параграф 11.1) использует enumeration вместо identity для определения единиц, выборок и интервалов, поскольку в ином случае нужно включать идентификатор пространства имён ietf-dots-telemetry при включении атрибута телеметрии (например, при обновлении эффективности смягчения). Применение identity неоптимально с точки зрения компактности сообщений, которая очень важна для сигнального канала DOTS.

Модуль телеметрии DOTS (параграф 11.1) включает списки без оператора key. Это соответствует [RFC8791]. Причина отсутствия ключей состоит в том, что они не включаются в тело запросов DOTS, эти ключи обязательны лишь в запросах Uri-Paths (разделы 7 и 8). Иначе при каждом включении оператора key предполагается такое же определение, как в параграфе 7.8.2 [RFC7950].

Некоторые параметры (например, значения low-percentile) могут быть связаны с разными типами YANG (например, decimal64 и yang:gauge64). Чтобы проще было различать типы этих параметров и сохранить осмысленность имён, применяются суффиксы, показанные в таблице 1.

Таблица 1. Суффиксы и типы YANG.

Суффикс

Тип YANG

Пример

-g

yang:gauge64

low-percentile-g

-c

container

connection-c

-ps

per second

connection-ps

 

Диаграмму полного дерева телеметрии DOTS можно создать с помощью pyang [PYANG]. Дерево не включено в документ из-за слишком большого размера (параграф 3.3 а [RFC8340]) и представлено лишь частями.

Для оптимизации обмена данных по сигнальному каналу DOTS в этом документе определён второй модуль YANG (ietf-dots-mapping, параграф 11.2), дополняющий канал данных DOTS [RFC8783]. Это дополнение можно использовать в период «бездействия» для обмена сведениями о сопоставлениях атак (параграф 8.1.5). Клиенты DOTS могут применять инструменты, такие как YANG Library [RFC8525], для получения списка свойств и отклонений, поддерживаемых сервером по каналу данных.

5. Базовые вопросы

5.1. Идентификация клиентов DOTS

В соответствии с правилами параграфа 4.4.1 в [RFC9132] клиент DOTS создаёт уникальный идентификатор cuid для предотвращения конфликтов. Напомним, что параграф 4.4.1.3 в [RFC9132] запрещает возврат cuid в теле откликов.

5.2. Шлюзы DOTS

Между клиентами и серверами DOTS могут размещаться шлюзы DOTS. Необходимо следовать соображениям, изложенным в параграфе 4.4.1 [RFC9132]. В частности, атрибут cdid служит для однозначной идентификации клиентского домена DOTS. Напомним, что параграф 4.4.1.3 в [RFC9132] запрещает возврат cuid (при наличии) в теле откликов.

5.3. Параметры Uri-Path и пустые значения

Параметры Uri-Path и атрибуты с пустыми значениями недопустимо включать в запрос. Наличие пустого значения делает всё сообщение недействительным.

5.4. Управление данными конфигурации

Сервер DOTS руководствуется теми же соображениями, которые изложены в параграфе 4.5.3 [RFC9132], для поддержки актуальности и уведомлений конфигурации телеметрии DOTS.

Аналогично, клиент DOTS может управлять выбором конфигурационных и неконфигурационных узлов данных при отправке запроса GET с помощью опции Uri-Query c (content — содержимое), следуя процедуре, заданной в параграфе 4.4.2 [RFC9132]. В последующих параграфах эти соображения не повторяются.

5.5. Проверка сообщения

Полномочными для проверки сообщений, передаваемых по сигнальному каналу DOTS являются разделы 7 — 9 и таблица сопоставлений в разделе 12. Структура тела сообщений представлена в модуле YANG (параграф 11.1).

5.6. Замечания о примерах

Примеры представлены для иллюстрации и не представляют полный набор сообщений.

JSON-кодирование данных модели YANG служит для демонстрации операций телеметрии. Для удобочитаемости в примерах применяются имена параметров и их типы JSON, а не значение ключей CBOR и типы CBOR (см. раздел 12). Эти соглашения заимствованы из [RFC9132].

В примерах применяется значение Enterprise Number = 32473, выделенное для документации (см. [RFC5612]).

6. Пути операций телеметрии

Как отмечено в параграфе 4.2 [RFC9132], каждая операция DOTS указывается суффиксом пути, который задаёт предусмотренную операцию. Путь операции добавляется в конце префикса пути для создания URI, применяемого с запросом CoAP для выполнения нужной операции DOTS. Суффиксы путей телеметрии приведены в таблице 2.

Таблица 2. Операции телеметрии DOTS.

Операция

Путь операции

Описание

Telemetry Setup

/tm-setup

Раздел 7

Telemetry

/tm

Раздел 8

 

Модуль YANG ietf-dots-telemetry, заданный в параграфе 11.1, определяет структуру данных для представления новых типов сообщений DOTS — telemetry-setup и telemetry. Структура дерева показана на рисунке 1, а описания даны в разделах 7 и 8 с указанием точной структуры типов сообщений telemetry-setup и telemetry.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     ...
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 1. Новые типы сообщений DOTS (дерево YANG).


Реализации DOTS должны поддерживать Observe Option [RFC7641] для tm (раздел 8).

7. Конфигурация установки телеметрии DOTS

Как показано на рисунке 1, сообщение установки телеметрии DOTS должно включать лишь относящиеся к телеметрии параметры конфигурации (параграф 7.1), сведения о «емкости трубы» клиентского домена DOTS (параграф 7.2) или данные о базовом уровне трафика телеметрии (параграф 7.3). Поэтому запросы, включающие комбинацию настроек телеметрии, ёмкости трубы и данные о базовом уровне трафика, должны отвергаться серверами DOTS с кодом отклика 4.00 (Bad Request — недопустимый запрос).

Клиент DOTS может сбросить все установленные данные конфигурации телеметрии DOTS в соответствии с параграфом 7.4.

Сервер DOTS может обнаруживать конфликты при обработке запросов, относящихся к ёмкости трубы клиентского домена DOTS или данным о базовом трафике телеметрии, с запросами от других клиентов из того же домена (см. параграф 7.5).

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

Запросы и отклики конфигурации телеметрии DOTS помечаются как сообщения Confirmable (параграф 2.1 [RFC7252]).

7.1. Конфигурация телеметрии

В телеметрии DOTS применяется несколько значений процентилей для представления общего распределения картины трафика, а не моментального снимка в конкретное время. Моделирование необработанных данных о потоке трафика в форме распределения и описание такого распределения влечёт за собой выбор периода измерений, описываемого распределением, и числа интервалов выборки или «сегментов» (bucket) в этом интервале измерений. Трафик в каждом сегменте считается одним событием (усредняется), а распределение сегментов служит для описания распределения трафика в интервале измерений. Распределение можно характеризовать статистически (например, среднее значение, медиана, стандартное отклонение), а также указанием значений на разных уровнях процентилей рассматриваемого набора данных (например, квартили для 25-го, 50-го и 75-го процентиля). Значения процентилей и их расчёт подробно описаны в параграфе 11.3 [RFC2330].

В телеметрии DOTS применяется 3 значения процентилей и общий пик для описания распределений трафика. Значения для low-percentile, mid-percentile и high-percentile настраиваются. Принятые по умолчанию значения указаны в параграфе 7.1.2. Клиент DOTS может согласовать с серверами набор используемых параметров конфигурации телеметрии, включая указанные ниже.

  • Связанные с процентилями параметры измерений. В частности, measurement-interval задаёт период, в течение которого рассчитываются процентили, а measurement-sample определяет распределение по времени измерений, служащих для расчёта процентилей.

  • Единицы измерения.

  • Допустимые значения процентилей.

  • Интервал уведомлений телеметрии.

  • Допустимая телеметрия от сервера.

7.1.1. Извлечение текущей конфигурации телеметрии DOTS

Запрос GET служит для получения приемлемых и текущих параметров телеметрии от сервера DOTS. Запрос может включать Uri-Path cdid при трансляции шлюзом DOTS. Пример запроса (без шлюза) показан на рисунке 2.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 2. GET для извлечение текущей и приемлемой конфигурации телеметрии DOTS.


При получении такого запроса и отсутствии ошибок при его обработке сервер DOTS возвращает отклик 2.05 (Content — содержимое) с параметрами телеметрии, которые подходят для сервера, сведениями о трубе (параграф 7.2) и текущими данными о базовом уровне (параграф 7.3), которые сервер поддерживает для этого клиента DOTS. Структура дерева тела отклика показана на рисунке 3.

Серверы DOTS, поддерживающие передачу клиентам сведений телеметрии до или в процессе смягчения атаки (параграф 9.2) устанавливают для server-originated-telemetry в max-config-values значение true (false в ином случае). Если server-originated-telemetry отсутствует в отклике, это эквивалентно отклику в server-originated-telemetry = false.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  +-- (direction)?
          |  |  +--:(server-to-client-only)
          |  |     +-- max-config-values
          |  |     |  +-- measurement-interval?          interval
          |  |     |  +-- measurement-sample?            sample
          |  |     |  +-- low-percentile?                percentile
          |  |     |  +-- mid-percentile?                percentile
          |  |     |  +-- high-percentile?               percentile
          |  |     |  +-- server-originated-telemetry?   boolean
          |  |     |  +-- telemetry-notify-interval?     uint16
          |  |     +-- min-config-values
          |  |     |  +-- measurement-interval?        interval
          |  |     |  +-- measurement-sample?          sample
          |  |     |  +-- low-percentile?              percentile
          |  |     |  +-- mid-percentile?              percentile
          |  |     |  +-- high-percentile?             percentile
          |  |     |  +-- telemetry-notify-interval?   uint16
          |  |     +-- supported-unit-classes
          |  |     |  +-- unit-config* [unit]
          |  |     |     +-- unit           unit-class
          |  |     |     +-- unit-status    boolean
          |  |     +-- supported-query-type*  query-type
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  +-- current-config
          |        |     +-- measurement-interval?          interval
          |        |     +-- measurement-sample?            sample
          |        |     +-- low-percentile?                percentile
          |        |     +-- mid-percentile?                percentile
          |        |     +-- high-percentile?               percentile
          |        |     +-- unit-config* [unit]
          |        |     |  +-- unit           unit-class
          |        |     |  +-- unit-status    boolean
          |        |     +-- server-originated-telemetry?   boolean
          |        |     +-- telemetry-notify-interval?     uint16
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 3. Структура дерева конфигурации телеметрии.


При наличии атрибутов min-config-values и max-config-values значения в max-config-values должны быть больше значений в соответствующих атрибутах min-config-values.

7.1.2. Передача конфигурации телеметрии DOTS

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

Примечание. Содержимое сообщения на рисунке 4 представлено в кодировке CBOR, как указано Content-Format application/dots+cbor (см. параграф 10.3 в [RFC9132]). Однако для удобочитаемости этот пример (и другие рисунки, показывающие сообщения телеметрии DOTS) следует параграфу 5.6, используя имена и типы JSON из раздела 12.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "low-percentile": "5.00",
             "mid-percentile": "65.00",
             "high-percentile": "95.00"
           }
         }
       ]
     }
   }

Рисунок 4. PUT для доставки конфигурации телеметрии DOTS.


Параметр cuid является обязательным в Uri-Path запросов PUT.

Ниже приведено определение дополнительного параметра Uri-Path.

tsid

Идентификатор установки телеметрии (Telemetry Setup Identifier) служит для представления конфигурационных данных установки телеметрии DOTS целым числом и должен создаваться клиентами DOTS. Значения tsid должны монотонно возрастать по мере необходимости передачи клиентом новых (а не просто изменённых) параметров конфигурации.
При достижении максимального значения (rollover) параметра tsid должна применяться процедура, заданная в параграфе 4.4.1 [RFC9132] для параметра mid.
Этот атрибут является обязательным и должен размещаться в опциях Uri-Path после атрибута cuid.

Атрибуты cuid и tsid недопустимо включать в тело запросов PUT.

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

Запрос PUT с большим значением tsid переопределяет установленные запросом с меньшим tsid данные конфигурации телеметрии DOTS. Чтобы не поддерживать слишком длинные списки tsid для доставки данных конфигурации телеметрии от клиента DOTS, наименьшее значение tsid должно автоматически удаляться без доступности серверу.

Сервер DOTS указывает результат обработки запроса PUT с помощью приведённых ниже кодов отклика.

  • Если в запросе отсутствуют обязательные атрибуты, не включён параметр Uri-Path cuid или tsid или имеется хотя бы один недействительный или неизвестный параметр, должен возвращаться отклик с кодом 4.00 (Bad Request — непригодный запрос).

  • Если сервер DOTS не находит в своей конфигурации значение параметра tsid, переданное в запросе PUT, и воспринимает параметры конфигурации, в отклике должен указываться код 2.01 (Created — создано).

  • Если сервер DOTS находит в своей конфигурации значение параметра tsid, переданное в запросе PUT, и воспринимает параметры конфигурации, в отклике должен указываться код 2.04 (Changed — изменено).

  • Если какое-либо из включённых значений атрибутов не приемлемо для сервера DOTS (параграф 7.1.1), должен возвращаться отклик 4.22 (Unprocessable Entity — необрабатываемый элемент).

    Клиент DOTS может повторить и передать запрос PUT с другими значениями атрибутов, приемлемыми для сервера DOTS.

По умолчанию для представления данных телеметрии служат значения low-percentile (10-й), mid-percentile (50-й), high-percentile (90-й) и peak (100-й). Клиент DOTS может отменить некоторые типы процентилей (low, mid, high). В частности, low-percentile = 0.00 указывает, что клиенту DOTS не нужны значения low-percentile. Аналогично, установка для mid-percentile (или high-percentile) таклго же значения, как для low-percentile (или mid-percentile) указывает, что клиенту не нужны значения mid-percentile (или high-percentile). Например, клиент DOTS может отправить запрос. Показанный на рисунке 5, для информирования сервера о желании получать лишь значения high-percentile. Это предполагает, что клиент будет применять этот тип процентилей при совместном с сервером использовании данных телеметрии.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=124"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "low-percentile": "0.00",
             "mid-percentile": "0.00",
             "high-percentile": "95.00"
           }
         }
       ]
     }
   }

Рисунок 5. PUT для отключения Low и Mid процентилей.


Клиенты DOTS могут также настраивать класс единиц измерения для относящихся к трафику данных телеметрии, а также другие классы единиц измерения, такие как пакет/сек, бит/сек, байт/сек. Для одного набора данных телеметрии можно применять одновременно классы бит/сек и байт/сек. Однако получение конфликтующих значений считается недействительным параметром и отвергается с кодом 4.00 (Bad Request).

Клиенты DOTS, заинтересованные в получении от сервера данных телеметрии до и в процессе смягчения атак (pre-or-ongoing-mitigation, см. параграф 9.2), должны установить для server-originated-telemetry значение true. Отсутствие server-originated-telemetry в запросе PUT эквивалентно установке для атрибута значения false. Пример запроса для включения телеметрии pre-or-ongoing-mitigation от сервера DOTS показан на рисунке 6.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=125"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "server-originated-telemetry": true
           }
         }
       ]
     }
   }

Рисунок 6. PUT для включения телеметрии до или в процессе смягчения от сервера DOTS.


7.1.3. Извлечение установленной конфигурации телеметрии DOTS

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"

Рисунок 7. GET для извлечения текущей конфигурации телеметрии DOTS.


Клиент DOTS может передать сообщение GET с параметром Uri-Path tsid для извлечения текущей конфигурации телеметрии DOTS. Пример такого запроса показан на рисунке 7.

Если сервер DOTS не находит полученного значения Uri-Path tsid в своих данных конфигурации, он должен передать отклик с кодом 4.04 (Not Found — не найдено).

7.1.4. Удаление конфигурации телеметрии DOTS

Запрос DELETE служит для удаления установленных данных конфигурации телеметрии DOTS (Рисунок 8). Параметры Uri-Path cuid и tsid обязательны для таких запрсов DELETE.

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"

Рисунок 8. Удаление конфигурации телеметрии.


Сервер DOTS сбрасывает конфигурацию телеметрии DOTS в принятые по умолчанию значения и подтверждает запрос клиента DOTS откликом с кодом 2.02 (Deleted — удаллено). Код 2.02 (Deleted) возвращается даже в том случае, когда значение параметра tsid из запроса DELETE отсутствовало в данных конфигурации до запроса.

В параграфе 7.4 описана процедура сброса всех конфигурационных данных установки телеметрии DOTS.

7.2. Общая «ёмкость» трубы

Клиент DOTS может сообщать серверам DOTS сведения о трубе (pipe) в свой домен DOTS. Структура дерева таких сведений показана на рисунке 9.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  +-- total-pipe-capacity* [link-id unit]
          |        |     +-- link-id     nt:link-id
          |        |     +-- capacity    uint64
          |        |     +-- unit        unit
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 9. Структура дерева данных о «трубе».


Труба клиентского домена DOTS определена как список ограничений на (входящий) трафик (total-pipe-capacity), который может пересылаться в домен по входящим каналам, каждый из которых указывается link-id [RFC8345].

Единицы, применяемые клиентом DOTS при передаче информации о трубе, указываются в атрибуте unit. Клиент DOTS должен автоматически приводить значения к соответствующим единицам. Т. е. для данного класса unit клиент DOTS использует наибольшую единицу измерения, дающую значение больше 1. Таким образом, разрешён лишь 1 класс unit.

7.2.1. Передача «ёмкости трубы» клиентского домена DOTS

Применимы соображения параграфа 7.1.2 с одним исключением.

Относительный порядок двух запросов PUT с атрибутами трубы клиентского домена DOTS от клиента DOTS определяется сравнением значений tsid. Если в двух запросах установки link-id и unit перекрываются, PUT с большим значением tsid будет иметь преимущество. Перекрывающиеся значения с меньшим tsid должны автоматически удаляться с утратой доступности.

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

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

Пример настройки сведений о каналах для однодомного домена DOTS показан на рисунке 10, где клиент передаёт запрос PUT (Рисунок 11) с ёмкостью канала link1, подключённого к его ISP.

    ,--,--,--.             ,--,--,--.
 ,-'          `-.       ,-'          `-.
(Клиентский домен)=====(     ISP#A      )
 `-.   DOTS   ,-'канал1 `-.          ,-'
    `--'--'--'             `--'--'--'

Рисунок 10. Однодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=126"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 11. Пример запроса PUT для передачи сведений о трубе (однодомной).


Клиентам DOTS можно задать указание совокупных сведений вместо отдельных каналов. Например, клиент с 2 каналами к восходящим ISP (Рисунок 12) может передать запрос PUT (Рисунок 13) для информирования сервера о суммарной пропускной способности каналов к ISP. Информирование об отдельных каналах определяет реализация.

    ,--,--,--.             ,--,--,--.
 ,-'          `-.===== ,-'          `-.
(Клиентский домен)    (     ISP#C      )
 `-.   DOTS   ,-'====== `-.          ,-'
    `--'--'--'             `--'--'--'

Рисунок 12. Клиентский домен DOTS с двумя соединительными каналами.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
   Uri-Path: "tsid=896"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "aggregate",
               "capacity": "700",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 13. Пример запроса PUT для передачи сведений о трубе (агрегат).


Рассмотрим клиентский домен DOTS подключенный к дополнительному ISP (например, ISP#B на рисунке 14). Клиент может информировать сервер DOTS, расположенный вне ISP#A и ISP#B о таком подключении, передавая запрос PUT, показанный на рисунке 15. Этот запрос включает сведения о канале link1, даже если этот канал не обновлён. При получении запроса сервер DOTS удалит запрос с tsid=126 и обновит конфигурацию, включив в неё link1 и link2.


   ,--,--,--.
 ,-'          `-.
(     ISP#B      )
 `-.          ,-'
    `--'--'--'
        ||
        || канал2
   ,--,--,--.             ,--,--,--.
 ,-'          `-.       ,-'         `-.
(Клиентский домен)=====(     ISP#A     )
 `-.   DOTS   ,-'канал1 `-.         ,-'
    `--'--'--'             `--'--'--'

Рисунок 14. Многодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=127"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "500",
               "unit": "megabit-ps"
             },
             {
               "link-id": "link2",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 15. Пример запроса PUT для передачи сведений о трубе (многодомный).


Клиент DOTS может исключить канал, передав запрос PUT с атрибутом capacity = 0, если для того же домена DOTS другие каналы сохраняются. Например, клиентский домен DOTS может сменить ISP и тогда клиент DOTS сообщает своему серверу DOTS об этом (например, смена конфигурации с рисунка 10 на конфигурацию с рисунка 16) в запросе PUT, показанном на рисунке 17. При получении этого запроса (если при его обработке не будет ошибок) сервер удалит канал link1 из своей конфигурации для этого клиентского домена DOTS. Отметим, что при получении сервером DOTS запроса PUT с capacity 0 для всех каналов он должен отклонить запрос с возвратом кода 4.00 (Bad Request). Для удаления всех каналов клиент DOTS может передать запрос DELETE (параграф 7.2.3).


   ,--,--,--.
 ,-'          `-.
(     ISP#B      )
 `-.          ,-'
    `--'--'--'
        ||
        || канал2
   ,--,--,--.  
 ,-'          `-.
(Клиентский домен)
 `-.   DOTS   ,-'
    `--'--'--' 

Рисунок 16. Однодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=128"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "0",
               "unit": "megabit-ps"
             },
             {
               "link-id": "link2",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 17. Пример запроса PUT для передачи сведений о трубе (многодомный).


7.2.2. Извлечение сведений о ёмкости установленной трубы клиентского домена DOTS

Запрос GET с параметром Uri-Path tsid служит для извлечения конкретных сведений об установленной трубе клиентского домена DOTS в соответствии с процедурой, описанной в параграфе 7.1.3.

Для получения всех данных о трубе, связанных с клиентом DOTS клиент выполняет процедуру из параграфа 7.1.1.

7.2.3. Удаление установленной ёмкости трубы клиентского домена

Запрос DELETE служит для удаления конкретных сведений об установленной трубе клиентского домена DOTS по процедуре, описанной в параграфе 7.1.4.

7.3. Базовый уровень телеметрии

Клиент DOTS может сообщать серверам DOTS базовый уровень трафика и пропускную способность соединений.

Total traffic normal baseline — общий базовый уровень трафика

Данные о суммарном базовом уровне трафика обеспечивают значения процентилей, представляющие общий базовый уровень трафика. Их можно представить для цели с использованием total-traffic-normal.
Нормальный уровень трафика по протоколам (total-traffic-normal-per-protocol) представляется для цели и зависит от транспортного протокола.
Нормальный уровень трафика по номерам портов (total-traffic-normal-per-port) представляется для каждого порта, связанного с целью.
Если клиент DOTS согласует значения процентилей и единицы измерения (параграф 7.1), эти согласованные параметры применяются взамен принятых по умолчанию. Для каждого используемого класса единиц клиент DOTS должен обеспечивать автоматическое приведение к соответствующим единицам.

Total connection capacity — общая пропускная способность соединений

Если цель подвержена истощающим ресурсы DDoS-атакам, полезны указанные ниже атрибуты на уровне транспортного протокола для обнаружения таких DdoS-атак.
  • Максимальное число разрешённых для цели одновременных соединений.
  • Максимальное число разрешённых для цели одновременных соединений на клиента.
  • Максимальное число разрешённых для цели «эмбриональных» соединений. Этим термином обозначают соединения, в которых ещё не завершено согласование. Такие соединения возможны лишь в ориентированных на соединения протоколах, таких как TCP или (SCTP) [RFC9260].
  • Максимальное число разрешённых для цели «эмбриональных» соединений на клиента.
  • Максимальное число разрешённых для цели соединений в секунду.
  • Максимальное число разрешённых для цели соединений в секунду на клиента.
  • Максимальное число разрешённых для цели запросов (например, HTTP/DNS/SIP) в секунду.
  • Максимальное число разрешённых для цели запросов в секунду на клиента.
  • Максимальное число разрешённых для цели остающихся неполных запросов. Атаки на основе неполных запросов создают соединения с жертвой, но не передают полного запроса (например, HTTP).
  • Максимальное число разрешённых для цели остающихся неполных запросов на клиента.
Совокупные данные для транспортного протокола выражаются в total-connection-capacity, а возможности порта — в total-connection-capacity-per-port.

Отметим, что целевой ресурс указывается с использованием атрибутов target-prefix, target-port-range, target-protocol, target-fqdn, target-uri, alias-name, как указано в параграфе 4.4.1.1 [RFC9132].

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

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           +-- baseline* [id]
          |              +-- id                     uint32
          |              +-- target-prefix*
          |              |       inet:ip-prefix
          |              +-- target-port-range* [lower-port]
          |              |  +-- lower-port    inet:port-number
          |              |  +-- upper-port?   inet:port-number
          |              +-- target-protocol*                      uint8
          |              +-- target-fqdn*
          |              |       inet:domain-name
          |              +-- target-uri*
          |              |       inet:uri
          |              +-- alias-name*
          |              |       string
          |              +-- total-traffic-normal* [unit]
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-traffic-normal-per-protocol*
          |              |       [unit protocol]
          |              |  +-- protocol             uint8
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-traffic-normal-per-port* [unit port]
          |              |  +-- port                 inet:port-number
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-connection-capacity* [protocol]
          |              |  +-- protocol                     uint8
          |              |  +-- connection?                  uint64
          |              |  +-- connection-client?           uint64
          |              |  +-- embryonic?                   uint64
          |              |  +-- embryonic-client?            uint64
          |              |  +-- connection-ps?               uint64
          |              |  +-- connection-client-ps?        uint64
          |              |  +-- request-ps?                  uint64
          |              |  +-- request-client-ps?           uint64
          |              |  +-- partial-request-max?         uint64
          |              |  +-- partial-request-client-max?  uint64
          |              +-- total-connection-capacity-per-port*
          |                      [protocol port]
          |                 +-- port
          |                 |       inet:port-number
          |                 +-- protocol                     uint8
          |                 +-- connection?                  uint64
          |                 +-- connection-client?           uint64
          |                 +-- embryonic?                   uint64
          |                 +-- embryonic-client?            uint64
          |                 +-- connection-ps?               uint64
          |                 +-- connection-client-ps?        uint64
          |                 +-- request-ps?                  uint64
          |                 +-- request-client-ps?           uint64
          |                 +-- partial-request-max?         uint64
          |                 +-- partial-request-client-max?  uint64
          +--:(telemetry)
             ...

Рисунок 18. Структура дерева базового уровня телеметрии.


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

7.3.1. Передача сведений о базовом уровне клиентского домена DOTS

Здесь применимы соображения из параграфа 7.1.2 с одним исключением.

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

Два запроса PUT от клиента DOTS имеют перекрывающиеся цели если у них общие адреса или префиксы IP, FQDN, URI или псевдонимы. Кроме того, цели запросов PUT от клиента DOTS имеют пересекающиеся цели с точки зрения сервера DOTS, если адреса, связанные с FQDN, URI, псевдонимами перекрываются между собой или с target-prefix.

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

Если в запросе нет атрибута target это указывает применение данных о базовом уровне ко всему клиентскому домену.

Пример запроса PUT для передачи сведения о базовом уровне приведён на рисунке 19.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=129"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "baseline": [
             {
               "id": 1,
               "target-prefix": [
                 "2001:db8:6401::1/128",
                 "2001:db8:6401::2/128"
               ],
               "total-traffic-normal": [
                 {
                   "unit": "megabit-ps",
                   "peak-g": "60"
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок 19. Запрос PUT для передачи сведений о базовом уровне DOTS.


Клиенты DOTS могут совместно использовать связанные с протоколом данные, как показано на рисунке 20.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=130"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "baseline": [
             {
               "id": 1,
               "target-prefix": [
                 "2001:db8:6401::1/128",
                 "2001:db8:6401::2/128"
               ],
               "total-traffic-normal-per-protocol": [
                 {
                   "unit": "megabit-ps",
                   "protocol": 6,
                   "peak-g": "50"
                 },
                 {
                   "unit": "megabit-ps",
                   "protocol": 17,
                   "peak-g": "10"
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок 20. Запрос PUT для передачи сведений о базовом уровне DOTS (2).


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

7.3.2. Получение сведений об установленном базовом уровне трафика

Запрос GET с параметром Uri-Path tsid служит для извлечения сведений об установленном в домене базовом уровне. Применяется такая же процедура, как описано а параграфе 7.1.3. Для получения сведений обо всех базовых уровнях, связанных с клиентом DOTS, клиент DOTS выполняет процедуру, описанную в параграфе 7.1.1.

7.3.3. Удаление установленных сведений о базовом уровне трафика

Запрос DELETE служит для удаления сведений об установленном в клиентском домене DOTS обычном уровне трафика. Процедура описана в параграфе 7.1.4.

7.4. Сброс установленной телеметрии

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 21. Удаление конфигурации телеметрии.


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

7.5. Конфликт с другими клиентами DOTS из того же домена

Сервер DOTS может сталкиваться с конфликтами запросов, содержащих сведения о трубе или базовом уровне от разных клиентов одного клиентского домена DOTS. Для уведомления клиентов о конфликте применяется атрибут conflict-information, следуя рекомендациям по устранению конфликта, подобным описанным в параграфе 4.4.1 [RFC9132]. В качестве причины конфликта может быть указано одно из двух значений:

1 — перекрытие целей (параграф 4.4.1 в [RFC9132]);
5 — перекрытие области действия трубы (раздел 13).

8. Телеметрия DOTS до и во время смягчения атак

Имеется два обширных класса атак DDoS: атаки с расходом пропускной способности и ресурсов цели. В этом разделе описаны атрибуты телеметрии DOTS (параграф 8.1), охватывающие оба типа атак. Эти атрибуты предназначены для обеспечения полных сведений об атаках и различных аспектов, наиболее полно характеризующих атаки.

В модуле ietf-dots-telemetry (параграф 11.1) задана структура данных нового типа сообщений telemetry (Рисунок 22).

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 22. Структура дерева типов сообщений.


Атрибуты телеметрии до и во время атаки указываются суффиксом пути /tm, который добавляется после префикса пути для формирования URI, применяемого с запросом CoAP для сигналов телеметрии DOTS. Атрибуты телеметрии pre-or-ongoing-mitigation, указанные в параграфе 8.1, могут передаваться между агентами DOTS и их могут передавать клиенты и серверы DOTS.

+-----------+                                         +-----------+
|Клиент DOTS|                                         |Сервер DOTS|
+-----------+                                         +-----------+
      |                                                     |
      |===============Запрос смягчения (mid)===============>|
      |                                                     |
      |=============Телеметрия (mid-list{mid})=============>|
      |                                                     |

Рисунок 23. Пример запроса сопоставления с использованием mid.


Агентам DOTS следует привязывать атрибуты pre-or-ongoing-mitigation к запросам на смягчение, связанным с атакованными ресурсами. В частности, запрос PUT после запроса смягчения может включать ссылку на запрос смягчения (mid-list) как показано на рисунке 23. Пример сопоставления запросов через target-prefix дан на рисунке 24.

Большинство данных телеметрии pre-or-ongoing-mitigation использует единицы измерения, относящиеся к классу unit, заданному процедурой, описанной в параграфе 7.1.2. При генерации данных телеметрии агент DOTS должен автоматически приводить данные к корректным единицам измерения.

+-----------+                                         +-----------+
|Клиент DOTS|                                         |Сервер DOTS|
+-----------+                                         +-----------+
      |                                                     |
      |<==============Телеметрия (target-prefix)============|
      |                                                     |
      |==========Запрос смягчения (target-prefix)==========>|
      |                                                     |

Рисунок 24. Пример запроса сопоставления с использованием target-prefix.


Агентам DOTS недопустимо передавать уведомления телеметрии pre-or-ongoing-mitigation одному партнёру чаще, чем 1 раз за telemetry-notify-interval (параграф 7.1). Если уведомление телеметрии передаётся в режиме подобном блочному (например,, [RFC9177]), этому правилу ограничения скорости недопустимо считать блоки отдельными сообщениями.

Запросы и отклики телеметрии DOTS до и во время смягчения атак должны помечаться как неподтверждаемые сообщения (параграф 2.1 в [RFC7252]).

8.1. Атрибуты телеметрии Pre-or-Ongoing-Mitigation

В разделе 3 описаны мотивы применения атрибутов телеметрии DOTS, описанных в последующих параграфах.

8.1.1. Цель

Ресурс target (Рисунок 25) идентифицируется с использованием атрибутов target-prefix, target-port-range, target-protocol, target-fqdn, target-uri, alias-name или указателя на запрос смягчения (mid-list).

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  +-- target-prefix*       inet:ip-prefix
                |  +-- target-port-range* [lower-port]
                |  |  +-- lower-port    inet:port-number
                |  |  +-- upper-port?   inet:port-number
                |  +-- target-protocol*     uint8
                |  +-- target-fqdn*         inet:domain-name
                |  +-- target-uri*          inet:uri
                |  +-- alias-name*          string
                |  +-- mid-list*            uint32
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 25. Структура дерева цели.


В определении цели должен присутствовать хотя бы один из атрибутов target-prefix, target-fqdn, target-uri, alias-name, mid-list.

Если цель восприимчива к атакам на пропускную способность, включаются атрибуты, представляющие значения процентилей трафика атаки attack-id. Для целей, восприимчивых к DDoS-атакам с потреблением ресурсов, атаки можно представлять с помощью атрибутов, определённых в параграфе 8.1.4.

В сообщении телеметрии DOTS должен присутствовать хотя бы атрибут target и ещё один иной атрибут pre-or-ongoing-mitigation.

8.1.2. Суммарный трафик

Атрибут total-traffic (Рисунок 26) передаёт значения процентилей (включая пиковое и наблюдаемые в данный момент) для общего наблюдаемого трафика. Более детальные сведения о суммарном трафике можно передать в атрибутах total-traffic-protocol и total-traffic-port. Атрибут total-traffic-protocol представляет суммарный трафик для цели и зависит от транспортного протокола, атрибут total-traffic-port представляет суммарный трафик для номера порта цели.

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-traffic-protocol* [unit protocol]
                |  +-- protocol             uint8
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-traffic-port* [unit port]
                |  +-- port                 inet:port-number
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 26. Структура дерева суммарного трафика.


8.1.3. Суммарный трафик атаки

Атрибут total-attack-traffic (Рисунок 27) указывает суммарный наблюдаемый трафик атаки. Более детальные сведения могут передавать атрибуты total-attack-traffic-protocol и total-attack-traffic-port. Атрибут total-attack-traffic-protocol представляет суммарный трафик атаки для цели и зависит от транспортного протокола, атрибут total-attack-traffic-port представляет суммарный трафик атаки для номера порта цели.

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic-protocol* [unit protocol]
                |  +-- protocol             uint8
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic-port* [unit port]
                |  +-- port                 inet:port-number
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 27. Структура дерева суммарного трафика атаки.


8.1.4. Суммарные соединения атаки

Если цель восприимчива к DDoS-атакам на поглощение ресурсов, атрибут total-attack-connection-protocol служит для передачи значений процентилей (включая пиковое и наблюдаемые текущие значения) различных атрибутов, связанных с общим числом соединений атаки. Ниже перечислены субатрибуты для цели по транспортным протоколам, представляющие характеристики атаки.

  • Число одновременных соединений с целью.
  • Число одновременных эмбриональных соединений с целью.
  • Число соединений с целью за секунду.
  • Число запросов для цели за секунду.
  • Число неполных запросов для цели.
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  +-- protocol              uint8
                |  +-- connection-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- embryonic-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- connection-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- request-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- partial-request-c
                |     +-- low-percentile-g?    yang:gauge64
                |     +-- mid-percentile-g?    yang:gauge64
                |     +-- high-percentile-g?   yang:gauge64
                |     +-- peak-g?              yang:gauge64
                |     +-- current-g?           yang:gauge64
                +-- total-attack-connection-port* [protocol port]
                |  +-- protocol              uint8
                |  +-- port                  inet:port-number
                |  +-- connection-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- embryonic-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- connection-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- request-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- partial-request-c
                |     +-- low-percentile-g?    yang:gauge64
                |     +-- mid-percentile-g?    yang:gauge64
                |     +-- high-percentile-g?   yang:gauge64
                |     +-- peak-g?              yang:gauge64
                |     +-- current-g?           yang:gauge64
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 28. Структура дерева соединений атаки.


Общее число соединений на порт представляется атрибутом total-attack-connection-port.

8.1.5. Детали атаки

Этот атрибут (Рисунок 29) служит для передачи подробных характеристик атаки. Субатрибуты происходящих атак перечислены ниже.

vendor-id

Идентификатор производитель (систем защиты) в форме номера предприятия из реестра IANA Private Enterprise Numbers [Private-Enterprise-Numbers].

attack-id

Уникальный идентификатор, присвоенный атаке производителем. Этот параметр должен присутствовать независимо от наличия attack-description.

description-lang

Указывает тег языка, используемого в тексте атрибута attack-description. Кодирование атрибута определяется правилами параграфа 2.1 в [RFC5646]. По умолчанию применяется кодировка en-US.

attack-description

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

attack-severity

Уровень серьёзности атаки (значения определены в параграфе 3.12.2 [RFC7970]).

start-time

Время начала атаки в секундах с 1970-01-01T00:00Z (параграф 3.4.2 в [RFC8949]). Кодирование CBOR изменено и ведущий тег 1 (дата и время на основе эпохи) должен быть опущен.

end-time

Время завершения атаки в секундах с 1970-01-01T00:00Z (параграф 3.4.2 в [RFC8949]). Кодирование CBOR изменено и ведущий тег 1 (дата и время на основе эпохи) должен быть опущен.

source-count

Цисло источников, вовлечённых в нацеленную на жертву атаку.

top-talker

Список источников, вовлечённых в атаку и генерирующих важную часть трафика атаки. Источники представляются с помощью source-prefix.
Атрибут spoofed-status указывает, использует ли источник фиктивный адрес IP (например, в атаке с отражением). Если узел spoofed-status не включён, это означает, что статус подмены адреса не известен.
Если цель подвергается атаке на поглощение пропускной способности, включается статистический профиль атаки для каждого из основных участников (total-attack-traffic, см. параграф 8.1.3).
Если цель подвергается DDoS-атаке на поглощение ресурсов, применимы заданные в параграфе 8.1.4 атрибуты для характеризации по участникам атаки.
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   +-- vendor-id             uint32
                   +-- attack-id             uint32
                   +-- description-lang?     string
                   +-- attack-description?   string
                   +-- attack-severity?      attack-severity
                   +-- start-time?           uint64
                   +-- end-time?             uint64
                   +-- source-count
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- top-talker
                      +-- talker* [source-prefix]
                         +-- spoofed-status?            boolean
                         +-- source-prefix              inet:ip-prefix
                         +-- source-port-range* [lower-port]
                         |  +-- lower-port    inet:port-number
                         |  +-- upper-port?   inet:port-number
                         +-- source-icmp-type-range* [lower-type]
                         |  +-- lower-type    uint8
                         |  +-- upper-type?   uint8
                         +-- total-attack-traffic* [unit]
                         |  +-- unit                 unit
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- total-attack-connection-protocol*
                                 [protocol]
                            +-- protocol              uint8
                            +-- connection-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- embryonic-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- connection-ps-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- request-ps-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- partial-request-c
                               +-- low-percentile-g?    yang:gauge64
                               +-- mid-percentile-g?    yang:gauge64
                               +-- high-percentile-g?   yang:gauge64
                               +-- peak-g?              yang:gauge64
                               +-- current-g?           yang:gauge64

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


Для оптимизации размера сообщений телеметрии в сигнальном канале DOTS агенты DOTS могут применять канал данных DOTS [RFC8783] при обмене зависящими от производителей деталями атак (т. е. {vendor identifier, attack identifier} ==> текстовое описание атаки). Таким образом, агенты DOTS не передают систематически описаний атаки в сообщениях телеметрии по сигнальному каналу DOTS.

8.1.6. Отображения атак

Можно использовать несколько отображений для разных идентификаторов производителей — агент DOTS, передающий данные телеметрии, может выбрать для использования одно или несколько отображений даже в одном сообщении.

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

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

   POST /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-mapping:vendor-mapping": {
       "vendor": [
         {
           "vendor-id": 345,
           "vendor-name": "mitigator-c",
           "last-updated": "1629898958",
           "attack-mapping": [
             {
               "attack-id": 1,
               "attack-description":
                  "Описание атаки"
             },
             {
               "attack-id": 2,
               "attack-description":
                  "Описание атаки"
             }
           ]
         }
       ]
     }
   }

Рисунок 30. POST для установки деталей Vendor Attack Mapping.


Модуль YANG ietf-dots-mapping, определённый в параграфе 11.2, дополняет модуль ietf-dots-data-channel [RFC8783]. Структура ietf-dots-mapping показана на рисунке 31.

   module: ietf-dots-mapping
     augment /data-channel:dots-data/data-channel:dots-client:
       +--rw vendor-mapping {dots-telemetry}?
          +--rw vendor* [vendor-id]
             +--rw vendor-id         uint32
             +--rw vendor-name?      string
             +--rw description-lang?   string
             +--rw last-updated      uint64
             +--rw attack-mapping* [attack-id]
                +--rw attack-id             uint32
                +--rw attack-description    string
     augment /data-channel:dots-data/data-channel:capabilities:
       +--ro vendor-mapping-enabled?   boolean {dots-telemetry}?
     augment /data-channel:dots-data:
       +--ro vendor-mapping {dots-telemetry}?
          +--ro vendor* [vendor-id]
             +--ro vendor-id         uint32
             +--ro vendor-name?      string
             +--ro description-lang?   string
             +--ro last-updated      uint64
             +--ro attack-mapping* [attack-id]
                +--ro attack-id             uint32
                +--ro attack-description    string

Рисунок 31. Структура дерева Vendor Attack Mapping.


Клиент DOTS передаёт запрос GET по каналу данных DOTS для получения списка поддерживаемых сервером DOTS возможностей, как указано в параграфе 7.1 [RFC8783]. Этот запрос позволяет проверить, поддерживает ли сервер совместное использование деталей отображения атак от производителя (проверка vendor-mapping-enabled).

Если vendor-mapping-enabled имеет значение true, клиент DOTS может передавать запрос GET для получения от сервера деталей отображения атак. Пример такого запроса GET представлен на рисунке 32.

   GET /restconf/data/ietf-dots-data-channel:dots-data\
       /ietf-dots-mapping:vendor-mapping HTTP/1.1
   Host: example.com
   Accept: application/yang-data+json

Рисунок 32. GET для получения Vendor Attack Mapping от сервера DOTS.


Клиент DOTS может извлечь лишь список производителей, поддерживаемых сервером DOTS, устанавливая для параметра depth (параграф 4.8.2 в [RFC8040]) значение 3 в запросе GET, как показано на рисунке 33. Пример тела отклика сервера DOTS на такой запрос приведён на рисунке 34. GET /restconf/data/ietf-dots-data-channel:dots-data\ /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 Host: example.com Accept: application/yang-data+json

Рисунок 33. GET для извлечения Vendors List, используемого сервером DOTS.

  {
     "ietf-dots-mapping:vendor-mapping": {
       "vendor": [
         {
           "vendor-id": 32473,
           "vendor-name": "mitigator-s",
           "last-updated": "1629898758",
           "attack-mapping": []
         }
       ]
     }
   }

Рисунок 34. Тело отклика на запрос GET для Vendors List.


Клиент DOTS регулярно (например, каждую неделю) повторяет процедуру обновления отображений атак производителями с сервера DOTS.

Если клиент DOTS видит, что у сервера DOTS нет ссылок на детали конкретного отображения атак, он использует запрос POST для установки своего отображения атак от производителя. Пример такого запроса показан на рисунке 30.

Сервер DOTS указывает результат обработки запроса POST в строке состояния. Если сервер воспринимает предложенное в запросе отображение, он должен возвращать строку «201 Created». Если в запросе нет обязательного атрибута или имеется недействительный или неизвестный параметр, сервер должен возвращать в отклике строку «400 Bad Request», устанавливая тег ошибки missing-attribute, invalid-value или unknown-element.

Если запрос получен через шлюз серверного домена DOTS, а сервер DOTS не поддерживает указанное значение cdid тогда как cuid ожидается, сервер должен вернуть строку «403 Forbidden» с тегом ошибки access-denied. При получении такого отклика клиент DOTS должен зарегистрироваться (параграф 5.1 в [RFC8783]).

Клиент DOTS использует запрос PUT для обновления деталей отображения атак от производителя на сервере DOTS (например, для добавления нового или обновления имеющегося отображения). Клиент DOTS использует запрос GET для получения дателей отображения атак от производителей на сревере (Рисунок 35).

   GET /restconf/data/ietf-dots-data-channel:dots-data\
       /dots-client=dz6pHjaADkaFTbjr0JGBpw\
       /ietf-dots-mapping:vendor-mapping?\
       content=all HTTP/1.1
   Host: example.com
   Accept: application/yang-data+json

Рисунок 35. GET для извлечения Installed Vendor Attack Mapping Details.


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

8.2. От клиентов к серверам DOTS

Клиенты DOTS применяют запрос PUT (Рисунок 36) для передачи телеметрии pre-or-ongoing-mitigation серверам DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "target": {
             "target-prefix": [
               "2001:db8::1/128"
             ]
           },
           "total-attack-traffic-protocol": [
             {
               "protocol": 17,
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ],
           "attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "start-time": "1608336568",
               "attack-severity": "high"
             }
           ]
         }
       ]
     }
   }

Рисунок 36. PUT для отправки телеметрии до и во время смягчения атак.


Параметр cuid является обязательным в Uri-Path запросов PUT.

Ниже приведено определение дополнительного параметра Uri-Path.

tmid

Идентификатор телеметрии (Telemetry Identifier) служит для представления данных телеметрии DOTS до и во время смягчения атак целым числом и должен создаваться клиентами DOTS. Значения tmid должны монотонно возрастать по мере необходимости передачи клиентом новых данных телеметрии pre-or-ongoing-mitigation.
При достижении максимального значения (rollover) параметра tmid должна применяться процедура, заданная в параграфе 4.4.1 [RFC9132] для параметра mid.
Этот атрибут является обязательным и должен размещаться в опциях Uri-Path после атрибута cuid.

Атрибуты cuid и tmid недопустимо включать в тело запросов PUT.

В запросе PUT должен присутствовать хотя бы один атрибут target и иной атрибут pre-or-ongoing-mitigation (параграф 8.1). При наличии лишь атрибута target, запрос обрабатывается в соответствии с параграфом 8.3.

Относительный порядов пары запросов PUT с телеметрией pre-or-ongoing-mitigation от клиента DOTS определяется сравнением значений tmid. Если в двух запросах перекрываются атрибуты target, преимущество имеет запрос с большим tmid, а запрос с меньшим tmid должен автоматически удаляться, теряя доступность.

Сервер DOTS указывает результат обработки запроса PUT кодом отклика CoAP. В частности, возвращается код 2.04 (Changed), если сервер воспринял телеметрию pre-or-ongoing-mitigation. При возникновении ошибки на сервере возвращается код 5.03 (Service Unavailable) с использованием опции Max-Age для указания числа секунд, по истечении которых можно повторить запрос.

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

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=123"

Рисунок 37. Удаление конкретных данных телеметрии Pre-or-Ongoing-Mitigation.


Клиент DOTS, который потерял статус своих активных tmid или должен сбросить tmid в 0 (например, при аварии или перезапуске) должен передать запрос GET серверам DOTS для получения списка активных tmid. Затем клиент DOTS может удалить tmid, которым больше не нужно быть активными (Рисунок 37). Передача запроса DELETE без tmid указывает, что нужно деактивировать все tmid (Рисунок 38).

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 38. Удаление всех данных телеметрии Pre-or-Ongoing-Mitigation.


8.3. От серверов DOTS к клиентам

Данные pre-or-ongoing-mitigation (в частности, детали атаки) могут передаваться от серверов DOTS клиентам. Например, сервер DOTS, размещённый вместе с детектором DDoS, может вести мониторинг целевых сетей и обнаруживать DDoS-атаки путём статистического анализа или глубокого изучения, сообщая детали атак клиентам DOTS. Клиент может использовать эти сведения для решения вопроса о потребности в смягчении атак. Кроме того, персонал служб безопасности клиентских доменов DOTS может применять детали атак для определения стратегии защиты и выбора подходящего сервера DOTS для ослабления атаки.

Для получения уведомлений телеметрии до и во время смягчения от сервера DOTS клиент DOTS должен передать запрос PUT (затем GET) с фильтром цели. Пример такого запроса PUT показан на рисунке 39. Чтобы не поддерживать длинный список таких запросов, клиентам DOTS рекомендуется включать в один запрос все цели (в предположении, что эти сведения помещаются в одну дейтаграмму). Серверам DOTS можно задать ограничение числа запросов pre-or-ongoing-mitigation на клиентский домен DOTS. Запросы pre-or-ongoing-mitigation должны поддерживаться в активном состоянии сервером DOTS до получения от того же клиента DOTS запроса DELETE, отменяющего эту телеметрию pre-or-ongoing-mitigation, или пока клиент DOTS не будет сочтён неактивным (см., например, параграф 3.5 в [RFC8783]).

Относительный порядов пары запросов PUT для телеметрии pre-or-ongoing-mitigation от клиента DOTS определяется сравнением значений tmid. Если в двух запросах перекрываются атрибуты target, преимущество имеет запрос с большим tmid, а запрос с меньшим tmid должен автоматически удаляться, теряя доступность.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=567"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "target": {
             "target-prefix": [
               "2001:db8::/32"
             ]
           }
         }
       ]
     }
   }

Рисунок 39. PUT для запроса телеметрии Pre-or-Ongoing-Mitigation.


Клиенты DOTS из одного домена могут запросить получение телеметрии pre-or-ongoing-mitigation, привязанной к одной цели, без возникновения «перекрытий» и конфликтов.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=567"
   Observe: 0

Рисунок 40. GET для подписки на асинхронные уведомления телеметрии для tmid.


После успешного выполнения запроса PUT для создания статуса запроса на сервере клиент DOTS передаёт запрос GET для получения обновлений телеметрии. Клиент использует опцию Observe = 0 (регистрация) в запросе GET для получения асинхронных уведомлений с данными телеметрии до и во время смягчения атак от сревреа DOTS. Запрос GET может указывать конкретное значение tmid (Рисунок 40) или не включать tmid (Рисунок 41) для получения обновления по всем запросам от этого клиента.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Observe: 0

Рисунок 41. GET для подписки на асинхронные уведомления телеметрии для всех tmid.


Клиент DOTS может задать фильтр для запроса части асинхронных уведомлений от сервера DOTS, включив одну или несколько опций Uri-Query в свой запрос GET. Опция Uri-Query может включать параметры target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, mid и c (content — содержимое) (параграф 5.4).

  • При наличии в запросе нескольких опций Uri-Query они интерпретируются так же, как при включении нескольких атрибутов target в тело сообщения (параграф 4.4.1 в [RFC9132]).

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

  • Диапазоны значений (непрерывный блок с включением границ) можно применять в параметрах target-port, target-protocol и mid, указывая границы через дефис (-).

  • Шаблоны имён (левая часть имени заменена символом *) можно включать в параметры target-fqdn и target-uri. Клиентам DOTS недопустимо указывать шаблоны, где символ * не является первым. Примером корректного шаблона служит *.example.com и такие шаблоны можно включать в параметр target-fqdn опции Uri-Query.

Клиенты DOTS могут также филтровать асинхронные уведомления от сервера DOTS, указывая информацию о конкретном источнике атаки с помощью атрибутов source-prefix, source-port, source-icmp-type в опции Uri-Query. Здесь применяется такой же подход (диапазоны, множество значений) как для атрибутов цели. При использовании этих фильтров следует соблюдать особую осторожность, поскольку фильтры могут скрывать некоторые атаки от запрашивающего клиента DOTS (например, при смене информации об источнике атаки).

Запросы с недействительными (например, не поддерживаемыми или некорректно сформированными) типами сервер DOTS должен отвергать с кодом 4.00 (Bad Request).

Пример запроса подписки на асинхронные уведомления, относящиеся к трафику UDP, показан на рисунке 42. Этот фильтр применяется для всех tmid.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Query: "target-protocol=17"
   Observe: 0

Рисунок 42. GET для получения асинхронных уведомлений с фильтром Uri-Query.


Сервер DOTS будет передавать асинхронные уведомления клиентам DOTS при обнаружении связанных с атакой событий, следуя процедурам, подобным описанным в параграфе 4.4.2.1 [RFC9132]. Пример асинхронного уведомления телеметрии pre-or-ongoing-mitigation показан на рисунке 43.

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "tmid": 567,
           "target": {
             "target-prefix": [
               "2001:db8::1/128"
             ]
           },
           "target-protocol": [
             17
           ],
           "total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ],
           "attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "start-time": "1618339785",
               "attack-severity": "high"
             }
           ]
         }
       ]
     }
   }

Рисунок 43. Тело уведомления телеметрии Pre-or-Ongoing-Mitigation от сервера DOTS.


Сервер DOTS передаёт совокупные данные для цели, используя атрибут total-attack-traffic. Агрегирование предполагает применение для цели фильтров Uri-Query. Сервер DOTS при необходимости может включить более подробные сведения (т. е. total-attack-traffic-protocol и total-attack-traffic-port). Если в запрос включён фильтр по протоколу (или порту), применяется total-attack-traffic-protocol (или total-attack-traffic-port).

Сервер DOTS может агрегировать данные pre-or-ongoing-mitigation (например, top-talker) для всех целей домена или (когда это задано) передавать конкретные сведения (например, top-talker) для указанной цели.

Клиент DOTS может регистрировать данные телеметрии pre-or-ongoing-mitigation с передачей сигналов администратору или сетевому контроллеру. Клиент DOTS может передавать запросы на смягчение, если атаку не удаётся обработать локально. Клиент DOTS, не заинтересованный в телеметрии pre-or-ongoing-mitigation, передаёт запрос DELETE, подобно показанному на рисунке 37 запросу DELETE.

9. Обновление статуса телеметрии смягчения DOTS

9.1. От клиентов к серверам DOTS — телеметрия эффективности смягчения

Атрибуты телеметрии эффективности смягчения атак могут передаваться серверам от клиентов DOTS как часть периодических обновления эффективности смягчения, отправляемых серверу (параграф 4.4.3 в [RFC9132]).

Total attack traffic — суммарный трафик атаки

Суммарный трафик с точки зрения клиента DOTS в процессе смягчения атаки (см. Рисунок 27).

Attack details — детали атаки

Детали атаки с точки зрения клиента DOTS в процессе смягчения атаки (см. параграф 8.1.5).

Модуль YANG ietf-dots-telemetry (параграф 11.1) дополняет тип mitigation-scope из модуля ietf-dots-signal-channel [RFC9132], чтобы клиент DOTS мог передавать эти атрибуты в обновлениях эффективности смягчения (Рисунок 44).

     augment-structure /dots-signal:dots-signal/dots-signal:message-type
                       /dots-signal:mitigation-scope/dots-signal:scope:
       +-- total-attack-traffic* [unit]
       |  +-- unit                 unit
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- attack-detail* [vendor-id attack-id]
          +-- vendor-id             uint32
          +-- attack-id             uint32
          +-- attack-description?   string
          +-- attack-severity?      attack-severity
          +-- start-time?           uint64
          +-- end-time?             uint64
          +-- source-count
          |  +-- low-percentile-g?    yang:gauge64
          |  +-- mid-percentile-g?    yang:gauge64
          |  +-- high-percentile-g?   yang:gauge64
          |  +-- peak-g?              yang:gauge64
          |  +-- current-g?           yang:gauge64
          +-- top-talker
             +-- talker* [source-prefix]
                +-- spoofed-status?            boolean
                +-- source-prefix              inet:ip-prefix
                +-- source-port-range* [lower-port]
                |  +-- lower-port    inet:port-number
                |  +-- upper-port?   inet:port-number
                +-- source-icmp-type-range* [lower-type]
                |  +-- lower-type    uint8
                |  +-- upper-type?   uint8
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection
                   +-- connection-c
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- embryonic-c
                   |  ...
                   +-- connection-ps-c
                   |  ...
                   +-- request-ps-c
                   |  ...
                   +-- partial-request-c
                      ...

Рисунок 44. Структура дерева обновления эффективности телеметрии.


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

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=123"
   If-Match:
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "alias-name": [
             "https1",
             "https2"
           ],
           "attack-status": "under-attack",
           "ietf-dots-telemetry:total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ]
         }
       ]
     }
   }

Рисунок 45. Пример обновления эффективности телеметрии с атрибутами телеметрии.


Пример обновления эффективности смягчения с атрибутами телеметрии показан на рисунке 45.

9.2. От серверов к клиентам — атрибуты телеметрии статуса смягчения DOTS

Атрибуты телеметрии статуса смягчения атак могут передаваться от сервера DOTS клиентам как часть периодического обновления статуса смягчения (параграф 4.4.2 в [RFC9132]). В частности, клиенты DOTS могут получать асинхронные уведомления о деталях атаки от сервера с использованием опции Observe, определённой в [RFC7641]. Для использования этой возможности клиенты DOTS должны организовать сеанс телеметрии с сервером в состоянии «бездействия» и должны установить для атрибута server-originated-telemetry значение true. Серверам DOTS недопустимо включать атрибуты в обновления статуса смягчения для клиентов DOTS в сессиях телеметрии, где для server-originated-telemetry задано значение false.

Как задано в [RFC8612], фактические действия по смягчению атак могут включать несколько мер противодействия. Сервер DOTS передаёт текущий статус соответствующих мер и может включать список обнаруженных атак. Атрибуты, заданные в параграфе 8.1.5, применимы к описанию атак, обнаруженных и смягчаемых в домене сервера DOTS.

Модуль YANG ietf-dots-telemetry (параграф 11.1) дополняет тип сообщений mitigation-scope из модуля ietf-dots-signal-channel [RFC9132] данными телеметрии, как показано на рисунке 46.

     augment-structure /dots-signal:dots-signal/dots-signal:message-type
                       /dots-signal:mitigation-scope/dots-signal:scope:
       +-- (direction)?
       |  +--:(server-to-client-only)
       |     +-- total-traffic* [unit]
       |     |  +-- unit                 unit
       |     |  +-- low-percentile-g?    yang:gauge64
       |     |  +-- mid-percentile-g?    yang:gauge64
       |     |  +-- high-percentile-g?   yang:gauge64
       |     |  +-- peak-g?              yang:gauge64
       |     |  +-- current-g?           yang:gauge64
       |     +-- total-attack-connection
       |        +-- connection-c
       |        |  +-- low-percentile-g?    yang:gauge64
       |        |  +-- mid-percentile-g?    yang:gauge64
       |        |  +-- high-percentile-g?   yang:gauge64
       |        |  +-- peak-g?              yang:gauge64
       |        |  +-- current-g?           yang:gauge64
       |        +-- embryonic-c
       |        |  ...
       |        +-- connection-ps-c
       |        |  ...
       |        +-- request-ps-c
       |        |  ...
       |        +-- partial-request-c
       |           ...
       +-- total-attack-traffic* [unit]
       |  +-- unit                 unit
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- attack-detail* [vendor-id attack-id]
          +-- vendor-id             uint32
          +-- attack-id             uint32
          +-- attack-description?   string
          +-- attack-severity?      attack-severity
          +-- start-time?           uint64
          +-- end-time?             uint64
          +-- source-count
          |  +-- low-percentile-g?    yang:gauge64
          |  +-- mid-percentile-g?    yang:gauge64
          |  +-- high-percentile-g?   yang:gauge64
          |  +-- peak-g?              yang:gauge64
          |  +-- current-g?           yang:gauge64
          +-- top-talker
             +-- talker* [source-prefix]
                +-- spoofed-status?            boolean
                +-- source-prefix              inet:ip-prefix
                +-- source-port-range* [lower-port]
                |  +-- lower-port    inet:port-number
                |  +-- upper-port?   inet:port-number
                +-- source-icmp-type-range* [lower-type]
                |  +-- lower-type    uint8
                |  +-- upper-type?   uint8
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection
                   +-- connection-c
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- embryonic-c
                   |  ...
                   +-- connection-ps-c
                   |  ...
                   +-- request-ps-c
                   |  ...
                   +-- partial-request-c
                      ...

Рисунок 46. Структура дерева телеметрии статуса смягчения от сервера к клиенту.


На рисунке 47 приведён пример асинхронного уведомления о статусе смягчения атак от сервера DOTS. Это уведомления содержит значение mid-percentile трафика обрабатываемой атаки и пиковые значения уникальных участников атаки.

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "mid": 12332,
           "mitigation-start": "1507818434",
           "alias-name": [
             "https1",
             "https2"
           ],
           "lifetime": 1600,
           "status": "attack-successfully-mitigated",
           "bytes-dropped": "134334555",
           "bps-dropped": "43344",
           "pkts-dropped": "333334444",
           "pps-dropped": "432432",
           "ietf-dots-telemetry:total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "752"
             }
           ],
           "ietf-dots-telemetry:attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "source-count": {
                 "peak-g": "12683"
               }
             }
           ]
         }
       ]
     }
   }

Рисунок 47. Тело отклика со статусом смягчения и атрибутами телеметрии.


Клиенты DOTS могут фильтровать асинхронные уведомления от сервера DOTS, указывая опцию Uri-Query в запросе GET. Опция Uri-Query может включать параметры target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, c (content) (параграф 5.4). Должны применяться приведённые в параграфе 8.3 соображения в части включения нескольких значений, диапазонов (target-port, target-protocol) и шаблонов (target-fqdn, target-uri). Пример запроса подписки на асинхронные уведомления для псевдонима https1 приведён на рисунке 48.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=12332"
   Uri-Query: "target-alias=https1"
   Observe: 0

Рисунок 48. GET для получения асинхронных уведомлений с фильтром Uri-Query.


Если запрос не соответствует цели встроенного mid на сервере DOTS, сервер должен возвращать отклик 4.04 (Not Found). Серверу DOTS недопустимо добавлять новую запись Observe, если запрос перекрывается с имеющейся записью Observe. В таком случае сервер должен возвращать отклик 4.09 (Conflict).

10. Обработка ошибок

Список ошибок CoAP, поддерживаемых серверами DOTS, представлен в разделе 9 [RFC9132]. Ниже указаны ошибки, относящиеся к расширению для телеметрии.

  • 4.00 (Bad Request) сервер DOTS возвращает при получении от клиента запросов, нарушающих расширение телеметрии DOTS.

  • 4.04 (Not Found) сервер DOTS возвращает при получении от клиента запросов с недействительным tsid или tmid.

  • 4.00 (Bad Request) сервер DOTS возвращает при получении от клиента недействительных запросов (например, не поддерживаемых или некорректно сформированных).

  • 4.04 (Not Found) сервер DOTS возвращает при получении от клиента запросов с целью, не соответствующей вложенному mid на сервере DOTS.

Как указано в разделе 9 [RFC9132], в теле отклика возвращается дополнительный текст (параграф 5.5.2 в [RFC7252]), помогающий в поиске неполадок.

11. Модули YANG

11.1. Модуль телеметрии сигнального канала DOTS

Этот модуль использует типы, определённые в [RFC6991] и [RFC8345], а также группировки из [RFC8783].

   <CODE BEGINS> file "ietf-dots-telemetry@2022-06-20.yang"
   module ietf-dots-telemetry {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
     prefix dots-telemetry;

     import ietf-dots-signal-channel {
       prefix dots-signal;
       reference
         "RFC 9132: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Signal Channel Specification";
     }
     import ietf-dots-data-channel {
       prefix data-channel;
       reference
         "RFC 8783: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Data Channel Specification";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types, Section 4";
     }
     import ietf-network-topology {
       prefix nt;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies,
                    Section 6.2";
     }
     import ietf-yang-structure-ext {
       prefix sx;
       reference
         "RFC 8791: YANG Data Structure Extensions";
     }

     organization
       "IETF DDoS Open Threat Signaling (DOTS) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dots/> 
        WG List:  <mailto:dots@ietf.org> 

        Author:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 

        Author:   Konda, Tirumaleswar Reddy.K
                  <mailto:kondtir@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для сигналов телеметрии
        DOTS, передаваемых между клиентами и серверами DOTS по 
        сигнальному каналу DOTS.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9244: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Telemetry";
     }

     typedef attack-severity {
       type enumeration {
         enum none {
           value 1;
           description
             "Без влияния на клиентский домен DOTS.";
         }
         enum low {
           value 2;
           description
             "Минимальное влияние на клиентский домен DOTS.";
         }
         enum medium {
           value 3;
           description
             "Часть ресурсов клиентского домена DOTS не обслуживается.";
         }
         enum high {
           value 4;
           description
             "Клиентский домен DOTS находится в крайне тяжёлых условиях.";
         }
         enum unknown {
           value 5;
           description
             "Влияние атаки не известно.";
         }
       }
       description
         "Перечисляемые значения для уровня атак.";
       reference
         "RFC 7970: The Incident Object Description Exchange
                    Format Version 2, Section 3.12.2";
     }

     typedef unit-class {
       type enumeration {
         enum packet-ps {
           value 1;
           description
             "Пакетов в секунду (pps).";
         }
         enum bit-ps {
           value 2;
           description
             "Бит в секунду (bps).";
         }
         enum byte-ps {
           value 3;
           description
             "Байт в секунду (Bps).";
         }
       }
       description
         "Перечисляемые значения для классов единиц измерения.
          Поддерживаются классы pps, bps, Bps.";
     }

     typedef unit {
       type enumeration {
         enum packet-ps {
           value 1;
           description
             "Пакетов в секунду (pps).";
         }
         enum bit-ps {
           value 2;
           description
             "Бит в секунду (bps).";
         }
         enum byte-ps {
           value 3;
           description
             "Байт в секунду (Bps).";
         }
         enum kilopacket-ps {
           value 4;
           description
             "Килопакетов в секунду (kpps).";
         }
         enum kilobit-ps {
           value 5;
           description
             "Килобит в секунду (kbps).";
         }
         enum kilobyte-ps {
           value 6;
           description
             "Килобайт в секунду (kBps).";
         }
         enum megapacket-ps {
           value 7;
           description
             "Мегапакетов в секунду (Mpps).";
         }
         enum megabit-ps {
           value 8;
           description
             "Мегабит в секунду (Mbps).";
         }
         enum megabyte-ps {
           value 9;
           description
             "Мегабайт в секунду (MBps).";
         }
         enum gigapacket-ps {
           value 10;
           description
             "Гигапакетов в секунду (Gpps).";
         }
         enum gigabit-ps {
           value 11;
           description
             "Гигабит в секунду (Gbps).";
         }
         enum gigabyte-ps {
           value 12;
           description
             "Гигабайт в секунду (GBps).";
         }
         enum terapacket-ps {
           value 13;
           description
             "Терапакетов в секунду (Tpps).";
         }
         enum terabit-ps {
           value 14;
           description
             "Терабит в секунду (Tbps).";
         }
         enum terabyte-ps {
           value 15;
           description
             "Терабайт в секунду (TBps).";
         }
         enum petapacket-ps {
           value 16;
           description
             "Петапакетов в секунду (Ppps).";
         }
         enum petabit-ps {
           value 17;
           description
             "Петабит в секунду (Pbps).";
         }
         enum petabyte-ps {
           value 18;
           description
             "Петабайт в секунду (PBps).";
         }
         enum exapacket-ps {
           value 19;
           description
             "Экзапакетов в секунду (Epps).";
         }
         enum exabit-ps {
           value 20;
           description
             "Экзабит в секунду (Ebps).";
         }
         enum exabyte-ps {
           value 21;
           description
             "Экзабайт в секунду (EBps).";
         }
         enum zettapacket-ps {
           value 22;
           description
             "Зеттапакетов в секунду (Zpps).";
         }
         enum zettabit-ps {
           value 23;
           description
             "зеттабит в секунду (Zbps).";
         }
         enum zettabyte-ps {
           value 24;
           description
             "Зеттабайт в секунду (ZBps).";
         }
       }
       description
         "Перечисляемые значения для единиц измерения. В связи с
          автоматическим масштабированием применяется лишь одна
          единица на класс.";
     }

     typedef interval {
       type enumeration {
         enum 5-minutes {
           value 1;
           description
             "5 минут.";
         }
         enum 10-minutes {
           value 2;
           description
             "10 минут.";
         }
         enum 30-minutes {
           value 3;
           description
             "30 минут.";
         }
         enum hour {
           value 4;
           description
             "Час.";
         }
         enum day {
           value 5;
           description
             "День.";
         }
         enum week {
           value 6;
           description
             "Неделя.";
         }
         enum month {
           value 7;
           description
             "Месяц.";
         }
       }
       description
         "Перечисляемые значения для продолжительности измерения.";
     }

     typedef sample {
       type enumeration {
         enum second {
           value 1;
           description
             "1-секундный интервал измерения.";
         }
         enum 5-seconds {
           value 2;
           description
             "5-секундный интервал измерения.";
         }
         enum 30-seconds {
           value 3;
           description
             "30-секундный интервал измерения.";
         }
         enum minute {
           value 4;
           description
             "1-минутный интервал измерения.";
         }
         enum 5-minutes {
           value 5;
           description
             "5-минутный интервал измерения.";
         }
         enum 10-minutes {
           value 6;
           description
             "10-минутный интервал измерения.";
         }
         enum 30-minutes {
           value 7;
           description
             "30-минутный интервал измерения.";
         }
         enum hour {
           value 8;
           description
             "Часовой интервал измерения.";
         }
       }
       description
         "Перечисляемые значения для интервала выборки.";
     }

     typedef percentile {
       type decimal64 {
         fraction-digits 2;
       }
       description
         "n-й процентиль из набора данных имеет значение при котором
          n процентов данных меньше его.";
     }

     typedef query-type {
       type enumeration {
         enum target-prefix {
           value 1;
           description
             "Запрос на основе префикса цели.";
         }
         enum target-port {
           value 2;
           description
             "Запрос на основе номера порта цели.";
         }
         enum target-protocol {
           value 3;
           description
             "Запрос на основе протокола цели.";
         }
         enum target-fqdn {
           value 4;
           description
             "Запрос на основе FQDN цели.";
         }
         enum target-uri {
           value 5;
           description
             "Запрос на основе URI цели.";
         }
         enum target-alias {
           value 6;
           description
             "Запрос на основе псевдонима цели.";
         }
         enum mid {
           value 7;
           description
             "Запрос на основе идентификатора смягчения (mid).";
         }
         enum source-prefix {
           value 8;
           description
             "Запрос на основе префикса источника.";
         }
         enum source-port {
           value 9;
           description
             "Запрос на основе номера порта.";
         }
         enum source-icmp-type {
           value 10;
           description
             "Запрос на основе типа ICMP.";
         }
         enum content {
           value 11;
           description
             "Запрос на основе опции Uri-Query c (content), применяемый для
              выбора конфигурационных и неконфигурационных узлов данных.";
           reference
             "RFC 9132: Distributed Denial-of-Service Open Threat
                        Signaling (DOTS) Signal Channel
                        Specification, Section 4.4.2";
         }
       }
       description
         "Перечисляемые значения для типов запроса, которые могут применться
          в запросах GET для фильтрации данных. Запрос с недействительным
          типом (например, не поддерживаемым или с неверным форматом) сервер
          DOTS отвергает с возвратом кода 4.00 (Bad Request).";
     }

     grouping telemetry-parameters {
       description
         "Группировка с набором параметров подготовки отчётов телеметрии.

          Группировка указывает интервалы измерения и выборки, а также
          значение low-percentile/mid-percentile/high-percentile.";
       leaf measurement-interval {
         type interval;
         description
           "Задаёт период, в течение которого рассчитываются процентили.";
       }
       leaf measurement-sample {
         type sample;
         description
           "Задаёт распределение времени измерения значений, применяемых
            для расчёта процентилей.

            Интервал выборки должен быть меньше длительности измерений.";
       }
       leaf low-percentile {
         type percentile;
         default "10.00";
         description
           "Low-percentile. Значение 0 отменяет low-percentile.";
       }
       leaf mid-percentile {
         type percentile;
         must '. >= ../low-percentile' {
           error-message
             "Значение mid-percentile должно быть не меньше low-percentile.";
         }
         default "50.00";
         description
           "Mid-percentile. Совпадение с low-percentile означает отказ от
            значений mid-percentile.";
       }
       leaf high-percentile {
         type percentile;
         must '. >= ../mid-percentile' {
           error-message
             "Должно быть не меньше mid-percentile.";
         }
         default "90.00";
         description
           "High-percentile. Совпадение с mid-percentile означает отказ от
            значений high-percentile.";
       }
     }

     grouping percentile-and-peak {
       description
         "Базовая группировка для значений процентилей и пиков.";
       leaf low-percentile-g {
         type yang:gauge64;
         description
           "Значение Low-percentile.";
       }
       leaf mid-percentile-g {
         type yang:gauge64;
         description
           "Значение Mid-percentile.";
       }
       leaf high-percentile-g {
         type yang:gauge64;
         description
           "Значение High-percentile.";
       }
       leaf peak-g {
         type yang:gauge64;
         description
           "Значение пика.";
       }
     }

     grouping percentile-peak-and-current {
       description
         "Базовая группировка для значений процентилей и пиков.";
       uses percentile-and-peak;
       leaf current-g {
         type yang:gauge64;
         description
           "Текущее значение.";
       }
     }

     grouping unit-config {
       description
         "Базовая группировка для настройки единиц измерения.";
       list unit-config {
         key "unit";
         description
           "Управляет калссами единиц, разрешенными для обмена данными.";
         leaf unit {
           type unit-class;
           description
             "Можно применять packet-ps, bit-ps или byte-ps.";
         }
         leaf unit-status {
           type boolean;
           mandatory true;
           description
             "Разрешает или запрещает класс единиц измерения.";
         }
       }
     }

     grouping traffic-unit {
       description
         "Группировка трафика как функции единицы измерения.";
       leaf unit {
         type unit;
         description
           "Трафик можно измерять с использованием классов packet-ps, 
            bit-ps или byte-ps. Агенты DOTS автоматически приводят к 
            соответствующим единицам (например, megabit-ps, kilobit-ps).";
       }
       uses percentile-and-peak;
     }

     grouping traffic-unit-all {
       description
         "Группировка трафика как функции единицы измерения,
          включая текущие значения.";
       uses traffic-unit;
       leaf current-g {
         type yang:gauge64;
         description
           "Текущее наблюдаемое значение.";
       }
     }

     grouping traffic-unit-protocol {
       description
         "Группировка трафика данного транспортного протокола
          как функции единицы измерения.";
       leaf protocol {
         type uint8;
         description
           "Транспортный протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>. 

            Например, этот параметр содержит значение 6 для TCP,
            17 для UDP, 33 для DCCP, 132 для SCTP.";
       }
       uses traffic-unit;
     }

     grouping traffic-unit-protocol-all {
       description
         "Группировка трафика данного транспортного протокола как
          функции единицы измерения, включая текущие значения.";
       uses traffic-unit-protocol;
       leaf current-g {
         type yang:gauge64;
         description
           "Текущее наблюдаемое значение.";
       }
     }

     grouping traffic-unit-port {
       description
         "Группировка трафика данного номера порта как функции
          единицы измерения.";
       leaf port {
         type inet:port-number;
         description
           "Номер порта, используемый транспортным протоколом.";
       }
       uses traffic-unit;
     }

     grouping traffic-unit-port-all {
       description
         "Группировка трафика данного номера порта как функции
          единицы измерения, включая текущие значения.";
       uses traffic-unit-port;
       leaf current-g {
         type yang:gauge64;
         description
           "Текущее наблюдаемое значение.";
       }
     }

     grouping total-connection-capacity {
       description
         "Общая ёмкость различных типов соединений, а также суммарная 
          пропускная способность. Эти узлы данных полезны для обнаружения
          нацеленных на поглощение ресурсов DDoS-атак.";
       leaf connection {
         type uint64;
         description
           "Максимальное число разрешённых одновременных соединений с 
            целевым сервером.";
       }
       leaf connection-client {
         type uint64;
         description
           "Максимальное число разрешённых одновременных соединений с 
            целевым сервером на клиента.";
       }
       leaf embryonic {
         type uint64;
         description
           "Максимальное число разрешённых одновременных эмбриональных 
            соединений с сервером. Эмбриональным считается соединение, где
            согласование не завершено. Такие соединения возможны лишь для
            ориентированных на соединения протоколов, таких как TCP и SCTP.";
       }
       leaf embryonic-client {
         type uint64;
         description
           " Максимальное число разрешённых одновременных эмбриональных 
            соединений с сервером на клиента.";
       }
       leaf connection-ps {
         type uint64;
         description
           "Максимальное число новых соединений с целевым сервером в 
            секунду.";
       }
       leaf connection-client-ps {
         type uint64;
         description
           "Максимальное число новых соединений с целевым сервером в 
            секунду на клиента.";
       }
       leaf request-ps {
         type uint64;
         description
           "Максимальное число запросов в секунду для целевого сервера.";
       }
       leaf request-client-ps {
         type uint64;
         description
           "Максимальное число запросов в секунду для целевого сервера
            на клиента.";
       }
       leaf partial-request-max {
         type uint64;
         description
           "Максимальное число остающихся частичных запросов для целевого
            сервера.";
       }
       leaf partial-request-client-max {
         type uint64;
         description
           "Максимальное число остающихся частичных запросов для целевого
            сервера на клиента.";
       }
     }

     grouping total-connection-capacity-protocol {
       description
         "Общая ёмкость соединения на протокол. Эти узлы данных полезны для 
          обнаружения нацеленных на поглощение ресурсов DDoS-атак.";
       leaf protocol {
         type uint8;
         description
           "Транспортный протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>."; 
       }
       uses total-connection-capacity;
     }

     grouping connection-percentile-and-peak {
       description
         "Узлы данных для представления характеристик атаки.";
       container connection-c {
         uses percentile-and-peak;
         description
           "Число одновременных соединений с сервером для атаки.";
       }
       container embryonic-c {
         uses percentile-and-peak;
         description
           "Число одновременных эмбриональных соединений с сервером
            для атаки.";
       }
       container connection-ps-c {
         uses percentile-and-peak;
         description
           "Число соединений с сервером в секунду для атаки.";
       }
       container request-ps-c {
         uses percentile-and-peak;
         description
           "Число запросов к серверу в секунду для атаки.";
       }
       container partial-request-c {
         uses percentile-and-peak;
         description
           "Число частичных запросов к серверу в секунду для атаки.";
       }
     }

     grouping connection-all {
       description
         "Всего соединений в атаке с учётом текущих значений.";
       container connection-c {
         uses percentile-peak-and-current;
         description
           "Число одновременных соединений с сервером для атаки.";
       }
       container embryonic-c {
         uses percentile-peak-and-current;
         description
           "Число одновременных эмбриональных соединений с сервером
            для атаки.";
       }
       container connection-ps-c {
         uses percentile-peak-and-current;
         description
           "Число соединений с сервером в секунду для атаки.";
       }
       container request-ps-c {
         uses percentile-peak-and-current;
         description
           "Число запросов к серверу в секунду для атаки.";
       }
       container partial-request-c {
         uses percentile-peak-and-current;
         description
           "Число частичных запросов к серверу в секунду для атаки.";
       }
     }

     grouping connection-protocol {
       description
         "Общее число соединений для атаки.";
       leaf protocol {
         type uint8;
         description
           "Транспортый протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>."; 
       }
       uses connection-percentile-and-peak;
     }

     grouping connection-port {
       description
         "Общее число соединений для атаки с данным портом.";
       leaf protocol {
         type uint8;
         description
           "Транспортый протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>."; 
       }
       leaf port {
         type inet:port-number;
         description
           "Номер порта.";
       }
       uses connection-percentile-and-peak;
     }

     grouping connection-protocol-all {
       description
         "Общее число соединений для атаки, включая текущие значения.";
       leaf protocol {
         type uint8;
         description
           "Транспортый протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>."; 
       }
       uses connection-all;
     }

     grouping connection-protocol-port-all {
       description
         "Общее число соединений для атаки на порт, включая 
          текущие значения.";
       leaf protocol {
         type uint8;
         description
           "Транспортый протокол из реестра IANA Protocol Numbers
            <https://www.iana.org/assignments/protocol-numbers/>."; 
       }
       leaf port {
         type inet:port-number;
         description
           "Номер порта.";
       }
       uses connection-all;
     }

     grouping attack-detail {
       description
         "Детали, описывающие происходящие атаки, которые нужно смягчать
          с помощью сервера DOTS. Детали должны охватывать общие и
          хорошо известные атаки (такие, как SYN flood), а также новые
          и связанные с определёнными производителями атаки.";
       leaf vendor-id {
         type uint32;
         description
           "Vendor ID - идентификатор производителя из реестра IANA 
            Private Enterprise Number.";
         reference
           "IANA: Private Enterprise Numbers
            (https://www.iana.org/assignments/enterprise-numbers/)"; 
       }
       leaf attack-id {
         type uint32;
         description
           "Уникальный идентификатор, заданный для атаки производителем.";
       }
       leaf description-lang {
         type string {
           pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
                 + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
                 + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
                 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
                 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
                 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
                 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
                 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
                 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
                 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
                 + '|[Ii]-[Hh][Aa][Kk]|'
                 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
                 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
                 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
                 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
                 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
                 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
                 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
                 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
                 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
                 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
                 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
                 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
                 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
                 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
         }
         default "en-US";
         description
           "Тег языка для attack-description.";
         reference
           "RFC 5646: Tags for Identifying Languages, Section 2.1";
       }
       leaf attack-description {
         type string;
         description
           "Текстовое описание атаки. Методы обработки естественных
            языков (например, встраивание слов) могут быть полезны
            в сопоставлении описания атаки с её типом.";
       }
       leaf attack-severity {
         type attack-severity;
         description
           "Уровень серьёзности атаки, определяемый реализацией.";
       }
       leaf start-time {
         type uint64;
         description
           "Время начала атаки в секундах с 1970-01-01T00:00:00Z.";
       }
       leaf end-time {
         type uint64;
         description
           "Время завершения атаки в секундах с 1970-01-01T00:00:00Z.";
       }
       container source-count {
         description
           "Число уникальных источников, вовлечённых в атаку.";
         uses percentile-and-peak;
         leaf current-g {
           type yang:gauge64;
           description
             "Текущее наблюдаемое значение.";
         }
       }
     }

     grouping talker {
       description
         "Определяет базовые данные о наиболее активных участниках.";
       leaf spoofed-status {
         type boolean;
         description
           "Значение true указывает, что адрес подменен.";
       }
       leaf source-prefix {
         type inet:ip-prefix;
         description
           "Префикс IPv4 или IPv6, указывающий атакующих.";
       }
       list source-port-range {
         key "lower-port";
         description
           "Диапазон портов. Наличие лишь lower-port указывает 1 порт.";
         leaf lower-port {
           type inet:port-number;
           description
             "Меньший номер диапазона портов.";
         }
         leaf upper-port {
           type inet:port-number;
           must '. >= ../lower-port' {
             error-message
               "Старший порт должен иметь номер больше, чем младший.";
           }
           description
             "Больший номер диапазона портов.";
         }
       }
       list source-icmp-type-range {
         key "lower-type";
         description
           "Диапазон типов ICMP. Указание лишь lower-type представляет 
            один тип ICMP.";
         leaf lower-type {
           type uint8;
           description
             "Меньшее значение диапазона типов ICMP.";
         }
         leaf upper-type {
           type uint8;
           must '. >= ../lower-type' {
             error-message
               "Верхнее значение типа ICMP должно быть больше нижнего.";
           }
           description
             "Большее значение диапазона типов ICMP.";
         }
       }
       list total-attack-traffic {
         key "unit";
         description
           "Суммарный трафик атаки от данного источника.";
         uses traffic-unit-all;
       }
     }

     grouping top-talker-aggregate {
       description
         "Агрегат основных источников атаки. Обычно служит для 
          включения в запрос на смягчение.";
       list talker {
         key "source-prefix";
         description
           "Основные участники атаки, указанные префиксом IPv4 или IPv6.";
         uses talker;
         container total-attack-connection {
           description
             "Общее число соединений атаки от данного источника.";
           uses connection-all;
         }
       }
     }

     grouping top-talker {
       description
         "Основные источники атаки с деталями по протоколам.";
       list talker {
         key "source-prefix";
         description
           "Основные участники атаки, указанные префиксом IPv4 или IPv6.";
         uses talker;
         list total-attack-connection-protocol {
           key "protocol";
           description
             "Общее число соединений атаки от данного источника.";
           uses connection-protocol-all;
         }
       }
     }

     grouping baseline {
       description
         "Группировка для базового уровня телеметрии.";
       uses data-channel:target;
       leaf-list alias-name {
         type string;
         description
           "Псевдоним ресурса IP (маршрутизатор, хост, объект (IoT),
            сервер и т. п.";
       }
       list total-traffic-normal {
         key "unit";
         description
           "Общий уровень нормального трафика.";
         uses traffic-unit;
       }
       list total-traffic-normal-per-protocol {
         key "unit protocol";
         description
           "Общий уровень нормального трафика на протокол.";
         uses traffic-unit-protocol;
       }
       list total-traffic-normal-per-port {
         key "unit port";
         description
           "Общий уровень нормального трафика на номер порта.";
         uses traffic-unit-port;
       }
       list total-connection-capacity {
         key "protocol";
         description
           "Общая пропускная способность соединений.";
         uses total-connection-capacity-protocol;
       }
       list total-connection-capacity-per-port {
         key "protocol port";
         description
           "Общая пропускная способность соединений с портом.";
         leaf port {
           type inet:port-number;
           description
             "Номер целевого порта.";
         }
         uses total-connection-capacity-protocol;
       }
     }

     grouping pre-or-ongoing-mitigation {
       description
         "Группировка для данных телеметрии.";
       list total-traffic {
         key "unit";
         description
           "Общий трафик.";
         uses traffic-unit-all;
       }
       list total-traffic-protocol {
         key "unit protocol";
         description
           "Общий трафик для протокола.";
         uses traffic-unit-protocol-all;
       }
       list total-traffic-port {
         key "unit port";
         description
           "Общий трафик для номера порта.";
         uses traffic-unit-port-all;
       }
       list total-attack-traffic {
         key "unit";
         description
           "Общий трафик атаки.";
         uses traffic-unit-all;
       }
       list total-attack-traffic-protocol {
         key "unit protocol";
         description
           "Общий трафик атаки для протокола.";
         uses traffic-unit-protocol-all;
       }
       list total-attack-traffic-port {
         key "unit port";
         description
           "Общий трафик атаки для номера порта.";
         uses traffic-unit-port-all;
       }
       list total-attack-connection-protocol {
         key "protocol";
         description
           "Общее число соединений атаки.";
         uses connection-protocol-all;
       }
       list total-attack-connection-port {
         key "protocol port";
         description
           "Общее число соединений атаки для целевого порта.";
         uses connection-protocol-port-all;
       }
       list attack-detail {
         key "vendor-id attack-id";
         description
           "Детали атаки.";
         uses attack-detail;
         container top-talker {
           description
             "Список источников атаки.";
           uses top-talker;
         }
       }
     }

     sx:augment-structure "/dots-signal:dots-signal"
                        + "/dots-signal:message-type"
                        + "/dots-signal:mitigation-scope"
                        + "/dots-signal:scope" {
       description
         "Расширяет смягчение атаки данными обновления телеметрии.";
       choice direction {
         description
           "Направление связи, в котором могут включаться узлы данных.";
         case server-to-client-only {
           description
             "Эти узлы данных появляются лишь в сообщениях смягчения,
              передаваемых от сервера клиенту.";
           list total-traffic {
             key "unit";
             description
               "Общий трафик.";
             uses traffic-unit-all;
           }
           container total-attack-connection {
             description
               "Общее число соединений атаки.";
             uses connection-all;
           }
         }
       }
       list total-attack-traffic {
         key "unit";
         description
               "Общий трафик атаки.";
         uses traffic-unit-all;
       }
       list attack-detail {
         key "vendor-id attack-id";
         description
           "Детали атаки.";
         uses attack-detail;
         container top-talker {
           description
             "Основные источники атаки.";
           uses top-talker-aggregate;
         }
       }
     }
     sx:structure dots-telemetry {
       description
         "Основная структура для сообщений телеметрии DOTS.";
       choice telemetry-message-type {
         description
           "Может быть telemetry-setup или данными телеметрии.";
         case telemetry-setup {
           description
             "Указывает сообщение об установке телеметрии.";
           choice direction {
             description
               "Направление связи, в котором могут включаться узлы данных.";
             case server-to-client-only {
               description
                "Эти узлы данных появляются лишь в сообщениях телеметрии,
                 передаваемых от сервера клиенту.";
               container max-config-values {
                 description
                   "Максимально допустимые значения конфигурации.";
                 uses telemetry-parameters;
                 leaf server-originated-telemetry {
                   type boolean;
                   default "false";
                   description
                     "Указывает, можно ли задать серверу DOTS передачу
                      телеметрии pre-or-ongoing-mitigation. Значение false
                      или отсутствие узла данных указывает, что сервер не
                      поддерживает такую возможность.";
                 }
                 leaf telemetry-notify-interval {
                   type uint16 {
                     range "1 .. 3600";
                   }
                   units "seconds";
                   must '. >= ../../min-config-values'
                      + '/telemetry-notify-interval' {
                     error-message
                       "Значение должно быть не меньше telemetry-notify-
                        interval в атрибуте min-config-values.";
                   }
                   description
                     "Минимальное число секунд между последовательными
                      уведомлениями телеметрии.";
                 }
               }
               container min-config-values {
                 description
                   "Минимально допустимые значения конфигурации .";
                 uses telemetry-parameters;
                 leaf telemetry-notify-interval {
                   type uint16 {
                     range "1 .. 3600";
                   }
                   units "seconds";
                   description
                     "Минимальное число секунд между последовательными
                      уведомлениями телеметрии.";
                 }
               }
               container supported-unit-classes {
                 description
                   "Поддерживаемые классы единиц измерения и принятый
                    по умолчанию статус активации.";
                 uses unit-config;
               }
               leaf-list supported-query-type {
                 type query-type;
                 description
                   "Типы поддерживаемых сервером запросов. Если сервер не
                    анонсирует поддерживаемые типы, клиент не сможет
                    использовать какие-либо значения query-type для снижения
                    объёма данных от сервера.";
               }
             }
           }
           list telemetry {
             description
               "Данные телеметрии для клиента DOTS. Ключами этого списка
                служат cuid и tsid, но они не представлены здесь, поскольку
                обязательны в запросах Uri-Paths. Отсутствие ключей
                согласуется с RFC 8791.";
             reference
               "RFC 8791: YANG Data Structure Extensions";
             choice direction {
               description
                 "Направление связи, в котором можно включать узлы данных.";
               case server-to-client-only {
                 description
                   "Эти узлы данных появляются лишь в сообщениях телеметрии,
                    передаваемых от сервера клиенту.";
                 leaf tsid {
                   type uint32;
                   description
                     "Заданный клиентом идентификатор для данных установки 
                      телеметрии DOTS.";
                 }
               }
             }
             choice setup-type {
               description
                 "Может указывать конфигурацию смягчения, ёмкость трубы,
                  или базовый уровень.";
               case telemetry-config {
                 description
                   "Служит для установки параметров телеметрии, таких как
                    значения low-, mid-, high-percentile.";
                 container current-config {
                   description
                     "Текущие значения конфигурации телеметрии.";
                   uses telemetry-parameters;
                   uses unit-config;
                   leaf server-originated-telemetry {
                     type boolean;
                     description
                       "Применяется клиентом DOTS для управления 
                        возможностью запросов телеметрии 
                        pre-or-ongoing-mitigation у сервера.";
                   }
                   leaf telemetry-notify-interval {
                     type uint16 {
                       range "1 .. 3600";
                     }
                     units "seconds";
                     description
                       "Минимальное число секунд между последовательными
                        уведомлениями телеметрии.";
                   }
                 }
               }
               case pipe {
                 description
                   "Общая емкость трубы клиентского домена DOTS.";
                 list total-pipe-capacity {
                   key "link-id unit";
                   description
                     "Общая емкость трубы клиентского домена DOTS.";
                   leaf link-id {
                     type nt:link-id;
                     description
                       "Идентификатор внешнего канала клиентского домена 
                        DOTS.";
                   }
                   leaf capacity {
                     type uint64;
                     mandatory true;
                     description
                       "Ёмкость трубы. Обязательный атрибут при наличии 
                        total-pipe-capacity в сообщении.";
                   }
                   leaf unit {
                     type unit;
                     description
                       "Трафик можно измерять в пакетах (pps), битах (bps)
                         и/или байтах (Bps) за секунду.

                        Для данного класса единиц агенты DOTS автоматически
                        приводят значения к соответствующим единицам
                        (например, megabit-ps, kilobit-ps).";
                   }
                 }
               }
               case baseline {
                 description
                   "Данные о базовом уровне трафика клиентского домена 
                    DOTS.";
                 list baseline {
                   key "id";
                   description
                     "Данные о базовом уровне трафика клиентского домена 
                      DOTS.";
                   leaf id {
                     type uint32;
                     must '. >= 1';
                     description
                       "Идентификатор, однозначно указывающий запись
                        базового уровня, переданную клиентом DOTS.";
                   }
                   uses baseline;
                 }
               }
             }
           }
         }
         case telemetry {
           description
             "Данные телеметрии.";
           list pre-or-ongoing-mitigation {
             description
               "Телеметрия Pre-or-ongoing-mitigation по клиенту DOTS. 
                Ключами этого списка служат cuid и tsid, но они не 
                представлены здесь, поскольку обязательны в запросах 
                Uri-Paths. Отсутствие ключей согласуется с RFC 8791.";
             reference
               "RFC 8791: YANG Data Structure Extensions";
             choice direction {
               description
                 "Направление, в котором могут включаться узлы данных.";
               case server-to-client-only {
                 description
                   "Эти узлы данных появляются лишь в сообщениях телеметрии,
                    передаваемых от сервера клиенту.";
                 leaf tmid {
                   type uint32;
                   description
                     "Заданный клиентом идентификатор данных телеметрии 
                      DOTS.";
                 }
               }
             }
             container target {
               description
                 "Указывает цель. В определении цели должен присутствовать
                  хотя бы один из атрибутов target-prefix, target-fqdn,
                  target-uri, alias-name, mid-list.";
               uses data-channel:target;
               leaf-list alias-name {
                 type string;
                 description
                   "Псевдоним ресурса.";
               }
               leaf-list mid-list {
                 type uint32;
                 description
                   "Ссылка на список связанных запросов смягчения.";
                 reference
                   "RFC 9132: Distributed Denial-of-Service Open
                              Threat Signaling (DOTS) Signal Channel
                              Specification, Section 4.4.1";
               }
             }
             uses pre-or-ongoing-mitigation;
           }
         }
       }
     }
   }
   <CODE ENDS>

11.2. Модуль YANG для деталей отображения атак от производителя

   <CODE BEGINS> file "ietf-dots-mapping@2022-06-20.yang"
   module ietf-dots-mapping {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
     prefix dots-mapping;

     import ietf-dots-data-channel {
       prefix data-channel;
       reference
         "RFC 8783: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Data Channel Specification";
     }

     organization
       "IETF DDoS Open Threat Signaling (DOTS) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dots/> 
        WG List:  <mailto:dots@ietf.org> 

        Author:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 

        Author:   Jon Shallow
                  <mailto:supjps-ietf@jpshallow.com>"; 
     description
       "Этот модуль содержит определения YANG для совместного использования
        деталей отображения атак DDoS клиентами и серверами DOTS, 
        передаваемых по сигнальному каналу DOTS.

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

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

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

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9244: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Telemetry";
     }

     feature dots-telemetry {
       description
         "Показывает возможность совместного использования 
          телеметрии DOTS клиентами и серверами.";
     }

     grouping attack-mapping {
       description
         "Набор сведений, используемых для совместного с партнёром 
          использования данных отображения атак от производителя.";
       list vendor {
         key "vendor-id";
         description
           "Сведения отображения атак от производителя, относящиеся
            к клиенту/серверу.";
         leaf vendor-id {
           type uint32;
           description
             "Идентификатор производителя средств защиты из реестра 
              IANA Private Enterprise Numbers.";
           reference
             "IANA: Private Enterprise Numbers
              (https://www.iana.org/assignments/enterprise-numbers/)"; 
         }
         leaf vendor-name {
           type string;
           description
             "Имя производителя (например, компания A).";
         }
         leaf description-lang {
           type string {
             pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
                   + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
                   + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
                   + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
                   + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
                   + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
                   + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
                   + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
                   + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
                   + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
                   + '|[Ii]-[Hh][Aa][Kk]|'
                   + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
                   + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
                   + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
                   + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
                   + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
                   + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
                   + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
                   + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
                   + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
                   + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
                   + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
                   + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
                   + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
                   + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
             }
           default "en-US";
           description
             "Тег языка, применяемого в attack-description.";
           reference
             "RFC 5646: Tags for Identifying Languages, Section 2.1";
         }
         leaf last-updated {
           type uint64;
           mandatory true;
           description
             "Время обновления таблицы отображений в секундах с
              1970-01-01T00:00:00Z.";
         }
         list attack-mapping {
           key "attack-id";
           description
             "Attack mapping details.";
           leaf attack-id {
             type uint32;
             description
               "Unique identifier assigned by the vendor for the
                attack.";
           }
           leaf attack-description {
             type string;
             mandatory true;
             description
               "Текстовое описание атаки. Методы обработки естественных
                языков (например, встраивание слов) могут быть полезны
                для сопоставляния описаний атак с их типами.";
           }
         }
       }
     }

     augment "/data-channel:dots-data/data-channel:dots-client" {
       if-feature "dots-telemetry";
       description
         "Дополняет канал данных клиентской таблицей отображений атак от 
          производителя.";
       container vendor-mapping {
         description
           "Применяется клиентом DOTS для использования его сведений 
            об отображении атак от производителя совместно с сервером.";
         uses attack-mapping;
       }
     }

     augment "/data-channel:dots-data/data-channel:capabilities" {
       if-feature "dots-telemetry";
       description
         "Дополняет возможности сервера DOTS параметром для индикации
          возможности совместного использования деталей отображения атак.";
       leaf vendor-mapping-enabled {
         type boolean;
         config false;
         description
           "Указывает, что сервер DOTS поддерживает использование деталей
            отображения атак от производителя совместно с клиентом.";
       }
     }

     augment "/data-channel:dots-data" {
       if-feature "dots-telemetry";
       description
         "Дополняет канал данных таблицей отображений атак от производителя
          от сервера DOTS.";
       container vendor-mapping {
         config false;
         description
           "Список деталей отображения атак от производителя, которые будут
            использоваться совместно с клиентами DOTS по их запросам.";
         uses attack-mapping;
       }
     }
   }
   <CODE ENDS>

12. Сопоставление параметров YANG/JSON и CBOR

Все параметры телеметрии DOTS в полях данных сигнального канала DOTS должны отображаться на типы CBOR, как показано в таблице 3.

Примечание. Разработчики должны убедиться, что выход отображений, обеспечиваемых схемами преобразования YANG в CBOR, соответствует таблице 3.

Таблица 3. Сопоставление параметров JSON/YANG и CBOR.

 

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

Тип YANG

Ключ CBOR

Старший тип и данные CBOR

Тип JSON

tsid

uint32

128

0 unsigned

Number

telemetry

list

129

4 array

Array

low-percentile

decimal64

130

6 tag 4 [-2, integer]

String

mid-percentile

decimal64

131

6 tag 4 [-2, integer]

String

high-percentile

decimal64

132

6 tag 4 [-2, integer]

String

unit-config

list

133

4 array

Array

unit

enumeration

134

0 unsigned

String

unit-status

boolean

135

7 bits 20

False

7 bits 21

True

total-pipe-capacity

list

136

4 array

Array

link-id

string

137

3 text string

String

pre-or-ongoing-mitigation

list

138

4 array

Array

total-traffic-normal

list

139

4 array

Array

low-percentile-g

yang:gauge64

140

0 unsigned

String

mid-percentile-g

yang:gauge64

141

0 unsigned

String

high-percentile-g

yang:gauge64

142

0 unsigned

String

peak-g

yang:gauge64

143

0 unsigned

String

total-attack-traffic

list

144

4 array

Array

total-traffic

list

145

4 array

Array

total-connection-capacity

list

146

4 array

Array

connection

uint64

147

0 unsigned

String

connection-client

uint64

148

0 unsigned

String

embryonic

uint64

149

0 unsigned

String

embryonic-client

uint64

150

0 unsigned

String

connection-ps

uint64

151

0 unsigned

String

connection-client-ps

uint64

152

0 unsigned

String

request-ps

uint64

153

0 unsigned

String

request-client-ps

uint64

154

0 unsigned

String

partial-request-max

uint64

155

0 unsigned

String

partial-request-client-max

uint64

156

0 unsigned

String

total-attack-connection

container

157

5 map

Object

connection-c

container

158

5 map

Object

embryonic-c

container

159

5 map

Object

connection-ps-c

container

160

5 map

Object

request-ps-c

container

161

5 map

Object

attack-detail

list

162

4 array

Array

id

uint32

163

0 unsigned

Number

attack-id

uint32

164

0 unsigned

Number

attack-description

string

165

3 text string

String

attack-severity

enumeration

166

0 unsigned

String

start-time

uint64

167

0 unsigned

String

end-time

uint64

168

0 unsigned

String

source-count

container

169

5 map

Object

top-talker

container

170

5 map

Object

spoofed-status

boolean

171

7 bits 20

False

7 bits 21

True

partial-request-c

container

172

5 map

Object

total-attack-connection-protocol

list

173

4 array

Array

baseline

list

174

4 array

Array

current-config

container

175

5 map

Object

max-config-values

container

176

5 map

Object

min-config-values

container

177

5 map

Object

supported-unit-classes

container

178

5 map

Object

server-originated-telemetry

boolean

179

7 bits 20

False

7 bits 21

True

telemetry-notify-interval

uint16

180

0 unsigned

Number

tmid

uint32

181

0 unsigned

Number

measurement-interval

enumeration

182

0 unsigned

String

measurement-sample

enumeration

183

0 unsigned

String

talker

list

184

4 array

Array

source-prefix

inet:ip-prefix

185

3 text string

String

mid-list

leaf-list

186

4 array

Array

uint32

0 unsigned

Number

source-port-range

list

187

4 array

Array

source-icmp-type-range

list

188

4 array

Array

target

container

189

5 map

Object

capacity

uint64

190

0 unsigned

String

protocol

uint8

191

0 unsigned

Number

total-traffic-normal-per-protocol

list

192

4 array

Array

total-traffic-normal-per-port

list

193

4 array

Array

total-connection-capacity-per-port

list

194

4 array

Array

total-traffic-protocol

list

195

4 array

Array

total-traffic-port

list

196

4 array

Array

total-attack-traffic-protocol

list

197

4 array

Array

total-attack-traffic-port

list

198

4 array

Array

total-attack-connection-port

list

199

4 array

Array

port

inet:port-number

200

0 unsigned

Number

supported-query-type

leaf-list

201

4 array

Array

0 unsigned

String

vendor-id

uint32

202

0 unsigned

Number

ietf-dots-telemetry:telemetry-setup

container

203

5 map

Object

ietf-dots-telemetry:total-traffic

list

204

4 array

Array

ietf-dots-telemetry:total-attack-traffic

list

205

4 array

Array

ietf-dots-telemetry:total-attack-connection

container

206

5 map

Object

ietf-dots-telemetry:attack-detail

list

207

4 array

Array

ietf-dots-telemetry:telemetry

container

208

5 map

Object

current-g

yang:gauge64

209

0 unsigned

String

description-lang

string

210

3 text string

String

lower-type

uint8

32771

0 unsigned

Number

upper-type

uint8

32772

0 unsigned

Number

 

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

13.1. Значения ключей CBOR

Эта спецификация регистрирует приведенные в таблице 4 необязательные для понимания параметры в реестре IANA «DOTS Signal Channel CBOR Key Values» [Key-Map].

Таблица 4. Зарегистрированные ключи CBOR для сигнального канала DOTS.

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

Значение ключа CBOR

Старший тип CBOR

Контролёр изменений

Документ

tsid

128

0

IESG

RFC 9244

telemetry

129

4

IESG

RFC 9244

low-percentile

130

6tag4

IESG

RFC 9244

mid-percentile

131

6tag4

IESG

RFC 9244

high-percentile

132

6tag4

IESG

RFC 9244

unit-config

133

4

IESG

RFC 9244

unit

134

0

IESG

RFC 9244

unit-status

135

7

IESG

RFC 9244

total-pipe-capacity

136

4

IESG

RFC 9244

link-id

137

3

IESG

RFC 9244

pre-or-ongoing-mitigation

138

4

IESG

RFC 9244

total-traffic-normal

139

4

IESG

RFC 9244

low-percentile-g

140

0

IESG

RFC 9244

mid-percentile-g

141

0

IESG

RFC 9244

high-percentile-g

142

0

IESG

RFC 9244

peak-g

143

0

IESG

RFC 9244

total-attack-traffic

144

4

IESG

RFC 9244

total-traffic

145

4

IESG

RFC 9244

total-connection-capacity

146

4

IESG

RFC 9244

connection

147

0

IESG

RFC 9244

connection-client

148

0

IESG

RFC 9244

embryonic

149

0

IESG

RFC 9244

embryonic-client

150

0

IESG

RFC 9244

connection-ps

151

0

IESG

RFC 9244

connection-client-ps

152

0

IESG

RFC 9244

request-ps

153

0

IESG

RFC 9244

request-client-ps

154

0

IESG

RFC 9244

partial-request-max

155

0

IESG

RFC 9244

partial-request-client-max

156

0

IESG

RFC 9244

total-attack-connection

157

5

IESG

RFC 9244

connection-c

158

5

IESG

RFC 9244

embryonic-c

159

5

IESG

RFC 9244

connection-ps-c

160

5

IESG

RFC 9244

request-ps-c

161

5

IESG

RFC 9244

attack-detail

162

4

IESG

RFC 9244

id

163

0

IESG

RFC 9244

attack-id

164

0

IESG

RFC 9244

attack-description

165

3

IESG

RFC 9244

attack-severity

166

0

IESG

RFC 9244

start-time

167

0

IESG

RFC 9244

end-time

168

0

IESG

RFC 9244

source-count

169

5

IESG

RFC 9244

top-talker

170

5

IESG

RFC 9244

spoofed-status

171

7

IESG

RFC 9244

partial-request-c

172

5

IESG

RFC 9244

total-attack-connection-protocol

173

4

IESG

RFC 9244

baseline

174

4

IESG

RFC 9244

current-config

175

5

IESG

RFC 9244

max-config-values

176

5

IESG

RFC 9244

min-config-values

177

5

IESG

RFC 9244

supported-unit-classes

178

5

IESG

RFC 9244

server-originated-telemetry

179

7

IESG

RFC 9244

telemetry-notify-interval

180

0

IESG

RFC 9244

tmid

181

0

IESG

RFC 9244

measurement-interval

182

0

IESG

RFC 9244

measurement-sample

183

0

IESG

RFC 9244

talker

184

4

IESG

RFC 9244

source-prefix

185

3

IESG

RFC 9244

mid-list

186

4

IESG

RFC 9244

source-port-range

187

4

IESG

RFC 9244

source-icmp-type-range

188

4

IESG

RFC 9244

target

189

5

IESG

RFC 9244

capacity

190

0

IESG

RFC 9244

protocol

191

0

IESG

RFC 9244

total-traffic-normal-per-protocol

192

4

IESG

RFC 9244

total-traffic-normal-per-port

193

4

IESG

RFC 9244

Total-connection- capacity-per-port

194

4

IESG

RFC 9244

total-traffic-protocol

195

4

IESG

RFC 9244

total-traffic-port

196

4

IESG

RFC 9244

total-attack-traffic-protocol

197

4

IESG

RFC 9244

total-attack-traffic-port

198

4

IESG

RFC 9244

total-attack-connection-port

199

4

IESG

RFC 9244

port

200

0

IESG

RFC 9244

supported-query-type

201

4

IESG

RFC 9244

vendor-id

202

0

IESG

RFC 9244

ietf-dots-telemetry:telemetry-setup

203

5

IESG

RFC 9244

ietf-dots-telemetry:total-traffic

204

4

IESG

RFC 9244

ietf-dots-telemetry:total-attack-traffic

205

4

IESG

RFC 9244

ietf-dots-telemetry:total-attack-connection

206

5

IESG

RFC 9244

ietf-dots-telemetry:attack-detail

207

4

IESG

RFC 9244

ietf-dots-telemetry:telemetry

208

5

IESG

RFC 9244

current-g

209

0

IESG

RFC 9244

description-lang

210

3

IESG

RFC 9244

13.2. Код причины конфликтов в сигнальном канале DOTS

В соответствии с этим документом агетство IANA выделило новый код в реестре DOTS Signal Channel Conflict Cause Codes [Cause].

Таблица 5. Зарегистрированные коды причин конфликтов в сигнальном канале DOTS.

Код

Метка

Описание

Документ

5

overlapping-pipes

Перекрытие области действия трубы

RFC 9244

13.3. Регистрация DOTS Telemetry URI и модулей YANG

В соответствии с этим документом агетство IANA зарегистрировало приведённые ниже UR в субреестре ns реестра IETF XML Registry [RFC3688]:

   URI:  urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:ietf-dots-mapping
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   Per this document, IANA has registered the following YANG modules in
   the "YANG Module Names" subregistry [RFC6020] within the "YANG
   Parameters" registry.

   Name:  ietf-dots-telemetry
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
   Maintained by IANA:  N
   Prefix:  dots-telemetry
   Reference:  RFC 9244

   Name:  ietf-dots-mapping
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-dots-mapping
   Maintained by IANA:  N
   Prefix:  dots-mapping
   Reference:  RFC 9244

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

14.1. Телеметрия в сигнальном канале DOTS

Вопросы безопасности для сигнального канала DOTS рассмотрены в разделе 11 [RFC9132], а ниже обсуждаются вопросы, связанные с безопасностью определённых в документе расширений сигнального канала DOTS.

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

Клиенты DOTS обычно считаются доверенными устройствами в клиентском домене DOTS. Клиенты могут размещаться вместе с устройствами защиты сети (например, межсетевыми экранами) и взломанная служба защиты может нанести сети гораздо больший вред, незели просто клиентские компоненты DOTS. Это допущение отличается от распространенного мнения о том, что устройства не являются доверенными (это часто называют моделью нулевого доверия — zero-trust model). Взломанный клиент DOTS может передавать фальшивые данные телеметрии серверу DOTS, чтобы ввести тот в заблуждение. Такие атаки можно предотвратить, отслеживая и проверяя клиентов DOTS для обнаружения недопустимого поведения и его предотвращения и разрешая передачу данных телеметрии для конкретных ресурсов лишь уполномоченным клиентам DOTS (например, серверу приложений разрешается обмен телеметрией DOTS для его адреса IP, а системе смягчения DDoS-атак разрешено обмениваться телеметрией DOTS для любого целевого ресурса в сети). Напомним, что имеется вариант работы со взломанными клиентами DOTS, описанный в разделе 11 [RFC9132].

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

  • Скорость зондирования (probing rate, как определено в параграфе 4.5 [RFC9132]) может служить ограничением скорости передачи данных серверу DOTS.

  • Телеметрия DOTS с ограничением скорости, включая пакеты с новыми значениями tmid от одного клиента DOTS, защищает от DoS-атак, которые могут приводит к изменению tmid для истощения ресурсов сервера DOTS. Сервер DOTS может также установить квоту и ограничение по времени для числа активных элементов телеметрии до и во время смягчения атак (определяется по tmid) для клиента DOTS.

Отметим также, что можно применять интервал между уведомлениями телеметрии для ограничения скорости уведомлений pre-or-ongoing-mitigation, получаемых клиентским доменом DOTS.

14.2. Отображение атак от производителя

Вопросы безопасности для протокола канала данных DOTS рассмотрены в разделе 10 [RFC8783], а ниже приведены соображения, связанные с определённым в документе расширением канала данных DOTS.

Все узлы данных в модуле YANG, заданном в параграфе 11.2, которые можно создавать, изменять, удалять (т. е. узлы с config true, что принято по умолчанию) считяются чувствительными к угрозам. Операции записи в такие узлы без подобающей защиты могут оказывать негативное влияние на работу сети. Рекомендуется применять подходящие меры защиты, предотвращающие вызов примитивов канала данных DOTS недоверенными пользователями, как описано в [RFC8783]. Тем не менее, злоумышленник с доступом к клиенту DOTS технически способен организовать разные атаки, атке как передача серверу недействительных сведений о деталях отображения атак (/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping), которые могут ввести сервер в заблуждение.

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

  • /data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping могут использоваться для выяснения технологии защиты от атак DDoS, реализованной в клиентском домене DOTS.

  • /data-channel:dots-data/dots-telemetry:vendor-mapping могут использоваться взломанными клиентами DOTS для утечки сведений о возможностях обнаружения атак с сервера DOTS. Это является вариантом атак со стороны скомпрометрированных клиентов DOTS, упомянутых в параграфе 14.1.

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

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

[Private-Enterprise-Numbers] IANA, «Private Enterprise Numbers», <https://www.iana.org/assignments/enterprise-numbers/>.

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

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

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.

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

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

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, «The Constrained Application Protocol (CoAP)», RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7641] Hartke, K., «Observing Resources in the Constrained Application Protocol (CoAP)», RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC7959] Bormann, C. and Z. Shelby, Ed., «Block-Wise Transfers in the Constrained Application Protocol (CoAP)», RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.

[RFC7970] Danyliw, R., «The Incident Object Description Exchange Format Version 2», RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

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

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, «A YANG Data Model for Network Topologies», RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., «Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification», RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.

[RFC8791] Bierman, A., Björklund, M., and K. Watsen, «YANG Data Structure Extensions», RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.

[RFC8949] Bormann, C. and P. Hoffman, «Concise Binary Object Representation (CBOR)», STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification», RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/info/rfc9132>.

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

[Cause] IANA, «DOTS Signal Channel Conflict Cause Codes», <https://www.iana.org/assignments/dots/>.

[DOTS-Multihoming] Boucadair, M., Reddy.K, T., and W. Pan, «Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)», Work in Progress, Internet-Draft, draft-ietf-dots-multihoming-13, 26 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-13>.

[DOTS-Robust-Blocks] Boucadair, M. and J. Shallow, «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission», Work in Progress, Internet-Draft, draft-ietf-dots-robust-blocks-03, 11 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-robust-blocks-03>.

[DOTS-Telemetry-Specs] Doron, E., Reddy, T., Andreasen, F., Xia, L., and K. Nishizuka, «Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Specifications», Work in Progress, Internet-Draft, draft-doron-dots-telemetry-00, 30 October 2016, <https://datatracker.ietf.org/doc/html/draft-doron-dots-telemetry-00>.

[Key-Map] IANA, «DOTS Signal Channel CBOR Key Values», <https://www.iana.org/assignments/dots/>.

[PYANG] «pyang», commit dad5c68, April 2022, <https://github.com/mbj4668/pyang>.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, «Internet Denial-of-Service Considerations», RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.

[RFC5612] Eronen, P. and D. Harrington, «Enterprise Number for Documentation Use», RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/info/rfc5612>.

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

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, «YANG Library», RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, «DDoS Open Threat Signaling (DOTS) Requirements», RFC 8612, DOI 10.17487/RFC8612, May 2019, <https://www.rfc-editor.org/info/rfc8612>.

[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, «DDoS Open Threat Signaling (DOTS) Architecture», RFC 8811, DOI 10.17487/RFC8811, August 2020, <https://www.rfc-editor.org/info/rfc8811>.

[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, «Use Cases for DDoS Open Threat Signaling», RFC 8903, DOI 10.17487/RFC8903, May 2021, <https://www.rfc-editor.org/info/rfc8903>.

[RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, «Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel», RFC 9133, DOI 10.17487/RFC9133, September 2021, <https://www.rfc-editor.org/info/rfc9133>.

[RFC9177] Boucadair, M. and J. Shallow, «Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission», RFC 9177, DOI 10.17487/RFC9177, March 2022, <https://www.rfc-editor.org/info/rfc9177>.

[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, «Stream Control Transmission Protocol», RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.

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

Авторы хотели бы поблагодарить Flemming Andreasen, Liang Xia и Kaname Nishizuka, соавторов [DOTS-Telemetry-Specs], а также всех, кто внёс вклад в этот документ.

Спасибо Kaname Nishizuka, Yuhei Hayashi и Tom Petch за их замечания и рецензии.

Особая благодарность Jon Shallow и Kaname Nishizuka за из работу по реализации и взаимодуйствию.

Большое спасибо Jan Lindblad за обзор yangdoctors, Nagendra Nainar за обзор opsdir, James Gruessing за обзор artart, Michael Scharf за обзор tsv-art, Ted Lemon за обзор int-dir и Robert Sparks за обзор gen-art.

Спасибо Benjamin Kaduk за подробную рецензию AD.

Спасибо Roman Danyliw, Éric Vyncke, Francesca Palombini, Warren Kumari, Erik Kline, Lars Eggert, Robert Wilton за рецензии IESG.

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

Li Su
CMCC
Email: suli@chinamobile.com
 
Pan Wei
Huawei
Email: william.panwei@huawei.com

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

Mohamed Boucadair (editor)
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
 
Tirumaleswar Reddy.K (editor)
Akamai
Embassy Golf Link Business Park
Bangalore 560071
Karnataka
India
Email: kondtir@gmail.com
 
Ehud Doron
Radware Ltd.
Raoul Wallenberg Street
Tel-Aviv 69710
Israel
Email: ehudd@radware.com
 
Meiling Chen
CMCC
32 Xuanwumen West Street
Beijing
100053
China
Email: chenmeiling@chinamobile.com
 
Jon Shallow
United Kingdom
Email: supjps-ietf@jpshallow.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9232 Network Telemetry Framework

Internet Engineering Task Force (IETF)                           H. Song
Request for Comments: 9232                                     Futurewei
Category: Informational                                           F. Qin
ISSN: 2070-1721                                             China Mobile
                                                       P. Martinez-Julia
                                                                    NICT
                                                            L. Ciavaglia
                                                          Rakuten Mobile
                                                                 A. Wang
                                                           China Telecom
                                                                May 2022

Network Telemetry Framework

Модель сетевой телеметрии

PDF

Аннотация

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

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

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

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

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

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

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

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

  1. помогать в получении данных о текущем состоянии сети, включая плоскости устройств, пересылки, управления и администрирования (management);

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

  3. обрабатываться с разными целями от обеспечения сервиса до безопасности сети с использованием широкого спектра методов анализа.

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

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

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

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

1.1. Заявление о применимости

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

1.2. Глоссарий

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

AI (Artificial Intelligence) — искусственный интеллект

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

AM (Alternate Marking) — чередующаяся маркировка

Метод измерения производительности потоков, описанный в [RFC8321].

BMP (BGP Monitoring Protocol) — протокол мониторинга BGP

Описан в [RFC7854].

DPI (Deep Packet Inspection) — глубокая инспекция пакетов

Методы проверки пакетов за пределами заголовков L3/L4.

GNMI (gRPC Network Management Interface) — интерфейс сетевого управления gRPC

Протокол сетевого управления от OpenConfig Operator Working Group, разработанный в основном Google. Подробности приведены в [gnmi].

GPB (Google Protocol Buffer) — протокольный буфер Google

Расширяемый механизм представления структурированных данных в последовательной форме. Подробности приведены в [gpb].

GRPC (gRPC Remote Procedure Call) — обобщенный вызов удалённых процедур

Модель высокопроизводительных вызовов RPC с открытым исходным кодом, на которой основан интерфейс gNMI. Подробности приведены в [grpc].

IPFIX (IP Flow Information Export Protocol) — протокол экспорта сведений о потоке IP

Описан в [RFC7011].

IOAM

In situ (на месте) OAM [RFC9197]. Метод телеметрии путей в плоскости данных.

JSON (JavaScript Object Notation) — обозначение объектов JavaScript

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

MIB (Management Information Base) — база информации для управления

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

NETCONF (Network Configuration Protocol) — протокол настройки сети

Описан в [RFC6241].

NetFlow

Протокол компании Cisco, служащий для сбора записей о потоках, как указано в [RFC3954].

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

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

NMS (Network Management System) — система управления сетью

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

OAM (Operations, Administration, and Maintenance) — эксплуатация, администрирование, поддержка

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

PBT (Postcard-Based Telemetry)

Метод телеметрии путей в плоскости данных. Один из вариантов описан в [IPPM-IOAM-DIRECT-EXPORT].

RESTCONF

Работающий на основе HTTP протокол, который обеспечивает программный интерфейс для доступа к данным, определенным в YANG, с использованием концепции хранилища, определённой в NETCONF [RFC8040].

SMIv2 (Structure of Management Information Version 2) — структура управляющей информации версии 2

Определяет объекты MIB, как описано в [RFC2578].

SNMP (Simple Network Management Protocol) — простой протокол управления сетью

Версии 1, 2, 3 заданы в [RFC1157], [RFC3416], [RFC3411], соответственно.

XML (Extensible Markup Language) — расширяемый язык разметки

Язык разметки для представления данных в человекочитаемом и машинном формате, как указано W3C [W3C.REC-xml-20081126].

YANG

Язык моделирования для определения данных, передаваемых протоколами управления сетью, такими как NETCONF и RESTCONF. Определение YANG дано в [RFC6020] и [RFC7950].

YANG ECA

Модель YANG для правил событие-условие-действие (Event-Condition-Action) [NETMOD-ECA-POLICY].

YANG-Push

Механизм, позволяющий приложениям подписчиков запросить поток обновлений из хранилища YANG на сетевом устройстве. Подробности приведены в [RFC8639] и [RFC8641].

2. Основы

Термин «большие данные» (big data) служит для описания чрезвычайно крупных наборов данных, которые можно анализировать вычислительными средствами для выявления закономерностей, тенденций и связей. Сети несомненно является источником больших данных из-за своих масштабов и объёма пересылаемого трафика. Когда оконечные точки сети не представляют индивидуальных пользователей, например, в контексте предприятия, ЦОД или инфраструктуры), сетевые операции зачастую могут выигрывать от крупномасштабного сбора данных без нарушения приватности пользователей.

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

Вполне возможно, что самоуправляемые сети [RFC7575] являются следующим логическим шагом развития сетей вслед за программно управляемыми сетями (Software-Defined Networking или SDN), направленным на сокращение (или даже исключение) человеческого труда, более эффективное использование ресурсов сетей и предоставления более качественных услуг в соответствии с потребностями клиентов. Рабочая группа IETF ANIMA занимается разработкой и поддержкой протоколов и процедур для автоматизированного управления сетями и контроля профессионально управляемых сетей. Родственный подход сетей на основе намерений (Intent-Based Networking или IBN) [NMRG-IBN-CONCEPTS-DEFINITIONS] требует видимости сетей и данных телеметрии для обеспечения должного поведения сетей.

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

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

2.1. Охват данными телеметрии

Любая информация, которую можно извлечь из сети (включая плоскости данных, управления и администрирования) и использовать для обеспечения видимости или в качестве основы для действий, считается данными телеметрии. Это включает статистику, записи событий и системных журналов (log), снимки состояния, данные конфигурации и т. п. Телеметрия также включает выходные данные любых активных или пассивных измерений [RFC7799]. В некоторых случаях «сырые» (raw) данные обрабатываются в сети до их отправки потребителю. Обработанные данные также относятся к телеметрии. Значения данных телеметрии меняются. В некоторых случаях, если это приемлемо, лучше отдать предпочтение меньшему объёму высококачественных данных, нежели большому объёму данных низкого качества. Классификация данных телеметрии приведена в разделе 3. Для сохранения приватности конечных пользователей не следует собирать содержимое их пакетов. В частности, объектам данных, генерируемым, экспортируемым и собираемым приложениями сетевой телеметрии, не следует включать какое-либо содержимое из пакетов, связанных с системами конечных пользователей.

2.2. Примеры использования

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

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

  • Соответствие правилам и намерениям. Политика сети представляет собой набор правил, ограничивающих доступ служб к сети в целях дифференциации или принудительно применяющих специальную обработку трафика. Например, цепочка сервисных функций может являться политикой, требующей прохождения отдельных потоков через набор упорядоченных сетевых функций. Намерение, как указано в [NMRG-IBN-CONCEPTS-DEFINITIONS], — это набор операционных целей, которые сети следует поддерживать, и результатов, которые сети следует обеспечивать, заданных декларативно без указания способов достижения или реализации. Намерения требуют сложной трансляции и отображения процессов до применения в сети. Применение политики или намерения требуется непрерывная проверка соответствия и мониторинг, основанные на видимости, обеспечиваемой сетевой телеметрией. Обо всех нарушениях требуется сообщать незамедлительно, т. е. информировать администратора сети о нарушении, что может приводить к изменению применяемой политики или намерений для обеспечения их соблюдения в сети.

  • Соответствие SLA. Соглашение об уровне обслеживания (Service Level Agreement или SLA) является контрактом между сервис-провайдером и клиентом, включающим показатели для оценки сервиса, а также меры и санкции в случае нарушения контракта. Пользователям требуется проверять получение обещанных услуг, а операторам — оценивать способы предоставления услуг в соответствии с SLA в реальном масштабе времени на основе данных сетевой телеметрии, включая данные сетевых измерений.

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

  • Оптимизация сети. Методы краткосрочной и долгосрочной оптимизации сети, включая балансировку нагрузки, организацию трафика (Traffic Engineering или TE) и планирование сети. Операторы стремятся оптимизировать использование своих сетей для ускорения возврата инвестиций (Return on Investment или ROI) и снижения капитальных расходов (Capital Expenditure или CAPEX). Первым шагом является получение в реальном масштабе времени состояния сети до применения правил управления трафиком. В некоторых случаях нужно обнаружение микропиков трафика в течение очень коротких интервалов для тонкого управления трафиком с целью предотвращения перегрузок в сети. Долгосрочное планирование пропускной способности и топологии сети требует анализа фактических данных сетевой телеметрии, собранных в течение длительного времени.

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

2.3. Задачи

Долгое время сетевые операторы полагались на SNMP [RFC3416], командный интерфейс (Command-Line Interface или CLI), Syslog [RFC5424] для мониторинга своей сети. Некоторые методы OAM, как описано в [RFC7276], также применялись для облегчения устранения неполадок в сети. Этих традиционных методов недостаточно для поддержки указанных выше вариантов по целому ряду причин.

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

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

  • Во многих приложениях требуется сопоставлять в масштабе сети данные из разных источников (например, от распределенных сетевых устройств, разных компонент устройства, разных плоскостей сети). Частным решениям зачастую не достает возможностей консолидировать данные из разных источников. Состав полного решения, частично предложенный в архитектуре самоуправления ресурсами (Autonomic Resource Control Architecture — ARCA) [NMRG-ANTICIPATED-ADAPTATION], будет расширен для работы в комплексной модели.

  • Некоторые традиционные методы OAM (например, CLI и Syslog) не имеют формальных моделей данных. Отсутствие структуры данных препятствует автоматизации инструментов и расширяемости. Стандартизованные модели данных важны для поддержки программируемых сетей.

  • Хотя некоторые традиционные методы OAM поддерживают выталкивание (push) данных (например, SNMP Trap [RFC2981][RFC3877], Syslog, sFlow [RFC3176]), передаваемые данные ограничены предопределенным набором предупреждения плоскости администрирования (например, SNMP Trap) или выборкой пользовательских пакетов (например, sFlow). Операторам сетей нужны данные из произвольных источников, с разной детализацией и точностью, что превосходит возможности имеющихся технологий.

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

Эти проблемы решены в новых стандартах и методах (например, IPFIX/Netflow, Packet Sampling (PSAMP), IOAM, YANG-Push), но возникают новые проблемы. Эти стандарты и методы нужно принять и включить в новую модель.

2.4. Сетевая телеметрия

Сетевая телеметрия стала основным техническим термином для обозначения методов сбора и применения сетевых данных. Несколько методов и протоколов сетевой телеметрии (например, IPFIX [RFC7011] и gRPC [grpc]) уже получили широкое распространение. Сетевая телеметрия позволяет разным объектам получать данные от сетевых устройств так, что эти данные можно анализировать и визуализировать для поддержки мониторинга и работы сети. Сетевая телеметрия охватывает традиционные методы OAM и имеет более широкую область действия. Например, ожидается, что сетевая телеметрия сможет обеспечить данные о сети, требуемые для самоуправления и устранения недостатков традиционных методов OAM.

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

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

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

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

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

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

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

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

Идеальное решение для сетевой телеметрии должно также иметь указанные ниже свойства или возможности.

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

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

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

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

  • Сбор данных в основной полосе (In-Band). В дополнение к активному и пассивному сбору данных новый гибридный подход позволяет собирать данные на прямую для любого целевого потока на всем пути его пересылки [OPSAWG-IFIT-FRAMEWORK].

Следует отметить, что для сетевой телеметрии не следует нарушать обычные сетевые операции и следует избегать «эффекта наблюдателя», т. е. не следует изменять поведение сети или влиять на поведение пересылки. Кроме того, большой объем трафика сетевой телеметрии может вызывать перегрузку сети, если не принять подобающих мер изоляции, методов организации трафика или механизмов контроля перегрузок, обеспечивающих отключение трафика телеметрии в случае нехватки сетевых возможностей. Для этого подойдут механизмы, описанные в [RFC8084] и [RFC8085] (Best Current Practice или BCP).

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

2.5. Потребность в модели сетевой телеметрии

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

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

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

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

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

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

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

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

3.1. Модули верхнего уровня

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

+------------------------------+
|                              |
|           Приложения         |<-------+
|     для сетевых операций     |        |
|                              |        |
+------------------------------+        |
        ^          ^       ^            |
        |          |       |            |
        V          V       |            V
+--------------+-----------|---+  +-----------+
|              | Телеметрия|   |  |           |
|              | плоскости |   |  | Телеметрия|
|            <--->         |   |  | внешних   |
|              | управления|   |  | данных и  |
|  Телеметрия  |       ^   V   |  | событий   |
|  плоскости   +-------|-------+  |           |
|  администр.  |       V       |  +-----------+
|              | Телеметрия    |
|              | плоскости     |
|            <--->             |
|              | пересылки     |
|              |               |
+--------------+---------------+

Рисунок 1. Категории модулей сетевой телеметрии.


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

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

Сводка основных различий этих 4 модулей дана в таблице 1 с шести точек зрения:

  • объекты данных;

  • местоположение (цель) экспорта данных;

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

  • представление данных;

  • прикладной протокол телеметрии;

  • метод доставки данных.

Объекты данных являются целями или источниками для каждого модуля. Поскольку источники данных могут меняться, место, куда наиболее удобно экспортировать данные, также может меняться. Например, данные плоскости пересылки в основном поступают как данные, экспортируемые из микросхем пересылки (Application-Specific Integrated Circuit или ASIC), тогда ка данные плоскости управления исходят обычно от протокольных демонов, работающих на процессорах управления (CPU). Для удобства и эффективности предпочтительно экспортировать данные в устройства, расположенные ближе к источнику. Поскольку места для экспорта данных различаются по возможностям, для баланса производительности и расходов применяются разные модели данных, кодирование и методы транспортировки. Например, микросхемы пересылки имеют высокую пропускную способность, но ограниченные возможности обработки комплексных данных и поддержки состояния, а основной процессор управления способен обрабатывать сложные данные и состояния, но имеет ограниченную пропускную способность. В результате протоколы телеметрии для модулей могут различаться. Некоторые методы представлены в соответствующих ячейках таблицы, чтобы подчеркнуть техническое различие модулей. Отметим, что выбранные методы просто отражают фактический уровень и не являются исчерпывающими (например, IPFIX может работать по протоколам TCP и SCTP, но это не рекомендуется для плоскости пересылки). Важно подчеркнуть, что не следует ожидать универсального протокола для всех случаев.

Таблица 1. Сравнение модулей объектов данных.

Модуль

Плоскость администрирования

Плоскость управления

Плоскость пересылки

Внешние данные

Object (объект)

Конфигурация и рабочее состояние

Протокол управления и сигнализации, RIB

QoS пакетов и потоков, статистика трафика, статистика буферов и очередей, FIB, списки управления доступом (ACL)

терминал, социальные данные, окружение

Export Location (цель экспорта)

Основной процессор (CPU) управления

Основной процессор (CPU) управления, CPU линейной платы или микросхема пересылки

Микросхема пересылки или CPU линейной платы; основной процессор маловероятен

Разные

Data Model (модель данных)

YANG, MIB, syslog

YANG, пользовательская

YANG, пользовательская

YANG, пользовательская

Data Encoding (кодирование данных

GPB, JSON, XML

GPB, JSON, XML, текст

текст

GPB, JSON, XML, текст

Application Protocol (прикладные протоколы)

gRPC, NETCONF, RESTCONF

gRPC, NETCONF, IPFIX, отражение трафика

IPFIX, отражение трафика, gRPC, NETFLOW

gRPC

Data Transport (доставка данных)

HTTP(S), TCP

HTTP(S), TCP, UDP

UDP

HTTP(S), TCP, UDP

Отметим, что взаимодействие с приложениями, потребляющими данные сетевой телеметрии, может быть косвенным. Возможна передача некоторых данных внутри устройства. Например, плоскости администрирования могут потребоваться данные от плоскости управления. Некоторые операционные состояния можно вывести лишь из сведений от источников в плоскости данных, примером могут служить состояния интерфейсов и статистика. Для получения данных телеметрии плоскости управления может потребоваться доступ к таблицам пересылки (Forwarding Information Base или FIB) в плоскости данных.

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

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

3.1.1. Телеметрия плоскости администрирования

Телеметрия плоскости администрирования (управления элементами сети) взаимодействует с системой управления сетью (Network Management System или NMS) и обеспечивает такие сведения, как данные производительности, данные сетевых журналов и данные о предупреждениях и дефектах в сети, а также сетевую статистику и данные о состоянии. Плоскость администрирования включает множество протоколов, в том числе классические SNMP и syslog. Независимо от протокола телеметрия плоскости администрирования должна удовлетворять приведённым ниже требованиям.

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

  • Структурированные данные. В сети с самоуправлением машины заменят людей по вопросам осмысления сетевых данных. Языки моделирования данных, такие как YANG, позволяют эффективно описывать структурированные данные, а также нормализовать представление и преобразования данных.

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

  • Предотвращение перегрузок в сети. Приложение должно защищать сеть с помощью механизмов контроля перегрузок или хотя бы «выключателей» (circuit breaker). Некоторые решения даны в [RFC8084] и [RFC8085].

3.1.2. Телеметрия плоскости управления

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

  • Способ сопоставления сквозных индикаторов KPI (End-to-End Key Performance Indicator) с KPI конкретных уровней. Например, пользователи IPTV могут оценить сервис плавностью и чёткостью изображения. В случае необычно низкого UE KPI или прерывания сервиса нетривиальной задачей становится обнаружение проблемы в стеке протоколов (например, транспортный или сетевой уровень) и её границ, конкретного протокола (например, IS-IS или BGP на сетевом уровне) и устройства.

  • Традиционный подход на основе OAM для измерения KPI плоскости управления, включая Ping (L3), Traceroute (L3), Y.1731 [y1731] (L2) и т. д. Общей проблемой, связанной с этими методами является то, что они лишь измеряют KPI, не отражая реального статуса протоколов, что снижает их эффективность и действенность при поиске неполадок в плоскости управления и оптимизации сети.

  • Какие дополнительные исследования нужны для протокола мониторинга BGP (BMP). BMP является примером телеметрии плоскости управления, он применяется сейчас для мониторинга маршрутов BGP и позволяет применять многофункциональные приложения, такие как анализ партнёров BGP, автономных систем (AS), префиксов и безопасности. Однако мониторинг других уровней, протоколов, а также кроссуровневые и кросспротокольные корреляции KPI всё ещё нахотядся в зачаточном состоянии (например, мониторинг IGP не так обширен, как BMP) и требуют дополнительных исследований.

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

3.1.3. Телеметрия плоскости пересылки

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

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

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

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

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

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

  • Требования и решения по предотвращению перегрузок относятся и к телеметрии плоскости пересылки.

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

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

  • Активная, пассивная и гибридная. Этот критерий относится к сквозным измерениям. Активные и пассивные методы (а также гибридные типы) хорошо описаны в [RFC7799]. Пассивные методы включают TCPDUMP, IPFIX [RFC7011], sFlow, отражение трафика. Эти методы обычно охватывают малую область данных. Расход пропускной способности очень высок, что не позволяет расширить охват. Активные методы включают Ping, OWAMP [RFC4656], TWAMP [RFC5357], STAMP [RFC8762], и Cisco SLA Protocol [RFC6812]. Эти интрузивные методы обеспечивают лишь косвенные измерения. Гибридные методы включают IOAM [RFC9197], Alternate Marking (AM) [RFC8321], Multipoint Alternate Marking [RFC8889] и обеспечивают хорошо сбалансированный и более гибкий подход. Однако реализация гибридных методов более сложна.

  • Внутри- или внеполосные данные. Данные телеметрии, передаваемые в пользовательских пакетах до экспорта в коллектор (например, IOAM [RFC9197]), считаюся внутриполосными (in-band). Данные, экспортируемые в коллектор напрямую (например, как описано в Приложении A.3.5), считаются внеполосными (out-of-band). Возможны также гибридные методы, где в пользовательских пакетах передаётся лишь часть данных и инструкции телеметрии (например, AM [RFC8321]).

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

  • Субъект данных. В зависимости от целей телеметрии методы могут основываться на потоках (например, IOAM [RFC9197]), путях (например, Traceroute) и узлах (например, IPFIX [RFC7011]). Объектами данных могут быть пакеты, записи о потоках, измерения, состояния, сигналы.

3.1.4. Телеметрия внешних данных

События за пределами сети также являются важным источником сетевой телеметрии. Сопоставление внутренней телеметрии и внешних событий с требованиями сетевой системы, как описано в [NMRG-ANTICIPATED-ADAPTATION], обеспечивает стратегические и функциональные преимущества для операций управления.

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

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

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

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

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

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

3.2. Блоки функций второго уровня

Модули телеметрии в каждой плоскости можно дополнительно разделить на 5 концептуальных блоков.

  • Запрос, анализ и хранение данных. Этот блок работает с приложением сетевых операций, показанным на рисунке 1. Обычно это является частью системы управления сетью на приёмной стороне. Этот блок отвечает за формирование требований к данным. Интересующие данные могут моделироваться через конфигурацию или пользовательские программы моделирования. Данные могут извлекаться по запросам , а также через подписку на события или потоковые данные. Блок принимает, хранит и обрабатывает возвращённые сетевыми устройствами данные. Анализ данных может быть интерактивным для создания последующих запросов. Блок функций может быть централизованным или распределенным и может иметь 1 или несколько экземпляров.

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

  • Кодирование и экспорт данных. Этот блок определяет, как данные телеметрии будут доставляться для анализа и хранения с контролем доступа. Кодирование данных и протоколы доставки могут меняться в зависимости от цели (местоположения) экспорта.

  • Генерация и обработка данных. Запрошенные данные должны быть собраны, отфильтрованы, обработаны и форматированы в сетевых устройствах из «сырых» данных от источников. Это может включать расчёты и обработку на быстром или медленном пути в устройствах.

  • Объект и источник данных. Этот блок определяет объекты мониторинга и исходные источники данных в устройстве. Источник обычно просто отдаёт «сырые» данные, которые требуют дальнейшей обработки. Каждый источник данных можно считать датчиком. Некоторые источники могут создаваться динамически.

  +----------------------------------------+
+----------------------------------------+ |
|                                        | |
|    Запрос данных, анализ, хранилище    | |
|                                        | +
+-------+++ -----------------------------+
        |||                   ^^^
        |||                   |||
        ||V                   |||
     +--+V--------------------+++------------+
  +-----V---------------------+------------+ |
+---------------------+-------+----------+ | |
| Настройка данных    |                  | | |
| и подписка          | Кодирование и    | | |
| (модель, шаблон,    | экспорт данных   | | |
|  программа)         |                  | | |
+---------------------+------------------| | |
|                                        | | |
|           Генерация и                  | | |
|           обработка данных             | | |
|                                        | | |
+----------------------------------------| | |
|                                        | | |
|       Объект и источник данных         | |-+
|                                        |-+
+----------------------------------------+

Рисунок 2. Блоки модели сетевой телеметрии.


3.3. Абстракции механизмов извлечения и типов данных

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

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

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

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

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

  • Вызванные событиями данные. Данные, которые извлекаются в результате каких-либо событий, например, переход рабочего состояния интерфейса между включённым и отключённым (up, down). Такие данные могут активно выталкиваться через подписку или извлекаться (poll) по запросам. Есть много способов моделирования событий, включая использование конечных автоматов (Finite State Machine или FSM) и действия по событиям (Event Condition Action или ECA) [NETMOD-ECA-POLICY].

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

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

+----------------------+     +-----------------+
|Вызван. событ. данные |<----+ Потоковые данные|
+-------+---+----------+     +-----+---+-------+
        |   |                      |   |
        |   |                      |   |
        |   |   +--------------+   |   |
        |   +-->|Выведен. Данн.|<--+   |
        |       +------+------ +       |
        |              |               |
        |              V               |
        |       +--------------+       |
        +------>|Простые данные|<------+
                +--------------+

Рисунок 3. Связи между типами данных.


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

3.4. Сопоставление модели с имеющимися механизмами

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

Таблица 2. Сопоставление существующих работ


Плоскость администрирования

Плоскость управления

Плоскость пересылки

Генерация данных и подписка

gNMI, NETCONF, RESTCONF, SNMP, YANG-Push

gNMI, NETCONF, RESTCONF, YANG-Push

NETCONF, RESTCONF, YANG-Push

Генерация и обработка данных

MIB, YANG

YANG

IOAM, PSAMP, PBT, AM

Кодирование и экспорт данных

gRPC, HTTP, TCP

BMP, TCP

IPFIX, UDP

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

4. Развитие приложений сетевой телеметрии

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

Этап 0 — Статическая телеметрия

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

Этап 1 — Динамическая телеметрия

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

Этап 2 — Интерактивная телеметрия

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

Этап 3 — Телеметрия с обратной связью

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

Имеющиеся технологии соответствуют этапам 0 и 1, имеются также отдельные приложения для этапов 2 и 3. Однако в будущем сетям с самоуправлением потребуется полнофункциональная система управления операциями, соответствующая этапам 2 и 3 для охвата всех сетевых операций. Чётко заданная модель сетевой телеметрии является первым шагом в этом направлении.

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

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

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

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

  • Модели доверия и правил для телеметрии.

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

  • Транспорт, применяемый для данных телеметрии и присущие ему свойства безопасности.

  • Хранилища данных телеметрии, методы доступа и практика хранения.

  • Отслеживание событий и аномалий телеметрии, которые могут указывать на атаки, использующие интерфейсы телеметрии.

  • Проверка подлинности и целостности телеметрических данных для повешения доверия к ним.

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

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

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

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

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

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

[gnmi] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, C., and C. Marrow, «gRPC Network Management Interface», IETF 98, March 2017, <https://datatracker.ietf.org/meeting/98/materials/slides-98-rtgwg-gnmi-intro-draft-openconfig-rtgwg-gnmi-spec-00>.

[gpb] Google Developers, «Protocol Buffers», <https://developers.google.com/protocol-buffers>.

[grpc] gRPC, «gPPC: A high performance, open source universal RPC framework», <https://grpc.io>.

[IPPM-IOAM-DIRECT-EXPORT] Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Bhandari, S., Ed., Sivakolundu, R., and T. Mizrahi, Ed., «In-situ OAM Direct Exporting», Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-07>.

[IPPM-POSTCARD-BASED-TELEMETRY] Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, T., Li, Z., Mishra, G., Shin, J., and K. Lee, «In-Situ OAM Marking-based Direct Export», Work in Progress, Internet-Draft, draft-song-ippm-postcard-based-telemetry-12, 12 May 2022, <https://datatracker.ietf.org/doc/html/draft-song-ippm-postcard-based-telemetry-12>.

[NETCONF-DISTRIB-NOTIF] Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, «Subscription to Distributed Notifications», Work in Progress, Internet-Draft, draft-ietf-netconf-distributed-notif-03, 10 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-03>.

[NETCONF-UDP-NOTIF] Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H., and P. Lucente, «UDP-based Transport for Configured Subscriptions», Work in Progress, Internet-Draft, draft-ietf-netconf-udp-notif-05, 4 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-05>.

[NETMOD-ECA-POLICY] Wu, Q., Bryskin, I., Birkholz, H., Liu, X., and B. Claise, «A YANG Data model for ECA Policy Management», Work in Progress, Internet-Draft, draft-ietf-netmod-eca-policy-01, 19 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-eca-policy-01>.

[NMRG-ANTICIPATED-ADAPTATION] Martinez-Julia, P., Ed., «Exploiting External Event Detectors to Anticipate Resource Requirements for the Elastic Adaptation of SDN/NFV Systems», Work in Progress, Internet-Draft, draft-pedro-nmrg-anticipated-adaptation-02, 29 June 2018, <https://datatracker.ietf.org/doc/html/draft-pedro-nmrg-anticipated-adaptation-02>.

[NMRG-IBN-CONCEPTS-DEFINITIONS] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, «Intent-Based Networking — Concepts and Definitions», Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09>.

[OPSAWG-DNP4IQ] Song, H., Ed. and J. Gong, «Requirements for Interactive Query with Dynamic Network Probes», Work in Progress, Internet-Draft, draft-song-opsawg-dnp4iq-01, 19 June 2017, <https://datatracker.ietf.org/doc/html/draft-song-opsawg-dnp4iq-01>.

[OPSAWG-IFIT-FRAMEWORK] Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, «A Framework for In-situ Flow Information Telemetry», Work in Progress, Internet-Draft, draft-song-opsawg-ifit-framework-17, 22 February 2022, <https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-17>.

[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, «Simple Network Management Protocol (SNMP)», RFC 1157, DOI 10.17487/RFC1157, May 1990, <https://www.rfc-editor.org/info/rfc1157>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.

[RFC2981] Kavasseri, R., Ed., «Event MIB», RFC 2981, DOI 10.17487/RFC2981, October 2000, <https://www.rfc-editor.org/info/rfc2981>.

[RFC3176] Phaal, P., Panchen, S., and N. McKee, «InMon Corporation’s sFlow: A Method for Monitoring Traffic in Switched and Routed Networks», RFC 3176, DOI 10.17487/RFC3176, September 2001, <https://www.rfc-editor.org/info/rfc3176>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, «An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks», STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC3416] Presuhn, R., Ed., «Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, <https://www.rfc-editor.org/info/rfc3416>.

[RFC3877] Chisholm, S. and D. Romascanu, «Alarm Management Information Base (MIB)», RFC 3877, DOI 10.17487/RFC3877, September 2004, <https://www.rfc-editor.org/info/rfc3877>.

[RFC3954] Claise, B., Ed., «Cisco Systems NetFlow Services Export Version 9», RFC 3954, DOI 10.17487/RFC3954, October 2004, <https://www.rfc-editor.org/info/rfc3954>.

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

[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., «Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires», RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.

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

[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.

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

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, «Cisco Service-Level Assurance Protocol», RFC 6812, DOI 10.17487/RFC6812, January 2013, <https://www.rfc-editor.org/info/rfc6812>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information», STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, «An Overview of Operations, Administration, and Maintenance (OAM) Tools», RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., «Hypertext Transfer Protocol Version 2 (HTTP/2)», RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, «Autonomic Networking: Definitions and Design Goals», RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

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

[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, «BGP Monitoring Protocol (BMP)», RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8084] Fairhurst, G., «Network Transport Circuit Breakers», BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

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

[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, «Alternate-Marking Method for Passive and Hybrid Performance Monitoring», RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.

[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, «Subscription to YANG Notifications», RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.

[RFC8641] Clemm, A. and E. Voit, «Subscription to YANG Notifications for Datastore Updates», RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.

[RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, «Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)», RFC 8671, DOI 10.17487/RFC8671, November 2019, <https://www.rfc-editor.org/info/rfc8671>.

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

[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, «Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring», RFC 8889, DOI 10.17487/RFC8889, August 2020, <https://www.rfc-editor.org/info/rfc8889>.

[RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, R., and A. Ghanwani, «Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework», RFC 8924, DOI 10.17487/RFC8924, October 2020, <https://www.rfc-editor.org/info/rfc8924>.

[RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, «Support for Local RIB in the BGP Monitoring Protocol (BMP)», RFC 9069, DOI 10.17487/RFC9069, February 2022, <https://www.rfc-editor.org/info/rfc9069>.

[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., «Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)», RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.

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

[y1731] ITU-T, «Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks», ITU-T Recommendation G.8013/Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.

Приложение A. Обзор имеющихся методов сетевой телеметрии

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

A.1. Телеметрия плоскости администрирования

A.1.1. Расширения NETCONF для выталкивания

NETCONF [RFC6241] — это популярный протокол сетевого управления, рекомендуемый IETF. Его основное назначение состоит в управлении конфигурацией, но протокол пригоден и для сбора данных. Модель YANG-Push [RFC8639] [RFC8641] расширяет NETCONF и разрешает подписчикам запрашивать непрерывный, настраиваемый поток обновления из хранилища YANG. Видимость изменений, вносимых в конфигурацию YANG и работающие объекты даёт новые возможности, основанные на удалённом отображении (mirroring) конфигурации и операционного состояния. Кроме того, механизм распределенного сбора данных [NETCONF-DISTRIB-NOTIF] с помощью канала публикации UDP [NETCONF-UDP-NOTIF] обеспечивает рост эффективности телеметрии на основе NETCONF.

A.1.2. Интерфейс управления gRPC

Интерфейс сетевого управления gRPC (gRPC Network Management Interface или gNMI) [gnmi] обеспечивает протокол управления сетью на основе модели удалённого вызова процедур gRPC [grpc] (Remote Procedure Call или RPC). Одно определение службы gRPC позволяет охватить настройку конфигурации и телеметрию. Коммуникационная модель gRPC с открытым исходным кодом основана на HTTP/2 [RFC7540] и обеспечивает многочисленные возможности для сетевой телеметрии, включая указанные ниже.

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

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

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

A.2. Телеметрия плоскости управления

A.2.1. Протокол мониторинга BGP

Протокол BMP [RFC7854] служит для мониторинга сессий BGP и предназначен для обеспечения удобного интерфейса при получении представлений маршрутов (route view).

Маршрутные данные BGP собираются с отслеживаемых устройств на станцию мониторинга BMP через организованную сессию BMP TCP. Партнёры BGP отслеживаются с помощью уведомлений BMP Peer Up и Peer Down. Маршруты BGP (включая Adj_RIB_In [RFC7854], Adj_RIB_out [RFC8671], и локальную базу RIB [RFC9069]) инкапсулируются в сообщения BMP Route Monitoring и BMP Route Mirroring, обеспечивающие исходный дамп таблицы и обновления маршрутов в реальном масштабе времени. В дополнение к этому передаётся статистика BGP в сообщениях BMP Stats Report Message, которые могут передаваться по таймеру или событиям. Будущие расширения BMP могут дополнительно обогатить приложения для мониторинга BGP.

A.3. Телеметрия плоскости данных

A.3.1. Технология чередующейся маркировки (AM)

Метод чередующейся маркировки (Alternate-Marking) позволяет эффективно измерять потери пакетов, задержку и её вариации в сетях IP и наложенных (Overlay) сетях, как описано в [RFC8321] и [RFC8889].

Этот метод применим для потоков «точка-точка» и «точка-много точек». AM создаёт группы (batch) пакетов, меняя значение одного бита (или метки) в заголовке пакета. Эти группы пакетов однозначно распознаются в сети и сравнение счётчиков пакетов позволяет определить потери пакетов. Эта же идея модет применяться для измерения задержки путём выбора специальных (ad hoc) пакетов с битом маркировки для измерения задержки.

Методу AM нужны два счётчика на каждый период маркировки для каждого контролируемого потока. Например, при рассмотрении n точек измерения и m отслеживаемых потоков порядок числа счётчиков для каждого интервала измерений составляет n*m*2 (1 счётчик на цвет).

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

Многоточечная чередующаяся маркировка (Multipoint Alternate-Marking) описанная в [RFC8889], нацелена на решение этой проблемы и повышение гибкости мониторинга производительности при потребности в детальном анализе. Приложение координирует задачи измерения производительности сети для оптимизации мониторинга и может выбрать точность настройки точек измерения в зависимости от потребностей.

Используя AM, можно контролировать многоточечную сеть без углублённого изучения с помощью кластеризации (кластерами названы подсети, являющиеся частью сети и имеющие свойства сети в целом). В случае потери пакетов или слишком большой задержки можно применить специальные фильтры для сбора более детального анализа с использованием иной комбинации кластеров вплоть до измерения на уровне потока, как описано в [RFC8321].

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

A.3.2. Динамические сетевые зонды

Аппаратные динамические датчики (Dynamic Network Probe или DNP) [OPSAWG-DNP4IQ] обеспечивают программируемые средства для настройки данных, собираемых приложением из плоскости данных. Явным преимуществом DNP является снижение объёма экспортируемых данных. Полное решение DNP охватывает несколько направлений, включая источники данных, подписку и генерацию данных. Подписка нужна для определения производных данных, которые могут быть составлены и выведены из «сырых» данных. Генерация данных пользуется преимуществами умеренных расчётов в сети для создания желаемых данных.

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

A.3.3. Протокол IPFIX

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

A.3.4. In Situ OAM

Классические методы активного и пассивного мониторинга и измерений неточны или потребляют много ресурсов. Предпочтительно напрямую получать данные, связанные с потоками пакета при прохождении пакетов через сеть. Метод генерации данных IOAM [RFC9197] встраивает новый заголовок инструкций в пользовательские пакеты, а инструкции предписывают узлам сети добавлять в пакеты запрошенные данные. Таким образом, в конце пути можно собрать сведения о пакете, полученные в процессе пересылки. Такие данные «из первых рук» неоценимы для многих сетевых приложений OAM. Однако IOAM создаёт некоторые проблемы, влияя на производительность, безопасность, расширяемость и издержки. Кроме того, возникают проблемы с инкапсуляцией в некоторых протоколах, а также сложны реализации в нескольких доменах (cross-domain).

A.3.5. Телеметрия на основе «открыток»

Телеметрия на базе открыток (postcard), воплощенная в IOAM Direct Export (DEX) [IPPM-IOAM-DIRECT-EXPORT] и IOAM Marking [IPPM-POSTCARD-BASED-TELEMETRY], является дополнительным методов для IOAM на основе паспорта [RFC9197]. PBT напрямую экспортирует данные в каждом узле с помощью независимого пакета. За счёт дополнительного расхода пропускной способности и необходимости сопоставления данных PBT обеспечивает несколько уникальных преимуществ, а также помогает идентифицировать место отбрасывания пакета на пути пересылки.

A.3.6. OAM для конкретных плоскостей данных

Требования к OAM отличаются в разных плоскостях данных. В IETF опубликованы документы по методам и моделям OAM (например, [RFC8924] и [RFC5085]), предназначенные для таких плоскостей данных, как MPLS, L2VPN, NVO3 (Network Virtualization over Layer 3), VXLAN, BIER (Bit Index Explicit Replication), SFC (Service Function Chaining), SR (Segment Routing), DETNET (Deterministic Networking). Упомянутые выше методы телеметрии в плоскости данных могут применяться для расширения возможностей OAM в этих плоскостях данных.

A.4. Телеметрия внешних данных и событий

A.4.1. Источники внешних событий

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

Некоторые интересные для управления сетью категории внешних источников перечислены ниже.

  • «Умные» объекты и датчики. С консолидацией IoT (Internet of Things) любая сетевая система будет иметь много смарт-объектов, подключённых к её физическому окружению и логическим операционным средам. Большинство таких объектов будет основано на различных датчиках (температура, влажность, давление и пр.) и предоставляемые ими сведения может быть очень полезной для управления сетью, даже если датчики не предназначены специально для этого. Элементы этого типа источников обычно будут предоставлять конкретный протокол для взаимодействия, чаще всего — один из протоколов, связанных с IoT, например CoAP.

  • Сетевые службы новостей. Некоторые сетевые службы новостей имеют возможность предоставлять огромный объем информации о происходящих в мире событиях. Некоторые из этих событий могут влиять на сетевые системы, управляемые конкретной моделью, поэтому такая информация модет быть интересная для них. Например, различные отчёты о безопасности, такие как CVE (Common Vulnerabilities and Exposures), от соответствующего агентства могут использоваться управляющим решением для обновления системы при необходимости. Вместо конкретного протокола и формата источники этого типа обычно применяют неформализованный, но структурированный формат. Этот формат может быть частью онтологии и информационной модели платформы телеметрии.

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

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

A.4.2. Соединители и интерфейсы

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

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

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

Спасибо Rob Wilton, Greg Mirsky, Randy Presuhn, Joe Clarke, Victor Liu, James Guichard, Uri Blumenthal, Giuseppe Fioccola, Yunan Gu, Parviz Yegani, Young Lee, Qin Wu, Gyan Mishra, Ben Schwartz, Alexey Melnikov, Michael Scharf, Dhruv Dhody, Martin Duke, Roman Danyliw, Warren Kumari, Sheng Jiang, Lars Eggert, Éric Vyncke, Jean-Michel Combes, Erik Kline, Benjamin Kaduk и многим другим, кто предоставил полезные замечания и предложения, улучшившие документ.


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

В работе над документом участвовали Tianran Zhou, Zhenbin Li, Zhenqiang Li, Daniel King, Adrian Farrel, Alexander Clemm.

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

Haoyu Song

Futurewei

United States of America

Email: haoyu.song@futurewei.com

Fengwei Qin

China Mobile

China

Email: qinfengwei@chinamobile.com

Pedro Martinez-Julia

NICT

Japan

Email: pedro@nict.go.jp

Laurent Ciavaglia

Rakuten Mobile

France

Email: laurent.ciavaglia@rakuten.com

Aijun Wang

China Telecom

China

Email: wangaj3@chinatelecom.cn


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

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

nmalykh@protokols.ru

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

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

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

RFC 9197 Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)

Internet Engineering Task Force (IETF)                 F. Brockners, Ed.
Request for Comments: 9197                                         Cisco
Category: Standards Track                               S. Bhandari, Ed.
ISSN: 2070-1721                                              Thoughtspot
                                                         T. Mizrahi, Ed.
                                                                  Huawei
                                                                May 2022

Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)

Поля данных для операций OAM «на месте»

PDF

Аннотация

IOAM1 собирает операционные и телеметрические данные в пакет по мере прохождения им пути между парой точек сети. В этом документе обсуждаются поля данных для IOAM и связанные с этим типы. Поля данных (IOAM-Data-Fields) можно инкапсулировать в разные протоколы, такие как NSH2, Segment Routing, Geneve3, IPv6. IOAM можно использовать для дополнения механизмов на основе OAM, например, с ICMP или иными типами пакетов-зондов.

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

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

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

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

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

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

Этот документ определяет поля данных для IOAM. Данные OAM в IOAM записываются в пакеты по мере их прохождения через конкретный сетевой домен. Термин in situ (на месте) относится к тому, что сведения OAM добавляются к пакетам данных. А не передаются в специальных пакетах OAM. IOAM служит дополнением к таким механизмам как Ping или Traceroute. В терминах активных или пассивных типов OAM методы IOAM можно отнести к гибридным. Механизмы IOAM не требуют применения специальных пакетов и сведения добавляются в имеющиеся пакеты данных, поэтому метод нельзя считать пассивным. В классификации [RFC7799] IOAM можно считать гибридным типом I (Hybrid Type I). Механизмы IOAM можно применять там, где мехнизмы на основе, например, ICMP, не применимы или не дают нужных результатов, таких как подтверждение прохождения трафика по определённому пути, проверка соглашений об уровне обслуживания (Service Level Agreement или SLA), подробная статистика распределения путей трафика в сетях с применением нескольких путей или случаях, когда тестовый трафик может обрабатываться сетевыми устройствами не так, как трафик данных.

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

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

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

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

E2E

Edge to Edge — сквозной.

Geneve

Generic Network Virtualization Encapsulation [RFC8926] — базовая инкапсуляция для сетевой виртуализации.

IOAM

In situ Operations, Administration, and Maintenance — выполняемые «на месте» действия OAM.

MTU

Maximum Transmission Unit — максимальный передаваемый блок.

NSH

Network Service Header [RFC8300] — заголовок сетевого сервиса.

OAM

Operations, Administration, and Maintenance — эксплуатация, администрирование, обслуживание.

PMTU

Path MTU — MTU на пути.

POT

Proof of Transit — доказательство (подтверждение) транзита.

Short format — короткий формат

Указывает IOAM-Data-Field размером 4 октета.

SID

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

SR

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

VXLAN-GPE

Virtual eXtensible Local Area Network, Generic Protocol Extension [NVO3-VXLAN-GPE] — расширение базового протокола VXLAN.

Wide format — широкий формат

Указывает IOAM-Data-Field размером 8 октетов.

3. Область действия, применимость и допущения

IOAM предполагает набор ограничений, а также руководящие принципы и концепции, тесно связанные с определениями полей (IOAM-Data-Field) и описанные в данном разделе. Вопросы применения полей данных IOAM и связанных с ними концепций при развёртывании IOAM выходят за рамки документа и рассмотрены в [IPPM-IOAM-DEPLOYMENT].

Scope — область действия

Этот документ определяет поля данных IOAM и связанные с ними типы. IOAM-Data-Field можно инкапсулировать в разные протоколы, включая NSH, Segment Routing, Geneve, IPv6. Детали такой инкапсуляции выходят за рамки этого документа и предполагается, что для каждого типа инкапсуляции будет выпущен документ RFC, созданный в тесном контакте с рабочей группой, которая разрабатывает и поддерживает протокол инкапсуляции, а также с рабочей группой IETF по измерению производительности IP (IP Performance Measurement — IPPM).

Domain (or scope) of in situ OAM deployment — домен (область) развёртывания IOAM

IOAM ориентируется на домены с ограничениями, как указано в [RFC8799]. Таким доменом для IOAM может быть, например, кампус предприятия, использующий физические соединения между устройствами или наложенную сеть с виртуальными соединениями (туннелями) между устройствами. Домен с ограничениями, использующий IOAM может содержать один или несколько доменов IOAM со своими идентификаторами пространств имён. Границей IOAM-Domain является периметр или край (edge). Домены IOAM могут пересекаться внутри домена с ограничениями. Разработчики протоколов инкапсуляции для IOAM задают механизмы, обеспечивающие нахождение данных IOAM в пределах IOAM-Domain. Кроме того предполагается, что оператор домена принимает меры по предотвращению утечки данных IOAM через границу домена, например, путём фильтрации пакетов. Оператору следует учитывать потенциальное влияние IOAM на механизмы, такие как обработка ECMP (например, при распределении нагрузки по размерам пакетов может влиять рост размера из-за IOAM), PMTU (значения MTU на всех каналах в домене должны быть достаточными для передачи пакетов увеличенного из-за IOAM размера) и обработка пакетов ICMP (например для IPv6 желательна поддержка IOAM запросов и откликов ICMPv6 с трансляцией в расширения ICMPv6, чтобы можно было копировать IOAM-Data-Field из запросов в отклики).

IOAM control points — точки управления IOAM

Поля данных IOAM добавляются или удаляются из пользовательского трафика устройствами на краю домена. Устройства, формирующие IOAM-Domain, могут добавлять, обновлять или удалять поля данных IOAM. Крайвыми устройствами домена IOAM могут быть хосты или сетевые устройства.

Traffic sets that IOAM is applied to — наборы трафика для применения IOAM

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

Encapsulation independence — независимость от инкапсуляции

Определения IOAM-Data-Field независимы от протоколов, в которые инкапсулируются поля данных IOAM. IOAM-Data-Field можно инкапсулировать в несколько разных протоколов.

Layering — уровни

Если несколько протоколов инкапсуляции (например, при туннелировании) образуют стек, поля данных IOAM могут присутствовать на нескольких уровнях этого стека. Такое поведение соответствует модели ships-in-the-night (корабли в ночи), т. е. IOAM-Data-Field на одном уровне не зависят от полей данных IOAM на другом уровне. Уровни позволяют операторам задавать протокольный уровень, на котором выполняются измерения. На разных уровнях могут (но не обязаны) применяться одни механизмы инкапсуляции IOAM.

IOAM implementation — реализация IOAM

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

4. Поля данных, типы и узлы IOAM

В этом разделе описана относящаяся к IOAM номенклатура и типы данных, такие как IOAM-Data-Field, IOAM-Type, IOAM-Namespace, а также разные типы узлов IOAM.

4.1. Поля данных и типы опций IOAM

Поле данных IOAM-Data-Field — это набор битов с заданным форматом и назначением, который сохраняется в неком месте пакета для целей IOAM.

Для разных вариантов применения IOAM поля данных IOAM делятся по категориям, которые называют типами опций — IOAM-Option-Type. Поддерживается общий реестр IOAM-Option-Type (7.1. Реестр IOAM Option-Type). В соответствии с IOAM-Option-Type определены разные IOAM-Data-Field. Этот документ задаёт 4 IOAM-Option-Type:

  • Pre-allocated Trace Option-Type;

  • Incremental Trace Option-Type;

  • POT Option-Type;

  • E2E Option-Type.

Новые значения IOAM-Option-Type могут быть выделены IANA, как указано в параграфе 7.1. Реестр IOAM Option-Type.

4.2. Домены и типы узлов IOAM

В разделе 3 уже отмечено, что развёртывание IOAM предполагается в домене с ограничениями [RFC8799]. В пакет добавляется 1 или несколько IOAM-Option-Type на входе в IOAM-Domain и они удаляются на выходе из домена. Внутри домена IOAM поля IOAM-Data-Field могут обновляться узлами, через которые они проходят. IOAM-Domain состоит их инкапсулирующих, декапсулирующих и транзитных узлов IOAM. Роль узла определяется в пространстве имён IOAM-Namespace, описанном ниже. Узел может иметь разные роли в разных IOAM-Namespace.

Устройство, добавляющее в пакет хотя бы один IOAM-Option-Type, называется инкапсулирующим узлом IOAM, а устройство, удаляющее IOAM-Option-Type, — декапсулирующим узлом IOAM. Узлы внутри домена, понимающие данные IOAM, считывающие, записывающие или обрабатывающие их, называются транзитными узлами IOAM. Узлы IOAM, добавляющие или удаляющие IOAM-Data-Field, могут также обновлять поля IOAM-Data-Field. Иными словами, узлы инкапсуляции и декапсуляции могут одновременно быть транзитными узлами IOAM. Отметим, что не каждый узел в домене IOAM обязан быть транзитным узлом IOAM. Например, пакеты могут проходить через межсетевые экраны (МСЭ) с поддержкой IOAM и в этом случае транзитными узлами IOAM будут эти МСЭ, а не все узлы.

Узел инкапсуляции IOAM внедряет хотя бы один IOAM-Option-Type (из списка в параграфе 7.1. Реестр IOAM Option-Type) в пакеты, для которых разрешено применять IOAM. Если IOAM применяется для части трафика, узел инкапсуляции отвечает за применение IOAM к указанному подмножеству трафика.

Транзитные узлы IOAM читают, записывают и/или обрабатывают хотя бы одно поле IOAM-Data-Field. При наличии в пакете одновременно типов Pre-allocated и Incremental каждый транзитный узел IOAM с учётом конфигурации и возможностей реализации IOAM может заполнять данные трассировки IOAM для типа Pre-allocated или Incremental (но не для обоих). Отметим, что отсутствие заполнения Trace Option-Type разрешено транзитным узлам IOAM. Транзитный узел должен игнорировать непонятные IOAM-Option-Type. Транзитному узлу недопустимо добавлять в пакет новые IOAM-Option-Type, недопустимо удалять IOAM-Option-Type из пакета и недопустимо менять IOAM-Data-Field для типа Edge-to-Edge Option-Type.

Узел декапсуляции IOAM удаляет из пакетов IOAM-Option-Type.

Роль узлов инкапсуляции, транзита и декапсуляции IOAM всегда выполняется в конкретном пространстве имён IOAM. Это означает, что узел IOAM, являющийся, например декапсулирующим для IOAM-Namespace A, но не для IOAM-Namespace B, будет удалять IOAM-Option-Type из пакета лишь для пространства A. Отметим, что это применимо и к IOAM-Option-Type, которые узел не понимает, например, IOAM-Option-Type, которые могут быть добавлены в будущем, сверх описанных выше 4 типов.

IOAM-Namespace позволяет специфические для пространства имён определения и интерпретацию IOAM-Data-Field. Идентификатор пространства имён может, например, указывать на физический интерфейс (чтобы понимать, какой из физических интерфейсов агрегированного канала использован для приёма или передачи пакета), а в другом случае — на логический (для туннеля). Пространства имён рассмотрены в следующем параграфе.

4.3. Пространства имён IOAM

IOAM-Namespace добавляет контекст к IOAM-Option-Type и связанным IOAM-Data-Field, которые интерпретируются, как указано в этом документе, независимо от пространства имён IOAM. IOAM-Namespace обеспечивает способ группировки узлов для поддержки разных подходов к развёртыванию IOAM (см. примеры ниже). Пространства имён позволяют также решать возможные проблемы из-за того, что IOAM-Data-Field (например, идентификаторы узлов IOAM) не уникальны в глобальном масштабе. Значимость IOAM-Data-Field всегда ограничена конкретным IOAM-Namespace. С учётом интерпретации IOAM-Data-Field как контекста конкретного пространства имён всегда требуется передавать поле Namespace-ID вместе с полями данных IOAM.

IOAM-Namespace указывается 16-битовым идентификатором пространства имён (Namespace-ID). Поле IOAM-Namespace включается во все IOAM-Option-Type, определённые в этом документе, и должно включаться во все будущие IOAM-Option-Type. Значения Namespace-ID поделены на два диапазона:

  • операторские значения от 0x0001 до 0x7FFF;

  • выделенные IANA значения от 0x8000 до 0xFFFF.

Диапазон выделяемых IANA значений предназначен для обеспечения совместимости с новой функциональностью в будущих расширениях IOAM, а операторские значения относятся к домену и назначаются оператором. Namespace-ID = 0x0000 является принятым по умолчанию (Default-Namespace-ID) и указывает, что с полями IOAM-Data-Field в пакете не связано конкретного пространства имён. Значение Default-Namespace-ID должно поддерживаться всеми узлами, реализующими IOAM. Примером использования Default-Namespace-ID является система, где не применяется конкретных пространств имён для некоторых или всех пакетов с IOAM-Data-Field.

Идентификаторы пространства имён позволяют устройствам с поддержкой IOAM определить:

  • требуется ли устройству обрабатывать один или несколько IOAM-Option-Type; если Namespace-ID в пакете не соответствует ни одному из настроенных на узле Namespace-ID, где он работает, узлу недопустимо изменять содержимое полей IOAM-Data-Field;

  • какие IOAM-Option-Type требуется обрабатывать/менять при наличии в пакете нескольких IOAM-Option-Type (это может быть в случае перекрытия IOAM-Domain или многоуровневого развёртывания IOAM);

  • нужно ли удалять из пакета один или несколько IOAM-Option-Type, например, на границе домена.

Для IOAM-Namespace поддерживается несколько вариантов применения, указанных ниже.

  • IOAM-Namespace могут использоваться оператором для идентификации разных IOAM-Domain. Устройства на краю IOAM-Domain могут фильтровать Namespace-ID для обеспечения изоляции доменов.

  • IOAM-Namespace создают дополнительный контекст для полей IOAM-Data-Field и могут служить для обеспечения уникальности IOAM-Data-Field и подобающей интерпретации станциями управления сетью и контроллерами. Поле идентификатора узла (node_id, см. ниже) не обязано быть уникальным в развёртываний. Возможны ситуации, когда оператор хочет использовать разные идентификаторы узлов для разных уровней IOAM даже в одном устройстве или идентификаторы узлов могут быть не уникальными по организационным причинам, таким как слияние двух организаций. Namespace-ID может служить идентификатором контекста, чтобы комбинация node_id и Namespace-ID всегда была уникальной.

  • IOAM-Namespace можно использовать для задания способа интерпретации IOAM-Data-Field. IOAM поддерживает 3 разных формата временных меток и Namespace-ID можно использовать для выбора нужного формата. Поля IOAM-Data-Field (например, заполнение буферов), с которыми не связана единица измерения, интерпретируются в контексте IOAM-Namespace.

  • IOAM-Namespace могут служить для идентификации различных наборов устройств (например, разных типов) в системе. Если оператор хочет внедрять разные поля IOAM-Data-Field по устройствам, эти устройства можно собрать в разные IOAM-Namespace. Это может быть связано с тем, что набор функций IOAM зависит от устройства или имеются причины оптимизировать пространство в заголовках пакетов. Возможна также связь с аппаратными или эксплуатационными ограничениями на размер данных трассировки, которые можно добавить и обработать, что препятствует сбору полной трассировки для пакета.

  • Назначение различных IOAM Namespace-ID разным наборам узлов или частям сети и использование отдельного экземпляра IOAM-Option-Type для каждого Namespace-ID позволяет собрать и построить полную трассировку на основе частичных трассировок для каждого IOAM-Option-Type в каждом пакете потока. Например, оператор может разделить устройства домена по двум IOAM-Namespace так, что каждое пространство имён представляется одним или двумя IOAM-Option-Type в пакете. Каждый узел будет записывать данные только для IOAM-Namespace, к которому он относится, игнорируя IOAM-Option-Type с другим IOAM-Namespace. Для получения полного представления нужно сопоставить поля IOAM-Data-Field обоих IOAM-Namespace.

4.4. IOAM Trace Option-Type

В типичном развёртывании все узлы IOAM-Domain принимают участие в IOAM, выполняя функции транзитного, инкапсулирующего или декапсулирующего узла. Если не все узлы домена поддерживают функциональность IOAM, определённую в этом документе, данные трассировки IOAM (т. е. данные узлов, см. ниже) могут собираться лишь на узлах с поддержкой IOAM. Не поддерживающие определённые здесь функции IOAM узлы будут пересылать пакеты, не изменяя полей IOAM-Data-Field. Предполагается, что максимальное число пересылок и минимальное значение PMTU в IOAM-Domain известны. Индикатор переполнения (бит O) определён как один из способов обработки ситуаций с недооценкой значения PMTU, когда число интервалов пересылки с поддержкой IOAM превосходит возможности (место для данных) пакета.

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

Pre-allocated Trace-Option — заранее определённая трассировка

Этот вариант трассировки определён как контейнер полей узлов данных (см. ниже) с выделенным заранее пространством для каждого узла, куда тот может поместить свои данные. Этот вариант полезен для реализаций, где эффективно однократное выделение пространства и поддерживается индексированный массив для заполнения данных в процессе транзита (например, к этому типу часто относятся программные узлы пересылки). Инкапсулирующий узел IOAM выделяет пространство для Pre-allocated Trace Option-Type в пакете и устанавливает соответствующие поля в IOAM-Option-Type. Декапсулирующий узел IOAM выделяет массив для хранения данных, полученных от каждого узла в домене, через который прошёл пакет. Транзитные узлы IOAM обновляют содержимое массива и, возможно, контрольные суммы во внешних заголовках. Указатель, являющийся частью данных трассировки IOAM, задаёт следующую позицию в массиве. Транзитный узел, обновляющий содержимое Pre-allocated Trace-Option, обновляет и указатель, определяющий место записи данных для следующего транзитного узла IOAM. Массив со списком узлов данных (см. ниже) в пакете заполняется итеративно по мере прохождения пакета через сеть, начиная с последней записи в массисе, т. е, сначала заполняется node data list [n], затем node data list [n-1] и т. д.

Incremental Trace-Option — инкрементная трассировка

Этот вариант трассировки определён как контейнер полей узлов данных, где каждый узел выделяет и выталкивает свои данные сразу после заголовка опции. Этот тип записи трассировки полезен для некоторых аппаратных реализаций, поскольку он исключает для транзитных элементов необходимость считывать полный массив в опции и позволяет использовать пакеты произвольного размера, разрешаемого MTU. Узел инкапсуляции IOAM выделяет пространство для Trace Option-Type, устанавливая на основе рабочего состояния и конфигурации поля Option-Type, определяющие поля IOAM-Data-Field для сбора сведений и размер списка данных узла. Транзитные узлы IOAM выталкивают свои данные в список с учётом протокольных ограничений на уровне инкапсуляции, а затем уменьшают значение размера, остающегося для заполнения последующими узлами, и корректируют размер (возможно и контрольную сумму) во внешних заголовках.

Узлы инкапсуляции и декапсуляции IOAM, поддерживающие трассировку, должны поддерживать оба Trace Option-Type, а транзитным узлам достаточно поддержки одного типа. При одновременном использовании в системе обоих вариантов опция Incremental Trace-Option должна размещаться до Pre-allocated Trace-Option. В системах с устройствами Incremental Trace-Option и Pre-allocated Trace-Option в пакетах могут присутствовать оба Option-Type. С учётом того, что оператору известно оборудование в конкретном IOAM-Domain, он может с помощью настройки выбрать вариант трассировки для домена.

В каждой записи данных узла содержатся сведения от конкретного транзитного узла IOAM, через который прошёл пакет. Узел декапсуляции IOAM удаляет IOAM-Option-Type и обрабатывает и/или экспортирует данные. Как и для всех IOAM-Data-Field, поля IOAM-Data-Field в IOAM Trace Option-Type определяются в контексте IOAM-Namespace.

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

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

  • Идентификация устройства, принявшего пакет (входной интерфейс).

  • Идентификация устройства, передавшего пакет (выходной интерфейс).

  • Время суток, кода пакет был обработан узлом и задержка при транзите. Возможны и ожидаются разные определения времени обработки, но важно использовать одно определение на всех устройствах IOAM-Domain.

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

  • Сведения о том, добавлялись ли данные трассировки IOAM на каждом узле пересылки (hop) или некоторые узлы пересылки не являются транзитными узлами IOAM.

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

4.4.1. Выделенные заранее и инкрементные Trace Option-Type

Форматы IOAM Pre-allocated Trace-Option и IOAM Incremental Trace-Option похожи, а исключения указаны ниже. Оба варианта трассировки включают заголовок варианта трассировки с фиксированным размером и пространство переменного размера для хранения собранных данных (список данных узла — node data list). Транзитному узлу IOAM (т. е. узлу, не выполняющему инкапсуляцию или декапсуляцию) недопустимо менять какие-либо поля в заголовке фиксированного размера, за исключением полей Flags и RemainingLen. Т. е. транзитному узлу IOAM недопустимо менять поля Namespace-ID, NodeLen, IOAM Trace-Type, Reserved.

Формат заголовка фиксированного размера (Pre-allocated и Incremental) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IOAM Trace-Type                 |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Данные опции трассировки должны выравниваться по 4 октетной границе, как показано на рисунке.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                                                               |  |
|                        node data list [0]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  D
|                                                               |  a
|                        node data list [1]                     |  t
|                                                               |  a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                             ...                               ~  S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  p
|                                                               |  a
|                        node data list [n-1]                   |  c
|                                                               |  e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
|                        node data list [n]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+


Namespace-ID

16-битовый идентификатор IOAM-Namespace. Значение Namespace-ID = 0x0000 определено как Default-Namespace-ID (см. параграф 4.3) и должно быть известно всем узлам, реализующим IOAM. Для любого другого Namespace-ID, не соответствующего пространству имён, заданному для узла, этому узлу недопустимо менять содержимое полей IOAM-Data-Field.

NodeLen

5-битовое целое число без знака, задающее размер данных, добавляемых каждым узлом, в 4-октетных блоках без учёта поля Opaque State Snapshot.
Если бит 22 в IOAM Trace-Type не установлен, поле NodeLen задаёт фактический размер, добавляемый каждым узлом, а при установленном бите 22 фактический размер добавляемых узлом данных определяет сумма NodeLen и размера поля Opaque State Snapshot в 4-октетных блоках.
Например, если установлены 3 бита IOAM Trace-Type и ни для одного из них не задан широкий формат, поле NodeLen будет иметь значение 3. Если установлены 3 бита IOAM Trace-Type и для двух задан широкий формат, поле NodeLen будет иметь значение 5.
Узел инкапсуляции IOAM должен устанавливать NodeLen.
Узел, получаемый опцию трассировки IOAM Pre-allocated или Incremental Trace-Option, полагается на NodeLen.

Flags

4-битовое поле. Флаги выделяются IANA, как указано в параграфе 7.3. Этот документ задаёт 1 флаг.

Бит 0

Бит переполнения (Overflow или O-bit) является старшим в поле флагов. Если элемент сети, который считается добавляющим данные узла, обнаруживает нехватку места для записи этих данных, ему недопустимо добавлять в пакет какие-либо поля и он должен установить бит O = 1 в заголовке IOAM Trace-Option. Это полезно для транзитных узлов, чтобы исключить последующую обработку опции.

RemainingLen

7-битовое целое число без знака. Это поле задаёт размер пространства данных (в 4-октетных блоках), остающееся для записи, до того, как список данных узла будут сочтёт заполненным. Отправитель должен установить начальное значение поля RemainingLen. Отправитель может рассчитать значение RemainingLen, учитывая число байтов узлов данных, разрешённых PMTU, с учётом известности PMTU. Последующие узлы могут просто сравнивать RemainingLen и NodeLen вместе с Opaque State Snapshot (если нужно) для определения возможности добавить данные. Когда данные узла добавлены, узел должен уменьшить величину RemainingLen на размер добавленных данных. В Pre-allocated Trace-Option поле RemainingLen служит для определения смещения в пространстве данных для записи элемента данных узла. В частности, запись данных узла будет начинаться со смещения RemainingLen — NodeLen — размер (Opaque State Snapshot) в 4-октетных блоках. Если RemainingLen в Pre-allocated Trace-Option превосходит размер опции, как указано в заголовке нижележащего уровня (который выходит за рамки этого документа), узлу недопустимо добавлять какие-либо поля.

IOAM Trace-Type

24-битовый идентификатор, указывающий, какие типы данных используются в списке данных узла.
IOAM Trace-Type является битовым полем. Ниже приведён список определённых в этом документе типов, которые описаны в параграфе 4.4.2. Порядок размещения полей данных в каждом элементе узла соответствует приведенному ниже порядку битов поля IOAM Trace-Type.

Бит 0

Старший бит, установка (1) которого указывает наличие Hop_Lim и node_id (короткий формат) в данных узла.

Бит 1

Значение 1 указывает наличие ingress_if_id и egress_if_id (короткий формат) в данных узла.

Бит 2

Значение 1 указывает наличие секунд временной метки в данных узла.

Бит 3

Значение 1 указывает наличие долей секунд временной метки в данных узла.

Бит 4

Значение 1 указывает наличие транзитной задержки в данных узла.

Бит 5

Значение 1 указывает наличие определяемых IOAM-Namespace сведений (короткий формат) в данных узла.

Бит 6

Значение 1 указывает наличие глубины очереди в данных узла.

Бит 7

Значение 1 указывает наличие Checksum Complement в данных узла.

Бит 8

Значение 1 указывает наличие Hop_Lim и node_id (широкий формат) в данных узла.

Бит 9

Значение 1 указывает наличие ingress_if_id и egress_if_id (широкий формат) в данных узла.

Бит 10

Значение 1 указывает наличие определяемых IOAM-Namespace сведений (широкий формат) в данных узла.

Бит 11

Значение 1 указывает наличие занятости буфера в данных узла.

Биты 12-21

Не определены и доступны для распределения в реестре IOAM Trace-Type (параграф 7.2). Каждый будущий узел данных, соответствующий одному из этих битов, должен иметь размер 4 октета. Узел инкапсуляции IOAM должен устанавливать для неопределённых битов значение 0. Если транзитный узел IOAM получает пакет со значением 1 в одном или нескольких резервных битах, он должен выполнить одно из действий:
  1. добавить соответствующие данные узла, заполнив их резервным значением 0xFFFFFFFF, после полями данных узла для определённых выше битов IOAM Trace-Type, чтобы общий размер данных, добавленных этим узлом (в 4-октетных блоках) был равен NodeLen;
  2. не добавлять никаких полей данных узла даже для указанных выше битов IOAM Trace-Type.

Бит 22

Установка (1) этого бита указывает наличие поля переменного размера Opaque State Snapshot.

Бит 23

Резервный бит, который должен сбрасываться при передаче и игнорироваться при получении. Этот бит зарезервирован для будущих расширений поля битов IOAM Trace-Type.
В параграфе 4.4.2 описаны типы IOAM-Data-Type и их форматы. Внутри IOAM-Domain возможные комбинации битов IOAM Trace-Type могут быть ограничены конфигурацией.

Reserved

8 резервных битов, которые узел инкапсуляции IOAM должен сбрасывать (0) до передачи, а транзитные узлы IOAM должны игнорировать.

Node data List [n]

Поле переменного размера со списком элементов узла данных, где содержимое каждого элемента определяется значением IOAM Trace-Type. Порядок полей данных в каждом элементу соответствует порядку битов в поле IOAM Trace-Type. Каждый узел должен помещать свой элемент данных перед полученными элементами данных, чтобы его элемент стал первым в списке. Последним элементом данных в этом списке является элемент данных первого узла с поддержкой IOAM на пути пакета. Такое заполнение списка данных узла обеспечивает совпадение порядка данных в списке с порядком в опциях трассировки Incremental и Pre-allocated. В Pre-allocated Trace-Option индекс в RemainingLen указывает смещение текущего активного узла для заполнения.

4.4.2. Поля данных узла IOAM и связанные форматы

Все поля IOAM-Data-Field должны выравниваться по 4 октетам. Если узел, в котором предполагается обновление IOAM-Data-Field, не способен заполнить значение, указанное IOAM Trace-Type, в это поле должно быть помещено значение 0xFFFFFFFF (4-октетное поле) или 0xFFFFFFFFFFFFFFFF (8-октетное поле), указывающее, что значение не заполнено (за исключением явно указанных полей).

Некоторые IOAM-Data-Field, определённые ниже, такие как определяемые IOAM-Namespace поля, могут иметь коротких и длинный (широкий) формат, которые не исключают друг друга и в развёртывании могут применяться оба сразу. Например, ingress_if_id_(short format) может быть идентификатором физического интерфейса, а ingress_if_id_(wide format) — идентификатором логического субинтерфейса на нем.

Поля данных и связанные с ними типы для каждого IOAM-Data-Field заданы ниже. Определения IOAM-Data-Field сосредоточены на синтаксисе полей данных и не избегают задания семантики. Поэтому для полей данных не заданы единицы измерения для таких полей, как заполнение буфера или глубина очереди. При таком подходе узлы могут предоставлять сведения в их исходном формате и не потребуется преобразовывать единицы измерения или формат. Предполагается, что системы с дополнительной обработкой сведений IOAM, например, системы управления сетью, способны преобразовывать единицы измерения в рамках обработки IOAM-Data-Field. Сочетание конкретного поля данных и Namespace-ID обеспечивает контекст для корректной интерпретации представленных данных.

4.4.2.1. Hop_Lim и node_id в коротком формате

Hop_Lim и короткое поле node_id занимают 4 октета, как показано на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Hop_Lim

1-октетное целое число без знака. В поле помещается значение Hop Limit в пакете на выходе из узла, записавшего эти данные. Данные Hop Limit служат для определения местоположения узла на пути связи. Значение копируется из нижележащего уровня, например, TTL в заголовке IPv4 или Hop Limit в заголовке IPv6 пакета, готового к передаче. Семантика Hop_Lim зависит от протокола нижележащего уровня, в который инкапсулируется IOAM, поэтому в данном документе не рассматривается. В это поле должно помещаться значение 0xff, если нижележащий уровень не имеет поля, эквивалентного TTL или Hop Limit.

node_id

3-октетное целое число без знака. Поле однозначно указывает узел в IOAM-Namespace и связанном IOAM-Domain. Процедура выделения, управления и отображения node_id выходит за рамки документа. Аспекты node_id, связанные с развёртыванием, рассматриваются в [IPPM-IOAM-DEPLOYMENT].
4.4.2.2. ingress_if_id и egress_if_id в коротком формате
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поля ingress_if_id и egress_if_id образуют 4-октетный блок, как показано ниже.

ingress_if_id

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

egress_if_id

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

Отметим, что в результате использования в IOAM своих IOAM-Namespace для IOAM-Data-Field поля данных, такие как идентификаторы интерфейсов, можно гибко применять для представления системных ресурсов, связанных со входными или выходными пакетами, например, ingress_if_id может представлять физический, логический или виртуальный интерфейс и даже очередь.

4.4.2.3. Секунды временной метки

Поле timestamp seconds является 4-октетным целым числом без знака и содержит метку абсолютного времени в секундах для момент получения пакета узлом. Для этого поля могут применяться 3 формата на основе протокола точного времени (Precision Time Protocol или PTP) (см., например, [RFC8877]), NTP [RFC5905] или POSIX [POSIX], описанных в разделе 5. Во всех трёх случаях поле содержит 32 старших бита временной метки в формате, заданном в разделе 5. Если узел не способен указать время, он помещает в это поле значение 0xFFFFFFFF. Отметим, что это значение указывает корректное время в течение 1 секунды примерно один раз за 136 лет. Анализатор сопоставляет несколько пакетов или сравнивает значение метки со своим временем суток для обнаружения ошибки.

4.4.2.4. Дробная часть временной метки

Поле timestamp fraction является 4-октетным целым числом без знака и содержит дробную часть числа секунд с начала эпохи NTP [RFC8877] для момента получения пакета узлом. Для этого поля могут применяться 3 формата на основе протокола точного времени (Precision Time Protocol или PTP) (см., например, [RFC8877]), NTP [RFC5905] или POSIX [POSIX], описанных в разделе 5. Во всех трёх случаях поле содержит 32 младших бита временной метки в формате, заданном в разделе 5. Если узел не способен указать время, он помещает в это поле значение 0xFFFFFFFF. Отметим, что это значение указывает корректное время вформате NTP примерно в течение 233 пикосекунд каждой секунды. При использовании формата NTP анализатор сопоставляет несколько пакетов или сравнивает значение метки со своим временем суток для обнаружения ошибки.

4.4.2.5. Задержка при передаче

Поле transit delay является 4-октетным целым числом без знака из диапазона 0 — 231-1 и указывает число наносекунд, проведённых пакетом в транзитном режиме, которое может показывать задержку в очередях на узле. Если транзитная задержка больше 231-1 нсек, устанавливается бит O для индикации переполнения значением поле 0x80000000. Когда поле является частью данных, но узел не способен указать значение, он должен установить 0xFFFFFFFF.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|                     transit delay                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.6. Данные, связанные с пространством имён

Поле namespace-specific data является 4-октетным целым числом без знака, которое может использоваться узлом для добавления связанных с IOAM-Namespace данных. Семантика значений поля определяется в контексте IOAM-Namespace.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.7. Глубина очереди
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       queue depth                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

4.4.2.8. Дополнение контрольной суммы

Поле Checksum Complement является 4-октетным целым числом без знака, содержащим значение дополнения контрольной суммы. Это значение полезно при транспортировке IOAM с инкапсуляцией, использующей транспорт UDP, такой как VXLAN-GPE или Geneve. Без Checksum Complement узел IOAM, добавляющий данные, обновляет контрольную сумму UDP в соответствии с рекомендациями протокола инкапсуляции, а при наличии Checksum Complement узле инкапсуляции или транзитный узел IOAM, добавляющий данные, должен следовать одному из приведённых вариантов для поддержки корректности UDP Checksum.

  1. Повторный расчёт поля UDP Checksum.

  2. Использование Checksum Complement для нейтрального к контрольной сумме обновления данных UDP (payload). Полю Checksum Complement назначается значение, которое учитывает добавленные текущим узлом данные, чтобы значение UDP Checksum оставалось корректным.

Узлы декапсуляции IOAM должны пересчитывать поле UDP Checksum, поскольку они не знают, какие из предшествующих узлов изменили поле UDP Checksum или Checksum Complement.

Поля Checksum Complement аналогичным способом применяются в [RFC7820] и [RFC7821].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Checksum Complement                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.9. Hop_Lim и node_id в широком формате

Поля Hop_Lim node_id в широком формате занимают 8 октетов, как показано ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      node_id (продолжение)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Hop_Lim

1-октетное целое число без знака (см. параграф 4.4.2.1).

node_id

7-октетное целое число без знака, указывающее идентификатор узла в IOAM-Namespace и связанном IOAM-Domain. Процедура выделения, управления и отображения node_id выходит за рамки документа.
4.4.2.10. ingress_if_id и egress_if_id в широком формате

Поля ingress_if_id и egress_if_id в широком формате занимают 8 октетов, как показано ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ingress_if_id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       egress_if_id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ingress_if_id

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

egress_if_id

4-октетное целое число без знака, указывающее идентификатор выходного интерфейса, переславшего поток.
4.4.2.11. Зависящие от Namespace данные в широком формате

Поле namespace-specific занимает 8 октетов, которые могут использоваться узлом для добавления связанных с IOAM-Namespace данных. Семантика значений поля определяется в контексте IOAM-Namespace.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~             namespace-specific data (продолжение)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.12. Buffer Occupancy

Поле buffer occupancy является 4-октетным целым числом без знака и указывает текущее состояние занятости общего пула буферов, используемого набором очередей, в зависимых от реализации единицах измерения. Значение интерпретируется в контексте IOAM-Namespace и/или идентификатора узла, если он применяется. Авторы отмечают, что в некоторых случаях требуется согласованность единиц на всем пути через сеть, поэтому реализациям рекомендуется применять стандартные единицы, такое как байты.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       buffer occupancy                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.13. Opaque State Snapshot
 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      |                     Schema ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поле Opaque State Snapshot имеет переменный размер и следует приведённым выше правилам для IOAM-Data-Field. Это поле позволяет узлам сети сохранять произвольное состояние на узле данных без предопределённой схемы, а фактическая схема задаётся в контексте IOAM-Namespace и должна быть передана анализатору с помощью отдельного механизма (out-of-band), который данный документ не задаёт. 24-битовое поле Schema ID в контексте IOAM-Namespace указывает конкретную используемую схему и настраивается для сетевого элемента оператором.

Length

1-октетное целое число без знака — размер поля Opaque data, следующего за Schema ID, в 4-октетных блоках.

Schema ID

3- октетное целое число без знака, указывающее схему для поля Opaque data.

Opaque data

Поле переменного размера, интерпретируемое в соответствии со схемой, указанной в поле Schema ID.

Когда поле является частью данных, но узел не способен указать значение, он должен установить Length = 0 и Schema ID = 0xFFFFFFFF, что говорит об отсутствии схемы.

4.4.3. Примеры данных узла IOAM

The format used for the entries in a packet’s «node data list» array can vary from packet to packet and deployment to deployment. Some deployments might only be interested in recording the node identifiers, whereas others might be interested in recording node identifiers and timestamps. This section provides example entries of the «node data list» array.

0xD40000 (0b110101000000000000000000)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     timestamp fraction                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0xC00000 (0b110000000000000000000000)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0x900000 (0b100100000000000000000000)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   timestamp fraction                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0x840000 (0b100001000000000000000000)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0x940000 (0b100101000000000000000000)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


0x308002 (0b001100001000000000000010)


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      timestamp seconds                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      node_id(продолжение)                     |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length      |                     Schema ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5. Подтверждение Transit Option-Type

IOAM Proof of Transit Option-Type (POT) служит для поддержки проверки вариантов использования пути или цепочки функций [RFC7665], т. е. подтверждения того, что трафик прошёл по определённому пути. Хотя детали обработки данных IOAM для POT инкапсулирующими, транзитными и декапсулирующими узлами IOAM выходят за рамки документа, подходы POT разделяют необходимость однозначной идентификации пакетов, а также интерактивной работы с набором сведений, обрабатываемых от узла к узлу. Поэтому в пакет добавляются 2 элемента данных как IOAM-Data-Field.

PktID

Уникальный идентификатор пакета.

Cumulative

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

IOAM Proof of Transit Option-Type состоит из заголовка IOAM Proof of Transit Option фиксированного размера и полей данных IOAM Proof of Transit Option. Формат заголовка показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Namespace-ID            |IOAM POT-Type  | IOAM POT flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поля данных IOAM Proof of Transit Option-Type должны выравниваться по 4-октетной границе.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Поле данных POT Option, определяемое IOAM POT-Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Namespace-ID

16-битовый идентификатор IOAM-Namespace. Значение 0x0000 определено как Default-Namespace-ID (параграф 4.3) и должно быть известно всем узлам, реализующим IOAM. Для любого Namespace-ID, не соответствующего пространству имён на узле, этому узлу недопустимо менять содержимое полей IOAM-Data-Field.

IOAM POT-Type

8-битовый идентификатор конкретного варианта POT, задающего данные POT для включения. Этот документ определяет IOAM POT-Type 0
0: данные POT являются 16-октетным полем для переноса данных, связанных с процедурами POT.
Если узел получает непонятное значение IOAM POT-Type, ему недопустимо менять, добавлять или удалять содержимое полей IOAM-Data-Field.

IOAM POT flags

8 битов. Этот документ не задаёт флагов и биты 0-7 доступны для распределения (см. параграф 7.5). Невыделенные биты должны сбрасываться (0) при передаче и игнорироваться при получении.

POT Option data

Поле переменного размера, тип которого определяет IOAM POT-Type.

4.5.1. POT типа 0

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |IOAM POT-Type=0|R R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                        PktID                                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  P
|                     PktID (продолжение)                       |  O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  T
|                        Cumulative                             |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                     Cumulative (продолжение)                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+


Формат IOAM Proof of Transit Option с IOAM POT-Type 0 показан на рисунке.

Namespace-ID

16-битовый идентификатор IOAM-Namespace (см. параграф 4.3).

IOAM POT-Type

8-битовый идентификатор конкретного варианта POT, задающего данные POT для включения (см. параграф 4.5). В данном случае устанавливается IOAM POT-Type = 0.

Bit 0-7

Не определены (см. параграф 4.5).

PktID

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

Cumulative

64-битовое значение Cumulative, обновляемое на конкретных узлах путём обработки по значению поля PktID и параметров настройки.

Примечание. Допустимы большие или меньшие значения PktID и Cumulative, которые могут потребоваться в некоторых развёртываниях, например, при ограничении пространства протоколом инкапсуляции. В будущих версиях документа могут быть заданы другие размеры данных POT.

4.6. IOAM Edge-to-Edge Option-Type

IOAM Edge-to-Edge Option-Type содержит данные, добавляемые узлом инкапсуляции и интерпретируемые узлом декапсуляции IOAM. Транзитные узлы IOAM могут обрабатывать данные, но им недопустимо менять их.

IOAM Edge-to-Edge Option-Type содержит заголовок фиксированного размера IOAM Edge-to-Edge Option-Type и поля данных IOAM Edge-to-Edge Option-Type. Формат заголовка показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |         IOAM E2E-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поля данных IOAM Edge-to-Edge Option-Type должны выравниваться по 4-октетной границе.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Поле данных E2E Option, определяемое IOAM-E2E-Type       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Namespace-ID

16-битовый идентификатор IOAM-Namespace. Значение 0x0000 определено как Default-Namespace-ID (параграф 4.3) и должно быть известно всем узлам, реализующим IOAM. Для любого Namespace-ID, не соответствующего пространству имён на узле, этому узлу недопустимо менять содержимое полей IOAM-Data-Field.

IOAM-E2E-Type

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

Бит 0

Старший бит, установка (1) которого указывает наличие 64-битового порядкового номера, добавленного к конкретной группе пакетов, используемой для обнаружения потерь, переупорядочения или дублирования пакетов этой группы. Группировка пакетов зависит от развёртывания и определяется инкапсулирующим узлом IOAM, например, путём классификации по n полям (n-tuple) пакетов. При установке этого бита бит 1 (для 32-битового порядкового номера) должен быть сброшен (0).

Бит 1

Установка этого бита указывает наличие 32-битового порядкового номера, добавленного к конкретной группе пакетов, используемой для обнаружения потерь, переупорядочения или дублирования пакетов этой группы. Группировка пакетов зависит от развёртывания и определяется инкапсулирующим узлом IOAM, например, путём классификации по n полям (n-tuple) пакетов. При установке этого бита бит 0 (для 64-битового порядкового номера) должен быть сброшен (0).

Бит 2

Установка этого бита указывает наличие секунд временной метки, представляющей момент входа пакета в домен IOAM. На узле IOAM время взятия метки может зависеть от реализации. Возможна фиксация времени, когда 1) пакет был получен узлом, 2) передан узлом или 3) инкапсулирован в туннель (при использовании туннельной инкапсуляции. Каждая реализация документирует момент взятия метки E2E для включения в пакет. Это 4-октетное поле метки может иметь формат PTP (см., например, [RFC8877]), NTP [RFC5905] или POSIX [POSIX], как описано в разделе 5. Во всех трёх случаях поле содержит 32 старших бита временной метки в формате, заданном в разделе 5. Если узел не способен указать время, он помещает в это поле значение 0xFFFFFFFF. Отметим, что это значение указывает корректное время в течение 1 секунды примерно один раз за 136 лет. Анализатор сопоставляет несколько пакетов или сравнивает значение метки со своим временем суток для обнаружения ошибки.

Бит 3

Установка этого бита указывает наличие дробной части числа секунд, представляющей момент входа пакета в домен IOAM. time at which the packet entered the IOAM-Domain. Это 4-октетное поле метки может иметь формат PTP (см., например, [RFC8877]), NTP [RFC5905] или POSIX [POSIX], как описано в разделе 5. Во всех трёх случаях поле содержит 32 старших бита временной метки в формате, заданном в разделе 5. Если узел не способен указать время, он помещает в это поле значение 0xFFFFFFFF. Если узел не способен указать время, он помещает в это поле значение 0xFFFFFFFF. Отметим, что это значение указывает корректное время вформате NTP примерно в течение 233 пикосекунд каждой секунды. При использовании формата NTP анализатор сопоставляет несколько пакетов или сравнивает значение метки со своим временем суток для обнаружения ошибки.

Биты 4-15

Не определены. Инкапсулирующий узел IOAM должен установить 0 при передаче и игнорировать при получении.

E2E Option data

Поле переменного размера, тип которого определяется значением IOAM E2E-Type.

5. Форматы временных меток

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

5.1. Усечённый формат PTP

Протокол точного времени PTP использует 80-битовые метки времени, из которых ссечённый формат использует 64 старших бита. Усечённый формат PTP задан в параграфе 4.3 [RFC8877] и подробно описан ниже для полноты.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Nanoseconds                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Seconds

Целое число секунд с начала эпохи PTP, заданное 32-битовым значением без знака.

Nanoseconds

Дробная часть числа секунд с начала эпохи PTP, выраженная в наносекундах 32-битовым значением от 0 до 109-1 с дискретностью 1 нсек.

Эпоха

PTP (см. например, [RFC8877]).

Переход через максимум

Это поле заполняется каждые 232 секунды, что составляет примерно 136 лет. Следующий максимум будет в 2106 г.

Аспекты синхронизации

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

5.2. 64-битовые метки NTP

Протокол сетевого времени (Network Time Protocol или NTP) [RFC5905] задает 64-битовые временные метки. Эта спецификация использует метки NTP в соответствии с параграфом 4.2.1 of [RFC8877], описанный здесь для полноты.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Fraction                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Seconds

Целое число секунд с начала эпохи NTP, заданное 32-битовым значением без знака.

Fraction

Дробная часть числа секунд с начала эпохи NTP, выраженная 32-битовым значением с дискретностью 2-32 сек, что соответствует приблизительно 233 пикосекундам.

Эпоха

NTP, см. [RFC5905].

Переход через максимум

Это поле заполняется каждые 232 секунды, что составляет примерно 136 лет. Следующий максимум будет в 2036 г.

Аспекты синхронизации

Использующие этот протокол узлы обычно синхронизированы с UTC по протоколу NTP [RFC5905]. Таким образом, временная метка может выводиться из синхронизированных по протоколу NTP часов, что позволяет измерять время относительно часов сервера NTP.

5.3. Метки POSIX

Эти метки основаны на формате времени POSIX [POSIX]. Спецификация используемого формата приведена ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Microseconds                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Fraction                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Seconds

Целое число секунд с начала эпохи POSIX, заданное 32-битовым значением без знака.
Microseconds
Дробная часть числа секунд с начала эпохи POSIX, выраженная в микросекундах 32-битовым значением от 0 до 106-1 с дискретностью 1 мсек.

Эпоха

POSIX, см. [POSIX], Приложение A.4.16.

Переход через максимум

Это поле заполняется каждые 232 секунды, что составляет примерно 136 лет. Следующий максимум будет в 2106 г.

Аспекты синхронизации

Предполагается, что использующие этот формат узлы работают на основе операционной системы Linux и применяют время POSIX. В некоторых случаях узлы могут синхронизироваться с UTC с помощью механизма, выходящего за рамки этого документа, например, NTP [RFC5905]. Таким образом, временная метка может выводиться из синхронизированных по протоколу NTP часов, что позволяет измерять время относительно часов сервера NTP.

6. Экспорт данных IOAM

Узлы IOAM собирают сведения о пакетах, проходящих через домен с поддержкой IOAM. Инкапсулирующие и транзитные узлы IOAM могут извлекать информацию из пакетов, обрабатывать её и экспортировать, например, с помощью IP Flow Information Export (IPFIX). Механизмы и форматы данных для экспорта данных IOAM выходят за рамки документа.

Способ экспорта необработанных данных IOAM с помощью IPFIX описан в [IPPM-IOAM-RAWEXPORT].

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

Агентство IANA определило группу реестров In Situ OAM (IOAM), ключающую:

IOAM Option-Type;
IOAM Trace-Type;
IOAM Trace-Flags;
IOAM POT-Type;
IOAM POT-Flags;
IOAM E2E-Type;
IOAM Namespace-ID.

Эти реестры более подробно описаны ниже.

7.1. Реестр IOAM Option-Type

Этот реестр определяет 128 кодов полей IOAM Option-Type для идентификации типов IOAM-Option-Type, как описано в разделе 4. Этот документ определяет 4 кодо:

0: IOAM Pre-allocated Trace Option-Type;
1: IOAM Incremental Trace Option-Type;
2: IOAM POT Option-Type;
3: IOAM E2E Option-Type.

Коды 4 — 127 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Name: имя регистрируемого Option-Type;
Code point: желаемое значение кода;
Description: краткое описание регистрируемого Option-Type
Reference: ссылка на документ с определением нового Option-Type.

При оценке новых регистраций должно проверяться наличие в новом IOAM-Option-Type поля IOAM-Namespace и его размещение в качестве первого поля заголовка для нового Option-Type.

7.2. Реестр IOAM Trace-Type

Этот реестр определяет назначение для каждого бита поля IOAM Trace-Type для Pre-allocated Trace Option-Type и Incremental Trace Option-Type, определённых в параграфе 4.4. Биты 0 — 11 определены в параграфе 4.4.1.

Бит 0: hop_Lim и node_id в коротком формате;
Бит 1: ingress_if_id и egress_if_id в коротком формате;
Бит 2: секунды timestamp;
Бит 3: доли секунд;
Бит 4: транзитная задержка;
Бит 5: зависящие от пространства имён данные в коротком формате;
Бит 6: глубина очереди;
Бит 7: дополнение контрольной суммы;
Бит 8: hop_Lim и node_id в широком формате;
Бит 9: ingress_if_id и egress_if_id в широком формате;
Бит 10: зависящие от пространства имён данные в широком формате;
Бит 11: занятость буфера
Бит 22: Opaque State Snapshot с переменным размером;
Бит 23: резерв
Биты 12-21 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Bit: желаемый бит для выделения в 24-битовом поле IOAM Trace Option-Type для Pre-allocated Trace Option-Type и Incremental Trace Option-Type;
Description: краткое описание регистрируемого бита;
Reference: ссылка на документ с определением нового бита.

7.3. Реестр IOAM Trace-Flags

Этот реестр определяет биты флагов для Pre-allocated Trace-Option и Incremental Trace-Option, определённых в параграфе 4.4.1.

Бит 0: Переполнение (бит O)
Биты 1-3 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Bit: желаемый бит для выделения в поле флагов Pre-allocated Trace Option-Type и Incremental Trace Option-Type;
Description: краткое описание регистрируемого бита;
Reference: ссылка на документ с определением нового бита.

7.4. Реестр IOAM POT-Type

Этот реестр определяет 256 кодов IOAM POT-Type для IOAM Proof of Transit Option (параграф 4.5). Данный документ выделяет лишь код 0.

0: 16 октетов данных POT.

Коды 1-255 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Name: Имя регистрируемого POT-Type;
Code point: желаемое значение для регистрируемого кода;
Description: краткое описание регистрируемого POT-Type;
Reference: ссылка на документ с определением нового POT-Type.

7.5. Реестр IOAM POT-Flags

Этот реестр определяет биты флагов для типа IOAM POT Option-Type, определённого в параграфе 4.5.

Биты 0-7 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Bit: желаемый бит для выделения в 8-битовом поле флагов IOAM POT Option-Type;
Description: краткое описание регистрируемого бита;
Reference: ссылка на документ с определением нового бита.

7.6. Реестр IOAM E2E-Type

Этот реестр определяет биты 16-битового поля IOAM E2E-Type для IOAM E2E Option (параграф 4.6). Данный документ выделяет биты 0-3.

Бит 0: 64-битовый порядковый номер;
Бит 1: 32-битовый порядковый номер;
Бит 2: секунды timestamp;
Бит 3: доли секунды timestamp.
Биты 4-15 доступны для распределения по процедуре IETF Review, как указано в [RFC8126].

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

Bit: желаемый бит для выделения в 16-битовом поле флагов IOAM E2E-Type;
Description: краткое описание регистрируемого бита;
Reference: ссылка на документ с определением нового бита.

7.7. Реестр IOAM Namespace-ID

Агентство IANA организовало реестр IOAM Namespace-ID, содержащий 16-битовые значения и соответствующий шаблону для запросов, приведённому ниже. Определение для 0x0000 приведено в этом документе, значения 0x0001 — 0x7FFF зарезервированы для приватного использования (управляются операторами), как указано в параграфе 4.3 данного документа. Значения 0x8000 — 0xFFFF будут выделяться по процедуре Expert Review в соответствии с [RFC8126].

При получении нового запроса назначенные эксперты выполняют указанные ниже действия.

  • Проверка полноты запроса, т. е. соответствия шаблону. Неполные запросы возвращаются заявителю.

  • Проверка дублирования имеющихся или ожидающих пространств имён и конфликтов с ними. При наличии дублирования или конфликта запрос возвращается заявителю для исправления.

  • Запрос отзывов соответствующих рабочих групп и сообществ для обеспечения должного рассмотрения запроса и предварительного согласия с ним. Эксперт будет запрашивать отклик по меньшей мере от рабочей группы IPPM путём отправки запроса в почтовую конференцию ippm@ietf.org. На ожидание откликов отводятся 3 недели. При получении откликов от рабочих групп и сообществ м предварительным согласием эксперт будет одобрять запрос и просить IANA выделить новое значение Namespace-ID. Если эксперт не получит одобрения в откликах, он будет просить заявителя связаться с соответствующими рабочими группами и сообщеятвами для дальнейшего рассмотрения и уточнения запроса.

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

0x0000: принятое по умолчанию пространство имён (известно всем узлам IOAM);
0x0001 — 0x7FFF: резерв для приватного использования;
0x8000 — 0xFFFF: не распределены.

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

Name: имя регистрируемого Namespace-ID;
Code point: желаемое значение кода для регистрируемого Namespace-ID;
Description: краткое описание регистрируемого Namespace-ID;
Reference: ссылка на документ с определением регистрируемого Namespace-ID;
Status of the registration: регистрация может быть постоянной (permanent) или временной (provisional). Регистрации Namespace-ID, успешно прошедшие рецензирование экспертов, получают статус provisional. После публикации RFC для нового Namespace-ID статус меняется на permanent.

8. Вопросы управления и развёртывания

Этот документ определяет структуру и применение полей IOAM-Data-Field, но не задаёт инкапсуляцию этих полей в те или иные протоколы. Вопросы развёртывания и управления IOAM должны рассматриваться в контексте протокола инкапсуляции IOAM-Data-Field, поэтому не обсуждаются в документе. Развёртыванию IOAM посвящён документ [IPPM-IOAM-DEPLOYMENT], где описана структура развёртывания и приведены практические примеры.

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

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

Тип Proof of Transit Option-Type (параграф 4.5) служит для проверки пути пакетов данных, т. е. подтверждения того, что пакеты проходят через определённый набор узлов.

Если атакующий имеет доступ к некоторым узлам сети и может менять программы на этих узлах, он сможет воспользоваться полями IOAM-Data-Field для целей, отличных от указанных в этом документе, например, для сокрытия несанкционированных каналов между узлами сети.

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

IOAM может служить для организации или усиления атак на службы (Denial-of-Service или DoS). Например, атакующий может добавлять заголовок IOAM к пакетам с целью истощения ресурсов на сетевых устройствах, участвующих в IOAM, или элементов, принимающих, собирающих или анализирующих данные IOAM. Другим примером является атака с размером пакетов, где злоумышленник помещает связанные с IOAM-Option-Type заголовки в пакеты данных, что ведёт к фрагментированию или отбрасыванию пакетов по причине превышения MTU. В случае применения POT атакующий может повреждать поля данных POT в пакетах для отказа при проверке даже в случае корректного пути.

Опции IOAM могут включать временные метки, поэтому при использовании сетевыми устройствами протоколов синхронизации на эти протоколы возможны атаки [RFC7384] способные нарушить целостность меток времени.

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

Протоколам IETF требуются функции, обеспечивающие безопасность. Хотя поля IOAM-Data-Field сами не представляют протокола, они добавляют протокол, который служит для инкапсуляции IOAM-Data-Field. Любая спецификация, задающая передачу полей IOAM-Data-Field протоколом инкапсуляции, должна обеспечивать механизм криптографической защиты целостности IOAM-Data-Field. Такая защита может быть обеспечена механизмом протокола инкапсуляции или с помощью механизмов, указанных в [IPPM-IOAM-DATA-INTEGRITY].

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

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

Этот документ не определяет содержимого настраиваемых полей IOAM-Data-Field, таких как Opaque State Snapshot или зависящие от пространства имён данные. С такими полями могут быть связаны вопросы безопасности, которые должны рассматриваться в документах, определяющих содержимое и формат полей.

Системы IOAM, где применяются оба типа опций IOAM Trace Option-Type (Pre-allocated Trace Option-Type и Incremental Trace Option-Type) могут страдать от неполной видимости, если информацию, собираемую через два Trace Option-Type, должным образом не сопоставлять и не агрегировать. Если транзитные узлы IOAM используют IOAM-Data-Field в пакетах для дальнейших действий или анализа, узлы с поддержкой лишь одного IOAM Trace Option-Type в системе IOAM с двумя Trace Option-Type будут иметь ограниченную видимость, что может приводить к неверным выводам или действиям.

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

Вопросы развёртывания IOAM, включая подходы к снижению рассмотренных выше угроз и возможных атак, выходят за рамки этого документа. Развёртывание IOAM обсуждается в [IPPM-IOAM-DEPLOYMENT].

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

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

[POSIX] IEEE, «IEEE/Open Group 1003.1-2017 — IEEE Standard for Information Technology—Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7», IEEE Std 1003.1-2017, January 2018, <https://standards.ieee.org/ieee/1003.1/7101/>.

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

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

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

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

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

[IPPM-IOAM-DATA-INTEGRITY] Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman, «Integrity of In-situ OAM Data Fields», Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-integrity-01, 2 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-01>.

[IPPM-IOAM-DEPLOYMENT] Brockners, F., Bhandari, S., Bernier, D., and T. Mizrahi, «In-situ OAM Deployment», Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-deployment-01, 11 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-01>.

[IPPM-IOAM-RAWEXPORT] Spiegel, M., Brockners, F., Bhandari, S., and R. Sivakolundu, «In-situ OAM raw data export with IPFIX», Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-rawexport-06, 21 February 2022, <https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport-06>.

[IPV6-RECORD-ROUTE] Kitamura, H., «Record Route for IPv6 (RR6) Hop-by-Hop Option Extension», Work in Progress, Internet-Draft, draft-kitamura-ipv6-record-route-00, 17 November 2000, <https://datatracker.ietf.org/doc/html/draft-kitamura-ipv6-record-route-00>.

[NVO3-VXLAN-GPE] Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed., «Generic Protocol Extension for VXLAN (VXLAN-GPE)», Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12>.

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, «An Overview of Operations, Administration, and Maintenance (OAM) Tools», RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.

[RFC7384] Mizrahi, T., «Security Requirements of Time Protocols in Packet Switched Networks», RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., «Service Function Chaining (SFC) Architecture», RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.

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

[RFC7820] Mizrahi, T., «UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)», RFC 7820, DOI 10.17487/RFC7820, March 2016, <https://www.rfc-editor.org/info/rfc7820>.

[RFC7821] Mizrahi, T., «UDP Checksum Complement in the Network Time Protocol (NTP)», RFC 7821, DOI 10.17487/RFC7821, March 2016, <https://www.rfc-editor.org/info/rfc7821>.

[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., «Network Service Header (NSH)», RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[RFC8799] Carpenter, B. and B. Liu, «Limited Domains and Internet Protocols», RFC 8799, DOI 10.17487/RFC8799, July 2020, <https://www.rfc-editor.org/info/rfc8799>.

[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, «Guidelines for Defining Packet Timestamps», RFC 8877, DOI 10.17487/RFC8877, September 2020, <https://www.rfc-editor.org/info/rfc8877>.

[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., «Geneve: Generic Network Virtualization Encapsulation», RFC 8926, DOI 10.17487/RFC8926, November 2020, <https://www.rfc-editor.org/info/rfc8926>.

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

Авторы благодарны Éric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) и Greg Mirsky за комментарии и советы.

Этот документ использует несколько концепций, описанных в [IPV6-RECORD-ROUTE]. Авторы хотели бы отметить работу Hiroshi Kitamura и других создателей этого документа.

Авторы выражают признательность за полезные советы и проницательные комментарии Joe Clarke, Al Morton, Tom Herbert, Carlos J. Bernardos, Haoyu Song, Mickey Spiegel, Roman Danyliw, Benjamin Kaduk, Murray S. Kucherawy, Ian Swett, Martin Duke, Francesca Palombini, Lars Eggert, Alvaro Retana, Erik Kline, Robert Wilton, Zaheduzzaman Sarker, Dan Romascanu, Barak Gafni.

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

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

Carlos Pignataro
Cisco Systems, Inc.
Research Triangle Park
7200-11 Kit Creek Road
NC 27709
United States of America
Email: cpignata@cisco.com
 
Mickey Spiegel
Barefoot Networks, an Intel company
101 Innovation Drive
San Jose, CA 95134-1941
United States of America
Email: mickey.spiegel@intel.com
 
Barak Gafni
Nvidia
Suite 100
350 Oakmead Parkway
Sunnyvale, CA 94085
United States of America
Email: gbarak@nvidia.com
 
Jennifer Lemon
Broadcom
270 Innovation Drive
San Jose, CA 95134
United States of America
Email: jennifer.lemon@broadcom.com
 
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
 
John Leddy
United States of America
Email: john@leddy.net
 
Stephen Youell
JP Morgan Chase
25 Bank Street
London
E14 5JP
United Kingdom
Email: stephen.youell@jpmorgan.com
 
David Mozes
Email: mosesster@gmail.com
 
Petr Lapukhov
Facebook
1 Hacker Way
Menlo Park, CA 94025
United States of America
Email: petr@fb.com
 
Remy Chang
Barefoot Networks, an Intel company
101 Innovation Drive
San Jose, CA 95134-1941
United States of America
Email: remy.chang@intel.com
 
Daniel Bernier
Bell Canada
Canada
Email: daniel.bernier@bell.ca

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

Frank Brockners (editor)
Cisco Systems, Inc.
3rd Floor
Nordhein-Westfalen
Hansaallee 249
40549 Duesseldorf
Germany
Email: fbrockne@cisco.com
 
Shwetha Bhandari (editor)
Thoughtspot
3rd Floor
Indiqube Orion
Garden Layout
HSR Layout
24th Main Rd
Bangalore 560 102
Karnataka
India
Email: shwetha.bhandari@thoughtspot.com
 
Tal Mizrahi (editor)
Huawei
8-2 Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com

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

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

nmalykh@protokols.ru

1In situ Operations, Administration, and Maintenance — эксплуатация, администрирование, обслуживание на месте.

2Network Service Header — заголовок сетевого сервиса.

3Generic Network Virtualization Encapsulation — базовая инкапсуляция для виртуализации сетей.

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

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

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

RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3

Internet Engineering Task Force (IETF)                       E. Rescorla
Request for Comments: 9147                                       Mozilla
Obsoletes: 6347                                            H. Tschofenig
Category: Standards Track                                    Arm Limited
ISSN: 2070-1721                                              N. Modadugu
                                                            Google, Inc.
                                                              April 2022

The Datagram Transport Layer Security (DTLS) Protocol Version 1.3

Протокол защиты транспорта дейтаграмм (DTLS) версии 1.3

PDF

Аннотация

Этот документ задаёт версию 1.3 протокола защиты транспорта дейтаграмм (Datagram Transport Layer Security или DTLS). DTLS 1.3 позволяет приложениям клиентов и серверов взаимодействовать через Internet без возможности просмотра, перехвата и подмены сообщений.

Протокол DTLS 1.3 основан на протоколе защиты транспортного уровня (Transport Layer Security или TLS) версии 1.3 и обеспечивает такие же гарантии безопасности за исключением поддержки порядка доставки и невоспроизводимости пакетов. Семантика дейтаграмм базового транспорта сохраняется в DTLS.

Этот документ отменяет RFC 6347.

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

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

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

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

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

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

Основной целью протокола TLS является организация аутентифицированных соединений между взаимодействующими партнёрами и обеспечение для соединений защиты целостности и конфиденциальности. Протокол TLS включает два уровня — протокол TLS record и протокол TLS handshake. Для работы TLS требуется надёжный транспортный канал, обычно TCP [RFC0793].

Некоторые приложения используют транспорт UDP [RFC0768] и протокол DTLS был разработан для обеспечения защиты взаимодействий таких приложений. DTLS намеренно сделан максимально похожим на TLS, чтобы свести к минимуму новые разработки для защиты и максимально воспользоваться имеющимся кодом и инфраструктурой.

DTLS 1.0 [RFC4347] был разработан на основе TLS 1.1 [RFC4346], DTLS 1.2 [RFC6347] — на основе TLS 1.2 [RFC5246]. Протокола DTLS 1.1 нет, эта версия была пропущена для согласования с нумерацией версий TLS. Эта спецификация описывает наиболее современную версию протокола DTLS, основанную на TLS 1.3 [TLS13] и отменяет DTLS 1.2.

Реализации, поддерживающие DTLS 1.2 и DTLS 1.3, функционально совместимы с поддерживающими лишь DTLS 1.2 (используется DTLS 1.2), а реализации TLS 1.3 совместимы с TLS 1.2 (см. Приложение D к [TLS13]). Хотя возможна совместимость и с DTLS 1.0, применять DTLS 1.0 не рекомендуется, как указано в параграфе 3.1.2 [RFC7525]. Документ [DEPRECATE] запрещает использовать DTLS 1.0.

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

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

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

client — клиент

Конечная точка, инициирующая соединение DTLS.

association — ассоциация

Общее состояние двух конечных точек, организованное при согласовании DTLS.

connection — соединение

Синоним для ассоциации.

endpoint — конечная точка

Клиент или сервер в соединении.

epoch — эпоха

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

handshake — согласование (приветствие)

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

peer — партнёр

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

receiver — получатель

Конечная точка, принимающая записи.

sender — отправитель

Конечная точка, передающая записи.

server — сервер

Конечная точка, которая воспринимает (не инициирует) соединение DTLS.

CID

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

MSL

Максимальный срок действия (жизни) сегмента.

Предполагается знакомство читателя с [TLS13]. Как и в TLS 1.3, сообщение HelloRetryRequest имеет такой же формат как ServerHello, но для удобства в документе используется термин HelloRetryRequest, как будто это разные сообщения.

В DTLS 1.3 применяется сетевой порядок байтов (big-endian — сначала старший) кодирования сообщений, заданный в [TLS13] и ранних спецификациях (D)TLS.

Предполагается знакомство читателя с [RFC9146], поскольку функциональность CID применяется в DTLS 1.3.

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

+

Заслуживающие внимания расширения переданы в предыдущем сообщении.

*

Необязательные сообщения или расширения, передаваемые в зависимости от ситуации.

{}

Сообщения, защищённые с использованием ключей, выведенных из [sender]_handshake_traffic_secret.

[]

Сообщения, защищённые с использованием ключей, выведенных из traffic_secret_N.

3. Обоснование решения и обзор DTLS

Основой решения DTLS является организация TLS через транспортный уровень на базе дейтаграмм. Такой уровень не требует и не предоставляет надёжной и упорядоченной доставки данных. Протокол DTLS сохраняет эти свойства для данных приложений. Приложения вроде потоковой передачи, Internet-телефонии, сетевых игр используют транспорт на основе дейтаграмм из-за чувствительности передаваемых данных к зедержкам в сети. Поведение таких приложений не меняется в результате применения протокола DTLS для защиты коммуникаций, поскольку DTLS не компенсирует потери и нарушение порядка доставки. Отметим, что в потоковых приложениях с малой задержкой и играх DTLS применяется для защиты данных (например, канала данных WebRTC), а в телефониии DTLS служит для организации ключей, тогда как защиту данных обеспечивает протокол SRTP3 [RFC5763].

TLS не подходит напрямую для транспорта дейтаграмм по 4 указанным ниже причинам.

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

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

  3. Сообщения при согласовании могут превышать доступный для дейтаграмм размер. DTLS добавляет в согласующие сообщения поля, позволяющие собирать фрагменты.

  4. Протоколы доставки дейтаграмм подвержены некорректному поведени, вызывающему атаки с отказом в обслуживании (denial-of-service или DoS) сторонних элементов. В DTLS 1.3 применяется проверка обратных маршрутов с помощью сообщений TLS 1.3 HelloRetryRequest (смю 5.1. Противодействие DoS-атакам).

3.1. Потеря пакетов

Клиент                                   Сервер
------                                   ------
ClientHello           ------>
                         X<-- HelloRetryRequest
                                       (потеря)
[Таймер завершен]
ClientHello           ------>
(повтор передачи)

Рисунок 1. Пример повтора передачи DTLS.


В DTLS применяется простой таймер повтора передачи для обработки случаев потери пакетов.

На рисунке 1 показана базовая концепция использования первой фазы согласования DTLS (handshake).

Как только клиент передал сообщение ClientHello, он ожидает от сервера HelloRetryRequest или ServerHello. Однако по завершении отсчёта запущенного таймера клиент понимает, что ClientHello или отклик от сервера потерян и повторяет отправку ClientHello. Когда сервер получает повтор, он понимает, что нужно повторить своё сообщение HelloRetryRequest или ServerHello.

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

Более подробное описание тайм-аутов и повтора передачи приведено в параграфе 5.8. Тайм-ауты и повтор передачи.

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

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

3.3. Фрагментация

Согласующие сообщения TLS и DTLS могут быть достаточно большими (в теории до 224-1 байтов, практически много кбайт). Дейтаграммы UDP часто ограничены размером 1500 байтов, если фрагментация IP нежелательна. Чтобы преодолеть это ограничение, согласующие сообщения DTLS можно фрагментировать на записи DTLS, каждую из которых можно поместить в одну дейтаграмму UDP (см. параграф 4.4. Проблемы PMTU). В каждом согласующем сообщении DTLS указывается смещение и размер фрагмента, что позволяет получателю собрать исходное сообщение по получении всех фрагментов.

3.4. Обнаружение повторного использования

DTLS может поддерживать обнаружение воспроизведения записей (replay). Используются те же методы, что и в IPsec AH/ESP, путём поддержки окна юитовых отображений принятых пакетов. Записи, не попадающие в окно и полученные ранее автоматически отбрасываются без уведомления. Функция защиты от повтороного использования является необязательной, поскольку дубликаты пакетов не всегда являются злонамеренными и могут возникать из-за ошибок маршрутизации. Приложения могут (предположительно) сами обнаруживать дубликаты пакетов и соответственно изменять свою стратегию передачи данных.

4. Уровень DTLS Record

Уровень записей DTLS 1.3 отличается от уровня записей TLS 1.3 и уровня записей DTLS 1.2.

  1. В структуре DTLSCiphertext нет лишних полей номера версии и типа.

  2. В DTLS добавлена эпоха и порядковый номер в заголовок записи TLS. Номер позволяет получателю корректно расшифровать и проверить запись DTLS. Число битов для полей эпохи и номера в структуре DTLSCiphertext сокращено по сравнению с предыдущей версией.

  3. Эпоха DTLS представленная в DTLSPlaintext имеет размер 2 октета для совместимости с DTLS 1.2. Это значение помещается в два младших октета эпохи соединения, заданной 8-октетным счётчиком, инкрементируемым при каждом обновлении ключей KeyUpdate (4.2. Порядковый номер и эпоха). Порядковый номер помещается в младшие 48 битов 64-битового поля номера. Нешифрованные записи недопустимо передавать с порядковыми номерами больше 248-1, поэтому 16 старших битов всегда имеют значение 0.

  4. Заголовок структуры DTLSCiphertext имеет переменный размер.

Структуры DTLSPlaintext служат для передачи незащищённых записей, а DTLSCiphertext — для передачи защищенных.

Форматы записей DTLS показаны на рисунке 2. Если явно не указано иное, поля имеют такое же значение, как в предыдущих версиях TLS/DTLS.

       struct {
           ContentType type;
           ProtocolVersion legacy_record_version;
           uint16 epoch = 0
           uint48 sequence_number;
           uint16 length;
           opaque fragment[DTLSPlaintext.length];
       } DTLSPlaintext;

       struct {
            opaque content[DTLSPlaintext.length];
            ContentType type;
            uint8 zeros[length_of_padding];
       } DTLSInnerPlaintext;

       struct {
           opaque unified_hdr[variable];
           opaque encrypted_record[length];
       } DTLSCiphertext;

Рисунок 2. Форматы записей DTLS 1.3.

legacy_record_version

Поле должно иметь значение {254, 253} для всех записей, кроме начальной ClientHello (т. е. не созданной после HelloRetryRequest), где оно может иметь значение {254, 255} для совместимости. Поле должно игнорироваться при обработке (см. Приложение D.1 к [TLS13]).

epoch

Младшие 2 байта значения эпохи соединения.

unified_hdr

Структура переменного размера, показанная на рисунке 3.

encrypted_record

Зашифрованная форма последовательного представления структуры DTLSInnerPlaintext.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID |
| (при наличии  |
/  согласуется  /   C   - присутствует Connection ID (CID)
|  размер)      |   S   - размер порядкового номера
+-+-+-+-+-+-+-+-+   L   - присутствует Length
| 8 или 16 битов|   E   - Epoch
|Sequence Number|
+-+-+-+-+-+-+-+-+
|16 битов Length|
| (при наличии) |
+-+-+-+-+-+-+-+-+

Рисунок 3. Унифицированный заголовок DTLS 1.3.


Фиксированные биты

Три старших бита унифицированного заголовка имеют значения 001. Это гарантирует соответствие значения области DTLS при мультиплексировании в соответствии с [RFC7983], а также позволяет гарантированно отличать шифрованные записи DTLS 1.3 от шифрованных записей DTLS 1.2 при их передаче с одним квартетом хостов и портов. Такое мультиплексирование возможно лишь при использовании CID [RFC9146], где записи DTLS 1.2 будут иметь тип содержимого tls12_cid (25).

C

Бит (0x10), устанавливаемый при наличии Connection ID.

S

Этот бит (0x08) указывает размер порядкового номера — 0 для 8-битового, 1 для 16-битового. Реализации могут применять в одном соединении номера разного размера.

L

Бит L (0x04) указывает наличие поля Length.

E

Указывают 2 младших бита эпохи.

Connection ID

Идентификатор соединения (CID) переменного размера. Функциональность CID описана в [RFC9146], а пример можно найти в параграфе 9.1. Пример CID.

Sequence Number

8 или 16 битов порядкового номера записи (16 при установленном флаге S, 8 при сброшенном ).

Length

Идентично полю Length в записи TLS 1.3.

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

На рисунке 4 показаны разные заголовки записей.

 0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|Тип содержимого|     |0|0|1|1|1|1|E E|     |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|   16 битов    |     |               |     |8 битов Seq. No|
|   Version     |     / Connection ID /     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+     |               |     |               |
|   16 битов    |     +-+-+-+-+-+-+-+-+     |  Шифрованная  |
|    Epoch      |     |    16 битов   |     /  запись       /
+-+-+-+-+-+-+-+-+     |Sequence Number|     |               |
|               |     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|               |     |   16 битов    |       Структура
|   48 битов    |     |   Length      |       DTLSCiphertext
|Sequence Number|     +-+-+-+-+-+-+-+-+       (минимальная)
|               |     |               |
|               |     |  Шифрованная  |
+-+-+-+-+-+-+-+-+     /  запись       /
|    16 битов   |     |               |
|    Length     |     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      Структура 
|               |      DTLSCiphertext
|               |      (полная)
/   Фрагмент    /
|               |
+-+-+-+-+-+-+-+-+
 Структура
 DTLSPlaintext

Рисунок 4. Примеры заголовков DTLS 1.3.


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

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

После извлечения эпоху и порядковый номер можно объединить в структуре RecordNumber

       struct {
           uint64 epoch;
           uint64 sequence_number;
       } RecordNumber;

Это 128-битовое значение применяется в сообщении ACK, а также в качестве входного параметра record_sequence_number функции аутентифицированного шифрования со связанными данными (Authenticated Encryption with Associated Data или AEAD). Значение заголовка целиком, показанное на рисунке 4 (до шифрования номера записи, см. 4.2.2. Восстановление порядкового номера и эпохи), применяется как дополнительные данные функции AEAD. Например, при использовании минимального варианта связанные данные (Associated Data или AD) имеют размер 2 октета. Отметим, что это отличается от расчёта дополнительных данных для DTLS 1.2 и DTLS 1.2 с Connection ID. В DTLS 1.3 64-битовое значение sequence_number используется как порядковый номер для расчёта AEAD и, в отличие от DTLS 1.2, эпоха не включается.

4.1. Демультиплексирование записей DTLS

Формат заголовка DTLS 1.3 сложнее, чем в DTLS 1.2, где первый байт всегда указывает тип содержимого. Как показано на рисунке 5, первый байт определяет способ демультиплексирования входящей записи DTLS. Первые 3 бита отличают шифрованные записи DTLS 1.3 от записей прежних версий и нешифрованных записей DTLS 1.3. Поэтому диапазон от 32 (0b0010 0000) до 63 (0b0011 1111) должен быть исключён в будущем из выделяемых IANA значений, чтобы не было проблем при демультиплексировании (см. раздел 14). Реализации могут демультиплексировать записи DTLS 1.3, проверяя первый байт, как описано ниже.

  • Если первый байт — это alert(21), handshake(22) или ack(proposed, 26), запись должна считаться DTLSPlaintext.

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

  • В противном случае запись должна отвергаться как при отказе снятия защиты (см. параграф 4.5.2).

На рисунке 5 демультиплексирование представлено с учётом DTLS 1.3 и более ранних версий DTLS.

           +----------------+
           | Outer Content  |
           |   Type (OCT)   |
           |                |
           |   OCT == 20   -+--> ChangeCipherSpec (DTLS <1.3)
           |   OCT == 21   -+--> Alert (Plaintext)
           |   OCT == 22   -+--> DTLSHandshake (Plaintext)
           |   OCT == 23   -+--> Application Data (DTLS <1.3)
           |   OCT == 24   -+--> Heartbeat (DTLS <1.3)
Пакет -->  |   OCT == 25   -+--> DTLSCiphertext with CID (DTLS 1.2)
           |   OCT == 26   -+--> ACK (DTLS 1.3, Plaintext)
           |                |
           |                |   /+-----------------+\
           | 31 < OCT < 64 -+--> |DTLSCiphertext   |
           |                |    |(биты заголовка  |
           |     иначе      |    |начинаются с 001)|
           |       |        |   /+-------+---------+\
           +-------+--------+            |
                   |                     |
                   v         Расшифровка |
             +---------+          +------+
             |  Reject |          |
             +---------+          v
                          +----------------+
                          | Decrypted      |
                          | Content Type   |
                          | (DCT)          |
                          |                |
                          |     DCT == 21 -+--> Alert
                          |     DCT == 22 -+--> DTLSHandshake
                          |     DCT == 23 -+--> Application Data
                          |     DCT == 24 -+--> Heartbeat
                          |     DCT == 26 -+--> ACK
                          |     иначе -----+--> Error
                          +----------------+

Рисунок 5. Демультиплексирование записей DTLS 1.2 и DTLS 1.3.


4.2. Порядковый номер и эпоха

DTLS использует явный или частично явный порядковый номер вместо неявного, передавая его в поле записи sequence_number. Порядковые номера поддерживаются раздельно для каждой эпохи, начиная с sequence_number=0.

Для номера эпохи исходно устанавливается значение 0, а затем номер инкрементируется при каждом обновлении ключевого материала, когда отправитель хочеть заменить ключи (см. 6.1. Значения эпохи и смена ключей).

4.2.1. Рекомендации по обработке

Поскольку порядок записей DTLS может быть изменен, запись из эпохи M может быть получена после начала эпохи N (N > M). Реализациям следует отбрасывать записи из более ранних эпох, но можно сохранять ключевой материал предыдущих эпох в течение принятого по умолчанию интервала MSL для TCP [RFC0793], чтобы принять пакеты с нарушенным порядком. Отметим, что намерение здесь заключается в использовании текущих рекомендаций IETF для MSL, как указано в [RFC0793] или его преемниках, а не в попытке получить значение MSL, применяемое стеком TCP.

Записи, защищённые с новой эпохой, могут приходить до завершения согласования. Например, сервер может передать своё сообщение Finished и после этого начать передачу данных. Реализации могут буферизовать или отбрасывать такие записи, хотя при использовании DTLS с надёжным транспортом (например, SCTP [RFC4960]), им следует буферизовать записи и обрабатывать их по завершении согласования. Отметим, что ограничения TLS для времени отправки записей сохраняются здесь и получатель обрабатывает такие записи как при получении в корректном порядке.

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

Реализация должна разорвать ассоциацию или поменять ключи до достижения максимального порядкового номера.

Реализациям недопустимо переносить (wrap) эпоху, вместо этого должна создаваться новая ассоциация с разрывом прежней.

4.2.2. Восстановление порядкового номера и эпохи

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

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

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

4.2.3. Шифрование номера записи

В DTLS 1.3 при шифровании записи шифруется и её порядковый номер. Базовый алгоритм шифрования, используемый AEAD, служит для создания маски, которая применяется в операции XOR с порядковым номером. Когда в AEAD применяется алгоритм AES, маска создаётся путём расчёта AES-ECB для первых 16 байтов шифроданных

     Mask = AES-ECB(sn_key, Ciphertext[0..15])

При использовании в AEAD алгоритма ChaCha20 маска создаётся путём использования первых 4 байтов шифроданных как счётчика блоков, а следующих 12 байтов — как nonce с передачей блочной функции ChaCha20 (см. параграф 2.3 в [CHACHA])

     Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])

Значение sn_key определяется выражением

     [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)

где [sender] указывает передающую сторону. Значение Secret для каждой эпохи применяется в соответствии с параграфом Section 7.3 в [TLS13]. Отметим, что для каждой эпохи применяется новый ключ, а поскольку epoch передаётся в открытом виде, неоднозначности не возникает.

Зашифрованный порядковый номер рассчитывается с помощью операции XOR для начальных байтов маски и представляемого в линию порядкового номера. Расшифровка выполняется таким же способом.

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

Будущие шифронаборы, не основанные на AES или ChaCha20, должны задавать своё шифрование порядковых номеров при использовании с DTLS.

Отметим, что шифрование порядковых номеров применяется лишь к структуре DTLSCiphertext, а номера в DTLSPlaintext не шифруются.

4.3. Отображение транспортного уровня

Сообщения DTLS могут фрагментироваться на несколько записей DTLS. Каждая запись DTLS должна помещаться в одну дейтаграмму. Для предотвращения фрагментации IP клиентам уровня записи DTLS следует пытаться устанавливать размер записей так, чтобы они помещались в пакет размером Path MTU (PMTU), оценка которого получена от уровня записи (см. 4.4. Проблемы PMTU).

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

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

Некоторые транспортные протоколы, такие как DCCP [RFC4340], используют свои порядковые номера. При использовании такого транспорта будет присутствовать 2 порядковых номера (DTLS и транспорт). Хотя это несколько снижает эффективность, номера в DTLS и транспорте служат разным целям, поэтому для концептуальной простоты сохранены оба номера.

Некоторые транспортные протоколы поддерживают контроль перегрузок для передаваемого трафика. Если окно перегрузки достаточно мало, повторы передачи при согласовании DTLS могут быть задержаны, что может приводить к тайм-аутам и ненужным повторам передачи. При использовании DTLS с таким транспортом следует соблюдать осторожность, чтобы не выйти за рамки вероятного окна перегрузки. В [RFC5238] описано отображение DTLS на DCCP с учётом этой проблемы.

4.4. Проблемы PMTU

В общем случае DTLS оставляет определение PMTU за приложениями, однако DTLS не может полностью игнорировать PMTU по трём причинам:

  • «кадрирование» записей DTLS увеличивает размер дейтаграмм, снижая эффективное значение PMTU для приложений;

  • в некоторых реализациях приложения не могут напрямую обращаться к сети, поэтому стек DTLS может получать сообщения ICMP Datagram Too Big [RFC1191] или ICMPv6 Packet Too Big [RFC4443];

  • размер согласующих сообщений DTLS может превышать PMTU.

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

  • для DTLS на основе UDP вышележащему протоколу следует разрешать получение оценки PMTU от уровня IP;

  • для DTLS на основе DCCP вышележащему протоколу следует разрешать получение текущей оценки PMTU;

  • для DTLS на основе TCP или SCTP, которые автоматически фрагментируют и собирают дейтаграммы, нет ограничений PMTU. Однако вышележащему уровню недопустимо делать записи размером более 214 байтов.

Уровню записи DTLS следует также разрешать вышележащему протоколу определять величину расширения записи при обработке DTLS или он может сообщать вышележащему уровню значение PMTU от транспортного уровня за вычетом размера кадрирования записей DTLS.

Отметим, что в DTLS нет защиты от поддерльных сообщений ICMP и реализациям следует игнорировать такие сообщения, которые указывают PMTU ниже минимума для IPv4 и IPv6 — 576 и 1280 байтов, соответственно.

При наличии индикации транспортного уровня о превышении PMTU (через ICMP или отказ от передачи дейтаграммы, как указано в разделе 14 [RFC4340]) уровень записи DTLS должен информировать вышележащий уровень об ошибке.

Уровню записи DTLS не следует мешать вышележащим протоколам определять PMTU через [RFC1191] и [RFC4821] для IPv4 или через [RFC8201] для IPv6. В частности,

  • если позволяет базовый транспорт, вышележащему протоколу следует разрешать устанавливать бит запрета фрагментирования (Don’t Fragment или DF) для IPv4 или запрещать локальную фрагментацию для IPv6;

  • если базовый транспорт (например, DCCP) разрешает приложению запрашивать зондирование PMTU, уровню записи DTLS следует удовлетворять такие запросы.

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

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

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

4.5. Защита содержимого записи

Подобно TLS, протокол DTLS передаёт данные в форме последовательности защищённых записей, как описано ниже.

4.5.1. Предотвращение повторного использования

В каждой записи DTLS имеется порядковый номер для защиты от повторного использования (replay). Проверку порядковых номеров следует проводить с использованием описанной ниже процедуры скользящего окна, заимствованной из параграфа 3.4.3 в [RFC4303]. Поскольку в каждой эпохе нумерация записей начинается заново, для каждой эпохи требуется своё скользящее окно.

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

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

«Правый» край окна представляет наибольший проверенный номер, полученный в данной эпохе. Записи с номерами меньше «левого» края окна отвергаются. Записи с номерами, попадающими в окно, проверяются ещё раз по списку полученных записей из этого окна. Эффективным способом этой проверки служит использование битовой маски, как описано в параграфе 3.4.3 [RFC4303]. Если запись попадает в окно и является новой (не дубликат) или находится правей окна, она считается новой.

Окно недопустимо обновлять по принятой записи, пока с неё не будет снята защита.

4.5.2. Обработка недействительных записей

В отличие от TLS, протокол DTLS устойчив к непригодным записям (например, с некорректным форматом, размером, MAC и т. п.). В общем случае непригодные записи следует просто отбрасывать, сохраняя ассоциацию, однако ошибки можно фиксировать в системном журнале для диагностики. Реализации, решившие при этом выдавать предупреждения, должны генерировать критические предупреждения, чтобы избежать атак, где злоумышленник неоднократно проверяет реализацию, чтобы понять её реагирование на разные типы ошибок. Отметим, что при работе DTLS по протоколу UDP поступающая так реализация будет очень чувствительна к DoS-атакам, поскольку подделка UDP очень проста. Поэтому генерация критических предупреждений не рекомендуется для такого транспорта в качестве средства повышения надёжности сервиса DTLS и исключения риска атак с передачей поддельного трафика посторонним узлам.

Если DTLS работает на основе устойчивого к подделкам трафика (например, SCTP с SCTP-AUTH), безопасней передавать оповещения, поскольку атакующему будет очень сложно подделать дейтаграмму, которую транспортный уровень не отвергнет.

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

4.5.3. Ограничения AEAD

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

В [TLS13] не задано ограничений для AEAD_AES_128_CCM, но анализ в Приложении B показывает, что можно использовать предел в 223 пакетов для обеспечения такой же защиты конфиденциальности, какая задана в TLS.

Ограничения на использование, заданные в TLS 1.3, относятся к защите от атак на конфиденциальность и применяются к успешным применениям защиты AEAD. Защита целостности при аутентифицированном шифровании зависит от ограничения числа попыток подделки пакетов. TLS обеспечивает это путём закрытия соединений после отказа при проверки подлинности любой из записей. DTLS игнорирует невозможность аутентифицировать пакет, разрешая множественные попытки подделки.

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

Для AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_CHACHA20_POLY1305 предельным числом пакетов с отказом при аутентификации является 236. Отметим, что анализ [AEBounds] даёт большее значение для AEAD_AES_128_GCM и AEAD_AES_256_GCM, но эта спецификация рекомендует более жёсткое ограничение. Для AEAD_AES_128_CCM установлен предел числа не прошедших аутентификацию пакетов 223,5 (см. Приложение B).

Для AEAD_AES_128_CCM_8 AEAD, используемого в TLS_AES_128_CCM_8_SHA256, не задано ограничение для числа записей, не прошедших аутентификацию, что повышает вероятность подделки и создаёт для реализации риска DoS-атак (см. Приложение B.3). Поэтому TLS_AES_128_CCM_8_SHA256 недопустимо применять в DTLS без дополнительной защиты от подделок. Реализации должны задавать пределы использования AEAD_AES_128_CCM_8 с учётом применяемых дополнительных механизмов защиты от подделок.

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

5. Протокол согласования DTLS Handshake

DTLS 1.3 использует согласующие сообщения и потоки TLS 1.3 с указанными ниже изменениями.

  1. Для обработки потерь, нарушения порядка и фрагментации нужно изменить заголовок согласования.

  2. Добавлены таймеры повторной передачи для обработки потери пакетов.

  3. Добавлен тип содержимого ACK для надёжной доставки согласующих сообщений.

Кроме того, DTLS использует расширение TLS 1.3 cookie для проверки маршрутизации по пути возврата в процессе организации соединения. Это важный механизм предотвращения DoS-атак для протоколов на основе UDP в отличие от протоколов на основе TCP, где такую проверку обеспечивает протокол TCP в процессе организации соединения.

Реализации DTLS не используют режим совместимости TLS 1.3 (compatibility mode), описанный в Приложении D.4 к [TLS13]. Серверам DTLS недопустимо возвращать (echo) значение legacy_session_id, полученное от клиента, а конечным точкам недопустимо передавать сообщения ChangeCipherSpec.

В остальном формат сообщений, потоки и логика DTLS не отличаются от применяемых в TLS 1.3.

5.1. Противодействие DoS-атакам

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

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

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

Чтобы противостоять обоим типам атак DTLS заимствует метод cookie из Photuris [RFC2522] и IKE [RFC7296]. Когда клиент передаёт своё сообщение ClientHello серверу, тот может ответить сообщением HelloRetryRequest. Это сообщение и расширение cookie определены в TLS 1.3. HelloRetryRequest содержит не учитывающее состояние значение cookie (см. параграф 4.2.2 в [TLS13]). Клиент должен передать новое сообщение ClientHello, добавив cookie как расширение. Сервер проверяет cookie и при совпадении выполняет согласование. Этот механизм заставляет клиента или злоумышленника принять cookie, сто осложняет DoS-атаки с подменой адресов IP. Механизм не обеспечивает защиты от DoS-атак, организованных с действительных адресов IP.

Спецификация DTLS 1.3 меняет способ обмена cookie по сравнению с DTLS 1.2. В DTLS 1.3 используется сообщение HelloRetryRequest, передающее значение cookie клиенту через расширение. Принявший cookie клиент использует это же расширение для включения cookie в последующее сообщение ClientHello. В DTLS 1.2 применяется отдельное сообщение HelloVerifyRequest для передачи cookie клиенту без использования расширений. Для совместимости с прежними версиями поле cookie в ClientHello протокола DTLS 1.3 присутствует, но игнорируется поддерживающими DTLS 1.3 реализациями серверов.

Процесс обмена показан на рисунке 6 с указанием лишь cookie (без других расширений).

Клиент                                   Сервер
------                                   ------
ClientHello           ------>
                      <-----  HelloRetryRequest
                              + cookie
ClientHello           ------>
 + cookie
[Продолжение согласования]

Рисунок 6. Обмен DTLS с сообщением HelloRetryRequest, содержащим cookie.


Расширение cookie определено в параграфе 4.2.2 [TLS13]. При передаче начального ClientHello у клиента ещё нет cookie. В этом случае расширение опускается и в поле legacy_cookie сообщение ClientHello должен указываться вектор размера 0 (1 байт в поле размера со значением 0). При ответе на HelloRetryRequest клиент должен создать новое сообщение ClientHello в соответствии с параграфом 4.1.2 в [TLS13].

При использовании HelloRetryRequest начальное сообщение ClientHello и HelloRetryRequest включаются в расчёт хэша «стенограммы» (transcript). Расчёт хэша сообщения HelloRetryRequest выполняется в соответствии с параграфом 4.4.1 в [TLS13]. Стенограмма согласования не сбрасывается при получении второго ClientHello и реализация серверного cookie без учёта состояния требует сохранения содержимого или хэш-значения исходного ClientHello (и HelloRetryRequest) в cookie. Исходное сообщение ClientHello включается в стенограмму согласования как синтетическое сообщение message_hash, поэтому для завершения согласования нужно лишь хэш-значение, хотя требуется полное содержимое HelloRetryRequest. При получении второго ClientHello сервер может проверить cookie и возможности получения клиентом пакетов по данному адресу IP. Если видимый IP-адрес встроен в cookie, это не позволит атакующему создать приемлемое сообщение ClientHello от другого пользователя.

При такой схеме возможна атака, где злоумышленник собирает много значений cookie с разных адресов, где он контролирует конечные точки, а затем может использовать их для атаки на сервер. Сервер может защититься от такой атаки, часто меняя значение секрета, что сделает собранные cookie непригодными. Если сервер хочет разрешить легитимным клиентам согласование через смену секрета (например, клиент получает cookie с Secret 1, затем передаёт второе сообщение ClientHello уже после перехода сервера на Secret 2), он может задать ограниченное окно, в котором воспринимаются оба секрета. В [RFC7296] предложено добавлять в таких случаях идентификатор ключа в cookie. Другим вариантом является просто проверка для обоих секретов. Серверам рекомендуется реализовать схему ротации ключей, которая позволит поддерживать ключи с перекрывающимися сроками действия. Как вариант, сервер может включать в cookie временную метку и отвергать cookie, созданные вне заданного интервала времени.

Серверам DTLS следует выполнять обмен cookie при каждом новом согласовании. Если сервер работает в среде, где атаки с усилением не создают проблем, например, используется ICE [RFC8445] для организации двухсторонней связности, сервер может отключить обмен cookie, однако этого не следует делать по умолчанию. Кроме того, сервер может отказаться от обмена cookie при возобновлении сессии, или, в более общем случае, при согласовании DTLS с применением обмена ключами на основе PSK и совпадении IP-адреса с одним из связанных с PSK. Серверы, обрабатывающие запросы 0-RTT и передающие отклики 0.5-RTT без обмена cookie, рискуют быть вовлечёнными в атаки с усилением, если размер исходящих сообщений существенно превышает размер получаемых. Серверу следует ограничивать объем данных, передаваемых по адресу клиента трёхкратным размером переданных клиентом данных, пока сервер не будет уверен, что клиент способен принимать данные по этому адресу. Адрес клиента считается действительным после обмена cookie или завершения согласования. Клиенты должны быть готовы к обмену cookie при каждом согласовании. Отметим, что cookie действительны только в текущем согласовании и негодны для будущих.

Если сервер получает ClientHello с недействительным cookie, он должен прервать согласование с сигналом illegal_parameter. Это позволит клиенту перезапустить попытку соединения без cookie.

Как описано в параграфе 4.1.4 [TLS13], клиенты должны прерывать согласование с сигналом unexpected_message при получении второго сообщения HelloRetryRequest в том же соединении (т. е. когда сообщение ClientHello было ответом на HelloRetryRequest).

Клиентам DTLS, не желающим получать Connection ID, следует все равно предлагать расширение connection_id [RFC9146], пока профиль соединения не указывает иное. Это позволит серверу, желающему получать CID, согласовать это.

5.2. Формат сообщений DTLS Handshake

В DTLS применяются такие же сообщения Handshake как в TLS 1.3, однако перед отправкой их нужно преобразовать в DTLSHandshake с дополнительными данными для обработки потерь, изменения порядка и фрагментации.

       enum {
           client_hello(1),
           server_hello(2),
           new_session_ticket(4),
           end_of_early_data(5),
           encrypted_extensions(8),
           request_connection_id(9),           /* Новое */
           new_connection_id(10),              /* Новое */
           certificate(11),
           certificate_request(13),
           certificate_verify(15),
           finished(20),
           key_update(24),
           message_hash(254),
           (255)
       } HandshakeType;

       struct {
           HandshakeType msg_type;    /* Тип согласования */
           uint24 length;             /* Число байтов в сообщении */
           uint16 message_seq;        /* Требуемое DTLS поле */
           uint24 fragment_offset;    /* Требуемое DTLS поле */
           uint24 fragment_length;    /* Требуемое DTLS поле */
           select (msg_type) {
               case client_hello:          ClientHello;
               case server_hello:          ServerHello;
               case end_of_early_data:     EndOfEarlyData;
               case encrypted_extensions:  EncryptedExtensions;
               case certificate_request:   CertificateRequest;
               case certificate:           Certificate;
               case certificate_verify:    CertificateVerify;
               case finished:              Finished;
               case new_session_ticket:    NewSessionTicket;
               case key_update:            KeyUpdate;
               case request_connection_id: RequestConnectionId;
               case new_connection_id:     NewConnectionId;
           } body;
       } DTLSHandshake;

В DTLS 1.3 стенограмма (transcript) сообщения рассчитывается для исходного сообщения TLS 1.3 Handshake без полей message_seq, fragment_offset, fragment_length. Это отличается от DTLS 1.2, где поля учитывались.

Первое сообщение, которая каждая из сторон передаёт в каждой ассоциации, имеет message_seq = 0, а при создании нового сообщения значение message_seq увеличивается на 1. При повторной передаче сообщения используется прежний номер без инкрементирования. С точки зрения уровня записи DTLS повторная передача является новой записью и эта запись будет иметь новое значение DTLSPlaintext.sequence_number.

Примечание. В DTLS 1.2 значение message_seq сбрасывается в 0 при повторном согласовании. На первый взгляд повторное согласование в DTLS 1.2 похоже на обмен после согласования (post-handshake) в DTLS 1.3, однако в DTLS 1.3 message_seq не сбрасывается, что позволяет отличить повтор ранее переданного post-handshake от переданного недавно.

Реализации DTLS поддерживают (хотя бы номинально) счётчик next_receive_seq, для которого изначально устанавливается значение 0. Если При получении согласующего сообщения message_seq в нем совпадает с next_receive_seq, значение next_receive_seq увеличивается и сообщение обрабатывается. Если номер меньше next_receive_seq, сообщение должно отбрасываться, если же номер больше next_receive_seq, реализации следует поместить сообщение в очередь, но можно и отбросить (компромисс между ресурсами и пропускной способностью).

Кроме согласующих сообщений, отменённых спецификацией TLS 1.3, DTLS 1.3 отменяет HelloVerifyRequest, заданное исходно в DTLS 1.0. Совместимым с DTLS 1.3 реализациям недопустимо применять HelloVerifyRequest для проверки обратного маршрута. Клиенты с поддержкой DTLS 1.2 и DTLS 1.3 должны быть готовы взаимодействовать с серверами DTLS 1.2.

5.3. Сообщение ClientHello

Формат сообщений ClientHello в DTLS 1.3 отличается от применяемого в TLS 1.3 и показан ниже.

       uint16 ProtocolVersion;
       opaque Random[32];

       uint8 CipherSuite[2];    /* Селектор шифронабора */

       struct {
           ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
           Random random;
           opaque legacy_session_id<0..32>;
           opaque legacy_cookie<0..2^8-1>;               // DTLS
           CipherSuite cipher_suites<2..2^16-2>;
           opaque legacy_compression_methods<1..2^8-1>;
           Extension extensions<8..2^16-1>;
       } ClientHello;

legacy_version

В прежних версиях DTLS это поле служило для согласования версии и указывало наибольшую версию, поддерживаемую клиентом. Опыт показал, что многие серверы не реализуют корректно согласование версий, что вело к «неприемлемости версии», когда сервер отвергал в остальном верные сообщения ClientHello, где указан номер версии выше поддерживаемого сервером. В DTLS 1.3 клиент указывает свои предпочтения версии в расширении supported_versions (см. параграф 4.2.1 в [TLS13]), а в поле legacy_version должно быть указано значение {254, 253}, которое было номером версии в DTLS 1.2. Записи supported_versions для DTLS 1.0 и DTLS 1.2 имеют значения 0xfeff и 0xfefd (чтобы соответствовать версии в линии). Значение 0xfefc указывает DTLS 1.3.

random

Как в TLS 1.3, за исключением того, что индикаторы версий, описанные в параграфе 4.1.3 [TLS13] для согласования с TLS 1.2, TLS 1.1 и ниже, применяются к DTLS 1.2 и DTLS 1.0, соответственно.

legacy_session_id

В TLS и DTLS до версии 1.3 поддерживалась функция восстановления сессии (session resumption), которая была объединена с PSK (pre-shared key) в версии 1.3. Клиенту с кэшированным идентификатором сессии, установленным сервером до DTLS 1.3, следует установить в этом поле данное значение. В иных случаях он должен указать в поле вектор нулевого размера (1-байтовое поле со значением 0).

legacy_cookie

Клиент, поддерживающий только DTLS 1.3, должен указывать поле legacy_cookie с размером 0. Если сообщение DTLS 1.3 ClientHello получено с иным значением этого поля, сервер должен прервать согласование с сигналом illegal_parameter.

cipher_suites

Как в TLS 1.3. Можно применять только шифры с DTLS-OK=Y.

legacy_compression_methods

Как в TLS 1.3.

extensions

Как в TLS 1.3.

5.4. Сообщение ServerHello

Сообщение DTLS 1.3 ServerHello отличается от TLS 1.3 лишь полем legacy_version = 0xfefd, указывающим DTLS 1.2.

5.5. Фрагментация и сборка сообщений Handshake

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

При передаче согласующего сообщения отправитель делит его на N смежных блоков данных, перекрытие которых недопустимо. Затем отправитель создаёт N сообщений DTLSHandshake, указывая в каждом то же значение message_seq, что и в исходном DTLSHandshake. В каждом новом сообщении указываются значения fragment_offset (число байтов, содержащихся в предыдущих фрагментах) и fragment_length (размер данного фрагмента). Поля length в каждом сообщении совпадают с полем length в исходном сообщении. Нефрагментированное сообщение является вырожденным случаем с fragment_offset=0 и fragment_length=length. Затем каждый фрагмент согласующего сообщения, помещённый в запись, должен быть доставлен в одной дейтаграмме UDP.

Когда реализация DTLS получает фрагмент согласующего сообщения, соответствующий ожидаемому порядковому номеру согласующего сообщения, она должна обработать фрагмент, буферизуя его в ожидании остальных фрагментов или сразу обрабатывая упорядоченные части сообщения. «Стенограмма» (transcript) включает полные сообщения TLS Handshake (собранные из фрагментов при необходимости). Отметим, что поля message_seq, fragment_offset, fragment_length удаляются при создании структуры Handshake.

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

Отметим, что как в TLS, в одну запись DTLS можно поместить несколько согласующих сообщений, если для них имеется место и они относятся к одной отправке (flight). Таким образом, два согласующих сообщения DTLS могут передаваться в одной или раздельных записях.

5.6. Сообщение EndOfEarlyData

Согласование DTLS 1.3 имеет одно важное отличие от согласования TLS 1.3 — сообщение EndOfEarlyData отсутствует как в линии, так и в стенограмме согласования. Поскольку записи DTLS включают эпоху, EndOfEarlyData не требуется для определения завершения ранних данных, а возможность потерь в DTLS позволяет злоумышленникам тривиально организовать атаки с удалением, которые EndOfEarlyData предотвращает в TLS. Серверам не следует воспринимать записи из эпохи 1 бесконечно, как только они смогут обрабатывать записи из эпохи 3. Хотя нарушение порядка пакетов IP может приводить к прибытию записей из эпохи 1 после записей эпохи 3, это не может длиться долго по сравнению с временем кругового обхода. Сервер может отбросить ключи эпохи 1 после прихода первых данных эпохи 3 или сохранять в течение короткого времени для обработки записей эпохи 1 (см. 6.1. Значения эпохи и смена ключей).

5.7. Отправки сообщений DTLS Handshake

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

Таблица 1. Комбинации сообщений Handshake, создающих отправку (flight).

 

Клиент

Сервер

Сообщения Handshake

x

ClientHello

x

HelloRetryRequest

x

ServerHello, EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished

x4

Certificate, CertificateVerify, Finished

x1

NewSessionTicket

 

Необязательные сообщения в таблице 1 не выделены.

Ниже дано несколько примеров обмена, иллюстрирующих отправку с применением нотации [TLS13].

Клиент                                            Сервер 
                                                           +--------+
 ClientHello                                               | Flight |
                       -------->                           +--------+

                                                           +--------+
                       <--------        HelloRetryRequest  | Flight |
                                         + cookie          +--------+

                                                           +--------+
ClientHello                                                | Flight |
 + cookie              -------->                           +--------+

                                              ServerHello
                                    {EncryptedExtensions}  +--------+
                                    {CertificateRequest*}  | Flight |
                                           {Certificate*}  +--------+
                                     {CertificateVerify*}
                                               {Finished}
                       <--------     [Данные приложения*]
 {Certificate*}                                            +--------+
 {CertificateVerify*}                                      | Flight |
 {Finished}            -------->                           +--------+
 [Данные приложения]
                                                           +--------+
                       <--------                    [ACK]  | Flight |
                                     [Данные приложения*]  +--------+

 [Данные приложения]   <------->     [Данные приложения]

Рисунок 7. Отправка для полного согласования (с обменом Cookie).

Клиент                                            Сервер
    ClientHello                                              +--------+
     + pre_shared_key                                        | Flight |
     + psk_key_exchange_modes                                +--------+
     + key_share*         -------->

                                                ServerHello
                                           + pre_shared_key  +--------+
                                               + key_share*  | Flight |
                                      {EncryptedExtensions}  +--------+
                          <--------              {Finished}
                                       [Данные приложения*]
                                                             +--------+
    {Finished}            -------->                          | Flight |
    [Данные приложения*]                                     +--------+

                                                             +--------+
                          <--------                   [ACK]  | Flight |
                                       [Данные приложения*]  +--------+

    [Данные приложения]   <------->     [Данные приложения]

Рисунок 8. Отправка для возобновления и согласования PSK (без Cookie).

Клиент                                            Сервер
 ClientHello
  + early_data
  + psk_key_exchange_modes                                +--------+
  + key_share*                                            | Flight |
  + pre_shared_key                                        +--------+
 (Данные приложения*)    -------->

                                             ServerHello
                                        + pre_shared_key
                                            + key_share*  +--------+
                                   {EncryptedExtensions}  | Flight |
                                              {Finished}  +--------+
                       <--------    [Данные приложения*]

                                                          +--------+
 {Finished}            -------->                          | Flight |
 [Данные приложения*]                                     +--------+

                                                          +--------+
                       <--------                   [ACK]  | Flight |
                                    [Данные приложения*]  +--------+

 [Данные приложения]   <------->     [Данные приложения]

Рисунок 9. Отправка для согласования 0-RTT.

Клиент                                            Сервер
                                                          +--------+
                       <--------       [NewSessionTicket] | Flight |
                                                          +--------+

                                                          +--------+
[ACK]                  -------->                          | Flight |
                                                          +--------+

Рисунок 10. Отправка сообщения NewSessionTicket.

KeyUpdate, NewConnectionId, RequestConnectionId следуют схеме, похожей на NewSessionTicket, — одна сторона передаёт единственное сообщение, другая возвращает ACK.

5.8. Тайм-ауты и повтор передачи

5.8.1. Конечный автомат

DTLS использует простую схему с тайм-аутом и повтором передачи, конечный автомат которой показан на рисунке 11.

                       +-----------+
          +----------> | PREPARING |
          |            +-----------+
          |                  |
          |                  | Буфер следующей отправки
          |                  |
          |                 \|/
          |            +-----------+
          |            |  SENDING  |<-----------------------+
          |            +-----------+                        |
    Приём |                  |                              |
следующей |                  | Передача полно или           |
 отправки |                  | частичной отправки           |
          |                  |                              |
          |                  | Установка таймера повтора    |
          |                 \|/                             |
          |            +-----------+                        |
          +------------|  WAITING  |------------------------+
          |     +----->|           |Отсчёт таймера завершён |
          |     |      +-----------+                        |
          |     |          |  |   |                         |
          |     |          |  |   |                         |
          |     +----------+  |   +-------------------------+
          |    Приём записи   |   Чтение повтора или ACK
    Приём |(возможно Send ACK)|
последней |                   |
 отправки |                   | Приём ACK
          |                   | для последней отправки
         \|/                  |
      +-----------+           |
      |           | <---------+
      | FINISHED  |
      |           |
      +-----------+
          |  /|\
          |   |
          +---+
Сервер прочёл повтор Retransmit ACK

Рисунок 11. Конечный автомат тайм-аутов и повтора передачи DTLS.


Конечный автомат имеет 4 базовых состояния PREPARING, SENDING, WAITING, FINISHED.

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

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

Из состояния WAITING возможны 4 варианта выхода, описанных ниже.

  1. Завершение отсчёта таймера повтора — реализация переходит в состояние SENDING, повторяет отправку, корректирует и запускает таймер повтора (5.8.2. Значения таймеров) и возвращается в состояние WAITING.

  2. Получение ACK от партнёра — при ACK для частичной отправки (7.1. Передача ACK) реализация переходит в состояние SENDING, повторяет неподтвержденную часть отправки, корректирует и снова запускает таймер повтора и возвращается в состояние WAITING. Если ACK подтверждает всю отправку, реализация отбрасывает в повторы и возвращается в состояние WAITING или, если ACK подтверждает финальную отправку, — в состояние FINISHED.

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

  4. Реализация получает часть или все сообщения следующей отправки — если это финальная отправка сообщений, реализация переходит в состояние FINISHED. Если реализации нужно передать новую отправку, она переходит в состояние PREPARING. Частично считывание (частичные сообщения или часть сообщений отправки) могут вызывать передачу реализацией сообщения ACK, как описано в параграфе 7.1.

Поскольку клиент DTLS передаёт первое сообщение (ClientHello), он начинает с состояния PREPARING. Серверы DTLS начинают с состояния WAITING, но с пустыми буферами и без таймера повтора.

Сервер в состоянии FINISHED должен отвечать на повторы передачи финальной отправки от клиента повтором подтверждения ACK в течение по меньшей мере удвоенного интервала MSL5 [RFC0793].

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

5.8.2. Значения таймеров

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

Если у реализации нет специфичной для развёртывания или внешних условий информации о времени кругового обхода, ей следует использовать для таймера исходное значение 1000 мсек (1 секунда) и удваивать его при каждом повторе передачи, вплоть до значения по меньшей мере 60 секунд (максимум, заданный в RFC 6298 [RFC6298]). Профили приложений могут рекомендовать другие значения, например, как указано ниже.

  • Профили для конкретных сред развёртывания, таких как mesh-структуры со множеством пересылок (multi-hop) и слабым электропитанием, применяемых для IoT6, можно задавать более долгий тайм-аут. Более подробное описание профиля DTLS 1.3 IoT приведено в [IOT-PROFILE].

  • Протоколы, работающие в реальном масштабе времени, могут задавать более короткий тайм-аут. Для DTLS-SRTP [RFC5764] рекомендуется устанавливать по умолчанию 400 мсек, поскольку качество обслуживания клиентов снижается при односторонней задержке более 200 мсек и в таких системах столь длинные задержки маловероятны.

При наличии внешних сведений от RTT (например, от согласования ICE [RFC8445] или прежних соединений с тем же сервером) реализации следует устанавливать для таймера повтора передачи значение 1,5*RTT.

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

Поскольку повтор передачи предназначен для согласования, а не для потока данных, влияние коротких тайм-аутов на перегрузку меньше, чем в протоколах общего назначения, вроде TCP или QUIC. Опыт применения DTLS 1.2, где применяется более простой подход с повтором всего по тайм-ауту (retransmit everything on timeout) на практике не вызывает серьёзных проблем с перегрузкой.

5.8.3. Отправка большого размера

В DTLS нет встроенных механизмов контроля перегрузок и скорости. Обычно это не является проблемой, поскольку сообщения, как правило, невелики. Однако некоторые сообщения, в частности, Certificate, могут быть достаточно большими. Если все сообщения в одной большой отправке передаются разом, это может перегрузить сеть. Лучше передать лишь часть отправки с передачей дополнительных сообщений после подтверждения. Было стандартизовано несколько расширений для снижения размера сообщений Certificate, например, расширение cached_info [RFC7924] и сжатие сертификата [RFC8879] и [RFC6066], определяющее расширение client_certificate_url, позволяющее клиентам DTLS передавать цепочку унифицированных указателей ресурсов (Uniform Resource Locator или URL) вместо своего сертификата.

Стеку DTLS не следует передавать более 10 в один приём.

5.8.4. Дублирование конечного автомата для сообщений после согласования

DTLS 1.3 использует указанные ниже категории сообщений после согласования (post-handshake).

  1. NewSessionTicket
  2. KeyUpdate
  3. NewConnectionId
  4. RequestConnectionId
  5. Post-handshake client authentication

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

Отправка нескольких экземпляров сообщений данной категории без завершений предшествующей транзакции разрешена лишь для некоторых категорий. В частности, сервер может передать сразу несколько сообщений NewSessionTicket, не ожидая ACK для переданных NewSessionTicket. Сервер может передать несколько сообщений CertificateRequest разом, не ожидая завершения предшествующих запросов аутентификации клиента. Однако недопустимо передавать сообщение KeyUpdate, NewConnectionId или RequestConnectionId, пока не подтверждено предыдущее сообщение того же типа.

Примечание. За исключением аутентификации клиента после согласования, которое включает согласующие сообщения в обоих направлениях, прочие сообщения post-handshake представляют собой одну отправку и соответствующие конечные автоматы у отправителя сводятся к ожиданию ACK и повтору исходного сообщения. В частности, отметим, что сообщение RequestConnectionId не требует от получателя передавать в ответ NewConnectionId и оба эти сообщения обрабатываются независимо.

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

5.9. Префикс криптографической метки

В параграфе 7.1 [TLS13] указано, что HKDF-Expand-Label использует префикс метки «tls13 «. Для DTLS 1.3 нужно указывать префикс «dtls13». Это позволяет различать ключи DTLS 1.3 и TLS 1.3. Отметим, что здесь нет пробела в конце, чтобы полный размер метки сохранялся в одной итерации хэша (DTLS на 1 символ длиннее, чем TLS).

5.10. Сообщения Alert

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

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

5.11. Организация новых ассоциаций с имеющимися параметрами

Если в DTLS пара клиент-сервер настроена так, что повторные соединения организуются с тем же квартетом адресов и портов, клиент может «молча» разорвать соединение и организовать другое с теми же параметрами (например, после перезагрузки). Сервер увидит это как новое согласование с epoch=0. В тех случаях, когда сервер считает, что у него есть ассоциация с данным квартетом адресов и портов, но при этом получает ClientHello с epoch=0, ему следует обработать новое согласование, но недопустимо разрушать имеющуюся ассоциацию, пока клиент не продемонстрирует достижимость путём завершения обмена cookie или полного согласования, включая доставку проверяемого сообщения Finished. После приёма корректного сообщения Finished сервер должен отказаться от прежней ассоциации во избежание конфликта между двумя действительными ассоциациями с перекрывающимися эпохами. Требование достижимости предотвращает атаки извне пути и вслепую для разрушения ассоциаций путём отправки поддельных сообщений ClientHello.

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

6. Пример согласования с тайм-аутом и повтором

Ниже приведён пример согласования с потерей пакетов и повтором передач. Отметим, что клиент передаёт пустое сообщение ACK, поскольку он может подтвердить запись Record 2, переданную сервером, лишь после того, как обработает сообщения из Record 0 для создания ключей эпохи 2, требуемых для шифрования и расшифровки сообщений из 2. В разделе 7. Сообщение ACK обоснованы детали такого взаимодействия. Для простоты на рисунке 12 не сбрасываются номера записей, поэтому Record 1 на деле является Epoch 2, Record 0 и т. п..

Клиент                                                Сервер
 Record 0                  -------->
 ClientHello
 (message_seq=0)

                             X<-----                 Record 0
                             (потеря)             ServerHello
                                              (message_seq=0)
                                                     Record 1
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)

                           <--------                 Record 2
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)

 Record 1                  -------->
 ACK []

                           <--------                 Record 3
                                                  ServerHello
                                              (message_seq=0)
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)

                           <--------                 Record 4
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)

 Record 2                  -------->
 Certificate
 (message_seq=1)
 CertificateVerify
 (message_seq=2)
 Finished
 (message_seq=3)

                           <--------               Record 5
                                                    ACK [2]

Рисунок 12. Пример обмена DTLS с потерей сообщения.

6.1. Значения эпохи и смена ключей

Получателю сообщения DTLS нужно выбрать корректный ключевой материал для обработки входящего сообщения. С учётом возможных потерь и нарушения порядка нужен идентификатор для определения шифронабора, применяемого для защиты содержимого записи. В DTLS для этого служит номер эпохи. В дополнение к заданным в TLS 1.3 этапам вывода ключей (раздел 7 в [TLS13]) получатель может пожелать сменить ключи в любой момент работы соединения. Поэтому он должен указать, что обновляет свои ключи, применяемые при передаче.

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

  • Эпоха 0 применяется с нешифрованными сообщениями DTLS — ClientHello, ServerHello, HelloRetryRequest.

  • Эпоха 1 применяется с сообщениями, защищёнными с ключами, выведенными из client_early_traffic_secret. Отметим, что эта эпоха пропускается, если клиент не предоставляет ранних данных.

  • Эпоха 2 применяется с сообщениями, защищёнными с помощью ключей, выведенных из [sender]_handshake_traffic_secret. Это сообщения, передаваемые в процессе начального согласования, такие как EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished. Отметим, что сообщения после согласования защищаются с подходящим ключом трафика и не относятся к этой категории.

  • Эпоха 3 применяется с сообщениями, защищёнными с ключами, выведенными из начального [sender]_application_traffic_secret_0. Это могут быть согласующие сообщения, такие как post-handshake (например, NewSessionTicket).

  • Эпохи от 4 до 264-1 служат для данных, защищённых с использованием ключей, выведенных из [sender]_application_traffic_secret_N (N>0).

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

Отметим, что номера эпохи не переходят через максимум (wrap). Если реализация DTLS достигла максимального номера эпохи, она должна разорвать соединение. Расчёт ключей для трафика описан в параграфе 7.3 [TLS13]. На рисунке 13 показаны номера эпох для примера согласования DTLS.

Клиент                                                Сервер
 Record 0
 ClientHello
 (epoch=0)
                            -------->
                                                     Record 0
                            <--------       HelloRetryRequest
                                                    (epoch=0)
 Record 1
 ClientHello                -------->
 (epoch=0)
                                                     Record 1
                            <--------             ServerHello
                                                    (epoch=0)
                                        {EncryptedExtensions}
                                                    (epoch=2)
                                                {Certificate}
                                                    (epoch=2)
                                          {CertificateVerify}
                                                    (epoch=2)
                                                   {Finished}
                                                    (epoch=2)
 Record 2
 {Certificate}              -------->
 (epoch=2)
 {CertificateVerify}
 (epoch=2)
 {Finished}
 (epoch=2)
                                                     Record 2
                            <--------                   [ACK]
                                                    (epoch=3)
 Record 3
 [Данные приложения]        -------->
 (epoch=3)
                                                     Record 3
                            <--------     [Данные приложения]
                                                    (epoch=3)

                     Спустя некоторое время ...
                     (обмен Post-Handshake)
                                                     Record 4
                            <--------      [NewSessionTicket]
                                                    (epoch=3)
 Record 4
 [ACK]                      -------->
 (epoch=3)

                     Спустя некоторое время ...
                         (смена ключей)
                                                     Record 5
                            <--------     [Данные приложения]
                                                    (epoch=4)
 Record 5
 [Данные приложения]        -------->
 (epoch=4)

Рисунок 13. Обмен DTLS со сведениями об эпохе.

7. Сообщение ACK

Сообщения ACK применяются конечными точками для указания принятых и обработанных записей согласования от другой стороны. ACK не является согласующим сообщением, а представляет собой отдельный тип содержимого с кодом 26. Это позволяет не включать ACK в стенограмму согласования. Отметим, что ACK можно передавать в одной дейтаграмме UDP с записями согласования.

       struct {
           RecordNumber record_numbers<0..2^16-1>;
       } ACK;

record_numbers

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

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

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

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

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

7.1. Передача ACK

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

  • Приём сообщения или фрагмента с нарушением порядка — не то сообщение, которое ожидалось следующим, или не та часть текущего сообщения.

  • Получение части отправки без получения сразу же остальной части (которая может быть в той же дейтаграмме). Одним из подходов является установка для таймера 1/4 текущего значения таймера повтора при получении первой части и передача ACK по завершении отсчёта. Значение 1/4 выбрано достаточно произвольно. С учётом оценки времени кругового обхода при согласовании DTLS (обычно очень грубой или принятой по умолчанию) любое значение будет приблизительным и неизбежно нужен компромисс между повторной передачей изи слишком активных подтверждений (ACK) и чрезмерно активным тайм-аутом. Для сравнения, алгоритмы QUIC на основе алгоритма восстановления потерь (параграф 6.1.2 в [RFC9002]) работают с задержкой в 1/3 тайм-аута повторной передачи.

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

  1. Отправки согласования, отличные от финальной отправки клиента в основном согласовании.

  2. CertificateRequest от сервера после согласования.

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

Примечание. Хотя некоторые сообщения post-handshake следуют шаблону запрос-отклик, это не обязательно предполагает получение. Например, сообщение KeyUpdate, переданное в ответ на KeyUpdate с request_update = update_requested, не подтверждает неявно предыдущее сообщение KeyUpdate, поскольку оба могли находится одновременно в сети.

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

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

7.2. Получение ACK

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

7.3. Обоснование решения

Сообщения ACK применяются в двух случаях:

  • при признаках нарушения или отсутствии продвижения (progress);

  • для индикации полного получения последней отправки в согласовании.

В первом случае применение ACK необязательно, поскольку партнёр повторит передачу в любом случае и ACK просто разрешает ускоренный или выборочный повтор, а не полный повтор всей отправки по тайм-ауту, как в прежних версиях DTLS. При использовании DTLS 1.3 в средах с потерями, таких как беспроводные сети со слабым питанием и протяжёнными радиоканалами, а также mesh-сети со слабым питанием рекомендуется применять ACK.

Во втором случае применение ACK обязательно для корректной работы протокола. Например, сообщение ACK, переданное клиентом на рисунке 13 подтверждает приём и обработку Record 4 (с сообщением NewSessionTicket) и при его отсутствии сервер будет повторять передачу NewSessionTicket, пока не будет достигнут предел числа повторов.

8. Обновление ключей

Как и в TLS 1.3, реализации DTLS 1.3 передают сообщение KeyUpdate, чтобы указать обновление своих ключей для передачи. Как и другие согласующие сообщения без «встроенного» отклика, KeyUpdate должны подтверждаться. Для упрощения реконструкции эпохи (4.2.2. Восстановление порядкового номера и эпохи) реализациям недопустимо передавать записи с новыми ключами или отправлять новое сообщение KeyUpdate, пока не подтверждено отправленное сообщение KeyUpdate (это позволит избежать излишних активных эпох).

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

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

На рисунке 14 показа обмен, иллюстрирующий обработку ACK для обновления ключей отправителем KeyUpdate, приводящего к смене эпохи.

Клиент                                                Сервер

      /-------------------------------------------\
     |                                             |
     |           Начальное согласование            |
      \-------------------------------------------/

 [Данные приложения]        -------->
 (epoch=3)

                            <--------      [Application Data]
                                                    (epoch=3)

      /-------------------------------------------\
     |                                             |
     |          Некоторое время спустя ...         |
      \-------------------------------------------/

 [Данные приложения]        -------->
 (epoch=3)

 [KeyUpdate]
 (+ update_requested        -------->
 (epoch 3)

                            <--------     [Данные приложения]
                                                    (epoch=3)

                                                        [ACK]
                            <--------               (epoch=3)

 [Данные приложения]
 (epoch=4)                  -------->

                            <--------             [KeyUpdate]
                                                    (epoch=3)

 [ACK]                      -------->
 (epoch=4)

                            <--------     [Данные приложения]
                                                    (epoch=4)

Рисунок 14. Пример обновления ключей DTLS.

При использовании 128-битового ключа, как в AES-128, смена ключей 264 раз ведёт к высокой вероятности повтора ключей в данном соединении. Отметим, что даже при повторе ключей вектор инициализации (IV) создаётся независимо. Для обеспечения запаса безопасности передающей реализации недопустимо допускать превышение номером эпохи значения 248-1. Для продолжения смены эпох принимающим реализациям недопустимо форсировать применение этого правила. Если передающая реализация получает KeyUpdate с request_update = update_requested, ей недопустимо передавать своё сообщение KeyUpdate, если это приведёт к превышению указанного предела, и следует игнорировать флаг update_requested. Отметим, что это отличается от правила TLS 1.3 всегда передавать KeyUpdate в ответ на update_requested.

9. Обновление CID

Если клиент и сервер согласовали расширение connection_id [RFC9146], любой из них может передать желаемое значение CID другой стороне в сообщении NewConnectionId.

       enum {
           cid_immediate(0), cid_spare(1), (255)
       } ConnectionIdUsage;

       opaque ConnectionId<0..2^8-1>;

       struct {
           ConnectionId cids<0..2^16-1>;
           ConnectionIdUsage usage;
       } NewConnectionId;

cids

Указывает набор CID, который отправитель предлагает использовать партнёру.

usage

Указывает, следует ли сразу же применять предложенные CID или они являются «запасными». Значение cid_immediate, указывает, что один из новых CID должен сразу же применяться для всех новых записей, значение cid_spare указывает, что можно использовать любой из имеющихся или новых CID.

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

Реализациям, которые не согласовали расширение connection_id или согласовали получение пустого CID, недопустимо передавать NewConnectionId. Реализациям недопустимо передавать RequestConnectionId при отправке пустого Connection ID. Реализация, заметившая нарушение этих правил, должна прервать соединение с сигналом unexpected_message.

Реализациям следует применять новый CID при отправке по новому пути, а также следует запрашивать новые CID, если предполагается изменение пути.

       struct {
         uint8 num_cids;
       } RequestConnectionId;

num_cids

Желаемое число CID.

Конечным точкам следует отвечать на RequestConnectionId передачей NewConnectionId с cid_spare, содержащим число идентификаторов num_cids, как можно скорее. Конечным точка недопустимо передавать RequestConnectionId, когда имеющийся запрос ещё не выполнен, это предполагало бы запрос новых CID заблаговременно. Конечная точка может отвечать на запросы, которые она считает избыточными, сообщением NewConnectionId, содержащим число CID меньше num_cids, вплоть до отсутствия. Конечные точки могут отвечать на избыточные сообщения RequestConnectionId разрывом соединения с сигналом too_many_cids_requested (alert 52).

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

9.1. Пример CID

Ниже приведён пример обмена для DTLS 1.3 с использованием 1 CID в каждом направлении.

Примечание. Расширение connection_id, применяемое в ClientHello и ServerHello, задано в [RFC9146].

Клиент                                                Сервер
ClientHello
(connection_id=5)
                            -------->

                            <--------       HelloRetryRequest
                                                     (cookie)

ClientHello                 -------->
(connection_id=5)
  + cookie

                            <--------             ServerHello
                                          (connection_id=100)
                                          EncryptedExtensions
                                                      (cid=5)
                                                  Certificate
                                                      (cid=5)
                                            CertificateVerify
                                                      (cid=5)
                                                     Finished
                                                      (cid=5)

Certificate                -------->
(cid=100)
CertificateVerify
(cid=100)
Finished
(cid=100)
                           <--------                      ACK
                                                      (cid=5)

Application Data           ========>
(cid=100)
                           <========        Данные приложения
                                                      (cid=5)

Рисунок 15. Пример обмена DTLS 1.3 с CID.

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

10. Протокол данных приложения

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

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

Вопросы безопасности в основном рассмотрены в [TLS13].

Дополнительные соображения безопасности при использовании DTLS связаны в основном с DoS-атаками за счёт избыточного расхода ресурсов. DTLS включает обмен cookie, предназначенный для защиты от таких атак. Однако реализации, не применяющие этот механизм, остаются уязвимыми для DoS. В частности, серверы DTLS, не применяющие обмен cookie, могут использоваться как усилители атак, даже когда они сами не сталкиваются с отказами в обслуживании. Поэтому серверам DTLS следует использовать обмен cookie, если нет веских причин полагать, что атаки с усилением не актуальны в среде применения. Клиенты должны быть готовы к обмену cookie при каждом согласовании. Ниже перечислены некоторые важные свойства cookie, требуемые механизмом обмена, как описано в параграфе 3.3 [RFC2522]:

  • Значение cookie должно зависеть от адреса клиента.

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

  • Генерацию и проверку cookie инициируют стороны, не прошедшие проверку подлинности, поэтому нужно ограничивать потребление ресурсов, чтобы механизм обмена cookie сам не стал частью DoS-атаки.

Хотя cookie должны разрешать серверу создавать корректную стенограмму (transcript) согласования, их следует создавать так, чтобы знания cookie не было досточно для воспроизведения содержимого ClientHello. Иначе могут возникнуть проблемы с будущими расширениями, такими как Encrypted Client Hello [TLS-ECH].

Хотя cookie создаются с использованием механизма аутентификации на основе ключа, следует предусматривать возможность смены соответствующего секретного ключа, чтобы временная компрометация ключа не создавала постоянного нарушения целостности механизма обмена cookie. Этот секрет не так ценен, как, например, ключ шифрования сеансовых квитанций (session-ticket-encryption), смена ключа создания cookie в таком же масштабе времени гарантирует, что ключи будут обновляться регулярно и обеспечат безопасную работу.

Обмен cookie обеспечивает проверку адресов при начальном согласовании. DTLS с CID позволяет менять адреса конечных точек в процессе работы ассоциации и такие адреса не охватываются обменом cookie при согласовании. Реализациям DTLS недопустимо менять адрес, на который они отправляют пакеты, при ответе на пакет с определённого адреса, пока они каким-либо способом не проверять доступность этого адреса. Данная спецификация не задаёт такой проверки, а в будущем потребуется полностью задать процедуру проверки. Но даже при такой проверке злоумышленник на пути передачи может отправить трафик в «черную дыру» или организовать атаку с отражением на стороннюю систему, поскольку у узлов DTLS нет возможности отличить подлинную смену адреса (например, в результате изменения привязки NAT) от злонамеренной подделки. Такие атаки вызывают беспокойство при значительной асимметрии размеров сообщений с запросами и откликами.

За исключением порядка и невоспроизводимости гарантии безопасности для DTLS 1.3 не отличаются от TLS 1.3. В TLS всегда обеспечивается упорядоченность и невоспроизводимость, но DTLS такой защиты не предоставляет.

В отличие от TLS, реализациям DTLS не следует отвечать на непригодные записи разрывом соединения.

TLS 1.3 требует защиты от воспроизведения для данных 0-RTT (точнее, для соединений с данными 0-RTT, см. раздел 8 в [TLS13]). DTLS предоставляет необязательный механизм защиты от воспроизведения на уровне отдельной записи, поскольку протоколы на основе дейтаграмм по своей природе подвержены нарушению порядка и повторному использованию пакетов (replay). Эти механизмы защиты от повторного использования ортогональны и ни один из них не соответствует требованиям другого.

Стенограмма согласования DTLS 1.3 не включает новые поля DTLS, поэтому имеет такой же формат, как в TLS 1.3. Однако стенограммы DTLS 1.3 и TLS 1.3 не пересекаются, поскольку используют разные номера версий. Кроме того, в планировании ключей DTLS 1.3 использует свою метку и будет создавать иные ключи для той же стенограммы.

Свойства безопасности и приватности CID для DTLS 1.3 основаны на описанных для DTLS 1.2 в [RFC9146], однако имеется несколько отличий, указанных ниже.

  • В обеих версиях DTLS согласуется расширение для использования CID и их числа, а CID передаётся в заголовке записи DTLS (при согласовании). Однако способ включения CID в заголовок записи различается.

  • Использование сообщения post-handshake позволяет клиенту и серверу обновлять свои CID, а конфиденциальность обмена защищается.

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

  • Механизм шифрования порядковых номеров (4.2.3. Шифрование номера записи) защищает от банального отслеживания злоумышленниками на пути, пытающимися сопоставить картины порядковых номеров на разных путях, что может происходить даже при использовании на этих путях разных CID, если порядковые номера не шифровать. Смена CID по событиям или регулярно помогает защититься от отслеживания злоумышленниками на пути. Отметим, что шифрование номеров применяется для всех шифрованных записей DTLS 1.3 независимо от использования CID. Номера эпох не шифруются, поскольку они служат идентификаторами ключей, и это позволяет точнее сопоставлять пакеты одного соединения на разных путях через сеть.

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

12. Отличия от DTLS 1.2

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

  • Новая модель согласования, сократившая обмен сообщениями.

  • Поддерживаются только шифры AEAD, расчёт дополнительных данных упрощен.

  • Исключена поддержка слабых и устаревших криптоалгоритмов.

  • Сообщение HelloRetryRequest применяется в TLS 1.3 вместо HelloVerifyRequest.

  • Более гибкое согласования шифронабора.

  • Новый механизм возобновления сессий.

  • Переопределена аутентификация PSK.

  • Новая иерархия вывода ключей с новой конструкцией создания ключа.

  • Улучшено согласование версий.

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

  • Добавлена функциональность CID.

  • Порядковые номера шифруются.

13. Обновления, влияющие на DTLS 1.2

Этот документ вносит некоторые изменения, влияющие на реализации DTLS 1.2, даже не поддерживающие DTLS 1.3.

  • Новый механизм защиты от понижения версии, описанный в параграфе 4.1.3 [TLS13] с применением в DTLS, как описано в параграфе 5.3. Сообщение ClientHello.

  • Обновления, описанные в параграфе 1.3 [TLS13].

  • Новые требования к соответствию, указанные в параграфе 9.3 [TLS13].

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

Агентство IANA выделило значение типа содержимого 26 из реестра TLS ContentType для сообщений ACK, заданных в разделе 7. В поле DTLS-OK указано значение Y. Типы содержимого 32-63 объявлены резервными и не выделяются.

Агентство IANA выделило значение 52 для предупреждения too_many_cids_requested из реестра TLS Alerts с указанием для DTLS-OK значения Y.

Агентство IANA выделило из реестра TLS HandshakeType, заданного в [TLS13], значения для идентификаторов request_connection_id (9) и new_connection_id (10), заданных этим документом с указанием для DTLS-OK значения Y.

Агентство IANA добавило ссылку на этот документ в реестр TLS Cipher Suites с приведённым ниже примечанием.

Любой шифронабор TLS, заданный для использования с DTLS, должен указывать пределы использования связанной с ним функции AEAD, которая служит для защиты целостности и конфиденциальности, как указано в параграфе 4.5.3 RFC 9147.

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

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

[CHACHA] Nir, Y. and A. Langley, «ChaCha20 and Poly1305 for IETF Protocols», RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/info/rfc8439>.

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

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

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

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

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, «Computing TCP’s Retransmission Timer», RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

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

[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and A. Kraus, «Connection Identifier for DTLS 1.2», RFC 9146, DOI 10.17487/RFC9146, March 2022, <https://www.rfc-editor.org/info/rfc9146>.

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

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

[AEAD-LIMITS] Günther, F., Thomson, M., and C. A. Wood, «Usage Limits on AEAD Algorithms», Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-04, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04>.

[AEBounds] Luykx, A. and K. Paterson, «Limits on Authenticated Encryption Use in TLS», 28 August 2017, <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

[CCM-ANALYSIS] Jonsson, J., «On the Security of CTR + CBC-MAC», Selected Areas in Cryptography pp. 76-93, DOI 10.1007/3-540-36492-7_7, February 2003, <https://doi.org/10.1007/3-540-36492-7_7>.

[DEPRECATE] Moriarty, K. and S. Farrell, «Deprecating TLS 1.0 and TLS 1.1», BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

[IOT-PROFILE] Tschofenig, H. and T. Fossati, «TLS/DTLS 1.3 Profiles for the Internet of Things», Work in Progress, Internet-Draft, draft-ietf-uta-tls13-iot-profile-04, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04>.

[RFC2522] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, DOI 10.17487/RFC2522, March 1999, <https://www.rfc-editor.org/info/rfc2522>.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.

[RFC4346] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1», RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.

[RFC4347] Rescorla, E. and N. Modadugu, «Datagram Transport Layer Security», RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5238] Phelan, T., «Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)», RFC 5238, DOI 10.17487/RFC5238, May 2008, <https://www.rfc-editor.org/info/rfc5238>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, «Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)», RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.

[RFC5764] McGrew, D. and E. Rescorla, «Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)», RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.

[RFC6066] Eastlake 3rd, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6347] Rescorla, E. and N. Modadugu, «Datagram Transport Layer Security Version 1.2», RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

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

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7924] Santesson, S. and H. Tschofenig, «Transport Layer Security (TLS) Cached Information Extension», RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.

[RFC7983] Petit-Huguenin, M. and G. Salgueiro, «Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)», RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, «Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal», RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8879] Ghedini, A. and V. Vasiliev, «TLS Certificate Compression», RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., «QUIC Loss Detection and Congestion Control», RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.

[ROBUST] Fischlin, M., Günther, F., and C. Janson, «Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3», received 15 June 2020, last revised 22 February 2021, <https://eprint.iacr.org/2020/718>.

[TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C.A. Wood, «TLS Encrypted Client Hello», Work in Progress, Internet-Draft, draft-ietf-tls-esni-14, 13 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14>.

Приложение A. Структуры данных и константы протокола

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

A.1. Уровень Record

       struct {
           ContentType type;
           ProtocolVersion legacy_record_version;
           uint16 epoch = 0
           uint48 sequence_number;
           uint16 length;
           opaque fragment[DTLSPlaintext.length];
       } DTLSPlaintext;

       struct {
            opaque content[DTLSPlaintext.length];
            ContentType type;
            uint8 zeros[length_of_padding];
       } DTLSInnerPlaintext;

       struct {
           opaque unified_hdr[variable];
           opaque encrypted_record[length];
       } DTLSCiphertext;

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID |
| (при наличии  |
/  согласуется  /   C   - присутствует Connection ID (CID)
|  размер)      |   S   - размер порядкового номера
+-+-+-+-+-+-+-+-+   L   - присутствует Length
| 8 или 16 битов|   E   - Epoch
|Sequence Number|
+-+-+-+-+-+-+-+-+
|16 битов Length|
| (при наличии) |
+-+-+-+-+-+-+-+-+


struct {

           uint64 epoch;
           uint64 sequence_number;
       } RecordNumber;

A.2. Протокол Handshake

       enum {
           hello_request_RESERVED(0),
           client_hello(1),
           server_hello(2),
           hello_verify_request_RESERVED(3),
           new_session_ticket(4),
           end_of_early_data(5),
           hello_retry_request_RESERVED(6),
           encrypted_extensions(8),
           request_connection_id(9),           /* Новое */
           new_connection_id(10),              /* Новое */
           certificate(11),
           server_key_exchange_RESERVED(12),
           certificate_request(13),
           server_hello_done_RESERVED(14),
           certificate_verify(15),
           client_key_exchange_RESERVED(16),
           finished(20),
           certificate_url_RESERVED(21),
           certificate_status_RESERVED(22),
           supplemental_data_RESERVED(23),
           key_update(24),
           message_hash(254),
           (255)
       } HandshakeType;

       struct {
           HandshakeType msg_type;    /* Тип согласования */
           uint24 length;             /* Число байтов в сообщении */
           uint16 message_seq;        /* Требуемое DTLS поле */
           uint24 fragment_offset;    /* Требуемое DTLS поле */
           uint24 fragment_length;    /* Требуемое DTLS поле */
           select (msg_type) {
               case client_hello:          ClientHello;
               case server_hello:          ServerHello;
               case end_of_early_data:     EndOfEarlyData;
               case encrypted_extensions:  EncryptedExtensions;
               case certificate_request:   CertificateRequest;
               case certificate:           Certificate;
               case certificate_verify:    CertificateVerify;
               case finished:              Finished;
               case new_session_ticket:    NewSessionTicket;
               case key_update:            KeyUpdate;
               case request_connection_id: RequestConnectionId;
               case new_connection_id:     NewConnectionId;
           } body;
       } Handshake;

       uint16 ProtocolVersion;
       opaque Random[32];

       uint8 CipherSuite[2];    /* Селектор шифронабора */

       struct {
           ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
           Random random;
           opaque legacy_session_id<0..32>;
           opaque legacy_cookie<0..2^8-1>;               // DTLS
           CipherSuite cipher_suites<2..2^16-2>;
           opaque legacy_compression_methods<1..2^8-1>;
           Extension extensions<8..2^16-1>;
       } ClientHello;

A.3. ACK

       struct {
           RecordNumber record_numbers<0..2^16-1>;
       } ACK;

A.4. Управление идентификаторами соединений

       enum {
           cid_immediate(0), cid_spare(1), (255)
       } ConnectionIdUsage;

       opaque ConnectionId<0..2^8-1>;

       struct {
           ConnectionId cids<0..2^16-1>;
           ConnectionIdUsage usage;
       } NewConnectionId;

       struct {
         uint8 num_cids;
       } RequestConnectionId;

Приложение B. Анализ ограничений на использование CCM

В TLS [TLS13] и [AEBounds] не заданы пределы использования ключей для AEAD_AES_128_CCM. Однако для любого AEAD, применяемого с DTLS требуются ограничения на использование для защиты целостности и конфиденциальности. В этом приложении документируется анализ для алгоритма AEAD_AES_128_CCM.

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

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

t

Размер тега аутентификации в битах. Для описываемого шифра t = 128.

n

Размер блочной функции в битах. Для описываемого шифра n = 128.

l

Число блоков в каждом пакете (см. ниже).

q

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

v

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

Анализ AEAD_AES_128_CCM основан на подсчете числа блочных операций, вовлечённых в создание каждого сообщения. Для простоты и соответствия анализу других функций AEAD в [AEBounds] предполагается размер пакета 2^10 блоков и предельный размер 2^14 байтов.

Для AEAD_AES_128_CCM общее число операций блочного шифра определяется суммой размера связанных данных в блоках, размера шифрованных данных в блоках и размера открытых данных в блоках плюс 1. В данном анализе это упрощено до удвоенного значения максимального размера записи в блоках (2l = 2^11). Это упрощение основано на том, что размер связанных данных ограничен одним блоком.

B.1. Ограничения для конфиденциальности

Для обеспечения конфиденциальности теорема 2 из [CCM-ANALYSIS] указывает, что злоумышленник получает заметное преимущество над идеальной псевдослучайной перестановкой (pseudorandom permutation или PRP) не более

   (2l * q)^2 / 2^n

Для целевого преимущества 2^-60 в системе с 1 ключом, которое соответствует применяемому в TLS 1.3, как указано в [AEAD-LIMITS], это даёт соотношение

   q <= 2^23

Таким образом, конечные точки не могут защитить более 2^23 с одним набором ключей, не дав атакующему преимущества выше целевого 2^-60.

B.2. Ограничения для целостности

Для обеспечения целостности теорема 1 из [CCM-ANALYSIS] указывает, что что злоумышленник получает заметное преимущество над идеальной PRP не более

   v / 2^t + (2l * (v + q))^2 / 2^n

Целью является ограничение этого преимущества до значения 2^-57, соответствующего цели TLS 1.3, как указано в [AEAD-LIMITS]. Поскольку t и n имеют значение 128, первый член выражения пренебрежимо мал по сравнению со вторым и его можно удалить без существенного влияния на результат, что даёт в итоге

   v + q <= 2^24,5

Используя ранее установленное значение 2^23 для q с округлением, получим верхний предел для v равный 2^23,5. Таким образом, конечные точки не могут аутентифицировать более 2^23,5 с одним набором ключей, не давая злоумышленнику преимущества выше целевого значения 2^-57.

B.3. Ограничения для AEAD_AES_128_CCM_8

Шифронабор TLS_AES_128_CCM_8_SHA256 использует функцию AEAD_AES_128_CCM_8 с коротким тегом аутентификации (t=64).

Пределы защиты конфиденциальности для AEAD_AES_128_CCM_8 совпадают с пределами AEAD_AES_128_CCM, поскольку они не зависят от размера тега (см. B.1. Ограничения для конфиденциальности).

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

   v <= 2^7

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

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

Приложение C. Подводные камни реализации

В дополнение к аспектам TLS, которые были источниками проблем совместимости и безопасности (Приложение C.3 к [TLS13]), DTLS вносит несколько своих источников возможных проблем, отмеченных ниже.

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

  • Повторная передача согласующих сообщений не подтверждённых явно или неявно (5.8. Тайм-ауты и повтор передачи).

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

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

  • Ограничение объёма данных, передаваемых узлу до проверки его адреса.

  • Проверка явного указания размера записи в дейтаграмме, где запись содержится.

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

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

Hanno Becker
Arm Limited
Email: Hanno.Becker@arm.com
 
David Benjamin
Google
Email: davidben@google.com
 
Thomas Fossati
Arm Limited
Email: thomas.fossati@arm.com
 
Tobias Gondrom
Huawei
Email: tobias.gondrom@gondrom.org
 
Felix Günther
ETH Zurich
Email: mail@felixguenther.info
 
Benjamin Kaduk
Akamai Technologies
Email: kaduk@mit.edu
 
Ilari Liusvaara
Independent
Email: ilariliusvaara@welho.com
 
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
 
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net
 
Yin Xinxing
Huawei
Email: yinxinxing@huawei.com

Концепция шифрования порядкового номера заимствована из QUIC [RFC9000]. Спасибо авторам RFC 9000 за их работу. Felix Günther и Martin Thomson внесли вклад в анализ, представленный в Приложении B. Спасибо Jonathan Hammell, Bernard Aboba, Andy Cunningham за их комментарии.

Кроме того, авторы благодарны за обхорные комментации членам IESG: Martin Duke, Erik Kline, Francesca Palombini, Lars Eggert, Zaheduzzaman Sarker, John Scudder, Éric Vyncke, Robert Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin Vigoureux, Alvaro Retana.

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

Eric Rescorla
Mozilla
Email: ekr@rtfm.com
 
Hannes Tschofenig
Arm Limited
Email: hannes.tschofenig@arm.com
 
Nagendra Modadugu
Google, Inc.
Email: nagendra@cs.stanford.edu

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

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

nmalykh@protokols.ru


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

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

3Secure Real-time Transport Protocol — защищенный протокол транспортировки в реальном масштабе времени.

4Когда отправка при согласовании передаётся без ожидания ответа, как в случае с финальной отправкой клиента или сообщением NewSessionTicket, она должна подтверждаться сообщением ACK.

5Maximum Segment Lifetime — максимальное время жизни сегмента TCP в сети. Произвольно выбрано значение 2 минуты.

6Internet of Things — Internet вещей.

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

RFC 9236 Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service

Internet Research Task Force (IRTF)                              J. Hong
Request for Comments: 9236                                        T. You
Category: Informational                                             ETRI
ISSN: 2070-1721                                                 V. Kafle
                                                                    NICT
                                                              April 2022

Architectural Considerations of Information-Centric Networking (ICN)
Using a Name Resolution Service

Архитектурные вопросы сетей ICN, использующих службы распознавания имён

PDF

Аннотация

В этом документе описаны архитектурные соображения, относящиеся к службе распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Документ разъясняет, как может меняться архитектура ICN при использовании NRS и как это использование влияет на систему маршрутизации ICN. Документ разработан исследовательской группой ICNRG (Information-Centric Networking Research Group).

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

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

Документ является результатом работы IRTF1. IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).

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

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

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

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

1. Введение

Информационно-ориентированные сети (ICN) — это подход к развитию инфраструктуры Internet для обеспечения прямого доступа к именованным объектам (Named Data Object или NDO) по их именам. В двух распространённых архитектурах ICN — сети именованных данных (Named Data Networking или NDN) [NDN] и ориентированные на содержимое сети (Content-Centric Networking или CCNx) [CCNx] — имена NDO используются напрямую для маршрутизации запросов на извлечение объектов данных. Такая непосредственная маршрутизация по именам сталкивается с присущей ей по природе проблемами глобально расширяемой системы маршрутизации, обеспечением мобильности создателей (производителей) данных и поддержкой кэширования вне пути. Эти вопросы рассматриваются в разделе 3. Основы. Известны описания решений этих проблем с использованием системы распознавания имён (NRS), а также предложено несколько проектов ICN [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].

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

Этот документ представляет согласованное мнение исследовательской группы ICNRG. Он был тщательно рассмотрен членами группы, активно участвующими в исследованиях и разработке технологии, описанной здесь. Документ не является результатом работы IETF или стандартом.

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

Name Resolution Service (NRS) — система распознавания имен

NRS в ICN определяется как служба, обеспечивающая функцию трансляции имён содержимого или объекта данных в некую информацию, такую как маршрутизируемый префикс, локатор, указатель на кэш вне пути или псевдоним имени, более подходящий, чем исходное имя, служащие для пересылки запроса объекта в направлении целевого получателя, хранящего NDO [RFC9138]. NRS, скорее всего, реализуется на основе распределенной базы данных с отображениями. В качестве NRS можно использовать систему доменных имён Domain Name System или DNS). Однако в этом случае необходимо учитывать требования частого обновления NRS в результате создания большого числа новых NDO и смены их местоположения в сети.

NRS server — сервер NRS

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

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

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

Name registration — регистрация имён

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

Name resolution — распознавание имён

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

NRS node — узел NRS

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

NRS client — клиент NRS

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

3. Основы

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

Расширяемость маршрутизации

В ICN, имена приложений, указывающее содержимое, предназначены для использования напрямую при доставке пакетов, поэтому в маршрутизаторах ICN применяются протоколы маршрутизации по именам для создания таблиц маршрутизации и пересылки на основе имён. Как и в случае расширения маршрутизации IP, попадание неагрегируемых префиксов имён в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) маршрутизаторов ICN, вызывает неконтролируемый рост размера таблицы маршрутизации DFZ. Поэтому обеспечение некоторого уровня опосредованности за счёт внедрения NRS в ICN может обеспечить сохранение контроля над размером таблиц маршрутизации. Система NRS транслирует префиксы имён, отсутствующие в таблице пересылки DFZ, в глобально маршрутизируемые префиксы, такие как предложено в NDN [Afanasyev]. Другим решением проблемы расширяемости маршрутизации являются многоуровневые распределенные хэш-таблицы (Multi-level Distributed Hash Table или MDHT), применяемые в NetInf [Dannewitz]. Это обеспечивает anycast-маршрутизацию на основе имён, которая может поддерживать плоское (без иерархии) пространство имён и может быть приспособлена в глобальном масштабе [Dannewitz2].

Мобильность создателей содержимого

Если в ICN производитель содержимого перемещается в другую область (домен) имён, использующую иной префикс имён, запрос на созданное им содержимое по исходному его имени должен пересылаться в новое местоположение производителя содержимого. if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer’s new location. Поддержка мобильных создателей содержимого особенно усложняется в иерархической системе именования по сравнению с плоской схемой, поскольку требуется обновлять таблицы маршрутизации в более широкой области для отслеживания перемещений создателя содержимого. Поэтому в различных вариантах архитектуры ICN, таких как NetInf [Dannewitz] и MobilityFirst [MF], применяется система NRS для решения проблем при перемещении создателей содержимого.

Кэширование вне пути

Кэширование в сети является базовым свойством архитектуры ICN. Подход к кэшированию можно разделить на on-path (на пути) и off-path (вне пути) по местоположению кэша относительно пути пересылки от исходного хранилища содержимого к потребителю. Кэширование вне пути иногда называют репликацией или сохранением содержимого и оно нацелено на репликацию именованных объектов данных (NDO) в разных местах сети для повышения доступности содержимого и/или сокращения задержки при доступе. Кэш может располагать вне пути пересылки содержимого. Нахождение кэшированного вне пути содержимого требуется в системах маршрутизации исключительно на основе имён. Для поддержки доступа к кэшу вне пути местоположение реплик обычно анонсируется в систему маршрутизации по именам или в систему NRS, как описано в [Bayhan].

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

4. Влияние NRS на ICN

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

Процедура пересылки

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

Задержка

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

Безопасность

Добавлении в архитектуру ICN системы NRS может расширить фронт атак. Защита самой NRS от распределенных атак на службы (Distributed Denial of Service или DDoS) и подмены или изменения отображений имён может оказаться сложной задачей.

5. Вопросы архитектуры ICN для NRS

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

5.1. Регистрация, распознавание и обновление записей для имён

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

             +------------+             +------------+
             |  Узел NRS  |             |  Узел NRS  |
             +------------+             +------------+
                   |                          |
                   |                          |
+------------+     |                          |     +------------+
| Клиент NRS |--------------------------------------| Клиент NRS |
+------------+            Базовая сеть              +------------+

Рисунок 1. Узлы и клиенты NRS, соединённые через базовую сеть.


Регистрация имён

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

Распознавание имён

Распознавание имён выполняется клиентом NRS для получения записи об имени от узла NRS путём отправки сообщения с запросом распознавания и получения отклика с записью. В контексте маршрутизации ICN на основе имён распознавание требуется на каждом маршрутизаторе ICN, чья база данных о пересылке (forwarding information base или FIB) не содержит префикса запрошенного имени. Распознавание имён может также выполняться потребителем (особенно многодомным) для пересылки запросов содержимого в более подходящем направлении, чтобы получить содержимое из ближайшего кэша. Если потребитель имеет одно подключение, он может не утруждать себя распознаванием имён, полагаясь на прямую маршрутизацию по именам или распознавание имён восходящим маршрутизатором ICN. В этом случае потребитель создаёт пакет запроса содержимого, включающий имя, и направляет этот пакет ближайшему маршрутизатору ICN. Маршрутизатор ICN просматривает свою таблицу FIB для пересылки запроса содержимого. Если маршрутизатор ICN не может определить доступность запрошенного содержимого, он выполняет распознавание имени для получения записи об отображении имени и добавляет эту запись в свою FIB. Маршрутизатор ICN может выполнять распознавание имени даже до получения запроса содержимого, чтобы использовать запись об отображении в своей таблице FIB.

Обновление записей для имён

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

5.2. Протоколы и семантика

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

Одним из способов реализации NRS для CCNx является расширение базового формата TLV и семантики [RFC8569] [RFC8609]. Например, запросы и отклики распознавания имён можно реализовать путём определения новых типов полей в сообщениях Interest и Content Object [CCNxNRS]. Используя имеющиеся пакеты CCNx Interest и Content Object для регистрации и распознавания имён, систему NRS можно развернуть с незначительными изменениями протоколов ICN. Однако в таких случаях система NRS может быть неспособной использовать более гибкие и расширяемые схемы.

С другой стороны, система NRS может быть разработана независимо ко своими протоколами и семантикой, подобно NRS, описанной в [Hong]. Например, протокол и сообщения NRS можно реализовать с использованием RESTful API, а NRS может работать как прикладной протокол, независимый от остальных протоколов ICN.

5.3. Система маршрутизации

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

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

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

6. Заключение

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

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

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

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

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

При внесении в архитектуру ICN новых компонент, таких как NRS, фронт атак расширяется. Связанные с этим вопросы безопасности рассмотрены ниже.

Безопасность пространств имён

Для развёртывания системы NRS в архитектуре ICN пространства имён ICN, которые могут выделяться уполномоченными элементами, должны защищённо отображаться на издателей содержимого и надёжно обслуживаться теми. Согласно исследованиям ICN [RFC7927], новое пространство имён может также обеспечивать функцию проверки целостности для контроля подлинности издателей. Вопросы аутентификации пространства имён и отображений между разными пространствами имён требуют дополнительного исследования.

Безопасность системы NRS

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

Безопасность протокола и сообщений NRS

В системе NRS протоколы для создания, передачи и приёма сообщений NRS, связанных с регистрацией, распознаванием и обновлением записей для имён, следует защищать с помощью подходящих механизмов. Должны обеспечиваться подобающие меры защиты, чтобы инициировать и читать сообщения NRS могли только легитимные узлы. Целостность этих сообщений должна защищаться, а также должны применяться механизмы проверки подлинности, чтобы неуполномоченные стороны не могли манипулировать сообщениями при пересылке через сеть. Следует также предусматривать механизмы шифрования сообщений, чтобы предотвратить утечки данных и нарушения конфиденциальности. Множество проблем, аналогичных известным для сетей IP и DNS, могут оказывать влияние на архитектуру ICN в целом. Подход с минимизацией DNS QNAME может оказаться подходящим для обеспечения безопасности процессов распознавания имён. Следует предусматривать механизмы защиты, такие как проверка подлинности при доступе и т. п. для систем NRS [RFC9138], обеспечивающие безопасность не только NRS но и всей архитектуры ICN.

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

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

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, «Information-Centric Networking (ICN) Research Challenges», RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

[RFC8569] Mosko, M., Solis, I., and C. Wood, «Content-Centric Networking (CCNx) Semantics», RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[RFC8609] Mosko, M., Solis, I., and C. Wood, «Content-Centric Networking (CCNx) Messages in TLV Format», RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.

[RFC9138] Hong, J., You, T., Dong, L., Westphal, C., and B. Ohlman, «Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)», RFC 9138, DOI 10.17487/RFC9138, December 2021, <https://www.rfc-editor.org/info/rfc9138>.

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

[Afanasyev] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, «SNAMP: Secure namespace mapping to scale NDN forwarding», 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A., and J. Crowcroft, «On Content Indexing for Off-Path Caching in Information-Centric Networks», ACM ICN, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.

[CCNx] «Cicn», <https://wiki.fd.io/view/Cicn>.

[CCNxNRS] Hong, J., You, T., and Y. Hong, «CCNx Extension for Name Resolution Service», Work in Progress, Internet-Draft, draft-hong-icnrg-ccnx-nrs-02, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>.

[Dannewitz] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, «Network of Information (NetInf) — An information-centric networking architecture», Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.

[Dannewitz2] Dannewitz, C., D’Ambrosio, M., and V. Vercellone, «Hierarchical DHT-based name resolution for information-centric networks», Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.014, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.014>.

[Hong] Hong, J., Chun, W., and H. Jung, «Demonstrating a Scalable Name Resolution System for Information-Centric Networking», ACM ICN, DOI 10.1145/2810156.2812617, September 2015, <https://doi.org/10.1145/2810156.2812617>.

[MF] Future Internet Architecture (FIA), «MobilityFirst», <http://mobilityfirst.cs.umass.edu/>.

[NDN] NDN, «Named Data Networking», September 2010, <https://www.named-data.net>.

[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, «Forwarding Label support in CCN Protocol», Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.

[SAIL] «Scalable and Adaptive Internet Solutions (SAIL)», <https://www.sail-project.eu/>.

[Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, «A Survey of Mobility Support in Named Data Networking», Named Data Networking, Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016.

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

Авторы признательны Dave Oran (сопредседатель ICNRG) за очень полезные рецензии и комментарии, которые помогли значительно улучшить этот документ.

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

Jungha Hong
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: jhong@etri.re.kr
 
Tae-Wan You
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: twyou@etri.re.kr
 
Ved Kafle
NICT
Koganei
4-2-1 Nukui-Kitamachi, Tokyo
184-8795
Japan
Email: kafle@nict.go.jp

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

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

nmalykh@protokols.ru


1Internet Research Task Force — комиссия по исследованиям Internet.

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

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

RFC 9179 A YANG Grouping for Geographic Locations

Internet Engineering Task Force (IETF)                          C. Hopps
Request for Comments: 9179                       LabN Consulting, L.L.C.
Category: Standards Track                                  February 2022
ISSN: 2070-1721

A YANG Grouping for Geographic Locations

Группировки YANG для географического положения

PDF

Аннотация

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

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

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

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

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

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

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

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

Хотя обычно интересует местоположение относительно Земли, это не всегда так. Легко представить сетевой устройство, размещённое на Луне, Марсе, Энцеладе (спутник Сатурна) и даже на комете (например, 67p/churyumov-gerasimenko). Можно представить определение местоположения в разных системах отсчёта и даже альтернативных системах (например, в имитаторах или виртуальной реальности).

Этот документ определяет группировку YANG geo-location, которая позволяет фиксировать всё, указанное выше.

Эта спецификация соответствует [ISO.6709.2008].

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

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

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

2. Объект геолокации

2.1. Система отсчёта

Система отсчёта (reference-frame) определяет, к чему привязаны данные местоположения и смысл этих данных. Точкой отсчёта может служить любое астрономическое тело — планета, такая как Земля или Марс, спутник планеты, такой как Энцелад, астероид (например, Церера) и даже комета (например, 1P/Halley). Значение задаётся в astronomical-body и определяется Международным астрономическим союзом (International Astronomical Union) <http://www.iau.org>. По умолчанию astronomical-body имеет значение earth (Земля).

В дополнение к указанию астрономического тела нужно также определить систему координат (например, долгота и широта), а также уровень для отсчёта высоты. Это задаётся значением geodetic-datum. По умолчнию в качестве geodetic-datum применяется система wgs-84 (Всемирная геодезическая система — World Geodetic System [WGS84]), которая используется в системе глобального позиционирования (Global Positioning System или GPS) и др. Документ задаёт реестр IANA для указания стандартный значений geodetic-datum.

В дополнение к geodetic-datum разрешено переопределение точности координат и высоты с использованием coord-accuracy и height-accuracy, соответственно. Когда эти значения заданы, они переопределяют принятые по умолчанию значения, подразумеваемые значением geodetic-datum.

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

2.2. Местоположение

Это положение на астрономическом объекте или относительно него, задаваемое двумя или тремя координатами. Местоположение указываются широтой (latitude), долготой (longitude) и высотой (height, необязательно) или декартовыми координатами x, y, z. Для стандартного выбора местоположения широта и долгота задаются в угловых градусах, а высота — в метрах. Декартовы координаты указываются в метрах. В обоих случаях точный смысл всех значений определяется geodetic-datum (см. параграф 2.1).

2.3. Движение

Добавлена поддержка сравнительно стабильно движущихся объектов, для которых группировка определяет трехмерный вектор. Вектор задаётся направлениями скоростью в северном (v-north) и восточном (v-east) направлении, а также набором высоты (v-up), указываемые с м/сек. Значения v-north привязаны к истоинногму северу, заданному для астрономического тела, а v-up к направлению от центра масс, перпендикулярному v-north и v-east.

Для определения двумерного курса и скорости применяются приведённые ниже формулы.

                 ,------------------------------
       speed =  V  v_{north}^{2} + v_{east}^{2}
       heading = arctan(v_{east} / v_{north})

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

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

2.4. Вложенное местоположение

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

2.5. Другие атрибуты

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

2.6. Дерево

Ниже показано дерево YANG [RFC8340] для группировки geo-location.

     module: ietf-geo-location
       grouping geo-location:
         +-- geo-location
            +-- reference-frame
            |  +-- alternate-system?    string {alternate-systems}?
            |  +-- astronomical-body?   string
            |  +-- geodetic-system
            |     +-- geodetic-datum?    string
            |     +-- coord-accuracy?    decimal64
            |     +-- height-accuracy?   decimal64
            +-- (location)?
            |  +--:(ellipsoid)
            |  |  +-- latitude?    decimal64
            |  |  +-- longitude?   decimal64
            |  |  +-- height?      decimal64
            |  +--:(cartesian)
            |     +-- x?           decimal64
            |     +-- y?           decimal64
            |     +-- z?           decimal64
            +-- velocity
            |  +-- v-north?   decimal64
            |  +-- v-east?    decimal64
            |  +-- v-up?      decimal64
            +-- timestamp?         yang:date-and-time
            +-- valid-until?       yang:date-and-time

3. Модуль YANG

Эта модель импортирует Common YANG Data Types [RFC6991] и использует YANG версии 1.1 [RFC7950].

   <CODE BEGINS> file "ietf-geo-location@2022-02-11.yang"
   module ietf-geo-location {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-geo-location";
     prefix geo;
     import ietf-yang-types {
       prefix yang;
       reference "RFC 6991: Common YANG Data Types";
     }

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

       Editor:   Christian Hopps
                 <mailto:chopps@chopps.org>"; 

     description
       "Этот модуль задаёт группировку объектов контейнера, указывающих
        местоположение на астрономическом теле (например, Земле) или 
        относительно него.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-02-11 {
       description
         "Исходный выпуск";
       reference
         "RFC 9179: A YANG Grouping for Geographic Locations";
     }

     feature alternate-systems {
       description
         "Указывает поддержку альтернативных систем отсчёта.";
     }

     grouping geo-location {
       description
         "Группировка для указания местоположения на
          астрономическом объекте.";

       container geo-location {
         description
           "Место на астрономическом теле (например, Земля) где-то
            во Вселенной.";

         container reference-frame {
           description
             "Система отсчёта для значений местоположения.";

           leaf alternate-system {
             if-feature "alternate-systems";
             type string;
             description
               "Система, в которой определено астрономическое тело и 
                геодезические данные. Обычно это значение не указывается
                и системой отсчёта служит естественная Вселенная, однако
                с помощью этого значения можно задать альтернативные
                системы (например, виртуальную реальность). Это меняет
                определения (но не тип) значений системы отсчета";
           }
           leaf astronomical-body {
             type string {
               pattern '[ -@\[-\^_-~]*';
             }
             default "earth";
             description
               "Имя астрономического тела, заданное Международным
                астрономическим моюзом (IAU), или другой системой,
                если она указана. Примеры включают sun (Солнце),
                earth (Земля), moon (Луна), enceladus (спутник Сатурна),
                ceres (астероид), 67p/churyumov-gerasimenko (комета). 
                СЛЕДУЕТ использовать символы ASCII в нижнем регистре и
                не включать смволы управления (коды, 32-64 и 91-126).
                Артикль the НЕ СЛЕДУЕТ включать.";
             reference
               "https://www.iau.org/"; 
           }
           container geodetic-system {
             description
               "Геодезическая система для данных о местоположении.";
             leaf geodetic-datum {
               type string {
                 pattern '[ -@\[-\^_-~]*';
               }
               description
                 "Геодезические данные, указывающие широту, долготу и
                  высоту. По умолчанию для Земли (earth) применяется
                  система wgs-84, используемая в GPS. СЛЕДУЕТ 
                  использовать символы ASCII в нижнем регистре и не
                  включать смволы управления (коды, 32-64 и 91-126). В
                  реестре IANA дополнительно задана замена пробелов ( )
                  символами дефиса (-). Спецификация geodetic-datum
                  определяет, сколь точно моделируется астрономическое
                  тело как по горизонтали (широта - долгота), так и по
                  вертикали (высота).";
               reference
                 "RFC 9179: A YANG Grouping for Geographic Locations,
                  Section 6.1";
             }
             leaf coord-accuracy {
               type decimal64 {
                 fraction-digits 6;
               }
               description
                 "Точность пары широта-долгота для эллипсоидных 
                  координат или X, Y, Z для декартовых. Заданное 
                  значение coord-accuracy указывает, насколько точно
                  определены координаты в списке местоположений
                  относительно системы координат geodetic-datum. 
                  Например, может возникнуть погрешность из-за
                  ошибки измерения.";
             }
             leaf height-accuracy {
               type decimal64 {
                 fraction-digits 6;
               }
               units "meters";
               description
                 "Точность указания высоты в эллипсоидных координатах
                  (для декартовых координат этот лист не указывается).
                  Заданное значение указывает, насколько точны высоты в
                  списке местоположений относительно системы координат,
                  указанной geodetic-datum.  Например, может возникнуть
                  погрешность из-за ошибки измерения.";
             }
           }
         }
         choice location {
           description
             "Широта и долгота или декартовы координаты местоположения";
           case ellipsoid {
             leaf latitude {
               type decimal64 {
                 fraction-digits 16;
               }
               units "decimal degrees";
               description
                 "Значение широты на астрономическом теле. Определение и
                  точность этого значения зависят от reference-frame.";
             }
             leaf longitude {
               type decimal64 {
                 fraction-digits 16;
               }
               units "decimal degrees";
               description
                 "Значение долготы на астрономическом теле. Определение и
                  точность этого значения зависят от reference-frame.";
             }
             leaf height {
               type decimal64 {
                 fraction-digits 6;
               }
               units "meters";
               description
                 "Высота от нулевого уровня, задаваемого reference-frame.";
             }
           }
           case cartesian {
             leaf x {
               type decimal64 {
                 fraction-digits 6;
               }
               units "meters";
               description
                 "Значение X в системе отсчёта reference-frame.";
             }
             leaf y {
               type decimal64 {
                 fraction-digits 6;
               }
               units "meters";
               description
                 "Значение Y в системе отсчёта reference-frame.";
             }
             leaf z {
               type decimal64 {
                 fraction-digits 6;
               }
               units "meters";
               description
                 "Значение Z в системе отсчёта reference-frame.";
             }
           }
         }
         container velocity {
           description
             "Если объект движется, вектор скорости описывает это
              движение в момент, указанный временной меткой. Для 
              преобразования этих значений в скорость и курс служит
              формула из RFC 9179.";
           reference
             "RFC 9179: A YANG Grouping for Geographic Locations";

           leaf v-north {
             type decimal64 {
               fraction-digits 12;
             }
             units "meters per second";
             description
               "Составляющая скорости в направлении истинного севера 
                в системе координат geodetic-system.";
           }

           leaf v-east {
             type decimal64 {
               fraction-digits 12;
             }
             units "meters per second";
             description
               "Составляющая скорости перпендикулярно к направлению на 
                истинный север в системе координат geodetic-system.";
           }

           leaf v-up {
             type decimal64 {
               fraction-digits 12;
             }
             units "meters per second";
             description
               "Составляющая скорости в направлении от центра масс
                астрономического тела.";
           }
         }
         leaf timestamp {
           type yang:date-and-time;
           description
             "Время записи скорости.";
         }
         leaf valid-until {
           type yang:date-and-time;
           description
             "Временная метка, с которой связано местоположение.
              При отсутствии метки местоположение не связано с
              временем.";
         }
       }
     }
   }
   <CODE ENDS>

4. Соответствие ISO 6709:2008

В приложении к [ISO.6709.2008] задан набор тестов на соответствие стандарту. Эти тесты и результаты их выполнения приведены в таблице 1 с объяснением причин неприменимости некоторых тестов.

Таблица 1. Результаты тестов на соответствие.

 

Тест

Описание

Пояснение

A.1.2.1

Элементы, требуемые для определения положения географической точки

CRS3 указывается всегда

A.1.2.2

Описание CRS из реестра

Реестр CRS определён

A.1.2.3

Определение CRS

CRS не определяется

A.1.2.4

Представление горизонтальной позиции

Широта и долгота соответствуют

A.1.2.5

Представление вертикальной позиции

Высота соответствует

A.1.2.6

Представление текстовых строк

Строки не применяются

 

Для теста A.1.2.1 объект YANG geo-location включает CRS (reference-frame) или имеет принятое по умолчанию значение [WGS84].

Теста A.1.2.3 не применим, поскольку своя CRS не определяется.

Тест A.1.2.6 не применим по причине отсутствия текстовых строк.

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

Объект geo-location, определённый в этом документе, и модуль YANG разработаны для применения в широком наборе приложений. Это включает способность указывать местоположение на астрономических телах, отличных от Земли, и использовать совершенно разные системы отсчёта и «реальности».

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

Для проверки переносимости при разработке модуля рассматривались описанные ниже стандарты и API.

5.1.1. Значение IETF URI

В [RFC5870] задано стандартное значение URI для данных о географическом местоположении, включающее возможность указать geodetic-value (называется crs) с принятым по умолчанию значением wgs-84 [WGS84]. Для данных о местоположении поддерживаются 2 или 3 координаты, определяемые значением crs. Для точности задано единственное значение u, указывающее погрешность в долях метра, применяемую ко всем значениям местоположения. Поскольку URI является строкой, все значения указываются строками и могут поддерживать нужную точность.

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

5.1.2. W3C

W3C задаёт API геолокации в [W3CGEO]. Ниже приведён фрагмент кода, задающий данные геолокации для этого API. Интерфейс применяется во многих приложениях (например, Google Maps API).

   interface GeolocationPosition {
     readonly attribute GeolocationCoordinates coords;
     readonly attribute DOMTimeStamp timestamp;
   };

   interface GeolocationCoordinates {
     readonly attribute double latitude;
     readonly attribute double longitude;
     readonly attribute double? altitude;
     readonly attribute double accuracy;
     readonly attribute double? altitudeAccuracy;
     readonly attribute double? heading;
     readonly attribute double? speed;
   };

Рисунок 1. Фрагмент кода с определением геолокации.

5.1.2.1. Сравнение с моделью данных YANG

Таблица 2.

Поле

Тип

YANG

Тип

 accuracy
 double
 coord-accuracy
 dec64 fr 6
 altitude
 double
 height
 dec64 fr 6
 altitudeAccuracy
 double
 height-accuracy
 dec64 fr 6
 heading
 double
 v-north, v-east
 dec64 fr 12
 latitude
 double
 latitude
 dec64 fr 16
 longitude
 double
 longitude
 dec64 fr 16
 speed
 double
 v-north, v-east
 dec64 fr 12
 timestamp
 DOMTimeStamp
 timestamp
 string

accuracy (double)

Точность значений latitude и longitude в метрах4.

altitude (double)

Высота в метрах над уровнем эллипсоида [WGS84] (необязательно).

altitudeAccuracy (double)

Точность значения altitude в метрах (необязательно).

heading (double)

Направление (по часовой стрелке) в градусах относительно истинного севера (необязательно).

latitude, longitude (double)

Стандартные значения широты и долготы в угловых градусах.

speed (double)

Курсовая скорость в м/сек.

timestamp (DOMTimeStamp)

Число миллисекунд с начала UNIX Epoch в виде 64-битового целого числа без знака. Модель данных YANG определяет временную метку с произвольно высокой точностью, используя строковое представление значений.

Значения W3C API можно сопоставить с группировкой YANG, учитывая возможную потерю точности (в предельных случаях), связанную с применением в YANG формата чисел decimal64 вместо double в W3C API.

Со значениями W3C можно напрямую сопоставить лишь значения YANG для Земли, использующие принятое по умолчанию значение wgs-84 [WGS84] для geodetic-datum, поскольку W3C не поддерживает других систем отсчёта, доступных в группировке YANG.

5.1.3. GML

В ISO принят язык географической разметки (Geography Markup Language или GML), определённый в OGC 07-036 [OGC], как стандарт [ISO.19136.2007]. GML определяет наряду с другими тип позиции gml:pos в форме последовательности значений double, представляющей координаты в данной CRS. CRS наследуется от содержащихся элементов или задаётся напрямую атрибутом srsName и необязательным srsDimension в gml:pos.

GML задаёт тип Abstract CRS, из которого выводятся типы Concrete CRS, что позволяет задать множество определений типов CRS. Здесь рассматривается тип Geodetic CRS, который может использовать эллипсоидальные или декартовы координаты. Предполагается, что неземные и виртуальные CRS также следует представлять типами GML CRS.

Значения GML gml:pos можно напрямую сопоставить с группировкой YANG, учитывая возможную потерю точности (в предельных случаях), связанную с применением в YANG формата чисел decimal64 вместо double в GML.

Сопоставление значений группировки YANG с GML полностью поддерживается лишь для связанных с Землёй геодезических систем.

GML определяет значение наблюдения gml:Observation, включающее временную метку gml:validTime в дополнение к таким компонентам, как gml:using, gml:target, gml:resultOf. Сопоставление с группировкой YANG (и обратно) возможно лишь для метки времени. Значение gml:validTime может быть мгновенным измерением (gml:TimeInstant) или интервалом времени (gml:TimePeriod). Мгновенные значения gml:TimeInstant сопоставимы с YANG timestamp (и обратно), а значения gml:TimePeriod (вплоть до секунд) можно сопоставить с помощью узла valid-until в группировке YANG.

5.1.4. KML

Язык KML 2.2 [KML22] (ранее Keyhole Markup Language) был представлен Google в Open Geospatial Consortium (https://www.opengeospatial.org/) и принят им. Последней версией на момент написания этого документа была KML 2.3 [KML23]. Эта схема включает данные географического местоположения в некоторые из своих объектов (например, kml:Point или kml:Camera). Данные представляются в форме строк и соответствуют значениям, заданным в [W3CGEO]. Значение временной метки также представляется строкой (как и в группировке YANG).

В KML есть специальная обработка высоты, полезная для программ визуализации, kml:altitudeMode. Значения для kml:altitudeMode включают clampToGround, которое задаёт игнорирование высоты, relativeToGround, указывающее высоту относительно уровня земли в точке размещения, или absolute, задающее абсолютное значение высоты в геодезической системе. Группировка YANG может напрямую отображать абсолютные значения, но не поддерживает сопоставление с относительными.

В дополнение к kml:altitudeMode модель KML определяет два значения глубины морского дна, используя kml:seaFloorAltitudeMode. Одно значение (clampToSeaFloor) задаёт игнорирование глубины, другое (relativeToSeaFloor) — глубину от поверхности (уровня моря). Группировка YANG поддерживает игнорирование, но не поддерживает относительную глубину.

В значениях местоположения в KML используются геодезические данные, определённые в Приложении A к [ISO.19136.2007] с идентификатором LonLat84_5773. Значение высоты для режима абсолютной высоты в KML измеряется от уровня, заданного в [WGS84].

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

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

6.1. Реестр значений Geodetic System

Агентство IANA создало реестр Geodetic System Values внутри реестра YANG Geographic Location Parameters. Этот реестр содержит имена стандартных геодезических систем. Значения зачастую содержат несколько имён, например, полные имена и сокращения. Реестр предназначен для указания стандартных имён каждой геодезической системы.

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

Каждой записи должно быть достаточно для определения значений двух координат и высоты, если она требуется. Например, wgs-84 задан как WGS-84 с обновлением геоида для значений высоты как минимум до [EGM96]. Специальные записи [EGM96] и [EGM08] указаны для случаев, когда требуется более точное определение данных.

Следует отметить, что [RFC5870] также создал реестр для геодезических систем (‘geo’ URI ‘crs’ Parameter Values), однако для этого реестра заданы очень строгие правила внесения изменений. Авторы [RFC5870] поставили перед собой цель усложнить регистрацию CRS для предотвращения избыточного их числа. Поскольку этот модуль задаёт альтернативные системы и имеет более широкую область действия (не только Земля), указанный здесь реестр упрощает внесение изменений.

Значения добавляются в реестр по процедуре First Come First Served [RFC8126], поскольку целью является лишь предотвращение дубликатов.

Значение Reference должно указывать документ или контактное лицо, как указано в [RFC8126]. Поле Change Controller (т. е. владелец) также определено в [RFC8126].

Исходные значения реестра приведены в таблице 3 и включают систему отсчёта, связанную с Луной [MEAN-EARTH].

Таблица 3.

 

Имя

Описание

Документ

Контролёр изменений

me

Mean Earth/Polar Axis (Moon)

RFC 9179

IETF

wgs-84-96

World Geodetic System 1984

RFC 9179

IETF

wgs-84-08

World Geodetic System 1984

RFC 9179

IETF

wgs-84

World Geodetic System 1984

RFC 9179

IETF

 

6.2. Обновление реестра IETF XML

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

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

6.3. Обновление реестра YANG Module Names

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020] в соответствии с [RFC6020]

   Name:  ietf-geo-location
   Maintained by IANA:  N
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-geo-location
   Prefix:  geo
   Reference:  RFC 9179

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

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

Модель контроля доступа NETCONF [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

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

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

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

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

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

[EGM08] Pavlis, N., Holmes, S., Kenyon, S., and J. Factor, «An Earth Gravitational Model to Degree 2160: EGM08.», Presented at the 2008 General Assembly of the European Geosciences Union, Vienna, April 2008.

[EGM96] Lemoine, F., Kenyon, S., Factor, J., Trimmer, R., Pavlis, N., Chinn, D., Cox, C., Klosko, S., Luthcke, S., Torrence, M., Wang, Y., Williamson, R., Pavlis, E., Rapp, R., and T. Olson, «The Development of the Joint NASA GSFC and the National Imagery and Mapping Agency (NIMA) Geopotential Model EGM96.», NASA/TP-1998-206861, July 1998.

[ISO.6709.2008] International Organization for Standardization, «Standard representation of geographic point location by coordinates», ISO 6709:2008, 2008.

[MEAN-EARTH] NASA, «A Standardized Lunar Coordinate System for the Lunar Reconnaissance Orbiter», Version 4, Goddard Space Flight Center, May 2008.

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

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

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

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

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

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

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

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

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

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

[WGS84] National Imagery and Mapping Agency, «Department of Defense World Geodetic System 1984», NIMA TR8350.2, Third Edition, January 2000.

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

[ISO.19136.2007] International Organization for Standardization, «Geographic information — Geography Markup Language (GML)», ISO 19136:2007.

[KML22] Wilson, T., Ed., «OGC KML», Version 2.2, April 2008, <https://portal.opengeospatial.org/files/?artifact_id=27810>.

[KML23] Burggraf, D., Ed., «OGC KML», Version 2.3, August 2015, <https://docs.opengeospatial.org/is/12-007r2/12-007r2.html>.

[OGC] OpenGIS, «OpenGIS Geography Markup Language (GML) Encoding Standard», Version: 3.2.1, OGC 07-036, August 2007, <https://portal.ogc.org/files/?artifact_id=20509>.

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

[RFC5870] Mayrhofer, A. and C. Spanring, «A Uniform Resource Identifier for Geographic Locations (‘geo’ URI)», RFC 5870, DOI 10.17487/RFC5870, June 2010, <https://www.rfc-editor.org/info/rfc5870>.

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

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

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

[W3CGEO] Popescu, A., «Geolocation API Specification», 2nd Edition, November 2016, <https://www.w3.org/TR/2016/REC-geolocation-API-20161108/>.

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

Ниже показан вымышленный модуль, использующий группировку geo-location.

   module example-uses-geo-location {
     namespace
       "urn:example:example-uses-geo-location";
     prefix ugeo;
     import ietf-geo-location { prefix geo; }
     organization "Организация";
     contact "Example Author <eauthor@example.com>";
     description
       "Пример использования geo-location";
     revision 2022-02-11 { reference "None"; }
     container locatable-items {
       description
         "Контейнер с элементами геолокации.";
       list locatable-item {
         key name;
         description
           "Элемент геолокации";
         leaf name {
           type string;
           description
             "Имя элемента геолокации";
         }
         uses geo:geo-location;
       }
     }
   }

Рисунок 2. Пример модуля YANG, использующего геолокацию.

Ниже показано дерево YANG для вымышленного модуля, использующего группировку geo-location.

     module: example-uses-geo-location
       +--rw locatable-items
          +--rw locatable-item* [name]
             +--rw name            string
             +--rw geo-location
                +--rw reference-frame
                |  +--rw alternate-system?    string
                |  |       {alternate-systems}?
                |  +--rw astronomical-body?   string
                |  +--rw geodetic-system
                |     +--rw geodetic-datum?    string
                |     +--rw coord-accuracy?    decimal64
                |     +--rw height-accuracy?   decimal64
                +--rw (location)?
                |  +--:(ellipsoid)
                |  |  +--rw latitude?    decimal64
                |  |  +--rw longitude?   decimal64
                |  |  +--rw height?      decimal64
                |  +--:(cartesian)
                |     +--rw x?           decimal64
                |     +--rw y?           decimal64
                |     +--rw z?           decimal64
                +--rw velocity
                |  +--rw v-north?   decimal64
                |  +--rw v-east?    decimal64
                |  +--rw v-up?      decimal64
                +--rw timestamp?         yang:date-and-time
                +--rw valid-until?       yang:date-and-time

Рисунок 3. Пример дерева YANG, использующего геолокацию.

Ниже приведён пример данных YANG XML для вымышленного модуля, использующего группировку geo-location.

   <locatable-items xmlns="urn:example:example-uses-geo-location">
     <locatable-item>
       <name>Gaetana's</name>
       <geo-location>
         <latitude>40.73297</latitude>
         <longitude>-74.007696</longitude>
       </geo-location>
     </locatable-item>
     <locatable-item>
       <name>Pont des Arts</name>
       <geo-location>
         <timestamp>2012-03-31T16:00:00Z</timestamp>
         <latitude>48.8583424</latitude>
         <longitude>2.3375084</longitude>
         <height>35</height>
       </geo-location>
     </locatable-item>
     <locatable-item>
       <name>Saint Louis Cathedral</name>
       <geo-location>
         <timestamp>2013-10-12T15:00:00-06:00</timestamp>
         <latitude>29.9579735</latitude>
         <longitude>-90.0637281</longitude>
       </geo-location>
     </locatable-item>
     <locatable-item>
       <name>Apollo 11 Landing Site</name>
       <geo-location>
         <timestamp>1969-07-21T02:56:15Z</timestamp>
         <reference-frame>
           <astronomical-body>moon</astronomical-body>
           <geodetic-system>
             <geodetic-datum>me</geodetic-datum>
           </geodetic-system>
         </reference-frame>
         <latitude>0.67409</latitude>
         <longitude>23.47298</longitude>
       </geo-location>
     </locatable-item>
     <locatable-item>
       <name>Reference Frame Only</name>
       <geo-location>
         <reference-frame>
           <astronomical-body>moon</astronomical-body>
           <geodetic-system>
             <geodetic-datum>me</geodetic-datum>
           </geodetic-system>
         </reference-frame>
       </geo-location>
     </locatable-item>
   </locatable-items>

Рисунок 4. Пример данных XML с геолокацией.

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

Автор благодарит Jim Biard и Ben Koziol за рецензии и предложенные улучшения. Спасибо Peter Lothberg за мотивацию и помощь с полезным определением географического местоположения объекта, а также Acee Lindem и Qin Wu за их работу над объектом географического местоположения, которая привела к созданию этого документа. Спасибо куратору (Document Shepherd) Kent Watsen.

Адрес автора

Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org

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

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

nmalykh@protokols.ru

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

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

3Coordinate Reference System — система отсчёта координат.

4Представляется странным указание точности угловых величин в метрах, однако в спецификации [W3CGEO] указано именно так. Прим. перев

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

RFC 9195 A File Format for YANG Instance Data

Internet Engineering Task Force (IETF)                        B. Lengyel
Request for Comments: 9195                                      Ericsson
Category: Standards Track                                      B. Claise
ISSN: 2070-1721                                                   Huawei
                                                           February 2022

A File Format for YANG Instance Data

Формат файла для экземпляра данных YANG

PDF

Аннотация

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

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

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

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

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

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

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

Требуется документировать данные, определённые в моделях YANG, когда работающий сервер недоступен. Данные часто нужны в процессе разработки, при реализации или даже позже при недоступности работающего сервера. Для обеспечения такой (offline) доставки данных этот документ задаёт стандартный формат для наборов данных и файлов экземпляров данных YANG. Формат набора данных экземпляра задан в модуле YANG ietf-yang-instance-data (3. Модель YANG для данных экземпляра). Модель данных YANG в этом документе соответствует архитектуре хранилища данных управления сетью (Network Management Datastore Architecture или NMDA), заданной в [RFC8342].

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

UC1

Документирование возможностей сервера.

UC2

Предварительная загрузка заданных по умолчанию данных.

UC3

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

UC4

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

UC5

Сохранение данных диагностики.

UC6

Возможность передачи экземпляра данных YANG в сообщениях обмена между процессами (inter-process communication или IPC).

UC7

Использование заданных по умолчанию данных в качестве шаблона.

UC8

Предоставление примеров данных в RFC и Internet-draft.

Первые три варианта применения описаны в Приложении B.

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

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

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

Instance Data — данные экземпляра

Набор созданных узлов данных.

Instance Data Set — набор данных экземпляра

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

Instance Data File — файл данных экземпляра

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

Content-schema — схема содержимого

Набор модулей YANG с их выпусками, поддерживаемыми функциями (feature) и отклонениями (deviation) для которых набор данных экземпляра содержит данные.

Content-defining YANG Module — определяющий содержимое модуль YANG

Отдельный модуль YANG из content-schema.

Термин «сервер» определён в [RFC8342].

1.2. Принципы

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

P1

Нужно определить стандартные форматы кодирования на основе XML и JSON.

P2

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

P3

Нужно определить метаданные для набора данных экземпляра (2. Формат файла данных экземпляра).

P4

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

P5

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

P6

Нужно разрешать частичные наборы данных.

P7

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

P8

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

1.3. Доставка данных экземпляра

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

Другие наборы данных экземпляра могут предоставляться самим сервером YANG, например, при документировании данных диагностики (UC5).

1.4. Жизненный цикл данных

Набор данных экземпляра YANG создаётся в конкретный момент времени. Если данные меняются после этого, набор больше не будет представлять их, пока не будет обновлён. Текущие значения можно извлечь в процессе работы через NETCONF/RESTCONF или получить, например, в уведомлении YANG-Push.

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

2. Формат файла данных экземпляра

Файл данных экземпляра YANG должен содержать один набор данных экземпляра без дополнительных данных.

Формат набора данных экземпляра задан в модуле YANG ietf-yang-instance-data. Набо состоит из заголовка и содержимого. Заголовок содержит метаданные для набора данных экземпляра, а content-data, заданные как узел anydata, — данные экземпляра, которые пользователь хочет документировать и/или предоставить. Синтаксис и семантику content-data определяет content-schema.

Заданы два формата на основе кодировок YANG XML и JSON. Форматы файлов обеспечиваются путём применения соответствующих правил кодирования XML или JSON к включённой в этот документ структуре YANG. По мере определения иных кодировок YANG (например, CBOR) могут быть заданы другие форматы данных экземпляра.

Элемент content-data должен соответствовать content-schema с учётом приведённых ниже исключений. Для content-data нужно следовать правилам кодирования XML [RFC7950] или JSON [RFC7951] и должны применяться символы UTF-8. В content-data можно включать:

  • метаданные, определённые в [RFC7952];

  • источник метаданных, как указано в [RFC8526] и [RFC8527];

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

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

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

Файлы данных экземпляра могут содержать частичные наборы данных. Это означает, что ограничения mandatory, min-elements, require-instance true, must, when можно не соблюдать.

Для имени файла данных экземпляра следует использовать форму (нотация ABNF [RFC5234])

      instance-data-set-name ["@" ( revision-date / timestamp ) ]
                     ( ".xml" / ".json" )

Примерами имён служат acme-router-modules.xml, acme-router-modules@2018-01-25.xml,acme-router-modules@2018-01-25T15_06_34_3+01_00.json.

При наличии узла name в заголовке данных экземпляра его значение следует использовать как instance-data-set-name в имени файла. При наличии revision-date в имени файла значение должно соответствовать формату листа revision-date в модели YANG. При наличии revision-date и имени файла и заголовке данных экземпляра дата выпуска в имени файла должна соответствовать последнему выпуску в наборе данных экземпляра. При наличии timestamp в имени файла метка должна соответствовать формату листа timestamp в модели YANG за исключением описанной ниже замены двоеточий (:). При наличии timestamp в заголовке и имени файла для метки в имени следует использовать timestamp в наборе данных экземпляра с заменой двоеточий символом подчёркивания (_).

Метаданные со сведениями о наборе данных должны быть включены. Некоторые элементы метаданных определены в модуле YANG ietf-yang-instance-data, но можно применять другие элементы.

Метаданные должны включать версию формата данных экземпляра YANG (если она не задана явно, используется принятое по умолчанию значение). В метаданные следует включать:

  • имя набора данных;

  • спецификацию content-schema (т. е. узел content-schema);

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

  • индикацию включения заданных по умолчанию данных; для обработки таких данных применяются концепции [RFC6243], однако пользователи набора данных экземпляра не обязаны поддерживать [RFC6243].

2.1. Задание схемы содержимого

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

Встраивание (Inline)

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

Упрощённое встраивание

Включение информации в набор данных экземпляра с использованием лишь name и revision-date из модулей.

URI

Включения URI со ссылкой на дугой файл данных экземпляра YANG. Этот файл будет использовать ту же content-schema, что и указанный файл данных экземпляра YANG (чтобы не повторять снова и снова).

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

Отметим, что заданная схема содержимого (content-schema) лишь указывает набор модулей, использованных для определения этого набора данных экземпляра YANG. Иногда данные экземпляра могут применяться для сервера, поддерживающего иной набор модулей YANG (например, для предварительной загрузки принятых по умолчанию данных — UC2, где набор данных экземпляра YANG может не меняться при обновлении модулей на сервере). Возможность использования набора данных экземпляра с другой схемой содержимого зависит от многих факторов, включая различия в совместимости между схемами при рассмотрении модулей, выпусков, свойств (feature), отклонений (deviation), области действия данных экземпляра и т. п.

2.1.1. Встраивание (Inline)

Узел данных anydata inline-yang-library содержит данные экземпляра (в соответствии с ietf-yang-library@2019-01-04) [RFC8525], которые задают определяющие содержимое модули YANG, включая выпуск, поддерживаемые функции (feature), отклонения (deviation) и любые дополнительные данные. Пример встраивания приведён в параграфе 2.2.1.

2.1.2. Упрощённое встраивание

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

2.1.3. Метод URI

В лист same-schema-as-file нужно включить URI другого файла данных экземпляра YANG. Текущий файл данных экземпляра будет использовать ту же схему content-schema, что и указанный файл. Указанный файл данных экземпляра может не включать content-data, если он служит лишь для задания content-schema. Если указанный ссылкой файл недоступен, схема содержимого будет неизвестна.

Метод URI удобен, когда пользователь хочет сократить издержки, связанные с заданием content-schema в каждом файле данных экземпляра, например, в варианте UC6, когда система создаёт файл диагностики каждую минуту для документирования состояния сервера. Пример метода URI представлен в параграфе 2.2.3.

2.2. Примеры

2.2.1. Документирование возможностей сервера

Пример файла acme-router-modules@2022-01-20.xml отражает вариант UC1 из раздела 1 и предоставляет список поддерживаемых модулей YANG и возможностей NETCONF на сервере. Для задания content-schema служит метод inline. В примере применяется фальцовка, описанная в [RFC8792].

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   <?xml version="1.0" encoding="UTF-8"?>
   <instance-data-set xmlns=\
       "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
     <name>acme-router-modules</name>
     <content-schema>
       <inline-yang-library>
         <modules-state \
           xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
           <module>
             <name>ietf-yang-library</name>
             <revision>2019-01-04</revision>
           </module>
           <module>
             <name>ietf-netconf-monitoring</name>
             <revision>2010-10-04</revision>
           </module>
         </modules-state>
       </inline-yang-library>
     </content-schema>
     <revision>
       <date>2020-10-23</date>
       <description>Исходный выпуск</description>
     </revision>
     <description>Задает минимальный набор модулей, которые будет \
         включать каждый маршрутизатор acme-router. Этот набор будет \
         меняться лишь при обновлении выпуска программ.</description>
     <contact>info@acme.example.com</contact>
     <content-data>
       <modules-state \
           xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
         <module>
           <name>ietf-yang-library</name>
           <revision>2019-01-04</revision>
           <namespace>\
             urn:ietf:params:xml:ns:yang:ietf-yang-library\
           </namespace>
           <conformance-type>implement</conformance-type>
         </module>
         <module>
           <name>ietf-system</name>
           <revision>2014-08-06</revision>
          <namespace>urn:ietf:params:xml:ns:yang:ietf-system</namespace>
           <feature>sys:authentication</feature>
           <feature>sys:local-users</feature>
           <deviation>
             <name>acme-system-ext</name>
             <revision>2018-08-06</revision>
           </deviation>
           <conformance-type>implement</conformance-type>
         </module>
         <module>
           <name>ietf-netconf-monitoring</name>
           <revision>2010-10-04</revision>
           <namespace>\
             urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring\
           </namespace>
           <conformance-type>implement</conformance-type>
         </module>
         <module>
           <name>ietf-yang-types</name>
           <revision>2013-07-15</revision>
           <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-types\
             </namespace>
           <conformance-type>import</conformance-type>
         </module>
         <module>
           <name>acme-system-ext</name>
           <revision>2018-08-06</revision>
           <namespace>\
             urn:rdns:acme.example.com:oammodel:acme-system-ext\
           </namespace>
           <conformance-type>implement</conformance-type>
         </module>
       </modules-state>
       <netconf-state \
           xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
         <capabilities>
           <capability>\
             urn:ietf:params:netconf:capability:validate:1.1\
           </capability>
         </capabilities>
       </netconf-state>
     </content-data>
   </instance-data-set>

Рисунок 1.

2.2.2. Предварительно загруженные данные конфигурации по умолчанию

Пример файла read-only-acm-rules@2022-01-20.xml отражает вариант UC2 из раздела 1 и представляет принятый по умолчанию набор правил для оператора, которому доступно лишь считывание. Для указания content-schema применяется метод simplified-inline.

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   <?xml version="1.0" encoding="UTF-8"?>
   <instance-data-set
       xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
     <name>read-only-acm-rules</name>
     <content-schema>
       <module>ietf-netconf-acm@2018-02-14</module>
     </content-schema>
     <revision>
       <date>2018-07-04</date>
       <description>Исходный выпуск</description>
     </revision>
     <description>Принятые по умолчанию правила доступа, разрешающие \
         лишь чтение. Набор правил будет меняться лишь при установке \
         нового выпуска программ.</description>
     <content-data>
       <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
         <enable-nacm>true</enable-nacm>
         <read-default>deny</read-default>
         <exec-default>deny</exec-default>
         <rule-list>
           <name>read-only-role</name>
           <group>read-only-group</group>
           <rule>
             <name>read-all</name>
             <module-name>*</module-name>
             <access-operation>read</access-operation>
             <action>permit</action>
           </rule>
         </rule-list>
       </nacm>
     </content-data>
   </instance-data-set>

Рисунок 2.

2.2.3. Сохранение данных диагностики

Пример файла acme-router-netconf-diagnostics@2018-01-25T17_00_38Z.json отражает вариант UC5 из раздела 1. Набор данных экземпляра содержит статистику сервера NETCONF, отдаваемую сервером каждые 15 минут. Новый набор данных создаётся периодически много раз в день и дата выпуска не имеет смысла, поэтому включена метка времени.

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   {
     "ietf-yang-instance-data:instance-data-set": {
       "name": "acme-router-netconf-diagnostics",
       "content-schema": {
         "same-schema-as-file": "file:///acme-diagnostics-schema.json"
       },
       "timestamp": "2018-01-25T17:00:38Z",
       "description":  ["Статистика NETCONF. \
           Данные могут меняться каждый раз."],
       "content-data": {
         "ietf-netconf-monitoring:netconf-state": {
           "statistics": {
             "netconf-start-time ": "2018-12-05T17:45:00Z",
             "in-bad-hellos ": "32",
             "in-sessions ": "397",
             "dropped-sessions ": "87",
             "in-rpcs ": "8711",
             "in-bad-rpcs ": "408",
             "out-rpc-errors ": "408",
             "out-notifications": "39007"
           }
         }
       }
     }
   }

Рисунок 3.

3. Модель YANG для данных экземпляра

3.1. Диаграмма дерева

Диаграмма дерева использует нотацию, определённую в [RFC8340].

   module: ietf-yang-instance-data
     structure instance-data-set:
       +--name?                string
       +--format-version?      string
       +--includes-defaults?   enumeration
       +--content-schema
       |  +--(content-schema-spec)?
       |     +--:(simplified-inline)
       |     |  +--module*                module-with-revision-date
       |     +--:(inline)
       |     |  +--inline-yang-library    <anydata>
       |     +--:(uri)
       |        +--same-schema-as-file?   inet:uri
       +--description*         string
       +--contact?             string
       +--organization?        string
       +--datastore?           ds:datastore-ref
       +--revision* [date]
       |  +--date           string
       |  +--description?   string
       +--timestamp?           yang:date-and-time
       +--content-data?        <anydata>

3.2. Модель YANG

Этот модуль YANG импортирует определения типов мз [RFC6991], [RFC6243], идентификаторы из [RFC8342] и расширение structure из [RFC8791]. Модуль также ссылается на [RFC8525].

   <CODE BEGINS> file "ietf-yang-instance-data@2022-02-17.yang"
   module ietf-yang-instance-data {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data";
     prefix yid;

     import ietf-yang-structure-ext {
       prefix sx;
       reference
         "RFC 8791: YANG Data Structure Extensions";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-netconf-with-defaults {
       prefix ncwd;
       reference
         "RFC 6243: With-defaults Capability for NETCONF";
     }

     organization
       "IETF NETMOD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Author:  Balazs Lengyel
           <mailto:balazs.lengyel@ericsson.com> 

        Author:  Benoit Claise
           <mailto:benoit.claise@huawei.com>"; 
     description
       "The module defines the structure and content of YANG
        instance data sets.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-02-17 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9195: YANG Instance Data File Format";
     }

     typedef module-with-revision-date {
       type string {
         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'
               + '(@\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1]))?';
         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
       }
       description
         "Тип, задающий имя модуля и необязательную дату выпуска,
          например, ietf-yang-library@2019-01-04.";
     }

     sx:structure instance-data-set {
       description
         "Структура, задающая формат данных экземпляра YANG. Большинство
          узлов YANG предоставляет метаданные об экземпляре данных, а
          сам экземпляр содержится лишь в узле content-data.";
       leaf name {
         type string;
         description
           "Произвольное имя набора данных экземпляра YANG, применяемое
            в основном для описания. Однако при сохранении набора данных
            экземпляра в файле имя файла ДОЛЖНО кодировать значение name
            в соответствии с разделом 2 в RFC 9195.";
       }
       leaf format-version {
         type string {
           pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
         }
         default "2022-01-20";
         description
           "Для кодирования этого instance-data-set применяется revision
            из модуля ietf-yang-instance-data.";
       }
       leaf includes-defaults {
         type ncwd:with-defaults-mode;
         default "report-all";
         description
           "Указывает, как узлы с заданными по умолчанию значениями 
            представляются для узлов данных из instance-data-set.

            Используются некоторые определения из раздела 3 в RFC 6243,
            но значение применяется в контексте файла данных экземпляра, 
            а не запроса NETCONF с параметром <with-defaults>.

            Для файлов JSON кодирование опции report-all-tagged задано в
            параграфе 4.8.9 RFC 8040.";
         reference
           "RFC 6243: With-defaults Capability for NETCONF";
       }
       container content-schema {
         description
           "Схема содержимого (т. е. модули YANG), используемая для
            создания набора данных экземпляра. При отсутствии
            пользователь должен предоставить сведения из внешних
            документов.";
         choice content-schema-spec {
           description
             "Спецификация content-schema.";
           case simplified-inline {
             leaf-list module {
               type module-with-revision-date;
               min-elements 1;
               description
                 "Список определяющих содержимое модулей YANG. Значению
                  НУЖНО начинаться с имени модуля. Если модуль включает
                  оператор revision, НУЖНО включать дату выпуска в 
                  запись списка, например, ietf-yang-library@2019-01-04.

                  Использование этого leaf-list предполагает, что модули
                  применяются без отклонений и поддерживаются все 
                  функции. Указывать несколько выпусков одного модуля
                  НЕДОПУСТИМО.";
             }
           }
           case inline {
             anydata inline-yang-library {
               mandatory true;
               description
                 "Данные экземпляра, соответствующие определению
                  ietf-yang-library@2019-01-04 для набора задающих
                  содержимое этого instance-data-set модулей YANG.";
             }
           }
           case uri {
             leaf same-schema-as-file {
               type inet:uri;
               description
                 "Ссылка на другой файл данных экземпляра YANG с такой 
                  же схемой содержимого. ДОЛЖНЫ поддерживаться файлы,
                  применяющие методы inline и simplified-inline. МОГУТ
                  поддерживаться файлы, применяющие метод URI. ДОЛЖНЫ 
                  поддерживаться схемы URL file:// и https:// и МОГУТ
                  поддерживаться иные схемы.";
             }
           }
         }
       }
       leaf-list description {
         type string;
         description
           "Описание набора данных экземпляра.";
       }
       leaf contact {
         type string;
         description
           "Контактные данные человека или организации, куда следует
            направлять запросы, связанные с набором данных экземпляра.";
       }
       leaf organization {
         type string;
         description
           "Организация, отвечающая за набор данных экземпляра.";
       }
       leaf datastore {
         type ds:datastore-ref;
         description
           "Идентификатор хранилища данных, которым связан набор данных
            экземпляра, например, хранилище, откуда данные считаны или 
            куда данные были загружены, документированное хранилище
            данных. Если невозможно указать одно конкретное хранилище,
            лист ДОЛЖЕН отсутствовать. Если этого листа нет, хранилище
            остаётся незаданным.";
       }
       list revision {
         key "date";
         description
           "Наборам данных экземпляров, созданным при спецификации или
            разработке, СЛЕДУЕТ иметь хотя бы одну запись revision. Для
            каждого опубликованного изменения СЛЕДУЕТ указывать новый
            оператор revision перед имеющимися (обратный порядок).

            Когда набор данных экземпляра, считан с сервера или создан
            сервером или по иным причинам обновляется часто, НЕ СЛЕДУЕТ
            применять revision.";
         leaf date {
           type string {
             pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
           }
           description
             "Дата последнего изменения набора данных экземпляра в
              формате YYYY-MM-DD.";
         }
         leaf description {
           type string;
           description
             "Описание выпуска этого набора данных экземпляра.";
         }
       }
       leaf timestamp {
         type yang:date-and-time;
         description
           "Дата и время последнего изменения набора данных экземпляра.
            
            Когда набор данных экземпляра, считан с сервера или создан
            сервером или по иным причинам обновляется часто, СЛЕДУЕТ
            указывать timestamp.

            При наличии записей revision и timestamp в метке СЛЕДУЕТ
            указывать ту же дату, как в последнем операторе revision.";
       }
       anydata content-data {
         description
           "Фактические данные экземпляра. Данные ДОЛЖНЫ соответствовать
            модулям YANG, заданным в content-schema или иным способом.";
       }
     }
   }
   <CODE ENDS>

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

Заданный здесь модуль YANG определяет лишь структуру, задающую формат и заголовок метаданных для данных экземпляра YANG, указанных content-schema, поэтому шаблон вопросов безопасности для моделей YANG из параграфа 3.7.1 в [RFC8407] не применяется. Данные экземпляра предназначены для доступа через сохранённый файл или по протоколу или методу доступа к файлам.

Документ не задаёт методов, влияющих на поведение сервера.

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

  • userinfo, если применяется метод URI для задания content-schema и URI включает сведения о пользователе;

  • текст описания.

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

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

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

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

Документ регистрирует URI и модуль YANG.

5.1. Регистрация URI

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

   URI:  urn:ietf:params:xml:ns:yang:ietf-yang-instance-data
   Registrant Contact:  The IESG.
   XML:  N/A, запрошенный URI является пространством имён XML.

5.2. Регистрация модуля YANG

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-yang-instance-data
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-yang-instance-data
   Prefix:  yid
   Reference:  RFC 9195

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

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

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

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

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

[RFC6243] Bierman, A. and B. Lengyel, «With-defaults Capability for NETCONF», RFC 6243, DOI 10.17487/RFC6243, June 2011, <https://www.rfc-editor.org/info/rfc6243>.

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

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

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

[RFC7952] Lhotka, L., «Defining and Using Metadata with YANG», RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.

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

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

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, «YANG Library», RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «NETCONF Extensions to Support the Network Management Datastore Architecture», RFC 8526, DOI 10.17487/RFC8526, March 2019, <https://www.rfc-editor.org/info/rfc8526>.

[RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «RESTCONF Extensions to Support the Network Management Datastore Architecture», RFC 8527, DOI 10.17487/RFC8527, March 2019, <https://www.rfc-editor.org/info/rfc8527>.

[RFC8791] Bierman, A., Björklund, M., and K. Watsen, «YANG Data Structure Extensions», RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.

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

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

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

[RFC8407] Bierman, A., «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.

[RFC8632] Vallin, S. and M. Bjorklund, «A YANG Data Model for Alarm Management», RFC 8632, DOI 10.17487/RFC8632, September 2019, <https://www.rfc-editor.org/info/rfc8632>.

[RFC8641] Clemm, A. and E. Voit, «Subscription to YANG Notifications for Datastore Updates», RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.

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

[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, «A YANG Data Model for Factory Default Settings», RFC 8808, DOI 10.17487/RFC8808, August 2020, <https://www.rfc-editor.org/info/rfc8808>.

Приложение A. Совместимость с прежними версиями

Концепция совместимости с прежними версиями (backwards compatibility) и совместимые с ними изменения не определены для наборов данных экземпляра, поскольку они сильно зависят от конкретного варианта применения и схемы содержимого (content-schema).

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

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

  • Если значение записи меняется, а ключ остаётся (например, при переопределении alarm-type без смены alarm-type-id), изменение может остаться незамеченным.

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

Приложение B. Варианты применения

Это приложение не является нормативным.

B.1. Пример 1. Раннее документирование возможностей сервера

Сервер имеет много возможностей, определённых в модулях YANG, которые можно узнать от сервера про протоколу NETCONF или RESTCONF. Возможности сервера включают:

  • данные, определённые в ietf-yang-library: модуди и субмодули YANG, функции (feature), отклонения (deviation), точки монтирования схемы (schema-mount), хранилища данных ([RFC8525]);

  • поддерживаемые сигналы тревоги ([RFC8632]);

  • узлы данных и ветви с поддержкой и без поддержки уведомлений при изменении ([RFC8641]);

  • возможности NETCONF из ietf-netconf-monitoring.

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

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

Операторы часто создают свои системы NMS, в которые нужно интегрировать узлы производителей оборудования. Оператору нужно знать серверные возможности узлов сети для создания системы управления. Более того, на решение оператора о приобретении оборудования может влиять набор функций эксплуатации, администрирования и поддержки (Operations, Administration, and Maintenance или OAM), документированных как возможности сервера.

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

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

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

B.2. Пример 2. Предварительная загрузка данных

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

Производитель устройства может задать набор принятых по умолчанию групп (/nacm:nacm/groups) и правил для доступа этих групп к конкретным частям базовых моделей (/nacm:nacm/rule-list/rule).

Файлы данных экземпляров YANG можно использовать для документирования и/или предварительной загрузки принятой по умолчанию конфигурации.

B.3. Пример 3. Документирование заводских установок

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

Файлы данных экземпляров YANG можно использовать для документирования заводских настроек (см. [RFC8808]).

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

Спасибо Andy Bierman, Juergen Schoenwaelder, Rob Wilton, Joe Clarke, Kent Watsen, Martin Bjorklund, Ladislav Lhotka, Qin Wu и другим участникам рабочей группы Netmod за полезные комментарии, дискуссии и предложения.

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

Balazs Lengyel
Ericsson
Budapest
Magyar Tudosok korutja 11
1117
Hungary
Email: balazs.lengyel@ericsson.com
 
Benoit Claise
Huawei
Email: benoit.claise@huawei.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9196 YANG Modules Describing Capabilities for Systems and Datastore Update Notifications

Internet Engineering Task Force (IETF)                        B. Lengyel
Request for Comments: 9196                                      Ericsson
Category: Standards Track                                       A. Clemm
ISSN: 2070-1721                                                Futurewei
                                                               B. Claise
                                                                  Huawei
                                                           February 2022

YANG Modules Describing Capabilities for Systems and Datastore Update Notifications

Модули YANG для описания возможностей уведомлений об обновлениях системы и хранилища данных

PDF

Аннотация

Этот документ определяет модули YANG ietf-system-capabilities и ietf-notification-capabilities.

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

Модель ietf-notification-capabilities дополняет ietf-system-capabilities для указания возможностей, связанных с подпиской на уведомления YANG для обновлений хранилища данных (Subscription to YANG Notifications for Datastore Updates, RFC 8641).

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

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

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

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

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

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

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

Сведения о возможностях нужно публиковать, поскольку они являются частью интерфейса API между клиентом и сервером. Примерами служат максимальный размер данных, которые можно сохранить или передать, сведения о счётчиках (поддерживает ли узел передачу телеметрии при изменении — on-change) и т. п. Такие возможности часто зависят от реализации производителя или доступности ресурсов при развёртывании. Многие из таких возможностей специфичны для системы в целом, отдельных хранилищ данных YANG [RFC8342], конкретных частей схемы YANG или даже отдельных узлов данных. Целью этого документа является задание общего способа представления таких данных в формате, который:

  • не зависит от производителя;

  • понятен для машины;

  • доступен в процессе реализации и при работе (runtime).

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

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

Сведения о возможностях в процессе работы (runtime) требуются:

  • для приложений управления на основе модели (purely model-driven), например, браузеров NETCONF, зависящих от поддерживаемых моделей считывания и возможностей при работе, для полного использования функциональности;

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

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

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

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

Термины YANG-Push, on-change subscription (подписка на обновления), periodic subscription (периодическая подписка) определены в [RFC8641].

Термины subscriber (подписчик), publisher (издатель), receiver (получатель) определены в [RFC8639].

Термин server определён в [RFC8342].

Термины instance data file (файл данных экземпляра), instance data (данные экземпляра), instance data set (набор данных экземпляра) определены в [RFC9195].

Этот документ определяет указанные ниже термины.

Implementation-time information — сведения процесса реализации

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

Runtime information — сведения при работе

Сведения о поведении сервера, доступные от работающего экземпляра сервера по протоколам управления, таким как NETCONF [RFC6241] или RESTCONF [RFC8040].

2. Предоставление сведений о возможностях системы

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

В процессе реализации

Разработчику следует представлять возможности как файлы экземпляров данных YANG, соответствующие [RFC9195]. Когда такой файл предоставляется, он должен быть доступен во время реализации и извлекаться независимо от наличия работающего (live) узла, например, путём загрузки с web-сайта.

При работе

Возможности следует делать доступными по протоколу NETCONF [RFC6241] или RESTCONF [RFC8040] с работающего сервера (реализованного издателем). Реализациям, поддерживающим изменение возможностей в процессе работы, следует поддерживать уведомления об изменениях в контейнере system-capabilities.

Модуль ietf-system-capabilities содержит шаблон структуры для задания любых возможностей системы, связанных с YANG. Модуль ietf-notification-capabilities позволяет издателю задать возможности, связанные с подпиской на уведомления YANG об обновлениях хранилищ данных (Subscription to YANG Notifications for Datastore Updates) [RFC8641], называемые также YANG-Push и дополняющие ietf-system-capabilities.

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

3. Предоставление сведений о возможностях YANG-Push

Отдельным случаем является указание возможностей функциональности YANG-Push. Как указано в [RFC8641], издатель может позволить подписчикам подписываться на обновления от хранилища данных и последовательно выталкивать получателям уведомления о таких обновлениях. Уведомления могут отправляться периодически или при изменении (более или менее сразу после такого изменения).

Издатель, поддерживающий YANG-Push имеет множество возможностей, определенных в [RFC8641], которые часто задаются издателем в процессе реализации.

  • Поддерживаемые (сообщаемые) интервалы периодической отправки для подписки.

  • Максимальное число обектов, которые можно передать в обновлении.

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

Дополнительные возможности необязательной функции on-change включают:

  • поддерживаемые периоды «демпфирования» для подписок on-change;

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

У издателей могут быть возможности (или ограничения) для документов, например, число уведомлений или число обновлённых объектов хранилища, которые могут быть переданы за определённых интервал времени. Некоторые издатели могут не поддерживать периодической подписки для всех хранилищ. Иногда издатель, поддерживающий уведомления об изменениях, может быть неспособен выталкивать (push) обновления при изменении некоторых типов объектов. Причинами этого могут быть частые изменения данных в хранилище (например, счётчик октетов), частые и мелкие изменения, не имеющие важности для получателя (например, изменение температуры на 0,1 градуса в заданном и приемлемом диапазоне) или неспособность реализации передавать такие уведомления для некоторых уведомлений. Во всех таких случаях для приложений-подписчиков важно иметь способ объекты для которых поддерживаются и не поддерживаются уведомления об изменениях.

Поддержка уведомлений on-change не означает, что такие уведомления будут передаваться для любого конкретного узла данных, поскольку эат возможность может поддерживаться не для всех узлов. Поэтому управляющие приложения-подписчики не могут полагаться на функциональность on-change, пока они не знают, для каких объектов это поддерживается. Модели данных YANG предназначены для использования в качестве интерфейса. Без идентификации узлов данных, которые фактически поддерживают уведомления on-change, этот интерфейс может быть неполным.

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

4. Модель возможностей системы

Модуль ietf-system-capabilities задаёт структуру, которую можно использовать для обнаружения (как рабочего состояния read-only) любых возможностей системы, связанных с YANG. Сам модуль не включает каких-либо возможностей, он обеспечивает точки дополнения (augment) для возможностей, которые будут определены в последующих модулях YANG. Этот модуль используется другими модулями для дополнения сведений о конкретных возможностях. Каждый набор таких возможностей должен помещаться в контейнер под оператором augment для чёткого разделения различных групп возможностей. Эти контейнеры-оболочки нужно добавлять в /sysc:system-capabilities и /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-capabilities.

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

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

4.1. Диаграмма дерева

Диаграмма дерева использует нотацию, определённую в [RFC8340].

   module: ietf-system-capabilities
     +--ro system-capabilities
        +--ro datastore-capabilities* [datastore]
           +--ro datastore       -> /yanglib:yang-library/datastore/name
           +--ro per-node-capabilities* []
              +--ro (node-selection)?
                 +--:(node-selector)
                    +--ro node-selector?   nacm:node-instance-identifier

4.2. Модуль YANG

Этот модуль YANG импортирует определения типов из [RFC8341] и путь ссылок (reference path) из [RFC8525].

   <CODE BEGINS> file "ietf-system-capabilities@2022-02-17.yang"
   module ietf-system-capabilities {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-system-capabilities";
     prefix sysc;

     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }
     import ietf-yang-library {
       prefix yanglib;
       description
         "Этот модуль требует реализации ietf-yang-library. ТРЕБУЕТСЯ
          Revision 2019-01-04 или производный от него выпуск.";
       reference
         "RFC8525: YANG Library";
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org> 

        Editor:   Balazs Lengyel
                  <mailto:balazs.lengyel@ericsson.com>"; 
     description
       "Этот модуль задаёт структуру для указания возможностей системы
        для сервера или издателя. Возможности системы могут включать
        возможности сервера NETCONF или RESTCONF или издателя 
        уведомлений.

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

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

        ДОЛЖНА применяться одна группировка для задания иерархических
        возможностей на уровне системы и хранилища (узла данных).

        Для поиска значения возможности конкретного узла данных в 
        заданном хранилище пользователю НУЖНО следующее.

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

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

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

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-02-17 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9196: YANG Modules Describing Capabilities for Systems
          and Datastore Update Notifications";
     }

     container system-capabilities {
       config false;
       description
         "Возможности системы. Заданные здесь значения возможностей на
          уровне системы действительны для всех хранилищ данных и
          применяются, когда на уровне хранилищ или узлов данных 
          возможности не заданы.";
       /*
        * Точка добавления возможностей на уровне системы.
        */
       list datastore-capabilities {
         key "datastore";
         description
           "Значения возможностей на уровне хранилища.

            Для серверов и издателей без поддержки NMDA данные с
            config false рассматриваются как часть рабочего хранилища.";
         leaf datastore {
           type leafref {
             path
               "/yanglib:yang-library/yanglib:datastore/yanglib:name";
           }
           description
             "Хранилище, для которого заданы возможности. Указать можно
              лишь одно действительное хранилище, например, недопустимо
              использовать ds:conventional, поскольку оно представляет
              набор хранилищ конфигурации.";
         }
         list per-node-capabilities {
           description
             "Каждая запись списка задаёт возможности для выбранных 
              узлов данных. Одни и те же возможности относятся ко 
              всем узлам данных в ветвях выбранных узлов.

              Системе НУЖНО упорядочивать записи по их предпочтениям.
              Порядок записей НЕДОПУСТИМО менять, пока не меняются
              базовые возможности.

              Отметим, что самое длинное совпадение можно получить 
              путём упорядочения по размеру совпадения.";
           choice node-selection {
             description
               "Метод выбора некоторых или всех узлов в хранилище.";
             leaf node-selector {
               type nacm:node-instance-identifier;
               description
                 "Выбор узлов данных, для которых заданы возможности.
                  Значение / указывает все узлы данных в хранилище
                  в соответствии с узлом path (стр. 41 в [RFC8341]).";
               reference
                 "RFC 8341: Network Configuration Access Control Model";
             }
           }
           /*
            * Точка добавления возможностей на уровне хранилища или
            * узлов данных
            */
         }
       }
     }
   }
   <CODE ENDS>

5. Модель возможностей уведомления

Модуль YANG ietf-notification-capabilities предоставляет сведения, связанные с возможностью YANG-Push.

5.1. Диаграмма дерева

Диаграмма дерева использует нотацию, определённую в [RFC8340].

   module: ietf-notification-capabilities
     augment /sysc:system-capabilities:
       +--ro subscription-capabilities
          +--ro max-nodes-per-update?               uint32
          +--ro periodic-notifications-supported?   notification-support
          +--ro (update-period)?
          |  +--:(minimum-update-period)
          |  |  +--ro minimum-update-period?        uint32
          |  +--:(supported-update-period)
          |     +--ro supported-update-period*      uint32
          +--ro on-change-supported?                notification-support
          |       {yp:on-change}?
          +--ro minimum-dampening-period?           uint32
          |       {yp:on-change}?
          +--ro supported-excluded-change-type*     union
                  {yp:on-change}?
     augment /sysc:system-capabilities/sysc:datastore-capabilities
               /sysc:per-node-capabilities:
       +--ro subscription-capabilities
          +--ro max-nodes-per-update?               uint32
          +--ro periodic-notifications-supported?   notification-support
          +--ro (update-period)?
          |  +--:(minimum-update-period)
          |  |  +--ro minimum-update-period?        uint32
          |  +--:(supported-update-period)
          |     +--ro supported-update-period*      uint32
          +--ro on-change-supported?                notification-support
          |       {yp:on-change}?
          +--ro minimum-dampening-period?           uint32
          |       {yp:on-change}?
          +--ro supported-excluded-change-type*     union
                  {yp:on-change}?

5.2. Модуль YANG

Этот модуль YANG импортирует свойство (feature) и определения типов из [RFC8641] а также заданный выше модуль ietf-system-capabilities.

   <CODE BEGINS> file "ietf-notification-capabilities@2022-02-17.yang"
   module ietf-notification-capabilities {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities";
     prefix notc;

     import ietf-yang-push {
       prefix yp;
       description
         "Этот модуль требует реализации ietf-yang-push.";
       reference
         "RFC 8641: Subscription to YANG Notifications for
          Datastore Updates";
     }
     import ietf-system-capabilities {
       prefix sysc;
       description
         "Этот модуль требует реализации ietf-system-capabilities.";
       reference
         "RFC 9196: YANG Modules Describing Capabilities for Systems
          and Datastore Update Notifications";
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org> 

        Editor:   Balazs Lengyel
                  <mailto:balazs.lengyel@ericsson.com>"; 
     description
       "Этот модуль задаёт возможности издателя, связанные с YANG-Push
        (RFC 8641). Модуль включает:
        - спецификацию узлов данных, поддерживающих уведомления
          on-change или periodic;
        - возможности, связанные с пропускной способностью для данных
          уведомлений, которую может поддерживать издатель (отметим, что
          для конкретной подписки издатель МОЖЕТ разрешать лишь более 
          долгие интервалы или меньшие обновления в зависимости, 
          например, от фактической нагрузки).

        Значения возможностей можно задать на уровне системы (издателя), 
        хранилища данных или конкретных узлов указанного хранилища (и их
        ветвей), как указано в модуле ietf-system-capabilities.

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

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-02-17 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9196: YANG Modules Describing Capabilities for Systems
          and Datastore Update Notifications";
     }

     grouping subscription-capabilities {
       description
         "Возможности, связанные с подпиской и уведомлениями YANG-Push";
       container subscription-capabilities {
         description
           "Возможности для подписки и уведомлений YANG-Push.";
         typedef notification-support {
           type bits {
             bit config-changes {
               description
                 "Издатель способен передавать уведомления для узлов
                  config true при соответствующей области действия и
                  типе подписки.";
             }
             bit state-changes {
               description
                 "Издатель способен передавать уведомления для узлов
                  config false при соответствующей области действия и
                  типе подписки.";
             }
           }
           description
             "Определяет поддержку уведомлений on-change или periodic
              для всех узлов, узлов config false или config true и 
              отсутствие такой поддержки.

              Биты config-changes и state-changes не действуют для
              хранилищ или набора узлов данных, где нет узлов с заданным
              значением config (как будто поддержка не заявлена). 
              Примером служит указание поддержки state-changes для 
              хранилища candidate, которое не оказывает влияния.";
         }

         leaf max-nodes-per-update {
           type uint32 {
             range "1..max";
           }
           description
             "Максимальное число узлов данных для передачи в обновлении.
              Издатель МОЖЕТ поддерживать большее число и СЛЕДУЕТ
              поддерживать хотя бы указанное количество.

              Может служить для предотвращения ошибок update-too-big
              при подписке.";
           reference
             "RFC 8641: Subscription to YANG Notifications for
              Datastore Updates, the 'update-too-big' error/identity";
         }
         leaf periodic-notifications-supported {
           type notification-support;
           description
             "Указывает, способен ли издатель передавать периодические
              обновления для выбранных узлов данных, включая их ветви.";
           reference
             "RFC 8641: Subscription to YANG Notifications for
              Datastore Updates, 'periodic' subscription concept";
         }
         choice update-period {
           description
             "Поддерживаемые интервалы периодических обновлений.";
           leaf minimum-update-period {
             type uint32;
             units "centiseconds";
             description
               "Минимальный интервал для периодических обновлений.

                Запрос подписки для выбранных узлов с интервалом меньше,
                чем указан этим листом, ведёт к ошибке 
                period-unsupported.";
             reference
               "RFC 8641: Subscription to YANG Notifications for
                Datastore Updates, the period leaf in the ietf-yang-push
                YANG module";
           }
           leaf-list supported-update-period {
             type uint32;
             units "centiseconds";
             description
               "Поддерживаемый интервал периодических обновлений.

                Запрос подписки для выбранных узлов с интервалом, не
                указанным в этом leaf-list, ведёт к ошибке
                'period-unsupported.";
             reference
               "RFC 8641: Subscription to YANG Notifications for
                Datastore Updates, the period leaf in the ietf-yang-push
                YANG module";
           }
         }
         leaf on-change-supported {
           if-feature "yp:on-change";
           type notification-support;
           description
             "Указывает, способен ли издатель передавать уведомления 
              on-change для выбранных узлов данных и их ветвей.";
           reference
             "RFC 8641: Subscription to YANG Notifications for Datastore
              Updates, on-change concept";
         }
         leaf minimum-dampening-period {
           if-feature "yp:on-change";
           type uint32;
           units "centiseconds";
           description
             "Минимальный интервал демпфирования подписки on-change для
              выбранных узлов данных.

              Наличие здесь положительного значения означает 
              обязательность демпфирования.";
           reference
             "RFC 8641: Subscription to YANG Notifications for
              Datastore Updates, the dampening-period leaf in the
              ietf-yang-push YANG module";
         }
         leaf-list supported-excluded-change-type {
           if-feature "yp:on-change";
           type union {
             type enumeration {
               enum none {
                 value -2;
                 description
                   "Нельзя исключить ни один из типов изменений.";
               }
               enum all {
                 value -1;
                 description
                   "Можно исключить любую комбинацию изменений.";
               }
             }
             type yp:change-type;
           }
           description
             "Тип изменений, которые можно исключить из подписки
              YANG-Push для выбранных узлов данных.";
           reference
             "RFC 8641: Subscription to YANG Notifications for Datastore
              Updates, the change-type typedef in the ietf-yang-push
              YANG module";
         }
       }
     }

     augment "/sysc:system-capabilities" {
       description
         "Добавляет возможности на уровне системы.";
       uses subscription-capabilities {
         refine
           "subscription-capabilities/supported-excluded-change-type" {
           default "none";
         }
       }
     }

     augment "/sysc:system-capabilities/sysc:datastore-capabilities"
           + "/sysc:per-node-capabilities" {
       description
         "Добавляет возможности на уровне хранилищ и узлов данных.";
       uses subscription-capabilities {
         refine
           "subscription-capabilities/supported-excluded-change-type" {
           default "none";
         }
       }
     }
   }
   <CODE ENDS>

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

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

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

Этот документ описывает структуру для передачи сведений о возможностях системы, которые по своей природе являются гибкими и расширяемыми. Хотя все варианты применения сейчас неизвестны, они могут варьироваться в зависимости от минимального интервала периодических обновлений и протоколов, применяемых для уведомления. Знание типа значения может помочь злоумышленнику узнать, как долго могут сохраняться активными несанкционированные изменения до их обнаружения и какие каналы можно нарушить для увеличения этого срока. В документах, добавляющих возможности через операторы augment в этом модуле, рекомендуется рассматривать вопросы безопасности новых узлов YANG в соответствии с рекомендациями BCP 216 [RFC8407].

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

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

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

7.1. Реестр IETF XML

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

   URI:  urn:ietf:params:xml:ns:yang:ietf-system-capabilities
   Registrant Contact:  The IESG.
   XML:  N/A, запрошенный URI является пространством имён XML.

   URI:  urn:ietf:params:xml:ns:yang:ietf-notification-capabilities
   Registrant Contact:  The IESG.
   XML:  N/A, запрошенный URI является пространством имён XML.

7.2. Реестр YANG Module Names

Документ регистрирует модули YANG в реестре YANG Module Names [RFC6020]

   name:  ietf-system-capabilities
   namespace:  urn:ietf:params:xml:ns:yang:ietf-system-capabilities
   prefix:  sysc
   reference:  RFC 9196

   name:  ietf-notification-capabilities
   namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities
   prefix:  notc
   reference:  RFC 9196

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

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

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

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

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

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

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

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

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

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

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

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

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, «YANG Library», RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, «Subscription to YANG Notifications», RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.

[RFC8641] Clemm, A. and E. Voit, «Subscription to YANG Notifications for Datastore Updates», RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.

[RFC9195] Lengyel, B. and B. Claise, «A File Format for YANG Instance Data», RFC 9195, DOI 10.17487/RFC9195, February 2022, <https://www.rfc-editor.org/info/rfc9195>.

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

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

[RFC8407] Bierman, A., «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.

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

Приложение A. Пример экземпляра данных 1

В приведённом ниже примере применяется форматирование с фальцовкой [RFC8792].

Экземпляр данных описывает возможности уведомлений гипотетического маршрутизатора acme-router, реализующего хранилища running и operational. Каждое изменение может быть сообщено в режиме on-change из хранилища running, но из operational — лишь узлы config false и некоторые данные config false. Статистика интерфейсов не передаётся в on-change и включены лишь два важных счётчика. Возможности подписки на хранилища не сообщаются в on-change, поскольку они не меняются в процессе работы acme-router.

   ========== NOTE: '\' line wrapping per RFC 8792) ===========

   <?xml version="1.0" encoding="UTF-8"?>
   <instance-data-set xmlns=\
       "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
     <name>acme-router-notification-capabilities</name>
     <content-schema>
       <module>ietf-system-capabilities@2022-02-17</module>
       <module>ietf-notification-capabilities@2022-02-17</module>
     </content-schema>
     <description>Указывает возможности уведомлений от acme-router.
       Маршрутизатор имеет лишь хранилища running и operational. Каждое
       изменение может быть указано on-change из хранилища running, но
       из operational передаются лишь узлы config false и некоторые
       данные config false в режиме on-change. Статистика не передаётся
       on-change, за исключением двух важных счётчиков, где обязателен
       малый период демпфирования.
     </description>
     <content-data>
       <system-capabilities \
        xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities" \
        xmlns:notc=\
          "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities" \
        xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
        <notc:subscription-capabilities>
         <notc:minimum-update-period>500</notc:minimum-update-period>
         <notc:max-nodes-per-update>2000</notc:max-nodes-per-update>
         <notc:minimum-dampening-period>\
            100\
         </notc:minimum-dampening-period>
         <notc:periodic-notifications-supported>\
            config-changes state-changes\
         </notc:periodic-notifications-supported>
         <notc:on-change-supported>\
            config-changes state-changes\
         </notc:on-change-supported>
         <notc:supported-excluded-change-type>\
            all\
         </notc:supported-excluded-change-type>
        </notc:subscription-capabilities>
         <datastore-capabilities>
           <datastore>ds:operational</datastore>
           <per-node-capabilities>
             <node-selector>\
                 /if:interfaces/if:interface[if:name='lo']\
             </node-selector>
             <notc:subscription-capabilities>
               <notc:on-change-supported/>
               <notc:periodic-notifications-supported/>
             </notc:subscription-capabilities>
           </per-node-capabilities>
           <per-node-capabilities>
             <node-selector>\
                 /if:interfaces/if:interface/if:statistics/if:in-octets\
             </node-selector>
             <notc:subscription-capabilities>
               <notc:minimum-dampening-period>10
                 </notc:minimum-dampening-period>
               <notc:on-change-supported>\
                 state-changes\
               </notc:on-change-supported>
             </notc:subscription-capabilities>
           </per-node-capabilities>
           <per-node-capabilities>
             <node-selector>\
             /if:interfaces/if:interface/if:statistics/if:out-octets\
             </node-selector>
             <notc:subscription-capabilities>
               <notc:minimum-dampening-period>10
                 </notc:minimum-dampening-period>
               <notc:on-change-supported>\
                 state-changes\
               </notc:on-change-supported>
             </notc:subscription-capabilities>
           </per-node-capabilities>
           <per-node-capabilities>
             <node-selector>\
                 /if:interfaces/if:interface/if:statistics\
             </node-selector>
             <notc:subscription-capabilities>
               <notc:on-change-supported/>
             </notc:subscription-capabilities>
           </per-node-capabilities>
         </datastore-capabilities>
       </system-capabilities>
     </content-data>
   </instance-data-set>

Рисунок 1. Возможности уведомлений с настройками для узла данных.

Приложение B. Пример экземпляра данных 2

В приведённом ниже примере применяется форматирование с фальцовкой [RFC8792].

Экземпляр данных описывает возможности уведомлений гипотетического коммутатора acme-switch, реализующего хранилища running, candidate и operational. Каждое изменение может быть передано on-change из хранилища running, при изменениях в хранилище candidate не передаётся ничего, а для operational могут передаваться все узлы config false. Периодические уведомления поддерживаются для хранилищ running и operational, но не для candidate.

   ========== NOTE: '\' line wrapping per RFC 8792) ===========

   <?xml version="1.0" encoding="UTF-8"?>
   <instance-data-set xmlns=\
       "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
     <name>acme-switch-notification-capabilities</name>
     <content-schema>
       <module>ietf-system-capabilities@2022-02-17</module>
       <module>ietf-notification-capabilities@2022-02-17</module>
     </content-schema>
     <description>Возможности уведомлений acme-switch, реализующего
       хранилища running, candidate и operational. Каждое изменение
       быть передано on-change из хранилища running, ничего не 
       передаётся из candidate, а из operational передаются изменения
       для всех данных config false. Периодические уведомления
       поддерживаются для running и operational, но не для candidate.
     </description>
     <content-data>
       <system-capabilities \
        xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities" \
        xmlns:notc=\
          "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities" \
        xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
        <notc:subscription-capabilities>
         <notc:minimum-update-period>500</notc:minimum-update-period>
         <notc:max-nodes-per-update>2000</notc:max-nodes-per-update>
         <notc:minimum-dampening-period>\
           100\
         </notc:minimum-dampening-period>
         <notc:periodic-notifications-supported>\
           config-changes state-changes\
         </notc:periodic-notifications-supported>
        </notc:subscription-capabilities>
        <datastore-capabilities>
          <datastore>ds:operational</datastore>
          <per-node-capabilities>
            <node-selector>/</node-selector>
            <notc:subscription-capabilities>
              <notc:on-change-supported>\
                state-changes\
              </notc:on-change-supported>
            </notc:subscription-capabilities>
          </per-node-capabilities>
        </datastore-capabilities>
        <datastore-capabilities>
          <datastore>ds:candidate</datastore>
          <per-node-capabilities>
            <node-selector>/</node-selector>
            <notc:subscription-capabilities>
              <notc:on-change-supported/>
              <notc:periodic-notifications-supported/>
            </notc:subscription-capabilities>
          </per-node-capabilities>
        </datastore-capabilities>
        <datastore-capabilities>
         <datastore>ds:running</datastore>
          <per-node-capabilities>
            <node-selector>/</node-selector>
            <notc:subscription-capabilities>
              <notc:on-change-supported>\
                config-changes\
              </notc:on-change-supported>
            </notc:subscription-capabilities>
          </per-node-capabilities>
        </datastore-capabilities>
       </system-capabilities>
     </content-data>
   </instance-data-set>

Рисунок 2. Возможности уведомлений с настройками для хранилища данных.

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

Спасибо Andy Bierman, Juergen Schoenwaelder, Rob Wilton, Kent Watsen, Eric Voit, Joe Clarke, Martin Bjorklund, Ladislav Lhotka, Qin Wu, Mahesh Jethanandani, Ran Tao, Reshad Rahman и другим участникам рабочей группы Netmod за ценные замечания, дискуссии и отзывы.

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

Balazs Lengyel
Ericsson
Budapest
Magyar Tudosok korutja 11
1117
Hungary
Email: balazs.lengyel@ericsson.com
 
Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org
 
Benoit Claise
Huawei
George’s Court Townsend Street
Dublin 2
Ireland
Email: benoit.claise@huawei.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9181 A Common YANG Data Model for Layer 2 and Layer 3 VPNs

Internet Engineering Task Force (IETF)                        S. Barguil
Request for Comments: 9181                      O. Gonzalez de Dios, Ed.
Category: Standards Track                                     Telefonica
ISSN: 2070-1721                                        M. Boucadair, Ed.
                                                                  Orange
                                                                   Q. Wu
                                                                  Huawei
                                                           February 2022

A Common YANG Data Model for Layer 2 and Layer 3 VPNs

Базовая модель данных для VPN L2 и L3

PDF

Аннотация

Этот документ определяет модуль YANG общего назначения, который может применяться в разных модулях, связанных с VPN, таких как модели виртуальных частных сетей L3 и L2.

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

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

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

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

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

Copyright (c) 2022. Авторские права принадлежат 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 задаёт модули YANG для служб VPN, например, L3 VPN Service Model (L3SM) [RFC8299] и L2 VPN Service Model (L2SM) [RFC8466]. Другими примерами могут служить модели данных YANG L3 VPN Network Model (L3NM) [RFC9182] и L2 VPN Network Model (L2NM) [L2NM-YANG]. Имеются базовые узлы данных и структуры, присутствующие во всех или части этих моделей.

Этот документ определяет базовый модуль YANG, который может применяться связанными с VPN модулями, такими как L3NM [RFC9182] и L2NM [L2NM-YANG]: ietf-vpn-common (4. Модуль общего назначения VPN L2/3).

Модуль ietf-vpn-common включает набор идентификаторов, типов и группировок, которые могут применяться связанными с VPN модулями YANG, независимо от их уровня (например, L2, L3) и типа модуля (например, модель сети или службы), включая будущие выпуски имеющихся модулей (например, L3SM [RFC8299] и L2SM [RFC8466]).

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

Термины для описания модулей YANG определены в [RFC7950].

Значения символов в схемах деревьев описаны в [RFC8340].

Термины, связанные с VPN, определены в [RFC4026] и [RFC4176].

В документе применяется много терминов из [RFC8299] и [RFC8466] (например, Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), Massive Machine Type Communications (mMTC)).

3. Описание модуля YANG VPN общего назначения

Модуль ietf-vpn-common определяет набор связанных с VPN свойств общего назначения, включая указанные ниже.

Свойства инкапсуляции, такие как:

  • dot1Q [IEEE802.1Q];

  • QinQ [IEEE802.1ad];

  • агрегирование каналов [IEEE802.1AX];

  • виртуальные расширяемые ЛВС (Virtual eXtensible Local Area Network или VXLAN) [RFC7348].

Групповая передача[RFC6513].

Свойства маршрутизации, включая:

  • BGP [RFC4271];

  • OSPF [RFC4577] [RFC6565];

  • IS-IS [ISO10589];

  • RIP [RFC2080] [RFC2453];

  • двухстороннее обнаружение пересылки (Bidirectional Forwarding Detection или BFD) [RFC5880] [RFC7880];

  • протокол резервирования виртуального маршрутизатора (Virtual Router Redundancy Protocol или VRRP) [RFC5798].

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

service-type

Служит для идентификации типа сервиса VPN. Примеры поддерживаемых услуг включают:
  • L3VPN;
  • виртуальные частные ЛВС (Virtual Private LAN Service или VPLS) с использованием BGP [RFC4761];
  • VPLS с использованием протокола распространения меток (Label Distribution Protocol или LDP) [RFC4762];
  • виртуальные частные провода (Virtual Private Wire Service или VPWS) [RFC8214];
  • Ethernet BGP VPN на основе MPLS [RFC7432];
  • Ethernet VPN (EVPN) [RFC8365];
  • Провайдерские магистрали на основе мостов в комбинации с Ethernet VPN (Provider Backbone Bridging Combined with Ethernet VPN или PBB-EVPN) [RFC7623].

vpn-signaling-type

Служит для указания режима сигнализации данного типа сервиса. Примерами поддерживаемых типов сигнализации VPN являются:
  • L2VPN с использованием BGP [RFC6624];
  • LDP [RFC5036];
  • протокол туннелирования канального уровня (Layer Two Tunneling Protocol или L2TP) [RFC3931].

Модуль охватывает IPv4 [RFC0791] и IPv6 [RFC8200], а также включает связанные с групповой адресацией отождествления, такие как протоколы управления группами IGMPv1 (Internet Group Management Protocol version 1) [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376], протоколы обнаружения групповых получателей (Multicast Listener Discovery version 1 или MLDv1) [RFC2710], MLDv2 [RFC3810], независимая от протокола групповая передача (Protocol Independent Multicast или PIM) [RFC7761].

Читателям следует обратиться к разделу 4, где приведён полный список поддерживаемых отождествлений (отождествления, связанные с семействами адресов, топологии VPN, типы доступа в сеть, операционный и административный статус, роль сайта или узла, ограничения сервиса VPN, протоколы маршрутизации, правила импорта и экспорта маршрутов, пропускная способность, качество обслуживания — QoS и т. п.).

Модуль ietf-vpn-common содержит также набор связанных с VPN группировок. На рисунке 1 представлено дерево, указывающее группировки общего назначения для модуля ietf-vpn-common.

   module: ietf-vpn-common
     grouping vpn-description:
       +-- vpn-id?            vpn-id
       +-- vpn-name?          string
       +-- vpn-description?   string
       +-- customer-name?     string
     grouping vpn-profile-cfg:
       +-- valid-provider-identifiers
          +-- external-connectivity-identifier* [id]
          |       {external-connectivity}?
          |  +-- id   string
          +-- encryption-profile-identifier* [id]
          |  +-- id   string
          +-- qos-profile-identifier* [id]
          |  +-- id   string
          +-- bfd-profile-identifier* [id]
          |  +-- id   string
          +-- forwarding-profile-identifier* [id]
          |  +-- id   string
          +-- routing-profile-identifier* [id]
             +-- id   string
     grouping oper-status-timestamp:
       +--ro status?         identityref
       +--ro last-change?   yang:date-and-time
     grouping service-status:
       +-- status
          +-- admin-status
          |  +-- status?         identityref
          |  +-- last-change?    yang:date-and-time
          +--ro oper-status
             +--ro status?         identityref
             +--ro last-change?    yang:date-and-time
     grouping underlay-transport:
       +-- (type)?
          +--:(abstract)
          |  +-- transport-instance-id?   string
          |  +-- instance-type?           identityref
          +--:(protocol)
             +-- protocol*                identityref
     grouping vpn-route-targets:
       +-- vpn-target* [id]
       |  +-- id                  uint8
       |  +-- route-targets* [route-target]
       |  |  +-- route-target      rt-types:route-target
       |  +-- route-target-type    rt-types:route-target-type
       +-- vpn-policies
          +-- import-policy?   string
          +-- export-policy?   string
     grouping route-distinguisher:
       ...
     grouping vpn-components-group:
       +-- groups
          +-- group* [group-id]
             +-- group-id    string
     grouping placement-constraints:
       +-- constraint* [constraint-type]
          +-- constraint-type?   identityref
          +-- target
             +-- (target-flavor)?
                +--:(id)
                |  +-- group* [group-id]
                |     +-- group-id    string
                +--:(all-accesses)
                |  +-- all-other-accesses?   empty
                +--:(all-groups)
                   +-- all-other-groups?     empty
     grouping ports:
       ...
     grouping qos-classification-policy:
       ...

Рисунок 1. Базовое дерево VPN.

Описания группировок общего назначения приведены ниже.

vpn-description

Группировка YANG, предоставляющая административные сведения общего назначения о VPN, такие как идентификатор, имя, текстовое описание, имя клиента.

vpn-profile-cfg

Группировка YANG, определяющая набор действительных профилей (шифрование, маршрутизация, пересылка и пр.), которые могут быть связаны с L2/3 VPN. Этот документ не включает предположений о структуре таких профилей, но позволяет «склеивать» услугу VPN с другими параметрами, которые могут потребоваться локально для обеспечения дополнительных функций запрашивающим клиентам.
Например, сервис-провайдер может предоставлять клиенту VPN внешнюю связность (например, с частным или общественным облаком, Internet). Такая услуга может включать настройку правил фильтрации и NAT (например, связывая интерфейс виртуальной маршрутизации и пересылки VRF с экземпляром NAT, как описано в параграфе 2.10 [RFC8512]). Эти добавленные функции могут быть привязаны ко всему доступу в сети или его части. Некоторые из таких функций могут быть реализованы на границах провайдера (Provider Edge или PE), например, узел P или даже выделенный узел, на котором размещаются функции NAT.
Детализация структуры таких профилей выходит за рамки этого документа.

oper-status-timestamp

Группировка YANG, определяющая обновления рабочего состояния службы или компонент VPN.

service-status

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

underlay-transport

Группировка YANG, определяющая тип базового транспорта для услуги VPN и его установки (организации).
Базовый транспорт может указываться как экземпляр абстрактного транспорта (например, идентификатором экземпляра VPN+ [Enhanced-VPN-Framework] или виртуальной сети [ACTN-VN-YANG] [RFC8453], именем сетевого слоя [Network-Slices-Framework]) или упорядоченный список протоколов, которые будут разрешены в сети.
Модуль поддерживает большой набор идентификаторов протоколов, который может служить, например, для указания базового транспорта. Примеры поддерживаемых протоколов включают:
  • IP в IP [RFC2003] [RFC2473];
  • базовая инкапсуляция маршрутизации (Generic Routing Encapsulation или GRE) [RFC1701] [RFC1702] [RFC7676];
  • MPLS по протоколу UDP [RFC7510];
  • инкапсуляция базовой виртуализации сети (Generic Network Virtualization Encapsulation или Geneve) [RFC8926];
  • маршрутизация по сегментам (Segment Routing или SR) [RFC8660] [RFC8663] [RFC8754];
  • протокол резервирования ресурсов (Resource ReSerVation Protocol или RSVP) с расширениями организации трафика [RFC3209];
  • BGP с помеченными префиксами [RFC8277].

vpn-route-targets

Группировка YANG, определяющая правила импорта-экспорта цели маршрута (Route Target или RT), используемые VPN с включённым BGP. Группировка может применяться в L3VPN [RFC4364] и L2VPN [RFC4664]. Отметим, что группировка моделируется списком для упрощения её применения в модулях, где требуется идентификатор RT (например, связывание оператора с RT).

route-distinguisher

Группировка YANG, определяющая различители маршрутов (Route Distinguisher или RD).
Как показано на рисунке 2, модуль поддерживает режимы назначения RD — прямое и полностью автоматическое назначение, автоматическое назначение из заданного пула и отсутствие назначения.
Модуль также поддерживает развёртывание, где назначается лишь субполе Assigned Number в RD (параграф 4.2 в [RFC4364]) из пула, где указано субполе Administrator, например, Router ID для узла VPN. Модуль поддерживает три режима управления субполем Assigned Number: явное назначение, автоматическое назначение из данного пула, полностью автоматическое назначение.
        grouping route-distinguisher:
          +-- (rd-choice)?
             +--:(directly-assigned)
             |  +-- rd?               rt-types:route-distinguisher
             +--:(directly-assigned-suffix)
             |  +-- rd-suffix?        uint16
             +--:(auto-assigned)
             |  +-- rd-auto
             |     +-- (auto-mode)?
             |     |  +--:(from-pool)
             |     |  |  +-- rd-pool-name?   string
             |     |  +--:(full-auto)
             |     |     +-- auto?           empty
             |     +--ro auto-assigned-rd?
             |     |       rt-types:route-distinguisher
             +--:(auto-assigned-suffix)
             |  +-- rd-auto-suffix
             |     +-- (auto-mode)?
             |     |  +--:(from-pool)
             |     |  |  +-- rd-pool-name?        string
             |     |  +--:(full-auto)
             |     |     +-- auto?                empty
             |     +--ro auto-assigned-rd-suffix?   uint16
             +--:(no-rd)
                +-- no-rd?            empty

Рисунок 2. Субдерево группировки отличителя маршрута.

vpn-components-group

Группа YANG, служащая для группировки узлов VPN, доступа в сеть VPN, сайтов. Например, ограничения разнообразия или избыточности могут применяться на уровне группы.

placement-constraints

Группа YANG, служащая для для задания ограничений по размещению узлов VPN, доступа в сеть VPN, сайтов.

ports

Группировка YANG, определяющая диапазоны портов отправителя и получателя, а также операторы. Субдерево группы приведено на рисунке 3.
        grouping ports:
          +-- (source-port)?
          |  +--:(source-port-range-or-operator)
          |     +-- source-port-range-or-operator
          |        +-- (port-range-or-operator)?
          |           +--:(range)
          |           |  +-- lower-port    inet:port-number
          |           |  +-- upper-port    inet:port-number
          |           +--:(operator)
          |              +-- operator?     operator
          |              +-- port          inet:port-number
          +-- (destination-port)?
             +--:(destination-port-range-or-operator)
                +-- destination-port-range-or-operator
                   +-- (port-range-or-operator)?
                      +--:(range)
                      |  +-- lower-port    inet:port-number
                      |  +-- upper-port    inet:port-number
                      +--:(operator)
                         +-- operator?     operator
                         +-- port          inet:port-number

Рисунок 3. Субдерево группировки номеров портов.

qos-classification-policy

Группировка YANG, определяющая набор правил классификации QoS по различным критериям сопоставления L3/4 и приложений. Дерево группы показано на рисунке 4.
Критерии сопоставления QoS используют группировки, которые определены в модулей полей пакета ietf-packet-fields (параграф 4.2 в [RFC8519]).
Любой протокол L4 может быть указан в узле данных protocol под l3, но в этой версии рассматриваются лишь критерии сопоставления, связанные с TCP и UDP, поскольку эти протоколы широко применяются в контексте услуг VPN. В будущих версиях могут добавиться параметры L4 (например, Stream Control Transmission Protocol [RFC4960]), если это потребуется.
Некоторые транспортные протоколы используют имеющиеся протоколы (например, TCP или UDP) в качестве основы. Критерии сопоставления для таких протоколов могут основываться на узле protocol под l3 критерия сопоставления TCP/UDP, как показано на рисунке 4, части данных TCP/UDP или их комбинации. Эта версия модуля не поддерживает такие расширенные критерии. В будущих версиях модуля могут быть добавлены критерии сопоставления на основе полей данных транспортного протокола (например, по битовой маске).
        grouping qos-classification-policy:
          +-- rule* [id]
             +-- id                         string
             +-- (match-type)?
             |  +--:(match-flow)
             |  |  +-- (l3)?
             |  |  |  +--:(ipv4)
             |  |  |  |  +-- ipv4
             |  |  |  |     +-- dscp?                          inet:dscp
             |  |  |  |     +-- ecn?                           uint8
             |  |  |  |     +-- length?                        uint16
             |  |  |  |     +-- ttl?                           uint8
             |  |  |  |     +-- protocol?                      uint8
             |  |  |  |     +-- ihl?                           uint8
             |  |  |  |     +-- flags?                         bits
             |  |  |  |     +-- offset?                        uint16
             |  |  |  |     +-- identification?                uint16
             |  |  |  |     +-- (destination-network)?
             |  |  |  |     |  +--:(destination-ipv4-network)
             |  |  |  |     |     +-- destination-ipv4-network?
             |  |  |  |     |             inet:ipv4-prefix
             |  |  |  |     +-- (source-network)?
             |  |  |  |        +--:(source-ipv4-network)
             |  |  |  |           +-- source-ipv4-network?
             |  |  |  |                   inet:ipv4-prefix
             |  |  |  +--:(ipv6)
             |  |  |     +-- ipv6
             |  |  |        +-- dscp?                          inet:dscp
             |  |  |        +-- ecn?                           uint8
             |  |  |        +-- length?                        uint16
             |  |  |        +-- ttl?                           uint8
             |  |  |        +-- protocol?                      uint8
             |  |  |        +-- (destination-network)?
             |  |  |        |  +--:(destination-ipv6-network)
             |  |  |        |     +-- destination-ipv6-network?
             |  |  |        |             inet:ipv6-prefix
             |  |  |        +-- (source-network)?
             |  |  |        |  +--:(source-ipv6-network)
             |  |  |        |     +-- source-ipv6-network?
             |  |  |        |             inet:ipv6-prefix
             |  |  |        +-- flow-label?
             |  |  |                inet:ipv6-flow-label
             |  |  +-- (l4)?
             |  |     +--:(tcp)
             |  |     |  +-- tcp
             |  |     |     +-- sequence-number?               uint32
             |  |     |     +-- acknowledgement-number?        uint32
             |  |     |     +-- data-offset?                   uint8
             |  |     |     +-- reserved?                      uint8
             |  |     |     +-- flags?                         bits
             |  |     |     +-- window-size?                   uint16
             |  |     |     +-- urgent-pointer?                uint16
             |  |     |     +-- options?                       binary
             |  |     |     +-- (source-port)?
             |  |     |     |  +--:(source-port-range-or-operator)
             |  |     |     |     +-- source-port-range-or-operator
             |  |     |     |        +-- (port-range-or-operator)?
             |  |     |     |           +--:(range)
             |  |     |     |           |  +-- lower-port
             |  |     |     |           |  |       inet:port-number
             |  |     |     |           |  +-- upper-port
             |  |     |     |           |          inet:port-number
             |  |     |     |           +--:(operator)
             |  |     |     |              +-- operator?     operator
             |  |     |     |              +-- port
             |  |     |     |                      inet:port-number
             |  |     |     +-- (destination-port)?
             |  |     |        +--:(destination-port-range-or-operator)
             |  |     |           +-- destination-port-range-or-operator
             |  |     |              +-- (port-range-or-operator)?
             |  |     |                 +--:(range)
             |  |     |                 |  +-- lower-port
             |  |     |                 |  |       inet:port-number
             |  |     |                 |  +-- upper-port
             |  |     |                 |          inet:port-number
             |  |     |                 +--:(operator)
             |  |     |                    +-- operator?     operator
             |  |     |                    +-- port
             |  |     |                            inet:port-number
             |  |     +--:(udp)
             |  |        +-- udp
             |  |           +-- length?                        uint16
             |  |           +-- (source-port)?
             |  |           |  +--:(source-port-range-or-operator)
             |  |           |     +-- source-port-range-or-operator
             |  |           |        +-- (port-range-or-operator)?
             |  |           |           +--:(range)
             |  |           |           |  +-- lower-port
             |  |           |           |  |       inet:port-number
             |  |           |           |  +-- upper-port
             |  |           |           |          inet:port-number
             |  |           |           +--:(operator)
             |  |           |              +-- operator?     operator
             |  |           |              +-- port
             |  |           |                      inet:port-number
             |  |           +-- (destination-port)?
             |  |              +--:(destination-port-range-or-operator)
             |  |                 +-- destination-port-range-or-operator
             |  |                    +-- (port-range-or-operator)?
             |  |                       +--:(range)
             |  |                       |  +-- lower-port
             |  |                       |  |       inet:port-number
             |  |                       |  +-- upper-port
             |  |                       |          inet:port-number
             |  |                       +--:(operator)
             |  |                          +-- operator?     operator
             |  |                          +-- port
             |  |                                  inet:port-number
             |  +--:(match-application)
             |     +-- match-application?   identityref
             +-- target-class-id?           string

Рисунок 4. Субдерево классификации QoS.

4. Модуль общего назначения VPN L2/3

Этот модуль использует типы, определённые в [RFC6991], [RFC8294], [RFC8519] и расширения из [RFC8341].

   <CODE BEGINS> file "ietf-vpn-common@2022-02-11.yang"
   module ietf-vpn-common {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-vpn-common";
     prefix vpn-common;

     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }
     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }
     import ietf-packet-fields {
       prefix packet-fields;
       reference
         "RFC 8519: YANG Data Model for Network Access
                    Control Lists (ACLs)";
     }

     organization
       "IETF OPSAWG (Operations and Management Area Working Group)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/opsawg/> 
        WG List:  <mailto:opsawg@ietf.org> 

        Editor:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 
        Author:   Samier Barguil
                  <mailto:samier.barguilgiraldo.ext@telefonica.com> 
        Editor:   Oscar Gonzalez de Dios
                  <mailto:oscar.gonzalezdedios@telefonica.com> 
        Author:   Qin Wu
                  <mailto:bill.wu@huawei.com>"; 
     description
       "Этот модуль YANG определяет базу, предназначенную для применения
        в различных модулях VPN (например, Layer 3 VPN Service Model 
        (L3SM), Layer 2 VPN Service Model (L2SM), Layer 3 VPN Network 
        Model (L3NM), Layer 2 VPN Network Model (L2NM)).

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

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

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

     revision 2022-02-11 {
       description
         "Исходная версия.";
       reference
         "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
                    VPNs";
     }

     /******** Набор связанных с VPN свойств ********/
     /*
      * Свойства, относящиеся к схемам инкапсуляции
      */

     feature dot1q {
       description
         "Указывает поддержку инкапсуляции dot1Q.";
       reference
         "IEEE Std 802.1Q: IEEE Standard for Local and Metropolitan
                           Area Networks--Bridges and Bridged
                           Networks";
     }

     feature qinq {
       description
         "Указывает поддержку инкапсуляции QinQ.";
       reference
         "IEEE Std 802.1ad: IEEE Standard for Local and Metropolitan
                            Area Networks---Virtual Bridged Local
                            Area Networks---Amendment 4: Provider
                            Bridges";
     }

     feature vxlan {
       description
         "Указывает поддержку инкапсуляции VXLAN.";
       reference
         "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
                    A Framework for Overlaying Virtualized Layer 2
                    Networks over Layer 3 Networks";
     }

     feature qinany {
       description
         "Указывает поддержку инкапсуляции QinAny.
          Во внешнем теге VLAN указывается конкретное значение, а
          внутренний тег VLAN может быть любым.";
     }

     feature lag-interface {
       description
         "Указывает поддержку групп агрегирования каналов (LAG)
          между системами доступа VPN.";
       reference
         "IEEE Std 802.1AX: IEEE Standard for Local and Metropolitan
                            Area Networks--Link Aggregation";
     }

     /*
      * Свойства, относящиеся к групповой передаче
      */

     feature multicast {
       description
         "Указывает поддержку групповой передачи в VPN.";
       reference
         "RFC 6513: Multicast in MPLS/BGP IP VPNs";
     }

     feature igmp {
       description
         "Указывает поддержку протокола управления группами IGMP.";
       reference
         "RFC 1112: Host Extensions for IP Multicasting
          RFC 2236: Internet Group Management Protocol, Version 2
          RFC 3376: Internet Group Management Protocol, Version 3";
     }

     feature mld {
       description
         "Указывает поддержку обнаружения групповых получателей MLD).";
       reference
         "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
          RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
                    for IPv6";
     }

     feature pim {
       description
         "Указывает поддержку независимой от протокола групповой передачи
          (PIM).";
       reference
         "RFC 7761: Protocol Independent Multicast - Sparse Mode
                    (PIM-SM): Protocol Specification (Revised)";
     }

     /*
      * Свойства, относящиеся к семействам адресов
      */

     feature ipv4 {
       description
         "Указывает поддержку IPv4 для VPN. Трафик IPv4 может передаваться
          в VPN, адреса/префиксы IPv4 могут назначаться для доступа в сеть
          VPN, маршруты IPv4 могут устанавливаться на каналах между 
          клиентом и провайдером (CE-PE) и т. п.";
       reference
         "RFC 791: Internet Protocol";
     }

     feature ipv6 {
       description
         "Указывает поддержку IPv6 для VPN. Трафик IPv6 может передаваться
          в VPN, адреса/префиксы IPv6 могут назначаться для доступа в сеть
          VPN, маршруты IPv6 могут устанавливаться на каналах между 
          клиентом и провайдером (CE-PE) и т. п.";
       reference
         "RFC 8200: Internet Protocol, Version 6 (IPv6)
                    Specification";
     }

     /*
      * Свойства, относящиеся к протоколам маршрутизации
      */
     feature rtg-ospf {
       description
         "Указывает поддержку OSPF как протокола маршрутизации PE-CE.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
                    for BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
                    (PE-CE) Routing Protocol";
     }

     feature rtg-ospf-sham-link {
       description
         "Указывает поддержку фиктивных каналов OSPF.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
                    for BGP/MPLS IP Virtual Private Networks (VPNs),
                    Section 4.2.7
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
                    (PE-CE) Routing Protocol, Section 5";
     }

     feature rtg-bgp {
       description
         "Указывает поддержку BGP как протокола маршрутизации PE-CE.";
       reference
         "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
     }
     feature rtg-rip {
       description
         "Указывает поддержку RIP как протокола маршрутизации PE-CE.";
       reference
         "RFC 2453: RIP Version 2
          RFC 2080: RIPng for IPv6";
     }

     feature rtg-isis {
       description
         "Указывает поддержку IS-IS как протокола маршрутизации PE-CE.";
       reference
         "ISO10589: Information technology - Telecommunications and
                    information exchange between systems -
                    Intermediate System to Intermediate System
                    intra-domain routeing information exchange
                    protocol for use in conjunction with the protocol
                    for providing the connectionless-mode network
                    service (ISO 8473)";
     }

     feature rtg-vrrp {
       description
         "Указывает поддержку VRRP как протокола маршрутизации PE-CE.";
       reference
         "RFC 5798: Virtual Router Redundancy Protocol (VRRP)
                    Version 3 for IPv4 and IPv6";
     }

     feature bfd {
       description
         "Указывает поддержку BFD между PE и CE.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     /*
      * Свойства, связанные с ограничениями сервиса VPN
      */

     feature bearer-reference {
       description
         "Указывает свойства присоединения CE-PE ниже уровня L3.
          Это свойство указывает поддержку задания ограничений доступа,
          т. е. повторное использование сетевого соединения, которое уже
          заказано у сервис-провайдера помимо сайта IP VPN.";
     }

     feature placement-diversity {
       description
         "Указывает поддержку ограничения разнообразия размещения на 
          площадках клиента. Примером таких ограничений служит 
          предотвращение подключения сайта к тому же элементу PE, что
          и целевой доступ к сайту.";
     }

     /*
      * Свойства, относящиеся к пропускной способности и QoS
      */

     feature qos {
       description
         "Указывает поддержку CoS в VPN.";
     }

     feature inbound-bw {
       description
         "Указывает поддержку пропускной способности на входе в VPN,
          т. е. поддержку полосы загрузки из сети сервис-провайдера
          на сайт VPN. Отметим, что L3SM использует input для указания
          того же свойства. От этой терминологии следует отказаться в
          пользу определённых здесь терминов.";
     }

     feature outbound-bw {
       description
         "Указывает поддержку пропускной способности на выходе из VPN,
          т. е. поддержку полосы выгрузки в сеть сервис-провайдера с
          сайта VPN. Отметим, что L3SM использует output для указания
          того же свойства. От этой терминологии следует отказаться в
          пользу определённых здесь терминов.";
  }

     /*
      * Свойства, связанные с безопасностью и отказоустойчивостью
      */
     feature encryption {
       description
         "Указывает поддержку шифрования в VPN.";
     }

     feature fast-reroute {
       description
         "Указывает поддержку FRR для сайта VPN.";
     }

     /*
      * Свойства, связанные с расширенными опциями VPN
      */
     feature external-connectivity {
       description
         "Указывает поддержку внешних соединений для VPN (например,
          Internet, частное или общественное облако).";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks
                    (VPNs), Section 11";
     }

     feature extranet-vpn {
       description
         "Указывает поддержку extranet VPN, т. е. возможность VPN иметь 
          доступ к списку других VPN.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks
                    (VPNs), Section 1.1";
     }

     feature carriers-carrier {
       description
         "Указывает поддержку операторов в VPN.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks
                    (VPNs), Section 9";
     }

     /*
      * Отождествления, связанные с семействами адресов
      */
     identity address-family {
       description
         "Указывает семейство адресов.";
     }

     identity ipv4 {
       base address-family;
       description
         "Указывает семейство адресов IPv4.";
     }

     identity ipv6 {
       base address-family;
       description
         "Указывает семейство адресов IPv6.";
     }

     identity dual-stack {
       base address-family;
       description
         "Указывает семейства адресов IPv4 и IPv6.";
     }

     /*
      * Отождествления, связанные с топологией VPN
      */
     identity vpn-topology {
       description
         "Базовое отождествление топологии VPN.";
     }

     identity any-to-any {
       base vpn-topology;
       description
         "Указывает топологию VPN «каждый с каждым». Каждый сайт VPN может
          взаимодействовать с каждым другим сайтом без ограничений.";
     }

     identity hub-spoke {
       base vpn-topology;
       description
         "Топология «звезда» (Hub-and-Spoke). Лучи могут взаимодействовать
          лишь с хабами, которые могут взаимодействовать между собой.";
     }
     identity hub-spoke-disjoint {
       base vpn-topology;
       description
         "Топология Hub-and-Spoke, где хабы не могут взаимодействовать.";
     }

     identity custom {
       base vpn-topology;
       description
         "Клиентская топология VPN где роли узлов отличаются от «чистых»
          Hub и Spoke. Топология управляется правилами импорта-экспорта.
          Клиентская топология отражает более сложные узлы VPN, которые 
          играть роль Hub узлов и Spoke - для других.";
     }

     /*
      * Отождествления, связанные с типами доступа
      */

     identity site-network-access-type {
       description
         "Базовое отождествление типа доступа в сеть сайта.";
     }

     identity point-to-point {
       base site-network-access-type;
       description
         "Доступ «точка-точка».";
     }

     identity multipoint {
       base site-network-access-type;
       description
         "Многоточечный доступ.";
     }

     identity irb {
       base site-network-access-type;
       description
         "Отождествление IRB для псевдопроводов.";
     }

     identity loopback {
       base site-network-access-type;
       description
         "Loopback-доступ.";
     }

     /*
      * Отождествления, связанные с рабочим и административным статусом
      */

     identity operational-status {
       description
         "Базовое отождествление для рабочего состояния.";
     }

     identity op-up {
       base operational-status;
       description
         "Рабочее состояние Up/Enabled.";
     }

     identity op-down {
       base operational-status;
       description
         "Рабочее состояние Down/Disabled.";
     }

     identity op-unknown {
       base operational-status;
       description
         "Рабочее состояние неизвестно.";
     }

     identity administrative-status {
       description
         "Базовое отождествление для административного состояния.";
     }

     identity admin-up {
       base administrative-status;
       description
         "Административное состояние Up/Enabled.";
     }

     identity admin-down {
       base administrative-status;
       description
         "Административное состояние Down/Disabled.";
     }

     identity admin-testing {
       base administrative-status;
       description
         "Административное состояние Up для тестирования.";
     }

     identity admin-pre-deployment {
       base administrative-status;
       description
         "Административное состояние отражает фазу до фактического
          развёртывания сервиса.";
     }

     /*
      * Отождествления, связанные с ролями сайта и узлов
      */
     identity role {
       description
         "Базовое отождествление роли сайта или узла.";
     }

     identity any-to-any-role {
       base role;
       description
         "Каждый с каждым.";
     }

     identity spoke-role {
       base role;
       description
         "Узел или сайт в роли Spoke.";
     }

     identity hub-role {
       base role;
       description
         "Узел или сайт в роли Hub.";
     }

     identity custom-role {
       base role;
       description
         "Узел VPN с заказной или комплексной ролью в VPN. Для некоторых
          источников/получателей он может быть хабом, для других - лучом.";
     }

     /*
      * Отождествления, связанные с ограничениями службы VPN
      */
     identity placement-diversity {
       description
         "Базовое отождествление ограничений размещения доступа.";
     }

     identity bearer-diverse {
       base placement-diversity;
       description
         "Разнообразие носителей. Носителям не следует применять 
          базовые элементы.";
     }

     identity pe-diverse {
       base placement-diversity;
       description
         "Разнообразие PE.";
     }

     identity pop-diverse {
       base placement-diversity;
       description
         "Разнообразие точек присутствия (Point of Presence или POP).";
     }

     identity linecard-diverse {
       base placement-diversity;
       description
         "Разнообразие линейных плат.";
     }


     identity same-pe {
       base placement-diversity;
       description
         "Наличие сайтов, подключённых к тому же PE.";
     }

     identity same-bearer {
       base placement-diversity;
       description
         "Наличие сайтов, подключённых к тому же носителю.";
     }

     /*
      * Отождествления, связанные с типами сервиса
      */
     identity service-type {
       description
         "Базовое отождествление типа сервиса.";
     }

     identity l3vpn {
       base service-type;
       description
         "Служба L3VPN.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)";
     }

     identity vpls {
       base service-type;
       description
         "Услуга виртуальной частной ЛВС (VPLS).";
       reference
         "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for
                    Auto-Discovery and Signaling
          RFC 4762: Virtual Private LAN Service (VPLS) Using Label
                    Distribution Protocol (LDP) Signaling";
     }

     identity vpws {
       base service-type;
       description
         "Услуга виртуального частного провода (VPWS).";
       reference
         "RFC 4664: Framework for Layer 2 Virtual Private Networks
                    (L2VPNs), Section 3.1.1";
     }

     identity vpws-evpn {
       base service-type;
       description
         "Ethernet VPN (EVPN) для поддержки VPWS.";
       reference
         "RFC 8214: Virtual Private Wire Service Support in
                    Ethernet VPN";
     }

     identity pbb-evpn {
       base service-type;
       description
         "Служба PBB EVPN.";
       reference
         "RFC 7623: Provider Backbone Bridging Combined with
                    Ethernet VPN (PBB-EVPN)";
     }

     identity mpls-evpn {
       base service-type;
       description
         "Служба EVPN на основе MPLS.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN";
     }

     identity vxlan-evpn {
       base service-type;
       description
         "Служба EVPN на основе VXLAN.";
       reference
         "RFC 8365: A Network Virtualization Overlay Solution Using
                    Ethernet VPN (EVPN)";
     }

     /*
      * Отождествления для типов сигнализации VPN
      */
     identity vpn-signaling-type {
       description
         "Базовое отождествление для типов сигнализации VPN.";
     }

     identity bgp-signaling {
       base vpn-signaling-type;
       description
         "L2 VPN с сигнализацией BGP.";
       reference
         "RFC 6624: Layer 2 Virtual Private Networks Using BGP for
                    Auto-Discovery and Signaling
          RFC 7432: BGP MPLS-Based Ethernet VPN";
     }

     identity ldp-signaling {
       base vpn-signaling-type;
       description
         "Целевая сигнализация LDP.";
       reference
         "RFC 5036: LDP Specification";
     }

     identity l2tp-signaling {
       base vpn-signaling-type;
       description
         "Сигнализация L2TP.";
       reference
         "RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)";
     }

     /*
      * Отождествления, связанные с протоколами маршрутизации
      */

     identity routing-protocol-type {
       description
         "Базовое отождествление для типа протокола маршрутизации.";
     }

     identity static-routing {
       base routing-protocol-type;
       description
         "Статическая маршрутизация.";
     }

     identity bgp-routing {
       if-feature "rtg-bgp";
       base routing-protocol-type;
       description
         "Протокол BGP.";
       reference
         "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
     }

     identity ospf-routing {
       if-feature "rtg-ospf";
       base routing-protocol-type;
       description
         "Протокол OSPF.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
                    for BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
                    (PE-CE) Routing Protocol";
     }

     identity rip-routing {
       if-feature "rtg-rip";
       base routing-protocol-type;
       description
         "Протокол RIP.";
       reference
         "RFC 2453: RIP Version 2
          RFC 2080: RIPng for IPv6";
     }

     identity isis-routing {
       if-feature "rtg-isis";
       base routing-protocol-type;
       description
         "Протокол IS-IS.";
       reference
         "ISO10589: Information technology - Telecommunications and
                    information exchange between systems - Intermediate
                    System to Intermediate System intra-domain routeing
                    information exchange protocol for use in conjunction
                    with the protocol for providing the connectionless-mode
                    network service (ISO 8473)";
     }

     identity vrrp-routing {
       if-feature "rtg-vrrp";
       base routing-protocol-type;
       description
         "Протокол VRRP. Применяется при прямом соединении ЛВС с PEs";
       reference
         "RFC 5798: Virtual Router Redundancy Protocol (VRRP)
                    Version 3 for IPv4 and IPv6";
     }

     identity direct-routing {
       base routing-protocol-type;
       description
         "Непосредственная маршрутизация. Применяется при прямом
          соедиении ЛВС с PE и необходимости анонсирования в VPN.";
     }

     identity any-routing {
       base routing-protocol-type;
       description
         "Любой протокол маршрутизации. Может служить, например,
          для установки правил, применимых к любому протоколу.";
     }

     identity isis-level {
       if-feature "rtg-isis";
       description
         "Базовое отождествление для уровня IS-IS.";
       reference
         "ISO10589: Information technology - Telecommunications and
                    information exchange between systems - Intermediate
                    System to Intermediate System intra-domain routeing
                    information exchange protocol for use in conjunction
                    with the protocol for providing the connectionless-mode
                    network service (ISO 8473)";
     }

     identity level-1 {
       base isis-level;
       description
         "IS-IS Level 1.";
     }

     identity level-2 {
       base isis-level;
       description
         "IS-IS Level 2.";
     }

     identity level-1-2 {
       base isis-level;
       description
         "IS-IS Levels 1 and 2.";
     }

     identity bfd-session-type {
       if-feature "bfd";
       description
         "Базовое отождествление типа сессии BFD.";
     }

     identity classic-bfd {
       base bfd-session-type;
       description
         "Classic BFD.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     identity s-bfd {
       base bfd-session-type;
       description
         "Seamless BFD.";
       reference
         "RFC 7880: Seamless Bidirectional Forwarding Detection
                    (S-BFD)";
     }

     /*
      * Отождествления для правил импорта и экспорта маршрутов
      */
     identity ie-type {
       description
         "базовое отождествление профилей импорта-экспорта.
          Профиль может применять несколько узлов VPN.";
     }

     identity import {
       base ie-type;
       description
         "Профиль импорта маршрутизации.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks
                    (VPNs), Section 4.3.1";
     }

     identity export {
       base ie-type;
       description
         "Профиль экспорта маршрутизации.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks
                    (VPNs), Section 4.3.1";
     }

     identity import-export {
       base ie-type;
       description
         "Профиль импорта-экспорта маршрутизации.";
     }

     /*
      * Отождествления для пропускной способности и QoS
      */

     identity bw-direction {
       description
         "Базовое отождествление для полосы в одном направлении.";
     }

     identity inbound-bw {
       if-feature "inbound-bw";
       base bw-direction;
       description
         "Пропускная способность на входе.";
     }

     identity outbound-bw {
       if-feature "outbound-bw";
       base bw-direction;
       description
         "Пропускная способность на выходе.";
     }

     identity bw-type {
       description
         "Базовое отождествление для типа пропускной способности.";
     }

     identity bw-per-cos {
       if-feature "qos";
       base bw-type;
       description
         "Пропускная способность по CoS.";
     }

     identity bw-per-port {
       base bw-type;
       description
         "Пропускная способность по доступу в сеть для сайта.";
     }

     identity bw-per-site {
       base bw-type;
       description
         "Пропускная способность по сайтам. Применима ко всему доступу
          в рамках сайта.";
     }

     identity bw-per-service {
       base bw-type;
       description
         "Пропускная способность на услугу VPN.";
     }

     identity qos-profile-direction {
       if-feature "qos";
       description
         "Базовое отождествление профиля QoS в одном направлении.";
     }

     identity site-to-wan {
       base qos-profile-direction;
       description
         "От сайта клиента в сеть провайдера, обычно это от CE к PE.";
     }

     identity wan-to-site {
       base qos-profile-direction;
       description
         "Из сети провайдера к сайту клиента, обычно это от PE к CE.";
     }

     identity both {
       base qos-profile-direction;
       description
         "Оба направления между сайтом и WAN.";
     }

     /*
      * Отождествления, связанные с экземпляром базового транспорта
      */

     identity transport-instance-type {
       description
         "Базовое отождествление типа экземпляра базового транспорта.";
     }

     identity virtual-network {
       base transport-instance-type;
       description
         "Виртуальная сеть.";
       reference
         "RFC 8453: Framework for Abstraction and Control of TE
                    Networks (ACTN)";
     }

     identity enhanced-vpn {
       base transport-instance-type;
       description
         "Расширенная VPN (VPN+) - подход, основанный на имеющихся
          технологиях VPN и организации трафика (TE) с добавлением
          характеристик, нужных услугам на базе классических VPN.";
       reference
         "draft-ietf-teas-enhanced-vpn-09:
            A Framework for Enhanced Virtual Private Network
            (VPN+) Services";
     }

     identity ietf-network-slice {
       base transport-instance-type;
       description
         "Сетевой срез (slice) IETF - логическая топология сети,
          соединяющей множество конечных точек с применением набора
          общих или выделенных сетевых ресурсов для организации
          конкретных услуг.";
       reference
         "draft-ietf-teas-ietf-network-slices-05:
            Framework for IETF Network Slices";
     }

     /*
      * Отождествления для типа протоколов (обычно базового транспорта).
      */

     identity protocol-type {
       description
         "Базовое отождествление типов протоколов.";
     }

     identity ip-in-ip {
       base protocol-type;
       description
         "Транспорт на основе IP-in-IP.";
       reference
         "RFC 2003: IP Encapsulation within IP
          RFC 2473: Generic Packet Tunneling in IPv6 Specification";
     }

     identity ip-in-ipv4 {
       base ip-in-ip;
       description
         "Транспорт на основе IP по протоколу IPv4.";
       reference
         "RFC 2003: IP Encapsulation within IP";
     }

     identity ip-in-ipv6 {
       base ip-in-ip;
       description
         "Транспорт на основе IP по протоколу IPv6.";
       reference
         "RFC 2473: Generic Packet Tunneling in IPv6 Specification";
     }

     identity gre {
       base protocol-type;
       description
         "Транспорт на основе инкапсуляции (GRE).";
       reference
         "RFC 1701: Generic Routing Encapsulation (GRE)
          RFC 1702: Generic Routing Encapsulation over IPv4 networks
          RFC 7676: IPv6 Support for Generic Routing Encapsulation
                    (GRE)";
     }

     identity gre-v4 {
       base gre;
       description
         "Транспорт на основе GRE по протоколу IPv4.";
       reference
         "RFC 1702: Generic Routing Encapsulation over IPv4
                    networks";
     }

     identity gre-v6 {
       base gre;
       description
         "Транспорт на основе GRE по протоколу IPv6.";
       reference
         "RFC 7676: IPv6 Support for Generic Routing Encapsulation
                    (GRE)";
     }

     identity vxlan-trans {
       base protocol-type;
       description
         "Транспорт на основе VXLAN.";
       reference
         "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
                    A Framework for Overlaying Virtualized Layer 2
                    Networks over Layer 3 Networks";
     }

     identity geneve {
       base protocol-type;
       description
         "Транспорт на основе инкапсуляции Geneve.";
       reference
         "RFC 8926: Geneve: Generic Network Virtualization
                    Encapsulation";
     }

     identity ldp {
       base protocol-type;
       description
         "Транспорт на основе LDP.";
       reference
         "RFC 5036: LDP Specification";
     }

     identity mpls-in-udp {
       base protocol-type;
       description
         "Транспорт на основе MPLS по протоколу UDP.";
       reference
         "RFC 7510: Encapsulating MPLS in UDP";
     }

     identity sr {
       base protocol-type;
       description
         "Транспорт на основе маршрутизации по сегментам (SR).";
       reference
         "RFC 8660: Segment Routing with the MPLS Data Plane
          RFC 8663: MPLS Segment Routing over IP
          RFC 8754: IPv6 Segment Routing Header (SRH)";
     }

     identity sr-mpls {
       base sr;
       description
         "Транспорт на основе SR с плоскостью данных MPLS.";
       reference
         "RFC 8660: Segment Routing with the MPLS Data Plane";
     }

     identity srv6 {
       base sr;
       description
         "Транспорт на основе SR по протоколу IPv6.";
       reference
         "RFC 8754: IPv6 Segment Routing Header (SRH)";
     }

     identity sr-mpls-over-ip {
       base sr;
       description
         "Транспорт на основе SR через MPLS по протоколу IP.";
       reference
         "RFC 8663: MPLS Segment Routing over IP";
     }

     identity rsvp-te {
       base protocol-type;
       description
         "Транспорт на основе RSVP-TE.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity bgp-lu {
       base protocol-type;
       description
         "Транспорт на основе префиксов с метками BGP.";
       reference
         "RFC 8277: Using BGP to Bind MPLS Labels to Address Prefixes";
     }

     identity unknown {
       base protocol-type;
       description
         "Неизвестный тип протокола.";
     }

     /*
      * Отождествления для типов инкапсуляции
      */

     identity encapsulation-type {
       description
         "Базовое отождествление типов инкапсуляции.";
     }

     identity priority-tagged {
       base encapsulation-type;
       description
         "Интерфейс с тегами приоритета.";
     }

     identity dot1q {
       if-feature "dot1q";
       base encapsulation-type;
       description
         "Инкапсуляция dot1Q.";
     }

     identity qinq {
       if-feature "qinq";
       base encapsulation-type;
       description
         "Инкапсуляция QinQ.";
     }

     identity qinany {
       if-feature "qinany";
       base encapsulation-type;
       description
         "Инкапсуляция QinAny.";
     }

     identity vxlan {
       if-feature "vxlan";
       base encapsulation-type;
       description
         "Инкапсуляция VXLAN.";
     }

     identity ethernet-type {
       base encapsulation-type;
       description
         "Инкапсуляция Ethernet.";
     }

     identity vlan-type {
       base encapsulation-type;
       description
         "Инкапсуляция VLAN.";
     }

     identity untagged-int {
       base encapsulation-type;
       description
         "Инкапсуляция без тегов.";
     }

     identity tagged-int {
       base encapsulation-type;
       description
         "Инкапсуляция с тегами.";
     }

     identity lag-int {
       if-feature "lag-interface";
       base encapsulation-type;
       description
         "Интерфейс LAG.";
     }

     /*
      * Отождествления, связанные с тегами VLAN
      */

     identity tag-type {
       description
         "Базовое отождествление для типов тегов VLAN.";
     }

     identity c-vlan {
       base tag-type;
       description
         "Клиентская VLAN (C-VLAN), обычно с Ethertype 0x8100.";
     }

     identity s-vlan {
       base tag-type;
       description
         "Тег Service VLAN (S-VLAN).";
     }

     identity s-c-vlan {
       base tag-type;
       description
         "Применяется для тегов S-VLAN и C-VLAN.";
     }

     /*
      * Отождествления, связанные с VXLAN
      */

     identity vxlan-peer-mode {
       if-feature "vxlan";
       description
         "базовое отождествление для режимов партнёра VXLAN.";
     }

     identity static-mode {
       base vxlan-peer-mode;
       description
         "Доступ VXLAN в статическом режиме.";
     }

     identity bgp-mode {
       base vxlan-peer-mode;
       description
         "Доступ VXLAN с обучением BGP EVPN.";
     }

     /*
      * Отождествления для групповой передачи
      */
     identity multicast-gp-address-mapping {
       if-feature "multicast";
       description
         "Базовое отождествление типов сопоставления multicast-групп.";
     }

     identity static-mapping {
       base multicast-gp-address-mapping;
       description
         "Статическое сопоставление - интерфейс, подключенный к группе
          как ститический член.";
     }

     identity dynamic-mapping {
       base multicast-gp-address-mapping;
       description
         "Динамическое сопоставление - интерфейс, добавленный в 
          результате отслеживания.";
     }

     identity multicast-tree-type {
       if-feature "multicast";
       description
         "Базовое отождествление типов дерева группы.";
     }

     identity ssm-tree-type {
       base multicast-tree-type;
       description
         "Дерево с групповой передачей из заданного источника (SSM).";
     }

     identity asm-tree-type {
       base multicast-tree-type;
       description
         "Дерево с групповой передачей из любого источника (ASM).";
     }

     identity bidir-tree-type {
       base multicast-tree-type;
       description
         "Двунаправленное дерево.";
     }

     identity multicast-rp-discovery-type {
       if-feature "multicast";
       description
         "Базовое отождествление для обнаружения точки встречи (RP).";
     }

     identity auto-rp {
       base multicast-rp-discovery-type;
       description
         "Тип обнаружения Auto-RP.";
     }

     identity static-rp {
       base multicast-rp-discovery-type;
       description
         "Статический тип.";
     }

     identity bsr-rp {
       base multicast-rp-discovery-type;
       description
         "Тип обнаружения Bootstrap Router (BSR).";
     }

     identity group-management-protocol {
       if-feature "multicast";
       description
         "Базовое отождествление для протоколов управления группами.";
     }

     identity igmp-proto {
       base group-management-protocol;
       description
         "IGMP.";
       reference
         "RFC 1112: Host Extensions for IP Multicasting
          RFC 2236: Internet Group Management Protocol, Version 2
          RFC 3376: Internet Group Management Protocol, Version 3";
     }

     identity mld-proto {
       base group-management-protocol;
       description
         "MLD.";
       reference
         "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
          RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
                    for IPv6";
     }

     identity pim-proto {
       if-feature "pim";
       base routing-protocol-type;
       description
         "PIM.";
       reference
         "RFC 7761: Protocol Independent Multicast - Sparse Mode
                    (PIM-SM): Protocol Specification (Revised)";
     }

     identity igmp-version {
       if-feature "igmp";
       description
         "Базовое отождествление для указания версии IGMP.";
     }

     identity igmpv1 {
       base igmp-version;
       description
         "IGMPv1.";
       reference
         "RFC 1112: Host Extensions for IP Multicasting";
     }

     identity igmpv2 {
       base igmp-version;
       description
         "IGMPv2.";
       reference
         "RFC 2236: Internet Group Management Protocol, Version 2";
     }

     identity igmpv3 {
       base igmp-version;
       description
         "IGMPv3.";
       reference
         "RFC 3376: Internet Group Management Protocol, Version 3";
     }

     identity mld-version {
       if-feature "mld";
       description
         "Базовое отождествление для указания версии MLD.";
     }

     identity mldv1 {
       base mld-version;
       description
         "MLDv1.";
       reference
         "RFC 2710: Multicast Listener Discovery (MLD) for IPv6";
     }

     identity mldv2 {
       base mld-version;
       description
         "MLDv2.";
       reference
         "RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
                    for IPv6";
     }

     /*
      * Отождествления для типов трафика
      */

     identity tf-type {
       description
         "Базовое отождествление для типов трафика.";
     }

     identity multicast-traffic {
       base tf-type;
       description
         "Групповой трафик.";
     }

     identity broadcast-traffic {
       base tf-type;
       description
         "Широковещательный трафик.";
     }

     identity unknown-unicast-traffic {
       base tf-type;
       description
         "Неизвестный индивидуальный трафик.";
     }

     /*
      * Отождествления для пользовательских приложений
      */

     identity customer-application {
       description
         "Базовое отождествление для пользовательских приложений.";
     }

     identity web {
       base customer-application;
       description
         "Web-приложения (например, HTTP, HTTPS).";
     }

     identity mail {
       base customer-application;
       description
         "Почтовое приложение.";
     }

     identity file-transfer {
       base customer-application;
       description
         "Приложение для передачи файлов (например, FTP, Secure FTP (SFTP)).";
     }

     identity database {
       base customer-application;
       description
         "Приложение баз данных.";
     }

     identity social {
       base customer-application;
       description
         "Приложение социальной сети.";
     }

     identity games {
       base customer-application;
       description
         "Игровое приложение.";
     }

     identity p2p {
       base customer-application;
       description
         "Одноранговое приложение.";
     }

     identity network-management {
       base customer-application;
       description
         "Управляющее приложение (например, Telnet, syslog, SNMP).";
     }

     identity voice {
       base customer-application;
       description
         "Голосовое приложение.";
     }

     identity video {
       base customer-application;
       description
         "Приложение видеоконференций.";
     }

     identity embb {
       base customer-application;
       description
         "Расширенное широкополосное мобильное приложение (eMBB).
          Таким приложениям могут требоваться очень разные параметры
          производительности сети, такие как скорость передачи данных,
          задержка, частота потерь, надёжность и многие другие.";
     }

     identity urllc {
       base customer-application;
       description
         "Приложение URLLC (сверхнадежные коммуникации с малой задержкой).
          Приложениям URLLC могут требоваться очень разные параметры,
          такие как задержка, надёжность и многие другие.";
     }

     identity mmtc {
       base customer-application;
       description
         "Приложение mMTC (коммуникации больших машин). Таким приложениям
          могут требоваться очень разные параметры производительности, 
          такие как скорость передачи данных, задержка, частота потерь,
          надёжность и многие другие.";
     }

     /*
      * Отождествления, связанные с группировкой услуг
      */

     identity bundling-type {
       description
         "Базовое отождествление типа группировки. Поддерживаются все или
          часть CE-VLAN ID, связанных с услугой L2VPN.";
     }

     identity multi-svc-bundling {
       base bundling-type;
       description
         "Мультисервисная грруппировка, т. е. возможность связать 
          множество CE-VLAN ID со службой L2VPN на сайте.";
     }

     identity one2one-bundling {
       base bundling-type;
       description
         "Группировка служб «один к одному», т. е. каждая сеть L2VPN 
          может быть связана лишь с одним CE-VLAN ID на сайте.";
     }

     identity all2one-bundling {
       base bundling-type;
       description
         "Группировка служб «все с одним», т. е. все CE-VLAN ID
          сопоставляются с одной службой L2VPN.";
     }


     /*
      * Отождествления для служб Ethernet
      */

     identity control-mode {
       description
         "Базовое отождествление режима управления для L2CP.";
     }

     identity peer {
       base control-mode;
       description
         "Режим peer, т. е. участие в протоколе в направлении CE.
          Партнерство применяется для протокола управления агрегированием
          LACP и локального интерфейса управления Ethernet (E-LMI), а
          иногда - для протокола обнаружения канального уровня (LLDP).
          Для VPLS и VPWS абоненты могут запрашивать у провайдера
          партнерского сервиса включения связующего дерева.";
     }

     identity tunnel {
       base control-mode;
       description
         "Режим tunnel, т. е. передача выходному или целевому сайту.
          Для частных линий Ethernet (EPL) предполагается туннелирование
          кадров L2CP.";
     }

     identity discard {
       base control-mode;
       description
         "Режим Discard, т. е. отбрасывание кадра.";
     }
     identity neg-mode {
       description
         "Базовое отождествление типа согласования.";
     }

     identity full-duplex {
       base neg-mode;
       description
         "Полнодуплексный режим согласования.";
     }

     identity auto-neg {
       base neg-mode;
       description
         "Режим автосогласования.";
     }

     /******** Связанный с VPN тип ********/

     typedef vpn-id {
       type string;
       description
         "Идентификатор, применяемый с модулем VPN, например,
          идентификатор службы, узла и т. п.";
     }

     /******* Связанные с VPN группировки *******/

     grouping vpn-description {
       description
         "Общие сведения о VPN.";
       leaf vpn-id {
         type vpn-common:vpn-id;
         description
           "Идентификатор, однозначно указывающий VPN. Имеет локальную
            значимость, например, в сети сервис-провайдера.";
       }
       leaf vpn-name {
         type string;
         description
           "Служит для связывания имени с сервисом, для упрощения
            идентификации сервиса.";
       }
       leaf vpn-description {
         type string;
         description
           "Текстовое описание VPN.";
       }
       leaf customer-name {
         type string;
         description
           "Имя клиента, фактически использующего VPN.";
       }
     }

     grouping vpn-profile-cfg {
       description
         "Группировка для конфигурации профиля VPN.";
       container valid-provider-identifiers {
         description
           "Контейнер идентификаторов действительного профиля провайдера.";
         list external-connectivity-identifier {
           if-feature "external-connectivity";
           key "id";
           description
             "Список идентификаторов, однозначно указывающих профили, 
              управляющие предоставлением внешней связности для VPN. 
              Профиль указывает тип внешней связности (Internet, облако 
              и т. п.), связанные сайты и узлы и т. п. Профиль может
              также указывать правила фильтрации и/или трансляции
              адресов. Такие функции могут включать PE, P, выделенные
              узлы в зависимости от развёртывания.";
           leaf id {
             type string;
             description
               "Идентификация профиля внешней связности. Профиль имеет
                значимость лишь в административном домене провайдера.";
           }
         }
         list encryption-profile-identifier {
           key "id";
           description
             "Список идентификаторов профилей шифрования.";
           leaf id {
             type string;
             description
               "Идентификация применяемого профиля шифрования. Профиль имеет
                значимость лишь в административном домене провайдера.";
           }
         }
         list qos-profile-identifier {
           key "id";
           description
             "Список идентификаторов профилей QoS.";
           leaf id {
             type string;
             description
               "Идентификация применяемого профиля QoS. Профиль имеет
                значимость лишь в административном домене провайдера.";
           }
         }
         list bfd-profile-identifier {
           key "id";
           description
             "List of BFD profile identifiers.";
           leaf id {
             type string;
             description
               "Идентификация применяемого профиля BFD. Профиль имеет
                значимость лишь в административном домене провайдера.";
           }
         }
         list forwarding-profile-identifier {
           key "id";
           description
             "Список идентификаторов профилей пересылки.";
           leaf id {
             type string;
             description
               "Идентификация применяемого профиля пересылки. Профиль имеет
                значимость лишь в административном домене провайдера.";
           }
         }
         list routing-profile-identifier {
           key "id";
           description
             " Список идентификаторов профилей маршрутизации.";
           leaf id {
             type string;
             description
               "Идентификация профиля, используемого протоколами
                маршрутизации на сайтах, при доступе в сеть VPN или
                узлах VPN для указания правили импорта-экспорта VRF.

                Профиль имеет значимость лишь в административном 
                домене провайдера.";
           }
         }
         nacm:default-deny-write;
       }
     }

     grouping oper-status-timestamp {
       description
         "Определяет некоторые рабочие параметры для службы.";
       leaf status {
         type identityref {
           base operational-status;
         }
         config false;
         description
           "Рабочее состояние.";
       }
       leaf last-change {
         type yang:date-and-time;
         config false;
         description
           "Фактическая дата и время смены состояния сервиса.";
       }
     }

     grouping service-status {
       description
         "Группировка состояния сервиса.";
       container status {
         description
           "Состояние сервиса.";
         container admin-status {
           description
             "Административный статус сервиса.";
           leaf status {
             type identityref {
               base administrative-status;
             }
             description
               "Административный статус сервиса.";
           }
           leaf last-change {
             type yang:date-and-time;
             description
               "Фактическая дата и время смены состояния сервиса.";
           }
         }
         container oper-status {
           config false;
           description
             "Рабочее состояние сервиса.";
           uses oper-status-timestamp;
         }
       }
     }

     grouping underlay-transport {
       description
         "Тип базового транспорта для услуги VPN или способ организации
          этой базы. Может включать идентификатор экземпляра абстрактного
          транспорта, с которым связана VPN, или указывать техническую 
          реализацию упорядоченным списком протоколов.";
       choice type {
         description
           "Выбор на основе типа ограничений базового транспорта.";
         case abstract {
           description
             "Указывает, что ограничение транспорта является абстракцией.";
           leaf transport-instance-id {
             type string;
             description
               "Необязательный идентификатор экземпляра абстрактного 
                транспорта.";
           }
           leaf instance-type {
             type identityref {
               base transport-instance-type;
             }
             description
               "Тип экземпляра транспорта, например, VPN+, сетевой слой 
                IETF, виртуальная сеть и т. п.";
           }
         }
         case protocol {
           description
             "Указывает список протоколов.";
           leaf-list protocol {
             type identityref {
               base protocol-type;
             }
             ordered-by user;
             description
               "Упорядоченный клиентом список транспортных протоколов.";
           }
         }
       }
     }

     grouping vpn-route-targets {
       description
         "Группировка, задающая правила импорта-экспорта RT в VPN с
          поддержкой BGP.";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 4664: Framework for Layer 2 Virtual Private Networks
                    (L2VPNs)";
       list vpn-target {
         key "id";
         description
           "RT. Могут быть заданы операции AND/OR на основе заданных RT.";
         leaf id {
           type uint8;
           description
             "Указывает каждую цель VPN.";
         }
         list route-targets {
           key "route-target";
           description
             "Список RT.";
           leaf route-target {
             type rt-types:route-target;
             description
               "Значение RT.";
           }
         }
         leaf route-target-type {
           type rt-types:route-target-type;
           mandatory true;
           description
             "Тип импорта-экспорта RT.";
         }
       }
       container vpn-policies {
         description
           "Правила сервиса VPN - ссылки на на правила, которые будут
            связаны с услугой VPN.";
         leaf import-policy {
           type string;
           description
             "Указывает политику импорта.";
         }
         leaf export-policy {
           type string;
           description
             "Указывает политику экспорта.";
         }
       }
     }

     grouping route-distinguisher {
       description
         "Группировка для различителей маршрутов (RD).";
       choice rd-choice {
         description
           "Выбор RD из нескольких значений.";
         case directly-assigned {
           description
             "Явное задание значения RD.";
           leaf rd {
             type rt-types:route-distinguisher;
             description
               "Указывает явное задание значения RD.";
           }
         }
         case directly-assigned-suffix {
           description
             "Значение поля Assigned Number для RD. Субполе
              Administrator в RD будет основано на других данных
              конфигурации, таких как Router ID или ASN.";
           leaf rd-suffix {
             type uint16;
             description
               "Указывает явное задание значения поля Assigned Number.";
           }
         }
         case auto-assigned {
           description
             "RD назначается автоматически.";
           container rd-auto {
             description
               "RD назначается автоматически.";
             choice auto-mode {
               description
                 "Режим автоназначения. RD может задаваться автоматически
                  с указанием или без указания пула, из которого следует
                  брать RD. В обоих случаях сервер автоматически задаёт 
                  значение RD auto-assigned-rd и применяет его в работе.";
               case from-pool {
                 leaf rd-pool-name {
                   type string;
                   description
                     "Автоназначение из пула, указанного rd-pool-name.";
                 }
               }
               case full-auto {
                 leaf auto {
                   type empty;
                   description
                     "Полностью автоматическое назначение RD.";
                 }
               }
             }
             leaf auto-assigned-rd {
               type rt-types:route-distinguisher;
               config false;
               description
                 "Автоматически заданное значение RD.";
             }
           }
         }
         case auto-assigned-suffix {
           description
             "Значение поля Assigned Number будет задаваться 
              автоматически. Поле Administrator будет основано на
              других данных конфигурации, таких как Router ID или ASN.";
           container rd-auto-suffix {
             description
               "Поле Assigned Number назначено автоматически.";
             choice auto-mode {
               description
                 "Режим автоматического назначения для Assigned Number.
                  Это число задаётся автоматически с указанием или без
                  указания используемого для выбора пула. В обоих случаях
                  сервер автоматически задаёт auto-assigned-rd-suffix и
                  использует это значение при создании RD для работы.";
               case from-pool {
                 leaf rd-pool-name {
                   type string;
                   description
                     "Назначение из пула, указанного rd-pool-name.";
                 }
               }
               case full-auto {
                 leaf auto {
                   type empty;
                   description
                     "Полностью автоматическое задание Assigned Number.";
                 }
               }
             }
             leaf auto-assigned-rd-suffix {
               type uint16;
               config false;
               description
                 "Автоматически заданное значение Assigned Number.";
             }
           }
         }
         case no-rd {
           description
             "Использует тип empty для указания отсутствия значения RD
              и его автоматического задания.";
           leaf no-rd {
             type empty;
             description
               "Значение RD не задано.";
           }
         }
       }
     }

     grouping vpn-components-group {
       description
         "Группировка для назначение групповых идентификаторов,
          связывающих узлы VPN, сайты или доступ в сеть.";
       container groups {
         description
           "Список групп, к которым относится узел VPN, сайт или
            доступ в сеть.";
         list group {
           key "group-id";
           description
             "Список групповых идентификаторов.";
           leaf group-id {
             type string;
             description
               "Идентификатор группы, к которой относится узел VPN, 
                сайт или доступ в сеть.";
           }
         }
       }
     }

     grouping placement-constraints {
       description
         "Ограничения по размещению доступа в сеть.";
       list constraint {
         key "constraint-type";
         description
           "Список ограничений.";
         leaf constraint-type {
           type identityref {
             base placement-diversity;
           }
           description
             "Тип ограничения разнообразия.";
         }
         container target {
           description
             "Ограничения будут применяться к этому списку групп.";
           choice target-flavor {
             description
               "Выбор для определения группы.";
             case id {
               list group {
                 key "group-id";
                 description
                   "Список групп.";
                 leaf group-id {
                   type string;
                   description
                     "Ограничения будут применяться к этой группе.";
                 }
               }
             }
             case all-accesses {
               leaf all-other-accesses {
                 type empty;
                 description
                   "Ограничения будут применяться ко всем другим видам
                    сетевого доступа к сайту.";
               }
             }
             case all-groups {
               leaf all-other-groups {
                 type empty;
                 description
                   "Ограничения будут применяться ко всем другим
                    группам, поддерживаемым клиентом.";
               }
             }
           }
         }
       }
     }

     grouping ports {
       description
         "Выбор для задания портов отправителя и получателя.";
       choice source-port {
         description
           "Указание порта источника или ссылка на группу портов.";
         container source-port-range-or-operator {
           description
             "Определение порта источника.";
           uses packet-fields:port-range-or-operator;
         }
       }
       choice destination-port {
         description
           "Указание порта получателя или ссылка на группу портов.";
         container destination-port-range-or-operator {
           description
             "Определение порта получателя.";
           uses packet-fields:port-range-or-operator;
         }
       }
     }

     grouping qos-classification-policy {
       description
         "Конфигурация правила классификации трафика.";
       list rule {
         key "id";
         ordered-by user;
         description
           "Список правил маркировки.";
         leaf id {
           type string;
           description
             "Идентификатор правила классификации QoS.";
         }
         choice match-type {
           default "match-flow";
           description
             "Выбор для классификации.";
           case match-flow {
             choice l3 {
               description
                 "IPv4 или IPv6.";
               container ipv4 {
                 description
                   "Набор правил для заголовка IPv4.";
                 uses packet-fields:acl-ip-header-fields;
                 uses packet-fields:acl-ipv4-header-fields;
               }
               container ipv6 {
                 description
                   "Набор правил для заголовка IPv6.";
                 uses packet-fields:acl-ip-header-fields;
                 uses packet-fields:acl-ipv6-header-fields;
               }
             }
             choice l4 {
               description
                 "Включает сведения L4 (TCP и UDP).";
               container tcp {
                 description
                   "Набор правил для заголовка TCP.";
                 uses packet-fields:acl-tcp-header-fields;
                 uses ports;
               }
               container udp {
                 description
                   "Набор правил для заголовка UDP.";
                 uses packet-fields:acl-udp-header-fields;
                 uses ports;
               }
             }
           }
           case match-application {
             leaf match-application {
               type identityref {
                 base customer-application;
               }
               description
                 "Задаёт приложение для сопоставления.";
             }
           }
         }
         leaf target-class-id {
           type string;
           description
             "Идентификатор класса сервиса (внутренний для
              домена администрирования).";
         }
       }
     }
   }
   <CODE ENDS>

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

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

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

Модуль ietf-vpn-common определяет набор идентификаторов, типов и группировок, предназначенных для использования в других модулях YANG. Сам модуль не раскрывает каких-либо узлов данных, доступных для записи, узлов, доступных лишь для чтения, или RPC. Поэтому с модулем ietf-vpn-common не связаны какие-либо дополнительные проблемы безопасности.

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

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

Агентство IANA зарегистрировало указанный ниже идентификатор URI в субреестре ns реестра IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-vpn-common
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

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

   Name:  ietf-vpn-common
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-vpn-common
   Maintained by IANA?  N
   Prefix:  vpn-common
   Reference:  RFC 9181

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

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

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

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

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

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

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

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

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, «Common YANG Data Types for the Routing Area», RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.

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

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

[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, «YANG Data Model for Network Access Control Lists (ACLs)», RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.

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

[ACTN-VN-YANG] Lee, Y., Ed., Dhody, D., Ed., Ceccarelli, D., Bryskin, I., and B. Yoon, «A YANG Data Model for VN Operation», Work in Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-13, 23 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-13>.

[Enhanced-VPN-Framework] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, «A Framework for Enhanced Virtual Private Network (VPN+) Services», Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-09, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-09>.

[IEEE802.1ad] IEEE, «IEEE Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks—Amendment 4: Provider Bridges», <https://standards.ieee.org/standard/802_1ad-2005.html>.

[IEEE802.1AX] IEEE, «IEEE Standard for Local and Metropolitan Area Networks—Link Aggregation», <https://standards.ieee.org/standard/802_1AX-2020.html>.

[IEEE802.1Q] IEEE, «IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks», <https://standards.ieee.org/standard/802_1Q-2018.html>.

[ISO10589] ISO, «Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)», International Standard 10589:2002, Second Edition, November 2002, <https://www.iso.org/standard/30932.html>.

[L2NM-YANG] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and L. Munoz, «A Layer 2 VPN Network YANG Model», Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 November 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-12>.

[Network-Slices-Framework] Farrel, A., Ed., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, LM., and J. Tantsura, «Framework for IETF Network Slices», Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05>.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, DOI 10.17487/RFC1701, October 1994, <https://www.rfc-editor.org/info/rfc1701>.

[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, «Generic Routing Encapsulation over IPv4 networks», RFC 1702, DOI 10.17487/RFC1702, October 1994, <https://www.rfc-editor.org/info/rfc1702>.

[RFC2003] Perkins, C., «IP Encapsulation within IP», RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>.

[RFC2080] Malkin, G. and R. Minnear, «RIPng for IPv6», RFC 2080, DOI 10.17487/RFC2080, January 1997, <https://www.rfc-editor.org/info/rfc2080>.

[RFC2236] Fenner, W., «Internet Group Management Protocol, Version 2», RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>.

[RFC2453] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC2473] Conta, A. and S. Deering, «Generic Packet Tunneling in IPv6 Specification», RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.

[RFC2710] Deering, S., Fenner, W., and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, «Internet Group Management Protocol, Version 3», RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

[RFC3810] Vida, R., Ed. and L. Costa, Ed., «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., «Layer Two Tunneling Protocol — Version 3 (L2TPv3)», RFC 3931, DOI 10.17487/RFC3931, March 2005, <https://www.rfc-editor.org/info/rfc3931>.

[RFC4026] Andersson, L. and T. Madsen, «Provider Provisioned Virtual Private Network (VPN) Terminology», RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.

[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, «Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management», RFC 4176, DOI 10.17487/RFC4176, October 2005, <https://www.rfc-editor.org/info/rfc4176>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, «OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.

[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling», RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., «Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling», RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., «LDP Specification», RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

[RFC5880] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD)», RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., «Multicast in MPLS/BGP IP VPNs», RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, «OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol», RFC 6565, DOI 10.17487/RFC6565, June 2012, <https://www.rfc-editor.org/info/rfc6565>.

[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, «Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling», RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, «Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks», RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, «Encapsulating MPLS in UDP», RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.

[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, «Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)», RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.

[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, «IPv6 Support for Generic Routing Encapsulation (GRE)», RFC 7676, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-editor.org/info/rfc7676>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, «Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised)», STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.

[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, «Seamless Bidirectional Forwarding Detection (S-BFD)», RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/info/rfc7880>.

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

[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, «Virtual Private Wire Service Support in Ethernet VPN», RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.

[RFC8277] Rosen, E., «Using BGP to Bind MPLS Labels to Address Prefixes», RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

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

[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, «A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)», RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., «Framework for Abstraction and Control of TE Networks (ACTN)», RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, «A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery», RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.

[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, «A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)», RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing with the MPLS Data Plane», RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, W., and Z. Li, «MPLS Segment Routing over IP», RFC 8663, DOI 10.17487/RFC8663, December 2019, <https://www.rfc-editor.org/info/rfc8663>.

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, «IPv6 Segment Routing Header (SRH)», RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., «Geneve: Generic Network Virtualization Encapsulation», RFC 8926, DOI 10.17487/RFC8926, November 2020, <https://www.rfc-editor.org/info/rfc8926>.

[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, «A YANG Network Data Model for Layer 3 VPNs», RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/info/rfc9182>.

Приложение A. Пример базовых узлов в ранних решениях L2NM/L3NM

Во избежание дублирования узлов данных и для упрощения обмена данными между уровнями (т. е. от сервисного уровня к сетевому и обратно) в ранних версиях L3NM применяется много узлов данных, определённых в L3SM. Тем не менее, от этого подхода отказались, поскольку он интерпретировался как зависимость развёртывания L3NM от L3SM, которая на деле не нужна. Например, сервис-провайдер может применять L3NM для организации услуг L3VPN без раскрытия клиентам L3SM.

Точно так же ранние версии L2NM использовали множество узлов данных, определённых в L2SM и L3NM. Пример группировки L3NM, применяемой в L2NM, показан на рисунке 5. Такое использование интерпретировалось как зависимость развёртывания L2NM от поддержки L3NM, которая на деле не требуется.

   module ietf-l2vpn-ntw {
    ...
     import ietf-l3vpn-ntw {
       prefix l3vpn-ntw;
       reference
         "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
     }
     ...
     container l2vpn-ntw {
       ...
       container vpn-services {
         list vpn-service {
           ...
           uses l3vpn-ntw:service-status;
           uses l3vpn-ntw:svc-transport-encapsulation;
           ...
         }
       }
       ...
     }
   }

Рисунок 5. Извлечение из модуля L2NM YANG.

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

В ходе обсуждения этой работы были получены полезные комментарии и обзоры от (в алфавитном порядке) Alejandro Aguado, Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Tom Petch, Erez Segev, Paul Sherratt. Большое им спасибо.

Работа частично поддерживалась европейской комиссией в рамках проекта Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow), грант № 101015857.

Большое спасибо Radek Krejci за рецензию YANG Doctors, Wesley Eddy за рецензию tsvart, Ron Bonica и Victoria Pritchard за рецензию RtgDir, Joel Halpern за рецензию genart, Tim Wicinski за рецензию opsdir и Suresh Krishnan за рецензию intdir.

Отдельная благодарность Robert Wilton за рецензию AD.

Спасибо Roman Danyliw, Lars Eggert, Warren Kumari, Erik Kline, Zaheduzzaman Sarker, Benjamin Kaduk, Éric Vyncke за рецензию IESG.

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

Italo Busi
Huawei Technologies
Email: Italo.Busi@huawei.com
 
Luis Angel Munoz
Vodafone
Email: luis-angel.munoz@vodafone.com
 
Victor Lopez
Nokia
Madrid
Spain
Email: victor.lopez@nokia.com

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

Samier Barguil
Telefonica
Madrid
Spain
Email: samier.barguilgiraldo.ext@telefonica.com
 
Oscar Gonzalez de Dios (editor)
Telefonica
Madrid
Spain
Email: oscar.gonzalezdedios@telefonica.com
 
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
 
Qin Wu
Huawei
101 Software Avenue
Yuhua District
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com

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

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

nmalykh@protokols.ru

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

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

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