RFC 9127 YANG Data Model for Bidirectional Forwarding Detection (BFD)

Internet Engineering Task Force (IETF)                    R. Rahman, Ed.
Request for Comments: 9127                                              
Category: Standards Track                                  L. Zheng, Ed.
ISSN: 2070-1721                                      Huawei Technologies
                                                    M. Jethanandani, Ed.
                                                     Xoriant Corporation
                                                           S. Pallagatti
                                                                  VMware
                                                               G. Mirsky
                                                                Ericsson
                                                            October 2021

YANG Data Model for Bidirectional Forwarding Detection (BFD)

Модель данных YAND для обнаружения двухсторонней пересылки

PDF

Аннотация

Этот документ определяет модель данных YANG, которая может служить для настройки и управления двухсторонним обнаружениям пересылки (Bidirectional Forwarding Detection или BFD).

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

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

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

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

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

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

Copyright (c) 2021. Авторские права принадлежат 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, которая может служить для настройки и управления обнаружением двухсторонней пересылки (BFD) [RFC5880]. Протокол BFD применяется для обнаружения живучести произвольных путей между системами. Некоторые примеры путей, на которых применим протокол BFD указаны ниже.

  1. Две системы, соединённые напрямую по IP. Это называется BFD через один интервал (single-hop) IP, а также BFD для IPv4 и IPv6 [RFC5881].

  2. Две системы, соединённые через несколько интервалов пересылки, как описано в Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

  3. Две системы, соединённые по пути с коммутацией по меткам MPLS (MPLS Label Switched Path или LSP), как описано в Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [RFC5884].

  4. Две системы, соединённые через интерфейс группы агрегирования каналов (Link Aggregation Group или LAG), как описано в Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130].

  5. Две системы, соединённые через псевдопровода (PW). Это называют проверкой связности виртуальных устройств (Virtual Circuit Connectivity Verification или VCCV), как описано в Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5885]. Данный вариант в документе не рассматривается.

BFD обычно не работает сам по себе. Различные протоколы управления (клиенты BFD) используют услуги BFD для своей работы, как описано в Generic Application of Bidirectional Forwarding Detection (BFD) [RFC5882]. Очевидными кандидатами на использование BFD являются протоколы, не имеющие своих сообщений hello для обнаружения отказов, например, статическая маршрутизация, протоколы маршрутизации, где сообщения hello не поддерживают обнаружение отказов за доли секунды, такие как OSPF и IS-IS.

Модули YANG в этом документе соответствуют архитектуре хранилищ NMDA [RFC8342]. Это значит, что модели данных не имеют контейнеров верхнего уровня или братских (sibling) контейнеров для данных конфигурации и рабочего состояния.

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

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Модель данных

Поскольку BFD применяется для определения живучести различных путей пересылки, единого ключа для идентификации сессий BFD нет. В результате модель данных BFD разделена на несколько модулей YANG, каждый из которых соответствует определённому типу путей. Например, BFD для IP с одной пересылкой имеет один модуль YANG, а BFD для MPLS — другой. Основным различием между этими модулями является способ однозначной идентификации сессий BFD для данного пути пересылки. Чтобы избежать дублирования определений BFD, базовые типы и группировки собраны в отдельном модуле.

Пределен новый протокол управления bfdv1 и создан контейнер bfd в control-plane-protocol, заданном в документе A YANG Data Model for Routing Management (NMDA Version) [RFC8349]. Этот новый контейнер bfd дополняется указанными ниже модулями YANG с конкретной информацией.

  1. Модуль ietf-bfd-ip-sh (параграф 2.14) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-sh для сессий BFD с одной пересылкой IP (single-hop).

  2. Модуль ietf-bfd-ip-mh» (параграф 2.15) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-mh для сессий BFD с несколькими пересылками IP (multihop).

  3. Модуль ietf-bfd-lag» (параграф 2.16) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером lag для сессий BFD через LAG.

  4. Модуль ietf-bfd-mpls» (параграф 2.17) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером mpls для сессий BFD через MPLS LSP.

BFD может работать в разном контексте, как указано ниже.


  1. На уровне сетевого устройства.

  2. В логический элементах сети (logical network element или LNE), как описано в YANG Model for Logical Network Elements [RFC8530].

  3. В экземплярах сетей, как описано в YANG Data Model for Network Instances [RFC8529].

При использовании на уровне сетевого устройства модель данных YANG BFD применяется «как есть» (as is). При использовании модели YANG BFD в LNE или экземпляре сети эта модель дополняет имеющуюся модель маршрутизации для LNE или экземпляра сети.

2.1. Модель конфигурации

Модель конфигурации включает в основном параметры, заданные в BFD [RFC5880], например, желаемый минимальный интервал передачи, требуемый минимальный интервал получения, множитель обнаружения.

Клиентами BFD являются приложения, применяющие BFD для быстрого обнаружения отказов. В некоторых реализациях имеется настройка сессии BFD для клиентов BFD, например, для приложений маршрутизации, таких как OSPF, IS-IS, BGP. В других реализациях сессии BFD настраиваются на уровне BFD целиком, т. е. не по клиентам.

Основные параметры BFD, интересующие клиентов, относятся к множителям и интервалам, поскольку эти параметры влияют на время схождения у клиентов BFD при возникновении отказа. Другие параметры, например, аутентификация BFD, не зависят от требований клиентов BFD. Конфигурации BFD для всех клиентов следует быть централизованной. Однако это создаёт проблему для клиентов BFD, автоматически находящих своих партнёров. Например, в IGP адрес партнёра не настраивается, протокол IGP просто включается на интерфейсе и партнёры обнаруживаются автоматически. Таким образом, при настройке BFD для партнёра IGP оператору сначала нужно узнать адрес партнёра. При обнаружении нового партнера будет добавляться конфигурация BFD. Для предотвращения таких проблем задана группировка client-cfg-parms (параграф 2.12) для настройки BFD клиентами — это позволяет клиентами, таким как IGP, иметь конфигурацию (множитель и интервалы) для нужной сессии BFD. Например, при обнаружении нового партнёра IGP для него будет создаваться сессия BFD, а при утере партнёра IGP его сессия будет удаляться. Механизмы создания и удаления сессий BFD выходят за рамки этого документа, но обычно это выполняется с использованием API, реализованного в модуле BFD на системе. В случае клиентов BFD, создающий сессии BFD на основе своей конфигурации, параметры аутентификации (при необходимости) по-прежнему задаются в BFD.

2.1.1. Базовые параметры конфигурации BFD

Ниже перечислены базовые параметры конфигурации BFD.

local-multiplier

Множитель времени обнаружения, как указано в BFD [RFC5880].

desired-min-tx-interval

Желаемый минимальный интервал передачи (Desired Min TX), как указано в BFD [RFC5880].

required-min-rx-interval

Требуемый минимальный интервал получения (Required Min RX), как указано в BFD [RFC5880].

Хотя BFD [RFC5880] разрашает разные интервалы для приёма и передачи, некоторые реализации позволяют пользователю задать лишь один интервал (для приёма и передачи). Модель данных YANG BFD поддерживает оба варианта и можно выбрать min-interval, используемый для приёма и передачи, а также desired-min-tx-interval и required-min-rx-interval. Это поддерживается через группировку base-cfg-parms (2.12. Модуль YANG для типов BFD), применяемую модулями YANG для разных путей пересылки.

Для аутентификации BFD имеется два параметра.

key-chain

Ссылка на key-chain, как задано в YANG Data Model for Key Chains [RFC8177]. Ключи, криптоалгоритмы, сроки действия ключей и т. п. определены в модели key-chain.

meticulous

Включает скрупулёзный (meticulous) режим, заданный в BFD [RFC5880].

2.1.2. IP с одной пересылкой

Для одной пересылки (single-hop) IP задано дополнение в узле данных bfd, как указано в параграфе 2. Узел ip-sh содержит список сессий IP single-hop, каждая из которых однозначно указывается интерфейсом и адресом получателя. Применяются параметры конфигурации, указанные в параграфе 2.1.1. Узел ip-sh содержит также список интерфейсов и служит для задания параметров аутентификации сессий BFD, создаваемых клиентами BFD (2.1. Модель конфигурации).

[RFC5880] и [RFC5881] не задают работу функции Echo непрерывно или по запросу. Поэтому механизм для запуска и остановки функции Echo зависит от реализации и должен задаваться через дополнение, как указано ниже.

  1. Конфигурация. Подходит для непрерывной функции Echo (см. Приложение A. Пример настройки функции Echo).

  2. RPC. Это подходит для функции Echo, работающей по запросам.

2.1.3. IP с множеством пересылок

Для IP с несколькими пересылками (multihop) задано дополнение в узле данных bfd, как указано в параграфе 2.

По причине наличия разных путей может возникать несколько сессий multihop IP между отправителем и получателем. Набор сессий называется session-group. Клюя для session-group состоит из двух элементов.

Source address — адрес отправителя

Адрес, относящийся к локальной системе в соответствии с Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

Destination address — адрес получателя

Адрес, относящийся к удаленной системе в соответствии с [RFC5883].

Применяются параметры конфигурации, указанные в параграфе 2.1.1.

Этот документ также определяет следующие параметры:

tx-ttl

TTL в исходящих пакетах управления BFD;

rx-ttl

минимальное значение TTL во входящих пакетах управления BFD.

2.1.4. Пути с коммутацией по меткам MPLS

Здесь рассматриваются пути MPLS LSP, с которых классом эквивалентности пересылки (Forwarding Equivalence Class или FEC) [RFC3031] служит адрес IP. Узел bfd (параграф 2) дополнен узлом mpls со списком сессий, однозначно указываемых префиксомIP. По причине использования разных путей может быть несколько сессий MPLS для MPLS FEC. Набор этих сессий указывается в session-group.

Поскольку эти LSP являются односторонними, на выходном узле нет конфигурации LSP.

Параметры BFD для выходного узла добавляются в иерархию mpls.

2.1.5. Группы агрегирования каналов

В соответствии с Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130] конфигурация BFD для LAG включает микросессии BFD для каждого канала в составе LAG. Поскольку параметры BFD являются атрибутами LAG, им следует находиться в иерархии LAG. Однако модели данных YANG для LAG не существует, поэтому узел lag добавлен к узлу bfd (параграф 2). Конфигурация задаётся на уровне LAG, имеется список групп LAG. IP-адрес получателя в микросессии BFD задаётся для LAG и семейства адресов (IPv4 или IPv6).

2.2. Модель рабочего состояния

Модель рабочего состояния включает общую статистику сессий BFD на устройстве и статистику каждой сессии. Общая статистика указывает общее число сессий BFD, число активных сессий и т. п. Эти сведения доступны глобально (для всех сессий BFD) в иерархии узла bfd (параграф 2), а также по типам путей пересылки. Для каждой сессии BFD включены три основных категории рабочего состояния, указанные ниже.

  1. Фундаментальные сведения о сессии BFD, такие как локальный и удалённый дискриминаторы, способность поддерживать режим Demand (по запросу).

  2. Сведения о работе сессии BFD (session-running), например, удалённый статус BFD и полученный код диагностики. Тругим примером служит фактический интервал передачи управляющих пакетов, который может отличаться от заданного желаемого минимального интервала. Другие примеры включают фактические интервалы между получаемыми пакетами управления и передаваемыми пакетами Echo.

  3. Подробные сведения о сессии, например, время включения-отключения (up/down), продолжительность состояния.

Для некоторых типов путей может быть более одной сессии на виртуальный путь к адресату. Например, в IP multihop и MPLS LSP может быть несколько сессий BFD от источника к одному получателю для тестирования разных путей (ECMP). Это представляется множеством sessions в иерархии каждой группы session-group.

2.3. Уведомления

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

2.4. Операции RPC

Нет.

2.5. Иерархия верхнего уровня BFD

В узле bfd (иерархия control-plane-protocol) нет данных конфигурации — только данные рабочего состояния, включающие общую статистику сессии BFD, т. е. BFD для вех типов путей пересылки.

   module: ietf-bfd
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol:
       +--rw bfd
          +--ro summary
             +--ro number-of-sessions?              yang:gauge32
             +--ro number-of-sessions-up?           yang:gauge32
             +--ro number-of-sessions-down?         yang:gauge32
             +--ro number-of-sessions-admin-down?   yang:gauge32

2.6. Иерархия BFD IP Single-Hop

Узел ip-sh добавляется в ветвь bfd иерархии control-plane-protocol. Этот узел содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP single-hop.

   module: ietf-bfd-ip-sh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-sh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
          |  +--rw session* [interface dest-addr]
          |     +--rw interface                         if:interface-ref
          |     +--rw dest-addr                         inet:ip-address
          |     +--rw source-addr?                      inet:ip-address
          |     +--rw local-multiplier?                 multiplier
          |     +--rw (interval-config-type)?
          |     |  +--:(tx-rx-intervals)
          |     |  |  +--rw desired-min-tx-interval?    uint32
          |     |  |  +--rw required-min-rx-interval?   uint32
          |     |  +--:(single-interval) {single-minimum-interval}?
          |     |     +--rw min-interval?               uint32
          |     +--rw demand-enabled?                   boolean
          |     |       {demand-mode}?
          |     +--rw admin-down?                       boolean
          |     +--rw authentication! {authentication}?
          |     |  +--rw key-chain?    key-chain:key-chain-ref
          |     |  +--rw meticulous?   boolean
          |     +--ro path-type?                        identityref
          |     +--ro ip-encapsulation?                 boolean
          |     +--ro local-discriminator?              discriminator
          |     +--ro remote-discriminator?             discriminator
          |     +--ro remote-multiplier?                multiplier
          |     +--ro demand-capability?                boolean
          |     |       {demand-mode}?
          |     +--ro source-port?                      inet:port-number
          |     +--ro dest-port?                        inet:port-number
          |     +--ro session-running
          |     |  +--ro session-index?                uint32
          |     |  +--ro local-state?                  state
          |     |  +--ro remote-state?                 state
          |     |  +--ro local-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-authenticated?         boolean
          |     |  +--ro remote-authentication-type?
          |     |  |       iana-bfd-types:auth-type {authentication}?
          |     |  +--ro detection-mode?               enumeration
          |     |  +--ro negotiated-tx-interval?       uint32
          |     |  +--ro negotiated-rx-interval?       uint32
          |     |  +--ro detection-time?               uint32
          |     |  +--ro echo-tx-interval-in-use?      uint32
          |     |          {echo-mode}?
          |     +--ro session-statistics
          |        +--ro create-time?
          |        |       yang:date-and-time
          |        +--ro last-down-time?
          |        |       yang:date-and-time
          |        +--ro last-up-time?
          |        |       yang:date-and-time
          |        +--ro down-count?                     yang:counter32
          |        +--ro admin-down-count?               yang:counter32
          |        +--ro receive-packet-count?           yang:counter64
          |        +--ro send-packet-count?              yang:counter64
          |        +--ro receive-invalid-packet-count?   yang:counter64
          |        +--ro send-failed-packet-count?       yang:counter64
          +--rw interfaces* [interface]
             +--rw interface         if:interface-ref
             +--rw authentication! {authentication}?
                +--rw key-chain?    key-chain:key-chain-ref
                +--rw meticulous?   boolean

     notifications:
       +---n singlehop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro interface?                   if:interface-ref
          +--ro echo-enabled?                boolean

2.7. Иерархия BFD IP Multihop

Узел ip-mh добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP multihop. В модели рабочего состояния поддерживается множество сессий BFD multihop на удалённый адрес (ECMP), ключом для них служит локальный дискриминатор.

   module: ietf-bfd-ip-mh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-mh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw session-groups
             +--rw session-group* [source-addr dest-addr]
                +--rw source-addr                       inet:ip-address
                +--rw dest-addr                         inet:ip-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw tx-ttl?                           bfd-types:hops
                +--rw rx-ttl                            bfd-types:hops
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                      +--ro create-time?
                      |       yang:date-and-time
                      +--ro last-down-time?
                      |       yang:date-and-time
                      +--ro last-up-time?
                      |       yang:date-and-time
                      +--ro down-count?
                      |       yang:counter32
                      +--ro admin-down-count?
                      |       yang:counter32
                      +--ro receive-packet-count?
                      |       yang:counter64
                      +--ro send-packet-count?
                      |       yang:counter64
                      +--ro receive-invalid-packet-count?
                      |       yang:counter64
                      +--ro send-failed-packet-count?
                              yang:counter64

     notifications:
       +---n multihop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref

2.8. Иерархия для BFD через LAG

Узел lag добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния каждой сессии BFD LAG.

   module: ietf-bfd-lag
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw lag
          +--rw micro-bfd-ipv4-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw micro-bfd-ipv6-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
             +--rw session* [lag-name]
                +--rw lag-name                          if:interface-ref
                +--rw ipv4-dest-addr?
                |       inet:ipv4-address
                +--rw ipv6-dest-addr?
                |       inet:ipv6-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw use-ipv4?                         boolean
                +--rw use-ipv6?                         boolean
                +--ro member-links* [member-link]
                   +--ro member-link       if:interface-ref
                   +--ro micro-bfd-ipv4
                   |  +--ro path-type?              identityref
                   |  +--ro ip-encapsulation?       boolean
                   |  +--ro local-discriminator?    discriminator
                   |  +--ro remote-discriminator?   discriminator
                   |  +--ro remote-multiplier?      multiplier
                   |  +--ro demand-capability?      boolean
                   |  |       {demand-mode}?
                   |  +--ro source-port?            inet:port-number
                   |  +--ro dest-port?              inet:port-number
                   |  +--ro session-running
                   |  |  +--ro session-index?                uint32
                   |  |  +--ro local-state?                  state
                   |  |  +--ro remote-state?                 state
                   |  |  +--ro local-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-authenticated?         boolean
                   |  |  +--ro remote-authentication-type?
                   |  |  |       iana-bfd-types:auth-type
                   |  |  |       {authentication}?
                   |  |  +--ro detection-mode?               enumeration
                   |  |  +--ro negotiated-tx-interval?       uint32
                   |  |  +--ro negotiated-rx-interval?       uint32
                   |  |  +--ro detection-time?               uint32
                   |  |  +--ro echo-tx-interval-in-use?      uint32
                   |  |          {echo-mode}?
                   |  +--ro session-statistics
                   |     +--ro create-time?
                   |     |       yang:date-and-time
                   |     +--ro last-down-time?
                   |     |       yang:date-and-time
                   |     +--ro last-up-time?
                   |     |       yang:date-and-time
                   |     +--ro down-count?
                   |     |       yang:counter32
                   |     +--ro admin-down-count?
                   |     |       yang:counter32
                   |     +--ro receive-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-packet-count?
                   |     |       yang:counter64
                   |     +--ro receive-invalid-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-failed-packet-count?
                   |             yang:counter64
                   +--ro micro-bfd-ipv6
                      +--ro path-type?              identityref
                      +--ro ip-encapsulation?       boolean
                      +--ro local-discriminator?    discriminator
                      +--ro remote-discriminator?   discriminator
                      +--ro remote-multiplier?      multiplier
                      +--ro demand-capability?      boolean
                      |       {demand-mode}?
                      +--ro source-port?            inet:port-number
                      +--ro dest-port?              inet:port-number
                      +--ro session-running
                      |  +--ro session-index?                uint32
                      |  +--ro local-state?                  state
                      |  +--ro remote-state?                 state
                      |  +--ro local-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-authenticated?         boolean
                      |  +--ro remote-authentication-type?
                      |  |       iana-bfd-types:auth-type
                      |  |       {authentication}?
                      |  +--ro detection-mode?               enumeration
                      |  +--ro negotiated-tx-interval?       uint32
                      |  +--ro negotiated-rx-interval?       uint32
                      |  +--ro detection-time?               uint32
                      |  +--ro echo-tx-interval-in-use?      uint32
                      |          {echo-mode}?
                      +--ro session-statistics
                         +--ro create-time?
                         |       yang:date-and-time
                         +--ro last-down-time?
                         |       yang:date-and-time
                         +--ro last-up-time?
                         |       yang:date-and-time
                         +--ro down-count?
                         |       yang:counter32
                         +--ro admin-down-count?
                         |       yang:counter32
                         +--ro receive-packet-count?
                         |       yang:counter64
                         +--ro send-packet-count?
                         |       yang:counter64
                         +--ro receive-invalid-packet-count?
                         |       yang:counter64
                         +--ro send-failed-packet-count?
                                 yang:counter64

     notifications:
       +---n lag-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro lag-name?                    if:interface-ref
          +--ro member-link?                 if:interface-ref

2.9. Иерархия для BFD через MPLS LSP

Узел mpls добавлен в ветвь bfd иерархии control-plane-protocol и содержит конфигурации для MPLS FEC. В модели рабочего состояния поддерживается множество сессий BFD на MPLS FEC (ECMP), ключом для них служит локальный дискриминатор. Узел mpls можно применять в сетевом устройстве (верхний уровень), а также устанавливать в LNE или экземпляре сети.

   module: ietf-bfd-mpls
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw mpls
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw egress
          |  +--rw enabled?                          boolean
          |  +--rw local-multiplier?                 multiplier
          |  +--rw (interval-config-type)?
          |  |  +--:(tx-rx-intervals)
          |  |  |  +--rw desired-min-tx-interval?    uint32
          |  |  |  +--rw required-min-rx-interval?   uint32
          |  |  +--:(single-interval) {single-minimum-interval}?
          |  |     +--rw min-interval?               uint32
          |  +--rw authentication! {authentication}?
          |     +--rw key-chain?    key-chain:key-chain-ref
          |     +--rw meticulous?   boolean
          +--rw session-groups
             +--rw session-group* [mpls-fec]
                +--rw mpls-fec                          inet:ip-prefix
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                   |  +--ro create-time?
                   |  |       yang:date-and-time
                   |  +--ro last-down-time?
                   |  |       yang:date-and-time
                   |  +--ro last-up-time?
                   |  |       yang:date-and-time
                   |  +--ro down-count?
                   |  |       yang:counter32
                   |  +--ro admin-down-count?
                   |  |       yang:counter32
                   |  +--ro receive-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-packet-count?
                   |  |       yang:counter64
                   |  +--ro receive-invalid-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-failed-packet-count?
                   |          yang:counter64
                   +--ro mpls-dest-address?      inet:ip-address

     notifications:
       +---n mpls-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro mpls-dest-address?           inet:ip-address

2.10. Взаимодействие с другими модулями YANG

В документе Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications [RFC8532] описано, как можно расширить независимой от уровня поддержки OAM (Layer-Independent OAM Management in the Multi-Layer Environment или LIME) без организации явных соединений для поддержки BFD.

Работа модели данных BFD зависит также от параметров конфигурации, определённых в других модулях YANG.

2.10.1. Модуль ietf-interfaces

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for Interface Management [RFC8343].

/if:interfaces/if:interface/if:enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD.

2.10.2. Модуль ietf-ip

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for IP Management [RFC8344].

/if:interfaces/if:interface/ip:ipv4/ip:enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

/if:interfaces/if:interface/ip:ipv4/ip:forwarding

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

/if:interfaces/if:interface/ip:ipv6/ip:enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

/if:interfaces/if:interface/ip:ipv6/ip:forwarding

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

2.10.3. Модуль ietf-mpls

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for MPLS Base [RFC8960].

/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/mpls:mpls-enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD.

2.11. Модуль YANG IANA BFD

Этот модуль YANG импортирует определения из [RFC5880], а также ссылается на [RFC5880] и [RFC6428].

   <CODE BEGINS> file "iana-bfd-types@2021-10-21.yang"
   module iana-bfd-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types";
     prefix iana-bfd-types;

     organization
       "IANA";
     contact
       "Internet Assigned Numbers Authority

        Postal: ICANN
                12025 Waterfront Drive, Suite 300
                Los Angeles, CA 90094-2536
                United States of America
        Tel:    +1 310 301 5800
        <mailto:iana@iana.org>"; 
     description
       "Этот модуль определяет типы данных YANG для зарегистрированных
        IANA параметров BFD.

        Этот модуль YANG поддерживается IANA и отражает реестры 
        BFD Diagnostic Codes и BFD Authentication Types.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Определения типов
      */

     typedef diagnostic {
       type enumeration {
         enum none {
           value 0;
           description
             "Нет диагностики.";
         }
         enum control-expiry {
           value 1;
           description
             "Истекло время обнаружения.";
         }
         enum echo-failed {
           value 2;
           description
             "Отказ функции Echo.";
         }
         enum neighbor-down {
           value 3;
           description
             "Сосед указал отключение сессии (Down).";
         }
         enum forwarding-reset {
           value 4;
           description
             "Сброс плоскости пересылки.";
         }
         enum path-down {
           value 5;
           description
             "Отключение пути (Down).";
         }
         enum concatenated-path-down {
           value 6;
           description
             "Отключение составного пути.";
         }
         enum admin-down {
           value 7;
           description
             "Административное отключение.";
         }
         enum reverse-concatenated-path-down {
           value 8;
           description
             "Отключение обратного составного пути.";
         }
         enum mis-connectivity-defect {
           value 9;
           description
             "Обнаружена ошибочная связность.";
           reference
             "RFC 5880: Bidirectional Forwarding Detection (BFD)
              RFC 6428: Proactive Connectivity Verification, Continuity
              Check, and Remote Defect Indication for the MPLS Transport
              Profile";
         }
       }
       description
         "Коды диагностики BFD в соответствии с RFC 5880. Значения кодов
          (0 - 31) поддерживаются в реестре IANA BFD Diagnostic Codes.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     typedef auth-type {
       type enumeration {
         enum reserved {
           value 0;
           description
             "Резерв.";
         }
         enum simple-password {
           value 1;
           description
             "Простой пароль.";
         }
         enum keyed-md5 {
           value 2;
           description
             "MD5 с ключом.";
         }
         enum meticulous-keyed-md5 {
           value 3;
           description
             "Скрупулёзный MD5 с ключом.";
         }
         enum keyed-sha1 {
           value 4;
           description
             "SHA1 с ключом.";
         }
         enum meticulous-keyed-sha1 {
           value 5;
           description
             "Скрупулёзный SHA1 с ключом.";
         }
       }
       description
         "Типы аутентификации BFD из RFC 5880. Значения (0 - 255) 
          поддерживаются в реестре IANA BFD Authentication Types.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }
   }
   <CODE ENDS>

2.12. Модуль YANG для типов BFD

Этот модуль YANG импортирует определения типов из [RFC6991] и [RFC8177], определения из [RFC5880], [RFC5881], [RFC5883], [RFC5884] и [RFC7130], а также отождествление control-plane-protocol из [RFC8349, и ссылки [RFC9127].

   <CODE BEGINS> file "ietf-bfd-types@2021-10-21.yang"
   module ietf-bfd-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types";
     prefix bfd-types;

     import iana-bfd-types {
       prefix iana-bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     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-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }
     import ietf-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения связанных с BFD типов данных
        YANG в соответствии с RFC 5880, а также группировки, применяемые
        совместно с другими модулям YANG BFD.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5880: Bidirectional Forwarding Detection (BFD)
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Определения свойств (функций)
      */

     feature single-minimum-interval {
       description
         "Указывает, что сервер поддерживает настройку 1 минимального
          значение для интервалов приёма и передачи.";
     }

     feature authentication {
       description
         "Указывает, что сервер поддерживает аутентификацию BFD.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.7";
     }

     feature demand-mode {
       description
         "Указывает, что сервер поддерживает режим BFD Demand.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.6";
     }

     feature echo-mode {
       description
         " Указывает, что сервер поддерживает режим BFD Echo.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.4";
     }

     /*
      * Определения отождествлений (идентификаторов)
      */

     identity bfdv1 {
       base rt:control-plane-protocol;
       description
         "Протокол BFD версии 1.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     identity path-type {
       description
         "Базовое отождествление для типа пути BFD, указывающего тип 
          пути, по которому работает BFD.";
     }

     identity path-ip-sh {
       base path-type;
       description
         "BFD через 1 интервал пересылки IP.";
       reference
         "RFC 5881: Bidirectional Forwarding Detection (BFD)
          for IPv4 and IPv6 (Single Hop)";
     }

     identity path-ip-mh {
       base path-type;
       description
         "BFD через множество интервалов пересылки IP.";
       reference
         "RFC 5883: Bidirectional Forwarding Detection (BFD) for
          Multihop Paths";
     }

     identity path-mpls-te {
       base path-type;
       description
         "BFD через MPLS TE.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
     }

     identity path-mpls-lsp {
       base path-type;
       description
         "BFD через MPLS LSP.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
     }

     identity path-lag {
       base path-type;
       description
         "Micro-BFD на канале из группы LAG.";
       reference
         "RFC 7130: Bidirectional Forwarding Detection (BFD) on
          Link Aggregation Group (LAG) Interfaces";
     }

     identity encap-type {
       description
         "Базовое отождествление типа инкапсуляции BFD.";
     }

     identity encap-ip {
       base encap-type;
       description
         "BFD с инкапсуляцией IP.";
     }

     /*
      * Определения типов
      */

     typedef discriminator {
       type uint32;
       description
         "Дискриминатор BFD, описанный в RFC 5880.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     typedef state {
       type enumeration {
         enum adminDown {
           value 0;
           description
             "Состояние adminDown.";
         }
         enum down {
           value 1;
           description
             "Состояние Down.";
         }
         enum init {
           value 2;
           description
             "Состояние Init.";
         }
         enum up {
           value 3;
           description
             "Состояние Up.";
         }
       }
       description
         "Состояния BFD в соответствии с RFC 5880.";
     }

     typedef multiplier {
       type uint8 {
         range "1..255";
       }
       description
         "Множитель BFD, определённый в RFC 5880.";
     }

     typedef hops {
       type uint8 {
         range "1..255";
       }
       description
         "Соответствует TTL в IPv4 и Hop Limit в IPv6.";
     }

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

     grouping auth-parms {
       description
         "Параметры аутентификации BFD (параграф 6.7 в RFC 5880).";
       container authentication {
         if-feature "authentication";
         presence "Включает аутентификацию (параграф 6.7 в RFC 5880).";
         description
           "Параметры аутентификации BFD.";
         reference
           "RFC 5880: Bidirectional Forwarding Detection (BFD),
            Section 6.7";
         leaf key-chain {
           type key-chain:key-chain-ref;
           description
             "Имя key-chain в соответствии с RFC 8177.";
         }
         leaf meticulous {
           type boolean;
           description
             "Включает скрупулёзный режим (параграф 6.7 в RFC 5880).";
         }
       }
     }

     grouping base-cfg-parms {
       description
         "Группировка BFD для базовых параметров конфигурации.";
       leaf local-multiplier {
         type multiplier;
         default "3";
         description
           "Multiplier transmitted by the local system.";
       }
       choice interval-config-type {
         default "tx-rx-intervals";
         description
           "Два или одно значение для интервалов приёма и передачи.";
         case tx-rx-intervals {
           leaf desired-min-tx-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Желаемый минимальный интервал передачи пакетов 
                управления.";
           }
           leaf required-min-rx-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Требуемый минимальный интервал получения пакетов
                управления.";
           }
         }
         case single-interval {
           if-feature "single-minimum-interval";
           leaf min-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Желаемый минимальный интервал передачи и требуемый
                минимальный интервал получения пакетов управления.";
           }
         }
       }
     }

     grouping client-cfg-parms {
       description
         "Группировка BFD для параметров конфигурации, применяемых 
          клиентами BFD, например, IGP или MPLS.";
       leaf enabled {
         type boolean;
         default "false";
         description
           "Указывает, разрешён ли протокол BFD.";
       }
       uses base-cfg-parms;
     }

     grouping common-cfg-parms {
       description
         "Группировка BFD для общих параметров конфигурации.";
       uses base-cfg-parms;
       leaf demand-enabled {
         if-feature "demand-mode";
         type boolean;
         default "false";
         description
           "Для включения режима Demand.";
       }
       leaf admin-down {
         type boolean;
         default "false";
         description
           "Указывает, была ли сессия BFD отключена административно.";
       }
       uses auth-parms;
     }

     grouping all-session {
       description
         "Сведения о работе сессии BFD.";
       leaf path-type {
         type identityref {
           base path-type;
         }
         config false;
         description
           "Тип пути, по которому работает BFD.";
       }
       leaf ip-encapsulation {
         type boolean;
         config false;
         description
           "Указывает, используется ли для BFD инкапсуляция IP.";
       }
       leaf local-discriminator {
         type discriminator;
         config false;
         description
           "Локальный дискриминатор.";
       }
       leaf remote-discriminator {
         type discriminator;
         config false;
         description
           "Удалённый дискриминатор.";
       }
       leaf remote-multiplier {
         type multiplier;
         config false;
         description
           "Удалённый множитель.";
       }
       leaf demand-capability {
         if-feature "demand-mode";
         type boolean;
         config false;
         description
           "Локальная поддержка режима Demand.";
       }
       leaf source-port {
         when "../ip-encapsulation = 'true'" {
           description
             "Порт-источник пригоден лишь при инкапсуляции IP.";
         }
         type inet:port-number;
         config false;
         description
           "Порт-источник UDP.";
       }
       leaf dest-port {
         when "../ip-encapsulation = 'true'" {
           description
             "Порт-получатель пригоден лишь при инкапсуляции IP.";
         }
         type inet:port-number;
         config false;
         description
           "Порт-получатель UDP.";
       }
       container session-running {
         config false;
         description
           "Информация о работе сессии BFD.";
         leaf session-index {
           type uint32;
           description
             "Индекс для однозначного указания сессий BFD.";
         }
         leaf local-state {
           type state;
           description
             "Локальное состояние.";
         }
         leaf remote-state {
           type state;
           description
             "Удалённое состояние.";
         }
         leaf local-diagnostic {
           type iana-bfd-types:diagnostic;
           description
             "Локальная диагностика.";
         }
         leaf remote-diagnostic {
           type iana-bfd-types:diagnostic;
           description
             "Удаленная диагностика.";
         }
         leaf remote-authenticated {
           type boolean;
           description
             "Указывает, аутентифицированы ли входящие пакеты 
              управления BFD.";
         }
         leaf remote-authentication-type {
           when "../remote-authenticated = 'true'" {
             description
               "Пригодно лишь при аутентифицированных входящих пакетах.";
           }
           if-feature "authentication";
           type iana-bfd-types:auth-type;
           description
             "Тип аутентификации входящих пакетов управления BFD.";
         }
         leaf detection-mode {
           type enumeration {
             enum async-with-echo {
               value 1;
               description
                 "Асинхронно с Echo.";
             }
             enum async-without-echo {
               value 2;
               description
                 "Асинхронно без Echo.";
             }
             enum demand-with-echo {
               value 3;
               description
                 "Demand с Echo.";
             }
             enum demand-without-echo {
               value 4;
               description
                 "Demand без Echo.";
             }
           }
           description
             "Режим детектирования.";
         }
         leaf negotiated-tx-interval {
           type uint32;
           units "microseconds";
           description
             "Согласованный интервал передачи.";
         }
         leaf negotiated-rx-interval {
           type uint32;
           units "microseconds";
           description
             "Согласованный интервал приёма.";
         }
         leaf detection-time {
           type uint32;
           units "microseconds";
           description
             "Время обнаружения.";
         }
         leaf echo-tx-interval-in-use {
           when "../../path-type = 'bfd-types:path-ip-sh'" {
             description
               "Echo поддерживается лишь для IP single-hop.";
           }
           if-feature "echo-mode";
           type uint32;
           units "microseconds";
           description
             "Применяемый интервал передачи Echo.";
         }
       }
       container session-statistics {
         config false;
         description
           "Статистика для сессии BFD.";
         leaf create-time {
           type yang:date-and-time;
           description
             "Дата и время создания сессии.";
         }
         leaf last-down-time {
           type yang:date-and-time;
           description
             "Дата и время последнего закрытия сессии (down).";
         }
         leaf last-up-time {
           type yang:date-and-time;
           description
             " Дата и время последнего открытия сессии (up).";
         }
         leaf down-count {
           type yang:counter32;
           description
             "Число переходов сессии в состояние down.";
         }
         leaf admin-down-count {
           type yang:counter32;
           description
             " Число переходов сессии в состояние admin-down.";
         }
         leaf receive-packet-count {
           type yang:counter64;
           description
             "Число полученных в сессии пакетов (включая непригодные).";
         }
         leaf send-packet-count {
           type yang:counter64;
           description
             "Число переданных в сессии пакетов.";
         }
         leaf receive-invalid-packet-count {
           type yang:counter64;
           description
             "Число полученных в сессии недействительных пакетов.";
         }
         leaf send-failed-packet-count {
           type yang:counter64;
           description
             "Число отказов при передаче пакетов в сессии.";
         }
       }
     }

     grouping session-statistics-summary {
       description
         "Группировка для сводной статистики сессий.";
       container summary {
         config false;
         description
           "Сводная статистика сессий BFD.";
         leaf number-of-sessions {
           type yang:gauge32;
           description
             "Число сессий BFD.";
         }
         leaf number-of-sessions-up {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии Up (в соответствии с 
              RFC 5880).";
         }
         leaf number-of-sessions-down {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии Down или Init, но не
              adminDown (в соответствии с RFC 5880).";
         }
         leaf number-of-sessions-admin-down {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии adminDown (в соответствии с 
              RFC 5880).";
         }
       }
     }

     grouping notification-parms {
       description
         "Группа описывает общие параметры, которые будут передаваться
          в уведомлениях BFD.";
       leaf local-discr {
         type discriminator;
         description
           "Локальный дискриминатор BFD.";
       }
       leaf remote-discr {
         type discriminator;
         description
           "Удалённый дискриминатор BFD.";
       }
       leaf new-state {
         type state;
         description
           "Текущее состояние BFD.";
       }
       leaf state-change-reason {
         type iana-bfd-types:diagnostic;
         description
           "Причина смены состояния BFD.";
       }
       leaf time-of-last-state-change {
         type yang:date-and-time;
         description
           "Календарное время последней смены состояния.";
       }
       leaf dest-addr {
         type inet:ip-address;
         description
           "Адрес партнёра BFD.";
       }
       leaf source-addr {
         type inet:ip-address;
         description
           "Локальный адрес BFD.";
       }
       leaf session-index {
         type uint32;
         description
           "Индекс для однозначного указания сессий BFD.";
       }
       leaf path-type {
         type identityref {
           base path-type;
         }
         description
           "Тип пути BFD.";
       }
     }
   }
   <CODE ENDS>

2.13. Модуль верхнего уровня для BFD

Этот модуль YANG импортирует и дополняет модуль /routing/control-plane-protocols/control-plane-protocol из [RFC8349]. Модуль также ссылается на [RFC5880].

   <CODE BEGINS> file "ietf-bfd@2021-10-21.yang"
   module ietf-bfd {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd";
     prefix bfd;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD 
        в соответствии с RFC 5880.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5880: Bidirectional Forwarding Detection (BFD)
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol" {
       when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" {
         description
           "Дополнение действительно лишь для экземпляра BFD
            в плоскости управления (тип bfdv1).";
       }
       description
         "Дополнение BFD.";
       container bfd {
         description
           "Контейнер верхнего уровня BFD.";
         uses bfd-types:session-statistics-summary;
       }
     }
   }
   <CODE ENDS>

2.14. Модуль BFD IP Single-Hop

Этот модуль YANG импортирует interface-ref из [RFC8343] и определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5881].

   <CODE BEGINS> file "ietf-bfd-ip-sh@2021-10-21.yang"
   module ietf-bfd-ip-sh {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh";
     prefix bfd-ip-sh;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD с одной
        пересылкой IP (single-hop) в соответствии с RFC 5881.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5881: Bidirectional Forwarding Detection (BFD)
        for IPv4 and IPv6 (Single Hop)
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

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

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для IP single-hop.";
       container ip-sh {
         description
           "Контейнер верхнего уровня BFD IP single-hop.";
         uses bfd-types:session-statistics-summary;
         container sessions {
           description
             "Сессии BFD IP single-hop.";
           list session {
             key "interface dest-addr";
             description
               "Список сессий IP single-hop.";
             leaf interface {
               type if:interface-ref;
               description
                 "Интерфейс, на котором работает сессия BFD.";
             }
             leaf dest-addr {
               type inet:ip-address;
               description
                 "IP-адрес партнера.";
             }
             leaf source-addr {
               type inet:ip-address;
               description
                 "Локальный адрес IP.";
             }
             uses bfd-types:common-cfg-parms;
             uses bfd-types:all-session;
           }
         }
         list interfaces {
           key "interface";
           description
             "Список интерфейсов.";
           leaf interface {
             type if:interface-ref;
             description
               "Сведения BFD для данного интерфейса.";
           }
           uses bfd-types:auth-parms;
         }
       }
     }

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

     notification singlehop-notification {
       description
         "Уведомление о смене состояния сессии BFD single-hop. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf interface {
         type if:interface-ref;
         description
           "Интерфейс, к которому относится эта сессия BFD.";
       }
       leaf echo-enabled {
         type boolean;
         description
           "Указывает, разрешены ли сообщения Echo для BFD.";
       }
     }
   }
   <CODE ENDS>

2.15. Модуль BFD IP Multihop

Этот модуль YANG импортирует определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5883].

   <CODE BEGINS> file "ietf-bfd-ip-mh@2021-10-21.yang"
   module ietf-bfd-ip-mh {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh";
     prefix bfd-ip-mh;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для BFD IP multihop
        в соответствии с RFC 5883.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5883: Bidirectional Forwarding Detection (BFD) for
        Multihop Paths
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

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

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для IP multihop.";
       container ip-mh {
         description
           "Контейнер верхнего уровня BFD IP multihop.";
         uses bfd-types:session-statistics-summary;
         container session-groups {
           description
             "Группы сессий BFD IP multihop.";
           list session-group {
             key "source-addr dest-addr";
             description
               "Группа сессий BFD IP multihop (для ECMP) между одной
                парой источник - получатель. Каждая сессия имеет своё 
                поле в заголовке UDP/IP для ECMP.";
             leaf source-addr {
               type inet:ip-address;
               description
                 "Локальный адрес IP.";
             }
             leaf dest-addr {
               type inet:ip-address;
               description
                 "IP-адрес партнера.";
             }
             uses bfd-types:common-cfg-parms;
             leaf tx-ttl {
               type bfd-types:hops;
               default "255";
               description
                 "Счётчик пересылок в выходных пакетах управления BFD.";
             }
             leaf rx-ttl {
               type bfd-types:hops;
               mandatory true;
               description
                 "Минимальное разрешённое значение счётчика интервалов 
                  во входящих пакетах управления BFD. Пакеты с меньшим
                  значением отбрасываются.";
             }
             list sessions {
               config false;
               description
                 "Множество сессий BFD между источником и получателем.";
               uses bfd-types:all-session;
             }
           }
         }
       }
     }

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

     notification multihop-notification {
       description
         "Уведомление о смене состояния сессии BFD multihop. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
     }
   }
   <CODE ENDS>

2.16. Модуль для BFD через LAG

Этот модуль YANG импортирует interface-ref из [RFC8343] и определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC7130].

   <CODE BEGINS> file "ietf-bfd-lag@2021-10-21.yang"
   module ietf-bfd-lag {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag";
     prefix bfd-lag;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для интерфейсов BFD через
        LAG в соответствии с RFC 7130.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 7130: Bidirectional Forwarding Detection (BFD) on
        Link Aggregation Group (LAG) Interfaces
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

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

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для LAG.";
       container lag {
         description
           "Контейнер верхнего уровня для BFD через LAG.";
         container micro-bfd-ipv4-session-statistics {
           description
             "Счётчики сессий Micro-BFD IPv4.";
           uses bfd-types:session-statistics-summary;
         }
         container micro-bfd-ipv6-session-statistics {
           description
             "Счётчики сессий Micro-BFD IPv6.";
           uses bfd-types:session-statistics-summary;
         }
         container sessions {
           description
             "Сессии BFD через LAG.";
           list session {
             key "lag-name";
             description
               "Список сессий BFD через LAG.";
             leaf lag-name {
               type if:interface-ref;
               description
                 "Имя LAG.";
             }
             leaf ipv4-dest-addr {
               type inet:ipv4-address;
               description
                 "Адрес IPv4 для партнёра в сессии IPv4 micro-BFD.";
             }
             leaf ipv6-dest-addr {
               type inet:ipv6-address;
               description
                 "Адрес IPv6 для партнёра в сессии IPv6 micro-BFD.";
             }
             uses bfd-types:common-cfg-parms;
             leaf use-ipv4 {
               type boolean;
               description
                 "Использование IPv4 micro-BFD.";
             }
             leaf use-ipv6 {
               type boolean;
               description
                 "Использование IPv6 micro-BFD.";
             }
             list member-links {
               key "member-link";
               config false;
               description
                 "Micro-BFD через LAG — один член группы.";
               leaf member-link {
                 type if:interface-ref;
                 description
                   "Канал, на котором работает micro-BFD.";
               }
               container micro-bfd-ipv4 {
                 when "../../use-ipv4 = 'true'" {
                   description
                     "Требуется лишь при использовании IPv4.";
                 }
                 description
                   "Состояние сессии Micro-BFD IPv4 на канале.";
                 uses bfd-types:all-session;
               }
               container micro-bfd-ipv6 {
                 when "../../use-ipv6 = 'true'" {
                   description
                     "Требуется лишь при использовании IPv6.";
                 }
                 description
                   "Состояние сессии Micro-BFD IPv6 на канале.";
                 uses bfd-types:all-session;
               }
             }
           }
         }
       }
     }

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

     notification lag-notification {
       description
         "Уведомление о смене состояния сессии BFD через LAG. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf lag-name {
         type if:interface-ref;
         description
           "Имя интерфейса LAG.";
       }
       leaf member-link {
         type if:interface-ref;
         description
           "Канал из группы, на котором работает BFD.";
       }
     }
   }
   <CODE ENDS>

2.17. Модуль для BFD через MPLS

Этот модуль YANG импортирует определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5586] и [RFC5884].

   <CODE BEGINS> file "ietf-bfd-mpls@2021-10-21.yang"
   module ietf-bfd-mpls {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls";
     prefix bfd-mpls;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD при
        работе через MPLS LSP в соответствии с RFC 5884.

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

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

        Эта версия модуля YANG является частью RFC 9127, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5884: Bidirectional Forwarding Detection (BFD)
        for MPLS Label Switched Paths (LSPs)
        RFC 9127: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Отождествления (идентификаторы)
      */

     identity encap-gach {
       base bfd-types:encap-type;
       description
         "BFD с инкапсуляцией G-ACh в соответствии с RFC 5586.";
       reference
         "RFC 5586: MPLS Generic Associated Channel";
     }

     identity encap-ip-gach {
       base bfd-types:encap-type;
       description
         "BFD с инкапсуляцией IP и G-ACh в соответствии с RFC 5586.";
     }

     /*
      * Groupings
      */

     grouping encap-cfg {
       description
         "Конфигурация для инкапсуляции BFD.";
       leaf encap {
         type identityref {
           base bfd-types:encap-type;
         }
         default "bfd-types:encap-ip";
         description
           "Инкапсуляция BFD.";
       }
     }

     grouping mpls-dest-address {
       description
         "Адрес получателя в соответствии с RFC 5884.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
       leaf mpls-dest-address {
         type inet:ip-address;
         config false;
         description
           "Адрес получателя в соответствии с RFC 5884
            Требуется при инкапсуляции IP.";
       }
     }

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

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для MPLS.";
       container mpls {
         description
           "Контейнер верхнего уровня BFD MPLS.";
         uses bfd-types:session-statistics-summary;
         container egress {
           description
             "Выходная конфигурация.";
           uses bfd-types:client-cfg-parms;
           uses bfd-types:auth-parms;
         }
         container session-groups {
           description
             "Группы сессий BFD через MPLS.";
           list session-group {
             key "mpls-fec";
             description
               "Группа сессий BFD MPLS (для ECMP). Группа сессий для
                одного класса FEC. Каждая сессия имеет своё поле в
                заголовке UDP/IP для ECMP.";
             leaf mpls-fec {
               type inet:ip-prefix;
               description
                 "MPLS FEC.";
             }
             uses bfd-types:common-cfg-parms;
             list sessions {
               config false;
               description
                 "Сессии BFD для MPLS FEC. Локальный дискриминатор
                  уникален для каждой сессии в группе.";
               uses bfd-types:all-session;
               uses bfd-mpls:mpls-dest-address;
             }
           }
         }
       }
     }

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

     notification mpls-notification {
       description
         "Уведомление о смене состояния сессии BFD через MPLS FEC. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf mpls-dest-address {
         type inet:ip-address;
         description
           "Адрес получателя в соответствии с RFC 5884.
            Требуется при инкапсуляции IP.";
       }
     }
   }
   <CODE ENDS>

3. Примеры моделей данных

В этом разделе представлены некоторые простые, иллюстративные примеры настройки BFD. В примерах применяется представление XML [W3C.REC-xml-20081126].

3.1. IP Single-Hop

Ниже приведён пример настройки сессии BFD IP single-hop. Для желаемого интервала передачи и требуемого интервала получения установлено значение 10 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
       <interface>
         <name>eth0</name>
         <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
           ianaift:ethernetCsmacd
         </type>
       </interface>
     </interfaces>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
               <sessions>
                 <session>
                   <interface>eth0</interface>
                   <dest-addr>2001:db8:0:113::101</dest-addr>
                   <desired-min-tx-interval>
                     10000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     10000
                   </required-min-rx-interval>
                 </session>
               </sessions>
             </ip-sh>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.2. IP Multihop

Ниже приведён пример настройки сессии BFD IP multihop. Для желаемого интервала передачи и требуемого интервала получения установлено значение 150 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <ip-mh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh">
               <session-groups>
                 <session-group>
                   <source-addr>2001:db8:0:113::103</source-addr>
                   <dest-addr>2001:db8:0:114::100</dest-addr>
                   <desired-min-tx-interval>
                     150000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     150000
                   </required-min-rx-interval>
                   <rx-ttl>240</rx-ttl>
                 </session-group>
               </session-groups>
             </ip-mh>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.3. LAG

Ниже приведён пример конфигурации сессии BFD через LAG. Здесь интерфейс Bundle-Ether1 типа ieee8023adLag имеет желаемый интервал передачи и требуемый интервал получения 10 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
       <interface>
         <name>Bundle-Ether1</name>
         <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
           ianaift:ieee8023adLag
         </type>
       </interface>
     </interfaces>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <lag xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-lag">
               <sessions>
                 <session>
                   <lag-name>Bundle-Ether1</lag-name>
                   <ipv6-dest-addr>2001:db8:112::16</ipv6-dest-addr>
                   <desired-min-tx-interval>
                     100000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     100000
                   </required-min-rx-interval>
                   <use-ipv6>true</use-ipv6>
                 </session>
               </sessions>
             </lag>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.4. MPLS

Ниже приведён пример настройки сессии BFD через MPLS LSP. Для желаемого интервала передачи и требуемого интервала получения установлено значение 250 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <mpls xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-mpls">
               <session-groups>
                 <session-group>
                   <mpls-fec>2001:db8:114::/116</mpls-fec>
                   <desired-min-tx-interval>
                     250000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     250000
                   </required-min-rx-interval>
                 </session-group>
               </session-groups>
             </mpls>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

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

Модули 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.

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

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions

Этот список задаёт сессии BFD IP single-hop. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD IP single-hop. Узлы source-addr и dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD IP single-hop.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-group

Этот список задаёт группы сессий BFD IP multihop. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD IP multihop. Узлы source-addr и dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD IP multihop.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions

Этот список задаёт группы сессий BFD через LAG. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через LAG. Узлы ipv4-dest-addr и ipv6-dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-group

Этот список задаёт группы сессий BFD через MPLS. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через MPLS LSP. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через MPLS LSP.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egress

Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через MPLS LSP, для которых это устройство служит выходным узлом MPLS LSP. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через MPLS LSP для таких узлов.

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

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

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

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/summary

Эти сведения раскрывают число сессий BFD IP single-hop в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions/session/

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IP single-hop.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summary

Эти сведения раскрывают число сессий BFD IP multihop в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-groups/session-group/sessions

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IP multihop.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv4-session-statistics/summary

Эти сведения раскрывают число сессий micro-BFD IPv4 LAG в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv4

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IPv4 LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv6-session-statistics/summary

Эти сведения раскрывают число сессий micro-BFD IPv6 LAG в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv6

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IPv6 LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summary

Эти сведения раскрывают число сессий BFD через MPLS LSP в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-groups/session-group/sessions

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD через MPLS LSP.

Этот документ не определяет операций RPC.

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

Этот документ регистрирует указанные ниже URI пространство имён в реестре IETF XML Registry [RFC3688].

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

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

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

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

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

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

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

Этот документ регистрирует указанные ниже модули YANG в реестре YANG Module Names [RFC6020].

   Name:  iana-bfd-types
   Namespace:  urn:ietf:params:xml:ns:yang:iana-bfd-types
   Prefix:  iana-bfd-types
   Reference:  RFC 9127

   Name:  ietf-bfd-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-types
   Prefix:  bfd-types
   Reference:  RFC 9127

   Name:  ietf-bfd
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd
   Prefix:  bfd
   Reference:  RFC 9127

   Name:  ietf-bfd-ip-sh
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh
   Prefix:  bfd-ip-sh
   Reference:  RFC 9127

   Name:  ietf-bfd-ip-mh
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh
   Prefix:  bfd-ip-mh
   Reference:  RFC 9127

   Name:  ietf-bfd-lag
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-lag
   Prefix:  bfd-lag
   Reference:  RFC 9127

   Name:  ietf-bfd-mpls
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-mpls
   Prefix:  bfd-mpls
   Reference:  RFC 9127

5.1. Поддерживаемый IANA модуль iana-bfd-types

This document defines the initial version of the IANA-maintained «iana-bfd-types» YANG module.

The «iana-bfd-types» YANG module mirrors the «BFD Diagnostic Codes» and «BFD Authentication Types» registries at <https://www.iana.org/assignments/bfd-parameters/>. Whenever these registries change, IANA must update the «iana-bfd-types» YANG module.

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

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

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., «MPLS Generic Associated Channel», RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.

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

[RFC5881] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)», RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.

[RFC5882] Katz, D. and D. Ward, «Generic Application of Bidirectional Forwarding Detection (BFD)», RFC 5882, DOI 10.17487/RFC5882, June 2010, <https://www.rfc-editor.org/info/rfc5882>.

[RFC5883] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for Multihop Paths», RFC 5883, DOI 10.17487/RFC5883, June 2010, <https://www.rfc-editor.org/info/rfc5883>.

[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)», RFC 5884, DOI 10.17487/RFC5884, June 2010, <https://www.rfc-editor.org/info/rfc5884>.

[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., «Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)», RFC 5885, DOI 10.17487/RFC5885, June 2010, <https://www.rfc-editor.org/info/rfc5885>.

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

[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., «Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces», RFC 7130, DOI 10.17487/RFC7130, February 2014, <https://www.rfc-editor.org/info/rfc7130>.

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

[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, «YANG Data Model for Key Chains», RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/info/rfc8177>.

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

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

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

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

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

[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, «A YANG Data Model for MPLS Base», RFC 8960, DOI 10.17487/RFC8960, December 2020, <https://www.rfc-editor.org/info/rfc8960>.

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

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., «Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile», RFC 6428, DOI 10.17487/RFC6428, November 2011, <https://www.rfc-editor.org/info/rfc6428>.

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

[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Data Model for Network Instances», RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.

[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Model for Logical Network Elements», RFC 8530, DOI 10.17487/RFC8530, March 2019, <https://www.rfc-editor.org/info/rfc8530>.

[RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, «Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications», RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.

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

Приложение A. Пример настройки функции Echo

Как отмечено в параграфе 2.1.2, механизм запуска и остановки функции Echo (определён в [RFC5880] и обсуждается в [RFC5881]) зависит от реализации. В этом приложении дан пример реализации функции Echo через настройку.

   module: example-bfd-echo
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
               /bfd-ip-sh:sessions:
       +--rw echo {bfd-types:echo-mode}?
          +--rw desired-min-echo-tx-interval?    uint32
          +--rw required-min-echo-rx-interval?   uint32

A.1. Пример модуля YANG для настройки функции BFD Echo

В этом приложении приведён пример модуля YANG для настройки функции BFD Echo. Модуль импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5880].

   module example-bfd-echo {
     namespace "tag:example.com,2021:example-bfd-echo";
     prefix example-bfd-echo;

     import ietf-bfd-types {
       prefix bfd-types;
     }
     import ietf-bfd {
       prefix bfd;
     }
     import ietf-bfd-ip-sh {
       prefix bfd-ip-sh;
     }
     import ietf-routing {
       prefix rt;
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит пример дополнения YANG для настройки
        функции BFD Echo.

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

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

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

     revision 2021-09-03 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

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

     grouping echo-cfg-parms {
       description
         "Группировка BFD для параметров конфигурации Echo.";
       leaf desired-min-echo-tx-interval {
         type uint32;
         units "microseconds";
         default "0";
         description
           "Минимальный интервал, который локальная система будет 
            применять при отправке пакетов BFD Echo. Значение 0
            отключает функцию Echo, как указано в BFD (RFC 5880).";
       }
       leaf required-min-echo-rx-interval {
         type uint32;
         units "microseconds";
         default "0";
         description
           "Required Min Echo RX Interval, заданный в BFD (RFC 5880).";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
           + "bfd-ip-sh:sessions" {
       description
         "Дополнение для функции BFD Echo.";
       container echo {
         if-feature "bfd-types:echo-mode";
         description
           "Контейнер функции BFD Echo.";
         uses echo-cfg-parms;
       }
     }
   }

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

Авторы признательны Nobo Akiya и Jeff Haas за поддержку этой работы. Спасибо Tom Petch за комментарии к документу. Спасибо Acee Lindem за его руководство. Спасибо Jürgen Schönwälder за важную роль в улучшении модулей YANG.

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


Reshad Rahman (editor)
Canada
Email: reshad@yahoo.com
 
Lianshu Zheng (editor)
Huawei Technologies
China
Email: veronique_cheng@hotmail.com
 
Mahesh Jethanandani (editor)
Xoriant Corporation
1248 Reamwood Ave
Sunnyvale, California 94089
United States of America
Email: mjethanandani@gmail.com
 
Santosh Pallagatti
VMware
India
Email: santosh.pallagatti@gmail.com
 
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9119 Multicast Considerations over IEEE 802 Wireless Media

Internet Engineering Task Force (IETF)                        C. Perkins
Request for Comments: 9119                                   Lupin Lodge
Category: Informational                                       M. McBride
ISSN: 2070-1721                                                Futurewei
                                                              D. Stanley
                                                                     HPE
                                                               W. Kumari
                                                                  Google
                                                              JC. Zúñiga
                                                                  SIGFOX
                                                            October 2021

Multicast Considerations over IEEE 802 Wireless Media

Групповая передача в беспроводных средах IEEE 802

PDF

Аннотация

Хорошо известные проблемы с групповой адресацией (multicast) помешали развёртыванию группового взаимодействия в сетях 802.11 (Wi-Fi) и других беспроводных средах локального действия. В этом документе описаны известные ограничения группового обмена на канальном уровне (L2) в беспроводных сетях (в основном 802.11). Описаны также некоторые возможности улучшения, найденные IETF и IEEE 802 для беспроводных сред, а также некоторые варианты использования, способные повысить производительность сетей. Кроме того, приведены некоторые рекомендации по использованию и комбинированию этих улучшений, а также рассмотрены вопросы эксплуатации.

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

Документ относится к категории информационных и не задаёт стандартов Internet.

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

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

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

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

Хорошо известные проблемы с групповой адресацией помешали развёртыванию группового взаимодействия в сетях 802.11 [dot11] и других локальных беспроводных средах, как описано в [mc-props] и [mc-prob-stmt]. Проблемы наблюдались при групповой адресации в протоколах IETF, использующих беспроводные среды IEEE 802. Хотя улучшения для групповой передачи были разработаны в IETF и IEEE 802, между спецификациями и реализациями, а также настройками сохраняется несовместимость.

Многие протоколы IETF зависят от широковещательной или групповой доставки управляющих сообщений множеству получателей. Групповая адресация позволяет передать данные множеству заинтересованных получателей без необходимости отправки копии каждому. При широковещательной передаче данные отправляются каждому устройству, независимо от его заинтересованности в них. Групповая передача применяется для таких целей, как обнаружение соседей (Neighbor Discovery или ND), лавинная рассылка по сети и распознавание адресов, а также для снижения нагрузки на сеть при передаче данных, предназначенных множеству адресатов. Помимо использования широковещательной и групповой передачи для пакетов управления, её применяют многие приложения, такие как Push To Talk3 в больницах, видеослужбы на предприятиях, университетах и в жилых домах, отправляя групповые пакеты IP устройствам конечных пользователей, которые все чаще применяют Wi-Fi.

Протоколы IETF обычно полагаются на многоуровневую структуру протоколов для снижения или исключения зависимости протоколов более высокого уровня от конкретной природы уровня MAC или физической среды. В случае групповой передачи протоколы верхних уровней обычно разрабатывались в предположении, что передача пакета по адресу IP равноценна в плане помех и доступа к сетевой среде, независимо от использования индивидуального, группового или широковещательного IP-адреса получателя. Эта модель подходит для сетей с передачей по кабелю, таким как Ethernet. К сожалению во многих беспроводных средах «стоимость» доступа к среде может существенно меняться. Групповая передача через сеть Wi-Fi часто имеет столь низкую производительность, что её просто не разрешают. Были разработаны некоторые усовершенствования для протоколов IETF, которые предполагалось использовать в основном в беспроводных средах. Однако эти улучшения обычно не получали широкого распространения в большинстве беспроводных сетей.

Беспроводные протоколы IEEE 802 были разработаны с некоторыми функциями для поддержки группового трафика. Например, для передачи групповых кадров применяется более низкая частота модуляции и они могут быть получены всеми станциями в ячейке, независимо от расстояния и затухания на пути от базовой станции или точки доступа (Access Point или AP). Однако такие передачи с более низкочастотной модуляцией дольше занимают среду, препятствуя эффективной передаче трафика с более высокочастотной модуляцией для расположенных близко станций. По этой и другим причинам рабочие группы IEEE 802, такие как 802.11, разработали средства повышения эффективности групповой передачи на уровне L2 [ietf_802-11]. Дополнительное улучшение работы при использовании групповой передачи может быть достигнуто с помощью некоторых эксплуатационных и конфигурационных решений (см. раздел 5).

Похоже, все уже согласились с тем, что эти проблемы не будут решены в ближайшее время в первую очередь из-за того, что это дорого и групповая передача не обеспечивает надёжности. По сравнению с индивидуальным трафиком Wi-Fi, групповой рассматривается как нечто второсортное, несмотря на наличие множества протоколов, использующих multicast-передачу. Нужны какие-то средства повышения надёжности групповой передачи. Протокол IPv6 ND, насыщающий каналы Wi-Fi является лишь частью проблемы. В решении могут помочь классы трафика Wi-Fi. Этот документ нацелен на прояснение вопроса о том, какие проблемы следует решать в IETF, а какие — в IEEE (раздел 8).

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

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

ACK

Подтверждение канального уровня 802.11 L2.

AES-CCMP

Протокол AES-Counter Mode CBC-MAC.

AP

Точка доступа IEEE 802.11.

Basic rate — базовая скорость

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

DVB-H

Digital Video Broadcasting — Handheld — переносное устройство для цифрового приёма видео.

DVB-IPDC

Digital Video Broadcasting — Internet Protocol Datacasting — передача данных IP через цифровое вещание видео.

DTIM

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

MCS

Modulation and Coding Scheme — схема модуляции и кодирования.

NOC

Network Operations Center — сетевой операционный центр.

PER

Packet Error Rate — частота ошибок в пакетах.

STA

Станция 802.11 (например, переносное устройство).

TIM

Traffic Indication Map (карта индикации трафика) — информационный элемент, сообщающий о наличии или отсутствии у ассоциированных станций буферизованных индивидуальных кадров.

TKIP

Temporal Key Integrity Protocol — протокол защиты целостности временных ключей.

WiMAX

Worldwide Interoperability for Microwave Access

WPA

Wi-Fi Protected Access — защищённый доступ к Wi-Fi.

3. Известные проблемы групповой передачи

3.1. Проблемы на уровне L2 и ниже

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

3.1.1. Ненадёжность групповой передачи

Надёжность группового трафика обычно значительно ниже, чем индивидуального. Поскольку для групповой передачи применяется режим «один со многими», для подтверждения доставки требуется передача множества пакетов. Однако для групповой передачи подтверждения (ACK) не применяются и точка доступа (AP) не знает, требуется ли повторная отправка. Даже в кабельной части Internet с этим зачастую связан нежелательно высокий уровень ошибок. В результате групповые приложения внедряются сравнительно медленно, хотя протоколы для них давно доступны. В беспроводных сетях ситуация значительно хуже и очень чувствительна к наличию фонового трафика. В результате может наблюдаться очень высокая частота пакетных ошибок (packet error rate или PER) из-за отсутствия повторов передачи и снижения скорости отправки. PER представляет собой долю (в процентах) пакетов, которые не были получены устройством. Нередко этот уровень превышает 5%, что особенно неприятно для видео и других данных, где нужна высокая скорость и надёжность.

3.1.2. Низкая и переменная скорость передачи данных

Групповая передача по кабелям отличается от беспроводной, поскольку кабельные каналы обычно работают на фиксированной скорости. Скорость передачи в Wi-Fi зависит от близости STA к AP. Полоса видеопотоков и пропускная способность в большой сети Wi-Fi будет меняться при перемещении устройства. Это влияет на возможности решений QoS эффективно резервировать пропускную способность и обеспечивать контроль подачи данных в сеть.

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

Поскольку более отказоустойчивые схемы модуляции и кодирования (modulation and coding scheme или MCS) обеспечивают большую дальность, но меньшую скорость, широковещательный и групповой трафик обычно передаётся с наименьшей среди всех подключённых устройств скоростью. Эту скорость называют базовой. Уровень дополнительных помех зависит от конкретной беспроводной технологии. Фактически, совместимость с более старыми устройствами и многопоточные реализации позволяют передавать индивидуальный трафик со скоростью несколько Гбит/с, а разница скорости передачи группового или широковещательного трафика и оптимальной скорости индивидуального трафика может превышать 3 порядка. Некоторые методы повышения спектральной эффективности, такие как пространственное мультиплексирование в системах с несколькими входами и выходами (Multiple Input Multiple Output или MIMO) недоступны для нескольких получателей. Совместимость со старыми версиями не является единственным фактором ограничения скорости групповой передачи.

Проводная групповая передача также влияет на беспроводные LAN, когда AP служит расширением кабельного сегмента. В этом случае групповые и широковещательные кадры на проводной стороне ЛВС копируются в беспроводную сеть (Wireless Local Area Network или WLAN). Поскольку широковещательные сообщения передаются с более отказоустойчивыми схемами MCS, многие большие кадры отправляются с малой скоростью через беспроводный канал.

3.1.3. Пропускная способность и влияние на помехи

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

3.1.4. Влияние энергосбережения на групповой трафик

Одной из характеристик групповой передачи в Wi-Fi является настройка каждой станции на пробуждение по приёму группового кадра, даже если тот будет в итоге отброшен. Это оказывает сильное влияние на потребляемую станцией энергию. По этой причине были найдены некоторые обходные пути, такие как направленная групповая передача (Directed Multicast Service или DMS), описанная в разделе 4, чтобы избежать пробуждения станций.

Групповая и индивидуальная передача может плохо работать с механизмами энергосбережения IEEE 802.11e в силу перечисленных ниже причин.

  • Клиенты могут быть не способны оставаться в спящем режиме из-за частого пробуждения групповыми пакетами управления.

  • Индивидуальный пакет задерживается, пока STA не проснётся и не запросит его. Задержка индивидуального трафика может также служить для экономии энергии, а также повышения эффективности и вероятности агрегирования.

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

  • Пакеты могут отбрасываться из-за ограничений буферов в AP и STA без AP.

3.2. Проблемы на уровне L3 и выше

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

  • сигнализация плоскости управления;

  • обнаружение соседей;

  • распознавание адресов;

  • обнаружение служб;

  • приложения (доставка видео, данных складов и т. п.);

  • маршрутизация по запросу;

  • создание магистрали;

  • другие протоколы L3 (не IP).

Протокол пользовательских дейтаграмм (User Datagram Protocol или UDP наиболее распространён для доставки группового трафика. Сам по себе, протокол UDP не обеспечивает гарантий и сообщения могут теряться или менять порядок доставки.

3.2.1. Проблемы IPv4

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

  • ARP [RFC0826].

  • DHCP [RFC2131].

  • Multicast DNS (mDNS) [RFC6762].

  • Universal Plug and Play (uPnP) [RFC6970].

После начальной настройки ARP (см. ниже), DHCP и uPnP применяются достаточно редко, но обнаружение служб может происходить в любой момент. Некоторые широко распространённые протоколы обнаружения служб (например, для поиска принтеров) используют механизм mDNS (групповой), который операторы часто блокируют. Даже при отслеживании групповой передачи [RFC4541] (которое обеспечивает сохранение пропускной способности сегментов сети, где ни один узел не заявил интереса в получении пакетов по этому групповому адресу) одновременно может регистрироваться много устройств, существенно снижая производительность сети.

3.2.2. Проблемы IPv6

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

  • DHCPv6 [RFC8415];

  • Protocol Independent Multicast (PIM) [RFC7761];

  • IPv6 Neighbor Discovery Protocol (NDP) [RFC4861];

  • Multicast DNS (mDNS) [RFC6762];

  • Router Discovery [RFC4286].

Сообщения IPv6 NDP Neighbor Solicitation (NS) при обнаружении дубликатов адресов (Duplicate Address Detection или DAD) и поиске адресов могут использовать групповую адресацию с областью действия на локальном канале (link-scope). В отличие от IPv4, узел IPv6 обычно использует несколько адресов и может часто менять их по соображениям приватности. Влияние групповых сообщений возрастает при мобильности устройств. Анонсы маршрутизаторов (Router advertisement или RA) также периодически передаются по групповым адресам.

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

3.2.3. Проблемы MLD

Обнаружение слушателей группового трафика (Multicast Listener Discovery или MLD) [RFC4541] применяется для обнаружения членов multicast-группы, подключённых к портам коммутатора. Пересылка групповых кадров в область с поддержкой Wi-Fi может использовать поддержку коммутатором сведений о пересылке на аппаратном уровне. По причине интенсивного применения групповой передачи в IPv6 для каждой станции STA с адресом IPv6 потребуется хранить в коммутаторе состояние для нескольких (возможно многих) групповых адресов solicited-node. Это групповые адреса IPv6Ю используемые протоколом NDP для проверки занятости адресов IPv6 на локальном канале. Групповые адреса, для которых не установлено состояние пересылки (возможно по причине недостатка памяти в коммутаторе), будут вызывать лавинную рассылку во все порты коммутатора. Некоторые производители коммутаторов не поддерживают MLD для групповой передачи link-scope, по причине требований к поддержке состояний.

3.2.4. Ложное обнаружение соседей

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

Частота этих запросов ARP пропорциональна размеру подсетей, темпам сканирования и обратного рассеяния, а также времени хранения маршрутизатором состояний для отсутствия ответов ARP. Оказывается, что эта частота обратно пропорциональная заполненности подсети (действительные ARP сохраняются в кэше без широковещательных повторов, а неиспользуемые адреса IP не отвечают на запросы, что увеличивает широковещательный трафик). В зависимости от используемого пространства адресов, времени суток, заполненности сети и других (неизвестных) факторов могут наблюдаться тысячи широковещательных пакетов в секунду. Наблюдалось около 2000 широковещательных пакетов в секунду в сети IETF NOC во время конференций.

С помощью протокола Neighbor Discovery для IPv6 [RFC4861] узлы распознают адреса путём групповой передачи сообщений Neighbor Solicitation, запрашивающих у узлов адрес канального уровня. Сообщения Neighbor Solicitation передаются по групповому адресу solicited-node. Целевой узел возвращает адрес канального уровня в индивидуальном сообщении Neighbor Advertisement. Одной пары пакетов с запросом и откликом достаточно для инициатора и цели, чтобы узнать адреса канального уровня друг друга (инициатор включает его в Neighbor Solicitation).

В кабельных сетях нет большой разницы между индивидуальным, групповым и широковещательным трафиком. В результате аппаратной фильтрации (см., например, [Deri-2010]) непреднамеренный лавинный трафик (или избыточные групповые кадры Ethernet) в кабельной сети может быть значительно «дешевле» по сравнению с беспроводными сетями, где спящие устройства пробуждаются для обработки пакетов. Кабельные сети Ethernet как правило являются коммутируемыми, что дополнительно снижает помехи от группового трафика. Фактически не возникает проблем с коллизиями и планированием за исключением случаев чрезвычайно высокой загрузки порта. В беспроводных сетях это не так и оборудование зачастую неспособно передавать большие объёмы широковещательного и группового трафика, что ведёт к отбрасыванию значительной части таких пакетов. Поэтому при подключении хоста он зачастую не может завершить процедуру DHCP и пакеты IPv6 RA отбрасываются, что препятствует доступу пользователя в сеть.

4. Оптимизация группового протокола

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

4.1. Proxy ARP в 802.11-2012

AP знает адреса L2 (Medium Access Control или MAC) и IP всех связанных с ней STA. Таким образом, AP выступает центральным «менеджером» для всех 802.11 STA в наборе базовых служб (Basic Service Set или BSS). Proxy ARP легко реализовать на AP, обеспечив указанные ниже преимущества.

  • Снижение широковещательного трафика (передаётся с низкими MCS) в беспроводной среде.

  • STA может более эффективно использовать спящий режим, поскольку запросы ARP для её адреса IP обрабатывает AP.

  • Кадры ARP не попадают в беспроводную среду.

  • Не требуется менять реализации STA.

Ниже приведён фрагмент спецификации из параграфа 10.23.13 [dot11-proxyarp].

Когда AP поддерживает Proxy ARP «[…] AP нужно поддерживать сопоставление аппаратных адресов с адресами Internet для каждой связанной станции и обновлять сопоставление при смене станцией адреса Internet. При преобразовании адреса IPv4 с помощью запроса ARP от станции STA без AP, связанной с BSS, службе Proxy ARP нужно отвечать от имени STA на запрос ARP или пакет ARP Probe.

4.2. Регистрация адресов IPv6 и Proxy ND

В этом параграфе персональной беспроводной со слабым питанием (Low-Power Wireless Personal Area Network или 6LoWPAN) считается сеть со слабым питанием и потерями (Low-Power and Lossy Network или LLN), поддерживающая сжатие заголовков 6LoWPAN (Header Compression или HC) [RFC6282]. Примером 6LoWPAN является сеть 6TiSCH [RFC9030]. Для контроля использования групповой передачи IPv6 через сети 6LoWPAN разработан стандарт 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775], определяющий механизм регистрации адресов на основе центрального реестра, контролирующего уникальность адресов вместо неэффективного механизма DAD применяемого протоколом обнаружения соседей IPv6 (Neighbor Discovery Protocol или NDP) [RFC4861] [RFC4862].

Рабочая группа 6lo подготовила обновление [RFC6775]. Беспроводное устройство может регистрировать свой адрес на магистральном маршрутизаторе (Backbone Router) [RFC8929], который служит посредником к IPv6 NDP, работающему высокоскоростной магистрали агрегирования. Обновление также включает механизм прокси-регистрации от имени зарегистрированного узла, например, через маршрутизатор 6LoWPAN, к которому подключён мобильный узел.

Общая идея концепции магистрального маршрутизатора заключается в том, что широковещательные и групповые сообщения следует строго контролировать в разных WLAN и персональных беспроводных сетях (Wireless Personal Area Network или WPAN). Связность с конкретным каналом, обеспечивающим подсеть, следует сохранить на уровне L3. Модель работы Backbone Router показана на рисунке 1.

          |
        +-----+
        |     | Принятый по умолчанию маршрутизатор
        |     |
        +-----+
           |
           |      Магистральный канал
     +--------------------+------------------+
     |                    |                  |
  +-----+             +-----+             +-----+
  |     |Магистральный|     |Магистральный|     |Магистральный
  |     |маршрутиз. 1 |     |маршрутиз. 2 |     |маршрутиз. 3
  +-----+             +-----+             +-----+
     o                o   o  o              o o
 o o   o  o       o o   o  o  o         o  o  o  o o
o  o o  o o       o   o  o  o  o        o  o  o o o
o   o  o  o          o    o  o           o  o   o
  o   o o               o  o                 o o

    LLN 1              LLN 2                LLN 3

Рисунок 1. Магистральный канал и магистральные маршрутизаторы.

Узлы LLN могут свободно перемещаться из сети LLN, привязанной к одному магистральному маршрутизатору IPv6 BR, в сеть, привязанную к другому BR на той же магистрали, сохраняя все настроенные адреса IPv6. Маршрутизаторы BR поддерживают таблицу привязки (Binding Table) своих зарегистрированных адресов, которая служит распределенной базой данных обо всех узлах LLN. Расширение протокола NDP введено для обмена данными таблиц привязки через магистральный канал (Backbone Link) для обеспечения работы IPv6 Neighbor Discovery.

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

4.3. Буферизация для увеличения срока службы батареи

Разработаны методы, позволяющие продлить срок службы батареи. Например, устройство может не просыпаться при получении точкой доступа (AP) группового пакета. AP действует от имени STA разными способами. Для включения функций экономии энергии в STA в своём наборе BSS точка доступа AP буферизует предназначенные STA кадры до времени, когда STA планирует приём. Если AP, например, выражает сообщение индикации доставки трафика (Delivery Traffic Indication Message или DTIM) 3, AP будет передавать групповой пакет через каждые 3 пакета. Фактически, когда любая отдельная беспроводная станция STA, связанная с AP, имеет включенный режим энергосбережения 802.11, AP буферизует все групповые кадры и передаёт их лишь после следующего сигнала DTIM.

На практике большинство AP будет передавать групповые пакеты каждые 30 секунд. Для индивидуальных пакетов AP может передавать сообщение индикации трафика (Traffic Indication Message или TIM), но для группового трафика AP передаёт широковещательное сообщение всем. DTIM управляет питанием, но STA могут сами решить, нужно ли просыпаться и когда отбрасывать пакет. К сожалению без должной административной настройки такие STA могут быть не способны определить, почему их групповые операции не работают.

4.4. Ограничение глубины аппаратной очереди группового буфера

Очередь CAB (Content after Beacon) служит для передачи буферизованных групповых кадров по сигналу. Если буферизовано много групповых кадров и очередь заполнена, она «заглушает» весь обычный трафик. Для ограничения ущерба, который может нанести буферизованный трафик, некоторые драйверы ограничивают объем групповых данных в очереди до доли beacon_interval. Пример этого приведён в [CAB].

4.5. Поддержка IPv6 в 802.11-2012

IPv6 использует NDP вместо ARP. Каждый узел IPv6 подписан для этого на специальный групповой адрес. Ниже приведён фрагмент текста из параграфа 10.23.13 в [dot11-proxyarp].

При распознавании адреса IPv6 службе Proxy Neighbor Discovery нужно отвечать сообщением Neighbor Advertisement […] от имени связанной станции STA на сообщение [ICMPv6] Neighbor Solicitation […]. При смене сопоставления с MAC-адресом AP может передавать незапрошенные сообщения Neighbor Advertisement от имени STA.

Протокол NDP можно использовать для запроса дополнительных данных с использованием разных методов, включая:

  • Maximum Transmission Unit;

  • Router Solicitation;

  • Router Advertisement.

Сообщения NDP передаются как групповые (широковещательные) кадры 802.11. Использование прокси помогает сохранять сообщения NDP вне беспроводной среды.

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

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

4.6.1. Обзор

Во многих случаях через канал Wi-Fi лучше передавать индивидуальные пакеты вместо групповых. Это избавляет от большинства проблем, связанных с групповой передачей через Wi-Fi, поскольку индивидуальные кадры подтверждаются и буферизуются для клиентов с энергосбережением. При таком подходе иногда приходится один и тот же пакет передавать несколько раз через канал Wi-Fi. Однако во многих случаях, таких как передача видео в домашней сети, это обеспечивает хороший компромисс, поскольку канал Wi-Fi имеет достаточную ёмкость для индивидуального трафика для каждой подписавшейся STA, даже если на восходящем канале в сеть доступа применяется multicast.

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

4.6.2. Преобразование на уровне L2

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

Хотя пока нет стандартизованного метода преобразования, имеется по меньшей мере одна широко распространённая реализация в коде моста Linux [bridge-mc-2-uc]. Разные производители также имеют свои фирменные решения. В общем случае эти реализации выполняют прямое сопоставление для групп и каналов, обнаруженный при отслеживании IGMP и MLD, в соответствующие индивидуальные адреса MAC.

4.6.3. Направленная групповая передача DMS

DMS (Directed Multicast Service) позволяет STA запросить у AP передачу адресованных в группу кадров, предназначенных для запрашивающих STA в виде кадров с индивидуальным адресом (преобразовать в unicast). Ниже указаны некоторые характеристики DMS.

  • Требуются блоки агрегирования данных сервиса 802.11n MAC (Aggregate MAC Service Data Unit или A-MSDU).

  • Кадры с индивидуальными адресами подтверждаются и буферизуются для энергосберегающих STA.

  • Запрашивающая STA может указать характеристики для трафика DMS.

  • Служба DMS определена в IEEE Std 802.11v-2011 [v2011].

  • DMS требует изменений в реализациях AP и STA.

Служба DMS в настоящее время ещё не реализована в продукции. Дополнительная информация доступна в [Tramarin2017] и [Oliva2013].

4.6.4. Автоматическое туннелирование AMT

AMT (Automatic Multicast Tunneling) [RFC7450] обеспечивает возможность туннелирования групповых пакетов IP в индивидуальных пакетах через сеть, поддерживающую лишь unicast-передачу. Когда операционная система или приложение на станции STA имеет встроенный шлюз AMT, она может использовать индивидуальную адресацию для передачи по каналу Wi-Fi, развернув ретранслятор AMT в не относящейся к Wi-Fi части сети, соединённой с AP.

Рекомендуется в сетях с поддержкой групповой передачи, где развёрнуты ретрансляторы AMT, обеспечивать локальное обнаружение этих ретрансляторов с использованием описанных в [RFC8777] методов:

  • обнаружение служб на основе DNS (DNS-SD) [RFC6763];

  • общеизвестные адреса IP из раздела 7 в [RFC7450].

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

4.7. GroupCast с повторами (GCR)

Механизм GCR (GroupCast with Retries, [dot11aa]) повышает надёжность за счёт использования незапрошенных повторов или механизма подтверждения блока. GCR повышает вероятность получения групповых кадров, но все же не обеспечивает гарантии.

Для механизма подтверждения блоков AP использует для каждого адресованного в группу кадра обычную групповую передачу. Повторные передачи адресуются в группу, но скрыты от STA, не поддерживающих 802.11aa. Применяется схема направленного подтверждения блоков для сбора статуса приёма от получателей и на основе этого выполняется повтор передачи.

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

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

  • индивидуальная передача запроса подтверждения блока (Block Ack Request или BAR) части группы;

  • ожидание соответствующего подтверждения блока (Block Ack или BA);

  • повтор пропущенных кадров;

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

Такая задержка может быть неприемлема для некоторых типов трафика.

В 802.11 разрабатываются расширения для повышения производительности GCR:

  • запросы BAR передаются с использованием нисходящего многопользовательского MIMO (MU-MIMO);

  • отклики BA передаются с использованием восходящего MU-MIMO (свойство IEEE 801.11ax-2021);

  • задержка может быть дополнительно снижена одновременным получением данных BA от нескольких STA.

5. Эксплуатационная оптимизация

В этом разделе описаны некоторые варианты эксплуатационной оптимизации, которые могут быть реализованы при развёртывании беспроводных сетей IEEE 802 для смягчения проблем, описанных в разделе 3.

5.1. Устранение проблем ложного обнаружения соседей

ARP Sponge

ARP Sponge размещаются в сети и узнают реально применяемые адреса IP. Они также прослушивают запросы ARP и, видя ARP для адреса IP, который по их мнению не используется, будут передавать в ответ свой MAC-адрес. Это значит, что маршрутизатор будет иметь сопоставление IP-MAC, которое он кэширует. Если позднее этот адрес IP будет выделен машине (например, через DHCP), ARP Sponge увидит это и прекратит отвечать для него. Беспричинные (Gratuitous) ARP (или ARP от машин к их шлюзам) будут заменять подменный адрес (sponged) в ARP-таблице маршрутизатора. Этот метод достаточно эффективен, но к сожалению демоны ARP Sponge не были предназначены для такого применения — один из наиболее распространённых ARP Sponge [arpsponge] был разработан для борьбы с исчезновением участников обмена в IXP (Internet Exchange Point) и тоже не оптимизирован для такой задачи. Для каждой подсети нужен один демон, настройка сложна (скорость сканирования, плотность заполнения, число повторов и т. п.), а иногда демон просто останавливается, что требует перезапуска, вызывающего нарушения работы.

Маршрутизаторы

Некоторые маршрутизаторы (часто на основе Linux) реализуют демон негативного кэширования ARP. Если маршрутизатор не видит откликов на ARP, можно задать сохранение этой информации в течение некоторого времени. К сожалению, часто используемые в ядре маршрутизаторы не поддерживают этого. Вместо этого при получении адреса IP подключившимся к сети хостом он передаёт запрос ARP для принятого по умолчанию шлюза (маршрутизатора). Маршрутизатор обновляет свой кэш, включая в него сопоставление IP с MAC-адресом хоста из запроса (пассивное обучение ARP).

Фильтрация неиспользуемых адресов

Распределение пользователей в беспроводных (под)сетях может меняться в различных вариантах применения, таких как конференции (например, переименовываются SSID (Service Set Identifier), некоторые SSID становятся непопулярными и т. п.). Это осложняет прогнозирование использования конкретных SSID, но его можно отслеживать по мере использования сетей. Настройка нескольких пулов DHCP в подсети и их последующее включение позволяет создавать большую подсеть, в которой используются лишь младшие части адресов. Это позволяет применять входные списки доступа по IP, блокирующие старшие адреса, которые не используются. Маршрутизатор не пытается пересылать пакеты в старшие части пространств адресов и не использует для них ARP. Этот метод показал свою эффективность, но он достаточно трудоёмкий и требует координации.

Запрет и фильтрация запросов ARP

В общем случае маршрутизатору не нужны запросы ARP для хостов, он может получить сопоставление IP-MAC из переданного хостом при подключении запроса ARP. Поэтому следует обеспечивать возможность запрета и/или фильтрации запросов ARP от маршрутизатора. К сожалению ARP является фундаментальной и низкоуровневой частью стека IP и зачастую выгружается из обычной плоскости управления. Хотя многие маршрутизаторы могут фильтровать трафик на уровне L2, обычно это реализовано в форме входного фильтра, а возможности выходной фильтрации широковещательного трафика ограничены. Это означает, что кажущееся очевидным решение просто отключить или фильтровать ARP на выходе на практике сложно выполнить или оно ограничено реализацией или архитектурой.

Трансляция NAT

Широковещательная передача часто может вызываться сканированием или обратным рассеянием извне Wi-Fi. Для снижения влияния широковещания можно применять трансляцию NAT для всей (или большей части) сети. Для неиспользуемых адресов в NAT не будет записей и маршрутизатор не будет применять ARP для них. Однако имеется много причин отказываться от применения NAT в таком режиме.

Межсетевые экраны с учётом состояния

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

5.2. Устранение ложных сообщений обнаружения служб

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

6. Групповая передача в других беспроводных средах

Многие из описанных выше случаев потери производительности наблюдались и в беспроводных сетях, отличных от 802.11. Например, проблемы с энергосбережением, избыточной загрузкой среды и малой надёжностью проявляются также в сетях 802.15.3 и 802.15.4. К сожалению спецификация среды 802.15 пока не включает механизмов, подобных разработанным для 802.11. Фактически проектирование 802.15 нацелено на минимизацию и многие функции реализуются в протоколах вышележащих уровней. Это ведёт к мешанине несовместимых и фирменных решений. В [uli] подробно рассматриваются проблемы и представлены предложения для группы задач, решающие проблемы, где объем групповых передач можно снизить.

Похожие соображения применимы и к другим беспроводным средам. В работе [RFC5757] приведено краткое рассмотрение для сред 802.16 WiMAX, 3GPP/3GPP2, DVB-H/DVB-IPDC, а также широковещательного и спутникового телевидения.

7. Рекомендации

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

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

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

8. Вопросы для обсуждения

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

Во-первых, органам стандартизации (включая частные) следует создавать рекомендации, помогающие прояснить, когда лучше передавать групповые пакеты через кабельную, а не беспроводную сеть. Например, 802.1ak [IEEE802.1ak] работает с Ethernet и Wi-Fi, поэтому организации могут помочь в принятии решений о развёртывании, разработав рекомендации для групповой передачи через Wi-Fi, включая варианты передачи трафика по кабелям.

Во-вторых, надёжная регистрация в multicast-группах L2 и надёжные групповые операции L2 могут обеспечить хорошее решение для Wi-Fi. Не следует требовать поддержки 224 для групповой работы, достаточно просто выбрать число битов, имеющих смысл для данного размера сети, чтобы ограничить число нежелательных передач разумным уровнем. Рабочие группы IEEE 802.1, 802.11, 802.15 следует поощрять к пересмотру групповой передачи L2 и разработке работоспособных решений.

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

Этот документ не добавляет и не меняет механизмов защиты. Групповую передачу в кабельных и беспроводных сетях, рассматриваемую здесь, можно защитить разными способами. Например, в [RFC4601], описано применение IPsec для проверки подлинности сообщений на локальном канале (link-local) при независимой от протокола групповой маршрутизации (Protocol Independent Multicast — Sparse Mode или PIM-SM). В [RFC5796] заданы механизмы проверки подлинности локальных сообщений PIM-SM link-local с использованием IPsec ESP (Encapsulating Security Payload) или AH (Authentication Header).

При использовании механизмов преобразования группового трафика в индивидуальный для передачи по радиоканалам точка доступа AP (или иной объект) вынуждена явно отслеживать абонентов, заинтересованных в определённом групповом трафике. Обычно такой компромисс разумен, но но это ведёт к тому, что другой объект отслеживает подписчиков группового трафика. Хотя такая информация при необходимости где-то уже отслеживается, это расширяет фронт атак, при которых возможна утечка возможно конфиденциальных сведений.

Как отмечено в [group_key], ненадёжная по природе групповая передача через беспроводную среду может вызывать небольшие проблемы для управления и обновления групповых ключей. В [group_key] сказано, что при использовании шифрования TKIP (WPA сейчас не рекомендуется) или AES-CCMP (WPA2/WPA3) групповые пакеты от AP к клиентам (FromDS) должны шифроваться с использованием отдельного ключа, известного всем клиентам (Group Key). Далее там же сказано «… большинство клиентов могут подключаться и просматривать web0страницы, проверять почту и т. п., даже когда групповая передача FromDS не работает. Поэтому многие не осознают наличие проблем с групповой передачей в их сети …».

Этот документ рекомендует применять прокси-методы для экономии пропускной способности сети и снижения расхода батарей в устройствах с энергосбережением. С такими методами обычно связаны вопросы безопасности, требующие иметь доверенные прокси во избежание недопустимого поведения. Одним из таких методов является ARP Sponge, где прослушиваются запросы ARP и при наблюдении ARP для адреса IP, который считается неиспользуемым, прокси возвращает свой MAC-адрес. Отравление ARP (poisoning) и фальшивые анонсы могут нарушить (например, DoS) работу этого и других прокси-методов.

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

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

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

[arpsponge] Wessel, M. and N. Sijm, «Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge», July 2009, <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692>.

[bridge-mc-2-uc] «bridge: multicast to unicast», commit 6db6f0e, January 2017, <https://github.com/torvalds/linux/commit/6db6f0e>.

[CAB] «limit multicast buffer hardware queue depth», commit 2687951, June 2013, <https://patchwork.kernel.org/patch/2687951/>.

[Deri-2010] Deri, L. and J. Gasparakis, «10 Gbit Hardware Packet Filtering Using Commodity Network Adapters», RIPE 61, November 2010, <http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf>.

[dot11] IEEE, «Information Technology—Telecommunications and Information Exchange between Systems — Local and Metropolitan Area Networks—Specific Requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (includes 802.11v amendment)», DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020, December 2020, <https://standards.ieee.org/standard/802_11-2020.html>.

[dot11-proxyarp] Hiertz, G., Mestanov, F., and B. Hart, «Proxy ARP in 802.11ax», September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.

[dot11aa] IEEE, «Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming», DOI 10.1109/IEEESTD.2012.6204193, IEEE Std 802.11aa-2012, March 2012, <https://standards.ieee.org/standard/802_11aa-2012.html>.

[group_key] «Subject: Why do some WiFi routers block multicast packets going from wired to wireless?», message to the Super User Q & A community, January 2017, <https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless>.

[IEEE802.1ak] IEEE, «Local and Metropolitan Area Networks Virtual Bridged Local Area Networks — Amendment 07: Multiple Registration Protocol», DOI 10.1109/IEEESTD.2007.380667, IEEE Std 802.1ak-2007, June 2007, <https://www.ieee802.org/1/pages/802.1ak.html>.

[ietf_802-11] Stanley, D., «IEEE 802.11 multicast capabilities», November 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt>.

[mc-prob-stmt] Abrahamsson, M. and A. Stephens, «Multicast on 802.11», 2013, <https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx>.

[mc-props] Stephens, A., «IEEE 802.11 multicast properties», September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt>.

[Oliva2013] de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, «Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming», 2013 IEEE 14th International Symposium on «A World of Wireless, Mobile and Multimedia Networks» (WoWMoM), pp. 1-9, DOI 10.1109/WoWMoM.2013.6583394, June 2013, <https://doi.org/10.1109/WoWMoM.2013.6583394>.

[RFC0826] Plummer, D., «An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC4286] Haberman, B. and J. Martin, «Multicast Router Discovery», RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, «Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches», RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, «Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised)», RFC 4601, DOI 10.17487/RFC4601, August 2006, <https://www.rfc-editor.org/info/rfc4601>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, «Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey», RFC 5757, DOI 10.17487/RFC5757, February 2010, <https://www.rfc-editor.org/info/rfc5757>.

[RFC5796] Atwood, W., Islam, S., and M. Siami, «Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages», RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.

[RFC6282] Hui, J., Ed. and P. Thubert, «Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks», RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.

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

[RFC6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, «Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)», RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.

[RFC6970] Boucadair, M., Penno, R., and D. Wing, «Universal Plug and Play (UPnP) Internet Gateway Device — Port Control Protocol Interworking Function (IGD-PCP IWF)», RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.

[RFC7450] Bumgardner, G., «Automatic Multicast Tunneling», RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.

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

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

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, «Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery», RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.

[RFC8777] Holland, J., «DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery», RFC 8777, DOI 10.17487/RFC8777, April 2020, <https://www.rfc-editor.org/info/rfc8777>.

[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, «IPv6 Backbone Router», RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.

[RFC9030] Thubert, P., Ed., «An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)», RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.

[Tramarin2017] Tramarin, F., Vitturi, S., and M. Luvisotto, «IEEE 802.11n for Distributed Measurement Systems», 2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC), pp. 1-6, May 2017.

[uli] Kinney, P., «LLC Proposal for 802.15.4», September 2015, <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>.

[v2011] IEEE, «Information technology — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network Management», DOI 10.1109/IEEESTD.2011.5716530, IEEE Std 802.11v-2011, February 2011, <https://ieeexplore.ieee.org/document/5716530>.

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

Этот документ выиграл в результате обсуждения с перечисленными в алфавитном порядке людьми: Mikael Abrahamsson, Bill Atwood, Stuart Cheshire, Donald Eastlake 3rd, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Thubert, Jeffrey (Zhaohui) Zhang.

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

Charles E. Perkins
Lupin Lodge
Phone: +1 408 255 9223
Email: charliep@lupinlodge.com
 
Mike McBride
Futurewei Technologies Inc.
2330 Central Expressway
Santa Clara, CA 95055
United States of America
Email: michael.mcbride@futurewei.com
 
Dorothy Stanley
Hewlett Packard Enterprise
6280 America Center Dr.
San Jose, CA 95002
United States of America
Phone: +1 630 363 1389
Email: dorothy.stanley@hpe.com
 
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
 
Juan Carlos Zúñiga
SIGFOX
Montreal
Canada
Email: j.c.zuniga@ieee.org

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

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

nmalykh@protokols.ru

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

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

3Нажмите для разговора.

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

RFC 9108 YANG Types for DNS Classes and Resource Record Types

Internet Engineering Task Force (IETF)                         L. Lhotka
Request for Comments: 9108                                        CZ.NIC
Category: Standards Track                                      P. Špaček
ISSN: 2070-1721                              Internet Systems Consortium
                                                          September 2021

YANG Types for DNS Classes and Resource Record Types

Типы YANG для классов DNS и типов RR

PDF

Аннотация

Этот документ вводит модуль YANG iana-dns-class-rr-type, содержащий производные типы данных, отражающие реестры IANA DNS CLASSes и Resource Record (RR) TYPEs. Эти типы YANG служат начальной основой для будущей работы по моделированию данных.

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

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

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

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

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

Авторские права (Copyright (c) 2021) принадлежат 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 [RFC7950] стал фактическим стандартом моделирования данных конфигурации и состояния, а также задания управляющих операций и асинхронных уведомлений. Разумно ожидать, что основанный на таких моделях данных подход вместе со стандартными протоколами управления, такими как NETCONF [RFC6241] и RESTCONF [RFC8040], можно будет эффективно применять и в операциях DNS. Фактически в настоящее время уже предпринимаются попытки использовать NETCONF и RESTCONF для настройки и управления:

  • полномочными серверами;

  • распознавателями;

  • данными зон.

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

На основе опыта IETF Routing Area можно ожидать, что разработка унифицированных моделей данных для DNS окажется сложной и длительной и потребует активного сотрудничества и компромиссов между разработчиками и поставщиками основных серверных платформ DNS. Тем не менее, вполне вероятно, что любое моделирование относящихся к DNS данных потребует использования различных параметров и перечней DNS, заданных в нескольких реестрах IANA. Для использования с YANG эти параметры и перечни нужно перевести в соответствующие типы YANG или иные структуры. Такой трансляции следует быть простой и сравнительно бесспорной.

Этот документ обеспечивает трансляцию двух связанных с DNS фундаментальных реестров IANA в YANG. Документ содержит первоначальную версию модуля YANG iana-dns-class-rr-type, которая определяет производные типы для общих параметров записей DNS о ресурсах (RR) — класс и тип. Типы YANG dns-class и rr-type, отражают реестры IANA DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS].

В Приложении A приведена таблица стилей XSLT 1.0, предназначенная для использования IANA при генерации исходной версии модуля iana-dns-class-rr-type. Впоследствии при добавлении нового класса или типа RR в упомянутые реестры IANA будет также обновлять модуль iana-dns-class-rr-type, следуя инструкциям раздела 4.

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

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

Терминология для описания моделей данных YANG приведена в [RFC7950]. Используемые в документе термины DNS определены в [RFC1035] и [RFC8499].

3. Вопросы проектирования YANG

Во время написания этого документа реестр «Domain Name System (DNS) Parameters» [IANA-DNS-PARAMETERS] включал 13 субреестров. Модуль YANG iana-dns-class-rr-type определяет производные типы, соответствующие лишь 2 реестрам, которые важны для моделей данных, включающих данные зоны, а именно «DNS CLASSes» и «Resource Record (RR) TYPEs». Предполагается, что оставшиеся реестры [IANA-DNS-PARAMETERS], а также другие реестры IANA, связанные с DNS, по мере необходимости будут отражаться в последующих модулях YANG. Таким образом, можно будет выбрать подходящую комбинацию модулей YANG в зависимости от требуемых типов YANG и целей моделирования.

Реестры «DNS CLASSes» и «Resource Record (RR) TYPEs» преобразованы в перечисляемые типы YANG dns-class-name и rr-type-name, соответственно. Ниже приведён начальный фрагмент первого из них.

     typedef dns-class-name {
       type enumeration {
         enum IN {
           value 1;
           description
             "Internet (IN)";
           reference
             "RFC 1035";
         }
         ...
       }
       ...
     }

Другой производный тип rr-type-name определён аналогичным способом.

В [RFC3597] введена опция для указания класса или типа RR присвоенным ему десятичным номером вместо мнемонического имени. Например, класс IN можно указать как CLASS1, а тип AAAA — как TYPE28. В соответствии с этим производные типы dns-class и rr-type определены в модуле YANG как объединение двух типов:

  • 16-битовое десятичное значение (uint16);

  • мнемоническое имя, относящееся к перечисляемым типам dns-class-name и rr-type-name.

Например, тип rr-type определён как

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description
         "Этот тип позволяет указывать тип записи о ресурсе DNS
          с использованием мнемонического имени или числа.";
     }

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

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

В этом разделе рассматриваются действия и процессы IANA, требуемые для поддержки модуля YANG iana-dns-class-rr-type, предназначенного для отображения реестров DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS]. Свежая версия модуля YANG доступна в реестре YANG Parameters [IANA-YANG-PARAMETERS].

С публикацией этого документа агентство IANA создало и разместило начальную версию модуля iana-dns-class-rr-type путём применения таблицы стилей XSLT из Приложения A к XML-версии [IANA-DNS-PARAMETERS].

Ниже приведено примечание, добавленное IANA к записи iana-dns-class-rr-type в реестре YANG Module Names [IANA-YANG-PARAMETERS].

Классы и типы записей о ресурсах DNS недопустимо добавлять напрямую в модуль YANG iana-dns-class-rr-type, они должны добавляться в реестры DNS CLASSes и Resource Record (RR) TYPEs, соответственно.

При добавлении класса DNS или типа RR в реестр DNS CLASSes или Resource Record (RR) TYPEs нужно добавлять оператор enum к типу dns-class-name или rr-type-name, соответственно. Имени в enum нужно совпадать с мнемоническим именем нового класса или типа. В оператор enum нужно включить указанные ниже субоператоры.

value

Десятичное значение из реестра.

status

Включается лишь для классов или типов, регистрация которых отменена или устарела. Значениям deprecated и obsolete в реестре соответствуют такие же значения в модуле YANG.

description

Копия соответствующих сведений из реестра, а именно полное имя нового класса DNS или значение нового типа RR, если оно имеется.

reference

Копия ссылок из реестра.

Невыделенные и резервные значение не нужно включать в перечисляемые типы dns-class-name и rr-type-name.

При каждом обновлении модуля YANG iana-dns-class-rr-type нужно добавлять новый оператор revision перед имеющимися операторами revision.

Ниже приведено примечание, добавленное IANA в реестры DNS CLASSes и Resource Record (RR) TYPEs.

При изменении реестра должен обновляться модуль YANG iana-dns-class-rr-type, как указано в [RFC9108].

Ниже приведено обновление текста Reference в реестре DNS CLASSes.

Старый текст

[RFC6895]

Новый текст

[RFC6895][RFC9108]

Ниже приведено обновление текста Reference в реестре Resource Record (RR) TYPEs.

Старый текст

[RFC6895][RFC1035]

Новый текст

[RFC6895][RFC1035][RFC9108]

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

Этот документ регистрирует URI в реестре IETF XML [RFC3688], добавляя в него приведённые ниже записи.

   URI:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace3.

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

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020], добавляя в него приведённые ниже записи.

   Name:  iana-dns-class-rr-type
   Namespace:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Prefix:  dnsct
   Reference:  RFC 9108

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

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

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

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

[IANA-DNS-PARAMETERS] IANA, «Domain Name System (DNS) Parameters», <https://www.iana.org/assignments/dns-parameters>.

[IANA-YANG-PARAMETERS] IANA, «YANG Parameters», <https://www.iana.org/assignments/yang-parameters>.

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

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

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

[W3C.REC-xslt-19991116] Clark, J., «XSL Transformations (XSLT) Version 1.0», W3C Recommendation REC-xslt-19991116, November 1999, <https://www.w3.org/TR/1999/REC-xslt-19991116>.

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

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

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.

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

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

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

Приложение A. Таблица стилей XSLT

В этом приложении содержится таблица стилей XSLT 1.0 [W3C.REC-xslt-19991116], использованная для создания исходной версии модуля YANG iana-dns-class-rr-type. Это было выполнено путём применения таблицы стилей к XML-версии реестра IANA Domain Name System (DNS) Parameters [IANA-DNS-PARAMETERS] на момент публикации этого документа.

С помощью программы xsltproc текст модуля YANG можно создать командой

       $ xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml

   <CODE BEGINS> file "iana-dns-class-rr-type.xsl"
   <?xml version="1.0" standalone="yes"?>
   <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
               xmlns:iana="http://www.iana.org/assignments"
               version="1.0">
     <output method="text"/>
     <strip-space elements="*"/>

     <variable name="dq">"</variable>
     <variable name="sq">'</variable>

     <variable name="module-intro">
       <text>module iana-dns-class-rr-type {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type";
     prefix dnsct;

     organization
       "Internet Assigned Numbers Authority (IANA)";

     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                12025 Waterfront Drive, Suite 300
                Los Angeles, CA 90094

        Tel:    +1 424 254 5300

        &lt;mailto:iana@iana.org&gt;";

     description4
       "This YANG module translates IANA registries 'DNS CLASSes' and
        'Resource Record (RR) TYPEs' to YANG-derived types.

        Copyright (c) 2021 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module was generated from
        the corresponding IANA registries using an XSLT stylesheet
        from Appendix A of RFC 9108
        (https://www.rfc-editor.org/info/rfc9108); see the RFC itself
        for full legal notices.";

     reference
       "IANA 'Domain Name System (DNS) Parameters' registry
        https://www.iana.org/assignments/dns-parameters";</text>
        <text>&#xA;&#xA;</text>
     </variable>

     <template name="enum">
       <param name="id"/>
       <value-of select="concat('      enum ', $id)"/>
       <text> {&#xA;        value </text>
       <value-of select="concat(iana:value, ';&#xA;')"/>
       <if test="contains(iana:description, 'OBSOLETE')">
         <text>        status obsolete;&#xA;</text>
       </if>
       <apply-templates select="iana:description"/>
       <variable name="xrefs" select="iana:xref[@type!='note']"/>
       <if test="$xrefs">
         <text>        reference&#xA;          "</text>
         <if test="count($xrefs)&gt;1">- </if>
         <apply-templates select="iana:xref[@type!='note']"/>
       </if>
       <text>      }&#xA;</text>
     </template>

     <template match="/">
       <value-of select="$module-intro"/>
       <apply-templates select="iana:registry[@id='dns-parameters']"/>
       <text>}&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters']">
       <apply-templates select="iana:updated"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-2']"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-4']"/>
     </template>

     <template match="iana:updated">
       <value-of select="concat('  revision ', ., ' {')"/>
       <text>
       description
         "Initial revision.";
       reference
         "RFC 9108: YANG Types for DNS Classes and Resource Record
          Types";
     }

     /* Typedefs */&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-2']">
       <text>  typedef dns-class-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[not(iana:description='Unassigned' or
                   starts-with(iana:description,'Reserved'))]"
           mode="class"/>
       <text>    }
       description5
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS classes.";
       reference
         "RFC 6895: Domain Name System (DNS) IANA Considerations";
     }

     typedef dns-class {
       type union {
         type uint16;
         type dns-class-name;
       }
       description6
         "This type allows reference to a DNS class using either the
          assigned mnemonic name or numeric value.";
     }&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-4']">
       <text>  typedef rr-type-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[iana:type!='Unassigned' and
                   iana:type!='Private use' and iana:type!='Reserved']"
           mode="rr-type"/>
       <text>    }
       description7
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS resource record types.";
       reference
         "- RFC 6895: Domain Name System (DNS) IANA Considerations

          - RFC 1035: Domain names - implementation and specification";
     }

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description8
         "This type allows reference to a DNS resource record type
          using either the assigned mnemonic name or numeric value.";
     }&#xA;</text>
     </template>

     <template match="iana:record" mode="class">
       <call-template name="enum">
         <with-param name="id">
           <choose>
             <when test="contains(iana:description,'(')">
               <value-of select="substring-before(substring-after(
                                 iana:description, '('), ')')"/>
             </when>
             <otherwise>
               <value-of
                   select="substring-after(iana:description, ' ')"/>
             </otherwise>
           </choose>
         </with-param>
       </call-template>
     </template>

     <template match="iana:record" mode="rr-type">
       <call-template name="enum">
         <with-param name="id" select="iana:type"/>
       </call-template>
     </template>

     <template match="iana:description">
       <text>        description&#xA;          </text>
       <value-of select="concat($dq, ., $dq, ';&#xA;')"/>
     </template>

     <template match="iana:xref">
       <choose>
         <when test="@type='rfc'">
           <value-of
               select="concat('RFC ', substring-after(@data, 'rfc'))"/>
         </when>
         <when test="@type='person'">
           <apply-templates
               select="/iana:registry/iana:people/iana:person[
                       @id=current()/@data]"/>
         </when>
         <when test="@type='text'">
           <value-of select="translate(., $dq, $sq)"/>
         </when>
         <otherwise>
           <value-of select="@data"/>
         </otherwise>
       </choose>
       <choose>
         <when test="position()=last()">
           <text>";&#xA;</text>
         </when>
         <otherwise>
           <text>&#xA;           - </text>
         </otherwise>
       </choose>
     </template>

     <template match="iana:person">
       <value-of select="concat(iana:name, ' &lt;', iana:uri, '&gt;')"/>
     </template>

   </stylesheet>
   <CODE ENDS>

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

Ladislav Lhotka

CZ.NIC

Czech Republic

Email: ladislav.lhotka@nic.cz

Petr Špaček

Internet Systems Consortium

Czech Republic

Email: pspacek@isc.org


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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Не задано. Запрошенный идентификатор URI является пространством имён XML.

4Этот модуль YANG транслирует реестры IANA «DNS CLASSes» и «Resource Record (RR) TYPEs» в типы YANG.

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

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

Эта версия модуля YANG создана из соответствующих реестров IANA с использованием таблицы стилей XSLT из Приложения A к RFC 9108 (https://www.rfc-editor.org/info/rfc9108). Полная юридическая информация приведена в самом RFC.

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

6Этот тип позволяет указывать классы DNS мнемоническим именем или числом.

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

8Этот тип позволяет указывать записи о ресурсах DNS мнемоническим именем или числом.

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

RFC 9106 Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications

Internet Research Task Force (IRTF)                          A. Biryukov
Request for Comments: 9106                                       D. Dinu
Category: Informational                         University of Luxembourg
ISSN: 2070-1721                                          D. Khovratovich
                                                         ABDK Consulting
                                                            S. Josefsson
                                                                  SJD AB
                                                          September 2021

Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications

Функция Argon2 для хэширования паролей и приложений Proof-of-Work

PDF

Аннотация

Этот документ определяет функцию Argon2 с интенсивным использованием памяти для хэширования паролей и приложений подтверждения работы (proof-of-work). Дано ориентированное на разработчиков описание с тестовыми векторами. Цель заключается в упрощении адаптации Argon2 для протоколов Internet. Документ является результатом работы исследовательской группы Crypto Forum (Crypto Forum Research Group или CFRG) в составе IRTF.

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

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

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

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

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

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

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

1. Введение

Этот документ определяет функцию Argon2 с интенсивным использованием памяти для хэширования паролей и приложений подтверждения работы (proof-of-work). Дано ориентированное на разработчиков описание с тестовыми векторами. Цель заключается в упрощении адаптации Argon2 для протоколов Internet. Документ воответствует хэш-функции Argon2 версии 1.3.

Argon2 — функция с интенсивным использованием памяти [HARD]. Это оптимизированная конструкция, нацеленная на максимальную скорость заполнения памяти и эффективное использование множества расчётных блоков с обеспечением устойчивости к компромиссным (trade-off) атакам. Функция Argon2 оптимизирована для архитектуры x86 и использует организацию кэше и памяти в последних моделях процессоров Intel и AMD. Argon2 имеет 1 основной вариант Argon2id и два дополнительных (Argon2d и Argon2i). В Argon2d применяется зависимый от данных доступ к памяти, что подходит для криптовалют и приложений proof-of-work без угроз атак через побочные каналы. В Argon2i применяется независимый от данных доступ к памяти, который предпочтителен для хэширования паролей и вывода ключей на основе пароля. Argon2id работает как Argon2i для первой половины первого прохода по памяти и как Argon2d в остальное время, что обеспечивает защиту от атак по побочным каналам и экономию при переборе (brute-force) за счёт компромисса между временем и расходом памяти. В Argon2i применяется больше проходов по памяти для защиты от компромиссных атак [AB15].

Функция Argon2id должна поддерживаться всеми реализациями этого документа могут поддерживаться также Argon2d и Argon2i.

Argon2 — это также режим работы на основе функции сжатия с фиксированным размером ввода (G) и функции хэширования с переменным входным размером (H). Хотя Argon2 можно использовать с произвольной функцией H, которая обеспечивает вывод вплоть до 64 байтов, в документе применяется функций BLAKE2b [BLAKE2].

Дополнительные сведения и обсуждение представлены в статье по Argon2 [ARGON2].

Этот документ представляет согласованный подход исследовательской группы Crypto Forum (CFRG).

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

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

2. Обозначения и соглашения

x^y

Умножение целого числа x самого на себя y раз (возведение в степень).

a*b

Произведение целых чисел a и b.

c-d

Вычитание целого числа d из целого числа c.

E_f

Переменная E с подстрочным индексом f.

g / h

Деление целого числа g на целое число h (результат является рациональным числом).

I(j)

Значение функции I для аргумента j.

K || L

Объединение (конкатенация) строки K со строкой L.

a XOR b

Побитовая рперация исключительное-ИЛИ для битовых строк a и b.

a mod b

Деление целого числа a по модулю b (результат всегда относится к диапазону [0, b-1]).

a >>> n

Сдвиг 64-битовой строки a на n битов вправо.

trunc(a)

64-битовое значение усечённое до 32 младших битов.

floor(a)

Наибольшее целое число, не превышающее a

ceil(a)

Наименьшее целое число, которое не меньше a

extract(a, i)

i-ый набор из 32 битов битовой строки a, начиная с позиции 0.

|A|

Число элементов множества A.

LE32(a)

32-битовое целое число, преобразованное в строку байтов little endian (например, десятичное число 123456 будет иметь вид 40 E2 01 00).

LE64(a)

64-битовое целое число, преобразованное в строку байтов little endian (например, десятичное число 123456 будет иметь вид 40 E2 01 00 00 00 00 00).

int32(s)

32-битовая строка s, преобразованная в неотрицательное целое число в формате little endian.

int64(s)

64-битовая строка s, преобразованная в неотрицательное целое число в формате little endian.

length(P)

Количество байтов строки P в виде 32-битового целого числа.

ZERO(P)

Строка из P нулевых байтов.

3. Алгоритм Argon2

3.1. Входные и выходные данные Argon2

Ниже перечислены входные параметры Argon2.

  • Строка сообщения P, являющаяся паролем для приложений хэширования паролей. Размер строки должен быть не более 2^(32)-1 байтов.

  • Обноразовое значение S, служащее затравкой для приложений хэширования паролей. Размер затравки должен быть не более 2^(32)-1 байтов. Для хэштрования паролей рекомендуется размер 16 байтов. Затравку следует делать уникальной для каждого пароля.

  • Степень распараллеливания p, определяющая число независимых (но синхронизированных) цепочек расчётов (lane), которые могут быть запущены. Это должно быть целое число из диапазона 1 — 2^(24)-1.

  • Размер тега T должен быть целым числом байтов от 4 до 2^(32)-1.

  • Размер памяти (в килобайтах) должен быть целым числом от 8*p до 2^(32)-1. Фактическое число блоков m’ является округлением вниз до ближайшего значения, кратного 4*p.

  • Число проходов t (служит для настройки времени работы независимо от объёма памяти), которое должно быть целым числом из диапазона 1 — 2^(32)-1.

  • Номер версии v должен быть 1 байтом со значением 0x13.

  • Необязательное значение секрета K, которое (при наличии) должно иметь размер не более 2^(32)-1 байтов.

  • Необязательные связанные данные X, размер которых (при наличии) должен быть не более 2^(32)-1 байтов.

  • Тип y должен иметь значение 0 для Argon2d, 1 для Argon2i, 2 для Argon2id.

Выходные данные Argon2 или тег — это строка размером T байтов.

3.2. Работа Argon2

Argon2 использует внутреннюю функцию сжатия G с двумя входными параметрами по 1024 байта, результатом в 1024 байта и внутренней хэш-функцией H^x(), где x — выходной размер в байтах. Функция H^x(), примененная в строке A — это функция BLAKE2b ([BLAKE2], параграф 3.3), которая принимает параметры (d,ll,kk=0,nn=x), где d — это A с заполнением до размера, кратного 128 байтам, а ll — размер d в байтах. Функция сжатия G основана на внутренней перестановке. Применяется также хэш-функция H’ с переменным размером, основанная на H. Описание G дано в параграфе 3.5, H’ — в параграфе 3.3. Работа функции Argon2 описана ниже.

  1. Создаётся 64-байтовое значение H_0, как показано ниже. Если K, X или S имеет нулевой размер, они просто не включаются, но поле размера остаётся.

  2.        H_0 = H^(64)(LE32(p) || LE32(T) || LE32(m) || LE32(t) ||
                   LE32(v) || LE32(y) || LE32(length(P)) || P ||
                   LE32(length(S)) || S ||  LE32(length(K)) || K ||
                   LE32(length(X)) || X)

    Рисунок . Генерация H_0.


    Выделяется память как m’ блоков по 1024 байта, где m’ определяется приведённым ниже выражением.

           m' = 4 * p * floor (m / 4p)

    Рисунок . Выделение памяти.


    Для p цепочек память организуется в форме матрицы B[i][j] блоков с p строк (цепочек) и q = m’ / p столбцов.

  3. Рассчитывается B[i][0] для всех i от 0 до p-1.

  4.        B[i][0] = H'^(1024)(H_0 || LE32(0) || LE32(i))

    Рисунок . Первые блоки прохода.


    Рассчитывается B[i][1] для всех i от 0 до p-1.

  5.        B[i][1] = H'^(1024)(H_0 || LE32(1) || LE32(i))

    Рисунок . Вторые блоки прохода.


    Рассчитывается B[i][j] для всех i от 0 до p-1 и всех j от 2 до q-1. Расчёты должны выполняться по срезам (slicewise, параграф 3.4) — сначала для всех цепочек среза 0 (с произвольным порядком цепочек), затем для среза 1 и т. д. Индексы блоков l и z определяются для каждой пары i, j по-разному в Argon2d, Argon2i, Argon2id.

  6.        B[i][j] = G(B[i][j-1], B[l][z])

    Рисунок . Генерация последующих блоков.


    Если число проходов больше 1, п. 5 повторяется. Рассчитываются B[i][0] и B[i][j] для всех i от 0 до p-1 и всех j от 1 до q-1. Однако блоки рассчитываются по-разному, поскольку старое значение комбинируется с новым (XOR), как показано ниже.

  7.        B[i][0] = G(B[i][q-1], B[l][z]) XOR B[i][0];
           B[i][j] = G(B[i][j-1], B[l][z]) XOR B[i][j].

    Рисунок . Последующие проходы.


    После t итераций рассчитывается финальный блок C как XOR для последнего столбца

  8.        C = B[0][q-1] XOR B[1][q-1] XOR ... XOR B[p-1][q-1]

    Рисунок . Финальный блок.


    Результирующий тег рассчитывается как H’^T(C).

3.3. Хэш функция с переменным размером H’

Пусть V_i — 64-байтовый блок, а W_i — его первые 32 байта. Тогда функция H’ определяется, как показано ниже.

           if T <= 64
               H'^T(A) = H^T(LE32(T)||A)
           else
               r = ceil(T/32)-2
               V_1 = H^(64)(LE32(T)||A)
               V_2 = H^(64)(V_1)
               ...
               V_r = H^(64)(V_{r-1})
               V_{r+1} = H^(T-32*r)(V_{r})
               H'^T(X) = W_1 || W_2 || ... || W_r || V_{r+1}

Рисунок . Функция H’ для расчёта тега и начального блока.


3.4. Индексирование

Для параллельного расчёта блока матрица памяти разбита на SL=4 вертикальных среза. Пересечение среза и цепочки называется сегментом и имеет размер q/SL. Сегменты одного среза можно рассчитывать параллельно и они не связаны между собой. Все другие блоки могут быть связаны (ссылаться один на другой).

        срез 0     срез 1     срез 2     срез 3
       ___/\___   ___/\___   ___/\___   ___/\___
      /        \ /        \ /        \ /        \
     +----------+----------+----------+----------+
     |          |          |          |          | > цепочка 0
     +----------+----------+----------+----------+
     |          |          |          |          | > цепочка 1
     +----------+----------+----------+----------+
     |          |          |          |          | > цепочка 2
     +----------+----------+----------+----------+
     |         ...        ...        ...         | ...
     +----------+----------+----------+----------+
     |          |          |          |          | > цепочка p - 1
     +----------+----------+----------+----------+

Рисунок . Однопроходная функция Argon2 с p цепочек и 4 срезами.


3.4.1. Расчёт 32-битовых значений J_1 и J_2

3.4.1.1. Argon2d

J_1 задаётся первыми 32 битами блока B[i][j-1], а J_2 — следующими 32 битами блока B[i][j-1].

   J_1 = int32(extract(B[i][j-1], 0))
   J_2 = int32(extract(B[i][j-1], 1))

Рисунок . Расчет J1,J2 в Argon2d.


3.4.1.2. Argon2i

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

Z = ( LE64(r) || LE64(l) || LE64(sl) || LE64(m') || LE64(t) || LE64(y) )

Рисунок . Входные данные для расчета J1,J2 в Argon2i.


где

r — номер прохода;
l — номер цепочки;
sl — номер среза;
m’ — общее число блоков памяти;
t — число проходов;
y — тип Argon2 (0 для Argon2d, 1 для Argon2i, 2 для Argon2id).

Затем рассчитываются q/(128*SL) 1024-байтовых значений, как показано ниже.

   G(ZERO(1024),G(ZERO(1024), Z || LE64(1) || ZERO(968) )),
   G(ZERO(1024),G(ZERO(1024), Z || LE64(2) || ZERO(968) )),... ,
   G(ZERO(1024),G(ZERO(1024), Z || LE64(q/(128*SL)) || ZERO(968) ))

Эти значения делятся на q/(SL) 8-байтовых значений X, которые рассматриваются как X1||X2 и преобразуются в J_1=int32(X1) и J_2=int32(X2). Значения r, l, sl, m’, t, y, i представляются как 8 байтов в формате little endian.

3.4.1.3. Argon2id

Для прохода 0 и среза 0 и 1 значения J_1 и J_2 рассчитываются как в Argon2i, в остальных случаях — как в Argon2d.

3.4.2. Отображение J_1 и J_2 на индекс опорного блока [l][z]

Значение l = J_2 mod p задаёт индекс цепочки, из которой берётся блок. Для первого прохода (r=0) и первого среза (sl=0) блок берётся из текущей строки.

Множество W содержит индексы, которые указываются по приведённым ниже правилам.

  1. Если l — текущая цепочка, W включает индексы всех блоков из последних SL-1 = 3 рассчитанных и завершенных сегментов, а также из блоков, рассчитанных в текущем сегменте и проходе, кроме B[i][j-1].

  2. Если цепочка l не является текущей, W включает индексы всех блоков из последних SL-1 = 3 рассчитанных и завершенных сегментов в цепочке l. Если B[i][j] — первый блок сегмента, последний индекс исключается из W.

Затем берётся блок из W с неоднородным распределением по [0, |W|) с помощью указанного ниже отображения.

   J_1 -> |W|(1 - J_1^2 / 2^(64))

Рисунок . Расчёт J1.


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

   x = J_1^2 / 2^(32)
   y = (|W| * x) / 2^(32)
   zz = |W| - 1 - y

Рисунок . Расчёт J1, часть 2.


Затем берётся индекс zz из W. Это будет значение z для индекса «опорного» (reference) блока [l][z].

3.5. Функция сжатия G

Функция сжатия G строится на основе BLAKE2b-преобразования P, принимающего на входе 128 байтов, которые можно рассматривать ка восемь 16-байтовых регистров.

   P(A_0, A_1, ... ,A_7) = (B_0, B_1, ... ,B_7)

Рисунок . Функция раунда Блэйка P.


Функция сжатия G(X, Y) работает с двумя блоками по 1024 байта — X и Y. Сначала рассчитывается R = X XOR Y, затем R рассматривается как матрица 8×8 16-байтовых регистров R_0, R_1, … , R_63. После этого для получения Z применяется преобразование P сначала к каждой строке, затем к каждому столбцу.

   ( Q_0,  Q_1,  Q_2, ... ,  Q_7) <- P( R_0,  R_1,  R_2, ... ,  R_7)
   ( Q_8,  Q_9, Q_10, ... , Q_15) <- P( R_8,  R_9, R_10, ... , R_15)
                                 ...
   (Q_56, Q_57, Q_58, ... , Q_63) <- P(R_56, R_57, R_58, ... , R_63)
   ( Z_0,  Z_8, Z_16, ... , Z_56) <- P( Q_0,  Q_8, Q_16, ... , Q_56)
   ( Z_1,  Z_9, Z_17, ... , Z_57) <- P( Q_1,  Q_9, Q_17, ... , Q_57)
                                 ...
   ( Z_7, Z_15, Z 23, ... , Z_63) <- P( Q_7, Q_15, Q_23, ... , Q_63)

Рисунок . Ядро функции сжатия G.


Заключительным этапом G является операция Z XOR R.

   G: (X, Y) -> R -> Q -> Z -> Z XOR R

                            +---+       +---+
                            | X |       | Y |
                            +---+       +---+
                              |           |
                              ---->XOR<----
                            --------|
                            |      \ /
                            |     +---+
                            |     | R |
                            |     +---+
                            |       |
                            |      \ /
                            |   P для строки
                            |       |
                            |      \ /
                            |     +---+
                            |     | Q |
                            |     +---+
                            |       |
                            |      \ /
                            |  P для столбца
                            |       |
                            |      \ /
                            |     +---+
                            |     | Z |
                            |     +---+
                            |       |
                            |      \ /
                            ------>XOR
                                    |
                                   \ /

Рисунок . Функция сжатия G в Argon2.


3.6. Перестановка P

Перестановка P основана на круговой (round) функции BLAKE2b. Восемь 16-байтовых входных элементов S_0, S_1, … , S_7 рассматриваются как матрица 4×4 из 64-битовых слов, где S_i = (v_{2*i+1} || v_{2*i}).

            v_0  v_1  v_2  v_3
            v_4  v_5  v_6  v_7
            v_8  v_9 v_10 v_11
           v_12 v_13 v_14 v_15

Рисунок . Маркировка элементов матрицы.


Это работает, как показано ниже.

           GB(v_0, v_4,  v_8, v_12)
           GB(v_1, v_5,  v_9, v_13)
           GB(v_2, v_6, v_10, v_14)
           GB(v_3, v_7, v_11, v_15)

           GB(v_0, v_5, v_10, v_15)
           GB(v_1, v_6, v_11, v_12)
           GB(v_2, v_7,  v_8, v_13)
           GB(v_3, v_4,  v_9, v_14)

Рисунок . Передача элементов матрицы в GB.


Определение GB(a, b, c, d) приведено ниже.

           a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64)
           d = (d XOR a) >>> 32
           c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64)
           b = (b XOR c) >>> 24

           a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64)
           d = (d XOR a) >>> 16
           c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64)
           b = (b XOR c) >>> 63

Рисунок . Детали GB.


Сложение по модулю в GB сочетается с 64-битовым умножением. Перемножение является единственным отличием от исходной функции BLAKE2b. Это сделано для того, чтобы увеличить глубину схемы и, соответственно, время работы ASIC-реализация, при этом время работы на CPU будет примерно таким же за счёт распараллеливания и конвейеров.

4. Выбор параметров

Функция Argon2d оптимизирована для систем, где злоумышленники не имеют постоянного доступа к системной памяти или CPU, т. е. не могут организовать атаку через побочные каналы на основе данных о времени, а также не способны быстро восстановить пароль с использованием сборки мусора. Такие условия достаточно типичны для backend-серверов и майнинга криптовалют. Для практических ситуаций предлагаются указанные ниже настройки.

  • Майнинг криптовалюты, занимающий 0,1 сек на CPU с частотой 2 ГГц и одним ядром, — Argon2d с двумя цепочками и 250 Мбайт ОЗУ.

Функция Argon2id оптимизирована для более реалистичных ситуаций, где злоумышленник может получить доступ к машине, использовать её CPU или организовать атаку с холодной загрузкой (cold-boot). Предлагаемые настройки приведены ниже.

  • Аутентификация на backend-сервере, занимающая 0,5 сек на CPU с частотой 2 ГГц и 4 ядрами, — Argon2id с 8 цепочками и 4 Гбайт ОЗУ.

  • Вывод ключей для шифрования диска, занимающий 3 сек на CPU с частотой 2 ГГц и 2 ядрами, — Argon2id с 4 цепочками и 6 Гбайт ОЗУ.

  • Аутентификация на frontend-сервере, занимающая 0,5 сек на CPU с частотой 2 ГГц и 2 ядрами, — Argon2id с 4 цепочками и 1 Гбайт ОЗУ.

Ниже приведена процедура выбора типа и параметров для практического применение Argon2.

  1. Если применим однородно безопасный вариант без адаптации к оборудованию и прилежению, следует выбирать Argon2id с числом итераций t=1, числом цепочек p=4, m=2^(21) (2 Гбайт ОЗУ), 128-битовой затравкой и размером тега 256 битов. Это первый рекомендуемый вариант.

  2. Если доступен меньший объем памяти однородно безопасным вариантом будет Argon2id и чсилом итераций t=3, числом цепочек p=4, m=2^(16) (64 Мбайт ОЗУ), 128-битовой затравкой и размером тега 256 битов. Это второй рекомендуемый вариант.

  3. В иных случаях выбор начинается с типа y. Если различия между типами не ясны или предполагается реальная угроза атак по побочным каналам, следует выбирать Argon2id.

  4. Выбирается число цепочек p=4.

  5. Определяется максимальный объем памяти, доступной для каждого вызова, и транслируется в параметр m.

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

  7. Выбирается размер затравки (salt). 128 битов достаточно для всех приложений, но можно сократить размер до 64 битов в случае ограничений по пространству.

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

  9. Если атаки по побочным каналам являются реальной угрозой или нет уверенности по этому вопросу, при вызове библиотеки следует включить опцию очистки памяти (memory-wiping).

  10. Запускается схема типа y, с памятью m и числом цепочек lanes с использованием разного числа проходов t. Определяется максимальное значение t при котором время работы не выходит за допустимые пределы. Если это происходит при t = 1, следует уменьшить m.

  11. Используется Argon2 с найденными значениями m, p и t.

5. Тестовые векторы

В этом разделе приведены тестовые векторы для Argon2.

5.1. Тестовые векторы Argon2d

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

   =======================================
   Argon2d версии 19
   =======================================
   Размер памяти: 32 Кбайт
   Число проходов: 3
   Число параллельных цепочек: 4 
   Размер тега: 32 байта
   Пароль[32]: 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
   Затравка[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
   Секрет[8]: 03 03 03 03 03 03 03 03
   Связанные данные[12]: 04 04 04 04 04 04 04 04 04 04 04 04
   Дайджест предварительного хэширования: b8 81 97 91 a0 35 96 60
                       bb 77 09 c8 5f a4 8f 04
                       d5 d8 2c 05 c5 f2 15 cc
                       db 88 54 91 71 7c f7 57
                       08 2c 28 b9 51 be 38 14
                       10 b5 fc 2e b7 27 40 33
                       b9 fd c7 ae 67 2b ca ac
                       5d 17 90 97 a4 af 31 09

    После прохода 0:
   Блок 0000 [  0]: db2fea6b2c6f5c8a
   Блок 0000 [  1]: 719413be00f82634
   Блок 0000 [  2]: a1e3f6dd42aa25cc
   Блок 0000 [  3]: 3ea8efd4d55ac0d1
   ...
   Блок 0031 [124]: 28d17914aea9734c
   Блок 0031 [125]: 6a4622176522e398
   Блок 0031 [126]: 951aa08aeecb2c05
   Блок 0031 [127]: 6a6c49d2cb75d5b6

    После прохода 1:
   Блок 0000 [  0]: d3801200410f8c0d
   Блок 0000 [  1]: 0bf9e8a6e442ba6d
   Блок 0000 [  2]: e2ca92fe9c541fcc
   Блок 0000 [  3]: 6269fe6db177a388
   ...
   Блок 0031 [124]: 9eacfcfbdb3ce0fc
   Блок 0031 [125]: 07dedaeb0aee71ac
   Блок 0031 [126]: 074435fad91548f4
   Блок 0031 [127]: 2dbfff23f31b5883

    После прохода 2:
   Блок 0000 [  0]: 5f047b575c5ff4d2
   Блок 0000 [  1]: f06985dbf11c91a8
   Блок 0000 [  2]: 89efb2759f9a8964
   Блок 0000 [  3]: 7486a73f62f9b142
   ...
   Блок 0031 [124]: 57cfb9d20479da49
   Блок 0031 [125]: 4099654bc6607f69
   Блок 0031 [126]: f142a1126075a5c8
   Блок 0031 [127]: c341b3ca45c10da5
   Тег: 51 2b 39 1b 6f 11 62 97
        53 71 d3 09 19 73 42 94
        f8 68 e3 be 39 84 f3 c1
        a1 3a 4d b9 fa be 4a cb

5.2. Тестовые векторы Argon2i

   =======================================
   Argon2i версии 19
   =======================================
   Размер памяти: 32 Кбайт
   Число проходов: 3
   Число параллельных цепочек: 4 
   Размер тега: 32 байта
   Пароль[32]: 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
                 01 01 01 01 01 01 01 01
   Затравка[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
   Секрет[8]: 03 03 03 03 03 03 03 03
   Связанные данные[12]: 04 04 04 04 04 04 04 04 04 04 04 04
   Дайджест предварительного хэширования: c4 60 65 81 52 76 a0 b3
                       e7 31 73 1c 90 2f 1f d8
                       0c f7 76 90 7f bb 7b 6a
                       5c a7 2e 7b 56 01 1f ee
                       ca 44 6c 86 dd 75 b9 46
                       9a 5e 68 79 de c4 b7 2d
                       08 63 fb 93 9b 98 2e 5f
                       39 7c c7 d1 64 fd da a9

    После прохода 0:
   Блок 0000 [  0]: f8f9e84545db08f6
   Блок 0000 [  1]: 9b073a5c87aa2d97
   Блок 0000 [  2]: d1e868d75ca8d8e4
   Блок 0000 [  3]: 349634174e1aebcc
   ...
   Блок 0031 [124]: 975f596583745e30
   Блок 0031 [125]: e349bdd7edeb3092
   Блок 0031 [126]: b751a689b7a83659
   Блок 0031 [127]: c570f2ab2a86cf00

    После прохода 1:
   Блок 0000 [  0]: b2e4ddfcf76dc85a
   Блок 0000 [  1]: 4ffd0626c89a2327
   Блок 0000 [  2]: 4af1440fff212980
   Блок 0000 [  3]: 1e77299c7408505b
   ...
   Блок 0031 [124]: e4274fd675d1e1d6
   Блок 0031 [125]: 903fffb7c4a14c98
   Блок 0031 [126]: 7e5db55def471966
   Блок 0031 [127]: 421b3c6e9555b79d

    После прохода 2:
   Блок 0000 [  0]: af2a8bd8482c2f11
   Блок 0000 [  1]: 785442294fa55e6d
   Блок 0000 [  2]: 9256a768529a7f96
   Блок 0000 [  3]: 25a1c1f5bb953766
   ...
   Блок 0031 [124]: 68cf72fccc7112b9
   Блок 0031 [125]: 91e8c6f8bb0ad70d
   Блок 0031 [126]: 4f59c8bd65cbb765
   Блок 0031 [127]: 71e436f035f30ed0
   Тег: c8 14 d9 d1 dc 7f 37 aa
        13 f0 d7 7f 24 94 bd a1
        c8 de 6b 01 6d d3 88 d2
        99 52 a4 c4 67 2b 6c e8

5.3. Тестовые векторы Argon2id

   =======================================
   Argon2id версии 19
   =======================================
   Размер памяти: 32 Кбайт
   Число проходов: 3
   Число параллельных цепочек: 4
   Размер тега: 32 байта
   Пароль[32]: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
               01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
   Затравка[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
   Секрет[8]: 03 03 03 03 03 03 03 03
   Связанные данные[12]: 04 04 04 04 04 04 04 04 04 04 04 04
   Дайджест предварительного хэширования: 28 89 de 48 7e b4 2a e5 00 c0 00 7e d9 25 2f
    10 69 ea de c4 0d 57 65 b4 85 de 6d c2 43 7a 67 b8 54 6a 2f 0a
    cc 1a 08 82 db 8f cf 74 71 4b 47 2e 94 df 42 1a 5d a1 11 2f fa
    11 43 43 70 a1 e9 97

    После прохода 0:
   Блок 0000 [  0]: 6b2e09f10671bd43
   Блок 0000 [  1]: f69f5c27918a21be
   Блок 0000 [  2]: dea7810ea41290e1
   Блок 0000 [  3]: 6787f7171870f893
   ...
   Блок 0031 [124]: 377fa81666dc7f2b
   Блок 0031 [125]: 50e586398a9c39c8
   Блок 0031 [126]: 6f732732a550924a
   Блок 0031 [127]: 81f88b28683ea8e5

    После прохода 1:
   Блок 0000 [  0]: 3653ec9d01583df9
   Блок 0000 [  1]: 69ef53a72d1e1fd3
   Блок 0000 [  2]: 35635631744ab54f
   Блок 0000 [  3]: 599512e96a37ab6e
   ...
   Блок 0031 [124]: 4d4b435cea35caa6
   Блок 0031 [125]: c582210d99ad1359
   Блок 0031 [126]: d087971b36fd6d77
   Блок 0031 [127]: a55222a93754c692

    После прохода 2:
   Блок 0000 [  0]: 942363968ce597a4
   Блок 0000 [  1]: a22448c0bdad5760
   Блок 0000 [  2]: a5f80662b6fa8748
   Блок 0000 [  3]: a0f9b9ce392f719f
   ...
   Блок 0031 [124]: d723359b485f509b
   Блок 0031 [125]: cb78824f42375111
   Блок 0031 [126]: 35bc8cc6e83b1875
   Блок 0031 [127]: 0b012846a40f346a
   Тег: 0d 64 0d f5 8d 78 76 6c 08 c0 37 a3 4a 8b 53 c9 d0
    1e f0 45 2d 75 b6 5e b5 25 20 e9 6b 01 e6 59

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

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

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

7.1. Безопасность как хэш-функция и KDF

Уровни стойкости Argon2 к коллизиям и прообразам эквивалентны уровня базовой хэш-функции BLAKE2b. Для возникновения коллизиии требуется 2^(256) вводов данных, для нахождения прообраза — 2^(512) попыток ввода.

Безопасность KDF определяется длиной ключа и размером внутреннего состояния хэш-функции H’. Чтобы отличить вывод Argon2 с ключом от случайных данных, требуется по меньшей мере (2^(128),2^length(K)) вызовов BLAKE2b.

7.2. Атаки с компромиссом между расходом времени и памяти

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

В наиболее известной атаке на Argon2i с 1 и 2 проходами (атака с малым размером хранилища), описанной в[CBS16], произведение времени и памяти (с использованием пикового расхода памяти) сокращено в 5 раз. Наиболее сильная атака на Argon2i с 3 и более проходами описана в [AB16] и коэффициент сокращения здесь является функцией от размера памяти и числа проходов (например, при расходе 1 Гбайт и 3 проходах коэффициент составляет 3, при 4 проходах — 2,5, при 6 — 2). При каждом удвоении размера памяти коэффициент возрастает примерно на 0,5. Для полного предотвращения описанных в [AB16] атак число проходов должно быть больше двоичного логарифма размера памяти минус 26. Асимптотически наиболее сильная атака на Argon2i с одним проходом описана в [BZ17], при этом преимущества атакующего ограничены сверху значением O(m^(0,233)), где m — число блоков. Эта атака является асимптотически оптимальной, поскольку в [BZ17] показано, что верхняя граница для любой атаки — это O(m^(0,25)).

Наиболее сильной атакой на Argon2d с t проходами является компромиссная атака с ранжированием (ranking trade-off attack), где коэффициент сокращения составляет 1.,3.

Наиболее сильную атаку на Argon2id можно организовать путём дополнения наиболее сильной атаки на Argon2i с 1 проходом наиболее сильной атакой на многопроходный Argon2d. Таким образом, наиболее сильной компромиссной атакой на Argon2id с одним проходом является сочетание атаки с малым объёмом хранилища (для первой половины памяти) и атаки с ранжированием (для второй половины), которая даёт коэффициент сокращения около 2,1. Наиболее сильной атакой на Argon2id с t проходами является компромиссная атака с ранжированием, где коэффициент сокращения имеет значение 1,33.

7.3. Безопасность для ограниченных по времени защитников

Узким местом систем с хэшированием паролей часто является не расход памяти, а задержка, вносимая функцией. Разумная система защиты будет максимально увеличивать расходы атак с перебором (brute-force) для злоумышленников, имеющий список хэшей, затравок и сведений о времени для фиксированного времени расчётов на машине защитника. Оценки стоимости в работе [AB16] показывают, что для Argon2i три прохода почти оптимальны для большинства разумных размеров памяти, для Argon2d и Argon2id один проход максимизирует расходы на атаку при постоянном времени у защитника.

7.4. Рекомендации

Argon2id с t=1 и 2 Гбайт памяти является первым рекомендуемым вариантом и предлагается в качестве принятой по умолчанию настройки во всех средах. Эта настройка защищена от атак по побочным каналам и максимизирует расходы злоумышленников на оборудование для перебора (brute-force hardware). Argon2id с t=3 и памятью 64 Мбайт является вторым рекомендуемым вариантом в качестве принятого по умолчанию для систем с ограниченной памятью.

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

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

[BLAKE2] Saarinen, M-J., Ed. and J-P. Aumasson, «The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)», RFC 7693, DOI 10.17487/RFC7693, November 2015, <https://www.rfc-editor.org/info/rfc7693>.

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

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

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

[AB15] Biryukov, A. and D. Khovratovich, «Tradeoff Cryptanalysis of Memory-Hard Functions», ASIACRYPT 2015, DOI 10.1007/978-3-662-48800-3_26, December 2015, <https://eprint.iacr.org/2015/227.pdf>.

[AB16] Alwen, J. and J. Блокi, «Efficiently Computing Data-Independent Memory-Hard Functions», CRYPTO 2016, DOI 10.1007/978-3-662-53008-5_9, March 2016, <https://eprint.iacr.org/2016/115.pdf>.

[ARGON2] Biryukov, A., Dinu, D., and D. Khovratovich, «Argon2: the memory-hard function for password hashing and other applications», March 2017, <https://www.cryptolux.org/images/0/0d/Argon2.pdf>.

[ARGON2ESP] Biryukov, A., Dinu, D., and D. Khovratovich, «Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications», Euro SnP 2016, DOI 10.1109/EuroSP.2016.31, March 2016, <https://www.cryptolux.org/images/d/d0/Argon2ESP.pdf>.

[BZ17] Блокi, J. and S. Zhou, «On the Depth-Robustness and Cumulative Pebbling Cost of Argon2i», TCC 2017, DOI 10.1007/978-3-319-70500-2_15, May 2017, <https://eprint.iacr.org/2017/442.pdf>.

[CBS16] Boneh, D., Corrigan-Gibbs, H., and S. Schechter, «Balloon Hashing: A Memory-Hard Function Providing Provable Protection Against Sequential Attacks», ASIACRYPT 2016, DOI 10.1007/978-3-662-53887-6_8, May 2017, <https://eprint.iacr.org/2016/027.pdf>.

[HARD] Alwen, J. and V. Serbinenko, «High Parallel Complexity Graphs and Memory-Hard Functions», STOC ’15, DOI 10.1145/2746539.2746622, June 2015, <https://eprint.iacr.org/2014/238.pdf>.

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

Большое спасибо за подготовку и рецензирование документа Jean-Philippe Aumasson, Samuel Neves, Joel Alwen, Jeremiah Блокi, Bill Cox, Arnold Reinhold, Solar Designer, Russ Housley, Stanislav Smyshlyaev, Kenny Paterson, Alexey Melnikov, Gwynne Raskind.

Описанная в документе работа была выполнена до перехода Daniel Dinu в Intel (пока он учился в университете Люксембурга).

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

Alex Biryukov
University of Luxembourg
Email: alex.biryukov@uni.lu
 
Daniel Dinu
University of Luxembourg
Email: daniel.dinu@intel.com
 
Dmitry Khovratovich
ABDK Consulting
Email: khovratovich@gmail.com
 
Simon Josefsson
SJD AB
Email: simon@josefsson.org
URI: http://josefsson.org/

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

nmalykh@protokols.ru


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

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

RFC 9040 TCP Control Block Interdependence

Internet Engineering Task Force (IETF)                          J. Touch
Request for Comments: 9040                                   Independent
Obsoletes: 2140                                                 M. Welzl
Category: Informational                                         S. Islam
ISSN: 2070-1721                                       University of Oslo
                                                               July 2021

TCP Control Block Interdependence

Взаимозависимость блоков управления TCP

PDF

Аннотация

Этот документ содержит рекомендации для разработчиков TCP, предназначенные для улучшения сходимости соединений к устойчивому состоянию без ущерба для функциональной совместимости. Документ обновляет и отменяет описание RFC 2140 для совместного использования состояния TCP, обычно представленного в блоках управления TCP (Control Block), похожими одновременными или последовательными соединениями.

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

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

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

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

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

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

TCP — это ориентированный на соединения транспортный протокол с гарантией доставки, работающий на основе [RFC0793]. Для каждого соединения TCP поддерживается состояние, обычно в структуре данных, называемой блоком управления TCP (TCP Control Block или TCB). TCB содержит сведения о состоянии соединения, связанных с ним локальных процессах и параметры обратной связи о свойствах передачи данных через соединение. Как задано исходно и принято в большинстве реализаций, большая часть сведений TCB поддерживается на уровне каждого соединения. В некоторых реализациях часть данных TCB совместно используется соединениями с одним хостом [RFC2140]. Предполагается, что это обеспечивает повышение общей производительности в переходные периоды, особенно при большом числе краткосрочных или одновременных соединений, как это бывает в WWW и других приложениях [Be94] [Br02]. обобществление состояния призвано помочь соединениям TCP быстрее сходиться к долгосрочному поведению (при условии стабильной нагрузки приложения, т. е. в установившемся состоянии) без ущерба для функциональной совместимости TCP.

Этот документ обновляет обсуждение совместного использования состояния TCB в RFC 2140 и полностью заменяет упомянутый документ. обобществление состояния влияет лишь на инициализацию TCB [RFC2140] и не оказывает воздействия на долгосрочное состояние TCP после организации соединения и на функциональную совместимость. Сведения о пути, совместно используемые для портов получателя SYN, предполагают, что сегменты TCP между одной парой хостов имеют общие свойства пути, т. е. трафик не маршрутизируется по-разному в зависимости от номера порта или других параметров соединения (см. параграф 8.1). Замечания о совместном использовании TCB в этом документе применимы к любому протоколу с состоянием контроля перегрузок, включая протокол управления потоковой передачей (Stream Control Transmission Protocol или SCTP) [RFC4960] и протокол контроля перегрузок для дейтаграмм (Datagram Congestion Control Protocol или DCCP) [RFC4340], а также отдельным субпотокам в Multipath TCP [RFC8684].

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

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

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

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

Ниже перечислены термины, часто используемые в документе. Элементы с префиксом + могут быть частью поддерживаемого состояния соединения TCP в TCB связанных соединений и являться предметом обобществления, как описано в этом документе. Отметим, что термины используются в их исходном смысле, когда это возможно. В некоторых случаях направление указывается суффиксом _S для передачи и _R для приёма, а иногда явно (sendcwnd).

+cwnd

Размер окна перегрузки TCP [RFC5681].

host

Источник или приёмник сегментов TCP, связанных с одним адресом IP.

host-pair

Пара хостов и их соответствующих адресов IP.

ISN

Initial Sequence Number — начальный порядковый номер.

+MMS_R

Максимальный размер сообщения, которое может быть принято, наибольший размер принимаемых данных транспортного уровня в дейтаграмме IP [RFC1122].

+MMS_S

Максимальный размер сообщения, которое может быть передано, наибольший размер передаваемых данных транспортного уровня в дейтаграмме IP [RFC1122].

path

Путь Internet между IP-адресами пары хостов.

PCB

Протокольный блок управления — связанные с протоколом данные, поддерживаемые конечной точкой. Для протокола TCP блок PCB называется TCB.

PLPMTUD

Обнаружение MTU на пути для уровня пакетизации — механизм, использующий транспортные пакеты для определения максимального передаваемого по пути блока (Path Maximum Transmission Unit или PMTU) [RFC4821].

+PMTU

Наибольший размер дейтаграммы IP, которая может быть передана через путь [RFC1191] [RFC8201].

PMTUD

Обнаружение MTU на уровне пути — механизм, основанный на сообщениях ICMP об ошибках, для определения PMTU [RFC1191] [RFC8201].

+RTT

Время кругового обхода при обмене пакетами TCP [RFC0793].

+RTTVAR

Вариации времени кругового обхода при обмене пакетами TCP [RFC6298].

+rwnd

Размер приёмного окна TCP [RFC5681].

+sendcwnd

Размер окна перегрузки на приёмной стороне TCP (cwnd) [RFC5681].

+sendMSS

Максимальный размер сегмента TCP — значение, передаваемое в опции TCP, которое представляет максимальный размер пользовательских данных TCP, которые могут быть приняты [RFC6691].

+ssthresh

Порог замедленного старта TCP [RFC5681].

TCB

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

TCP-AO

Опция аутентификации TCP [RFC5925].

TFO

Опция TCP Fast Open [RFC7413].

+TFO_cookie

TCP Fast Open cookie — состояние, используемое как часть механизма TFO при поддержке TFO [RFC7413].

+TFO_failure

индикация отказа при согласовании опции TFO в случае поддержки TFO.

+TFOinfo

Информация, кэшируемая при организации соединения TFO, которая включает TFO_cookie [RFC7413].

4. Блок управления TCP (TCB)

TCB описывает данные, связанные с каждым соединением, т. е. взаимодействием пары приложений через сеть. В состав TCB входят по меньшей мере указанные ниже сведения [RFC0793]:

Состояние локального процесса

указатели на буферы приёма и передачи

указатели на очередь повторной передачи и текущий сегмент

указатели на IP PCB

Обобществлённое состояние на уровне соединения

macro-state

состояние соединения

таймеры

флаги

адреса и номера портов локального и удалённого хоста

состояние опций TCP

micro-state

состояние окна приёма и передачи (size*, текущий номер)

размер окна перегрузки (sendcwnd)*

пороговый размер окна перегрузки (ssthresh)*

максимальный наблюдаемый размер окна*

sendMSS#

MMS_S#

MMS_R#

PMTU#

время кругового обхода и его вариации#

Сведения по соединениям разделены на макро (macro-state) и микросостояние (micro-state), как принято в [Co91]. Макросостояние описывает протокол для организации начального общего состояния соединения — адреса и номера портов конечных точек, а также компоненты (таймеры, флаги), требуемые при организации и затем используемые для поддержки состояния. Микросостояние описывает протокол после организации соединения для поддержки надёжности и контроля перегрузок при передаче данных через соединение.

Выделены два других класса общего микросостояния, связанные больше с парой хостов, чем с парой приложений. Один класс явно зависит от пары хостов (суффикс #, например, sendMSS, MMS_R, MMS_S, PMTU, RTT), поскольку эти параметры определяются конечной точкой или парой конечных точек (в данном примере sendMSS, MMS_R, MMS_S, RTT) или уже кэшированы и обобществлены на основе этого (в данном примере PMTU [RFC1191] [RFC4821]). Другой класс зависит от пары хостов в совокупности (суффикс *, например, сведения об окне перегрузки, размеры текущих окон и т. п.), поскольку параметры определяются общей пропускной способностью между двумя конечными точками.

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

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

5. Взаимозависимость TCB

Существует два случая взаимозависимости TCB. Временное обобществление происходит, когда TCB прежнего (сейчас CLOSED) соединения с хостом служит для инициализации некоторых параметров нового (последующего) соединения с тем же хостом. Обобществление в ансамбле происходит когда текущее активное соединение с хостом применяется для инициализации нового (одновременного) соединения с тем же хостом.

6. Временное обобществление

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

6.1. Инициализация нового TCB

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

Таблица 1. Временное обобществление — инициализация TCB.

Кэшированный TCB

Новый TCB

old_MMS_S

old_MMS_S или без кэширования3

old_MMS_R

old_MMS_S или без кэширования

old_sendMSS

old_sendMSS

old_PMTU

old_PMTU4

old_RTT

old_RTT

old_RTTVAR

old_RTTVAR

old_option

(зависит от опции)

old_ssthresh

old_ssthresh

old_sendcwnd

old_sendcwnd

В таблице 2 приведён обзор связанных с опциями сведений, которые могут обобществляться. Дополнительные сведения о обобществлении конкретных опций TCP приведены в Приложении B.

Таблица 2. Временное обобществление — инициализация опций.

Кэшированная

Новая

old_TFO_cookie

old_TFO_cookie

old_TFO_failure

old_TFO_failure

6.2. Обновления кэша TCB

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

Таблица 3. Временное обобществление — обновление кэша.

Кэшированный TCB

Текущий TCB

Когда?

Новый кэшированный TCB

old_MMS_S

curr_MMS_S

OPEN

curr_MMS_S

old_MMS_R

curr_MMS_R

OPEN

curr_MMS_R

old_sendMSS

curr_sendMSS

MSSopt

curr_sendMSS

old_PMTU

curr_PMTU

PMTUD/PLPMTUD

curr_PMTU

old_RTT

curr_RTT

CLOSE

merge(curr,old)

old_RTTVAR

curr_RTTVAR

CLOSE

merge(curr,old)

old_option

curr_option

ESTAB

(зависит от опции)

old_ssthresh

curr_ssthresh

CLOSE

merge(curr,old)

old_sendcwnd

curr_sendcwnd

CLOSE

merge(curr,old)

Функция merge() объединяет текущее и прежнее (старое) значение и может различаться для каждого параметра в кэше. Документ не задаёт конкретную функцию. Например, может использоваться усреднение в окне (среднее из N прошлых значений для некоторого N) или разложение вида new = (1-alpha)*old + alpha*new, где alpha имеет значение из диапазона [0..1]).

В таблице 4 приведён обзор зависящей от опции информации, которая может обобщестляться аналогичным способом. значение TFO cookie поддерживается, пока клиент не запросит явное обновление как отдельное событие.

Таблица 4. Временное обобществление — обновление опций.

Кэшированное

Текущее

Когда?

Новое кэшированное

old_TFO_cookie

old_TFO_cookie

ESTAB

old_TFO_cookie

old_TFO_failure

old_TFO_failure

ESTAB

old_TFO_failure

6.3. Обсуждение

Как уже отмечалось, особой пользу от кэширования MMS_S и MMS_R нет, поскольку их сообщает локальный стек IP. Кэширование sendMSS и PMTU тривиально — сообщаемые значения кэшируются (PMTU на уровне IP) и спользуется самое свежее значение. Кэш обновляется при получении опции MSS в SYN или после PMTUD (т. е при получении сообщения ICMPv4 Fragmentation Needed [RFC1191] или ICMPv6 Packet Too Big [RFC8201], а также эквивалентных производных сообщений, например, от PLPMTUD [RFC4821]),поэтому в кэше всегда хранится самое свежее значение для соединения. Для sendMSS обращение к кэшу происходит только при организации соединения, а в других случаях кэш не обновляется, поэтому опции MSS не влияют на текущие соединения. Принятое по умолчанию значение sendMSS никогда не сохраняется и кэш одновляют лишь сообщеннные значения MSS, поэтому для снижения sendMSS требуется явное переопределение. Кэшированное значение sendMSS влияет только на данные в сегментах SYN, т. е. при организации соединения клиентом или одновременном открытии, MSS для остальных сегментов ограничивается значением, обновлённым из SYN.

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

Обновления RTT, RTTVAR и ssthresh основываются лишь на имеющихся сведениях (на старых значениях). Если старых значений нет, кэшируются текущие значения.

Опции TCP копируются или объединяются в зависимости от деталей каждой опции. Например, состояние TFO обновляется при организации соединения и считывается перед организацией нового соединения.

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

Большинство кэшированных значений TCB обновляется при закрытии соединения. Исключениями являются MMS_R и MMS_S, которые ссобщает IP [RFC1122], PMTU, обновляемое после Path MTU Discovery и также приходящее от IP [RFC1191] [RFC4821] [RFC8201], и sendMSS, которое обновляется при получении опции MSS в заголовке TCP SYN.

Совместное использование сведений sendMSS влияет лишь на данные в SYN следующего соединения, поскольку информация sendMSS обычно включается в большинство сегментов TCP SYN. Кэширование PMTU может повысить эффективность PMTUD, но может привести к возникновению «черной дыры», пока ошибка не будет исправлена. Кэширование MMS_R и MMS_S может оказывать лишь незначительное прямое влияние, поскольку эти значения все равно сообщает локальный стек IP.

Способ обоществления состояния, связанного с другими опциями TCP, зависит от каждой опции. Например, состояние TFO включает TCP Fast Open cookie [RFC7413], а при отказе TFO — негативный отклик TCP Fast Open. В RFC 7413 сказано:

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

TFOinfo кэшируется при организации соединения.

Состояние, связанное с другими опциями TCP, может кэшироваться не так легко. Например, отказ или успех TCP-AO [RFC5925] между парой хостов для одного порта получателя SYN может быть полезно кэшировать. Успех или отказ TCP-AO для других портов получателя SYN той же пары хостов не будет полезен для кэширования,поскольку параметры защиты TCP-AO могут меняться в зависимости от службы.

7. Обобществление в ансамбле

Обобществление кэшированных данных TCB несколькими одновременными соединениями требует внимания к агрегированной природе некоторых обобществлённых состояний. Например, хотя значения MSS и RTT можно обоществлять путём копирования, простое копирование окна перегрузок и ssthresh может оказаться нецелесообразным и новые значения могут быть функцией (f) от совокупных значения и числа соединений (N).

7.1. Инициализация нового TCB

Блоки TCB для новых соединений можно инициализировать на основе контекста параллельных соединений, как показано в таблице 5.

Таблица 5. Обобществление в ансамбле — инициализация TCB.

Кэшированный TCB

Новый TCB

old_MMS_S

old_MMS_S

old_MMS_R

old_MMS_R

old_sendMSS

old_sendMSS

old_PMTU

old_PMTU5

old_RTT

old_RTT

old_RTTVAR

old_RTTVAR

sum(old_ssthresh)

f(sum(old_ssthresh), N)

sum(old_sendcwnd)

f(sum(old_sendcwnd), N)

old_option

(зависит от опции)

В таблице 5 сумма кэшированных значений sum() определяется для всех активных соединений, поскольку параметр является агрегатным. Функция f() обновляет сумму на основе значений нового соединения, представленного как N.

В таблице 6 приведён обзор зависящей от опции информации, которая может обобщестляться аналогичным способом. Значение TFO cookie поддерживается, пока клиент не запросит явное обновление как отдельное событие.

Таблица 6. Обобществление в ансамбле — инициализация опций.

Кэшированное

Новое

old_TFO_cookie

old_TFO_cookie

old_TFO_failure

old_TFO_failure

7.2. Обновление кэша TCB

При работе соединения кэш TCB может обновляться по изменениям параллельных соединений и их TCB, как показано в таблице 7.

Таблица 7. Обобществление в ансамбле — обновление кэша.

Кэшированный TCB

Текущий TCB

Когда?

Новый кэшированный TCB

old_MMS_S

curr_MMS_S

OPEN

curr_MMS_S

old_MMS_R

curr_MMS_R

OPEN

curr_MMS_R

old_sendMSS

curr_sendMSS

MSSopt

curr_sendMSS

old_PMTU

curr_PMTU

PMTUD/PLPMTUD

curr_PMTU

old_RTT

curr_RTT

update

rtt_update(old, curr)

old_RTTVAR

curr_RTTVAR

update

rtt_update(old, curr)

old_ssthresh

curr_ssthresh

update

корректировка суммы при необходимости

old_sendcwnd

curr_sendcwnd

update

корректировка суммы при необходимости

old_option

curr_option

(зависимость)

(зависит от опции)

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

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

Таблица 8. Обобществление в ансамбле — обновление опций.

Кэшированное

Текущее

Когда?

Новое кэшированное

old_TFO_cookie

old_TFO_cookie

ESTAB

old_TFO_cookie

old_TFO_failure

old_TFO_failure

ESTAB

old_TFO_failure

7.3. Обсуждение

Для обобществления в ансамбле сведения TCB следует кэшировать как можно раньше, иногда до закрытия соединения. В противном случае создание множества одновременных соединений может не привести к обоществлению данных TCB, если перед созданием соединения не было закрыто другое соединение. Объем работы, связанной с обновлением агрегированных средних значений, следует минимизировать так, чтобы результат был эквивалентен измерению всех значений в рамках одного соединения. Функция rtt_update в таблице 7 указывает эту операцию, которая выполняется всякий раз, когда значение RTT будет обновляться в отдельном соединении TCP. В результате кэш содержит обобществленные переменные RTT, которые больше не нужно хранить в TCB.

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

В разделах 8 и 9 рассматриваются вопросы совместимости и влияние обобществления указанных выше сведений.

Имеется несколько способов инициализации окна перегрузки в новом TCB среди ансамбля текущих соединений с хостом. Современные реализации TCP инициализируют его 4 сегментами в соответствии со стандартом [RFC3390] и 10 — в экспериментах [RFC6928]. Эти подходы предполагают, что новым соединениям следует быть как можно более консервативными. Описанный в [Ba12] алгоритм корректирует начальное значение cwnd в зависимости от cwnd имеющихся соединений. Можно также использовать механизмы обобществления в долгосрочных интервалах для автоматической адаптации начального окна TCP, как описано в Приложении C.

8. Проблемы при совместном использовании сведений TCB

В этом разделе рассматриваются различные проблемы, которые могут возникать при обобществлении данных TCB. Для окна перегрузки и текущего окна начальные значения, определяемые взаимозависимостью TCB, могут не соответствовать долговременному поведению агрегата одновременных соединений между теми же конечными точками. Если при традиционном контроле перегрузок TCP окно перегрузки одного имеющегося соединения сходится к 40 сегментам, два недавно добавившихся соединения будут иметь начальные окна в 10 сегментов [RFC6928]А окно имеющегося соединения не будет сокращаться, чтобы воспринять дополнительную нагрузку. В результате три соединения могут мешать друг другу. Один из примеров этого можно видеть на узкополосных каналах с высокой задержкой, где одновременные соединения, поддерживающие трафик Web, могут конфликтовать из-за слишком большого начального окна, даже если это 1 сегмент.

Авторы работы [Hu12] рекомендуют кэшировать ssthresh для временного обобществления толь при длительных потоках. Некоторые исследования показываю, что обобществление ssthresh для коротких потоков может снижать производительность отдельных соединений [Hu12] [Du16], хотя это может повышать совокупную производительность.

8.1. Путь прохождения через сеть

TCP иногда используется в ситуациях, когда пакеты между одной парой хостов не всегда идут по одному пути, например, при использовании в маршрутизации параметров, зависящих от соединения (например, для распределения нагрузки). Маршрутизация по нескольким путям, основанная на транспортных заголовках, такая как ECMP и группы агрегирования каналов (Link Aggregation Group или LAG) [RFC7424] может не приводить к повторяющемуся выбору пути, когда сегменты TCP инкапсулируются, шифруются или изменяются, например, в туннеле виртуальной частной сети (Virtual Private Network или VPN), использующем фирменную (нестандартную) инкапсуляцию. Такие подходы не могут быть детерминированными при шифровании заголовков TCP, например, в случае применения инкапсуляции защищённых данных IPsec (Encapsulating Security Payload или ESP), хотя взаимозависимость TCB для всего набора с одинаковыми IP-адресами конечных точек должна работать без проблем при зашифрованных заголовках TCP. Можно применить меры для повышения вероятности использования соединениями одного пути, например, присваивать им одну метку потока IPv6 [RFC6437]. Взаимозависимость TCB можно распространить на наборы пар адресов IP, использующих одинаковые условия для сетевого пути, например, при размещении хостов в одной ЛВС (см. раздел 9).

Прохождение по одному пути не имеет значения для информации, связанной с хостом (например, rwnd), состояния опций TCP (например, TFOinfo) или сведений, уже кэшированных по хостам (например, path MTU). При обобществении данных TCB между различными портами получателя SYN, связанные с путём сведения могут быть некорректными, однако влияние таких ошибок снижается, если (как отмечено здесь) обобществление TCB влияет лишь на временное событие организации соединения или сведения TCB сообща применяюичся лишь соединениями с одним портом получателя SYN.

При временном обобществлении сведения TCB могут стать недействительными через некоторое время, указывая, что путь остался прежним, однако его свойства изменились. Поскольку это похоже на случай с простоем соединения, механизмы, применяемые в случае бездействия соединений TCP (например, [RFC7661]) могут применяться и для управления кэшем TCB, особенно при использовании TCP Fast Open [RFC7413].

8.2. Зависимость состояний

Могут быть дополнительные соображения относительно способа перераспределения взаимозависимостями TCB откликов о перегрузке между текущими соединениями. Например, может быть целесообразно рассмотреть влияние соединения в режиме Fast Recovery [RFC5681] или ином необычно режиме обратной связи, которые могут препятствовать или видять на описанные здесь расчёты.

8.3. Проблемы при обобществлении по адресу IP

Обобществление данных TCB между соединениями TCP одного хоста, идентифицируемого адресом IP, может оказаться ошибочным, если IP-адрес назначен новому хосту (например, при использовании провайдером IP address для подавления нежелательных серверов). Это может быть ошибкой при использовании трансляции сетевых адресов (Network Address Translation или NAT) [RFC2663], адресов и портов (Network Address and Port Translation или NAPT) [RFC2663] и других механизмов совместного использования адресов IP. В IPv6 такие механизмы применяются реже. Можно рассмотреть другие методы идентификации хоста для повышения вероятности кооректного обоществления данных TCB. Кроме того, некоторые сведения TCB относятся к доминирующим свойствам пути, а не к конкретному хосту — адреса IP могут различаться, но соответствующая часть пути может совпадать.

9. Последствия

Имеется несколько последствий встраивания взаимозависимости TCB в реализации TCP. Это может снижать потребность в мультиплексировании на прикладном уровне для повышения производительности [RFC7231]. Такие протоколы, как HTTP/2 [RFC7540], позволяют избежать расходов, связанных с повторной организацией соединений, сериализуя и мультиплексируя набор соединений хоста через одно соединение TCP. Это позволяет избежать на уровне соединений согласования TCP OPEN, а также повторного расчёта MSS, RTT и размера окна перегрузки. Избегая медленного перезапуска замедленного старта (slow-start restart), можно оптимизировать производительность [Hu01]. Взаимозависимость TCB может обеспечит такое предотвращение для мультиплексирования без необходимости поддержки мультиплексирования на уровне приложения.

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

9.1. Уровни

Взаимозависимость TCB выталкивая часть реализации TCP с обычного транспортного уровня (модель ISO) на сетевой. Это означает, что некоторые компоненты состояния относятся, по сути, к парам хостов и могут относиться к путям, заданным лишь такой парой хостов. Транспортные протоколы обычно управляют ассоциациями между парой хостов (потоки), а сетевые протоколы — ассоциациями между парами хостов и путями (маршрутизация). Время кругового обхода, MSS и сведения о перегрузке могут быть более подходящими для обработки на сетевом уровне, агрегироваться для одновременных соединений и обобществляться экземплярами соединений [RFC3124].

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

9.2. Другие возможности

Попарные ассоциации хостов не являются переделом возможностей описанных методов. Вполне возможно аналогичное обобществление TCB между хостами в подсети или в кластере, поскольку преобладаюим типом будут соединения между подсетями, а не между хостами. Кроме того, взаимозависимость TCB может работать в любом протоколе с поддержкой состояния перегрузок, включая SCTP [RFC4960], DCCP [RFC4340], а также отдельные субпотоки Multipath TCP [RFC8684].

Между параллельными соединениями может обобществляться и другая информация. Например, зная о неудачной попытке соединения расширить окно, другое соединение может отказаться на некоторое время от попыток сделать то же самое. Идея заключается в том, что существующие реализации TCP учитывают поведение всех одновременных соединений, включая относящиеся к одному хосту или подсети. Одна из возможных оптимизаций заключается в том, чтобы сделать неявные обратные связи явными через расширение сведений, связанных с IP-адресом и реализацией TCP каждой конечной точки, а не состоянием TCB на уровне соединения.

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

10. Имеющиеся реализации

Наблюдение о зависимости некоторых состояний TCB от пары хостов, а не пары предложений, не является новым и представляет обычное инженерное решание в многоуровневых реализациях протоколов. В T/TCP [RFC1644] (признан устаревшим) было впервые предложено использовать кэш для поддержки состояний TCB (см. Приложение A).

В таблице 9 показаны состояния реализации временного обобществления TCB в Windows на декабрь 2020 г., вариантах Apple (macOS, iOS, iPadOS, tvOS, watchOS) на явнварь 2021 г., ядре Linux версии 5.10.3 и FreeBSD 12. Обобществление для ансамблей ещё не реализовано.

Таблица 9. Известные состояния реализаций.

Данные TCB

Статус

old_MMS_S

Не обобществляется

old_MMS_R

Не обобществляется

old_sendMSS

Кэшируется и обобществляется в Apple, Linux (MSS)

old_PMTU

Кэшируется и обобществляется в Apple, FreeBSD, Windows (PMTU)

old_RTT

Кэшируется и обобществляется в Apple, FreeBSD, Linux, Windows

old_RTTVAR

Кэшируется и обобществляется в Apple, FreeBSD, Windows

old_TFOinfo

Кэшируется и обобществляется в Apple, Linux, Windows

old_sendcwnd

Не обобществляется

old_ssthresh

Кэшируется и обобществляется в Apple, FreeBSD, Linux6

TFO failure

Кэшируется и обобществляется в Apple

Apple в таблице 9 указывает операционные системы macOS (настольные и переносные ПК), iOS (телефоны), iPadOS (планшеты), tvOS (видео-проигрыватели), watchOS (часы), в которых применяется один стек протоколов Internet.

11. Отличия от RFC 2140

Этот документ обновляет описание обобществления TCB в RFC 2140 и его влияние на состояния имеющихся и новых соединений, полностью заменяя [RFC2140]. Разъяснены описания и термины, расширен механизм с учётом влияния новых протоколов и механизмов, включая Multipath TCP, Fast Open, PLPMTUD, NAT, TCP Authentication Option.

В подробном описании влияния на состояние TCB параметры TCB рассмотрены более конкретно. Разделены способы использовани MSS для приёма и передачи, ихи отличия от sendMSS, добавлены параметры Path MTU и ssthresh, а также рассмотрено влияние на состояние, связанное с опциями TCP. Добавлены сведения о проблемах совместимости и обзор реализаций. Связь этой работы с T/TCP перенесена в Приложение A (история обобществления TCB), отражая признание документа устаревшим. Добавлено Приложение C, где обсуждается возможное использование временного обобществления в долгосрочном масштабе для автомтическогй адаптации начального окна TCP, позволяющего обойтись без переиодического пересмотра значения глобального параметра. Кроме того, в документе обновлён и значительно расширен список литературы.

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

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

Обобществление TCB может приводить к дополнительным DoS-атакам, влияющим на производительность других соединений путём загрязнения обобществленных сведений. Это может происходить в любом наборе соединений с обобществлением TCB, соединений одного хоста или соединений между хостами при реализации обобществления внутри подсети (см. раздел 9). Некоторые обоществляемые параметры TCB используются лишь при создании новых TCB, а другие применяются всеми действующими соединениями. Новые соединения могут добавляться в имеющийся набор, например, для оптимизации окна передачи в соединениях с одним хостом. Значение PMTU задано как обоществляемое на уровне IP и уже подверженное таким атакам.

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

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

При обобществлении TCB повторно используется и смешивается информация из прошлых и текущих соединений. Хотя неоднократное использование информации может открывать возможность идентифицировать хосты по их отпечаткам (fingerprint) смешивание сокращает такие возможности. Не было замечено никаких подтверждений использования таких отпечатков и в настоящее время это считается безопасным. Сведения о производительности соединений TCP не считаются конфиденциальными.

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

Этот документ не запрашивает действий IANA.

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

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

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

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

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

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

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

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, «TCP Fast Open», RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

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

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

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

[Al10] Allman, M., «Initial Congestion Window Specification», Work in Progress, Internet-Draft, draft-allman-tcpm-bump-initcwnd-00, 15 November 2010, <https://datatracker.ietf.org/doc/html/draft-allman-tcpm-bump-initcwnd-00>.

[Ba12] Barik, R., Welzl, M., Ferlin, S., and O. Alay, «LISA: A linked slow-start algorithm for MPTCP», IEEE ICC, DOI 10.1109/ICC.2016.7510786, May 2016, <https://doi.org/10.1109/ICC.2016.7510786>.

[Ba20] Bagnulo, M. and B. Briscoe, «ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets», Work in Progress, Internet-Draft, draft-ietf-tcpm-generalized-ecn-07, 16 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07>.

[Be94] Berners-Lee, T., Cailliau, C., Luotonen, A., Nielsen, H., and A. Secret, «The World-Wide Web», Communications of the ACM V37, pp. 76-82, DOI 10.1145/179606.179671, August 1994, <https://doi.org/10.1145/179606.179671>.

[Br02] Brownlee, N. and KC. Claffy, «Understanding Internet traffic streams: dragonflies and tortoises», IEEE Communications Magazine, pp. 110-117, DOI 10.1109/MCOM.2002.1039865, 2002, <https://doi.org/10.1109/MCOM.2002.1039865>.

[Br94] Braden, B., «T/TCP — Transaction TCP: Source Changes for Sun OS 4.1.3», USC/ISI Release 1.0, September 1994.

[Co91] Comer, D. and D. Stevens, «Internetworking with TCP/IP», ISBN 10: 0134685059, ISBN 13: 9780134685052, 1991.

[Du16] Dukkipati, N., Cheng, Y., and A. Vahdat, «Research Impacting the Practice of Congestion Control», Computer Communication Review, The ACM SIGCOMM newsletter, July 2016.

[FreeBSD] FreeBSD, «The FreeBSD Project», <https://www.freebsd.org/>.

[Hu01] Hughes, A., Touch, J., and J. Heidemann, «Issues in TCP Slow-Start Restart After Idle», Work in Progress, Internet-Draft, draft-hughes-restart-00, December 2001, <https://datatracker.ietf.org/doc/html/draft-hughes-restart-00>.

[Hu12] Hurtig, P. and A. Brunstrom, «Enhanced metric caching for short TCP flows», IEEE International Conference on Communications, DOI 10.1109/ICC.2012.6364516, 2012, <https://doi.org/10.1109/ICC.2012.6364516>.

[IANA] IANA, «Transmission Control Protocol (TCP) Parameters», <https://www.iana.org/assignments/tcp-parameters>.

[Is18] Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G., and S. Gjessing, «ctrlTCP: Reducing latency through coupled, heterogeneous multi-flow TCP congestion control», IEEE INFOCOM 2018 — IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2018.8406887, April 2018, <https://doi.org/10.1109/INFCOMW.2018.8406887>.

[Ja88] Jacobson, V. and M. Karels, «Congestion Avoidance and Control», SIGCOMM Symposium proceedings on Communications architectures and protocols, November 1988.

[RFC1379] Braden, R., «Extending TCP for Transactions — Concepts», RFC 1379, DOI 10.17487/RFC1379, November 1992, <https://www.rfc-editor.org/info/rfc1379>.

[RFC1644] Braden, R., «T/TCP — TCP Extensions for Transactions Functional Specification», RFC 1644, DOI 10.17487/RFC1644, July 1994, <https://www.rfc-editor.org/info/rfc1644>.

[RFC2001] Stevens, W., «TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms», RFC 2001, DOI 10.17487/RFC2001, January 1997, <https://www.rfc-editor.org/info/rfc2001>.

[RFC2140] Touch, J., «TCP Control Block Interdependence», RFC 2140, DOI 10.17487/RFC2140, April 1997, <https://www.rfc-editor.org/info/rfc2140>.

[RFC2414] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 2414, DOI 10.17487/RFC2414, September 1998, <https://www.rfc-editor.org/info/rfc2414>.

[RFC2663] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.

[RFC3124] Balakrishnan, H. and S. Seshan, «The Congestion Manager», RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.

[RFC3390] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 3390, DOI 10.17487/RFC3390, October 2002, <https://www.rfc-editor.org/info/rfc3390>.

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

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, «IPv6 Flow Label Specification», RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.

[RFC6691] Borman, D., «TCP Options and Maximum Segment Size (MSS)», RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.

[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, «Increasing TCP’s Initial Window», RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., «TCP Extensions for High Performance», RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, «Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks», RFC 7424, DOI 10.17487/RFC7424, January 2015, <https://www.rfc-editor.org/info/rfc7424>.

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

[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, «Updating TCP to Support Rate-Limited Traffic», RFC 7661, DOI 10.17487/RFC7661, October 2015, <https://www.rfc-editor.org/info/rfc7661>.

[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, «TCP Extensions for Multipath Operation with Multiple Addresses», RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.

Приложение A. История обобществления TCB

В T/TCP предложено использовать кэш для поддержки использования данных TCB (временное обобществление), например, сглаженного значения RTT, вариаций RTT, порога предотвращения перегрузки и MSS [RFC1644]. Эти значения были добавлены к подсчёту соединений, используемому T/TCP для ускорения доставки данных до завершения трехэтапного согласования при OPEN. Цель заключалась о объединении компонентов TCB, когда они отражают одну ассоциацию пары хостов вместо искусственного разделения этих компонентов по соединениям.

По меньшей мере одна из реализаций T/TCP сохраняла MSS и агрегировала параметры RTT среди множества соединений, но не кэшировала сведения об окне перегрузки [Br94], как было изначально указано в [RFC1379]. Некоторые реализации T/TCP обновляли MSS сразу по получении опции заголовка TCP MSS [Br94], хотя это не было оговорено в концепциях и функциональной спецификации [RFC1379] [RFC1644]. В последующих реализациях T/TCP значения RTT обновлялись лишь после CLOSE, что не шло на пользу одновременным сессиям.

Временное обобществление кэшированных данных TCB было реализовано сначала в расширениях T/TCP Sun OS 4.1.3 [Br94] и варианте (port) FreeBSD [FreeBSD]. Как отмечено выше, кэшировались лишь MSS и параметры RTT, как исходно указано в [RFC1379]. В последующем обсуждении T/TCP было предложено включить в этот кэш параметры контроля перегрузок, например, параграф 3.1 в [RFC1644] советует инициализировать окно перегрузок прежним значением.

Приложение B. Обобществление и кэширование TCP Option

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

Устарели (сохранять состояние небезопасно)

Echo

Echo Reply

Разрешены соединения с частичным упорядочением (Partial Order Connection Permitted)

Профиль службы с частичным упорядочением (Partial Order Service Profile)

CC

CC.NEW

CC.ECHO

Запрос дополнительной контрольной суммы TCP (Alternate Checksum Request)

Данные дополнительной контрольной суммы TCP (Alternate Checksum Data)

Не сохраняется состояние

Конец списка опций (End of Option List или EOL)

Нет операции (No-Operation или NOP)

Масштабирование окна (Window Scale или WS)

SACK

Временные метки (TS)

Подпись MD5 (Signature Option)

Опция аутентификации TCP (TCP Authentication Option или TCP-AO)

Эксперимент 1 в стиле RFC3692

Эксперимент 2 в стиле RFC3692

Небезопасно сохранять состояние

Skeeter (известно, что обмен DH уязвим)

Bubba (известно, что обмен DH уязвим)

Контрольная сумма трейлера (Trailer Checksum Option)

Возможности SCPS

Селективные негативные подтверждения (Selective Negative Acknowledgements или S-NACK)

Границы записей

Позникло повреждение

SNAP

Фильтр сжатия TCP

Откли Quick-Start

Опция пользовательского тайм-аута (User Timeout Option или UTO)

Успех согласования Multipath TCP (MPTCP), об отказе см. ниже

Успех согласования TCP Fast Open (TFO), об отказе см. ниже

Safe but optional to keep state:

Отказ согласования Multipath TCP (MPTCP), об успехе см. выше

Максимальный размер сегмента (Maximum Segment Size или MSS)

Отказ согласования TCP Fast Open (TFO), об отказе см. ниже

Safe and necessary to keep state:

TCP Fast Open (TFO) Cookie (при успехе TFO в прошлом)

Приложение C. Автоматизация TCP IW в долгосрочном масштабе

C.1. Введение

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

Алгоритм контроля перегрузок TCP использует начальный размер окна (initial window или IW) как при старте новых соединений, так в качестве верхнего предела при перезапуке после простоя [RFC5681] [RFC7661]. Это значение меняется с течение времени — изначально устанавливается окно размером в 1 максимальный сегмент (MSS), которое постепенно увеличивается до меньшего за значений 4 MSS или 4380 байтов [RFC3390] [RFC5681]. Для типичного соединения Internet с MTU 1500 байтов это позволяет использовать 3 сегмента по 1460 байтов.

Значение IW предложено в исходном описании контроля перегрузки TCP и документировано как стандарт в 1997 г. [RFC2001] [Ja88]. Значение было обновлено в 1998 (экспериментально) и опубликовано как Standards Track в 2002 г. [RFC2414] [RFC3390]. В 2013 г. оно было экспериментально повышено до 10 [RFC6928].

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

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

C.2. Устройство

Значение TCP IW применяется статически уже более 20 лет и любому решению по динамической корректировке IW следует обеспечивать стабильное неразрушающее воздействие на производительность и сложность TCP. Для обеспечения беспристрастности значение IW следует делать близким для большинства машин в общедоступной сети Internet. Желательная также разработка самокорректирующего алгоритма, чтобы избегать значений IW, вызывающих проблемы в сети. В соответствии с этим предлагаются указанные ниже цели разработки.

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

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

  • Сокращение IW при наличии устойчивых потерь сегментов IW во множестве разных соединений.

  • Увеличение IW в отсутствие устойчивых потерь сегментом IW во множестве разных соединений.

  • Консервативные действия для сохранения IW при отсутствии достаточных сведений и более внимательное отношение к потере сегментов IW, нежели успешной доставке.

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

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

C.3. Предложенный алгоритм IW

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

  • MinIW = 3 MSS или 4380 байтов (в соответствии с [RFC3390]).

  • MaxIW = 10 MSS (в соответствии с [RFC6928]).

  • MulDecr = 0,5.

  • AddIncr = 2 MSS.

  • Threshold = 0,05.

Предполагается, что минимальное значение IW (MinIW) следует устанавливать в соответствии с текущим стандартом [RFC3390]. Для максимального IW (MaxIW) можно задать фиксированное значение (предполагается использовать экспериментальый документ [RFC6928], уже ставший фактическим стандартом) или основывать его на планировании, если доступны надёжные временные ссылки [Al10]. Здесь выбран вариант с фиксированным значением. Предлагается также использовать алгоритм адаптивного увеличения и эеспоненциального снижения (Additive Increase Multiplicative Decrease или AIMD) с указанными параметрами.

Хотя приведённые выше параметры в той или иной мере спорны, их исходные значения не важны, за исключением того, что алгоритму AIMD и параметру MaxIW не следует выходить за пределы, рекомендуемые для других систем Internet (здесь выбран фактический, а не формальный стандарт). Текущие предложения, включая принятые по умолчанию операции, являются вырожденными вариантами приведённого ниже алгоритма для заданных параметров (в частности, MulDec = 1,0 и AddIncr = 0 MSS, отключающих автоматическую часть алгоритма).

Предлагаемый алгоритм указан ниже

  1. При загрузке.

           IW = MaxIW;	# предполагается, что это целое число байтов, кратное 2 MSS
                           # (чётное для поддержки сжатия ACK)
  • При старте нового соединения

    CWND = IW;
    conncount++;
    IWnotchecked = 1; # true
  • При обработке SYN-ACK в соединении наличие ECN (как указано для ECN++ в разделе 5 [Ba20] для TCP), считается индикацией слишком большого IW

           if (IWnotchecked && (synackecn == 1)) {
               losscount++;
               IWnotchecked = 0; # больше не повторять
           }
  • При повторе передачи в соединении проверяется порядковый номер (seqno) исходящего пакета (в байтах) для обнаружения потери сегмента IW

           if (Retransmitting && IWnotchecked && ((seqno - ISN) < IW))) {
               losscount++;
               IWnotchecked = 0; # не повторять впредь при соблюдении условия
           } else {
               IWnotchecked = 0; # выход за предел IW, остановка проверки
           }
  • На каждую 1000 соединений выполняется отдельный процесс, не являющийся частью обработки данного соединения

           if (conncount > 1000) {
               if (losscount/conncount > threshold) { 
                   # слишком много соединений с ошибками
                   IW = IW * MulDecr;
               } else {
                   IW = IW + AddIncr;
               }
           }

В представленном виде алгоритм может давать ложные срабатывания при прохождении порядкового номера через максимум, например, код может увеличить losscount на этапе 4 при отсутствии потеррь или не увеличить при их наличии. Этого можно избежать, применяя контекст защиты от прохождения номер через максимум (Protection Against Wrapped Sequences или PAWS) [RFC7323] или расширяя внутреннее пространство порядковых номеров (как в TCP Authentication Option (TCP-AO) [RFC5925]). Можно допустить ложные срабатывания, считая из нечастыми и не оказывающими существенного влияния на алгоритм.

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

  • Автоматический алгоритм для IW должен инициализировать MaxIW значением не больше рекомендуемого в настоящее время по умолчанию для Internet при отсутствии других сведений о контексте. Таким образом, при слишком малом для принятия решения числе соединений или недостаточности иных сведений для увеличения IW параметр the MaxIW принимает текущее рекомендованное значение.

  • Реализация может разрешить рост MaxIW сверх рекомендуемого по умолчанию значения для Internet, но не более, чем на 2 сегмента за календарный год. Таким образом, при наличии у конечной точки постоянной истории успешной передачи сегментов IW без потерь ей разрешается исследовать Internet для проверки аналогичной успешности использования больших значений IW. Такая проверка ограничена и требует доверенного источника точного времни, иначе значение MaxIW сохранится постоянным.

  • Реализация должна корректировать IW на основе статистики не реже 1 раза на 1000 соединений.

    Конечная точка должна подобающим образом реагировать на потери сегментов IW.

  • Реализация должна снижать IW не менее, чем на 1 MSS, когда снижение указано в интервале оценки.

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

  • Реализация должна увеличивать значение не более, чем на 2 MSS за интервал оценки.

    Конечная точка, не сталкивающаяся с потерями IW должна инкрементально зондировать сеть.

  • Реализации следует использовать для IW целые значения, кратные 2 MSS.

    Значение IW следует сохранять кратным сегментам 2 MSS для эффективного сжатия ACK без возникновения излишних тайм-аутов.

  • Реализация должна снижать IW, если потери IW наблюдаются более, чем в 95% соединений.

    Это требуется для достаточн эффективной реакции реализации.

  • Реализация может группировать значения и статистику IW для подмножества соединений. Для группировки можно использовать любую информацию о соединениях, кроме статистики потерь.

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

Период, в течение которого обновляется IW, должен быть долгим, например, месяц или 1000 соединений (что больше). Реализация может проверять IW один раз в месяц и просто не обновлять IW или очищать счётчики соединений в месяцы, когда число соединений слишком мало.

C.4. Обсуждение

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

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

Алгоритм проверяет потери IW только для первого IW после старта, а затем проверка потерь IW не применяется (например, при использовании замедленного старта при перезапуске).

  • Реализация может обнаружить потери IW при замедленном старте в процессе перезапуска в дополнение к потерям в первом IW соединения. В этом случае реализация должна считать каждый перезапуск «соединением» для подсчёта соединений и переиодической проверки значения IW.

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

Этот механизм не требует дополнительного состояния на соединение, что в настоящее время распространено в некоторых реализациях и полезно по иным причинам (например, ISN в TCP-AO [RFC5925]). Механизм из этого приложения выигрывает от сохранения состояния при перезагрузке, что полезно и для других механизмов обобществления состояния (например, TCP Control Block Sharing, как описано выше).

Окно приёма (rwnd) не учитывается в расчёте, его размер определяется ресурсами получателя и обеспечивает пространство для восстановления порядка сегментов. Значение rwnd не участвует и в контроле перегрузки, который является основным способом управления IW в этом приложении.

C.5. Наблюдения

IW может не сходиться к одному глобальному значению и даже не сходиться совсем, осциллируя между несколькими значениями MSS при периодическом зондировании Internet для больших IW с отказами. Оба эти свойства согласуются с поведением TCP в каждом отдельном соединении.

Этот механизм предполагает, что потери в IW обусловлены размером IW. Постоянные ошибки с отбрасыванием пакетов по иным причинам, например, из-за ошибок ОС, могут вызывать ложные срабатывания. Это согласуется с базовым допущением TCP о потерях, вызываемых перегрузкой и требующих сокращения окна (backoff). Алгоритм считает IW новых соединений системов отката в длительных интервалах времени.

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

Авторы благодарны Praveen Balasubramanian за сведения об обобществлении TCB в Windows, Christoph Paasch — за сведения для Apple OS, Yuchung Cheng, Lars Eggert, Ilpo Jarvinen и Michael Scharf за комментарии к ранним версиям документа. Спасибо также членам рабочей группы TCPM WG. Предварительные выпуски этой работы финансировались в рамках совместного исследовательского проекта University of Oslo и Huawei Technologies Co., Ltd., а также частично поддерживались USC/ISI Postel Center.

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

Joe Touch

Manhattan Beach, CA 90266

United States of America

Phone: +1 (310) 560-0334

Email: touch@strayalpha.com

Michael Welzl

University of Oslo

PO Box 1080 Blindern

N-0316 Oslo

Norway

Phone: +47 22 85 24 20

Email: michawe@ifi.uio.no

Safiqul Islam

University of Oslo

PO Box 1080 Blindern

Oslo N-0316

Norway

Phone: +47 22 84 08 37

Email: safiquli@ifi.uio.no


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

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

nmalykh@protokols.ru


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

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

3PMTU кэшируется на уровне IP [RFC1191] [RFC4821].

4Некоторые значения не кэшируются при локальном расчёте (MMS_R) или указании в самом соединении (MMS_S в SYN).

5PMTU кэшируется на уровне IP [RFC1191] [RFC4821].

6Для FreeBSD новое значение ssthresh является средним между curr_ssthresh и текущим значением, для Linux расчёт в большинстве случаев зависит от состояния и max(curr_cwnd/2, old_ssthresh).

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

RFC 9063 Host Identity Protocol Architecture

Internet Engineering Task Force (IETF)                 R. Moskowitz, Ed.
Request for Comments: 9063                                HTT Consulting
Obsoletes: 4423                                                  M. Komu
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                July 2021

Host Identity Protocol Architecture

Архитектура протокола отождествления хостов

PDF

Аннотация

В этом документе описано пространство имён отождествления хостов (Host Identity), которое обеспечивает криптографическое пространство имён для приложений, протокол отождествления хоста (Host Identity Protocol или HIP), размещаемый между сетевым1 и транспортным уровнем, который поддерживает мобильность конечных хостов, многодомность и работу через NAT. В документе рассмотрены основы используемых в настоящее время пространств имён с их преимуществами и недостатками, а также их дополнение пространством HI. Определены роли пространства имён отождествления хостов в протоколах.

Этот документ отменяет RFC 4423 и решает проблемы, отмеченные IESG, в частности, вопрос гибкости шифрования. В разделе 11. Вопросы безопасности рассмотрены меры предотвращения лавинных атак (flooding), применение идентификаторов в списках контроля доступа, слабые типы идентификаторов и доверие при первом применении. Документ включает в себя уроки, извлечённые из реализации RFC 7401, и идёт дальше в разъяснении работы HIP как защищённого сигнального канала.

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

Документ относится к категории информационных и не задаёт стандартов Internet.

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

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

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

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

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

Предлагаемое пространство имён отождествления хостов также является глобальными занимает место между пространствами IP и DNS. Концептуально это пространство имён. относится к вычислительной платформе и такая платформа может иметь несколько идентификаторов (поскольку платформа может по разному идентифицировать себя разным партнёрам). Пространство имён. отождествления хостов состоит из идентификаторов хостов (Host Identifier или HI). Для каждого отождествления применяется в точности один идентификатор HI (хотя могут возникать переходные периоды, например, в момент замены ключей, когда могут быть активны несколько идентификаторов). Хотя далее в тексте обсуждаются некриптографические идентификаторы, архитектура фокусируется на криптографических идентификаторах хостов (HI). В частности, HI является открытым ключом асимметричной пары. Каждое отождествление хоста однозначно указывает один хост, т. е. два хоста не могут иметь совпадающие Host Identity. Если идентификаторы HI совпадают у двух или более вычислительных платформ, эти платформы являются экземплярами распределенного хоста. Идентификатор HI может быть публичным (например, доступным через DNS) или непубликуемым. В клиентских системах будут применяться оба типа HI.

Имеется незначительное но важное различие между отождествлением (Host Identity) и идентификатором (HI). Отождествление указывает абстрактную сущность, которая идентифицируется, а идентификатор — конкретную последовательность битов, используемую в процессе идентификации.

Хотя HI могут применяться во многих системах проверки подлинности (аутентификации), таких как IKEv2 [RFC7296], представленная архитектура задаёт новый протокол, названный протоколом отождествления хоста (Host Identity Protocol или HIP), и криптографический обмен, названный базовым обменом HIP (см. 6. Плоскость управления. HIP обеспечивает ограниченные варианты доверия между системами, повышает уровни мобильности, многодомности и динамической смены адресов IP, помогая в трансляции и изменении протоколов, а также снижая возможности организации некоторых DoS4-атак.

При использовании HIP фактический трафик данных между двумя хостами HIP обычно (но не обязательно) защищается с помощью ESP5 [RFC7402]. Отождествления хостов применяются для создания защищённых связей ESP (Security Association или SA) и аутентификации хостов. При использовании ESP фактические данные пакетов IP не отличаются от передаваемых в обычных пакетах IP с защитой ESP.

С момента публикации [RFC4423] было получено много информации о HIP [RFC6538]. Этот документ расширяет отождествление хоста за пределы первоначального применения для обеспечения связности IP и защиты, с целью предоставления общей защищённой сигнализации между хостами на уровне любого протокола. Сигналы могут организовать защищённую связь между хостами или просто передавать информацию внутри канала.

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

2.1. Общие с другими документами термины

Таблица 1.

Термин

Определение

Public key
Открытый ключ

Открытый ключ асимметричной криптографической пары ключей. Применяется в качестве доступного идентификатора для криптографической проверки подлинности. Открытость в данном случае трактуется в диапазоне от «известно партнёру» до «известно всем».

Private key
Секретный ключ

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

Public key pair
Пара с открытым ключом

Асимметричная пара криптографических ключей, содержащая открытый и секретный ключ. Например, это может быть пара ключей Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA).

Endpoint
Конечная точка

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

2.2. Термины, относящиеся к документам HIP

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

Таблица 2.

Термин

Определение

Computing platform
Вычислительная платформа

Элемент, способный к взаимодействию и расчётам, например, компьютер. См. определение Endpoint выше.

HIP base exchange
Базовый обмен HIP

Криптографический протокол (см. также раздел 6).

HIP packet
Пакет HIP

Пакет IP, содержащий сообщение HIP.

Host Identity
Отождествление хоста

Абстрактная концепция, связанная с вычислительной платформе. См. Host Identifier ниже.

Host Identifier
Идентификатор хоста

Открытый ключ, служащий именем для отождествления хоста (Host Identity).

Host Identity namespace
Пространство имён отождествления хостов

Пространство имён, содержащее все возможные HI.

Host Identity Protocol
Протокол отождествления хоста

Протокол, используемый для передачи и аутентификации HI и другой информации.

Host Identity Hash
Хэш отождествления хоста

Криптографический хэш, применяемый для создания HIT из HI.

Host Identity Tag
Тег отождествления хоста

128-битовый блок данных, создаваемый применением криптографического хэширования к HI, с битами идентификации метода хэширования.

Local Scope Identifier
Локальный идентификатор

32-битовый блок данных, обозначающий отождествление хоста.

Public Host Identifier and Identity
Публичный идентификатор и отождествление хоста

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

Unpublished Host Identifier and Identity
Неопубликованный идентификатор и отождествление хоста

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

Rendezvous Mechanism
Механизм встречи (рандеву)

Механизм, используемый для нахождения мобильных хостов по их HIT.

3. Основы

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

Для этих элементов (платформ) в Internet применяется два основных пространства имён — IP-адреса и доменные имена. Система доменных имён обеспечивает иерархическое выделение имён для некоторых вычислительных платформ и служб. Каждый уровень иерархии получает полномочия от вышележащего уровня и в доменных именах нет анонимности. Примерами доменных имён являются адреса Email, HTTP, SIP.

Пространство адресов IP перегружено их применением для интерфейсов (L3) и конечных точек (связанная с конечной точкой часть L3 и уровень L4). В части именования интерфейсов адреса IP иногда называют «локаторами» (locator) и они служат конечными точками в топологии маршрутизации.

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

В современной сети Internet транспортные уровни неразрывно связаны с адресами IP и не могут развиваться отдельно. На разработку IPng существенно повлиял отказ от создания соответствующего транспорта TCPng.

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

3.1. Пространство имён для вычислительных платформ

Независимое пространство имён для вычислительных платформ может применяться для сквозных (end-to-end) операций независимо от развития сетевого уровня и между разными сетевыми уровнями. Это позволит быстро менять адреса на сетевом уровне при перемещении, переносе или переадресации.

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

Ниже приведены характеристики пространства имён (для вычислительных платформ) и имён в них.

  • Пространство имён следует применять на уровне «ядра» или стека IP. Стек IP размещается между приложениями и инфраструктурой доставки пакетов.

  • Пространству следует полностью отделять (меж)сетевой уровень от вышележащих уровней. Именам следует заменять собой все вхождения адресов IP внутри приложений (как в блоке управления транспортом Transport Control Block или TCB). Замена может быть выполнена незаметно для унаследованных приложений с помощью локальных идентификаторов (Local Scope Identifier или LSI) и HIT, совместимых с адресами IPv4 и IPv6 [RFC5338]. Однако понимающие HIP приложения потребуется несколько изменить, например, в расширениях API для HIP [RFC6317].

  • Для введения пространства имён не следует требовать какой-либо административной инфраструктуры. Развёртывание должно выполняться снизу вверх попарно.

  • Для имён следует использовать представление фиксированного размера для простоты включения в заголовки дейтаграмм и имеющиеся программные интерфейсы (например, TCB).

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

  • По возможности следует избегать конфликтов имён. Можно использовать математический «парадокс дней рождения» для оценки вероятности конфликта в данной популяции и хэш-пространстве. В общем случае для случайного хэш-пространства размером n битов конфликт предполагается после примерно 1,2*sqrt(2n) хэш-значений. Для 64 это составит около 4 миллиардов. Размер 64 бита может оказаться слишком малым для крупных популяций, например вероятность конфликта составит 1% для популяции 640M. Для 100 битов (или более) возникновение конфликта ожидается после расчёта 250 (1 квадриллион) значений. При используемом в настоящее время размере 96 битов [RFC7343] можно рассчитать без конфликтов 248 (281 триллион) значений.

  • Именам следует иметь локализованную абстракцию, чтобы их можно было применять в имеющихся протоколах и API.

  • Должна обеспечиваться возможность локального создания имён. Когда имена не публикуются, это может обеспечивать анонимность за счёт сложности предсказания.

  • Пространству имён следует поддерживать услуги проверки подлинности.

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

В этом документе пространство имён, соответствующее приведённым выше характеристикам, называется пространством отождествления хостов — Host Identity. Использование идентификаторов HI требует своего протокольного уровня (Host Identity Protocol) между (меж)сетевым и транспортным уровнем. Имена создаются на основе криптографии с открытым ключом для предоставления услуг аутентификации. При корректной реализации можно обеспечить соответствие всем требованиям, приведённым выше.

4. Пространство имён отождествления хостов

Имя в пространстве Host Identity — идентификатор хоста (HI) представляет статистически уникальное значение для указания любой системы со стеком IP. Это отождествление обычно связано со стеком IP, но не ограничивается такой связью. Система может иметь множество идентификаторов, некоторые могут быть общеизвестными (well known), а другие — анонимными. Система может самостоятельно отождествлять себя или использовать сторонний аутентификатор, например DNSSEC [RFC4033], Pretty Good Privacy (PGP) или X.509 для «нотариального заверения» своего отождествления в другом пространстве имён.

Теоретически, любое имя, статистически уникальное в глобальном масштабе, может служить в качестве HI. В архитектуре HIP в качестве такого имени выбран открытый ключ пары асимметричных ключей, поскольку им можно управлять самостоятельно и такой ключ сложно подделать. Как указано в спецификации протокола HIP [RFC7401], HI на основе открытых ключей позволяет аутентифицировать пакеты HIP и защитить их от MitM6-атак. Поскольку аутентифицированные дейтаграммы обязательны для обеспечения основной защиты HIP от DoS-атак, обмен Diffie-Hellman в базовом обмене HIP использует аутентификацию. Таким образом, на практике поддерживаются лишь HI на базе открытых ключей и аутентифицированные сообщения HIP.

В этом документе упоминаются некриптографические формы HI и HIP, но следует предпочитать криптографические варианты, поскольку они более защищены. В прошлом исследовались варианты применения некриптографических HI для радио-меток (Radio Frequency IDentification или RFID) в обмене HIP, адаптированном для работы с такими задачами ([urien-rfid], [urien-rfid-draft]).

4.1. Идентификаторы хостов

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

Отождествление в HIP основано на парах из секретного и открытого ключа и представляется открытым ключом. Таким образом, имя, представляющее отождествление хоста в пространстве Host Identity, т. е. HI, является открытым ключом. В некотором смысле отождествление определяется владением секретным ключом. Если секретным ключом владеет несколько узлов, отождествление может считаться распределенным.

Архитектурно в качестве HI можно использовать любое другое соглашение от именовании в Internet, однако некриптографичекие имена следует применять лишь в средах с высоким уровнем доверия и/или малыми рисками. Это могут быть места, где не требуется аутентификация (нет риска подмены хоста) или не нужна защита ESP. Однако для соединённых между собой сетей, охватывающих несколько операционных доменов и сред, где существует риск подмены хостов, использование некриптографических HI вносит существенный риск. Поэтому в текущих документах HIP не задано использование HI, не основанных на открытых ключах. Например, служба Back to My Mac [RFC6281] от Apple очень близка по функциональности к HIP, но основана на некриптографических идентификаторах.

Реальные HI не применяются напрямую на транспортном или сетевом уровне. Соответствующие HI (открытые ключи) могут храниться в DNS или иных каталогах, как указано в этом документе, и могут передаваться в базовом обмене HIP. Другие протоколы применяют тег отождествления хоста (Host Identity Tag или HIT) для представления Host Identity. Другое представления отождествлений хостов — локальный идентификатор (Local Scope Identifier или LSI) также можно применять в протоколах и API.

4.2. Хэш отождествления хоста (HIH)

Хэш отождествления хоста (Host Identity Hash или HIH) — это криптографических алгоритм, служащий для создания HIT из HI, а также применяемый в HIP для простоты и единообразия. Два хоста в обмене HIP могут применять разные алгоритмы.

Требуется несколько HIH внутри HIP для решения вопросов создания перемещающихся целей и разрешения возможных конфликтов хэш-значений. Это существенно усложняет протокол HIP и ослабляет возможность атак на понижение в HIP [RFC7401].

4.3. Тег отождествления хоста (HIT)

Тег отождествления хоста (Host Identity Tag или HIT) — это 128-битовое представление Host Identity. Благодаря размеру, тег подходит для использования в имеющихся API сокетов вместо адреса IPv6 (например, sin6_addr в структуре sockaddr_in6) без внесения изменений в приложения. Тег создаётся из HIH, префикса IPv6 [RFC7343] и идентификатора хэш-функции. Имеется два преимущества использования в протоколах HIT вместо HI. Первым является фиксированный размер, что упрощает кодирование протоколов и более эффективное управление размером пакетов. Во-вторых, тег представляет отождествление протоколу в согласованном формате независимо от используемых криптоалгоритмов.

По сути, HIT представляет собой хэш открытого ключа, поэтому не его создание влияют два алгоритма, используемые для открытого ключа HI и HIH. Эти алгоритмы кодируются в битовом представлении HIT. Поскольку две взаимодействующих стороны могут поддерживать разные алгоритмы, в [RFC7401] определён минимальный набор для надёжного взаимодействия. Для расширения возможностей взаимодействия отвечающая сторона (Responder) может сохранять свои ключи в записях DNS и инициатор может связать HIT адресата с соответствующими HIT источника по совпадению HIH.

В пакетах HIP идентификаторы HIT указывают отправителя и получателя пакетов, поэтому значениям HIT следуют быть уникальными во всем пространстве IP, где они применяются. В очень редких случаях, когда одно значение HIT сопоставляется с несколькими Host Identity, идентификаторы HI (открытые ключи) будут обеспечивать различие. Если для данного узла имеется несколько открытых ключей, HIT служит подсказкой для выбора нужного ключа.

Хотя случайные конфликты, когда одно значение HIT сопоставляется с несколькими Host Identity, могут возникать редко, атакующий может с помощью перебора или использования слабости алгоритма, найти второй хэш Host Identity с тем же HIT. Этот тип атак называют атаками на прообраз (preimage attack) и устойчивость к нахождению второго идентификатора HI (открытого ключа), который хэшируется в то же значение HIT называется устойчивостью ко второму прообразу. Такая устойчивость в HIP основана на силе алгоритма хэширования и выходном размере хэш-функции. Для HIPv2 [RFC7401] устойчивость составляет 96 битов (меньше 128-битового размера адреса IPv6 по причине наличия префикса ORCHID7 [RFC7343]). Такая устойчивость сочтена достаточной на момент разработки HIP, но её может не хватить для модели угроз предполагаемого развёртывания. Одним из возможных решений может быть расширение использования HIT в развёртывании за счёт идентификаторов HI (и механизмов защищённой привязки HI к HIT) так, что HI становится окончательным основанием. Можно также усложнить атаки с перебором за счёт увеличения сложности расчёта HI, например, с помощью защищенного обнаружения криптографически созданных адресов соседей (Secure Neighbor Discovery Cryptographically Generated Addres) [RFC3972], хотя спецификации HIP до HIPv2 не предоставляют такого механизма. Если при развёртывании не применяются идентификаторы ORCHID (например, в некоторых типах наложенных сетей), можно использовать полный размер 128 битовых адресов IPv6 для HIT.

4.4. Идентификатор с локальной областью действия (LSI)

LSI — это 32-битовое локализованное представление Host Identity, которое, благодаря его размеру, можно применять в имеющихся API сокетов вместо адресов IPv4 (например, sin_addr в структуре sockaddr_in), не изменяя приложений. Назначение LSI состоит в облегчении использования HI в имеющихся API для приложений IPv4. Значения LSI не передаются в линию и при передаче приложением данных с использованием пары LSI уровень HIP (или обработчик сокетов) транслирует LSI в соответствующие HIT (и обратно в случае приёма данных). Кроме упрощения связности на основе HIP для традиционных приложений IPv4, идентификаторы LSI полезны в 2 других сценариях [RFC6538].

В первом случае два приложения, поддерживающих лишь IPv4, размещены на двух разных хостах, соединённых через сеть с поддержкой только IPv6. Связность на основе HIP позволяет этим приложениям взаимодействовать, несмотря на различие семейств протоколов приложений и базовой сети. Это обусловлено тем, что уровень HIP транслирует LSI от вышележащих уровней в маршрутизируемые локаторы (адреса) IPv6 перед отправкой пакетов в линию.

Второй случай похож на описанный, но одно из приложений поддерживает лишь IPv6. Здесь имеется два препятствия взаимодействию приложений — разные семейства адресов, используемые двумя приложениями, и невозможность приложения IPv4 обмениваться данными с сетью IPv6. Связность на основе HIP решает эту проблему, транслируя локатор (адрес) входящего пакета в LSI или HIT.

Фактически LSI расширяет возможности взаимодействия IPv6 на сетевом уровне, как описано для первого случая, и на прикладном, как описано для второго. Механизм расширения возможностей взаимодействия не следует применять для отказа от перехода на IPv6, авторы твердо верят в принятие IPv6 и призывают разработчиков переводить имеющиеся приложения с поддержкой лишь IPv4 на использование IPv6. Однако некоторые фирменные приложения с закрытым кодом, поддерживающие лишь IPv4, могут не увидеть света IPv6 и здесь механизм LSI поможет продлить их жизнь даже в сетях, поддерживающих лишь IPv6.

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

4.5. Сохранение HI в каталогах

Общедоступные HI следует сохранять в DNS, а неопубликованные не следует сохранять нигде, кроме самих взаимодействующих хостов. Для хранения (общедоступных) HI вместе с поддерживаемыми HIH имеется новый тип записи о ресурсах (Resource Record или RR), определённый в расширении HIP DNS [RFC8005].

В дополнение к сохранению HI в DNS их можно хранить в других каталогах, например, LDAP (Lightweight Directory Access Protocol) или PKI (Public Key Infrastructure) [RFC8002]. Кроме того, были успешно использованы [RFC6538] распределенные таблицы хэшей (Distributed Hash Table или DHT) [RFC6537]. Такая практика позволяет применять идентификаторы не только для распознавания хостов.

Некоторые типы приложений могут кэшировать и использовать HI напрямую, а другие опосредованно находить идентификаторы по символьным именам хостов, таким как полные доменные имена (Fully Qualified Domain Name или FQDN), путём просмотра каталогов. Хотя HI могут действовать существенно дольше связанных с ними маршрутизируемых адресов IP, каталоги могут оказаться лучшим подходом для управления сроком действия HI. Например, каталог на основе LDAP или DHT можно применять для опубликованных локально идентификаторов, а DNS лучше подходит для общедоступных.

5. Новая архитектура стека

Одним из способов охарактеризовать Host Identity является сравнение предложенной архитектуры на основе HI с используемой в настоящее время. Как отмечено в отчёте IRTF Name Space Research Group Report [nsrg-report] и, например, документе «Endpoints and Endpoint Names» [chiappa-endpoints], адреса IP в настоящее время играют двойную роль — «локаторов» и идентификаторов конечных точек, т. е. каждый адрес IP указывает топологическое местоположение в Internet, действуя как вектор направления маршрутизации или «локатор», и в то же время именует физический сетевой интерфейс, размещённый в данный момент в точке подключения, выступая как имя конечной точки.

В архитектуре HIP имена конечных точек и «локаторы» отделены одно от другого. Идентификаторы HI указывают конечные точки. Важно понимать, что имена конечных точек, основанные на HI несколько отличаются от имён интерфейсов и доступ к Host Identity может одновременно обеспечиваться через несколько интерфейсов. Различия в привязках логических объектов показаны на рисунке 1, где слева показана текущая архитектура TCP/IP, а справа — архитектура на основе HIP

Транспортная --- Сокет                 Транспортная --- Сокет
ассоциация       |                     ассоциация       |
                 |                                      |
                 |                                      |
                 |                                      |
Конечная         |                     Конечная --- Host Identity
точка    \       |                     точка            |
           \     |                                      |
             \   |                                      |
               \ |                                      |
Место    --- IP-адрес                  Место    --- IP-адрес

Рисунок 1.


Архитектурно HIP обеспечивает разную привязку протоколов транспортного уровня, т. е. ассоциации транспортного уровня (например, соединения TCP и ассоциации UDP) связаны не с адресами IP. А с идентификаторами HI. На практике отождествление хостов раскрывается через LSI и HIT для унаследованных приложений и транспортного уровня, чтобы повысить уровень совместимости с имеющимися сетевыми API и стеками протоколов.

Уровень HIP логически размещён как L3,5 между транспортным и сетевым уровнем сетевого стека и действует как «прокладка», использующая LSI или HIT, но не затрагивающая другие данные. Уровень HIP выполняет преобразование двух форм идентификаторов HIP, приходящих от транспортного уровня, в маршрутизируемые адреса IPv4 или IPv6 для сетевого уровня и обратно.

5.1. Множественное отождествление

Хост может иметь множество отождествлений как на клиентской, так и на серверной стороне. Это вызывает некоторые дополнительные проблемы, рассматриваемые в этом параграфе.

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

На стороне сервера для распределения нагрузки лучше применять DNS, нежели общее отождествление Host Identity. Можно настроить одну запись FQDN указывающую разные Host Identity. Каждую запись FQDN можно связать с соответствующими «локаторами» или общим «локатором», если серверы используют общий сервер HIP rendezvous (6.3. Механизм встречи) или ретранслятор HIP (6.4. Механизм ретрансляции).

Вместо дублирования отождествлений в HIP реализован специальный (opportunistic) режим, в котором инициатор (Initiator) не учитывает идентификатор отвечающего (Responder) при инициировании обмена ключами и узнает его по завершении обмена. Этот компромисс имеет слабые гарантии защиты, но позволяет избежать публикации HI [komu-leap]. Поскольку многие общедоступные серверы уже используют DNS в качестве каталога, такой подход может оказаться более подходящим, например, для соединений «точка-точка». Следует также отметить, что этот режим нужен на практике при использовании в качестве «локаторов» anycast-адресов IP. Этот режим может применяться вместе с серверами HIP rendezvous или ретрансляторами HIP [komu-diss]. В таких случаях инициатор передаёт сообщение I1 с шаблонным HIT адресата «локатору» сервера HIP rendezvous или ретранслятора. Когда такой сервер обслуживает множество зарегистрированных Responder, он может выбирать HIT адресата, выступая балансировщиком на основе HIP. Однако этот подход остаётся экспериментальным и требует дополнительных исследований.

На стороне клиента хост может иметь несколько Host Identity, например, из соображений приватности или при работе пользователя хоста с разными административными доменами в качестве дополнительной меры защиты. Если на пути между клиентом и сервером имеется понимающее HIP промежуточное устройство, например, межсетевой экран (МСЭ) на основе HIP, пользователю или базовой системе следует аккуратно выбирать нужное отождествление, чтобы предотвратить ненужные препятствия со стороны МСЭ на основе HIP [komu-diss].

Сервер также может иметь несколько Host Identity, например, web-сервер может обслуживать несколько административных доменов. Обычно различия реализуются на основе имени DNS, но для этого может служить и Host Identity. Однако более веской причиной использования нескольких отождествлений являются понимающие HIP МСЭ, которые не способны видеть трафик HTTP внутри шифрованных туннелей IPsec. В этом случае для каждой службы можно настроить своё отождествление, позволяя МСЭ разделять службы одного web-сервера [lindqvist-enterprise].

6. Плоскость управления

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

6.1. Базовый обмен

Базовым обменом называется процедура обмена ключами, где Initiator и Responder проверяют подлинность друг друга, используя свои открытые ключи. Обычно инициатором является клиентский хост, а отвечающим (Responder) — сервер. Роли используются конечным автоматом реализации HIP и отбрасываются по завершении.

Обмен включает 4 сообщения и создание симметричных ключей для защиты плоскости управления с помощью хэшированных кодов аутентификации сообщений (Hash-based Message Authentication Code или HMAC). Эти ключи могут также служить для защиты плоскости данных, где обычно применяется IPsec ESP [RFC7402], хотя HIP поддерживает и другие протоколы. Плоскости данных и управления удаляются с помощью процедуры закрытия, включающей 2 сообщения.

Кроме того, базовый обмен включает вычислительную задачу (puzzle) [RFC7401], которую должен решить инициатор. Отвечающий выбирает уровень сложности этой задачи, что позволяет ему задерживать запросы новых инициаторов в соответствии с локальной политикой, например, при высокой нагрузке. Задача-головоломка может обеспечивать некоторую защиту от DoS-атак, поскольку механизм позволяет отвечающему не создавать состояния (stateless) до завершений базового обмена [aura-dos]. Головоломки HIP изучались для установившихся атак DDoS [beal-dos] на множестве моделей злоумышленников с изменением сложности задачи (puzzle) [tritilanunt-dos] и эфемерными отождествлениями хостов [komu-mitigation].

6.2. Мобильные и многоадресные хосты

HIP отделяет транспортный уровень от (меж)сетевого и связывает транспортные ассоциации с отождествлением хоста (через HIT или LSI). После начального обмена ключами уровень HIP поддерживает связность на транспортном уровне и потоки данных с использованием расширений для мобильности [RFC8046] и множественных адресов [RFC8047]. Таким образом, HIP может обеспечить некоторый уровень мобильности и поддержки множественных адресов без больших затрат на инфраструктуру. Поддержка мобильности в HIP включает смену адресов IP (любым способом) у любой из сторон. Система считается мобильной, если её адрес IP может меняться динамически по любой причине, такой как переназначение префикса PPP, DHCP, IPv6 или изменение трансляции NAT. Многодомной (многоадресной) считается система, имеющая одновременно несколько глобально маршрутизируемых адресов IP. HIP связывает адреса IP, если несколько адресов соответствует одному отождествлению хоста. Если один из адресов становится не применимым или появляется более предпочтительный адрес, имеющиеся транспортные ассоциации легко переносятся на другой адрес.

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

6.3. Механизм встречи

Организация контакта с перемещающимся мобильным узлом несколько сложней. Для начала обмена HIP узлу-инициатору нужно узнать, как связаться с мобильным узлом. Например, мобильный узел может реализовать Dynamic DNS [RFC2136] для обновления сведений о своей доступности в DNS. Чтобы избежать зависимости от DNS, в HIP имеется своё решение — механизм встречи HIP rendezvous, определённый в [RFC8004].

С помощью расширений HIP rendezvous мобильный узел постоянно обновляет инфраструктуру встреч, используя текущий адрес(а) IP. Мобильные узлы доверяют механизму встречи HIP для должной поддержки сопоставления их HIT с адресом IP. Механизм встречи особенно полезен в случаях, когда предполагается возможность изменения адресов одновременно обоими партнёрами. В этом случае пакеты HIP UPDATE будут «пересекаться» в сети и не попадут к партнёру.

6.4. Механизм ретрансляции

Механизм ретрансляции HIP [RFC9028] является альтернативой HIP rendezvous и более подходит для сетей IPv4 с NAT, поскольку способен пересылать все коммуникации управления и данных для гарантированного прохождения NAT.

6.5. Завершение плоскости управления

Плоскость управления между парой хостов удаляется с использованием защищённого обмена двумя сообщениями, описанного в базовой спецификации [RFC7401]. При удалении плоскости следует удалять и связанные с ней состояния (т. е., ассоциации между хостами).

7. Плоскость данных

Формат инкапсуляции для плоскости данных, служащей для переноса трафика прикладного уровня, может согласовываться динамически в процессе обмена ключами. Например, расширения HICCUPS [RFC6078] определяют один из способов доставки дейтаграмм прикладного уровня непосредственно через плоскость управления HIP с защитой на основе асимметричных ключей. Защищённый транспорт в реальном масштабе времени (Secure Real-time Transport Protocol или SRTP) также рассматривался в качестве протокола инкапсуляции данных [hip-srtp]. Однако более широкое распространение получил метод инкапсуляции защищённых данных (Encapsulated Security Payload или ESP) [RFC7402], использующий симметричные ключи, выведенные в процессе обмена ключами. Защищённые связи ESP (Security Association или SA) обеспечивают защиту конфиденциальности и целостности, причём первую можно отключить в процессе обмена ключами. В будущем могут быть определены иные способы доставки данных прикладного уровня.

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

В линии разница при использовании идентификаторов между плоскостями управления и данных HIP состоит в том, что теги HIT включаются во все пакеты управления, но не включаются в пакеты данных при использовании ESP. Вместо этого применяются индексы параметров защиты ESP (Security Parameter Index или SPI), которые действуют как сжатые HIT. Любым промежуточным устройствам с поддержкой HIP (например, HIP МСЭ), заинтересованным в трафике данных на основе ESP, нужно отслеживать идентификаторы плоскостей данных и управления, чтобы связать их между собой.

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

8. HIP и NAT

Передача пакетов между разными областями адресации IP требует изменения адресов в заголовках пакетов IP. Это может происходить, например, при передаче пакета между Internet и приватным пространством адресов или между сетями IPv4 и IPv6. Трансляция адресов обычно обеспечивается устройствами NAT (Network Address Translation) [RFC3022] или NAT-PT (NAT Protocol Translation) [RFC2766].

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

Расширения для прохождения NAT в протоколе HIP [RFC9028] могут служить для организации сквозной связности через устройства NAT. Для поддержки базовой совместимости с унаследованными устройствами NAT расширения инкапсулируют плоскости управления и данных HIP в протокол UDP. Расширения определяют механизмы для пересылки двух плоскостей через промежуточный хост, называемый ретранслятором HIP (relay) и процедуры для организации прямой сквозной связности через NAT. Поскольку это «естественный» режим прохождения через NAT для HIP, можно использовать и другие механизмы работы через NAT, например, Teredo [RFC4380] (см. [varjonen-split]).

Помимо традиционных NAT была разработана и реализована система NAT с поддержкой протокола HIP [ylitalo-spinat]. Для потоков на основе HIP поддерживающий HIP транслятор NAT или NAT-PT отслеживает сопоставления HIT и соответствующих ESP SPI с адресами IP. Система NAT узнает сопоставления HIT и SPI с адресами IP. Множество HIT (и SPI) может отображаться на один адрес IP в системе NAT, что упрощает соединения на интерфейсах NAT с недостаточным числом адресов. NAT может получать большую часть сведений из самих пакетов HIP, однако может потребоваться некоторая настройка конфигурации NAT.

8.1. HIP и контрольная сумма вышележащего уровня

Хост не может узнать, применялись ли адреса из заголовка IP при расчёте контрольной суммы TCP, т. е. невозможно рассчитать корректную контрольную сумму TCP, используя фактические адреса IP из псевдозаголовка, поскольку адрес в принятом пакете может отличаться от указанного передающим хостом. Кроме того, невозможно пересчитать контрольную сумму вышележащего уровня в системах NAT/NAT-PT, поскольку трафик защищён ESP. Поэтому контрольные суммы TCP и UDP рассчитываются с использованием HIT вместо адресов IP в псевдозаголовке. Используется лишь формат псевдозаголовков IPv6. Это обеспечивает трансляцию протоколов IPv4 и IPv6.

9. Групповая адресация

Был опубликован ряд исследований групповой адресации на основе HIP, включая [shields-hip], [zhu-hip], [amir-hip], [kovacshazi-host], [zhu-secure]. В частности, так называемые фильтры Блума, позволяющие сжимать несколько меток в небольшие структуры данных, могут быть многообещающим шагом вперёд [sarela-bloom]. Однако разные схемы не были приняты рабочей группой HIP (и исследовательской группой HIP в IRTF), поэтому детали здесь не приведены.

10. Правила HIP

Каждый хост должен поддерживать множество переменных, влияющих на обмен HIP. Всем реализациям HIP следует поддерживать по меньшей мере 2 HI, один из которых публикуется в DNS или иной службе каталогов, а второй не публикуется и служит для анонимного использования (предполагается его частая смена для предотвращения сопоставлений и отслеживания). Хотя неопубликованные HI редко применяются в качестве Responder HI, их часто используют инициаторы. Как указано в [RFC7401], «все реализации HIP должны поддерживать одновременно более одного HI, и по меньшей мере один идентификатор следует резервировать для анонимного использования» и «рекомендуется поддерживать более двух HI». Это ставит перед системами и пользователями вопрос выбора HI, раскрываемого при организации новой сессии.

Специальный (Opportunistic) режим, где инициатор начинает обмен HIP, не зная Responder HI, является компромиссом в части безопасности. Этот режим позволяет инициатору узнать отождествление отвечающего в процессе взаимодействия, а не из внешнего каталога, но это делает его уязвимым для MitM-атак. Этот режим можно применять для регистрации основанных на HIP служб [RFC8003] (т. е. использующих HIP для внутренних целей) или на уровне приложений [komu-leap]. Соображения безопасности, особенно во втором случае, требуют вовлечения пользователя в решение вопроса о восприятии отождествления отвечающего, подобно приглашению в протоколе SSH (Secure Shell) при первом подключении к серверу [pham-leap]. На практике этом может быть реализовано в МСЭ на конечных хостах в случае унаследованных приложений [karvonen-usable] или в естественных API для HIP [RFC6317] в приложениях с поддержкой HIP.

В [RFC7401] сказано: «Инициаторы могут использовать разные HI для разных отвечающих, чтобы обеспечить базовую приватность. Применение таких приватных HI повторно для одного отвечающего и срок действия HI определяется локальными правилами и зависит от требований приватности инициатора». Согласно [RFC7401]: «Responder, отвечающий лишь выбранным инициаторам, требует наличия списка управления доступом (Access Control List или ACL), представляющего хосты, от которых он воспринимает базовый обмен HIP, предпочтительный формат транспорта и локальные сроки действия. Следует поддерживать шаблонные записи в таких ACL, а также для отвечающих, которые предоставляют общедоступные или анонимные услуги.

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

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

11.1. MitM-атаки

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

DoS-атаки с истощением ресурсов используют «дороговизну» установки состояния протокола на отвечающей стороне по сравнению с «дешевизной» у инициатора. HIP позволяет отвечающему повысить стоимость запуска состояния на стороне инициатора и пытается снизить расходы отвечающего. Это делается за счёт запуска обмена Diffie-Hellman отвечающим вместо инициатора, что ведёт к базовому обмену HIP из 4 пакетов. Первый пакет, отправленный отвечающим, может быть создан заранее для дополнительного снижения затрат. Этот пакет также включает вычислительную задачу (puzzle), которая может служить для дополнительной задержки инициатора, например, при перегрузке отвечающего. Детали процесса приведены в спецификации базового обмена [RFC7401].

Защититься от MitM-атак сложно без сторонней аутентификации. Опытный атакующий может легко обработать все части базового обмена HIP, но протокол HIP опосредованно обеспечивает дополнительную защиту от MitM-атак. Если значение Responder HI получено из подписанной зоны DNS или иным защищённым способом, инициатор может применить это для аутентификации подписанных пакетов HIP. Если Initiator HI хранится в защищённой зоне DNS, отвечающий может найти идентификатор и проверить подписанные пакеты HIP. Однако инициатор может применять неопубликованный HI, осознанно принимая риск MitM-атаки. Responder может отказаться воспринимать обмен HIP с инициаторами, использующими неизвестный идентификатор HI.

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

В MitM-атаке может быть предпринята попытка использования старых сообщений I1 или R1 с более слабыми криптографическими алгоритмами, как указано в параграфе 4.1.4 [RFC7401]. Базовый обмен был усилен для борьбы с такими атаками путём перезапуска при обнаружении атаки. В худшем случае это приведёт лишь к бесконечному повтору базового обмена или его прерыванию после некоторого числа попыток. Недостатком этого является 6-этапный базовый обмен, который может показаться неудачным решением. Однако такое возможно лишь при атаке, которая может быть обработана (чтобы повторять её не было смысла), поэтому предполагается, что последующие сообщения не представляют угрозы безопасности. Поскольку MitM-атаки не позволяют снизить версию, их можно считать лишь помехой. Таким образом, базовый обмен будет включать обычно лишь 4 пакета даже при готовности реализации к защите от понижения версии.

В протоколе HIP защищённые связи SA для ESP индексируются по SPI, адрес отправителя всегда игнорируется, а адрес получателя также можно проигнорировать. Поэтому при включённом HIP работа ESP не зависит от адресов IP. Это может показаться упрощением для организации атак, но ESP с защитой от повторного использования (replay) уже обеспечивает высокий уровень безопасности и удаление адреса IP из проверки не увеличивает раскрытие ESP для DoS-атак.

11.2. Защита от лавинных атак

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

Восприятие новых адресов вслепую (без проверки) открывает возможность для организации лавинных DoS-атак против третьей стороны [RFC4225]. В распределенной лавинной атаке злоумышленник может создать соединения HIP с большим объёмом трафика и множеством хостов (неопубликованные HI) а затем объявить всем этим хостам о своём переходе на другой адрес IP. Если партнерские хосты будут просто воспринимать такой перенос, жертва с указанным адресом может получить лавину пакетов. Для предотвращения таких атак расширения HIP mobility включают процедуру проверки маршрута по обратному пути, где доступность узла проверяется независимо для каждого адреса до отправки по этому адресу большего объёма трафика.

До завершения проверки адреса для передачи данных между хостами можно воспользоваться основанном на кредите подходе «Host Mobility with the Host Identity Protocol» [RFC8046]. При использовании HIP между доверяющими один другому хостами можно отказаться от проверки адресов, однако такое решение следует принимать лишь в случаях, когда узлы заведомо заслуживают доверия и способны защитить себя от вредоносных программ.

11.3. Применение HIT в ACL

На конечных точках теги HIT могут применяться в списках контроля доступа на основе IP для прикладного или сетевого уровня. На промежуточных устройствах понимающие HIP МСЭ [lindqvist-enterprise] могут использовать HIT или открытые ключи для входного или выходного контроля на уровне сети или отдельных хостов даже в присутствии мобильных устройств, поскольку теги HIT и открытые ключи не связаны с топологией. Как отмечено в разделе 7, после организации сессии HIP значение SPI в пакете ESP может служить индексом, указывающим HIT. На практике МСЭ могут проверять пакеты HIP для изучения привязок между HIT, SPI и адресами IP. Можно даже явно контролировать использование ESP, динамически открывая ESP лишь для конкретных SPI и адресов IP. Подписи в пакетах HIP позволяют соответствующему МСЭ гарантировать, что обмен HIP действительно происходит между двумя известными хостами. Это может повысить уровень безопасности МСЭ.

Возможным недостатком HIT в ACL является их «плоская» природа, не позволяющая агрегировать теги, что может приводить к большому размеру таблиц поиска в МСЭ с поддержкой HIP. Способом оптимизации может служить применение фильтров Блума (Bloom) для группировки HIT [sarela-bloom]. Однако следует отметить, что правила для отдельных HIT, а не групп позволяют легко исключить хосты с некорректным поведением, не затрагивая других.

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

Хост может отслеживать всех своих партнёров, которые могут применять его HIT в ACL, регистрируя все удалённые HIT достаточно регистрировать отвечающие хосты). На основе этой информации хост может уведомить другие хосты о смене HIT. Были попытки разработать защищённый метод выдачи уведомлений об отзыве HIT [zhang-revocation].

Некоторые промежуточные устройства с поддержкой HIP, такие как МСЭ [lindqvist-enterprise] или NAT [ylitalo-spinat], могут пассивно просматривать трафик в пути. Такие устройства по своей природе прозрачны и не могут получать уведомлений о переходе хоста в другую сеть. В результате от таких устройств требуется поддержка состояния и тайм-аутов для слишком долгого простоя плоскостей управления и данных между парой конечных хостов HIP. Соответственно, два конечных хоста могут периодически передавать пакеты сохранения (keepalive), такие как UPDATE или сообщения ICMP в туннеле ESP, для поддержки статуса в промежуточном устройстве.

Одним из общих ограничений для сквозного шифрования является неспособность промежуточных устройств участвовать в защите потоков данных. Хотя эта проблема может влиять и на другие протоколы, Heer и др. [heer-end-host] проанализировали её в контексте HIP. В частности, при использовании ESP в качестве протокола плоскости данных для HIP связь между плоскостями данных и управления слаба и может использоваться при некоторых допущениях. Предположим, что злоумышленник получил доступ к целевой сети, защищённой МСЭ с поддержкой HIP, но хочет обойти HIP МСЭ. Для этого атакующий пассивно наблюдает базовый обмен между двумя хостами HIP, а затем воспроизводит его. Таким образом злоумышленнику удаётся преодолеть МСЭ и он может использовать туннель ESP для доставки своих данных. Эта возможность обусловлена тем, что МСЭ не может проверить действительность туннеля ESP. Для решения проблемы промежуточные устройства с поддержкой HIP могут участвовать во взаимодействии с плоскостью управления путём добавления в трафик управления одноразовых параметров (nonce), которые конечные хосты должны подписывать для обеспечения свежести трафика управления [heer-midauth]. Как вариант можно использовать расширения для доставки трафика плоскости данных напрямую через плоскость управления [RFC6078].

11.4. Варианты для HI

В определении идентификатора хоста сказано, что HI не обязательно является открытым ключом. Это означает, что HI может быть любым значением, например, FQDN. Этот документ не описывает поддержку некриптографических HI, но примеры таких вариантов протокола имеются ([urien-rfid], [urien-rfid-draft]). Некриптографические HI по-прежнему будут предоставлять услуги HIT или LSI для прохождения через NAT. Можно переносить теги HIT в пакетах HIP без защиты приватности и конфиденциальности. Такие схемы могут быть пригодны для устройств с ограниченными ресурсами, таких как небольшие датчики с батарейным питанием, но здесь подобные устройства не рассматриваются.

Если желательно использовать HIP в ситуации с низким уровнем защиты, где расчёт открытых ключей считается избыточным, HIP можно применять с очень короткими ключами Diffie-Hellman и Host Identity. Это делает участвующие хосты уязвимыми для MitM-атак и захвата соединений, однако не вызывает опасности лавинных атак, поскольку механизм проверки адресов полагается на систему маршрутизации, а не криптостойкость.

11.5. Доверие при первом применении

В [RFC7435] выделено 4 принципа разработки для принятия на веру (Leap of Faith) или доверия при первом использовании (Trust On First Use или TOFU) для протоколов, применимые также к opportunistic HIP.

  1. Сосуществование с явной политикой.

  2. Приоритизация коммуникаций.

  3. Максимальная защита партнёров.

  4. Отсутствие ложного представления о безопасности.

Согласно первому принципу TOFU: «Защита с использованием обстоятельств (Opportunistic security) никогда не заменит и не вытеснит явные правила.» некоторые данные приложений могут быть слишком конфиденциальными (sensitive), поэтому соответствующая политика может требовать проверки подлинности (т. е. открытого ключа или сертификата) вместо защиты по обстоятельствам без аутентификации. На практике это реализовано в HIP в соответствии с [RFC6538].

OpenHIP позволяет инициатору применять режим Opportunistic лишь с явно заданным IP-адресом отвечающего, когда Responder HIT неизвестен. У отвечающего реализация OpenHIP позволяет включить режим Opportunistic для любого инициатора (доверие к любому инициатору).

Разработчики HIP for Linux (HIPL) экспериментировали с более детализированными правилами на уровне приложения. Реализация HIPL использует так называемую ловушку LD_PRELOAD на уровне приложения, которая позволяет динамически подключаемой библиотеке перехватывать связанные с сокетом вызовы без пересборки соответствующих двоичных файлов приложения. Библиотека выступает промежуточным уровнем между приложениям и транспортом, транслируя не связанные с HIP вызовы сокета из приложения в вызовы на основе HIP. Хотя такая библиотека вносит определённые сложности, описанные в [komu-leap], она достигает цели применения режима Opportunistic на уровне детализации отдельных приложений.

Второй принцип TOFU по сути провозглашает приоритет коммуникаций над безопасностью. Поэтому в общем случае режим Opportunistic следует разрешать даже при отсутствии аутентификации и возможности отката к нешифрованной связи (если правила позволяют) вместо блокировки. На практике это можно реализовать в три этапа. Сначала инициатор HIP может выполнить поиск Responder HI в каталоге (например, DNS). При нахождении инициатором HI он может применить идентификатор для аутентификации и пропустить следующие шаги. При отказе в поиске HI инициатор может попробовать режим Opportunistic с отвечающим. На третьем шаге инициатор может отказаться от коммуникаций на базе HIP после отказа режима Opportunistic, если политика разрешает это. Эта трехступенчатая модель была реализована и описана более подробно в [komu-leap].

Третий принцип TOFU предлагает максимизировать защиту для использования по меньшей мере защиты по обстоятельствам (opportunistic security). Описанная выше трехэтапная модель предпочитает по возможности применять аутентификацию, например, через записи DNS (а при доступности — через DNSSEC) и возвращается в режим Opportunistic при недоступности свидетельств по отдельному каналу (out-of-band credentials). В крайнем случае может происходить отказ от коммуникаций на основе HIP, если правила разрешают это. Поскольку в третьем принципе явно упоминается совершенная защита (perfect forward secrecy или PFS), следует упомянуть её поддержку в HIP.

Четвёртый принцип TOFU гласит, что пользователей и неинтерактивные приложения следует должным образом информировать о применяемом уровне защиты. На практике не поддерживающие HIP приложения будут предполагать отсутствие дополнительной защиты, поэтому ложное представление, по крайней мере у неинтерактивных приложений, возникать не должно. В случае интерактивных desktop-приложений в ранних экспериментах с HIP [karvonen-usable] [RFC6538] использовались приглашения системного уровня для выбора пользователем базовой защиты на основе HIP. Обычно в этих экспериментах пользователи понимали, когда применяется защита на основе HIP. Однако пользователи не замечали разницы между Opportunistic HIP без аутентификации и HIP с аутентификацией но без режима Opportunistic. Причина заключалась в том, что режим Opportunistic HIP (пониженный уровень защиты) не был чётко указан в системном приложении. Это стало уроком в части улучшения пользовательского интерфейса.

В случае понимающих HIP приложений можно использовать естественные API сокетов для HIP, описанные в [RFC6317], для разработки зависящей от приложения логики вместо базового системного приглашения. Здесь приложение само может спросить пользователя или иным способом управлять ситуацией. В этом случае неинтерактивные приложения также могут должным образом осознать уровень защиты, поскольку разработчик может явно задать использование HIP с аутентификацией, Opportunistic HIP или обмен открытыми данными (plain-text).

Следует упомянуть несколько дополнительных пунктов, отмеченных в [RFC7435]. Для активных атак в HIP имеется встроенная защита против понижения версии шифра, как описано в [RFC7401]. Кроме того, могут применяться заранее установленные сертификаты для ослабления атак в случае режима Opportunistic, как отмечено в [RFC6538].

Обнаружение возможностей партнёра также упоминается в контексте TOFU и для этого может применяться трехэтапная модель, отмеченная выше. Хост может выполнить первый этап аутентификации, т. е. обнаружить открытый ключ, например, через DNS. Если хост не находит ключей, он может в качестве второго шага проверить режим Opportunistic. При возникновении тайм-аута хост может перейти к третьему шагу, возвращаясь к взаимодействию без HIP, если политика разрешает это. Последний этап основан на неявном тайм-ауте вместо явного (негативного) подтверждения как в случае DNS, поэтому пользователь может сделать вывод об отказе преждевременно. Для ускорения фазы обнаружения путём явной проверки, поддерживает ли партнёр режим Opportunistic HIP, исследователи предложили расширения для TCP [RFC6538] [komu-leap]. Инициатор передаёт партнёру одновременно пакет (opportunistic) I1 и соответствующую дейтаграмму TCP SYN со специальной опцией TCP. Если партнёр поддерживает HIP, он отбросит пакет SYN и ответит пакетом R1. Если же партнёр не понимает HIP, он отбросит пакет HIP (и неизвестную опцию TCP) и передаст в ответ TCP SYN-ACK. Преимуществом предложенной схемы является быстрый отказ от попытки взаимодействия на основе HIP за один период кругового обхода. Недостаток заключается в привязке к TCP (опции IP также рассматривались, но они плохо работают через МСЭ и NAT). Такой подход не работает против активных атак, но режим Opportunistic в любом случае не предназначен для этого.

Следует отметить, что, несмотря на некоторые преимущества режима Opportunistic, связанные с постепенным развёртыванием, он уступает HIP с аутентификацией [komu-diss], поскольку тот поддерживает постоянные идентификаторы (хост указывается одним HI независимо от перемещений). Opportunistic HIP решает эту задачу лишь частично — после первого контакта между хостами HIP может поддерживать соединение с помощью расширений для мобильности, но возникают проблемы, когда хосты разрывают ассоциацию HIP и пытаются связаться снова. Хост может сменить своё местоположение и нет гарантии привязки адреса IP к хосту, поскольку один адрес может временно выделяться разным хостам (например, сервером DHCP), области адресации могут перекрываться (см. Приложение A.1) или из-за попытки организации атаки.

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

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

13. Отличия от RFC 4423

Отличия от RFC 4423 [RFC4423] являются в основном редакторскими правками, включая разъяснения сложно описанных тем и исключение не относящихся к архитектуре деталей, уже описанных в других документах. Добавлен ряд пропущенных. Включено рассмотрение недостатков HIP, а также безопасности 802.15.4 и MAC, вариантов HIP для IoT, вопросов развёртывания и описание базового обмена.

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

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

[RFC5482] Eggert, L. and F. Gont, «TCP User Timeout Option», RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.

[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, «HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)», RFC 6079, DOI 10.17487/RFC6079, January 2011, <https://www.rfc-editor.org/info/rfc6079>.

[RFC7086] Keranen, A., Camarillo, G., and J. Maenpaa, «Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)», RFC 7086, DOI 10.17487/RFC7086, January 2014, <https://www.rfc-editor.org/info/rfc7086>.

[RFC7343] Laganier, J. and F. Dupont, «An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)», RFC 7343, DOI 10.17487/RFC7343, September 2014, <https://www.rfc-editor.org/info/rfc7343>.

[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, «Host Identity Protocol Version 2 (HIPv2)», RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.

[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, «Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)», RFC 7402, DOI 10.17487/RFC7402, April 2015, <https://www.rfc-editor.org/info/rfc7402>.

[RFC8002] Heer, T. and S. Varjonen, «Host Identity Protocol Certificates», RFC 8002, DOI 10.17487/RFC8002, October 2016, <https://www.rfc-editor.org/info/rfc8002>.

[RFC8003] Laganier, J. and L. Eggert, «Host Identity Protocol (HIP) Registration Extension», RFC 8003, DOI 10.17487/RFC8003, October 2016, <https://www.rfc-editor.org/info/rfc8003>.

[RFC8004] Laganier, J. and L. Eggert, «Host Identity Protocol (HIP) Rendezvous Extension», RFC 8004, DOI 10.17487/RFC8004, October 2016, <https://www.rfc-editor.org/info/rfc8004>.

[RFC8005] Laganier, J., «Host Identity Protocol (HIP) Domain Name System (DNS) Extension», RFC 8005, DOI 10.17487/RFC8005, October 2016, <https://www.rfc-editor.org/info/rfc8005>.

[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, «Host Mobility with the Host Identity Protocol», RFC 8046, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-editor.org/info/rfc8046>.

[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, «Host Multihoming with the Host Identity Protocol», RFC 8047, DOI 10.17487/RFC8047, February 2017, <https://www.rfc-editor.org/info/rfc8047>.

[RFC9028] Keränen, A., Melén, J., and M. Komu, Ed., «Native NAT Traversal Mode for the Host Identity Protocol», RFC 9028, DOI 10.17487/RFC9028, July 2021, <https://www.rfc-editor.org/info/rfc9028>.

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

[amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Pulkkis, «Security and Trust of Public Key Cryptography for HIP and HIP Multicast», International Journal of Dependable and Trustworthy Information Systems (IJDTIS), Vol. 2, Issue 3, pp. 17-35, DOI 10.4018/jdtis.2011070102, 2013, <https://doi.org/10.4018/jdtis.2011070102>.

[aura-dos] Aura, T., Nikander, P., and J. Leiwo, «DOS-Resistant Authentication with Client Puzzles», 8th International Workshop on Security Protocols, Security Protocols 2000, Lecture Notes in Computer Science, Vol. 2133, pp. 170-177, Springer, DOI 10.1007/3-540-44810-1_22, September 2001, <https://doi.org/10.1007/3-540-44810-1_22>.

[beal-dos] Beal, J. and T. Shepard, «Deamplification of DoS Attacks via Puzzles», October 2004.

[camarillo-p2psip] Camarillo, G., Mäenpää, J., Keränen, A., and V. Anderson, «Reducing delays related to NAT traversal in P2PSIP session establishments», IEEE Consumer Communications and Networking Conference (CCNC), pp. 549-553, DOI 10.1109/CCNC.2011.5766540, 2011, <https://doi.org/10.1109/CCNC.2011.5766540>.

[chiappa-endpoints] Chiappa, J., «Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture», 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

[heer-end-host] Heer, T., Hummen, R., Komu, M., Gotz, S., and K. Wehrle, «End-Host Authentication and Authorization for Middleboxes Based on a Cryptographic Namespace», 2009 IEEE International Conference on Communications, DOI 10.1109/ICC.2009.5198984, 2009, <https://doi.org/10.1109/ICC.2009.5198984>.

[heer-midauth] Heer, T., Ed., Hummen, R., Wehrle, K., and M. Komu, «End-Host Authentication for HIP Middleboxes», Work in Progress, Internet-Draft, draft-heer-hip-middle-auth-04, 31 October 2011, <https://datatracker.ietf.org/doc/html/draft-heer-hip-middle-auth-04>.

[henderson-vpls] Henderson, T. R., Venema, S. C., and D. Mattes, «HIP-based Virtual Private LAN Service (HIPLS)», Work in Progress, Internet-Draft, draft-henderson-hip-vpls-11, 3 August 2016, <https://datatracker.ietf.org/doc/html/draft-henderson-hip-vpls-11>.

[hip-dex] Moskowitz, R., Ed., Hummen, R., and M. Komu, «HIP Diet EXchange (DEX)», Work in Progress, Internet-Draft, draft-ietf-hip-dex-24, 19 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex-24>.

[hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov, «Novel secure VPN architectures for LTE backhaul networks», Security and Communication Networks, Vol. 9, pp. 1198-1215, DOI 10.1002/sec.1411, January 2016, <https://doi.org/10.1002/sec.1411>.

[hip-srtp] Tschofenig, H., Shanmugam, M., and F. Muenz, «Using SRTP transport format with HIP», Work in Progress, Internet-Draft, draft-tschofenig-hiprg-hip-srtp-02, 25 October 2006, <https://datatracker.ietf.org/doc/html/draft-tschofenig-hiprg-hip-srtp-02>.

[hummen] Hummen, R., Hiller, J., Henze, M., and K. Wehrle, «Slimfit — A HIP DEX compression layer for the IP-based Internet of Things», 2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), pp. 259-266, DOI 10.1109/WiMOB.2013.6673370, October 2013, <https://doi.org/10.1109/WiMOB.2013.6673370>.

[IEEE.802.15.4] IEEE, «IEEE Standard for Low-Rate Wireless Networks», IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2020.9144691, July 2020, <https://ieeexplore.ieee.org/document/9144691>.

[IEEE.802.15.9] IEEE, «IEEE Draft Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams», IEEE P802.15.9/D04, May 2015.

[karvonen-usable] Karvonen, K., Komu, M., and A. Gurtov, «Usable security management with host identity protocol», 2009 IEEE/ACS International Conference on Computer Systems and Applications, pp. 279-286, DOI 10.1109/AICCSA.2009.5069337, 2009, <https://doi.org/10.1109/AICCSA.2009.5069337>.

[komu-cloud] Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan, R., and S. Tarkoma, «Secure Networking for Virtual Machines in the Cloud», 2012 IEEE International Conference on Cluster Computing Workshops, pp. 88-96, DOI 10.1109/ClusterW.2012.29, 2012, <https://doi.org/10.1109/ClusterW.2012.29>.

[komu-diss] Komu, M., «A Consolidated Namespace for Network Applications, Developers, Administrators and Users», Dissertation, Aalto University, Espoo, Finland, ISBN 978-952-60-4904-5 (printed), ISBN 978-952-60-4905-2 (electronic), December 2012.

[komu-leap] Komu, M. and J. Lindqvist, «Leap-of-Faith Security is Enough for IP Mobility», 2009 6th IEEE Consumer Communications and Networking Conference, Las Vegas, NV, USA, pp. 1-5, DOI 10.1109/CCNC.2009.4784729, January 2009, <https://doi.org/10.1109/CCNC.2009.4784729>.

[komu-mitigation] Komu, M., Tarkoma, S., and A. Lukyanenko, «Mitigation of Unsolicited Traffic Across Domains with Host Identities and Puzzles», 15th Nordic Conference on Secure IT Systems, NordSec 2010, Lecture Notes in Computer Science, Vol. 7127, pp. 33-48, Springer, ISBN 978-3-642-27936-2, DOI 10.1007/978-3-642-27937-9_3, October 2010, <https://doi.org/10.1007/978-3-642-27937-9_3>.

[kovacshazi-host] Kovacshazi, Z. and R. Vida, «Host Identity Specific Multicast», International Conference on Networking and Services (ICNS ’07), Athens, Greece, pp. 1-1, DOI 10.1109/ICNS.2007.66, 2007, <https://doi.org/10.1109/ICNS.2007.66>.

[levae-barriers] Levä, T., Komu, M., and S. Luukkainen, «Adoption barriers of network layer protocols: the case of host identity protocol», Computer Networks, Vol. 57, Issue 10, pp. 2218-2232, ISSN 1389-1286, DOI 10.1016/j.comnet.2012.11.024, March 2013, <https://doi.org/10.1016/j.comnet.2012.11.024>.

[lindqvist-enterprise] Lindqvist, J., Vehmersalo, E., Komu, M., and J. Manner, «Enterprise Network Packet Filtering for Mobile Cryptographic Identities», International Journal of Handheld Computing Research (IJHCR), Vol. 1, Issue 1, pp. 79-94, DOI 10.4018/jhcr.2010090905, 2010, <https://doi.org/10.4018/jhcr.2010090905>.

[Nik2001] Nikander, P., «Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World», 9th International Workshop on Security Protocols, Security Protocols 2001, Lecture Notes in Computer Science, Vol. 2467, pp. 12-21, Springer, DOI 10.1007/3-540-45807-7_3, 2002, <https://doi.org/10.1007/3-540-45807-7_3>.

[nsrg-report] Lear, E. and R. Droms, «What’s In A Name: Thoughts from the NSRG», Work in Progress, Internet-Draft, draft-irtf-nsrg-report-10, 22 September 2003, <https://datatracker.ietf.org/doc/html/draft-irtf-nsrg-report-10>.

[paine-hip] Paine, R. H., «Beyond HIP: The End to Hacking As We Know It», BookSurge Publishing, ISBN-10 1439256047, ISBN-13 978-1439256046, 2009.

[pham-leap] Pham, V. and T. Aura, «Security Analysis of Leap-of-Faith Protocols», 7th International ICST Conference, Security and Privacy for Communication Networks, SecureComm 2011, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Vol. 96, DOI 10.1007/978-3-642-31909-9_19, 2012, <https://doi.org/10.1007/978-3-642-31909-9_19>.

[ranjbar-synaptic] Ranjbar, A., Komu, M., Salmela, P., and T. Aura, «SynAPTIC: Secure and Persistent Connectivity for Containers», 2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), Madrid, 2017, pp. 262-267, DOI 10.1109/CCGRID.2017.62, 2017, <https://doi.org/10.1109/CCGRID.2017.62>.

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

[RFC2766] Tsirtsis, G. and P. Srisuresh, «Network Address Translation — Protocol Translation (NAT-PT)», RFC 2766, DOI 10.17487/RFC2766, February 2000, <https://www.rfc-editor.org/info/rfc2766>.

[RFC3022] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.

[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, «Realm Specific IP: Framework», RFC 3102, DOI 10.17487/RFC3102, October 2001, <https://www.rfc-editor.org/info/rfc3102>.

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

[RFC3972] Aura, T., «Cryptographically Generated Addresses (CGA)», RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.

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

[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, «Mobile IP Version 6 Route Optimization Security Design Background», RFC 4225, DOI 10.17487/RFC4225, December 2005, <https://www.rfc-editor.org/info/rfc4225>.

[RFC4380] Huitema, C., «Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)», RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.

[RFC4423] Moskowitz, R. and P. Nikander, «Host Identity Protocol (HIP) Architecture», RFC 4423, DOI 10.17487/RFC4423, May 2006, <https://www.rfc-editor.org/info/rfc4423>.

[RFC5218] Thaler, D. and B. Aboba, «What Makes for a Successful Protocol?», RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.

[RFC5338] Henderson, T., Nikander, P., and M. Komu, «Using the Host Identity Protocol with Legacy Applications», RFC 5338, DOI 10.17487/RFC5338, September 2008, <https://www.rfc-editor.org/info/rfc5338>.

[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, «Renumbering Still Needs Work», RFC 5887, DOI 10.17487/RFC5887, May 2010, <https://www.rfc-editor.org/info/rfc5887>.

[RFC6078] Camarillo, G. and J. Melen, «Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)», RFC 6078, DOI 10.17487/RFC6078, January 2011, <https://www.rfc-editor.org/info/rfc6078>.

[RFC6250] Thaler, D., «Evolution of the IP Model», RFC 6250, DOI 10.17487/RFC6250, May 2011, <https://www.rfc-editor.org/info/rfc6250>.

[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, «Understanding Apple’s Back to My Mac (BTMM) Service», RFC 6281, DOI 10.17487/RFC6281, June 2011, <https://www.rfc-editor.org/info/rfc6281>.

[RFC6317] Komu, M. and T. Henderson, «Basic Socket Interface Extensions for the Host Identity Protocol (HIP)», RFC 6317, DOI 10.17487/RFC6317, July 2011, <https://www.rfc-editor.org/info/rfc6317>.

[RFC6537] Ahrenholz, J., «Host Identity Protocol Distributed Hash Table Interface», RFC 6537, DOI 10.17487/RFC6537, February 2012, <https://www.rfc-editor.org/info/rfc6537>.

[RFC6538] Henderson, T. and A. Gurtov, «The Host Identity Protocol (HIP) Experiment Report», RFC 6538, DOI 10.17487/RFC6538, March 2012, <https://www.rfc-editor.org/info/rfc6538>.

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

[RFC7435] Dukhovni, V., «Opportunistic Security: Some Protection Most of the Time», RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.

[sarela-bloom] Särelä, M., Esteve Rothenberg, C., Zahemszky, A., Nikander, P., and J. Ott, «BloomCasting: Security in Bloom Filter Based Multicast», Information Security Technology for Applications, NordSec 2010, Lecture Notes in Computer Science, Vol. 7127, pages 1-16, Springer, DOI 10.1007/978-3-642-27937-9_1, 2012, <https://doi.org/10.1007/978-3-642-27937-9_1>.

[schuetz-intermittent] Schütz, S., Eggert, L., Schmid, S., and M. Brunner, «Protocol enhancements for intermittently connected hosts», ACM SIGCOMM Computer Communication Review, Vol. 35, Issue 3, pp. 5-18, DOI 10.1145/1070873.1070875, July 2005, <https://doi.org/10.1145/1070873.1070875>.

[shields-hip] Shields, C. and J. J. Garcia-Luna-Aceves, «The HIP protocol for hierarchical multicast routing», Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, pp. 257-266, ISBN 0-89791-977-7, DOI 10.1145/277697.277744, 1998, <https://doi.org/10.1145/277697.277744>.

[tempered-networks] Tempered Networks, «Identity-Defined Network (IDN) Architecture: Unified, Secure Networking Made Simple», White Paper, 2016.

[tritilanunt-dos] Tritilanunt, S., Boyd, C., Foo, E., and J.M.G. Nieto, «Examining the DoS Resistance of HIP», On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Lecture Notes in Computer Science, Vol. 4277, pp. 616-625, Springer, DOI 10.1007/11915034_85, 2006, <https://doi.org/10.1007/11915034_85>.

[urien-rfid] Urien, P., Chabanne, H., Pepin, C., Orga, S., Bouet, M., de Cunha, D.O., Guyot, V., Pujolle, G., Paradinas, P., Gressier, E., and J.-F. Susini, «HIP-based RFID Networking Architecture», 2007 IFIP International Conference on Wireless and Optical Communications Networks, pp. 1-5, DOI 10.1109/WOCN.2007.4284140, 2007, <https://doi.org/10.1109/WOCN.2007.4284140>.

[urien-rfid-draft] Urien, P., Lee, G. M., and G. Pujolle, «HIP support for RFIDs», Work in Progress, Internet-Draft, draft-irtf-hiprg-rfid-07, 23 April 2013, <https://datatracker.ietf.org/doc/html/draft-irtf-hiprg-rfid-07>.

[varjonen-split] Varjonen, S., Komu, M., and A. Gurtov, «Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-Location Split», Journal of Communications Software and Systems, Vol. 6, Issue 1, ISSN 18456421, DOI 10.24138/jcomss.v6i1.193, 2010, <https://doi.org/10.24138/jcomss.v6i1.193>.

[xin-hip-lib] Xin, G., «Host Identity Protocol Version 2.5», Master’s Thesis, Aalto University, Espoo, Finland, June 2012.

[ylitalo-diss] Ylitalo, J., «Secure Mobility at Multiple Granularity Levels over Heterogeneous Datacom Networks», Dissertation, Helsinki University of Technology, Espoo, Finland, ISBN 978-951-22-9531-9, 2008.

[ylitalo-spinat] Ylitalo, J., Salmela, P., and H. Tschofenig, «SPINAT: Integrating IPsec into Overlay Routing», First International Conference on Security and Privacy for Emerging Areas in Communication Networks, SECURECOMM’05, Athens, Greece, pp. 315-326, ISBN 0-7695-2369-2, DOI 10.1109/SECURECOMM.2005.53, 2005, <https://doi.org/10.1109/SECURECOMM.2005.53>.

[zhang-revocation] Zhang, D., Kuptsov, D., and S. Shen, «Host Identifier Revocation in HIP», Work in Progress, Internet-Draft, draft-irtf-hiprg-revocation-05, 9 March 2012, <https://datatracker.ietf.org/doc/html/draft-irtf-hiprg-revocation-05>.

[zhu-hip] Zhu, X., Ding, Z., and X. Wang, «A Multicast Routing Algorithm Applied to HIP-Multicast Model», 2011 International Conference on Network Computing and Information Security, Guilin, China, pp. 169-174, DOI 10.1109/NCIS.2011.42, 2011, <https://doi.org/10.1109/NCIS.2011.42>.

[zhu-secure] Zhu, X. and J. W. Atwood, «A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol», 2007 4th IEEE Consumer Communications and Networking Conference, Las Vegas, NV, USA, pages 1098-1102, DOI 10.1109/CCNC.2007.221, 2007, <https://doi.org/10.1109/CCNC.2007.221>.

Приложение A. Соображения по устройству

A.1. Преимущества HIP

Изначально протокол сетевого уровня (IP) имел 4 «классических» инварианта:

  1. неизменность — переданный адрес совпадал с принятым;

  2. отсутствие мобильности — адрес не менялся в процессе взаимодействия;

  3. обратимость — адрес возврата всегда определялся перестановкой адресов отправителя и получателя;

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

Четвёртый инвариант можно вывести из 1 и 3, но он упомянут явно по причинам, рассмотренным ниже.

В современном «постклассическом» мире предпринимаются попытки исключить п. 2 (для мобильности и применения нескольких адресов), а также произошёл отказ от пп. 1 и 4. Попыткой сохранить п. 4 без п. 1, был документ Realm Specific IP [RFC3102], а IPv6 пытается восстановить п. 1.

Значимые имена DNS имеют немногие клиентские системы в Internet. Т. е. при наличии у клиентской системы имени FQDN это имя обычно относится к устройству NAT или серверу доступа (dial-up), а не указывает реально подключающуюся систему. FQDN (и их расширения в форме почтовых адресов) относятся к уровню приложений (чаще именуются службы, а не отдельные системы). Поэтому многие системы в Internet не зарегистрированы в DNS — у них просто нет служб, интересных другим хостам Internet.

Имена DNS являются ссылками на адреса IP и это лишь демонстрирует связь между сетевым и прикладным уровнем. DNS, как единственная и распределенная база данных Internet, является также хранилищем для других пространств имён, отчасти благодаря DNSSEC и записям ключей для приложений. Хотя каждое пространство имён можно растянуть (IP с помощью v6, DNS с помощью записей KEY), ни одно из них не может адекватно обеспечить аутентификацию хостов или послужить разделом между прикладным и сетевым уровнем.

Пространство имён HI заполняет важный пробел между пространствами IP и DNS. Интересным в HI является возможность отказа хоста от всего, кроме п. 3 для сетевого уровня. Иными словами, пока адреса отправителя и получателя в протоколе сетевого уровня обратимы, HIP заботится об идентификации хоста, а обратимость позволяет локальному хосту получать пакеты от удалённого. Смена адресов в результате прохождения через NAT (изменяемость) или перемещения хоста (мобильность и отсутствие всеведения) может обрабатываться уровнем HIP.

За исключением высокопроизводительных расчётных приложений, API сокетов являются наиболее общим вариантом разработки сетевых приложений, которые используют API напрямую или опосредованно через те или иные библиотеки или модели. Однако API сокетов основаны на допущении о статических адресах IP, а DNS со сроками действия записей придумали позже в процессе развития Internet. Поэтому API сокетов не работают со сроками действия адресов [RFC6250]. Сегодня большая часть пользовательского оборудования стала мобильной, а его адреса эфемерными, но API сокетов по-прежнему создают иллюзию постоянства адресов IP для неосторожных разработчиков. Протокол HIP может служить для укрепления этой иллюзии, поскольку HIP обеспечивает постоянные суррогатные адреса в форме LSI и HIT.

Постоянные идентификаторы, предоставляемые HIP, полезны во многих случаях (см. [ylitalo-diss] [komu-diss]).

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

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

  • При размещении хостов в разных сетях с приватными адресами приложение может однозначно распознавать хосты по их идентификаторам. Иными словами, HIP улучшает прозрачность Internet для уровня приложений [komu-diss].

  • При смене адресов сайта для служб в результате раздела или слияния компаний, а также при смене Internet-провайдера может полностью измениться сетевой префикс организации, что может создавать проблемы для трафика из-за жёсткого задания адресов в файлах конфигурации служб или кэширования адресов IP на стороне клиентов [RFC5887]. С учётом возможных человеческих ошибок использование независимых от местоположения идентификаторов, предоставляемых HIP, может смягчить проблему смены адресов.

  • Может быть повышена гибкость взаимодействия с IPv6, как отмечено в параграфе 4.4. Приложения на основе IPv6 могут взаимодействовать с помощью HIT с приложениями IPv4, использующими идентификаторы LSI. Кроме того, семейство адресов в приложении становится независимым от типа базовой сети (IPv4 или IPv6).

  • Можно применять HIT (или LSI) в списках доступа на основе IP как более защищённую замену адресов IPv6. Помимо защиты, контроль доступа на основе HIT обеспечивает два других преимущества. Во-первых, применение HIT может вдвое сократить размер списков, поскольку не будут нужны отдельные правила для IPv4 [komu-diss]. Во-вторых, правила конфигурации на основе HIT в промежуточных устройствах с поддержкой HIP остаются статическими и не зависят от смены топологии, что упрощает администрирование, особенно для сред с мобильными устройствами. Например, преимущества списков управления доступом на основе HIT применимы в HIP МСЭ, но могут использоваться также непосредственно на конечных хостах [RFC6538].

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

HIP можно объединять с разными протоколами, но сложность получаемых в результате программ может существенно возрасти, а взаимодействие между разными (возможно многоуровневыми) протоколами может негативно повлиять на задержку и пропускную способность. Следует также отметить, что практически нет помех в реализации архитектуры HIP в форме, например, библиотеки прикладного уровня, которая уже фактически была реализована в [xin-hip-lib]. Однако при переносе HIP на уровень приложений могут не поддерживаться унаследованные приложения.

A.2. Недостатки HIP

В информатике многие проблемы можно решить с помощью дополнительного уровня опосредованности. Однако косвенные обращения всегда связаны с определёнными расходами и «бесплатных обедов» не бывает. Издержки для случая HIP перечислены ниже.

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

  • HIP требует управления идентификаторами HI и централизованного подхода к масштабному управлению конечными точками с поддержкой HIP. Прежние ACL на основе адресов IP сейчас стали списками на основе доверенных HIT и сопоставление HIT с IP, а также правила доступа нужно администрировать. Конечные точки с поддержкой HIP должны также быть способны работать автономно для обеспечения мобильности и доступности (конечная точка должна сохранять работоспособность в отсутствие постоянного управляющего соединения). Пользователи, которым нужна повышенная защищенность и мобильность на основе HI вместо ACL по адресам IP, должны затем поддерживать этот дополнительный «уровень отождествления». Как показано в Приложении A.3.5, эти задачи уже решены в настройке инфраструктуры распространения политики и управления отображениями и отношениями доверия между конечными точками HIP.

  • HIP разделяет роли IP адресов как идентификаторов и «локаторов», поэтому требуется механизм сопоставления, чтобы связать их между собой. Неспособность сопоставить HIT с соответствующим «локатором» может приводить к отказам связности, поскольку идентификаторы HIT являются «плоскими» по своей природе и не поддерживают поиска через иерархическую систему DNS. Плоское пространство HIT обусловлено компромиссом в части защиты. Увеличение размера хэша в HIT снижает вероятность (злонамеренных) конфликтов (совпадений).

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

Из-за недостатков развёртывания для контроля доступа к различным службам и устройствам в современной сети Internet обычно применяются МСЭ. Поскольку HIP вносит дополнительное пространство имён, предполагается что для него также будет применяться фильтрация на предмет нежелательных подключений. Хотя это может быть достигнуто с помощью имеющихся средств непосредственно на конечных хостах, фильтры промежуточных устройств потребуется менять с внесением правок в программы имеющихся МСЭ или дополнительных промежуточных устройств [RFC6538].

Обмен ключами вносит дополнительную задержку *2 периода кругового обхода) в организацию транспортного соединения между парой конечных хостов. В TCP дополнительная задержка возникает, если реализация базового сетевого стека отбрасывает пакет SYN в процессе обмена ключами. Такие же издержки могут добавляться процедурами передачи обслуживания в HIP. Однако последующие сеансы TCP с той же ассоциацией HIP не будут добавлять издержек (в течение срока действия ключа). Издержки при обмене ключами и передаче обслуживания можно минимизировать за счёт кэширования пакетов TCP, а передачу обслуживания можно дополнительно оптимизировать с помощью расширений для пользовательского тайм-аута TCP [RFC5482], как подробно описал Schütz с соавторами [schuetz-intermittent].

Наиболее загружающие CPU операции связаны с использованием асимметричных ключей и вывода ключей методом Diffie-Hellman в плоскости управления, но это происходит при обмене ключами, их обслуживании (передача обслуживания и обновление ключевого материала) и завершении ассоциаций HIP. Плоскость данных обычно реализуется с помощью ESP, поскольку это снижает издержки за счёт применения симметричных ключей. Однако и с ESP связаны дополнительные издержки в части задержек (обработка) и пропускной способности (туннелирование), как отмечено в [ylitalo-diss] для оценки производительности.

A.3. Вопросы развёртывания и адаптации

В этом разделе рассмотрены некоторые соображения по развёртыванию и адаптации HIP с технической точки зрения.

A.3.1. Анализ развёртывания

Протокол HIP был адаптирован и развернут в промышленной сети управления производственного предприятия, где строгая идентификация HIP на сетевом уровне поддерживала безопасное сосуществование множества незащищённых сетевых устройств разных производителей [paine-hip]. Протокол HIP был также включён в продукцию защиты для поддержки L2 VPN [henderson-vpls] с целью поддержки зон безопасности в сети диспетчерского контроля и сбора данных (supervisory control and data acquisition или SCADA). Однако HIP не получил «большого успеха» [RFC5218] в Internet, как отмечено Levä и др. [levae-barriers]. Здесь кратко освещены некоторые выводы, основанные на общении с 19 специалистами из сферы промышленности и академических кругов.

С точки зрения маркетинга потребность в HIP была невелика и предпочтение отдавалось другим технологиям. Другая выявленная причина заключалась в сохранении некоторых технических заблуждений, связанных с ранними спецификациями HIP. Два обнаруженных заблуждения состояли в том, что HIP не поддерживает работу через NAT и требует реализации в ядре OS. Оба этих утверждения не соответствуют действительности — HIP включает расширения для работы через NAT [RFC9028], а изменения ядра можно избежать в современных ОС перенаправляя пакеты для обработки в пользовательское пространство.

В анализе Levä и др. приведены инфраструктурные требования для HIP. В минимальном варианте на машинах клиента и сервера должны работать программы HIP. Однако для предотвращения настройки вручную для HIP обычно создаются записи в DNS. Например, популярных DNS-сервер Bind9 не требует каких-либо изменений для размещения записей, связанных с HIP, поскольку он поддерживает двоичный формат в файлах конфигурации [RFC6538]. Серверы HIP rendezvous и МСЭ не являются обязательными. Не требуется вносить изменения в сетевые адреса, NAT, граничные маршрутизаторы и сети ядра.

Анализ также проясняет требования к компонентам хоста, состоящие из трёх частей. Во-первых, требуется плоскость управления HIP, обычно реализуемая в виде демона в пользовательском пространстве. Во-вторых, нужна плоскость данных и большинство реализаций HIP использует режим туннеля со сквозной привязкой (Bound End-to-End Tunnel или BEET) для ESP, доступный в Linux, начиная с ядра 2.6.27, и включенный также в нескольких реализациях в форме программы в пользовательском пространстве. В-третьих, системы HIP обычно обеспечивают DNS-прокси для локального хоста, транслирующий записи HIP DNS в LSI или HIT и передающий соответствующие «локаторы» демону HIP в пользовательском пространстве. Хотя третья часть не является обязательной, она очень полезна для предотвращения настройки вручную. Дополнительное описание этих модулей приведено в отчёте [RFC6538].

На основе обсуждения со специалистами в работе Levä и др. предложены дальнейшие направления для упрощения развёртывания HIP. Перенос ряда спецификаций HIP в IETF Standards Track уже произошёл, но авторы предлагают дополнительные меры, в частности, реализацию HIP в виде библиотеки прикладного уровня [xin-hip-lib] или иной промежуточной программы (middleware). С другой стороны, более осторожные меры включают сосредоточение на частных развёртываниях, контролируемых одной заинтересованной стороной. В качестве более конкретного примера такого сценария HIP может применяться одним сервис-провайдером для организации защищённых соединений между его серверами [komu-cloud].

A.3.2. HIP в сетях 802.15.4

Стандарты IEEE 802 определяют защиту на уровне MAC и многие из них используют расширяемый протокол аутентификации (Extensible Authentication Protocol или EAP) [RFC3748] в качестве системы управления ключами (Key Management System или KMS), но некоторые стандарты, такие как IEEE 802.15.4 [IEEE.802.15.4], оставляют систему KMS и её транспорт вне «области действия». HIP хорошо подходит для таких сред в качестве KMS.

  • HIP не зависит от адресации IP и может транспортироваться напрямую по любому сетевому протоколу.

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

  • Одноранговая KMS может лучше обслуживать специализированные (Ad-hoc) сети 802, чем модель «клиент-сервер» в EAP.

  • Память в некоторых устройствах может быть сильно ограничена, а общая система KMS для защиты MAC и IP даёт существенную экономию кода.

A.3.3. HIP и IoT

HIP требует на устройстве наличия вычислительных ресурсов для криптографической обработки. Протокол может работать в телефонах и небольших устройствах system-on-chip (таких как Raspberry Pi, Intel Edison), но мелкие датчики со слабыми батареями остаются проблематичными. Были разработаны расширения HIP для переноса на мелкие устройства обычно со снижением уровня защиты. Например, были предложены некриптографические идентификаторы для RFID. Подход Slimfit [hummen] предлагает уровень сжатия для HIP, делающий протокол более подходящим для сетей с ограничениями. Этот подход применён в облегчённой версии HIP (Diet HIP) для мелких датчиков.

Обмен HIP Diet EXchange (DEX) [hip-dex] нацелен на снижение издержек, связанных с криптографическими примитивами, за чет отказа от подписей открытых ключей и хэш-функций. При этом сохраняется цель обеспечить свойства защиты, аналогичные базовому обмену (Base Exchange или BEX). Обмен DEX разработан прежде всего для устройств и датчиков с оганиченной памятью и вычислительными ресурсами. Предполагается, что он будет применяться с подходящим протоколом защиты данных вышележащего протокола, таким как ESP. Кроме того, DEX может служить механизмом ввода ключей для примитивов защиты на уровне MAC, например, для сетей IEEE 802.15.9 [IEEE.802.15.9]. Основные отличия между BEX от DEX указаны ниже.

  1. Минимальный набор криптографических примитивов для снижения протокольных издержек:

    • статические пары ключей Elliptic Curve Diffie-Hellman (ECDH) для аутентификации и шифрования сеансового ключа;

    • AES-CTR для симметричного шифрования и AES-CMAC для функции MACing;

    • простая функций свёртки (fold) для генерации HIT.

  2. Отказ совершенной защиты (PFS) с отменой эфемерного согласования ключей Diffie-Hellman.

  3. Отказ от цифровых подписей с исключением хэш-функции. Использование выведенного из ECDH ключа в HIP_MAC для подтверждения владения секретным ключом.

  4. Выводимый с помощью Diffie-Hellman ключ применяется лишь для защиты пакетов HIP. Для создания сеансовых ключей применяется отдельный обмен секретами в пакетах HIP.

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

A.3.4. Инфраструктурные приложения

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

HIP успешно применялся в пересылающих web-прокси (прокси у клиента) между хостом клиента (web-браузер) и пересылающим прокси (сервер Apache), завершающим туннель HIP/ESP. Пересылающий web-прокси транслировал основанный на HIP трафик от клиента в обычный (не HIP) трафик с направлении web-сервера в Internet. Поддерживающий HIP клиент мог взаимодействовать с не понимающими HIP серверами. Таким способом клиент мог использовать поддержку мобильности в HIP при использовании фиксированного IP-адреса на web-прокси, например, для доступа к услугам, которые разрешены лишь для адресов IP из диапазона прокси.

В случае с обратным web-прокси (на стороне сервера), который также был исследован [komu-cloud], не поддерживающий HIP клиент обращался к понимающему HIP сервису web через промежуточный балансировщик нагрузки (HAProxy). Балансировщик транслировал обычный (не HIP) трафик от клиента в трафик на основе HIP для web-сервиса (серверы front-end и back-end). Балансировщик и web-сервис размещались в ЦОД. Одним из ключевых преимуществ шифрования web-трафика с помощью HIP в этом случае была поддержка частного и публичного (гибридного) облака, где балансировщик и серверы front-end и back-end размещаются в разных ЦОД и трафик нужно защищать при передаче через потенциально незащищённые сети между границами частного и публичного облака.

Хотя HIP можно применять для защиты доступа к промежуточным устройствам (например, доступа к коммутаторам по протоколу telnet), он использовался также для защиты соединений в инфраструктуре промежуточных устройств. Например, в более ранним исследовании [komu-mitigation] HIP применялся между почтовыми серверами (Simple Mail Transport Protocol или SMTP) для применения вычислительной головоломки (puzzle) HIP в качестве механизма снижения спама. Достаточно очевидной проблемой в этом случае было отсутствие адаптации HIP на серверах SMTP.

Чтобы избежать проблем развёртывания в имеющейся инфраструктуре, HIP можно использовать в контексте новых протоколов с минимальным развёртыванием. HIP был изучен в контексте некого протокола peer-to-peer SIP [camarillo-p2psip], результатом чего стал набор связанных RFC [RFC6078], [RFC6079], [RFC7086]. Основная идея исследования состояла в предотвращении избыточных трудоёмких процедур ICE путём группировки разных соединений (т. е. SIP и медиапотоки) вместе с использованием низкоуровневого HIP, выполняющего процедуру прохождения NAT лишь один раз на хост. Интересным аспектом было применение инфраструктуры P2P-SIP в качестве серверов встречи для плоскости управления HIP вместо использования традиционных служб HIP rendezvous [RFC8004].

Исследователи предложили применять HIP в сотовых сетях как решение для мобильности, множества адресов и защиты. В [hip-lte] приведён анализ защиты и моделирование применения HIP в транспортных сетях LTE.

HIP изучали в части защиты внутриоблачных соединений сначала с виртуальными машинами [komu-cloud], затем между контейнерами Linux [ranjbar-synaptic]. В обоих случаях HIP предоставлял решение для работы через NAT, которое подходило как внутри облака, так и между разными облаками. В частности, для первого случая HIP обеспечивал постоянную связность с виртуальной машиной при её переносе в другое место, а во втором контроллер программно-определяемой сети (Software-Defined Networking или SDN) служил сервером встреч для поддерживающих HIP контейнеров, обеспечивая надёжную защиту от повторного использования путём добавления middlebox nonce [heer-end-host] для базового обмена HIP и сообщений UPDATE.

A.3.5. Поддержка отождествлений в коммерческих системах

Tempered Networks выпускает продукцию на основе HIP, называя свою платформу сетью на основе отождествлений (Identity-Defined Networking или IDN) [tempered-networks] из за ориентированной на идентификацию архитектуры HIP. Задача заключалась в упрощении и бесперебойном развёртывании служб с поддержкой HIP в рабочих средах для обеспечения прозрачной аутентификации и проверки полномочий устройств, сокрытия, сегментации и сквозного взаимодействия в сети. Цель состоит в устранении большого числа циклических зависимостей, эксплойтов и сложности традиционных сетей на основе адресов, которые препятствуют мобильности и проверяемому контролю доступа к устройствам. Продукция Tempered Networks представляет HIP в нескольких типах устройств.

Коммутаторы и шлюзы HIP

Физические и виртуальные устройства, служащие шлюзами HIP и точками применения правил для приложений без поддержки HIP и расположенных за ними устройств. Для подключения, маскировки и защиты устройств без поддержки HIP не нужно менять IP или инфраструктуру. В настоящее время шлюзы HIP поддерживаются на устройствах x86 и ARM, а также в облаках ESXi, Hyper-V, KVM, AWS, Azure, Google.

Трансляторы и серверы встречи HIP

Физические и виртуальные устройства, служащие маршрутизаторами на основе отождествлений для проверки полномочий и соединения конечных точек HIP без шифрования сессий HIP. Ретранслятор HIP можно развернуть как автономное устройство или в кластере для горизонтальной расширяемости. Все конечные точки с поддержкой HIP, соединяемые и защищаемые ими устройства могут иметь приватные адреса. Платформы предотвращают конфликты IP, поддерживают туннели через NAT (включая NAT операторского класса) и не требуют менять базовую инфраструктуру. Единственным требованием является наличие у конечной точки HIP исходящего доступа в Internet а у ретранслятора HIP — публичного адреса.

Клиенты и серверы с поддержкой HIP

программы, устанавливаемые в сетевой стек хоста и обеспечивающие выполнение правил на хосте. Клиенты HIP поддерживают раздельное туннелирование. Клиенты и серверы HIP могут взаимодействовать с МСЭ на локальном хосте, а сервер можно заблокировать для прослушивания лишь применяемого для HIP порта, что делает его невидимым для неуполномоченных устройств. В настоящее время поддерживаются платформы Windows, OS X, iOS, Android, Ubuntu, CentOS и другие дистрибутивы Linux.

Менеджеры оркестровки правил

Физические и виртуальные устройства для задания и распространения правил сети и защиты (сопоставления HI и IP, наложенные сети, «белые» списки и т. п.) в конечные точки с поддержкой HIP. Оркестровка не требует сохранения в конечных точках HIP и наоборот, что позволяет создавать автономные сети и обеспечивать защиту.

A.4. Ответы на вопросы NSRG

Исследовательская группа IRTF Name Space задала в своём оценочном отчёте ряд вопросов [nsrg-report], ответы на которые представлены ниже.

  1. Как имя стека улучшит общую функциональность Internet?

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

  2. Как выглядит имя стека?

    HI является криптографическим открытым ключом, однако вместо непосредственного использования ключа многие протоколы применяют хэш открытого ключа с фиксированным размером.

  3. Каков срок действия идентификатора?

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

  4. Где HI размещаются в стеке?

    Идентификаторы HI находятся между транспортным и (меж)сетевым уровнем.

  5. Как HI используются конечными точками?

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

  6. Какая административная инфраструктура требуется для поддержки?

    В некоторых средах возможно применение HIP без какой-либо инфраструктуры, однако для полного использования преимуществ HIP идентификаторы HI должны храниться в DNS или PKI, а также нужен «механизм встречи (rendezvous) [RFC8005].

  7. Не делает ли дополнительный уровень ненужным список адресов в SCTP?

    Да, список не нужен.

  8. Какие дополнительные преимущества обеспечивает новая схема именования в части безопасности?

    HIP снижает зависимость от адресов IP, упрощая решение проблемы владения адресами [Nik2001]. На практике HIP обеспечивает защиту для мобильности и многоадресности конечных хостов. Кроме того, идентификаторы HI являются открытыми ключами и поверх HIP может применяться стандартная инфраструктура открытых ключей.

  9. Каким может быть механизм распознавания и какие характеристики требуются от него?

    Для большинства случаев достаточно модели с преобразованием имён DNS сразу в HI и адреса IP. Однако, если требуется преобразование HI в адреса IP или их обратное преобразование в имена DNS, нужна инфраструктура плоского распознавания, которая может быть реализована на основе распределенных хэш-таблиц, но это потребует новых разработок и развёртывания.

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

Люди, участвовавшие в ранних этапах разработки HIP, перечислены в разделе благодарностей спецификации HIP. На финальных этапах подготовки этого документа, когда редактором стал Pekka Nikander, бесценны были комментарии ранних разработчиков и других людей, включая Jari Arkko, Jeff Ahrenholz, Tom Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, Sasu Tarkoma, Jorma Wall. Спасибо также Lars Eggert, Spencer Dawkins, Dave Crocker, Erik Giesa за полезные комментарии.

Авторы выражают особую благодарность Tom Henderson, взявшему на себя задачи редактирования документа в ответ на комментарии IESG, когда оба автора были заняты другими делами. Без его настойчивости документ не достиг бы уровня RFC 4423.

Основная работа по обновлению и продвижению HIP в рамках процесса IETF была проделана несколькими командами разработчиков HIP. Авторы признательны компании Boeing, Helsinki Institute for Information Technology (HIIT), NomadicLab из Ericsson и трём университетам — RWTH Aachen, Aalto, University of Helsinki за их усилия. Без коллективной работы протокол HIP засох бы на лозе IETF как прекрасная концепция.

Спасибо также Suvi Koskinen за помощь в корректуре и джунглях ссылок.

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

Robert Moskowitz (editor)

HTT Consulting

Oak Park, Michigan

United States of America

Email: rgm@labs.htt-consult.com

Miika Komu

Ericsson

Hirsalantie 11

FI-02420 Jorvas

Finland

Email: miika.komu@ericsson.com


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

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

nmalykh@protokols.ru

1В оригинале применяется термин internetworking — межсетевой.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Denial-of-service — отказ в обслуживании.

5Encapsulating Security Payload — инкапсуляция данных защиты.

6Man-in-the-middle — перехват и изменение пакетов в пути с участием человека.

7Overlay Routable Cryptographic Hash Identifier — идентификатор наложенного маршрутизируемого криптографического хэша.

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

RFC 9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)

Internet Engineering Task Force (IETF)                    R. Marin-Lopez
Request for Comments: 9061                               G. Lopez-Millan
Category: Standards Track                           University of Murcia
ISSN: 2070-1721                                     F. Pereniguez-Garcia
                                               University Defense Center
                                                               July 2021

A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)

Модель данных YANG для защиты потоков IPsec на основе SDN

PDF

Аннотация

Этот документ описывает защиту потоков IPsec (целостность и конфиденциальность) через интерфейс с контроллером функций сетевой защиты (Interface to Network Security Function или I2NSF). Рассматриваются два базовых общеизвестных сценария IPsec — взаимодействие между шлюзами (gateway-to-gateway) и взаимодействие между хостами (host-to-host). Описанная в документе служба позволяет настраивать и отслеживать защищённые связи IPsec (Security Association или SA) от контроллера I2NSF к одной или нескольким основанным на потоках функциям защиты сети (Network Security Function или NSF), применяющих IPsec для защиты трафика данных.

Документ сосредоточен на интерфейсе I2NSF в сторону NSF и обеспечивает модели данных YANG для настройки баз данных IPsec, а именно, базы правил защиты (Security Policy Database или SPD), базы защищённых связей (Security Association Database или SAD), базы полномочий партнёров (Peer Authorization Database или PAD) и обмена ключами в Internet версии 2 (Internet Key Exchange Version 2 или IKEv2). Это позволяет создавать IPsec SA с минимальным вовлечением сетевого администратора. Документ определяет 3 модуля YANG, но не задаёт новых протоколов.

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

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

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

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

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

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

Архитектура программно-определяемых сетей (Software-Defined Networking или SDN) позволяет администраторам напрямую программировать, организовывать и управлять сетевыми ресурсами черех программы. Парадигма SDN переносит управления сетевыми ресурсами централизованному объекту — контроллеру SDN. Контроллер SDN настраивает и управляет сетевыми ресурсами, а также обеспечивает абстрактное представление сетевых ресурсов приложениям SDN. Эти приложения могут настраивать и автоматизировать операции (включая управление) абстрактных сетевых ресурсов программным способом через интерфейс [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].

В последнее время некоторые сетевые сценарии требуют централизованного управления различными аспектами безопасности, например, программно-управляемые сети WAN (Software-Defined WAN или SD-WAN). SD-WAN представляют собой расширения SDN, обеспечивающие программные абстракции для создания защищённых наложенных сетей на основе традиционных WAN и сетей филиалов. В SD-WAN применяется IPsec [RFC4301] как базовый протокол защиты. Цель SD-WAN состоит в предоставлении гибкого и автоматизируемого развёртывания из центральной точки для поддержки по запросам услуг защиты, таких как управление защищёнными связями IPsec (IPsec Security Association или IPsec SA). В параграфе 4.3.3 (Client-Specific Security Policy in Cloud VPNs) [RFC8192] описан другой пример использования для облачного центра обработки данных (ЦОД). В примере [RFC8192] сказано, что: «динамическое управление ключами очень важно для защиты VPN и распространения правил». Такие VPN могут создаваться с использованием IPsec. Управление IPsec SA у ЦОД с использованием централизованного объекта является вариантом, где может применяться эта спецификация.

Поэтому с расширением использования решений на основе SDN, где сетевые ресурсы разворачиваются автономно, механизм управления IPsec SA из центрального объекта становится все более актуальным для отрасли. В ответ на эту потребность устав рабочей группы I2NSF3 ставит задачу: «определить набор программных интерфейсов и моделей данных для управления и мониторинга аспектов физических и виртуальных NSF». Как определено в [RFC8192], функцией сетевой безопасности (Network Security Function или NSF) является: «функция, применяемая для обеспечения целостности, конфиденциальности и доступности сетевых коммуникаций, обнаружение нежелательной активности в сети, блокировка или смягчение последствий нежелательных действий». Этот документ обращает особое внимание на обеспечение целостности и конфиденциальности средствами IPsec. В параграфе 3.1.9 [RFC8192] сказано: «требуется контроллер для создания, управления и распространения различных ключей в распределенные NSF», однако «отсутствует стандартный интерфейс для предоставления защищённых связей и управления ими». На основе парадигмы SDN модель I2NSF [RFC8329] определяет централизованный объект (контроллер I2NSF), управляющий одной или множеством NSF через интерфейс I2NSF NSF-Facing. В этом документе задана архитектура, позволяющая контроллеру I2NSF выполнять процедуры управления ключами. В частности, определены три модели данных YANG для интерфейса I2NSF NSF-Facing, позволяющие контроллеру I2NSF настраивать и отслеживать основанные на потоках NSF с поддержкой IPsec.

Архитектура IPsec [RFC4301] чётко разделяет обработку для обеспечения услуг по защите пакетов IP и процедуры управления ключами для создания IPsec SA, что позволяет централизовать управления ключами в контроллере I2NSF. Этот документ рассматривает два типовых варианта автономного управления IPsec SA — между шлюзами (gateway-to-gateway) и между хостами (host-to-host) [RFC6071]. В этих случаях роль NSF могут играть хосты, шлюзы или те и другие сразу. По причине сложности вариант взаимодействия между хостом и шлюзам в документе не рассматривается. Причины этой сложности состоят в том, что в этом варианте хост может не управляться контроллером I2NSF и не может быть настроен. Тем не менее, заданные здесь интерфейсы можно рассматривать как отправную точку для анализа и представления решений для взаимодействия между хостом и шлюзом.

При определении моделей данных YANG для интерфейса I2NSF NSF-Facing в документе рассмотрены 2 общих случая, указанных ниже.

  1. Вариант с IKE. NSF реализует протокол обмена ключами Internet версии 2 (Internet Key Exchange Version 2 или IKEv2) и базы данных IPsec для правил безопасности (Security Policy Database или SPD), защищённых связей (Security Association Database или SAD) и предоставления полномочий партнёрам (Peer Authorization Database или PAD). Контроллер I2NSF отвечает за предоставление NSF требуемых сведений в SPD и PAD (например, свидетельства IKE) и самом протоколе IKE (например, параметры для согласования IKE_SA_INIT).

  2. Вариант без IKE. NSF реализует лишь базы данных IPsec (без IKE). Контроллер I2NSF предоставит требуемые параметры для создания действительных записей SPD и SAD NSF. Таким образом, NSF будет поддерживать лишь IPsec, а управление ключами будет передано контроллеру I2NSF.

В обоих случаях нужна модель данных YANG для интерфейса I2NSF NSF-Facing, чтобы безопасно обеспечить это предоставление между контроллером I2NSF и NSF. Используя язык моделирования YANG версии 1.1 [RFC7950], модели данных YANG из [netconf-vpn] и [TRAN-IPSECME-YANG], а также структуры данных из [RFC4301] и [RFC7296], этот документ определяет требуемые интерфейсы с моделью данных YANG для конфигурации и состояния IKE, PAD, SPD, SAD (см. параграфы 5.1 — 5.3). Предложенная модель данных YANG соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342]. Примеры использования этих моделей данных представлены в приложениях A — C.

Ниже указаны основные цели этого документа.

  • Описание архитектуры управления IPsec на основе I2NSF, позволяющего создавать и поддерживать IPsec SA с контроллера I2NSF для защиты конкретных потоков данных между парой основанных на потоках NSF, реализующих IPsec.

  • Отображение этой архитектуры на модель I2NSF.

  • Определение интерфейсов, требуемых для управления и мониторинга IPsec SA в NSF с контроллера I2NSF. Определены модели данных YANG для конфигурации и состояния IPsec и IKEv2 через интерфейс I2NSF NSF-Facing. Модели данных YANG можно применять по имеющимся протоколам, таким как протокол настройки сети (Network Configuration Protocol или NETCONF) [RFC6241] или RESTCONF [RFC8040]. Таким образом, этот документ задаёт три модуля YANG (см. раздел 5), но не определяет новых протоколов.

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

Документ использует термины из [ITU-T.Y.3300], [RFC8192], [RFC4301], [RFC6437], [RFC7296], [RFC6241], [RFC8329].

Термин из [ITU-T.Y.3300]:

  • Software-Defined Networking (SDN) — программно-определяемая сеть.

Термины из [RFC8192]:

  • Network Security Function (NSF) — функция защиты сети;

  • flow-based NSF — NSF на основе потоков.

Термины из [RFC4301]:

  • Peer Authorization Database (PAD) — база данных о полномочиях партнёров;

  • Security Association Database (SAD) — база данных о защищённых связях;

  • Security Policy Database (SPD) — база правил безопасности.

Термины из [RFC6437]:

  • flow — поток;

  • traffic flow — поток трафика.

Термин из [RFC7296]:

  • Internet Key Exchange Version 2 — (IKEv2) обмен ключами Internet версии 2.

Термины из [RFC6241]:

  • configuration data — данные конфигурации;

  • configuration datastore — хранилище данных конфигурации;

  • state data — данные состояния;

  • startup configuration datastore — хранилище данных стартовой конфигурации;

  • running configuration datastore — хранилище данных рабочей конфигурации.

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

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

3. Описание управления IPsec на основе SDN

Как отмечено в разделе 1, рассматриваются два варианта NSF — с реализацией IKEv2 и без IKE.

3.1. Вариант с IKE — IKEv2/IPsec в NSF

В этом случае NSF реализует IPsec с поддержкой IKEv2. Контроллер I2NSF отвечает за поддержку и применение сведений о соединениях IPsec (определение узлов, где нужно запустить сессии IKEv2/IPsec, идентификация типа защищаемого трафика, выведение и доставка свидетельств IKEv2, таких как заранее распределенные ключи, сертификаты и т. п.) и применение других параметров конфигурации IKEv2 (например, криптографических алгоритмов для организации IKEv2 SA) к NSF для согласования IKEv2.

Реализация IKEv2 может работать с этими записями для организации IPsec SA. Пользователь I2NSF устанавливает требования IPsec и сведения о конечных точках (через интерфейс I2NSF Consumer-Facing [RFC8329]), а контроллер I2NSF транслирует эти требования в записи IKEv2, SPD и PAD, которые будут установлены в NSF (через интерфейс I2NSF NSF-Facing). Имея эти сведения, NSF может просто запустить IKEv2 для организации требуемой IPsec SA (когда поток трафика нужно защищать). На рисунке 1 показаны уровни и соответствующая функциональность.

+-------------------------------------------+
|         Система управления IPsec          | Пользователь I2NSF
+-------------------------------------------+
                        |
                        |  Интерфейс I2NSF 
                        |  с клиентом
+-------------------------------------------+
| Распространение конфигурации IKEv2,       | Контроллер
|         записей PAD и SPD                 | I2NSF
+-------------------------------------------+
                        |
                        |  Интерфейс I2NSF
                        |  с NSF
+-------------------------------------------+
|   IKEv2  |      IPsec(PAD, SPD)           | Функция
|-------------------------------------------| защиты
|       Защита и пересылка данных IPsec     | сети
+-------------------------------------------+

Рисунок 1.IKE/IPsec в NSF.


Службы защиты потоков IPsec на основе I2NSF обеспечивают гибкое динамическое управление IPsec SA в NSF на основе потоков. Для поддержки этого в варианте с IKE определяется модель YANG для данных конфигурации IKEv2, SPD, PAD и данных состояния IKEv2, требуемых для определения интерфейса I2NSF в сторону NSF (NSF-Facing), см. 5. Модели YANG для данных конфигурации.

3.2. Вариант без IKE — IPsec (без IKEv2) в NSF

В этом случае NSF не развёртывает IKEv2, поэтому контроллер I2NSF выполняет функции IKEv2 для защиты и управления IPsec SA, заполняя и поддерживая SPD и SAD. Как показано на рисунке 2, при применении пользователем I2NSF основанной на потоках политики защиты через интерфейс в сторону клиента (Consumer-Facing Interface) контроллер I2NSF транслирует требования правил в записи SPD и SAD, устанавливаемые в NSF. Записи PAD не требуются, поскольку в этом случае IKEv2 для NSF не применяется.

+-----------------------------------------+
|        Система управления IPsec         | Пользователь I2NSF
+-----------------------------------------+
                    |
                    |  Интерфейс I2NSF 
                    |  с клиентом
+-----------------------------------------+
|             Распространение             | Контроллер
|            записей SPD и SAD            | I2NSF
+-----------------------------------------+
                    |
                    |  Интерфейс I2NSF с NSF
                    |
+-----------------------------------------+
|             IPsec (SPD, SAD)            | Функция
|-----------------------------------------| защиты
|     Защита и пересылка данных IPsec     | сети
+-----------------------------------------+

Рисунок 2. IPsec в NSF без IKEv2.


Для поддержки работы без IKE должна быть определена модель YANG для данных конфигурации SPD и SAD, а также данных состояния SAD для интерфейса NSF-Facing (см. 5. Модели YANG для данных конфигурации). В частности, вариант без IKE предполагает, что контроллер I2NSF выполняет некоторые функции защиты, которые обычно реализует IKEv2, а именно (неполный список):

  • создание вектора инициализации (Initialization Vector или IV);

  • предотвращение сброса счётчика для одного и того же ключа;

  • генерация псевдослучайных криптографических ключей для IPsec SA;

  • создание IPsec SA, когда этого требует уведомление (например, sadb-acquire) от NSF;

  • смена ключей IPsec SA на основе уведомлений от NSF (завершение срока действия);

  • обнаружение и поддержка работы через NAT.

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

  • генерация случайного индекса параметров защиты IPsec SA (Security Parameter Index или SPI);

  • выбор криптографического алгоритма;

  • использование расширенных порядковых номеров;

  • организация подходящих селекторов трафика (Traffic Selector).

4. Сравнение вариантов с IKE и без IKE

В принципе, вариант с IKE проще развернуть, поскольку современные NSF (хосты или шлюзы) на основе потоков имеют доступ к реализациям IKEv2. Хотя реализация IKEv2/IPsec обычно развёртывается на шлюзах, это легко сделать и на хосте. Недостатком является потребность в большем объёме ресурсов для NSF при использовании IKEv2, например, памяти для реализации и расчётов IKEv2, поскольку каждая смена ключей IPsec SA может включать обмен Диффи-Хеллмана (Diffie-Hellman или DH).

Вариант без IKE даёт выигрыш при развёртывании на NSF с ограниченными ресурсами. Кроме того, IKEv2 не требуется при взаимодействии «шлюз-шлюз» или «хост-хост», когда оба работают с одним контроллером I2NSF (см. D.1. Пример организации IPsec SA). Сложность создания и поддержки IPsec SA переносится на контроллер I2NSF, поскольку IKEv2 не входит в NSF. В результате это может усложнять реализацию контроллера по сравнению с вариантом IKE. Например, контроллер I2NSF должен иметь дело с задержкой на пути между контроллером I2NSF и NSF (для решения таких задач, как смена ключа) или с созданием и установкой новых IPsec SA. Однако это относится не только к данному решению, но и к любой сети на основе SDN. Этот подход может осложнять расширение и создавать проблемы производительности при большом числе NSF.

Тем не менее, из литературы по управлению сетями на основе SDN с использованием централизованного контроллера (например, I2NSF Controller) известно о проблемах расширяемости и производительности и решения уже найдены и рассмотрены (например, иерархические контроллеры, включающие множество реплик, выделенные высокоскоростные сети управления и т. п.) В контексте управления IPsec на основе I2NSF одним из способов снижения задержки и устранения некоторых проблем производительности можно установить правила IPsec и IPsec SA одновременно (упреждающий режим, как описано в D.1. Пример организации IPsec SA) вместо ожидания уведомлений (например, sadb-acquire от NSF, требующего создания IPsec SA) для установки IPsec SA (реактивный режим). Другим способом сокращения издержек, а также решения вопросов расширяемости и производительности в контроллере I2NSF является применение варианта с IKE, описанного в этом документе, поскольку в этом случае IPsec SA поддерживаются между NSF без участия контроллера I2NSF, а вместо этого контроллер I2NSF просто обеспечивает начальную настройку (записи IKEv2, PAD, SPD). Предложены иные решения, такие как Controller-IKE [IPSECME-CONTROLLER-IKE], где NSF предоставляют свои открытые ключи DH контроллеру I2NSF, а тот распространяет их всем партнёрам. Партнёры могут вычислить парные секреты для каждого из своих партнёров и сообщения между NSF не нужны. Механизм смены ключей дополнительно описан в [IPSECME-CONTROLLER-IKE].

С точки зрения безопасности вариант с IKE обеспечивает лучшую защиту, нежели вариант без (см. 7. Вопросы безопасности). Основная причина этого заключается в том, что сеансовые ключи создают NSF, а не контроллер I2NSF.

4.1. Процесс смены ключей

Смена ключей IPsec SA является важной частью управления IPsec SA. С моделями данных YANG, заданными здесь, контроллер I2NSF может настраивать параметры процесса смены ключей (вариант с IKE) или выполнять этот процесс (вариант без IKE).

Для варианта с IKE процесс смены ключей выполняет IKEv2, следуя данным из SPD и SAD (например, на основе срока действия IPsec SA, заданного контроллером I2NSF с использованием модели YANG из этого документа). Поэтому соединения IPsec будут активны, пока пользователь I2NSF не потребует иного или контроллер I2NSF не обнаружит что-либо неверное.

В варианте без IKE контроллер I2NSF должен заботиться о смене ключей. Когда срок действия IPsec SA истекает, контроллер должен создать новую IPsec SA и может удалить старую (например, если срок действия старой IPsec SA не задан). Процесс смены ключей начинается с получением контроллером I2NSF уведомления sadb-expire или по инициативе самого контроллера I2NSF на основе сведений о сроке действия данных состояния, полученных от NSF. Способ реализации контроллером I2NSF алгоритма смены ключей выходит за рамки этого документа. Тем не менее, пример возможной смены ключей представлен в D.2. Пример смены ключей в варианте без IKE.

4.2. Потеря состояния NSF

При перезапуске NSF теряется состояние IPsec (затрагиваемое NSF). По умолчанию контроллер I2NSF может считать, что было потеряно все состояние, поэтому он будет передавать NSF сведения IKEv2, SPD и PAD в варианте с IKE, SPD и SAD в варианте без IKE. В обоих случаях контроллер I2NSF знает о затронутом NSF (например, разорвано соединение NETCONF/TCP с NSF, контроллер I2NSF получил уведомление sadb-bad-spi от NSF и т. п.). Кроме того, контроллер I2NSF хранит список NSF, имеющих IPsec SA с затронутым NSF, поэтому он знает затронутые IPsec SA.

В варианте с IKE контроллеру I2NSF может потребоваться настройка для затронутого NSF новых сведений IKEv2, SPD и PAD. Как вариант, конфигурацию IKEv2 можно сделать неизменной при перезапуске NSF без ущерба для безопасности путём записи в хранилище стартовой конфигурации NSF. В этом случае при каждой перезагрузке NSF будет применяться одна и та же конфигурация, что позволит избежать обращения к контроллеру I2NSF. Контроллеру может потребоваться передача новых (например, свежий ключ PSK для аутентификации) элементам NSF, у которых были IKEv2 SA и IPsec SA с затронутым NSF.

В варианте без IKE контроллеру I2NSF следует удалить старые IPsec SA в неотказавших узлах, связанных с затронутым NSF. После перезапуска узла контроллер I2NSF должен выполнить действия по восстановления защищённой IPsec связи между отказавшим узлом и другими узлами, имеющими IPsec SA с затронутым NSF. Способ реализации контроллером I2NSF Controller алгоритма обработки возможной потери состояния NSF выходит за рамки документа. Тем не менее, пример обработки дан в D.3. Пример контроля потери состояния NSF в варианте без IKE.

4.3. Работа через NAT

В случае с IKE уже предоставляется механизм IKEv2 для обнаружения размещения одного или обоих партнёров за системой NAT. В таких случаях нужна инкапсуляция UDP или TCP для пакетов инкапсуляции защищённых данных (Encapsulating Security Payload или ESP) [RFC3948] [RFC8229]. Отметим, что транспортный режим IPsec недопустимо применять в этой спецификации, если требуется NAT.

В случае без IKE у NSF нет поддержки от реализации IKEv2 для обнаружения работы через NAT. Если у NSF нет иного механизма обнаружения таких ситуаций, контроллеру I2NSF следует реализовать свой механизм. Парадигма SDN обычно предполагает, что у контроллера I2NSF имеется представление управляемой сети. Это представление создаётся путём запроса информации от управляемых NSF или использования сведений, выталкиваемых NSF контроллеру I2NSF. На основе этих данных контроллер I2NSF может предсказать наличие NAT между двумя хостами и применить требуемые к обоим NSF правила в дополнение к инкапсуляции UDP или TCP для пакетов ESP [RFC3948] [RFC8229]. Интерфейс обнаружения NSF, расположенных за NAT, выходит за рамки этого документа.

Если у контроллера I2NSF нет механизма обнаружения работы хоста через NAT, должен применяться вариант с IKE.

4.4. Регистрация и обнаружение NSF

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

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

5. Модели YANG для данных конфигурации

Для поддержки вариантов с IKE и без IKE представлены модели с различными параметрами и значениями, которые должны быть настроены для управления IPsec SA. В частности для варианта с IKE требуется моделировать параметры конфигурации IKEv2, SPD и PAD, а для варианта без IKE требуются модели данных YANG для SPD и SAD. Ниже определены три модуля: ietf-i2nsf-ikec (параграф 5.1, общий для обоих вариантов), ietf-i2nsf-ike (параграф 5.2 для варианта с IKE), ietf-i2nsf-ikeless (параграф 5.3 для варианта без IKE). Поскольку модуль ietf-i2nsf-ikec включает лишь общие с другими модулями определения типов и группировки, модули ietf-i2nsf-ike и ietf-i2nsf-ikeless даны упрощенно.

5.1. Модуль ietf-i2nsf-ikec

5.1.1. Обзор модели данных

Модуль ietf-i2nsf-ikec определяет лишь типы данных (typedef) и группировки, применяемые другими модулями.

5.1.2. Модуль YANG

Этот модуль включает нормативные ссылки на [RFC3947], [RFC4301], [RFC4303], [RFC8174], [RFC8221], [RFC3948], [RFC8229], [RFC6991], [IANA-Protocols-Number], [IKEv2-Parameters], [IKEv2-Transform-Type-1] и [IKEv2-Transform-Type-3].

   <CODE BEGINS> file "ietf-i2nsf-ikec@2021-07-14.yang"
   module ietf-i2nsf-ikec {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
     prefix nsfikec;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types.";
     }

     organization
       "IETF I2NSF Working Group";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/> 
        WG List: <mailto:i2nsf@ietf.org> 

        Author: Rafael Marin-Lopez
                  <mailto:rafa@um.es> 

        Author: Gabriel Lopez-Millan
                  <mailto:gabilm@um.es> 

        Author: Fernando Pereniguez-Garcia
                  <mailto:fernando.pereniguez@cud.upct.es>";
     description
       "Базовая модель данных для вариантов с IKE и без IKE, заданных
        службой защиты потоков IPsec на основе SDN.

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

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

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

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

     revision 2021-07-14 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection
                    Based on Software-Defined Networking (SDN).";
     }

     typedef encr-alg-t {
       type uint16;
       description
         "Алгоритм шифрования указывается 16-битовым номером из реестра
          IANA. Приемлемые значения ДОЛЖНЫ соответствовать уровню
          требований для алгоритмов шифрования ESP и IKEv2.";
       reference
         "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
                IKEv2 Transform Attribute Types, Transform Type 1 -
                Encryption Algorithm Transform IDs
          RFC 8221: Cryptographic Algorithm Implementation Requirements
                    and Usage Guidance for Encapsulating Security 
                    Payload (ESP) and Authentication Header (AH)
          RFC 8247: Algorithm Implementation Requirements and Usage
                    Guidance for the Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
     }

     typedef intr-alg-t {
       type uint16;
       description
         "Алгоритм защиты целостности указывается 16-битовым номером из 
          реестра IANA. Приемлемые значения ДОЛЖНЫ соответствовать 
          уровню требований защиты целостности для ESP и IKEv2.";
       reference
         "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
                IKEv2 Transform Attribute Types, Transform Type 3 -
                Integrity Algorithm Transform IDs
          RFC 8221: Cryptographic Algorithm Implementation
                    Requirements and Usage Guidance for Encapsulating
                    Security Payload (ESP) and Authentication Header
                    (AH)
          RFC 8247: Algorithm Implementation Requirements and Usage
                    Guidance for the Internet Key Exchange Protocol
                    Version 2 (IKEv2).";
     }

     typedef ipsec-mode {
       type enumeration {
         enum transport {
           description
             "Транспортный режим IPsec. NAT не поддерживается.";
         }
         enum tunnel {
           description
             "Туннельный режим IPsec.";
         }
       }
       description
         "Определение типа для режима IPsec - transport или tunnel.";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 3.2.";
     }

     typedef esp-encap {
       type enumeration {
         enum espintcp {
           description
             "ESP с инкапсуляцией TCP.";
           reference
             "RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
         }
         enum espinudp {
           description
             "ESP с инкапсуляцией UDP.";
           reference
             "RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
         }
         enum none {
           description
             "Без инкапсуляции ESP.";
         }
       }
       description
         "Типы инкапсуляции ESP при возможном наличии трансляции NAT
          между двумя NSF.";
       reference
         "RFC 8229: TCP Encapsulation of IKE and IPsec Packets
          RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
     }

     typedef ipsec-protocol-params {
       type enumeration {
         enum esp {
           description
             "Протокол IPsec ESP.";
         }
       }
       description
         "Поддерживается только ESP, но потом возможно расширение.";
       reference
         "RFC 4303: IP Encapsulating Security Payload (ESP).";
     }

     typedef lifetime-action {
       type enumeration {
         enum terminate-clear {
           description
             "Завершает все IPsec SA и пропускает пакеты.";
         }
         enum terminate-hold {
           description
             "Завершает IPsec SA и отбрасывает пакеты.";
         }
         enum replace {
           description
             "Заменяет IPsec SA со сменой ключей.";
         }
       }
       description
         "При завершении срока действия IPsec SA нужно принимать меры.
          Имеется 3 варианта: terminate-clear, terminate-hold, replace";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.5.";
     }

     typedef ipsec-traffic-direction {
       type enumeration {
         enum inbound {
           description
             "Входящий трафик.";
         }
         enum outbound {
           description
             "Исходящий трафик.";
         }
       }
       description
         "Направление трафика IPsec определяется как inbound или 
          outbound. С точки зрения NSF входной и выходной трафик
          определяются в соответствии с параграфом 3.1 в RFC 4301.";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 3.1.";
     }

     typedef ipsec-spd-action {
       type enumeration {
         enum protect {
           description
             "Защита трафика с применением IPsec.";
         }
         enum bypass {
           description
             "Передача трафика в обход без защиты IPsec.";
         }
         enum discard {
           description
             "Отбрасывание трафика пакетов IP.";
         }
       }
       description
         "Действие при соответствии трафика политике IPsec. В RFC 4301
          задано 3 варианта BYPASS, PROTECT, DISCARD.";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.4.1.";
     }

     typedef ipsec-inner-protocol {
       type union {
         type uint8;
         type enumeration {
           enum any {
             value 256;
             description
               "Любой номер протокола IP.";
           }
         }
       }
       default "any";
       description
         "защита IPsec может быть применена к конкретному трафику IP и
          L4 (TCP, UDP, SCTP и т. п.) или ЛЮБОМУ протоколу в данных
          (payload) пакета IP. Номер протокола указывается типом uint8
          или ЛЮБЫМ определением перечисляемого типа со значением 256 
          для указания номера протокола. Отметим, что для IPv6 протокол
          в данных пакета IP указывает поле Next Header заголовка IPv6";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.4.1.1
          IANA: Protocol Numbers.";
     }

     grouping encap {
       description
         "Эта группа узлов позволяет определить тип инкапсуляции при
          необходимости работать через NAT и указании порта.";
       leaf espencap {
         type esp-encap;
         default "none";
         description
           "ESP в TCP, ESP с UDP, ESP в TLS.";
       }
       leaf sport {
         type inet:port-number;
         default "4500";
         description
           "Номер порта-источника при инкапсуляции.";
       }
       leaf dport {
         type inet:port-number;
         default "4500";
         description
           "Номер порта-получателя при инкапсуляции.";
       }
       leaf-list oaddr {
         type inet:ip-address;
         description
           "Если нужно, этот лист-список содержит исходный адрес,
            использованный до трансляции пакета в NAT.";
       }
       reference
         "RFC 3947: Negotiation of NAT-Traversal in the IKE
          RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
     }

     grouping lifetime {
       description
         "Значения срока действия ограничены для IPsec SA.";
       leaf time {
         type uint32;
         units "seconds";
         default "0";
         description
           "Число секунд с момент добавления IPsec SA. Например, 180
            означает, что прошло 180 секунд с момента добавления
            IPsec SA. Значение 0 подразумевает бесконечность.";
       }
       leaf bytes {
         type uint64;
         default "0";
         description
           "Срок действия IPsec SA завершается после обработки IPsec SA
            числа байтов, заданного этим листом, и СЛЕДУЕТ поменять 
            ключи. Значение 0 подразумевает бесконечность.";
       }
       leaf packets {
         type uint32;
         default "0";
         description
           "Срок действия IPsec SA завершается после обработки IPsec SA
            числа пакетов, заданного этим листом, и СЛЕДУЕТ поменять 
            ключи. Значение 0 подразумевает бесконечность.";
       }
       leaf idle {
         type uint32;
         units "seconds";
         default "0";
         description
           "NSF расходует ресурсы системы на сохранение IPsec SA. Для
            бездействующей IPsec SA это будет напрасный расход. Если 
            IPsec SA бездействует в течение указанного числа секунд, её
            СЛЕДУЕТ удалить. Значение 0 подразумевает бесконечность.";
       }
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.4.2.1.";
     }

     grouping port-range {
       description
         "Группировка задаёт диапазон портов, как указано в RFC 4301, 
          например, 1500 (начальный номер)-1600 (конечный номер).
          Диапазон портов применяется в селекторе трафика.";
       leaf start {
         type inet:port-number;
         description
           "Начальный номер порта.";
       }
       leaf end {
         type inet:port-number;
         must '. >= ../start' {
           error-message
             "Конечный номер порта ДОЛЖЕН быть не меньше начального.";
         }
         description
           "Конечный номер порта. Для указания одного порта указываются
            одинаковое начальное и конечное значения.";
       }
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.4.1.2.";
     }

     grouping tunnel-grouping {
       description
         "Параметры, требуемые для определения конечных точек туннеля
          IP, когда IPsec SA требует туннельный режим. Туннель задают
          адреса IP локальной и удалённой конечных точек.";
       leaf local {
         type inet:ip-address;
         mandatory true;
         description
           "Адрес IP локальной конечной точки туннеля.";
       }
       leaf remote {
         type inet:ip-address;
         mandatory true;
         description
           "Адрес IP удалённой конечной точки туннеля.";
       }
       leaf df-bit {
         type enumeration {
           enum clear {
             description
               "Сбрасывать флаг DF во внешнем заголовке. Принято по
                умолчанию.";
           }
           enum set {
             description
               "Устанавливать флаг DF во внешнем заголовке.";
           }
           enum copy {
             description
               "Копировать флаг DF во внешний заголовок.";
           }
         }
         default "clear";
         description
           "Разрешает задавать бит DF при инкапсуляции трафика в
            туннельном режиме IPsec. RFC 4301 описывает 3 варианта
            обработки флага DF при туннельной инкапсуляции: сброс,
            установка, копирование из внутреннего заголовка IP. Лист
            ДОЛЖЕН игнорироваться, если локальный и удалённый адреса
            IP являются адресами IPv6.";
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 8.1.";
       }
       leaf bypass-dscp {
         type boolean;
         default "true";
         description
           "Значение true задаёт копирование кода DSCP из внутреннего
            заголовка во внешний. Значение false указывает отображение
            значений DSCP в соответствии с ../dscp-mapping.";
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.1.2.";
       }
       list dscp-mapping {
         must '../bypass-dscp = "false"';
         key "id";
         ordered-by user;
         leaf id {
           type uint8;
           description
             "Индекс списка отображений.";
         }
         leaf inner-dscp {
           type inet:dscp;
           description
             "Значение DSCP во внутреннем пакете IP. Если лист не задан,
              предполагается ЛЮБОЕ внутреннее значение DSCP.";
         }
         leaf outer-dscp {
           type inet:dscp;
           default "0";
           description
             "Значение DSCP во внешнем заголовке IP.";
         }
         description
           "Список, представляющий массив отображений внутреннего кода
            DSCP во внешний при установке bypass-dscp false. Для задания
            принятого по умолчанию отображения, когда внутреннее 
            значение не соответствует ни одному узлу списка, в конец
            списка включается новый элемент, где лист inner-dscp не 
            задан (ANY), а outer-dscp содержит отображаемое значение. 
            Если outer-dscp, не указывает значения, предполагается 0.";
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.1.2 and Appendix C.";
       }
     }

     grouping selector-grouping {
       description
         "Группировка определения селектора трафика, используемого в 
          правилах IPsec policies и IPsec SA.";
       leaf local-prefix {
         type inet:ip-prefix;
         mandatory true;
         description
           "Префикс локального адреса IP.";
       }
       leaf remote-prefix {
         type inet:ip-prefix;
         mandatory true;
         description
           "Префикс удалённого адреса IP.";
       }
       leaf inner-protocol {
         type ipsec-inner-protocol;
         default "any";
         description
           "Внутренний протокол, который будет защищаться IPsec.";
       }
       list local-ports {
         key "start end";
         uses port-range;
         description
           "Список локальных портов. Для внутреннего протокола ICMP это
            16-битовое значение представляет код и тип. Если этот список 
            не задан, предполагается, что start и end имеют значения 0
            (любой порт).";
       }
       list remote-ports {
         key "start end";
         uses port-range;
         description
           "Список удалённых портов. Когда вышележащим протоколом 
            является ICMP, это 16-битовое значение представляет код и 
            тип. Если этот список не задан, предполагается, что start и
            end имеют значения 0(любой порт).";
       }
       reference
         "RFC 4301: Security Architecture for the Internet Protocol,
                    Section 4.4.1.2.";
     }

     grouping ipsec-policy-grouping {
       description
         "данные конфигурации для записи IPsec SPD.";
       leaf anti-replay-window-size {
         type uint32;
         default "64";
         description
           "Для установки размера окна anti-replay. По умолчанию 64,
            в соответствии с RFC 4303.";
         reference
           "RFC 4303: IP Encapsulating Security Payload (ESP),
                      Section 3.4.3.";
       }
       container traffic-selector {
         description
           "Пакеты выбираются для обработки по селекторам трафика,
            которые указывают IP и данные из внутреннего заголовка.";
         uses selector-grouping;
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.4.1.";
       }
       container processing-info {
         description
           "Обработка SPD. Если требуемым действием является защита,
            здесь содержатся сведения, требуемые для обработки.";
         leaf action {
           type ipsec-spd-action;
           default "discard";
           description
             "При обходе или отбрасывании контейнер ipsec-sa-cfg пуст.";
         }
         container ipsec-sa-cfg {
           when "../action = 'protect'";
           description
             "Конфигурация IPsec SA, включаемая в запись SPD.";
           leaf pfp-flag {
             type boolean;
             default "false";
             description
               "Каждый селектор имеет флаг заполнения из пакета 
                (Populate From Packet или PFP). Установленный для
                селектора X флаг указывает, что создаваемой IPsec SA
                следует брать своё значение (локальный и удалённый 
                адреса IP, Next Layer Protocol и т. п.) для X из
                значений в пакете. В иных случаях IPsec SA следует
                брать значения для X из записи в SPD.";
           }
           leaf ext-seq-num {
             type boolean;
             default "false";
             description
               "Значение true указывает, что данные IPsec SA применяет
                расширенные порядковые номера (64 бита). Значение false
                указывает применение обычных 32-битовых номеров.";
           }
           leaf seq-overflow {
             type boolean;
             default "false";
             description
               "Флаг, указывающий, должно ли переполнение счётчика 
                порядковых номеров препятствовать дальнейшей передаче 
                пакетов в IPsec SA (false) и, следовательно, нужна смена
                ключей, или разрешён переход счётчика через максимум
                (true). При аутентифицированном шифровании со связанными
                данными (Authenticated Encryption with Associated Data
                или AEAD) (лист esp-algorithms/encryption/algorithm-type)
                этот флаг ДОЛЖЕН иметь значение false. Установка значения
                true настоятельно не рекомендуется.";
           }
           leaf stateful-frag-check {
             type boolean;
             default "false";
             description
               "Указывает применяется (true) или нет (false) проверка 
                фрагментов с учётом состояния для создаваемой IPsec SA";
           }
           leaf mode {
             type ipsec-mode;
             default "transport";
             description
               "Туннельный или транспортный режим IPsec SA.";
           }
           leaf protocol-parameters {
             type ipsec-protocol-params;
             default "esp";
             description
               "Протокол защиты IPsec SA. Сейчас поддерживается лишь
                ESP, но возможно расширение в будущем.";
           }
           container esp-algorithms {
             when "../protocol-parameters = 'esp'";
             description
               "Конфигурация параметров и алгоритмов ESP.";
             leaf-list integrity {
               type intr-alg-t;
               default "0";
               ordered-by user;
               description
                 "Конфигурация аутентификации ESP на основе заданного
                  алгоритма защиты целостности. При шифровании AEAD узел
                  integrity не используется.";
               reference
                 "RFC 4303: IP Encapsulating Security Payload (ESP),
                            Section 3.2.";
             }
             list encryption {
               key "id";
               ordered-by user;
               leaf id {
                 type uint16;
                 description
                   "Идентификатор, однозначно указывающий каждую запись
                    списка, т. е. алгоритм шифрования и размер ключа
                    (если размер нужен).";
               }
               leaf algorithm-type {
                 type encr-alg-t;
                 default "20";
                 description
                   "По умолчанию 20 (ENCR_AES_GCM_16).";
               }
               leaf key-length {
                 type uint16;
                 default "128";
                 description
                   "По умолчанию размер ключа составляет 128 битов.";
               }
               description
                 "Алгоритмы шифрования или AEAD для IPsec SA. Список 
                  упорядочивается по снижению приоритета. При пустом 
                  списке шифрование не применяется (алгоритм NULL).";
               reference
                 "RFC 4303: IP Encapsulating Security Payload (ESP),
                            Section 3.2.";
             }
             leaf tfc-pad {
               type boolean;
               default "false";
               description
                 "Значение true разрешает заполнение для 
                  конфиденциальности трафика потока (Traffic Flow 
                  Confidentiality или TFC) при шифровании ESP, false
                  запрещает заполнение.";
               reference
                 "RFC 4303: IP Encapsulating Security Payload (ESP),
                            Section 2.7.";
             }
             reference
               "RFC 4303: IP Encapsulating Security Payload (ESP).";
           }
           container tunnel {
             when "../mode = 'tunnel'";
             uses tunnel-grouping;
             description
               "Определение конечных точек туннеля IPsec.";
           }
         }
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.1.2.";
       }
     }
   }
   <CODE ENDS>

5.2. Модуль ietf-i2nsf-ike

В этом параграфе описан модуль YANG для варианта с IKE.

5.2.1. Обзор модели данных

Модель, связанная с IKEv2, была создана на основе стандарта IKEv2 [RFC7296] и наблюдения за некоторыми реализациями с открытым кодом, такие как strongSwan [strongswan] и Libreswan [libreswan].

Модель PAD создана на основе параграфа 4.4.3 в [RFC4301]. Отметим, что многие реализации встраивают настройку PAD как часть настройки IKEv2.

Модель SPD в основном получена на основе параграфа 4.4.1 и Приложения D к [RFC4301].

Модель данных YANG для варианта с IKE задана в модуле ietf-i2nsf-ike, структура которого показана ниже с использованием нотации деревьев YANG из [RFC8340].

   module: ietf-i2nsf-ike
     +--rw ipsec-ike
       +--rw pad
       |  +--rw pad-entry* [name]
       |     +--rw name                           string
       |     +--rw (identity)
       |     |  +--:(ipv4-address)
       |     |  |  +--rw ipv4-address?            inet:ipv4-address
       |     |  +--:(ipv6-address)
       |     |  |  +--rw ipv6-address?            inet:ipv6-address
       |     |  +--:(fqdn-string)
       |     |  |  +--rw fqdn-string?             inet:domain-name
       |     |  +--:(rfc822-address-string)
       |     |  |  +--rw rfc822-address-string?   string
       |     |  +--:(dnx509)
       |     |  |  +--rw dnx509?                  binary
       |     |  +--:(gnx509)
       |     |  |  +--rw gnx509?                  binary
       |     |  +--:(id-key)
       |     |  |  +--rw id-key?                  binary
       |     |  +--:(id-null)
       |     |     +--rw id-null?                 empty
       |     +--rw auth-protocol?                 auth-protocol-type
       |     +--rw peer-authentication
       |        +--rw auth-method?         auth-method-type
       |        +--rw eap-method
       |        |  +--rw eap-type    uint64
       |        +--rw pre-shared
       |        |  +--rw secret?   yang:hex-string
       |        +--rw digital-signature
       |           +--rw ds-algorithm?           uint8
       |           +--rw (public-key)?
       |           |  +--:(raw-public-key)
       |           |  |  +--rw raw-public-key?   binary
       |           |  +--:(cert-data)
       |           |     +--rw cert-data?        binary
       |           +--rw private-key?            binary
       |           +--rw ca-data*                binary
       |           +--rw crl-data?               binary
       |           +--rw crl-uri?                inet:uri
       |           +--rw oscp-uri?               inet:uri
       +--rw conn-entry* [name]
       |  +--rw name                             string
       |  +--rw autostartup?                     autostartup-type
       |  +--rw initial-contact?                 boolean
       |  +--rw version?                         auth-protocol-type
       |  +--rw fragmentation
       |  |  +--rw enabled?   boolean
       |  |  +--rw mtu?      uint16
       |  +--rw ike-sa-lifetime-soft
       |  |  +--rw rekey-time?    uint32
       |  |  +--rw reauth-time?   uint32
       |  +--rw ike-sa-lifetime-hard
       |  |  +--rw over-time?   uint32
       |  +--rw ike-sa-intr-alg*  nsfikec:intr-alg-t
       |  +--rw ike-sa-encr-alg* [id]
       |  |  +--rw id                uint16
       |  |  +--rw algorithm-type?   nsfikec:encr-alg-t
       |  |  +--rw key-length?       uint16
       |  +--rw dh-group?                            fs-group
       |  +--rw half-open-ike-sa-timer?              uint32
       |  +--rw half-open-ike-sa-cookie-threshold?   uint32
       |  +--rw local
       |  |  +--rw local-pad-entry-name    string
       |  +--rw remote
       |  |  +--rw remote-pad-entry-name    string
       |  +--rw encapsulation-type
       |  |  +--rw espencap?   esp-encap
       |  |  +--rw sport?      inet:port-number
       |  |  +--rw dport?      inet:port-number
       |  |  +--rw oaddr*      inet:ip-address
       |  +--rw spd
       |  |  +--rw spd-entry* [name]
       |  |    +--rw name                   string
       |  |    +--rw ipsec-policy-config
       |  |      +--rw anti-replay-window-size?   uint32
       |  |      +--rw traffic-selector
       |  |      |  +--rw local-prefix      inet:ip-prefix
       |  |      |  +--rw remote-prefix     inet:ip-prefix
       |  |      |  +--rw inner-protocol?   ipsec-inner-protocol
       |  |      |  +--rw local-ports* [start end]
       |  |      |  |  +--rw start    inet:port-number
       |  |      |  |  +--rw end      inet:port-number
       |  |      |  +--rw remote-ports* [start end]
       |  |      |     +--rw start    inet:port-number
       |  |      |     +--rw end      inet:port-number
       |  |      +--rw processing-info
       |  |        +--rw action?         ipsec-spd-action
       |  |        +--rw ipsec-sa-cfg
       |  |         +--rw pfp-flag?              boolean
       |  |         +--rw ext-seq-num?           boolean
       |  |         +--rw seq-overflow?          boolean
       |  |         +--rw stateful-frag-check?   boolean
       |  |         +--rw mode?                  ipsec-mode
       |  |         +--rw protocol-parameters? ipsec-protocol-params
       |  |              +--rw esp-algorithms
       |  |              |  +--rw integrity*    intr-alg-t
       |  |              |  +--rw encryption* [id]
       |  |              |  |  +--rw id                uint16
       |  |              |  |  +--rw algorithm-type?   encr-alg-t
       |  |              |  |  +--rw key-length?       uint16
       |  |              |  +--rw tfc-pad?      boolean
       |  |              +--rw tunnel
       |  |                 +--rw local           inet:ip-address
       |  |                 +--rw remote          inet:ip-address
       |  |                 +--rw df-bit?         enumeration
       |  |                 +--rw bypass-dscp?    boolean
       |  |                 +--rw dscp-mapping* [id]
       |  |                    +--rw id            uint8
       |  |                    +--rw inner-dscp?   inet:dscp
       |  |                    +--rw outer-dscp?   inet:dscp
       |  +--rw child-sa-info
       |  |  +--rw fs-groups*                fs-group
       |  |  +--rw child-sa-lifetime-soft
       |  |  |  +--rw time?      uint32
       |  |  |  +--rw bytes?     yang:counter64
       |  |  |  +--rw packets?   uint32
       |  |  |  +--rw idle?      uint32
       |  |  |  +--rw action?    nsfikec:lifetime-action
       |  |  +--rw child-sa-lifetime-hard
       |  |     +--rw time?      uint32
       |  |     +--rw bytes?     yang:counter64
       |  |     +--rw packets?   uint32
       |  |     +--rw idle?      uint32
       |  +--ro state
       |     +--ro initiator?             boolean
       |     +--ro initiator-ikesa-spi?   ike-spi
       |     +--ro responder-ikesa-spi?   ike-spi
       |     +--ro nat-local?             boolean
       |     +--ro nat-remote?            boolean
       |     +--ro encapsulation-type
       |     |  +--ro espencap?   esp-encap
       |     |  +--ro sport?      inet:port-number
       |     |  +--ro dport?      inet:port-number
       |     |  +--ro oaddr*      inet:ip-address
       |     +--ro established?           uint64
       |     +--ro current-rekey-time?    uint64
       |     +--ro current-reauth-time?   uint64
       +--ro number-ike-sas
           +--ro total?               yang:gauge64
           +--ro half-open?           yang:gauge64
           +--ro half-open-cookies?   yang:gauge64

Модель данных YANG содержит уникальный контейнер ipsec-ike, определённый ниже. Он включает контейнер pad, служащий для настройки базы данных PAD с данными аутентификации для локальных и удалённых партнёров (NSF). Точнее, контейнер содержит список записей, каждая из которых указывает отождествление, метод аутентификации и свидетельства, которые партнёр (локальный или удалённый) будет применять. Таким образом, каждая запись содержит указанные сведения локального или удалённого элемента NSF. В результате контроллер I2NF может сохранять эти сведения.

Список conn-entry со сведениями о различных соединениях IKE, которые узел может поддерживать с другими партнёрами. Каждая запись для соединения состоит из большого числа параметров для настройки различных аспектов определённого соединения IKE между двумя партнёрами, аутентификационные данные локального и удалённого партнёра, конфигурацию IKE SA (мягкий и строгий срок действия, криптоалгоритмы и т. п.), список правил IPsec, описывающих тип защищаемого трафика (локальные и удалённые подсети и порты), способ защиты (ESP, туннельный или транспортный режим, криптоалгоритмы и т. п.), конфигурация Child SA (мягкий и строгий срок действия), сведения о состоянии соединения IKE (SPI, использование NAT, текущее время завершения срока действия и т. п.).

Контейнер ipsec-ike объявляет контейнер number-ike-sas для задания сообщаемых программами IKE сведений о состоянии, относящихся к числу организованных соединений IKE.

5.2.2. Пример использования

В Приложении A приведён пример конфигурации варианта NSF с IKE в туннельном режиме (шлюз-шлюз) с аутентификацией NSF на основе сертификатов X.509.

5.2.3. Модуль YANG

Этот модуль YANG включает нормативные ссылки на [RFC5280], [RFC4301], [RFC5915], [RFC6991], [RFC7296], [RFC7383], [RFC7427], [RFC7619], [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8229], [RFC8174], [RFC6960], [IKEv2-Auth-Method], [IKEv2-Transform-Type-4], [IKEv2-Parameters], [IANA-Method-Type].

   <CODE BEGINS> file "ietf-i2nsf-ike@2021-07-14.yang"
   module ietf-i2nsf-ike {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
     prefix nsfike;

     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-i2nsf-ikec {
       prefix nsfikec;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection
                    Based on Software-Defined Networking (SDN).";
     }
     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control
                    Model.";
     }

     organization
       "IETF I2NSF Working Group";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/> 
        WG List: <mailto:i2nsf@ietf.org> 

        Author: Rafael Marin-Lopez
                  <mailto:rafa@um.es> 

        Author: Gabriel Lopez-Millan
                  <mailto:gabilm@um.es> 

        Author: Fernando Pereniguez-Garcia
                  <mailto:fernando.pereniguez@cud.upct.es> 
       ";
     description
       "Этот модуль содержит модель для варианта IPsec IKE основанной на
        SDN службы защиты потоков IPsec.

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

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

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

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

     revision 2021-07-14 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection
                    Based on Software-Defined Networking (SDN).";
     }

     typedef ike-spi {
       type uint64 {
         range "0..max";
       }
       description
         "Индекс параметров защиты (SPI) IKE SA.";
       reference
         "RFC 7296: Internet Key Exchange Protocol Version 2
                    (IKEv2), Section 2.6.";
     }

     typedef autostartup-type {
       type enumeration {
         enum add {
           description
             "Конфигурация IKE/IPsec загружается в реализацию IKE, но 
              IKE/IPsec SA не запускается.";
         }
         enum on-demand {
           description
             "Конфигурация IKE/IPsec загружается в реализацию IKE.
              Павила IPsec переносятся в NSF, но IPsec SA не создаются
              сразу же. Реализация IKE будет согласовывать IPsec SA по
              мере необходимости (через уведомление ACQUIRE).";
         }
         enum start {
           description
             "Конфигурация IKE/IPsec загружается, переносится в ядро
              NSF и основанные на IKEv2 связи IPsec SA создаются сразу
              же (без ожидания).";
         }
       }
       description
         "Правила установки конфигурации IPsec SA в ядро NSF при запуске
          реализации IKEv2.";
     }

     typedef fs-group {
       type uint16;
       description
         "Группы DH для IKE и смены ключей IPsec SA.";
       reference
         "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
                IKEv2 Transform Attribute Types, Transform Type 4 -
                Diffie-Hellman Group Transform IDs
          RFC 7296: Internet Key Exchange Protocol Version 2
                    (IKEv2), Section 3.3.2.";
     }

     typedef auth-protocol-type {
       type enumeration {
         enum ikev2 {
           value 2;
           description
             "Протокол аутентификации IKEv2. Сейчас определён лишь 1
              протокол, но в будущем возможно расширение набора.";
         }
       }
       description
         "Версия протокола аутентификации IKE, заданная в базе(PAD).
          Она определена как enum для поддержки будущих версий IKE.";
       reference
         "RFC 7296: Internet Key Exchange Protocol Version 2
                    (IKEv2).";
     }

     typedef auth-method-type {
       type enumeration {
         enum pre-shared {
           description
             "Выбор аутентификации по заранее распространенным ключам.";
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2).";
         }
         enum eap {
           description
             "Выбор протокола (EAP) в качестве метода аутентификации.";
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2).";
         }
         enum digital-signature {
           description
             "Выбор цифровой подписи как метода аутентификации.";
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
              RFC 7427: Signature Authentication in the Internet Key
                        Exchange Version 2 (IKEv2).";
         }
         enum null {
           description
             "без аутентификации (Null).";
           reference
             "RFC 7619: The NULL Authentication Method in the Internet
                        Key Exchange Protocol Version 2 (IKEv2).";
         }
       }
       description
         "Метод аутентификации партнёра, указанный в PAD.";
     }

     container ipsec-ike {
       description
         "Конфигурация IKE для NSF, включающая параметры PAD, данные
          соединения IKE и состояния.";
       container pad {
         description
           "Конфигурация базы данных (PAD), каждая запись которой
            содержит данные конфигурации локального или удалённого 
            партнёра. Поэтому контроллер I2NSF сохраняет данные 
            аутентификации (и свидетельства) не только для локального,
            но и для удалённого элемента NSF. Локальный элемент NSF 
            МОЖЕТ применять одно отождествление для разных типов 
            аутентификации и свидетельств. Можно указать записи для 
            локального (например, A) и удалённого (например, B) элемента
            NSF, чтобы задать все требуемые данные для аутентификации
            между A и B (../conn-entry/local и ../conn-entry/remote).";
         list pad-entry {
           key "name";
           ordered-by user;
           description
             "Список записей базы данных PAD, упорядоченных контроллером
              I2NSF. Каждая запись однозначно указывается именем.";
           leaf name {
             type string;
             description
               "Уникальное в PAD имя данной записи.";
           }
           choice identity {
             mandatory true;
             description
               "Конкретный партнёр (локальный или удалённый) IKE будет 
                идентифицироваться по одному из этих отождествлений.";
             reference
               "RFC 4301: Security Architecture for the Internet
                          Protocol, Section 4.4.3.1.";
             case ipv4-address {
               leaf ipv4-address {
                 type inet:ipv4-address;
                 description
                   "Отождествление в виде 4-октетного адреса IPv4.";
               }
             }
             case ipv6-address {
               leaf ipv6-address {
                 type inet:ipv6-address;
                 description
                   "Отождествление в виде 16-октетного адреса IPv6,
                    например,2001:db8::8:800:200c:417a.";
               }
             }
             case fqdn-string {
               leaf fqdn-string {
                 type inet:domain-name;
                 description
                   "Отождествление в виде строки полного доменного имени
                    (FQDN), например, example.com. В строку НЕДОПУСТИМО
                    включать какие-либо терминаторы (NULL, CR и т. п.)";
               }
             }
             case rfc822-address-string {
               leaf rfc822-address-string {
                 type string;
                 description
                   "Отождествление в виде строки полного адреса 
                    электронной почты (RFC 5322), например, 
                    jsmith@example.com. В строку НЕДОПУСТИМО
                    включать какие-либо терминаторы (NULL, CR и т. п.)";
                 reference
                   "RFC 5322: Internet Message Format.";
               }
             }
             case dnx509 {
               leaf dnx509 {
                 type binary;
                 description
                   "Двоичное представление DER отличительного имени
                    ASN.1 X.500, как задано в IKEv2.";
                 reference
                   "RFC 5280: Internet X.509 Public Key Infrastructure
                              Certificate and Certificate Revocation
                              List (CRL) Profile
                    RFC 7296: Internet Key Exchange Protocol Version 2
                              (IKEv2), Section 3.5.";
               }
             }
             case gnx509 {
               leaf gnx509 {
                 type binary;
                 description
                   "Структура ASN.1 X.509 GeneralName, как задано в
                    RFC 5280, закодированная с использованием правил
                    ASN.1 DER в соответствии с ITU-T X.690.";
                 reference
                   "RFC 5280: Internet X.509 Public Key Infrastructure
                              Certificate and Certificate Revocation
                              List (CRL) Profile.";
               }
             }
             case id-key {
               leaf id-key {
                 type binary;
                 description
                   "Необрабатываемый (opaque) поток октетов, который
                    может служить для передачи фирменных сведений при
                    использовании фирменных типов аутентификации.";
                 reference
                   "RFC 7296: Internet Key Exchange Protocol Version 2
                              (IKEv2), Section 3.5.";
               }
             }
             case id-null {
               leaf id-null {
                 type empty;
                 description
                   "Применяется аутентификация ID_NULL, если не 
                    используются аутентификационные данные IKE.";
                 reference
                   "RFC 7619: The NULL Authentication Method in the
                              Internet Key Exchange Protocol Version 2
                              (IKEv2).";
               }
             }
           }
           leaf auth-protocol {
             type auth-protocol-type;
             default "ikev2";
             description
               "Сейчас поддерживается только IKEv2, но в будущем
                возможны иные протоколы аутентификации.";
           }
           container peer-authentication {
             description
               "Позволяет контроллеру безопасности настроить метод
                аутентификации (заранее распространённый ключ, eap, 
                цифровая подпись, null), который будет применяться
                для конкретного партнёра, и используемые свидетельства
                в зависимости от выбранного метода аутентификации.";
             leaf auth-method {
               type auth-method-type;
               default "pre-shared";
               description
                 "Тип метода аутентификации (заранее распространенный
                  ключ, eap, цифровая подпись, null).";
               reference
                 "RFC 7296: Internet Key Exchange Protocol Version 2
                            (IKEv2), Section 2.15.";
             }
             container eap-method {
               when "../auth-method = 'eap'";
               leaf eap-type {
                 type uint32 {
                   range "1 .. 4294967295";
                 }
                 mandatory true;
                 description
                   "Тип метода EAP, заданный значением из реестра IANA.
                    В зависимости от метода EAP может применяться ключ
                    PSK или сертификаты.";
               }
               description
                 "Описание метода EAP, используемого при значении eap.";
               reference
                 "IANA: Extensible Authentication Protocol (EAP)
                        Registry, Method Types
                  RFC 7296: Internet Key Exchange Protocol Version 2
                            (IKEv2), Section 2.16.";
             }
             container pre-shared {
               when "../auth-method[.='pre-shared' or
                     .='eap']";
               leaf secret {
                 nacm:default-deny-all;
                 type yang:hex-string;
                 description
                   "Значение ключа PSK. NSF не разрешает считывание 
                    этого значения из соображений безопасности. Значение
                    ДОЛЖНО устанавливаться, если метод EAP использует 
                    заранее распространённый ключ или выбран метод 
                    аутентификации pre-shared.";
               }
               description
                 "Значение секретного ключа для аутентификации PSK или
                  EAP на основе PSK.";
             }
             container digital-signature {
               when "../auth-method[.='digital-signature'
                     or .='eap']";
               leaf ds-algorithm {
                 type uint8;
                 default "14";
                 description
                   "Алгоритм цифровой подписи, заданный значением из
                    реестра IANA. По умолчанию применяется базовый метод
                    цифровой подписи. В зависимости от алгоритма ДОЛЖНЫ
                    указываться последующие листья. Например, если метод
                    EAP или цифровая подпись включает сертификат, листья
                    cert-data и private-key будут содержать информацию";
                 reference
                   "IANA: Internet Key Exchange Version 2 (IKEv2)
                          Parameters, IKEv2 Authentication Method.";
               }
               choice public-key {
                 leaf raw-public-key {
                   type binary;
                   description
                     "Двоичное значение открытого ключа, интерпретация
                      которого определяется алгоритмом цифровой подписи.
                      Например, ключ RSA представляет RSAPublicKey в 
                      соответствии с RFC 8017 а криптографию с 
                      эллиптической кривой (ECC) — publicKey, как
                      указано в RFC 5915.";
                   reference
                     "RFC 5915: Elliptic Curve Private Key Structure
                      RFC 8017: PKCS #1: RSA Cryptography
                                Specifications Version 2.2.";
                 }
                 leaf cert-data {
                   type binary;
                   description
                     "Данные сертификата X.509 в формате DER. Если задан
                      raw-public-key, этот лист будет пустым.";
                   reference
                     "RFC 5280: Internet X.509 Public Key
                                Infrastructure Certificate
                                and Certificate Revocation
                                List (CRL) Profile.";
                 }
                 description
                   "Если контроллер I2NSF знает, что NSF уже владеет
                    секретным ключом, связанным с данным открытым ключом
                    (например, NSF создаёт пару ключей по отдельному
                    каналу), будет настраиваться лишь один из листьев 
                    данного choice, но не лист private-key. По открытому
                    ключу NSF может определить секретный ключ для
                    использования.";
               }
               leaf private-key {
                 nacm:default-deny-all;
                 type binary;
                 description
                   "Двоичное значение секретного ключа, интерпретация
                    которого определяется алгоритмом цифровой подписи.
                    Например, ключ RSA представляет RSAPublicKey в 
                    соответствии с RFC 8017 а криптографию с 
                    эллиптической кривой (ECC) — publicKey, как указано
                    в RFC 5915. Это значение устанавливается, если
                    определён открытый ключ и контроллер I2NSF отвечает
                    за настройку секретного ключа. В иных случаях лист
                    не задаётся и значение хранится в секрете.";
                 reference
                   "RFC 5915: Elliptic Curve Private Key Structure
                    RFC 8017: PKCS #1: RSA Cryptography
                              Specifications Version 2.2.";
               }
               leaf-list ca-data {
                 type binary;
                 description
                   "Список сертификатов доверенных удостоверяющих 
                    центров (CA) в кодировке ASN.1 (DER). По умолчанию
                    пустое значение.";
               }
               leaf crl-data {
                 type binary;
                 description
                   "Структура CertificateList, как задано в RFC 5280,
                    в представлении ASN.1 (DER)в соответствии с ITU-T
                    X.690. По умолчанию пустое значение.";
                 reference
                   "RFC 5280: Internet X.509 Public Key Infrastructure
                              Certificate and Certificate Revocation
                              List (CRL) Profile.";
               }
               leaf crl-uri {
                 type inet:uri;
                 description
                   "URI списка отзыва сертификатов X.509 (CRL).
                    По умолчанию пустое значение.";
                 reference
                   "RFC 5280: Internet X.509 Public Key Infrastructure
                              Certificate and Certificate Revocation
                              List (CRL) Profile.";
               }
               leaf oscp-uri {
                 type inet:uri;
                 description
                   "URI протокола статуса сертификатов OCSP. 
                    По умолчанию пустое значение.";
                 reference
                   "RFC 6960: X.509 Internet Public Key Infrastructure
                              Online Certificate Status Protocol - OCSP
                    RFC 5280: Internet X.509 Public Key Infrastructure
                              Certificate and Certificate Revocation
                              List (CRL) Profile.";
               }
               description
                 "Контейнер digital-signature.";
             } /*Контейнер digital-signature*/
           } /*Контейнер peer-authentication*/
         }
       }
       list conn-entry {
         key "name";
         description
           "Список сведений о соединениях IKE с партнёрами. Список
            поддерживается в реальном масштабе времени по мере создания
            IKE SA с этими узлами.";
         leaf name {
           type string;
           description
             "Идентификатор записи для соединения.";
         }
         leaf autostartup {
           type autostartup-type;
           default "add";
           description
             "По умолчанию лишь добавляется конфигурация без запуска 
              защищённой связи.";
         }
         leaf initial-contact {
           type boolean;
           default "false";
           description
             "Значение true отключает использование уведомлений
              INITIAL_CONTACT. При значении false использование 
              INITIAL_CONTACT зависит от реализации IKEv2.";
         }
         leaf version {
           type auth-protocol-type;
           default "ikev2";
           description
             "Версия IKE (поддерживается лишь версия 2).";
         }
         container fragmentation {
           leaf enabled {
             type boolean;
             default "false";
             description
               "Управляет фрагментацией IKEv2 (true или false).";
             reference
               "RFC 7383: Internet Key Exchange Protocol Version 2
                          (IKEv2) Message Fragmentation.";
           }
           leaf mtu {
             when "../enabled='true'";
             type uint16 {
               range "68..65535";
             }
             description
               "MTU для использования при фрагментации IKEv2.";
             reference
               "RFC 7383: Internet Key Exchange Protocol Version 2
                          (IKEv2) Message Fragmentation.";
           }
           description
             "Фрагментация IKEv2 в соответствии с RFC 7383. Если 
              фрагментация IKEv2 разрешена, можно задать MTU.";
         }
         container ike-sa-lifetime-soft {
           description
             "Мягкий срок действия IKE SA. Можно задать два значения -
              время смены ключей IKE SA или время новой аутентификации
              IKE SA.";
           leaf rekey-time {
             type uint32;
             units "seconds";
             default "0";
             description
               "Число секунд между сменами ключей IKE SA. Значение 0
                указывает неограниченный срок действия ключей.";
           }
           leaf reauth-time {
             type uint32;
             units "seconds";
             default "0";
             description
               "Интервал повторной аутентификации IKE SA (в секундах)
                Значение 0 указывает неограниченный срок действия.";
           }
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2), Section 2.8.";
         }
         container ike-sa-lifetime-hard {
           description
             "Жёсткий срок действия IKE SA, по истечении которого
              IKE SA удаляется.";
           leaf over-time {
             type uint32;
             units "seconds";
             default "0";
             description
               "Срок действия IKE SA в секундах. Значение 0
                указывает неограниченный срок действия.";
           }
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2).";
         }
         leaf-list ike-sa-intr-alg {
           type nsfikec:intr-alg-t;
           default "12";
           ordered-by user;
           description
             "Алгоритм защиты целостности для организации IKE SA. Список
              упорядочен по снижению приоритета. По умолчанию задано
              значение 12 (AUTH_HMAC_SHA2_256_128).";
         }
         list ike-sa-encr-alg {
           key "id";
           min-elements 1;
           ordered-by user;
           leaf id {
             type uint16;
             description
               "Идентификатор, однозначно указывающий каждую запись
                списка, т. е. алгоритм шифрования и размер ключа
                (если размер нужен).";
           }
           leaf algorithm-type {
             type nsfikec:encr-alg-t;
             default "12";
             description
               "Принятое по умолчанию значение 12 (ENCR_AES_CBC).";
           }
           leaf key-length {
             type uint16;
             default "128";
             description
               "По умолчанию ключ имеет размер 128 битов.";
           }
           description
             "Алгоритм шифрования или AEAD для IKE SA. Список
              упорядочен по снижению приоритета.";
         }
         leaf dh-group {
           type fs-group;
           default "14";
           description
             "Номер группы показателя Диффи-Хеллмана для применения в
              IKE_SA_INIT при обмене ключами IKE SA.";
         }
         leaf half-open-ike-sa-timer {
           type uint32;
           units "seconds";
           default "0";
           description
             "Тайм-аут полуоткрытой IKE SA. Значение 0 указывает
              неограниченный срок.";
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2), Section 2.";
         }
         leaf half-open-ike-sa-cookie-threshold {
           type uint32;
           default "0";
           description
             "Число полуоткрытых IKE SA, активирующее механизм cookie.
              Значение 0 предполагает неограниченное число.";
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2), Section 2.6.";
         }
         container local {
           leaf local-pad-entry-name {
             type string;
             mandatory true;
             description
               "Имя записи PAD, в которой хранятся данные аутентификации
                конкретного локального партнёра. Значение ДОЛЖНО 
                совпадать с pad-entry-name.";
           }
           description
             "Данные аутентификации локального партнёра.";
         }
         container remote {
           leaf remote-pad-entry-name {
             type string;
             mandatory true;
             description
               "Имя записи PAD, в которой хранятся данные аутентификации
                конкретного удалённого партнёра. Значение ДОЛЖНО 
                совпадать с pad-entry-name.";
           }
           description
             "Данные аутентификации удаленного партнёра.";
         }
         container encapsulation-type {
           uses nsfikec:encap;
           description
             "Конфигурационные сведения о портах источника и получателя,
              которые следует использовать при инкапсуляции IKE, и тип
              инкапсуляции, который следует применять при работе через
              NAT. Это лишь рекомендация, поскольку реализация IKE 
              может выбрать иную инкапсуляцию, как указано в RFC 8229.";
           reference
             "RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
         }
         container spd {
           description
             "Конфигурация базы правил безопасности (SPD). Эти основные
              помещаются в группировку ipsec-policy-grouping.";
           list spd-entry {
             key "name";
             ordered-by user;
             leaf name {
               type string;
               description
                 "Уникальное имя записи SPD для задания политики IPsec";
             }
             container ipsec-policy-config {
               description
                 "Контейнер конфигурации политики IPsec.";
               uses nsfikec:ipsec-policy-grouping;
             }
             description
               "Список записей, представляющих SPD. Поскольку в этом
                случае NSF реализует IKE, требуется лишь передать 
                политику IPsec от локального элемента NSF к удалённому.
                Реализация IKE будет помещать правила IPsec в ядро NSF
                для обоих направления (входного и выходного) и создавать
                соответствующие IPsec SA на основе сведений из SPD.";
           }
           reference
             "RFC 7296: Internet Key Exchange Protocol Version 2
                        (IKEv2), Section 2.9.";
         }
         container child-sa-info {
           leaf-list fs-groups {
             type fs-group;
             default "0";
             ordered-by user;
             description
               "Ненулевое значение указывает необходимость полной защиты
                (forward secrecy) при создании IPsec SA и задаёт номер
                группы для процесса обмена ключами для достижения полной
                защиты. Список упорядочивается по снижению приоритета.";
           }
           container child-sa-lifetime-soft {
             description
               "Мягкий срок действия IPsec SA, по достижении которого
                выполняется действие, заданное листом action.";
             uses nsfikec:lifetime;
             leaf action {
               type nsfikec:lifetime-action;
               default "replace";
               description
                 "По завершении срока IPsec SA нужно выполнить данное
                  действие по отношению к IPsec SA. Возможны 3 варианта:
                  terminate-clear, terminate-hold, replace.";
               reference
                 "RFC 4301: Security Architecture for the Internet
                            Protocol, Section 4.5
                  RFC 7296: Internet Key Exchange Protocol Version 2
                            (IKEv2), Section 2.8.";
             }
           }
           container child-sa-lifetime-hard {
             description
               "Жёсткий срок действия IPsec SA, по истечение которого
                IPsec SA прерывается.";
             uses nsfikec:lifetime;
             reference
               "RFC 7296: Internet Key Exchange Protocol Version 2
                          (IKEv2), Section 2.8.";
           }
           description
             "Сведения для IPsec SA, включающие группу полной защиты
              (PFS) и интервал замены ключей IPsec SA.";
         }
         container state {
           config false;
           leaf initiator {
             type boolean;
             description
               "Роль инициатора для данного соединения.";
           }
           leaf initiator-ikesa-spi {
             type ike-spi;
             description
               "IKE SA SPI инициатора.";
           }
           leaf responder-ikesa-spi {
             type ike-spi;
             description
               "IKE SA SPI ответчика.";
           }
           leaf nat-local {
             type boolean;
             description
               "Значение true указывает размещение локальной конечной 
                точки за NAT.";
           }
           leaf nat-remote {
             type boolean;
             description
               "Значение true указывает размещение удалённой конечной 
                точки за NAT.";
           }
           container encapsulation-type {
             uses nsfikec:encap;
             description
               "Сведения о портах отправителя и получателя, используемых
                при инкапсуляции IKE, и тип инкапсуляции при работе
                через NAT.";
             reference
               "RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
           }
           leaf established {
             type uint64;
             units "seconds";
             description
               "Число секунд с момента создания IKE SA.";
           }
           leaf current-rekey-time {
             type uint64;
             units "seconds";
             description
               "Число секунд до смены ключей IKE SA.";
           }
           leaf current-reauth-time {
             type uint64;
             units "seconds";
             description
               "Число секунд до новой аутентификации IKE SA.";
           }
           description
             "Данные состояния IKE для конкретного соединения.";
         } /* ike-sa-state */
       } /* ike-conn-entries */
       container number-ike-sas {
         config false;
         leaf total {
           type yang:gauge64;
           description
             "Общее число активных IKE SA.";
         }
         leaf half-open {
           type yang:gauge64;
           description
             "Число полуоткрытых активных IKE SA.";
         }
         leaf half-open-cookies {
           type yang:gauge64;
           description
             "Число полуоткрытых активных IKE SA с cookie.";
         }
         description
           "Общие сведения о IKE SA, в частности, текущее число IKE SA";
       }
     } /* Контейнер ipsec-ike */
   }
   <CODE ENDS>

5.3. Модуль ietf-i2nsf-ikeless

В этом параграфе описан модуль YANG для варианта без IKE.

5.3.1. Обзор модели данных

Для этого варианта определение модели SPD в основном взято из параграфа 4.4.1 и Приложения D в [RFC4301], но внесены указанные ниже изменения.

  • Для простоты каждое правило IPsec (spd-entry) содержит один селектор трафика вместо их списка. Причина заключается в том, что фактические реализации ядра представляют лишь один селектор трафика на правило.

  • Каждое правило IPsec включает идентификатор (reqid) для связывания с IPsec SA, как принято в Linux.

  • Каждое правило IPsec имеет лишь одно имя, а не список имён.

  • Удалены комбинированные алгоритмы, поскольку для шифрования можно применять алгоритмы AEAD.

  • Туннельные данные были расширены отображением DSCP, поскольку некоторые реализации ядер разрешают настраивать эти значения.

Определение модели SAD в основном взято из параграфа 4.4.2 в [RFC4301], но внесены указанные ниже изменения.

  • Для простоты каждое правило IPsec (spd-entry) содержит один селектор трафика вместо их списка. Причина заключается в том, что фактические реализации ядра представляют лишь один селектор трафика на правило.

  • Каждая IPsec SA включает идентификатор (reqid) для связывания IPsec SA с правилом IPsec. Причиной послужила возможность включения этого значения во многих реализациях ядра.

  • IPsec SA именуются так же, как правила IPsec.

  • Модель поддерживает задание алгоритма шифрования, которым может быть AEAD или иной (не AEAD) алгоритм. При указании алгоритма AEAD не требуется задавать алгоритм защиты целостности, для иных алгоритмов он требуется [RFC8221].

  • Туннельные данные были расширены отображением DSCP. Предполагается, что NSF, охватываемые этим документом, обеспечивают полную функциональность ECN для предотвращения отбрасывания уведомлений ECN о перегрузках [RFC6040].

  • Срок действия IPsec SA может задаваться временем простоя или числом пакетов IP в качестве порога для триггера. Это обусловлено поддержкой фактическими реализациями ядер установки таких триггеров.

  • Включены данные для настройки типа инкапсуляции (encapsulation-type) для пакетов IPsec ESP (UDP [RFC3948] или TCP [RFC8229]).

Модель уведомлений определена на основе спецификации PF_KEYv2 [RFC2367].

Модель данных YANG для варианта без IKE задана в модуле ietf-i2nsf-ikeless, структура которого показана ниже в форме дерева YANG с нотацией [RFC8340].

   module: ietf-i2nsf-ikeless
     +--rw ipsec-ikeless
       +--rw spd
       |  +--rw spd-entry* [name]
       |     +--rw name  string
       |     +--rw direction nsfikec:ipsec-traffic-direction
       |     +--rw reqid? uint64
       |     +--rw ipsec-policy-config
       |        +--rw anti-replay-window-size?   uint32
       |        +--rw traffic-selector
       |        |  +--rw local-prefix      inet:ip-prefix
       |        |  +--rw remote-prefix     inet:ip-prefix
       |        |  +--rw inner-protocol?   ipsec-inner-protocol
       |        |  +--rw local-ports* [start end]
       |        |  |  +--rw start    inet:port-number
       |        |  |  +--rw end      inet:port-number
       |        |  +--rw remote-ports* [start end]
       |        |     +--rw start    inet:port-number
       |        |     +--rw end      inet:port-number
       |        +--rw processing-info
       |           +--rw action?         ipsec-spd-action
       |           +--rw ipsec-sa-cfg
       |             +--rw pfp-flag?              boolean
       |             +--rw ext-seq-num?           boolean
       |             +--rw seq-overflow?          boolean
       |             +--rw stateful-frag-check?   boolean
       |             +--rw mode?                  ipsec-mode
       |             +--rw protocol-parameters? ipsec-protocol-params
       |              +--rw esp-algorithms
       |              |  +--rw integrity*    intr-alg-t
       |              |  +--rw encryption* [id]
       |              |  |  +--rw id                uint16
       |              |  |  +--rw algorithm-type?   encr-alg-t
       |              |  |  +--rw key-length?       uint16
       |              |  +--rw tfc-pad?      boolean
       |              +--rw tunnel
       |                 +--rw local           inet:ip-address
       |                 +--rw remote          inet:ip-address
       |                 +--rw df-bit?         enumeration
       |                 +--rw bypass-dscp?    boolean
       |                 +--rw dscp-mapping* [id]
       |                    +--rw id            uint8
       |                    +--rw inner-dscp?   inet:dscp
       |                    +--rw outer-dscp?   inet:dscp
       +--rw sad
         +--rw sad-entry* [name]
          +--rw name               string
          +--rw reqid?             uint64
          +--rw ipsec-sa-config
          |  +--rw spi                        uint32
          |  +--rw ext-seq-num?               boolean
          |  +--rw seq-overflow?              boolean
          |  +--rw anti-replay-window-size?   uint32
          |  +--rw traffic-selector
          |  |  +--rw local-prefix      inet:ip-prefix
          |  |  +--rw remote-prefix     inet:ip-prefix
          |  |  +--rw inner-protocol?   ipsec-inner-protocol
          |  |  +--rw local-ports* [start end]
          |  |  |  +--rw start    inet:port-number
          |  |  |  +--rw end      inet:port-number
          |  |  +--rw remote-ports* [start end]
          |  |     +--rw start    inet:port-number
          |  |     +--rw end      inet:port-number
          |  +--rw protocol-parameters? nsfikec:ipsec-protocol-params
          |  +--rw mode?                      nsfikec:ipsec-mode
          |  +--rw esp-sa
          |  |  +--rw encryption
          |  |  |  +--rw encryption-algorithm?   nsfikec:encr-alg-t
          |  |  |  +--rw key?                    yang:hex-string
          |  |  |  +--rw iv?                     yang:hex-string
          |  |  +--rw integrity
          |  |     +--rw integrity-algorithm?   nsfikec:intr-alg-t
          |  |     +--rw key?                   yang:hex-string
          |  +--rw sa-lifetime-hard
          |  |  +--rw time?      uint32
          |  |  +--rw bytes?     yang:counter64
          |  |  +--rw packets?   uint32
          |  |  +--rw idle?      uint32
          |  +--rw sa-lifetime-soft
          |  |  +--rw time?      uint32
          |  |  +--rw bytes?     yang:counter64
          |  |  +--rw packets?   uint32
          |  |  +--rw idle?      uint32
          |  |  +--rw action?    nsfikec:lifetime-action
          |  +--rw tunnel
          |  |  +--rw local           inet:ip-address
          |  |  +--rw remote          inet:ip-address
          |  |  +--rw df-bit?         enumeration
          |  |  +--rw bypass-dscp?    boolean
          |  |  +--rw dscp-mapping* [id]
          |  |  |  +--rw id            uint8
          |  |  |  +--rw inner-dscp?   inet:dscp
          |  |  |  +--rw outer-dscp?   inet:dscp
          |  |  +--rw dscp-values*    inet:dscp
          |  +--rw encapsulation-type
          |     +--rw espencap?   esp-encap
          |     +--rw sport?      inet:port-number
          |     +--rw dport?      inet:port-number
          |     +--rw oaddr*      inet:ip-address
          +--ro ipsec-sa-state
             +--ro sa-lifetime-current
             |  +--ro time?      uint32
             |  +--ro bytes?     yang:counter64
             |  +--ro packets?   uint32
             |  +--ro idle?      uint32
             +--ro replay-stats
                +--ro replay-window
                |  +--ro w?   uint32
                |  +--ro t?   uint64
                |  +--ro b?   uint64
                +--ro packet-dropped?       yang:counter64
                +--ro failed?               yang:counter64
                +--ro seq-number-counter?   uint64

      notifications:
        +---n sadb-acquire {ikeless-notification}?
        |  +--ro ipsec-policy-name    string
        |  +--ro traffic-selector
        |     +--ro local-prefix      inet:ip-prefix
        |     +--ro remote-prefix     inet:ip-prefix
        |     +--ro inner-protocol?   ipsec-inner-protocol
        |     +--ro local-ports* [start end]
        |     |  +--ro start    inet:port-number
        |     |  +--ro end      inet:port-number
        |     +--ro remote-ports* [start end]
        |        +--ro start    inet:port-number
        |        +--ro end      inet:port-number
        +---n sadb-expire {ikeless-notification}?
        |  +--ro ipsec-sa-name           string
        |  +--ro soft-lifetime-expire?   boolean
        |  +--ro lifetime-current
        |     +--ro time?      uint32
        |     +--ro bytes?     yang:counter64
        |     +--ro packets?   uint32
        |     +--ro idle?      uint32
        +---n sadb-seq-overflow {ikeless-notification}?
        |  +--ro ipsec-sa-name    string
        +---n sadb-bad-spi {ikeless-notification}?
           +--ro spi    uint32

Модель данных YANG содержит уникальный контейнер ipsec-ikeless, включающий контейнеры spd и sad. В контейнере spd содержится список записей базы правил безопасности SPD. По сравнению с моделью YANG для варианта с IKE эта часть задаёт несколько дополнительных параметров, требуемых из-за отсутствия программ IKE в NSF — направление трафика для применения правила IPsec и значение reqid для привязки правила IPsec к IPsec SA, поскольку иначе поиск будет затруднён. Контейнер sad содержит список записей базы защищённых связей SAD. Обычно каждая запись позволяет указать данные конфигурации (SPI, селекторы трафика, туннельный или транспортный режим, криптоалгоритмы и ключевой материал, мягкий и жёсткий срок действия и т. п.), а также данные состояния (оставшийся срок действия, статистика повторов и т. п) конкретной IPsec SA.

Кроме того, модуль определяет набор уведомлений, позволяющих элементу NSF информировать контроллер I2NSF о соответствующих событиях, таких как завершение срока действия IPsec SA, переполнение порядкового номера, недопустимый индекс SPI в полученном пакете.

5.3.2. Пример использования

В Приложении B приведён пример конфигурации NSF в транспортном режиме (хост-хост) без IKE, а в Приложении C — примеры уведомлений о получении и завершении срока действия IPsec SA, переполнении порядкового номера, некорректных SPI.

5.3.3. Модуль YANG

Этот модуль YANG включает нормативные ссылки на [RFC4301], [RFC4303], [RFC6991], [RFC8174] и [RFC8341].

   <CODE BEGINS> file "ietf-i2nsf-ikeless@2021-07-14.yang"
   module ietf-i2nsf-ikeless {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
     prefix nsfikels;

     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-i2nsf-ikec {
       prefix nsfikec;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection
                    Based on Software-Defined Networking (SDN).";
     }
     import ietf-netconf-acm {
       prefix nacm;
       reference
         "RFC 8341: Network Configuration Access Control Model.";
     }

     organization
       "IETF I2NSF Working Group";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/i2nsf/> 
        WG List: <mailto:i2nsf@ietf.org> 

        Author: Rafael Marin-Lopez
                 <mailto:rafa@um.es> 

        Author: Gabriel Lopez-Millan
                 <mailto:gabilm@um.es> 

        Author: Fernando Pereniguez-Garcia
                 <mailto:fernando.pereniguez@cud.upct.es> 
       ";
     description
       "Модель данных для основанной на SDN службы защиты потоков IPsec
        без IKE.

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

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

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

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

     revision 2021-07-14 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection
                    Based on Software-Defined Networking (SDN).";
     }

     feature ikeless-notification {
       description
         "Указывает поддержку сервером генерации уведомлений в модуле
          ikeless. Для расширения применимости модуля уведомления
          заданы как свойства (feature). Для реализаций без IKE 
          предполагается поддержка этих свойств в NSF.";
     }

     container ipsec-ikeless {
       description
         "Контейнер для настройки варианта без IKE, содержащий 
          контейнеры spd и sad. Первый позволяет контроллеру I2NSF
          настраивать правила IPsec в базе данных SPD, а второй -
          настраивать IPsec SA в базе данных SAD.";
       reference
         "RFC 4301: Security Architecture for the Internet Protocol.";
       container spd {
         description
           "Конфигурация базы правил безопасности (SPD).";
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.1.2.";
         list spd-entry {
           key "name";
           ordered-by user;
           leaf name {
             type string;
             description
               "Уникальное имя записи SPD.";
           }
           leaf direction {
             type nsfikec:ipsec-traffic-direction;
             mandatory true;
             description
               "Входящий или исходящий трафик. В варианте без IKE
                контроллеру I2NSF нужно задавать направления для правил,
                применяемых в NSF. В варианте с IKE это направление
                задавать не нужно, поскольку IKE определяет его.";
           }
           leaf reqid {
             type uint64;
             default "0";
             description
               "Связывает правило IPsec с IPsec SA с тем же reqid. Это
                нужно только в варианте без IKE поскольку в варианте с 
                IKE это будет внутренняя привязка IKE.";
           }
           container ipsec-policy-config {
             description
               "Контейнер с конфигурацией политики IPsec.";
             uses nsfikec:ipsec-policy-grouping;
           }
           description
             "SPD представляется списком записей, каждая из которых 
              задаёт правило IPsec.";
         } /*Список spd-entry*/
       } /*Контейнер spd*/
       container sad {
         description
           "Конфигурация базы данных IPsec SAD.";
         reference
           "RFC 4301: Security Architecture for the Internet Protocol,
                      Section 4.4.2.1.";
         list sad-entry {
           key "name";
           ordered-by user;
           leaf name {
             type string;
             description
               "Имя записи в базе SAD.";
           }
           leaf reqid {
             type uint64;
             default "0";
             description
               "Связывает IPsec SA с правилом IPsec с тем же reqid.";
           }
           container ipsec-sa-config {
             description
               "Контейнер для настройки деталей IPsec SA.";
             leaf spi {
               type uint32 {
                 range "0..max";
               }
               mandatory true;
               description
                 "Индекс параметров безопасности (SPI) для IPsec SA.";
             }
             leaf ext-seq-num {
               type boolean;
               default "true";
               description
                 "Значение true указывает использование в этой IPsec SA 
                  расширенных порядковых номеров (64 бита), false 
                  указывает обычные порядковые номера (32 бита).";
             }
             leaf seq-overflow {
               type boolean;
               default "false";
               description
                 "Флаг, управляющей дальнейшей передачей пакетов при 
                  переполнении счётчика порядковых номеров IPsec SA. 
                  Значение false запрещает дальнейшую передачу и требует
                  замены ключей, true разрешает продолжать. При
                  использовании AEAD (лист esp-algorithms/encryption/
                  algorithm-type) этот флаг ДОЛЖЕН иметь значение false.
                  Устанавливать true настоятельно не рекомендуется.";
             }
             leaf anti-replay-window-size {
               type uint32;
               default "64";
               description
                 "Размер окна anti-replay, по умолчанию 64 в
                  соответствии с рекомендациями RFC 4303.";
               reference
                 "RFC 4303: IP Encapsulating Security Payload (ESP),
                            Section 3.4.3.";
             }
             container traffic-selector {
               uses nsfikec:selector-grouping;
               description
                 "Селектор трафика IPsec SA.";
             }
             leaf protocol-parameters {
               type nsfikec:ipsec-protocol-params;
               default "esp";
               description
                 "Протокол защиты для IPsec SA (пока лишь ESP).";
             }
             leaf mode {
               type nsfikec:ipsec-mode;
               default "transport";
               description
                 "Туннельный или транспортный режим.";
             }
             container esp-sa {
               when "../protocol-parameters = 'esp'";
               description
                 "Для IPsec SA с ESP требуется задать алгоритмы
                  шифрования и защиты целостности, а также ключевой
                  материал.";
               container encryption {
                 description
                   "Настройка алгоритма шифрования или AEAD для IPsec
                    ESP.";
                 leaf encryption-algorithm {
                   type nsfikec:encr-alg-t;
                   default "12";
                   description
                     "Настройка шифрования ESP. Для алгоритмов AEAD лист
                      integrity-algorithm не используется.";
                 }
                 leaf key {
                   nacm:default-deny-all;
                   type yang:hex-string;
                   description
                     "Ключ шифрования ESP. Если лист не задан, ключ 
                      шифрования не определён (например, NULL). Размер 
                      ключа определяется заданным здесь значением, по
                      умолчанию размер ключа составляет 128 битов.";
                 }
                 leaf iv {
                   nacm:default-deny-all;
                   type yang:hex-string;
                   description
                     "Значение вектора инициализации (IV) для шифрования
                      ESP. Если этот лист не задан, значение IV не
                      определено (например, шифрование NULL).";
                 }
               }
               container integrity {
                 description
                   "Настройка защиты целостности для IPsec ESP. Этот
                    контейнер позволяет настроить защиту целостности,
                    если она нужна, а алгоритм AEAD не применяется.";
                 leaf integrity-algorithm {
                   type nsfikec:intr-alg-t;
                   default "12";
                   description
                     "Алгоритм аутентификации сообщений (MAC) для защиты
                      целостности в ESP (по умолчанию 
                      AUTH_HMAC_SHA2_256_128). С алгоритмами AEAD этот
                      лист не используется.";
                 }
                 leaf key {
                   nacm:default-deny-all;
                   type yang:hex-string;
                   description
                     "Значение ключа защиты целостности ESP. Если этот 
                      лист не задан, ключ будет не определён (например,
                      выбран алгоритм AEAD и алгоритм защиты целостности
                      не нужен). Размер определяется выбранным ключом.";
                 }
               }
             } /*Контейнер esp-sa*/
             container sa-lifetime-hard {
               description
                 "Жёсткий срок действия IPsec SA, по завершении которого
                  связь разрывается и удерживается (hold).";
               uses nsfikec:lifetime;
             }
             container sa-lifetime-soft {
               description
                 "Мягкий срок действия IPsec SA.";
               uses nsfikec:lifetime;
               leaf action {
                 type nsfikec:lifetime-action;
                 description
                   "Действие по окончании срока: terminate-clear,
                    terminate-hold, replace.";
               }
             }
             container tunnel {
               when "../mode = 'tunnel'";
               uses nsfikec:tunnel-grouping;
               leaf-list dscp-values {
                 type inet:dscp;
                 description
                   "Значения DSCP, разрешённые для внутренних пакетов, 
                    передаваемых через IPsec SA. Если значение не 
                    задано, применяется фильтрация DSCP. При
                    ../bypass-dscp false и наличии dscp-mapping каждое
                    значение здесь будет совпадать с внутренним кодом
                    DSCP для отображения DSCP (список dscp-mapping).";
                 reference
                   "RFC 4301: Security Architecture for the Internet
                              Protocol, Section 4.4.2.1.";
               }
               description
                 "Конечные точки туннеля IPsec.";
             }
             container encapsulation-type {
               uses nsfikec:encap;
               description
                 "Контейнер с данными настройки для портов отправителя и
                  получателя, которые будут применяться для инкапсуляции
                  ESP и тип инкапсуляции при работе через NAT.";
             }
           } /*ipsec-sa-config*/
           container ipsec-sa-state {
             config false;
             description
               "Контейнер данных состояния IPsec SA.";
             container sa-lifetime-current {
               uses nsfikec:lifetime;
               description
                 "Текущий срок действия SAD.";
             }
             container replay-stats {
               description
                 "Данные состояния для окна anti-replay.";
               container replay-window {
                 leaf w {
                   type uint32;
                   description
                     "Размер окна повторов.";
                 }
                 leaf t {
                   type uint64;
                   description
                     "Наибольший порядковый номер, аутентифицированный
                      на данный момент - верхняя граница окна.";
                 }
                 leaf b {
                   type uint64;
                   description
                     "Нижняя граница окна.";
                 }
                 description
                   "Контейнер с параметрами, определяющими состояние
                    окна повтора - размер окна (w), наибольший
                    аутентифицированный порядковый номер (t), нижняя
                    граница окна. В соответствии с Приложением A2.1 к 
                    RFC 4303 выполняется условие w = t - b + 1.";
                 reference
                   "RFC 4303: IP Encapsulating Security Payload (ESP),
                              Appendix A.";
               }
               leaf packet-dropped {
                 type yang:counter64;
                 description
                   "Пакеты, отброшенные как повторы (replay).";
               }
               leaf failed {
                 type yang:counter64;
                 description
                   "Число пакетов, обнаруженных вне окна повтора.";
               }
               leaf seq-number-counter {
                 type uint64;
                 description
                   "Текущее значение 64-битового счётчика при 
                    использовании в IPsec SA  расширенных порядковых 
                    номеров или 32-битовое для обычных номеров.";
               }
             } /* Контейнер replay-stats*/
           } /*ipsec-sa-state*/
           description
             "Список записей базы данных SAD.";
         } /*Список sad-entry*/
       } /*Контейнер sad*/
     } /*Контейнер ipsec-ikeless*/

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

     notification sadb-acquire {
       if-feature "ikeless-notification";
       description
         "Элемент NSF обнаружил, что требуется IPsec SA для исходящих
          пакетов IP, соответствующих записи SPD. Контейнер
          traffic-selector в этом уведомлении содержит сведения о 
          вызвавшем уведомление пакете IP.";
       leaf ipsec-policy-name {
         type string;
         mandatory true;
         description
           "Уникальное имя записи SPD, которая соответствует IPsec SA,
            требуемой для пакета IP. Предполагается, что контроллер
            I2NSF будет иметь копию информации об правилах, чтобы
            чтобы получить все сведения по этому идентификатору. Тип
            IPsec SA указывается в правиле, поэтому контроллер 
            безопасности может также узнать тип IPsec SA, которую он
            ДОЛЖЕН создать.";
       }
       container traffic-selector {
         description
           "Пакет IP, требующий IPsec SA. В частности, контейнер будет
            включать IP-адреса/маски отправителя и получателя, протокол
            (udp, tcp и т. п.), номера портов отправителя и получателя";
         uses nsfikec:selector-grouping;
       }
     }

     notification sadb-expire {
       if-feature "ikeless-notification";
       description
         "завершение IPsec SA (мягкое или жесткое).";
       leaf ipsec-sa-name {
         type string;
         mandatory true;
         description
           "Уникальное имя записи SAD, для которой завершается срок
            действия IPsec SA. Предполагается, что у контроллера I2NSF
            будет копия сведений о IPsec SA (без криптографического
            материала и данных состояния) индексированная по именам
            (уникальный идентификатор), чтобы он мог знать всю
            информацию (криптоалгоритмы и т. п.) о завершающейся IPsec
            SA для замены ключей (мягкий срок действия) или удаления
            (жёсткий срок действия) по этому идентификатору.";
       }
       leaf soft-lifetime-expire {
         type boolean;
         default "true";
         description
           "Значение true указывает, что завершившийся срок действия был
            мягким, false указывает завершение жёсткого срока.";
       }
       container lifetime-current {
         description
           "Текущий срок действия IPsec SA. При soft-lifetime-expired
            true в этом контейнере содержатся сведения о текущем мягком
            сроке действия. Это может помочь контроллеру NSF узнать, 
            какие (мягкие) ограничения были достигнуты (время, число
            байтов, число пакетов, срок бездействия).";
         uses nsfikec:lifetime;
       }
     }

     notification sadb-seq-overflow {
       if-feature "ikeless-notification";
       description
         "Уведомление о переполнении порядкового номера.";
       leaf ipsec-sa-name {
         type string;
         mandatory true;
         description
           "Уникальное имя записи SAD для IPsec SA, в которой возникло
            переполнение порядкового номера. Когда NSF выдаёт это 
            событие заранее, переполнение зависит от реализации и
            выходит за рамки этой спецификации. Предполагается, что у
            контроллера I2NSF будет копия сведений о IPsec SA (без
            криптографического материала и данных состояния),
            индексированная по имени (уникальный идентификатор), чтобы
            можно было получить все сведения (криптоалгоритмы и пр.) о
            IPsec SA для замены ключей IPsec SA.";
       }
     }

     notification sadb-bad-spi {
       if-feature "ikeless-notification";
       description
         "Уведомление о получении NSF пакета с некорректным индексом
          SPI (т. е. не представленным в SAD).";
       leaf spi {
         type uint32 {
           range "0..max";
         }
         mandatory true;
         description
           "Значение SPI в ошибочном пакете IPsec.";
       }
     }
   }
   <CODE ENDS>

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

Агентство IANA внесло указанные ниже пространства имён в субреестр ns реестра IETF XML Registry [RFC3688]

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

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

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

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

   Name:         ietf-i2nsf-ikec
   Maintained by IANA:  N
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec
   Prefix:       nsfikec
   Reference:    RFC 9061

   Name:         ietf-i2nsf-ike
   Maintained by IANA:  N
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike
   Prefix:       nsfike
   Reference:    RFC 9061

   Name:         ietf-i2nsf-ikeless
   Maintained by IANA:  N
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless
   Prefix:       nsfikels
   Reference:    RFC 9061

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

К этому документу применимы соображения безопасности SDN, отмеченные в соответствующих разделах [ITU-T.Y.3300] и [RFC7426].

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

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

Этот раздел содержит два отдельных параграфа с анализом вопросов безопасности в NSF с IKEv2 (вариант с IKE) и без IKEv2 (вариант без IKE). В общем случае контроллер I2NSF, как обычно в парадигме SDN, является целью для разных типов атак (см. [SDNSecServ] и [SDNSecurity]). Поэтому контроллер I2NSF является ключевым элементом инфраструктуры и должен надёжно защищаться. В частности, контроллер I2NSF будет работать с криптографическим материалом и злоумышленники могут пытаться получить доступ к этому материалу. Последствия этого зависят от выбранного варианта — с IKE или без IKE.

7.1. Вариант с IKE

В варианте с IKE контроллер I2NSF передаёт свидетельства IKEv2 (PSK, открытые и секретные ключи, сертификаты и пр.) элементам NSF, используя защищённую связь между контроллером I2NSF и NSF. Контроллеру I2NSF недопустимо хранить свидетельства IKEv2 после их распространения. Кроме того, NSF недопустимо разрешать чтение этих значений после того, как они применены контроллером I2NSF (операции write-only). Одним из вариантов является возврат при всех попытках чтения одного и того же значения (все 0).

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

  • Конфигурациям IKEv2 следует соблюдать рекомендации [RFC8247].

  • При использовании аутентификации PSK в IKEv2 контроллер I2NSF должен удалять PSK сразу после генерации и распространения.

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

  • При использовании сертификатов NSF может создать секретный ключ и экспортировать открытый ключ контроллеру I2NSF для сертификации. Генерация криптографического материала (открытый и секретный ключ) в NSF и экспорт открытых ключей выходят за рамки этого документа.

7.2. Вариант без IKE

В варианте без IKE контроллер I2NSF передаёт в базу SAD элементов NSF сведения IPsec SA, включающие секретные сеансовые ключи, применяемые для шифрования и защиты целостности. Контроллеру I2NSF недопустимо хранить эти ключи после их распространения. Кроме того, элементам NSF, получающим секретный ключевой материал, недопустимо разрешать чтение этих значений каким-либо другим объектам (включая контроллер I2NSF) после их применения (операции write-only) в NSF. Тем не менее, атакующий с доступом к контроллеру I2NSF во время создания ключевого материала может эти значения получить и сможет наблюдать трафик IPsec и расшифровывать или даже изменять и заново шифровать трафик между партнёрами.

Защищённые связи между контроллером I2NSF и NSF должны обеспечивать уровень защиты не хуже, чем в IPsec SA, настроенных в NSF. В частности, защищённые связи между контроллером I2NSF и NSF должны обеспечивать полную защиту (forward secrecy), если это обеспечивается в IPsec SA, которые контроллер I2NSF настраивает в NSF. Алгоритм шифрования, применяемый в защищённых связях между контроллером I2NSF и NSF, должен иметь стойкость не ниже (как минимум ключи размером 128 битов), чем у алгоритмов, применяемых в IPsec SA.

7.3. Модули YANG

Заданные этим документом модули 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) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

Для варианта с IKE (ietf-i2nsf-ike)

/ipsec-ike

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

Для варианта без IKE (ietf-i2nsf-ikeless)

/ipsec-ikeless

Весь контейнер в этом модуле чувствителен к операциям записи. Атакующий может добавить, удалить или изменить правила IPsec (например, создать утечку данных путём смены политики на разрешающую) в контейнере /ipsec-ikeless/spd, любую IPsec SA между NSF через контейнер /ipsec-ikeless/sad и обычно может изменить любую IPsec SA и правила IPsec между любыми NSF.

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

Для варианта с IKE (ietf-i2nsf-ike)

/ipsec-ike/pad

Этот контейнер содержит чувствительные к операциям чтения сведения, которые недопустимо возвращать клиенту. Например, это может быть криптографический материал, настроенный в NSF (peer-authentication/pre-shared/secret и peer-authentication/digital-signature/private-key), уже защищённый расширением NACM default-deny-all в этом документе.

Для варианта без IKE (ietf-i2nsf-ikeless)

/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa

Этот контейнер включает симметричные ключи для IPsec SA. Например, encryption/key содержит ключ шифрования ESP, а encryption/iv — вектор инициализации (IV). В integrity/key содержится ключ защиты целостности ESP. Эти значения недопустимо считывать кому либо и они защищены расширением NACM default-deny-all в этом документе.

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

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

[IANA-Method-Type] IANA, «Method Type», <https://www.iana.org/assignments/eap-numbers/>.

[IANA-Protocols-Number] IANA, «Protocol Numbers», <https://www.iana.org/assignments/protocol-numbers/>.

[IKEv2-Auth-Method] IANA, «IKEv2 Authentication Method», <https://www.iana.org/assignments/ikev2-parameters/>.

[IKEv2-Parameters] IANA, «Internet Key Exchange Version 2 (IKEv2) Parameters», <https://www.iana.org/assignments/ikev2-parameters/>.

[IKEv2-Transform-Type-1] IANA, «Transform Type 1 — Encryption Algorithm Transform IDs», <https://www.iana.org/assignments/ikev2-parameters/>.

[IKEv2-Transform-Type-3] IANA, «Transform Type 3 — Integrity Algorithm Transform IDs», <https://www.iana.org/assignments/ikev2-parameters/>.

[IKEv2-Transform-Type-4] IANA, «Transform Type 4 — Diffie-Hellman Group Transform IDs», <https://www.iana.org/assignments/ikev2-parameters/>.

[ITU-T.X.690] International Telecommunication Union, «Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)», ITU-T Recommendation X.690, ISO/IEC 8825-1, February 2021.

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

[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, «Negotiation of NAT-Traversal in the IKE», RFC 3947, DOI 10.17487/RFC3947, January 2005, <https://www.rfc-editor.org/info/rfc3947>.

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec ESP Packets», RFC 3948, DOI 10.17487/RFC3948, January 2005, <https://www.rfc-editor.org/info/rfc3948>.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5915] Turner, S. and D. Brown, «Elliptic Curve Private Key Structure», RFC 5915, DOI 10.17487/RFC5915, June 2010, <https://www.rfc-editor.org/info/rfc5915>.

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

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP», RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.

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

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

[RFC7383] Smyslov, V., «Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation», RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>.

[RFC7427] Kivinen, T. and J. Snyder, «Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)», RFC 7427, DOI 10.17487/RFC7427, January 2015, <https://www.rfc-editor.org/info/rfc7427>.

[RFC7619] Smyslov, V. and P. Wouters, «The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 7619, DOI 10.17487/RFC7619, August 2015, <https://www.rfc-editor.org/info/rfc7619>.

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

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, «PKCS #1: RSA Cryptography Specifications Version 2.2», RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

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

[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, «Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.

[RFC8229] Pauly, T., Touati, S., and R. Mantha, «TCP Encapsulation of IKE and IPsec Packets», RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>.

[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, «Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>.

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

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

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

[IPSECME-CONTROLLER-IKE] Carrel, D. and B. Weis, «IPsec Key Exchange using a Controller», Work in Progress, Internet-Draft, draft-carrel-ipsecme-controller-ike-01, 10 March 2019, <https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01>.

[ITU-T.Y.3300] International Telecommunications Union, «Y.3300: Framework of software-defined networking», June 2014, <https://www.itu.int/rec/T-REC-Y.3300/en>.

[libreswan] The Libreswan Project, «Libreswan VPN software», <https://libreswan.org/>.

[netconf-vpn] Stefan Wallin, «Tutorial: NETCONF and YANG», January 2014, <https://ripe68.ripe.net/presentations/181-NETCONF-YANG-tutorial-43.pdf>.

[ONF-OpenFlow] Open Networking Foundation, «OpenFlow Switch Specification», Version 1.4.0 (Wire Protocol 0x05), October 2013, <https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf>.

[ONF-SDN-Architecture] Open Networking Foundation, «SDN architecture», Issue 1, June 2014, <https://www.opennetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf>.

[RFC2367] McDonald, D., Metz, C., and B. Phan, «PF_KEY Key Management API, Version 2», RFC 2367, DOI 10.17487/RFC2367, July 1998, <https://www.rfc-editor.org/info/rfc2367>.

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

[RFC6040] Briscoe, B., «Tunnelling of Explicit Congestion Notification», RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6071] Frankel, S. and S. Krishnan, «IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap», RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, «IPv6 Flow Label Specification», RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.

[RFC7149] Boucadair, M. and C. Jacquenet, «Software-Defined Networking: A Perspective from within a Service Provider Environment», RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, «Software-Defined Networking (SDN): Layers and Architecture Terminology», RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, «Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases», RFC 8192, DOI 10.17487/RFC8192, July 2017, <https://www.rfc-editor.org/info/rfc8192>.

[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, «Framework for Interface to Network Security Functions», RFC 8329, DOI 10.17487/RFC8329, February 2018, <https://www.rfc-editor.org/info/rfc8329>.

[SDNSecServ] Scott-Hayward, S., O’Callaghan, G., and P. Sezer, «SDN Security: A Survey», 2013 IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7, DOI 10.1109/SDN4FNS.2013.6702553, November 2013, <https://doi.org/10.1109/SDN4FNS.2013.6702553>.

[SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, «Towards secure and dependable software-defined networks», Proceedings of the second ACM SIGCOMM workshop on Hot Topics in software defined networking, pp. 55-60, DOI 10.1145/2491185.2491199, August 2013, <https://doi.org/10.1145/2491185.2491199>.

[strongswan] CESNET, «strongSwan: the OpenSource IPsec-based VPN Solution», <https://www.strongswan.org/>.

[TRAN-IPSECME-YANG] Tran, K., Wang, H., Nagaraj, V. K., and X. Chen, «Yang Data Model for Internet Protocol Security (IPsec)», Work in Progress, Internet-Draft, draft-tran-ipsecme-yang-01, 18 March 2016, <https://datatracker.ietf.org/doc/html/draft-tran-ipsecme-yang-01>.

Приложение A. Пример конфигурации XML для варианта IKE

Этот пример показывает файл конфигурации XML, передаваемый контроллером I2NSF для организации IPsec SA между парой NSF (Рисунок 3) в туннельном режиме (шлюз-шлюз) с ESP, аутентификацией по сертификатам X.509 (для краткости base64encodedvalue==) и вариантом с IKE.


                       +------------------+
                       | Контроллер I2NSF |
                       +------------------+
                Интерфейс I2NSF  |
                          с NSF  |
               /-----------------+---------------\
              /                                   \
             /                                     \
+----+  +--------+                            +--------+  +----+
| h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
+----+  +--------+                            +--------+  +----+
        :1        :100                       :200       :1

(2001:db8:1:/64)          (2001:db8:123:/64)       (2001:db8:2:/64)

Рисунок 3. Вариант IKE, туннельный режим, аутентификация по сертификату X.509.


<ipsec-ike xmlns=»urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike»

   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <pad>
       <pad-entry>
         <name>nsf_h1_pad</name>
         <ipv6-address>2001:db8:123::100</ipv6-address>
         <peer-authentication>
            <auth-method>digital-signature</auth-method>
            <digital-signature>
               <cert-data>base64encodedvalue==</cert-data>
               <private-key>base64encodedvalue==</private-key>
               <ca-data>base64encodedvalue==</ca-data>
            </digital-signature>
         </peer-authentication>
       </pad-entry>
       <pad-entry>
         <name>nsf_h2_pad</name>
         <ipv6-address>2001:db8:123::200</ipv6-address>
         <auth-protocol>ikev2</auth-protocol>
         <peer-authentication>
           <auth-method>digital-signature</auth-method>
           <digital-signature>
             <!-- Цифровая подпись RSA -->
             <ds-algorithm>1</ds-algorithm>
             <cert-data>base64encodedvalue==</cert-data>
             <ca-data>base64encodedvalue==</ca-data>
           </digital-signature>
         </peer-authentication>
       </pad-entry>
     </pad>
     <conn-entry>
        <name>nsf_h1-nsf_h2</name>
        <autostartup>start</autostartup>
        <version>ikev2</version>
        <initial-contact>false</initial-contact>
        <fragmentation><enabled>false</enabled></fragmentation>
        <ike-sa-lifetime-soft>
           <rekey-time>60</rekey-time>
           <reauth-time>120</reauth-time>
        </ike-sa-lifetime-soft>
        <ike-sa-lifetime-hard>
           <over-time>3600</over-time>
        </ike-sa-lifetime-hard>
        <!--AUTH_HMAC_SHA2_512_256-->
        <ike-sa-intr-alg>14</ike-sa-intr-alg>
        <!--ENCR_AES_CBC - 128 битов-->
        <ike-sa-encr-alg>
           <id>1</id>
        </ike-sa-encr-alg>
        <!-- 8192-битовая группа MODP-->
        <dh-group>18</dh-group>
        <half-open-ike-sa-timer>30</half-open-ike-sa-timer>
        <half-open-ike-sa-cookie-threshold>
           15
        </half-open-ike-sa-cookie-threshold>
        <local>
            <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
        </local>
        <remote>
            <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
        </remote>
        <spd>
          <spd-entry>
             <name>nsf_h1-nsf_h2</name>
             <ipsec-policy-config>
               <anti-replay-window-size>64</anti-replay-window-size>
               <traffic-selector>
                  <local-prefix>2001:db8:1::0/64</local-prefix>
                  <remote-prefix>2001:db8:2::0/64</remote-prefix>
                  <inner-protocol>any</inner-protocol>
               </traffic-selector>
               <processing-info>
                  <action>protect</action>
                  <ipsec-sa-cfg>
                     <pfp-flag>false</pfp-flag>
                     <ext-seq-num>true</ext-seq-num>
                     <seq-overflow>false</seq-overflow>
                     <stateful-frag-check>false</stateful-frag-check>
                     <mode>tunnel</mode>
                     <protocol-parameters>esp</protocol-parameters>
                     <esp-algorithms>
                        <!-- AUTH_HMAC_SHA1_96 -->
                        <integrity>2</integrity>
                         <encryption>
                             <!-- ENCR_AES_CBC -->
                             <id>1</id>
                             <algorithm-type>12</algorithm-type>
                             <key-length>128</key-length>
                         </encryption>
                         <encryption>
                             <!-- ENCR_3DES-->
                             <id>2</id>
                             <algorithm-type>3</algorithm-type>
                         </encryption>
                        <tfc-pad>false</tfc-pad>
                     </esp-algorithms>
                     <tunnel>
                        <local>2001:db8:123::100</local>
                        <remote>2001:db8:123::200</remote>
                        <df-bit>clear</df-bit>
                        <bypass-dscp>true</bypass-dscp>
                    </tunnel>
                  </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
          </spd-entry>
        </spd>
        <child-sa-info>
           <!-- 8192-битовая группа MODP -->
           <fs-groups>18</fs-groups>
           <child-sa-lifetime-soft>
              <bytes>1000000</bytes>
              <packets>1000</packets>
              <time>30</time>
              <idle>60</idle>
              <action>replace</action>
           </child-sa-lifetime-soft>
           <child-sa-lifetime-hard>
              <bytes>2000000</bytes>
              <packets>2000</packets>
              <time>60</time>
              <idle>120</idle>
           </child-sa-lifetime-hard>
        </child-sa-info>
      </conn-entry>
   </ipsec-ike>

Приложение B. Пример конфигурации XML для варианта без IKE

Этот пример показывает файл конфигурации XML, передаваемый контроллером I2NSF для организации IPsec SA между парой NSF (Рисунок 4) в транспортном режиме (хост-хост) с ESP в варианте без IKE.


                   +------------------+
                   | Контроллер I2NSF |
                   +------------------+
           Интерфейс I2NSF  |
                     с NSF  |
       /--------------------+-------------------\
      /                                          \
     /                                            \
+--------+                                    +--------+
| nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
+--------+                                    +--------+
        :100        (2001:db8:123:/64)       :200

Рисунок 4. Вариант без IKE, транспортный режим.


<ipsec-ikeless

     xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <spd>
       <spd-entry>
           <name>
              in/trans/2001:db8:123::200/2001:db8:123::100
           </name>
           <direction>inbound</direction>
           <reqid>1</reqid>
           <ipsec-policy-config>
              <traffic-selector>
                <local-prefix>2001:db8:123::200/128</local-prefix>
                <remote-prefix>2001:db8:123::100/128</remote-prefix>
                <inner-protocol>any</inner-protocol>
              </traffic-selector>
              <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>false</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                      <!--AUTH_HMAC_SHA1_96-->
                      <integrity>2</integrity>
                      <!--ENCR_AES_CBC -->
                      <encryption>
                        <id>1</id>
                        <algorithm-type>12</algorithm-type>
                         <key-length>128</key-length>
                      </encryption>
                      <encryption>
                        <id>2</id>
                        <algorithm-type>3</algorithm-type>
                      </encryption>
                   </esp-algorithms>
                 </ipsec-sa-cfg>
               </processing-info>
             </ipsec-policy-config>
           </spd-entry>
           <spd-entry>
             <name>out/trans/2001:db8:123::100/2001:db8:123::200</name>
             <direction>outbound</direction>
             <reqid>1</reqid>
             <ipsec-policy-config>
               <traffic-selector>
                 <local-prefix>2001:db8:123::100/128</local-prefix>
                 <remote-prefix>2001:db8:123::200/128</remote-prefix>
                 <inner-protocol>any</inner-protocol>
               </traffic-selector>
               <processing-info>
                 <action>protect</action>
                 <ipsec-sa-cfg>
                   <ext-seq-num>true</ext-seq-num>
                   <seq-overflow>false</seq-overflow>
                   <mode>transport</mode>
                   <protocol-parameters>esp</protocol-parameters>
                   <esp-algorithms>
                     <!-- AUTH_HMAC_SHA1_96 -->
                     <integrity>2</integrity>
                     <!-- ENCR_AES_CBC -->
                     <encryption>
                        <id>1</id>
                        <algorithm-type>12</algorithm-type>
                        <key-length>128</key-length>
                     </encryption>
                     <encryption>
                        <id>2</id>
                        <algorithm-type>3</algorithm-type>
                     </encryption>
                   </esp-algorithms>
                  </ipsec-sa-cfg>
                </processing-info>
              </ipsec-policy-config>
           </spd-entry>
        </spd>
        <sad>
          <sad-entry>
            <name>out/trans/2001:db8:123::100/2001:db8:123::200</name>
            <reqid>1</reqid>
            <ipsec-sa-config>
               <spi>34501</spi>
               <ext-seq-num>true</ext-seq-num>
               <seq-overflow>false</seq-overflow>
               <anti-replay-window-size>64</anti-replay-window-size>
               <traffic-selector>
                 <local-prefix>2001:db8:123::100/128</local-prefix>
                 <remote-prefix>2001:db8:123::200/128</remote-prefix>
                    <inner-protocol>any</inner-protocol>
                </traffic-selector>
                <protocol-parameters>esp</protocol-parameters>
                <mode>transport</mode>
                <esp-sa>
                  <encryption>
                     <!-- //ENCR_AES_CBC -->
                     <encryption-algorithm>12</encryption-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                     <iv>01:23:45:67:89:AB:CE:DF</iv>
                  </encryption>
                  <integrity>
                     <!-- //AUTH_HMAC_SHA1_96 -->
                     <integrity-algorithm>2</integrity-algorithm>
                     <key>01:23:45:67:89:AB:CE:DF</key>
                  </integrity>
                </esp-sa>
            </ipsec-sa-config>
          </sad-entry>
          <sad-entry>
             <name>in/trans/2001:db8:123::200/2001:db8:123::100</name>
             <reqid>1</reqid>
             <ipsec-sa-config>
                 <spi>34502</spi>
                 <ext-seq-num>true</ext-seq-num>
                 <seq-overflow>false</seq-overflow>
                 <anti-replay-window-size>64</anti-replay-window-size>
                 <traffic-selector>
                    <local-prefix>2001:db8:123::200/128</local-prefix>
                    <remote-prefix>2001:db8:123::100/128</remote-prefix>
                    <inner-protocol>any</inner-protocol>
                 </traffic-selector>
                 <protocol-parameters>esp</protocol-parameters>
                 <mode>transport</mode>
                 <esp-sa>
                    <encryption>
                       <!-- //ENCR_AES_CBC -->
                       <encryption-algorithm>12</encryption-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                       <iv>01:23:45:67:89:AB:CE:DF</iv>
                    </encryption>
                    <integrity>
                       <!-- //AUTH_HMAC_SHA1_96 -->
                       <integrity-algorithm>2</integrity-algorithm>
                       <key>01:23:45:67:89:AB:CE:DF</key>
                    </integrity>
                  </esp-sa>
                  <sa-lifetime-hard>
                     <bytes>2000000</bytes>
                     <packets>2000</packets>
                     <time>60</time>
                     <idle>120</idle>
                  </sa-lifetime-hard>
                  <sa-lifetime-soft>
                     <bytes>1000000</bytes>
                     <packets>1000</packets>
                     <time>30</time>
                     <idle>60</idle>
                     <action>replace</action>
                  </sa-lifetime-soft>
            </ipsec-sa-config>
          </sad-entry>
       </sad>
   </ipsec-ikeless>

Приложение C. Примеры уведомлений XML

Ниже показаны несколько файлов XML, иллюстрирующих разные типы уведомлений, определённые в модели данных YANG без IKE, которые передаются элементами NSF контроллеру I2NSF. Эти уведомления передаются в варианте без IKE.

   <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
   <ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
   </ipsec-sa-name>
       <soft-lifetime-expire>true</soft-lifetime-expire>
          <lifetime-current>
             <bytes>1000000</bytes>
             <packets>1000</packets>
             <time>30</time>
             <idle>60</idle>
          </lifetime-current>
   </sadb-expire>

Рисунок 5. Пример уведомления sadb-expire.

   <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
       <ipsec-policy-name>in/trans/2001:db8:123::200/2001:db8:123::100
       </ipsec-policy-name>
       <traffic-selector>
           <local-prefix>2001:db8:123::200/128</local-prefix>
           <remote-prefix>2001:db8:123::100/128</remote-prefix>
           <inner-protocol>any</inner-protocol>
            <local-ports>
                 <start>0</start>
                 <end>0</end>
            </local-ports>
            <remote-ports>
                 <start>0</start>
                 <end>0</end>
            </remote-ports>
       </traffic-selector>
   </sadb-acquire>

Рисунок 6. Пример уведомления sadb-acquire

   <sadb-seq-overflow
       xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
         <ipsec-sa-name>in/trans/2001:db8:123::200/2001:db8:123::100
         </ipsec-sa-name>
   </sadb-seq-overflow>

Рисунок 7. Пример уведомления sadb-seq-overflow.

   <sadb-bad-spi
            xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless">
           <spi>666</spi>
   </sadb-bad-spi>

Рисунок 8. Пример уведомления sadb-bad-spi.

Приложение D. Примеры использования

D.1. Пример организации IPsec SA

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

Применимость этих конфигураций проявляется в текущих и новых сетевых сценариях. Например, технологии SD-WAN обеспечивают динамические соединения VPN по запросу между филиалами и облачными службами SaaS4. Кроме того, службы предоставления инфраструктуры как услуги (Infrastructure as a Service или IaaS) обеспечивают среды виртуализации и развёртывания, которые часто используют IPsec для организации защищённых каналов между виртуальными экземплярами (хост-хост) и предоставления услуг VPN для виртуализованных сетей (шлюз-шлюз).

Как показано ниже, основанная на I2NSF система управления IPsec (для вариантов с IKE и без IKE) обеспечивает ряд преимуществ.

  1. Возможность создавать IPsec SA между NSF, основываясь лишь на применении общих правил защиты на основе потоков у пользователей I2NSF. Таким образом, администраторы могут управлять всеми защищёнными связями из центральной точки с абстрактным представлением сети.

  2. NSF в системе не требуют ручной настройки, что позволяет автоматизировать развёртывание.

D.1.1. Вариант с IKE

       +----------------------------------------+
       |Пользователь I2NSF (сист. управл. IPsec)|
       +----------------------------------------+
                 |
        (1) Политика защиты    Интерфейс I2NSF 
            на основе потоков     с клиентом
                 |
       +---------|------------------------------+
       |         |                              |
       |         |   Контроллер I2NSF           |
       |         V                              |
       |   +--------------+ (2)+--------------+ |
       |   |Трансляция в  |--->|   NETCONF/   | |
       |   |правила IPsec |    |   RESTCONF   | |
       |   +--------------+    +--------------+ |
       |                          |     |       |
       |                          |     |       |
       +--------------------------|-----|-------+
                                  |     |
      Интерфейс I2NSF с NSF |     |
                                  | (3) |
        |-------------------------+     +---|
        V                                   V
+----------------------+         +----------------------+
|       NSF A          |         |        NSF B         |
| IKEv2/IPsec(SPD/PAD) |         | IKEv2/IPsec(SPD/PAD) |
+----------------------+         +----------------------+

Рисунок 9. Взаимодействие между хостами и между шлюзами в варианте с IKE.


На рисунке 9 показано применение варианта с IKE для защиты данных на пути между NSF A и NSF B

  1. Пользователь I2NSF задаёт общие правила защиты на основе потоков (например, защищать трафик данных между NSF A и B). Контроллер I2NSF находит вовлечённые Controller NSF (NSF A и NSF B).

  2. Контроллер I2NSF генерирует свидетельства IKEv2 и транслирует правила в записи SPD и PAD.

  3. Контроллер I2NSF устанавливает конфигурацию IKEv2, включающую записи SPD и PAD в оба NSF A и B. При отказе какой-либо операции в NSF A или NSF B контроллер останавливает процесс и выполняет откат, удаляя конфигурацию IKEv2, SPD и PAD, установленную в NSF A или B.

Если предыдущие этапы успешны, между NSF A и NSF B организуется поток, защищённый IPsec SA с IKEv2.

D.1.2. Вариант без IKE

      +----------------------------------------+
      |Пользователь I2NSF (сист. управл. IPsec)|
      +----------------------------------------+
                |
       (1) Политика защиты    Интерфейс I2NSF 
           на основе потоков     с клиентом
                |
      +---------|------------------------------+
      |         |                              |
      |         |   I2NSF Controller           |
      |         V                              |
      |  +--------------+ (2) +--------------+ |
      |  |Трансляция в  |---->|   NETCONF/   | |
      |  |правила IPsec |     |   RESTCONF   | |
      |  +--------------+     +--------------+ |
      |                         |     |        |
      +-------------------------|-----|--------+
                                |     |
     Интерфейс I2NSF с NSF      |     |
                                | (3) |
         |----------------------+     +--|
         V                               V
+----------------+             +----------------+
|     NSF A      |             |     NSF B      |
| IPsec(SPD/SAD) |             | IPsec(SPD/SAD) |
+----------------+             +----------------+

Рисунок 10. Взаимодействие между хостами и между шлюзами в варианте без IKE.


На рисунке 10 показано применение варианта без IKE для защиты данных на пути между NSF A и NSF B.

  1. Пользователь I2NSF организует базовую политику защиты данных на основе потоков, а контроллер I2NSF находит вовлечённые NSF.

  2. Контроллер I2NSF транслирует правила основанной на потоках защиты в записи IPsec SPD и SAD.

  3. Контроллер помещает записи в базы данных IPsec NSF A и NSF B (SPD и SAD). Последующие действия указаны ниже.

    • Контроллер I2NSF выбирает два случайных значения индексов SPI, например, SPIa1 для входящей IPsec SA в NSF A и SPIb1 для входящей IPsec SA в NSF B. Значению SPIa1 недопустимо совпадать с каким-либо из входящих SPI в A, а SPIb1 недопустимо совпадать с каким-либо из входящих SPI в B. Кроме того, индекс SPIa1 должен применяться в B для исходящей IPsec SA к A, а SPIb1 должен применяться в A для исходящей IPsec SA к B. Генерируется также свежий криптографический материал для новых входящих и исходящих IPsec SA и их параметры.

    • После этого контроллер I2NSF одновременно передаёт новую входящую IPsec SA с SPIa1 и новую исходящую IPsec SA с SPIb1 элементу NSF A, а новую входящую IPsec SA с SPIb1 и новую исходящую IPsec SA с SPIa1 элементу B вместе с соответствующими правилами IPsec.

    • После получения контроллером I2NSF подтверждений от NSF A и NSF B он знает, что IPsec SA корректно установлены и готовы к работе.

В другом варианте этой операции контроллер I2NSF сначала передаёт правила IPsec и новые входящие IPsec SA элементам A и B. После подтверждения успеха этих операций от NSF A и NSF B, контроллер устанавливает новые исходящие IPsec SA. Это может увеличивать длительность процесса, но позволяет передавать трафик через сеть до полного завершения организации IPsec SA. Возможны и другие варианты выполнения этапа 3.

  1. При отказе какой-либо из предшествующих операций (например, NSF A указывает ошибку при попытке контроллера I2NSF установить запись SPD или создать новые IPsec SA) контроллер I2NSF должен выполнить откат операций, удаляя все новые IPsec SA (входящие и исходящие) и записи SPD, которые были установлены в каждом из NSF, и останавливает процесс. Отметим, что контроллер I2NSF может повторять попытки несколько раз.

  2. Если этапы 1 — 3 успешны, поток между NSF A и NSF B будет защищён IPsec SA, организованными контроллером I2NSF. Следует отметить, что контроллер I2NSF связывает сроки действия новых IPsec SA. По истечении срока действия NSF передаёт уведомление sadb-expire контроллеру I2NSF для запуска процесса замены ключей.

Вместо установки правил IPsec (в SPD) и IPsec SA (в SAD) на этапе 3 (упреждающий режим) контроллер I2NSF может устанавливать на этапе 3 только записи SPD (реактивный режим). В этом случае при необходимости защитить пакет с помощью IPsec элемент NSF, который первым увидел пакет данных, передаёт уведомление sadb-acquire для информирования контроллера I2NSF о потребности в записях SAD с IPsec SA для обработки этого пакета. При отказе какой-либо операции установки входящей или исходящей IPsec SA контроллер I2NSF останавливает процесс и выполняет операции отката, удаляя все вновь установленные SA.

D.2. Пример смены ключей в варианте без IKE

Для пояснения процесса смены ключей между парой IPsec NSF A и B предположим, что SPIa1 указывает входящую IPsec SA в A, SPIb1 — входящую IPsec SA в B.

  1. Контроллер I2NSF выбирает два случайных значения SPI для новых входящих IPsec SA, например, SPIa2 для IPsec SA в A и SPIb2 для IPsec SA в B. Значению SPIa1 недопустимо совпадать в каким-либо входящим SPI в A, а значению SPIb1 MUST NOT недопустимо совпадать в каким-либо входящим SPI в B. Затем контроллер I2NSF создаёт входящую IPsec SA с SPIa2 в A и входящую IPsec SA в B с SPIb2. Контроллер может передать информацию одновременно в A и B.

  2. Когда контроллер I2NSF получит подтверждения от A и B, он будет знать, что входящие IPsec SA установлены корректно. Затем контроллер параллельно передаёт в A и B исходящие IPsec SA — исходящую IPsec SA в A с SPIb2 и исходящую IPsec SA в B с SPIa2. После этого новые IPsec SA готовы к работе.

  3. Когда контроллер I2NSF получить подтверждения от A и B об установке исходящих IPsec SA, он параллельно удаляет старые IPsec SA в A (входящая SPIa1 и исходящая SPIb1) и B (исходящая SPIa1 и входящая SPIb1).

При отказе какой-либо операции на этапе 1 (например, NSF A сообщает об ошибке при попытке контроллера I2NSF установить новую входящую IPsec SA) контроллер I2NSF должен выполнить операции отката, удаляя все новые входящие SA, установленные на этапе 1.

Если этап 1 выполнен, но произошёл отказ на этапе 2 (например, NSF A сообщает об ошибке при попытке контроллера I2NSF установить новую исходящую IPsec SA) контроллер I2NSF должен выполнить операции отката, удаляя все новые исходящие SA, установленные на этапе 2 и входящие SA, установленные на этапе 1 (в указанном порядке).

Если этапы 1 и 2 выполнены, но произошёл отказ на этапе 3, контроллер I2NSF не будет выполнять откат для операций этапов 1 и 2, поскольку новые действительные IPsec SA были созданы и готовы к работе. Контроллер I2NSF может повторить попытку удаления старых входящих и исходящих IPsec SA в NSF A и NSF B несколько раз, пока не будет достигнут успех. В крайнем случае старые IPsec SA будут удалены по завершению их срока действия.

D.3. Пример контроля потери состояния NSF в варианте без IKE

В варианте без IKE при обнаружении контроллером I2NSF потери элементом NSF состояния IPsec он выполняет указанные ниже действия.

  1. Контроллеру I2NSF следует удалить старые IPsec SA на узлах без отказов и организовать новые с отказавшим узлом. Это предотвратит утечку нешифрованных данных с узлов без отказов.

  2. Если затронутый узел перезапускается, контроллер I2NSF настраивает новые входящие IPsec SA между этим узлом и всеми узлами, с которыми он взаимодействовал.

  3. После организации входящих IPsec SA контроллер I2NSF настраивает исходящие IPsec SA в параллель.

Этапы 2 и 3 могут выполняться одновременно с возможной потерей пакетов. Если возможность потерь не критична, такая оптимизация сокращает число обменов между контроллером I2NSF и элементами NSF.

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

Авторы благодарят Paul Wouters, Valery Smyslov, Sowmini Varadhan, David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, Ruben Ricart и всех членов IESG, просматривавших документ, за их ценные замечания.

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

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

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

nmalykh@protokols.ru

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

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

3Interface to Network Security Functions — интерфейс с функциями сетевой безопасности.

4Software as a Service — программы как услуги.

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

RFC 8999 Version-Independent Properties of QUIC

Internet Engineering Task Force (IETF)                        M. Thomson
Request for Comments: 8999                                       Mozilla
Category: Standards Track                                       May 2021
ISSN: 2070-1721

Version-Independent Properties of QUIC

Независимые от версии свойства QUIC

PDF

Аннотация

Этот документ определяет свойства транспортного протокола QUIC, общие для всех версий протокола.

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

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

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

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

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

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

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

2. Фиксированные свойства всех версий QUIC

В дополнение к защищённому мультиплексируемому транспорту QUIC [QUIC-TRANSPORT] протокол позволяет согласовать версию. Это позволяет протоколу меняться с течением времени в соответствии с новыми требованиями. Многие характеристики протокола могут меняться в разных версиях. В этом документе описано подмножество QUIC, которое предназначено оставаться стабильным в новых версиях по мере их разработки и развёртывания. Все эти инварианты не зависят от версии IP. Основной целью этого документа является обеспечение возможности развёртывания новых версий QUIC. Описывая неизменные свойства, этот документ направлен на сохранение возможности ключевых точек QUIC согласовать изменения любого другого аспекта протокола. В результате это гарантирует минимальный объем информации, доступной кому-либо кроме конечных точек. Если это явно не запрещено данным документом, любые аспекты протокола могут меняться в разных версиях.

В Приложении A приведён список некоторых некорректных допущения, которые могут быть сделаны на основе сведений о QUIC версии. Это не относится к другим версиям QUIC.

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

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

Этот документ определяет требования к будущим версиям QUIC, хотя нормативный язык здесь не применяется. В документе используются термины и соглашения о нотации из [QUIC-TRANSPORT].

4. Соглашения о нотации

Формат пакетов описывается с использованием определённой здесь нотации, которая совпадает с применяемой в [QUIC-TRANSPORT].

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

x (A)

Поле x размером A битов.

x (A..B)

Указывает, что x может иметь любой размер от A до B, если A не указано, поле может иметь размер 0, отсутствие B говорит, что размер поля не ограничен. Значения в этом формате всегда завершаются на границе байта.

x (L) = C

Указывает, что x имеет фиксированное значение C, размером L в одной из приведённых выше форм.

x (L) …

Указывает повторение x (возможно пустой набор), где каждый экземпляр имеет размер L.

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

Отдельные поля составного поля указываются с именем составного поля. На рисунке 1 представлен пример.

   Example Structure {
     One-bit Field (1),
     7-bit Field with Fixed Value (7) = 61,
     Arbitrary-Length Field (..),
     Variable-Length Field (8..24),
     Repeated Field (8) ...,
   }

Рисунок 1. Пример формата.


5. Пакеты QUIC

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

QUIC определяет два типа заголовка в пакетах — длинный и короткий. Пакеты с длинным заголовком указываются установкой (1) старшего бита в первом байте пакета, в коротких заголовках этот бит сброшен (0).

В пакетах QUIC может применяться защита целостности пакета, включая заголовок. Однако для пакетов QUIC Version Negotiation защита целостности не применяется (см. раздел 6).

Помимо описанных здесь значений содержимое (payload) пакетов QUIC зависит от версии и имеет произвольный размер.

5.1. Длинный заголовок

Формат длинного заголовка показан на рисунке 2.

   Long Header Packet {
     Header Form (1) = 1,
     Version-Specific Bits (7),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
     Version-Specific Data (..),
   }

Рисунок 2. Длинный заголовок QUIC.


В пакете QUIC с длинным заголовком старший бит первого байта имеет значение 1. Остальные биты этого байта зависят от версии. Следующие 4 байта образуют 32-битовое поле Version, описанное в параграфе 5.4. Следующий байт указывает размер следующего за ним поля Destination Connection ID (в байтах). Размер представлен 8-битовым целым числом без знака. Поле Destination Connection ID следует за Destination Connection ID Length и имеет размер от 0 до 255 байтов. Идентификаторы соединений описаны в параграфе 5.3. В следующем байте указан размер поля Source Connection ID, расположенного вслед за ним. Размер представлен 8-битовым целым числом без знака. Поле Source Connection ID следует за Source Connection ID Length и имеет размер от 0 до 255 байтов.

Остальная часть пакета зависит от версии.

5.2. Короткий заголовок

Формат короткого заголовка показан на рисунке 3.

   Short Header Packet {
     Header Form (1) = 0,
     Version-Specific Bits (7),
     Destination Connection ID (..),
     Version-Specific Data (..),
   }

Рисунок 3. Короткий заголовок QUIC.


В пакетах QUIC с коротким заголовком старший бит первого байта имеет значение 0. Пакет QUIC с коротким заголовком включает Destination Connection ID сразу за первым байтом. Короткий заголовок не содержит полей Destination Connection ID Length, Source Connection ID Length, Source Connection ID, Version. Размер Destination Connection ID не указывается в пакетах с коротким заголовком и не ограничивается этой спецификацией.

Остальная часть пакета зависит от версии.

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

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

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

5.4. Версия

Поле Version содержит 4-байтовый идентификатор, который может применяться конечными точками для указания версии QUIC. Поле Version = 0x00000000 зарезервировано для согласования версии (см. раздел 6), все остальные значения могут быть действительными.

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

6. Согласование версий

Конечная точка QUIC, получившая пакет с длинным заголовком и версией, которую она не понимает или не поддерживает, может передать в ответ пакет Version Negotiation. Пакеты с коротким заголовком не вызывают согласования версии.

В пакете Version Negotiation установлен (1) старший бит первого байта, задающий длинный заголовок, как описано в параграфе 5.1. Пакет Version Negotiation идентифицируется в качестве такового по полю Version = 0x00000000.

   Version Negotiation Packet {
     Header Form (1) = 1,
     Unused (7),
     Version (32) = 0,
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
     Supported Version (32) ...,
   }

Рисунок 4. Пакет согласования версии.


В первом байте пакета Version Negotiation определено значение лишь старшего бита (1), а остальные 7 битов, помеченные как Unused, могут иметь любые значения при передаче и должны игнорироваться получателем.

После поля Source Connection ID в пакете Version Negotiation содержатся пола Supported Version, каждое из которых указывает версию, поддерживаемую отправившей пакет конечной точкой. Других полей пакет Version Negotiation не содержит. Конечная точка должна игнорировать пакет без поля Supported Version или с усечённым полем. Для пакетов Version Negotiation не обеспечивается защиты целостности и конфиденциальности. Конкретные версии QUIC могут включать элементы протокола, позволяющие конечным точкам обнаруживать изменение или повреждения списка поддерживаемых версий.

Конечная точка должна включать значение Source Connection ID из полученного пакета в поле Destination Connection ID. Значение Source Connection ID должно копироваться из поля Destination Connection ID в полученном пакете, которое исходно клиент задаёт случайным. Указание обоих идентификаторов соединения даёт клиенту некоторую уверенность в том, что сервер получил пакет, а пакет Version Negotiation не создан злоумышленником, способным наблюдать пакеты.

Получившая пакет Version Negotiation конечная точка может сменить версию для последующих пакетов. Условия смены конечной точкой версии QUIC зависят от выбираемой версии.

В документе [QUIC-TRANSPORT] приведено более подробное описание генерации и использования пакетов Version Negotiation конечной точкой, поддерживающей QUIC версии 1.

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

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

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

Описанный в этом документе пакет Version Negotiation не имеет защиты целостности и лишь слегка защищён от злоумышленников. Конечная точка должна проверять подлинность смыслового содержимого Version Negotiation, если она пытается в результате сменить версию QUIC.

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

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

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

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

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

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., «Using TLS to Secure QUIC», RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[QUIC-TRANSPORT] 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>.

[RFC5116] McGrew, D., «An Interface and Algorithms for Authenticated Encryption», RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.

Приложение A. Некорректные допущения

Имеются некоторые черты QUIC версии 1 [QUIC-TRANSPORT], не защищённые от наблюдения, но тем не менее, считающиеся изменяемыми в новых версиях. В этом приложении приведены примеры некорректных допущений, которые могут быть приняты на основе сведений о QUIC версии 1. Некоторые из приведённый утверждений неверны даже для QUIC версии 1. Список не является полным и служит лишь иллюстрацией. Любое из приведённых ниже утверждений может быть ошибочным для конкретной версии QUIC.

  • QUIC использует TLS [QUIC-TLS] и некоторые сообщения TLS видимы в линии.

  • Длинные заголовки QUIC передаются лишь при организации соединения.

  • Каждый поток данного квинтета (5-tuple) включает фазу организации соединения.

  • Первые пакеты в потоке используют длинный заголовок.

  • Можно предположить, что последний поток перед долгим бездействием содержит лишь подтверждение.

  • QUIC использует функцию аутентифицированного шифрования со связанными данными (Authenticated Encryption with Associated Data или AEAD) AEAD_AES_128_GCM [RFC5116] для защиты пакетов в процессе организации соединения.

  • Номера пакетов QUIC шифруются и указываются в первых шифрованных байтах.

  • Номера пакетов QUIC увеличиваются на 1 в каждом передаваемом пакете.

  • QUIC устанавливает минимальный размер для первого пакета согласования, передаваемого клиентом.

  • QUIC требует, чтобы соединение инициировал (начинал «говорить») клиент.

  • В пакетах QUIC второй бит первого байта (0x40) всегда установлен (1).

  • Пакеты QUIC Version Negotiation передаёт только сервер.

  • Идентификаторы соединения QUIC меняются нечасто.

  • Конечные точки QUIC меняют применяемую версию, если передан пакет Version Negotiation.

  • Поле Version в пакетах QUIC с длинным заголовком одинаково для обоих направлений.

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

  • Между парой взаимодействующих конечных точек QUIC в каждый момент имеется лишь одно соединение.

Адрес автора

Martin Thomson

Mozilla

Email: mt@lowentropy.net


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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

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

RFC 8993 A Reference Model for Autonomic Networking

Internet Engineering Task Force (IETF)                 M. Behringer, Ed.
Request for Comments: 8993                                              
Category: Informational                                     B. Carpenter
ISSN: 2070-1721                                        Univ. of Auckland
                                                               T. Eckert
                                                           Futurewei USA
                                                            L. Ciavaglia
                                                                   Nokia
                                                                J. Nobre
                                                                   UFRGS
                                                                May 2021

A Reference Model for Autonomic Networking

Эталонная модель для сетей с самоуправлением

PDF

Аннотация

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

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

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

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

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

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

В документе «Autonomic Networking: Definitions and Design Goals» [RFC7575] описаны фундаментальные концепции, лежащие в основе автономных сетей (Autonomic Networking), определены термины и высокоуровневая эталонная модель. В [RFC7576] рассматривается «разрыв» между традиционным подходом и автономизацией.

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

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

Например, в имеющейся неавтоматической сети можно регистрировать устройства традиционным способом для создания доверенной инфраструктуры на основе сертификатов. Эту доверенную инфраструктуру затем можно применить для активизации автоматической плоскости управления (Autonomic Control Plane или ACP) и выполнения традиционных сетевых операций через защищённую и самовосстанавливающуюся ACP (см. [RFC8368]).

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

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

2. Представление сети

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

На рисунке 1 показано высокоуровневое представление сети с самоуправлением (AN). Сесть состоит из множества автоматических узлов, которые взаимодействуют между собой напрямую. Эти автоматические узлы обеспечивают в сети общий набор возможностей (свойств), который называется инфраструктурой автоматической сети (Autonomic Networking Infrastructure или ANI). Инфраструктура ANI обеспечивает такие функции, как именование, адресация, синхронизация, обнаружение и обмен сообщениями.

Автоматические функции обычно охватывают несколько узлов сети (возможно все). Неделимые элементы автоматической функции называют агентами автоматических служб (Autonomic Service Agent или ASA), их экземпляры создаются на узлах.

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:            :     Автоматическая функция 1      :                 :
: ASA 1      :      ASA 1      :      ASA 1      :          ASA 1  :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
             :                 :                 :
             :   +- - - - - - - - - - - - - - +  :
             :   :  Автоматическая функция 2  :  :
             :   :  ASA 2      :      ASA 2   :  :
             :   +- - - - - - - - - - - - - - +  :
             :                 :                 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:                Инфраструктура автоматической сети                :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+   :    +--------+   :    +--------+   :        +--------+
| Узел 1 |--------| Узел 2 |--------| Узел 3 |----...-----| Узел n |
+--------+   :    +--------+   :    +--------+   :        +--------+

Рисунок 1. Высокоуровневое представление сети с самоуправлением.


По горизонтали автоматические функции охватывают всю сеть, а также ANI. По вертикали сеть всегда реализует ANI и может включать один или несколько агентов ASA, которые могут быть автономными или включать в себя другие ASA (иерархия). Таким образом, ANI служит основой для автоматических функций.

3. Самоуправляемый элемент сети

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

3.1. Архитектура

В этом параграфе описывается элемент AN и его внутренняя архитектура. Эталонная модель из «Autonomic Networking: Definitions and Design Goals» [RFC7575] показывает источники информации, которые может использовать ASA — самообучение, изучение сети (с помощью обнаружения), Intent (см. параграф 7.2) и контуры обратной связи. Внутри автоматического узла имеется два уровня — уровень ASA и уровень ANI, причём первый использует услуги второго. Эта концепция показана на рисунке 2.

+------------------------------------------------------------+
|                                                            |
| +-----------+        +------------+        +------------+  |
| |   Агент   |        |   Агент    |        |   Агент    |  |
| | автоматич.|        | автоматич. |        | автоматич. |  |
| | службы 1  |        | службы 2   |        | службы 3   |  |
| +-----------+        +------------+        +------------+  |
|       ^                    ^                     ^         |
| -  -  | -  - Уровень API  -| -  -  -  -  -  -  - |-  -  -  |
|       V                    V                     V         |
|------------------------------------------------------------|
| Инфраструктура автоматической сети                         |
|    - структуры данных (сертификаты, сведения о партнёрах)  |
|    - обобщённая автоматическая плоскость управления (GACP) |
|    - адресация и именование автоматического узла           |
|    - функции обнаружения, согласования и синхронизации     |
|    - распространение намерений (Intent) и другой информации|
|    - агрегированные отчёты и контуры обратной связи        |
|    - маршрутизация                                         |
|------------------------------------------------------------|
|           Функции базовой операционной системы             |
+------------------------------------------------------------+

Рисунок 2. Модель автоматического узла.


Инфраструктура ANI (нижняя часть рисунка 2) содержит зависящие от узла структуры данных (например, сведения о доверии для самого узла и его партнёров), а также базовый набор функций, не зависящий от конкретного применения. Этой инфраструктуре следует быть общей и поддерживать разные ASA (верхняя часть рисунка 2). ANI включает адресацию и именование автоматических узлов, распространение информации, передачу отчётов, контуры обратной связи и маршрутизацию внутри плоскости управления ACP.

Обобщённая плоскость управления (Generalized ACP или GACP) — это сводка всех взаимодействий ANI с другими узлами и службами. Конкретная реализация GACP в этом документе обозначается ACP и описана в [RFC8994].

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

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

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

3.2. Таблица смежности

Самоуправляемые сети AN основаны на прямом взаимодействии между узлами домена. Плоскость управления ACP обычно строится на пошаговой основе (hop-by-hop), поэтому многие взаимодействия в ANI основываются на таблице смежности. Некоторые взаимодействия вносят сведения в эту таблицу, а другие используют данные из таблицы.

Таблица смежности ANI содержит по меньшей мере сведения о смежных автоматических узлах: Node-ID, IP-адрес в плоскости данных, IP-адрес в ACP, домен и сертификат. Автоматический узел поддерживает актуальность сведений в таблице. Таблица содержит сведения лишь об узлах, поддерживающих AN, а узлы без самоуправления обычно не отслеживаются в таблице. Однако информация отслеживается независимо от статуса партнёров, в частности, таблица смежности содержит сведения о незарегистрированных узлах того же или иного домена. Таблица смежности может включать сведения о действительности смежных автоматических узлов и уровне доверия к ним.

В таблицу смежности поступают указанные ниже данные.

  • Обнаружение локальных соединений (Link-local). Это взаимодействие происходит в плоскости данных с использованием лишь адресации IPv6 link-local, поскольку этот тип адресации сам является автоматическим. Этот способ позволяет узлу изучить автоматические узлы вокруг себя. Процедуру обнаружения локальных соединений описывают документы [RFC8990], [RFC8995], [RFC8994].

  • Перенаправление от производителя. Новое устройство может получать информацию о местоположении его домашней сети через перенаправление от уполномоченного производителем удостоверяющего центра (Manufacturer Authorized Signing Authority или MASA), как указано в параграфе 5.3. Обычно это маршрутизируемый адрес.

  • Неавтоматический ввод. Узел можно настроить вручную с участием автоматического партнёра, о котором узел может узнать из опций DHCP, DNS или иных неавтоматических механизмов. Обычно такие механизмы требуют того или иного участия администратора. Основной целью является обход (bypass) неавтоматического устройства или сети. Для новых устройств этот вопрос рассматривается в Приложениях A и B к [RFC8995].

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

  • Если узел не загрузился (bootstrap) в домен (т. е. не имеет сертификата домена), он проходит один за другим все узлы в таблице смежности, заявляющие присутствие в домене, и пытается загрузиться через них. Одним из возможных откликов является перенаправления через MASA производителя, которое будет введено в таблицу смежности (см. выше и [RFC8995]).

  • Если смежный узел относится к тому же домену, он аутентифицирует данный узел и при успешной проверке подлинности организует ACP (см. [RFC8994]).

  • Как только узел становится частью ACP в домене, он будет использовать GRASP [RFC8990] для поиска регистраторов домена и, возможно, других служб.

  • Если узел является частью ACP и нашёл хотя бы один регистратор в домене с помощью GRASP, он запускает ASA и будет выступать как прокси присоединения для соседей, которым нужна загрузка (см. параграф 6.3.1.2).

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

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

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

3.3. Конечный автомат

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

Обычно предполагается, что устройство сохраняет связанное с доменом отождествление — Local Device Identifier (LdevID, см. параграф 5.2) — в постоянном хранилище, которое будет доступно после выключения и последующего включения питания. Для устройств, не способных постоянно сохранять LDevID выключения питания равносильно сбросу к заводским настройкам.

3.3.1. Состояние 1 — заводские установки

Автоматический узел выпускается с завода в этом состоянии. Узел не имеет связанных с доменом настроек, в частности LDevID, и может использоваться в любой конкретной сети. Однако узел имеет заданный производителем идентификатор (Initial Device Identifier или IDevID) [IDevID]. Узлы без IDevID невозможно автоматически и безопасно зарегистрировать в домене, они требуют предварительной настройки вручную и в этом случае подготовка начинается из состояния 2.

Переходы

  • Загрузка. Устройство регистрируется в домене, получая при этом доменное отождествление — LDevID. При успешной регистрации следующим будет состояние 2. регистрация описана в [RFC8995].

  • Включение и выключение питания. Устройство теряет все таблицы состояний и остаётся в состоянии 1.

3.3.2. Состояние 2 — устройство зарегистрировано

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

Переходы

  • Присоединение к ACP. Устройство организует канал ACP к смежному устройству (см. [RFC8994]). Следующим будет состояние 3.

  • Сброс к заводским настройкам. Удаляются все конфигурации и доменное отождествление LdevID. Следующим будет состояние 1.

  • Включение и выключение питания. Устройство теряет все таблицы состояния, но сохраняет доменное отождествление LdevID и остаётся в состоянии 2.

3.3.3. Состояние 3 — устройство подключено к ACP

В этом состоянии автоматический узел имеет хотя бы 1 канал ACP к другому устройству. Узел теперь может участвовать в других автоматических транзакциях, таких как запуск ASA (например, он должен включить прокси-ASA для присоединения, чтобы помочь другим устройствам войти в домен). К таким взаимодействиям могут применяться другие условия, например, для работы в качестве посредника в присоединении, устройство сначала должно найти регистратор загрузки.

Переходы

  • Выход из ACP. Устройство отключает последний (единственный) канал ACP к смежному устройству. Следующим будет состояние 2.

  • Сброс к заводским настройкам. Удаляются все конфигурации и доменное отождествление LdevID. Следующим будет состояние 1.

  • Включение и выключение питания. Устройство теряет все таблицы состояния, но сохраняет доменное отождествление LdevID. Следующим будет состояние 2.

4. Инфраструктура AN

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

4.1. Именование

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

При отсутствии специфической для домена схемы именования следует применять принятую по умолчанию схему, использующую такую же логику как схема адресации, описанная в [RFC8994]. Имя устройства в этом случае состоит из Registrar-ID (например, MAC-адрес регистратора) и номера устройства. Примером такого имени может служить

   0123-4567-89ab-0001

Первые 3 поля этого имени образованы MAC-адресов, а четвёртое содержит порядковый номер устройства.

4.2. Адресация

Агенты ASA должны взаимодействовать друг с другом, используя автоматическую адресацию инфраструктуры ANI узла, на котором размещается агент. В этом параграфе описан подход к адресации ANI используемой агентами ASA. Подход к адресации в плоскости данных сети выходит за рамки этого документа. Эта адресация может настраиваться и управляться традиционным способом или согласовываться как услуга ASA. Один из примеров использования такой автономной функции представлен в [RFC8992].

Автоматическая адресация является функцией ANI (нижняя часть рисунка 2) и, в частности ACP. Агенты ASA не имеют собственных адресов. Они могут использовать вызовы API или схему автоматической адресации ANI. Требования к схеме автоматической адресации перечислены ниже.

  • Адресация без вмешательства (Zero-touch) для простых сетей, которым следует иметь полное самоуправление адресацией и не требовать централизованного управления, инструментов и планирования.

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

  • Гибкость. Схема адресации должна позволять узлам перемещаться по сети, а сеть должна иметь возможность расширяться, делиться и сливаться с другими сетями.

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

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

  • Поддержка виртуализации. Автоматические функции могут работать на уровне физической сети и устройств или на уровне виртуальных машин, контейнеров и сетей. В частности, автоматические узлы могут поддерживать ASA в виртуальных объектах. Инфраструктуре и схеме адресации, следует поддерживать это.

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

  • Расширяемость. Схема адресации должна работать в сетях любого размера.

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

Предлагаемая схема адресации описана в документе «An Autonomic Control Plane (ACP)» [RFC8994].

4.3. Обнаружение

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

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

Во-вторых, для сетевых служб, таких как аутентификация, проверка полномочий и учёт (Authentication, Authorization, Accounting или AAA), также следует поддерживать обнаружение без настройки. Сеть с самоуправлением (AN) может использовать имеющиеся функции обнаружения, применять новые подходы или то и другое вместе.

Таким образом, механизмы обнаружения могут быть полностью объединены с автоматической сигнализацией (см. следующий параграф) или использовать независимые механизмы, такие как обнаружение служб через DNS или Service Location Protocol. Выбор может быть независимым для каждого агента ASA, хотя инфраструктура может требовать того или иного общего минимума (например, обнаружение механизма защищённой загрузки или источника распространения информации, см. параграф 4.7).

В фазе 1 сети с самоуправлением (Autonomic Networking) используют для обнаружения протокол GRASP [RFC8990].

4.4. Сигнализация между автоматическими узлами

Автоматические узлы должны взаимодействовать между собой, например, для согласования и/или синхронизации технических целей (т. е. параметров сети) любого типа и сложности. Для этого нужна та или иная форма сигнализации между узлами. Автоматические узлы, реализующие определённый вариант, могут выбрать свой сигнальный протокол, если он соответствует общей модели безопасности. Однако в общем случае обмен данными может потребоваться любой паре узлов с самоуправлением, поэтому нужен общий протокол сигнализации. Предпосылкой для этого является возможность узлов обнаруживать друг друга без предварительной настройки, как отмечено выше. Для обеспечения общего характера обнаружение и сигнализация должны быть способны решать любые технические задачи, включая те, которым нужны сложные структуры данных. В документе «GeneRic Autonomic Signaling Protocol (GRASP)» [RFC8990] более подробно описаны требования к обнаружению, согласованию и синхронизации в AN. Документ также определяет протокол GRASP для этих целей, включающий встроенный, но необязательный процесс обнаружения.

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

4.5. Маршрутизация

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

4.6. Автоматическая плоскость управления

Плоскость управления ACP поддерживает протоколы управления в автоматической сети AN. В описанной здесь архитектуре она реализована как наложенная сеть. В документе «An Autonomic Control Plane (ACP)» [RFC8994] описаны детали реализации. Данный документ использует термин «наложенная» (overlay) для обозначения набора парных смежностей с базовой топологией соединений. Это может отличаться от толкования термина overlay в контексте маршрутизации. Примеры использования ACP приведены в [RFC8368].

4.7. Распространение информации (*)

Некоторые формы информации требуют распространения через домен с самоуправлением. Такое распространение происходит в плоскости управления ACP. Например Intent распространяется по домену, как описано в [RFC7575]. Намерения (Intent) являются языком правил в сети с самоуправлением AN (см. параграф 7.2). Это правила высокого уровня и менять их следует нечасто (дни). Поэтому такую информацию, как Intent, следует рассылать в лавинном режиме всем узлам автоматического домена и в настоящее время нет ощутимой потребности использовать более направленные методы распространения. Предполагается, что Intent будет «монолитным» и рассылаться будет целиком. Один из возможных методов распространения Intent и других форм данных рассмотрен в [GRASP-DISTRIB]. Intent и распространение информации не входят в задачи рабочей группы ANIMA.

5. Инфраструктура защиты и доверия

Автоматические сети AN сами защищают себя. Все протоколы по умолчанию являются защищёнными и не требуют привлечения администратора для явной настройки защиты за исключением установки инфраструктуры PKI.

Автоматические узлы взаимодействуют напрямую и это требует защиты. Поскольку сети AN не полагаются на настройку конфигурации, здесь нет опций настройки, таких как заранее распространённые ключи и вместо этого должна применяться доверенная инфраструктура, такая как PKI. В этом разделе описаны принципы инфраструктуры доверия. На первой фазе AN устройство 1) находится в доверенном домене и само является доверенным или 2) находится за пределами домена доверия и считается недоверенным.

Принятый по умолчанию метод автоматического запуска инфраструктуры доверия определён в документе «Bootstrapping Remote Secure Key Infrastructure (BRSKI)» [RFC8995]. Агенты ASA, требуемые для регистрации, описаны в параграфе 6.3. Автоматические узлы должны реализовать агенты ASA для регистрации и посредничества в присоединении. ASA-регистратор можно реализовать на части устройств.

5.1. Инфраструктура открытых ключей

Домен с самоуправлением использует модель PKI. Конем доверия является удостоверяющий центр (Certification Authority или CA). Регистратор выступает в качестве центра регистрации (Registration Authority или RA). Минимальная реализация автоматического домена содержит один CA, один регистратор и элементы сети.

5.2. Сертификат домена

Каждое устройство в домене самоуправления использует сертификат домена (LdevID) для отождествления себя. Новое устройство использует предоставленный производителем сертификат IdevID в процессе начальной загрузки для получения сертификата LdevID. Процесс получения доменного сертификата и его формат описаны в [RFC8995].

5.3. MASA

Уполномоченный производителем орган подписания (Manufacturer Authorized Signing Authority или MASA) является доверенной службой для устройств с начальной загрузкой. MASA позволяет владельцу отслеживать устройства в домене, обеспечивая регистратору аудит, проверку полномочий и маркеры владения в процессе начальной загрузки, чтобы помочь при проверке подлинности устройств, пытающихся присоединиться к домену самоуправления и позволить присоединяющемуся устройству проверить корректность домена. Детали службы MASA, безопасности и применения описаны в [RFC8995].

5.4. Субдомены (*)

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

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

5.5. Кросс-доменная функциональность (*)

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

6. Автоматические агенты служб

В этом разделе описана работа автоматических служб в инфраструктуре ANI.

6.1. Общее описание ASA

Агент ASA определён в [RFC7575] как: «Агент, реализованный на автоматическом узле и выполняющий автоматическую функцию частично (распределенная функция) или полностью. Таким образом, это процесс, использующий функции инфраструктуры ANI для достижения своих целей, обычно путём взаимодействия с другими ASA по протоколу GRASP [RFC8990] или иным способом. Агент также взаимодействует с конкретными объектами (target) своей функции, используя любой подходящий механизм. Если функция агента не очень проста, ASA потребуется обрабатывать перекрывающиеся асинхронные операции. Поэтому агент может быть достаточно сложной частью программы, работающей на прикладном уровне над инфраструктурой ANI. Рекомендации по проектированию ASA приведены в [ASA-GUIDELINES].

Можно выделить по меньшей мере 3 класса агентов ASA:

  • простые ASA небольшого размера, которые могут работать где угодно;

  • сложные, возможно многопоточные ASA с высокими требованиями к ресурсам, которые работают лишь на некоторых узлах;

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

Автоматические узлы и их агенты ASA знают свои возможности и ограничения, связанные с оборудованием, микрокодом (firmware) и установленными программами, т. е. «осознают себя» (self-aware).

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

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

Поскольку агенты ASA будут взаимодействовать с ANI, они будут зависеть от соответствующих интерфейсов API2. Желательна переносимость ASA между разными операционными системами, поэтому от API требуется универсальность. Интерфейс API для протокола GRASP описан в [RFC8991]. В общем случае агенты ASA будут разрабатываться и кодироваться специалистами в конкретной технологии и варианте применения, а не специалистами в части инфраструктуры ANI и её компонентов. Кроме того, они могут представляться на разных языках программирования, в частности, на языках, поддерживающих объекты, а также традиционные переменные и структуры. При разработке API это следует учитывать.

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

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

Агенты ASA автоматически используют возможности защиты, обеспечиваемой инфраструктурой ANI, в частности ACP и GRASP. Однако в дополнение к этому агенты сами отвечают за свою защиту, особенно при взаимодействии с конкретными объектами (target) своей функции. Поэтому при разработке ASA должен выполняться анализ безопасности сверх использования защиты ANI.

6.2. Управление жизненным циклом ASA

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

  • установки ASA, состоящей из копирования кода ASA на узел и его запуска;

  • развёртывания ASA, связывающего экземпляр ASA с управляемым сетевым устройством (устройствами) или функцией;

  • контроль исполнения ASA, задающий цикл управления ASA.

Жизненный цикл также определяет взаимодействия ASA с ANI в разных состояниях. Важные взаимодействия указаны ниже.

  • Самоописание экземпляров ASA в конце развёртывания, формат которого должен определять информацию, требуемую ждя управления агентами ASA со стороны ANI.

  • Контроль контура управления ASA в процессе исполнения. Сигнализация передаёт форматированные сообщения для управления исполнением ASA (по меньшей мере запуском и остановкой контура управления).

6.3. Конкретные ASA в инфраструктуре автоматической сети

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

Три первых агента (поручительство, посредник присоединения, регистратор присоединения) совместно поддерживают процесс регистрации, описанный в разделе 5. Более подробное описание дано в [RFC8995].

6.3.1. Регистрационные ASA

6.3.1.1. ASA-поручитель

Этот агент ASA включает функцию автоматического узла, который выполняет начальную загрузку в домен с помощью посредника в присоединении (join proxy ASA). Такой узел называют поручителем (pledge) в процессе регистрации. Он должен по умолчанию устанавливаться на всех узлах, которым нужна начальная загрузка без предварительной настройки (zero-touch bootstrap).

6.3.1.2. ASA-посредник присоединения

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

6.3.1.3. ASA-регистратор присоединения

Этот агент ASA включает функцию регистратора присоединения (Join Registrar) к автоматической сети AN. Такой агент не требуется устанавливать на всех узлах, достаточно разместить его на узлах с функцией Join Registrar.

6.3.2. ACP ASA

Этот агент ASA включает функцию плоскости управления ACP в автоматической сети AN. В частности, он обнаруживает другие потенциальные узлы ACP и поддерживает организацию и разрыв каналов ACP. Этот агент ASA должен устанавливаться на всех узлах. Подробное описание приведено в параграфе 4.6 и [RFC8994].

6.3.3. ASA для распространения информации (*)

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

ASA включает функцию распространения информации в AN. В частности, он анонсирует доступность Intent и другой информации всем остальным автоматическим узлам. Этот агент не требуется устанавливать на всех узлах, достаточно разместить его на узлах, реализующих функции распространения информации (см. параграф 4.7).

Отметим, что распространение информации может быть реализовано как функция в любом агенте ASA. Более подробное описание распространения информации дано в [GRASP-DISTRIB].

7. Управление и программируемость

В этом разделе рассматривается управление и программирование AN.

7.1. Управление (частично) автоматической сетью

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

  • Автоматические функции могут применять традиционные методы и протоколы (например, SNMP и NETCONF) для выполнения задач управления внутри или вне ACP.

  • Автоматические функции могут вызывать конфликты с некоторыми традиционными методами и протоколами.

  • Традиционные функции могут использовать ACP, например, когда ещё нет доступности в плоскости данных.

Автоматические намерения (Intent) определяются на высоком уровне абстракции. Однако в силу необходимости обращения к отдельным управляемым элементам, автоматическому управлению нужны коммуникации на более низких уровнях (например, команды и запросы). Предполагается, что настройка конфигурации таких элементов будет выполняться, например, с использованием NETCONF и модулей YANG, а мониторинг — с помощью SNMP и MIB.

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

7.2. Намерения (*)

В текущих спецификациях реализаций Intent не рассматривается и в этом параграфе обсуждаются темы дальнейших исследований. Параграф содержит обзор Intent и способы управления намерениями. Intent и сетевое управление на основе правил (Policy-Based Network Management или PBNM) уже описаны в IETF (например, Policy Core Information Model или PCIM) и других органах стандартизации (Standards Development Organization или SDO), например, целевой группе по распределенному управлению (Distributed Management Task Force или DMTF).

Намерения (Intent) можно описать в абстрактной, декларативной политике высокого уровня, используемой для работы автоматического домена, такого как сеть предприятия [RFC7575]. Намерения следует ограничивать лишь высокоуровневыми рекомендациями, т. е. они не должны напрямую определять правила для каждого элемента сети в отдельности.

Intent можно уточнять до политики более низкого уровня с использованием различных подходов. Предполагается, что позволит приспособить намерения к возможностям управляемых устройств. Intent может содержать сведения о ролях и функциях, которые можно транслировать на конкретные узлы [RFC7575]. Одним из возможных уточнений Intent является применение правил «событие-условия-действие» (Event-Condition-Action или ECA).

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

Более подробное рассмотрение Intent приведено в [ANIMA-INTENT]. Для распространения Intent и других типов информации применяется протокол GRASP, см. [GRASP-DISTRIB].

7.3. Агрегированные отчёты (*)

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

Автоматическим сетям AN следует минимизировать вовлечение операторов. С точки зрения поведения сети это выполняется с помощью автоматических намерений Intent, предоставляемых оператором. Аналогичным образом отчётам с описанием рабочего состояния сети следует агрегировать информацию от разных элементов сети для представления эффективности исполнения Intent. Поэтому отчёты в AN следует предоставлять на уровне сети [RFC7575].

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

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

7.4. Контуры обратной связи с NOC (*)

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

Однонаправленные уведомления в центр управления сетью (Network Operations Center или NOC), которые не предлагают заданных по умолчанию действий и не допускают переопределения в рамках транзакции, рассматриваются подобно традиционным службам уведомления, таким как syslog. Предполагается их сосуществование с автономными методами, но этот вопрос в документе не рассматривается.

7.5. Контуры управления (*)

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

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

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

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

7.6. API (*)

В [RFC8991] определена концептуальная схема API для протокола базовой автоматической сигнализации (GeneRic Autonomic Signaling Protocol или GRASP). Этот API разработан для взаимодействия между агентами ASA по протоколу GRASP. Полная спецификации Standards Track API не включены в текущий спецификации реализаций.

Большинство API являются статическими, что означает их предопределённость и использование инвариантных механизмов работы с данными. Автоматическим сетям AN следует иметь возможность использования динамических API в дополнение к статическим.

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

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

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

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

  • инвариантных атрибутов, которые не должны меняться в процессе исполнения метода.

7.7. Модели данных (*)

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

Определения модели данных и информационной модели адаптированы из [SUPA-DATA].

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

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

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

Модель данных важна для некоторых типов функций, таких как цикл адаптивного управления MRACL (Model-Reference Adaptive Control Loop. В более общем смысле модель данных может служить для определения объектов, атрибутов, методов и взаимоотношений программной системы (например, ANI, автоматического узла или агента ASA). Модель данных можно использовать при разработке API, а также любого языка для взаимодействия с сетью AN.

8. Координация между автоматическими функциями (*)

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

8.1. Проблема координации (*)

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

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

  • кооперация, когда автоматическая функция может улучшить поведение или производительность другой автоматической функции (например, функция предсказания трафика, используемая функцией распределения);

  • зависимость, когда одна автоматическая функция не может работать без наличия или доступности другой в сети AN;

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

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

  • Во время сборки можно создать «статический план взаимодействий» на основе взаимосвязей функций и атрибутов. Этот план можно использовать для установки правил и задания приоритетов для выявленных конфликтов.

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

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

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

8.2. Функциональный блок координации (*)

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

Для общего функционального блока координации требуется:

  • общее описание автоматических функций, их атрибутов и жизненного цикла;

  • общее представление информации и знаний (например, план взаимодействий);

  • общий интерфейс команд (управления) между «агентом» координации и автоматическими функциями.

Могут также предоставляться руководства, рекомендации или BCP для аспектов, относящихся к стратегии и механизмам координации.

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

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

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

9.1. Защита от внешних атак

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

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

  • защищённые от изменения;

  • аутентифицированные;

  • защищённые от replay-атак;

  • защищённые в части конфиденциальности (шифрованные).

Кроме того, протоколам AN следует быть стойкими к отбрасыванию пакетов и перехвату с участием человека (man-in-the-middle или MITM). Эти требования задаются в документах AN Standards Track, определяющих применяемые методы, в частности в [RFC8990], [RFC8994], [RFC8995].

Большинство сообщений AN передаётся в криптографически защищённой плоскости управления ACP. Незащищёнными сообщениями AN вне ACP являются лишь сообщения простого метода обнаружения, описанные в параграфе 2.5.2 [RFC8990], — сообщения DULL (Discovery Unsolicited Link-Local), для которых заданы детальные правила.

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

9.2. Риск внутренних атак

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

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

  • Внедрение обманного устройства в домен доверия за счёт нарушения (обхода) методов проверки подлинности. Это зависит от корректности спецификации, реализации и работы протоколов AN.

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

  • Использование ещё неизвестных уязвимостей в AN или ином протоколе. Эта угроза относится к любой сети.

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

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

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

Этот документ не запрашивает действий IANA.

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

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

[IDevID] IEEE, «IEEE Standard for Local and metropolitan area networks — Secure Device Identity», IEEE 802.1AR, <https://1.ieee802.org/security/802-1ar>.

[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., «GeneRic Autonomic Signaling Protocol (GRASP)», RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, «An Autonomic Control Plane (ACP)», RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, «Bootstrapping Remote Secure Key Infrastructure (BRSKI)», RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.

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

[ANIMA-INTENT] Du, Z., Jiang, S., Nobre, J. C., Ciavaglia, L., and M. Behringer, «ANIMA Intent Policy and Format», Work in Progress, Internet-Draft, draft-du-anima-an-intent-05, 14 February 2017, <https://tools.ietf.org/html/draft-du-anima-an-intent-05>.

[ASA-GUIDELINES] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso, «Guidelines for Autonomic Service Agents», Work in Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-00, 14 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-asa-guidelines-00>.

[GRASP-DISTRIB] Liu, B., Ed., Xiao, X., Ed., Hecker, A., Jiang, S., Despotovic, Z., and B. Carpenter, «Information Distribution over GRASP», Work in Progress, Internet-Draft, draft-ietf-anima-grasp-distribution-02, 8 March 2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>.

[Meyer97] Meyer, B., «Object-Oriented Software Construction (2nd edition)», Prentice Hall, ISBN 978-0136291558, 1997.

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

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, «General Gap Analysis for Autonomic Networking», RFC 7576, DOI 10.17487/RFC7576, June 2015, <https://www.rfc-editor.org/info/rfc7576>.

[RFC8368] Eckert, T., Ed. and M. Behringer, «Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)», RFC 8368, DOI 10.17487/RFC8368, May 2018, <https://www.rfc-editor.org/info/rfc8368>.

[RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, «GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)», RFC 8991, DOI 10.17487/RFC8991, May 2021, <https://www.rfc-editor.org/info/rfc8991>.

[RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun, «Autonomic IPv6 Edge Prefix Management in Large-Scale Networks», RFC 8992, DOI 10.17487/RFC8992, May 2021, <https://www.rfc-editor.org/info/rfc8992>.

[SUPA-DATA] Halpern, J. and J. Strassner, «Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)», Work in Progress, Internet-Draft, draft-ietf-supa-generic-policy-data-model-04, 18 June 2017, <https://tools.ietf.org/html/draft-ietf-supa-generic-policy-data-model-04>.

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

Вклад в работу и отклики предоставили Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur Hecker. Полезные рецензии представили Joel Halpern, Radia Perlman, Tianran Zhou, Christian Hopps.

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

Значительный вклад в документ внесли John Strassner (Huawei), Bing Liu (Huawei), Pierre Peloso (Nokia).

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

Michael H. Behringer (editor)

Email: Michael.H.Behringer@gmail.com

Brian Carpenter

School of Computer Science

University of Auckland

PB 92019

Auckland 1142

New Zealand

Email: brian.e.carpenter@gmail.com

Toerless Eckert

Futurewei USA

2330 Central Expy

Santa Clara, CA 95050

United States of America

Email: tte+ietf@cs.fau.de

Laurent Ciavaglia

Nokia

Villarceaux

91460 Nozay

France

Email: laurent.ciavaglia@nokia.com

Jéferson Campos Nobre

Federal University of Rio Grande do Sul (UFRGS)

Av. Bento Gonçalves, 9500

Porto Alegre-RS

91501-970

Brazil

Email: jcnobre@inf.ufrgs.br


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

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

nmalykh@protokols.ru


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

2Application programming interface — интерфейс с прикладными программами.

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

RFC 8992 Autonomic IPv6 Edge Prefix Management in Large-Scale Networks

Internet Engineering Task Force (IETF)                     S. Jiang, Ed.
Request for Comments: 8992                  Huawei Technologies Co., Ltd
Category: Informational                                            Z. Du
ISSN: 2070-1721                                             China Mobile
                                                            B. Carpenter
                                                       Univ. of Auckland
                                                                  Q. Sun
                                                           China Telecom
                                                                May 2021

Autonomic IPv6 Edge Prefix Management in Large-Scale Networks

Управление граничными префиксами IPv6 в больших сетях

PDF

Аннотация

Этот документ задаёт две автономных технических задачи для управления префиксами IPv6 на границе больших сетей ISP с расширением для поддержки префиксов IPv4. Важным назначением документа является его использование для проверки устройства различных компонентов автономной (самоуправляемой) сетевой инфраструктуры.

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

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

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

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

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

Исходным назначением этого документа была проверка устройства инфраструктуры автономных сетей (Autonomic Networking Infrastructure или ANI) для реалистических вариантов использования. Показаны возможные применения ANI для выделения префиксов IP и описаны подходы к построению систем для этого. Полностью стандартизованное решение потребует более детальной проработки, поэтому документ имеет статус информационного.

Документ определяет две автономных технических задачи для управления префиксами IPv6 в больших сетях с расширением для поддержки префиксов IPv4. Основы автономных сетей описаны в [RFC7575] и [RFC7576]. Базовый протокол автономной сигнализации (GeneRic Autonomic Signaling Protocol или GRASP) описан в [RFC8990] и может использовать технические задачи для разработки решения по автономному управлению префиксами. Важной целью этого документа является его использование для проверки устройства GRASP и других компонентов ANI, как описано в [RFC8993].

Документ не является полной функциональной спецификацией системы автономного управления префиксами и не описывает детали параметров задач GRASP и процедур автономных агентов служб (Autonomic Service Agent или ASA), требуемых для построения полной системы. Вместо этого описана архитектурная модель, использующая компоненты ANI, варианты и аспекты развёртывания, а также определены задачи GRASP, применяемые для построения системы. Приведены также примеры основных параметров.

Документ не рассматривает все варианты управления префиксами IPv6. Фактически предполагается, что основные элементы инфраструктуры уже имеют адреса и префиксы. Документ посвящён вопросам максимально автономного управления префиксами на границах большой сети. Это специально рассчитано на сети поставщиков услуг Internet (Internet Service Provider или ISP). Хотя между ISP и крупными корпоративными сетями имеется сходство, требования для этих случаев различаются. В любом варианте область действия решения предполагается ограниченной одним доменом управления, как в любой автономной сети.

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

Задачи GRASP являются просто блоками построения системы.

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

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

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

В этом документе применяется терминология, заданная в [RFC7575].

3. Постановка задачи

Рассматриваемым здесь примером использования автономных сетей является автономное управление префиксами IPv6 на границе больших сетей ISP.

Хотя делегирование префиксов (DHCPv6 Prefix Delegation или DHCPv6-PD) [RFC8415] поддерживает автоматическое делегирование префиксов IPv6 одним маршрутизатором для другого, управление префиксами во многом зависит от планирования людьми. Иными словами, не существует базовой информации или правил для автономного принятия решений о размере префиксов, которые каждый маршрутизатор должен запрашивать или получать в зависимости от его роли в сети. Роли могут задаваться для отдельных устройств или быть базовыми (граничный маршрутизатор, внутренний маршрутизатор и т. п.). Кроме того, управление префиксами IPv6, выполняемое людьми, после исходного планирования часто бывает жёстким и статичным.

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

3.1. Предполагаемый опыт пользователей и администраторов

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

3.2. Анализ параметров и информации

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

  • Идентификация, проверка подлинности и полномочий данного устройства. Предполагается, что для этого будет применяться процесс защищённой начальной загрузки в автономной сети [RFC8995], после чего устройство сможет безопасно участвовать в автономных операциях.

  • Роль устройства (см. примеры в параграфе 6.1).

  • Размер префикса IPv6 для этого устройства.

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

Сеть в целом будет реализовать указанные ниже параметры.

  • Отождествление привязки доверия, являющейся удостоверяющим центром (certification authority или CA), поддерживаемым администраторами сети, который используется в процессе защищённой начальной загрузки.

  • Общее пространство адресов IPv6, доступных для граничных устройств (1 или несколько префиксов IPv6).

  • Исходный размер префикса для каждой роли устройств.

3.2.1. Параметры, которые устройство может задавать для себя

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

  • Принятая по умолчанию роль устройства.

  • Принятый по умолчанию размер префикса IPv6 для устройства.

  • Криптографическое отождествление устройства, требуемое для защищённой начальной загрузки [RFC8995].

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

3.2.2. Сведения, требуемые для сетевых операций

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

  • Размер префикса IPv6 для устройства. Значение должно задаваться в соответствии с ролью устройства.

  • Исходный размер префикса для каждой роли устройств.

  • Возможность устройства запрашивать дополнительные адреса.

  • Правила, связанные с запросом дополнительных адресов, например, запрос при использовании определённого числа или доли выделенных ранее адресов.

3.2.3. Сравнение с имеющимися решениями

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

Некоторые функции автономного и динамического управления адресами можно реализовать путём расширения имеющихся протоколов, например, DHCPv6-PD [RFC8415] для запроса префиксов IPv6 в соответствии с ролью устройства. Однако задание унифицированных ролей устройств может оказаться не совсем практичным, поскольку некоторые функции невозможно настроить по ролям с помощью имеющихся протоколов делегирования префиксов.

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

3.3. Взаимодействие с другими устройствами

3.3.1. Сведения, требуемые от других устройств

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

  • Сведения об отождествлении привязки доверия.

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

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

  • Принятое по умолчанию значение размера префикса IPv6 может быть переопределено.

  • Устройству требуется запросить и получить 1 или несколько префиксов IPv6 для себя и своих устройств нисходящего направления.

  • Устройство может отвечать на запросы делегирования префиксов от устройств нисходящего направления.

  • Устройству может потребоваться выделение дополнительного пространства адресов IPv6, если прежние уже исчерпаны.

3.3.2. Мониторинг, диагностика и отчёты

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

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

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

  • Следует сообщать о предсказуемом исчерпании адресного пространства.

4. Решение для автономного управления граничными префиксами

В этом разделе описаны компоненты решения для автономного управления префиксами на границе сети. Как отмечено в разделе 1, это не является полным описанием решений, которое будет зависеть от деталей реализации соответствующих агентов ASA. Используется базовый протокол обнаружения и согласования, заданный в [RFC8990]. Соответствующие задачи GRASP определены в разделе 5.

Описанные ниже процедуры выполняются агентом ASA в каждом устройстве, вовлечённом в решение. Далее они называются PrefixManager ASA.

4.1. Поведение устройства, запрашивающего префикс

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

Агенту PrefixManager ASA, нуждающемуся в дополнительном пространстве адресов, следует сначала найти партнёров, которые могут предоставить такие адреса. ASA следует передать сообщение GRASP Discovery с опцией PrefixManager Objective (см. раздел 2 в [RFC8650] и параграф 5.1) для нахождения партнёров, поддерживающих эту опцию. Затем следует выбрать одного из таких партнёров (скорей всего, ответившего первым).

Если сообщение GRASP Discovery Response содержит опцию Divert, указывающую PrefixManager ASA вне канала, запрашивающий агент ASA может инициировать согласование с указанным ASA для определения возможности получить префикс запрошенного размера.

В любом случае запрашивающий агент ASA выступает инициатором согласования GRASP путём отправки сообщения GRASP Request с опцией PrefixManager Objective, указывая в ней размер запрашиваемого префикса. Это запускает процесс согласования GRASP.

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

Как вариант, ASA может инициировать обнаружение GRASP в ускоренном (rapid) режиме с вложенным запросом согласования, если это реализовано.

4.2. Поведение устройства, предоставляющего префикс

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

Устройству, получившему сообщение Discovery с опцией PrefixManager Objective, следует передавать в ответ сообщение GRASP Response, если это устройство включает PrefixManager ASA. Дополнительные сведения о процессе обнаружения приведены в [RFC8990]. Когда этот агент ASA получает последующее сообщение Request, ему следует выполнить последовательность согласования GRASP, используя сообщения Negotiate, Confirm Waiting, Negotiation End. Сообщения Negotiate содержат опцию PrefixManager Objective, которая указывает префикс, предлагаемый запрашивающему ASA, и размер этого префикса. Как указано в [RFC8990], согласование продолжается, пока любая из сторон не передаст сообщение Negotiation End. Если согласование успешно, агент ASA, предоставивший префикс, удаляет согласованный префикс из своего пула, а запрашивающий ASA добавляет его себе. При отказе согласования сторона, передающая сообщение Negotiation End, может включить в него строку кода ошибки.

В процессе согласования ASA на каждом этапе решает, какого размера префикс следует предлагать. Это решение, равно как и решение о завершении согласования, зависит от реализации.

Как вариант, ASA может выполнять согласование в ответ на обнаружение GRASP в ускоренном (rapid) режиме, если он это реализует.

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

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

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

4.3. Поведение после успешного согласования

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

В некоторых случаях управление префиксами на основе ANI/GRASP может работать вместе с DHCPv6-PD [RFC8415] как дополнение. Например, метод на основе ANI/GRASP можно использовать внутри домена, а DHCPv6-PD — вне (т. е. через административную границу). Можно также применять ANI/GRASP внутри домена, а DHCP/DHCPv6-PD — на границе домена для клиентов (не ANI). Другим примером является применение внутри домена ANI/GRASP, а RADIUS [RFC2865] — для предоставления префиксов устройствам клиентов.

4.4. Регистрация префиксов

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

5. Задачи автономного управления префиксами

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

5.1. Опция Edge Prefix Objective

Опция PrefixManager Objective является опцией GRASP Objective, соответствующей спецификации GRASP [RFC8990]. Она имеет имя PrefixManager (см. радел 8) и передаёт в своём значении размер и фактические биты префикса. Поскольку протокол GRASP основан на кратком представлении двоичных объектов (Concise Binary Object Representation или CBOR) [RFC8949], формат опции PrefixManager Objective на языке краткого определения данных (Concise Data Definition Language или CDDL) [RFC8610] имеет вид

     objective = ["PrefixManager", objective-flags, loop-count,
                  [length, ?prefix]]

     loop-count = 0..255         ; как в спецификации GRASP
     objective-flags /=          ; как в спецификации GRASP
     length = 0..128             ; размер запрошенного или предложенного префикса
     prefix = bytes .size 16     ; предложенный префикс в двоичном формате

Использование режима пробного прогона (dry run) в GRASP не рекомендуется для этой цели, поскольку он потребует от обоих агентов ASA сохранять сведения о состоянии для соответствующего согласования, что не даёт реальной пользы — запрашивающий ASA не может основывать какие-либо решения на основе успеха пробного согласования.

5.2. Расширение для IPv4

Ниже представлена расширенная версия задачи PrefixManager, поддерживающая IPv4 за счёт добавления флага.

     objective = ["PrefixManager", objective-flags, loop-count, prefval]

     loop-count = 0..255         ; как в спецификации GRASP
     objective-flags /=          ; как в спецификации GRASP

     prefval /= pref6val
     pref6val = [version6, length, ?prefix]
     version6 = 6
     length = 0..128             ; размер запрошенного или предложенного префикса
     prefix = bytes .size 16     ; предложенный префикс в двоичном формате

     prefval /= pref4val
     pref4val = [version4, length4, ?prefix4]
     version4 = 4
     length4 = 0..32             ; размер запрошенного или предложенного префикса
     prefix4 = bytes .size 4     ; предложенный префикс в двоичном формате

Управление префиксами и адресами IPv4 существенно сложнее, чем для IPv6, в связи с распространённостью NAT, неоднозначностью адресов [RFC1918] и совместным использованием адресов [RFC6346]. Эти сложности могут потребовать дальнейшего расширения задачи с добавлением полей, не описанных в этом документе.

6. Параметры управления префиксами

Реализация менеджера префиксов должна включать принятые по умолчанию значения всех требуемых параметров. Однако внутри одного административного домена оператор сети может менять принятые по умолчанию параметры для всех устройств в той или иной роли. Таким образом, можно применять нужную политику для каждого устройства простым способом без традиционных файлов конфигурации. Как отмечено в параграфе 4.1, отдельные автономные устройства также могут динамически менять своё поведение. Например, оператор может изменить принятый по умолчанию размер префикса для каждого типа ролей. Задачу управления размерами префиксов, которая включает сведения о сопоставлении роли устройства с принятым по умолчанию размером префикса, можно лавинно разослать через сеть с использованием автономной плоскости управления (Autonomic Control Plane или ACP) [RFC8994].

     objective = ["PrefixManager.Params", objective-flags, any]

     loop-count = 0..255         ; как в спецификации GRASP
     objective-flags /=          ; как в спецификации GRASP

Объект any представляет определения соответствующих параметров (как в примере ниже), передаваемых как объект CBOR в подходящем формате. Это можно лавинно разослать всем узлам и любой агент PrefixManager ASA, не получивший сообщение по какой-либо причине, сможет получить копию через индивидуальную синхронизацию GRASP. При получении параметров управления префиксами каждое устройство может выбрать принятый по умолчанию размер префикса в соответствии со своей ролью.

6.1. Пример параметров управления префиксами

Параметры содержат сведения о ролях устройств и принятых на них по умолчанию размерах префиксов в автономном домене. Предположим, например, что оператор сети радио-доступа (IP Radio Access Network или IPRAN) хочет задать для контроллера радиосети (Radio Network Controller Site Gateway или RSG) размер префикса 34, для шлюза агрегирования (Aggregation Site Gateway или ASG) — 44, а для шлюза сотового узла (Cell Site Gateway или CSG) — 56. Это можно описать значение цели PrefixManager.Params в виде

   [
      [["role", "RSG"],["prefix_length", 34]],
      [["role", "ASG"],["prefix_length", 44]],
      [["role", "CSG"],["prefix_length", 56]]
   ]

Пример представлен в формате JSON [RFC8259], который легко перевести в CBOR. Можно представить параметры в форме YANG [RFC7950], используя отображение YANG в CBOR [CORE-YANG-CBOR].

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

Сеть IPRAN служит для транзитной мобильной связи, включая базовые станции, контроллеры радиосети (Radio Network Controller или RNC) для 3G или пакетное ядро для LTE и сеть IP между ними, как показано на рисунке 1. Объекты eNB (Evolved Node B), RNC, SGW (Serving Gateway) и MME (Mobility Management Entity) являются элементами сети, определёнными в 3GPP. Элементы CSG, ASG и RSG определены в решении IPRAN. Топология IPRAN на рисунке 1 включает кольца Ring1 (ASG1->RSG1->RSG2->ASG2->ASG1), Ring2 (CSG1->ASG1->ASG2->CSG2->CSG1) и Ring3 (CSG3->ASG1->ASG2->CSG3). В реальном развёртывании IPRAN может быть больше станций, колец и маршрутизаторов, а сеть обычно зависит от проектирования и настройки с участием людей, что не обеспечивает ни гибкости, ни экономической эффективности.

+------+   +------+
| eNB1 |---| CSG1 |\
+------+   +------+  \   +-------+       +------+           +-------+
               |       \ |  ASG1 |-------| RSG1 |-----------|SGW/MME|
               |  Ring2  +-------+       +------+ \        /+-------+
+------+   +------+     /     |              |      \    /
| eNB2 |---| CSG2 | \  /      |      Ring1   |        \/
+------+   +------+   \  Ring3|              |        /\
                     / \      |              |      /   \
+------+   +------+ /    \ +-------+      +------+/       \+-------+
| eNB3 |---| CSG3 |--------|  ASG2 |------| RSG2 |---------|  RNC  |
+------+   +------+        +-------+      +------+         +-------+

Рисунок . Топология сети IPRAN.


Если IPRAN поддерживает ANI/GRASP, узлам сети сети следует выполнять согласование между собой и принимать автономные решения в соответствии со своим статусом и собранными из сети сведениями. Параметры управления префиксами следует включать в обмен информацией. Маршрутизаторам следует знать роли своих соседей, принятый по умолчанию размер префикса для каждой роли и т. п. Шлюзам ASG следует поддерживать запросы префиксов у RSG, а шлюзам CSG — у ASG. В каждом запросе шлюзам ASG и CSG следует указывать размер префикса или свою роль для запроса префикса принятого по умолчанию размера.

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

Соответствующие вопросы безопасности рассмотрены в [RFC8990]. Предпочтительной моделью защиты является доверие к устройствам в соответствии с процедурой защищённой загрузки [RFC8995] и наличие защищённой плоскости ACP [RFC8994].

При использовании DHCPv6-PD рекомендуется применять аутентификацию DHCPv6 или Secure DHCPv6.

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

Этот документ определяет 2 новые опции GRASP Objective: PrefixManager и PrefixManager.Params. Агентство IANA добавило их в реестр GRASP Objective Names, заданный в [RFC8990].

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

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

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

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

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

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

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

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, «Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures», RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., «GeneRic Autonomic Signaling Protocol (GRASP)», RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, «ACK Autonomic Control Plane (ACP)», RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, «Bootstrapping Remote Secure Key Infrastructure (BRSKI)», RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.

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

[CORE-YANG-CBOR] Veillette, M., Ed., Petrov, I., Ed., and A. Pelov, «CBOR Encoding of Data Modeled with YANG», Work in Progress3, Internet-Draft, draft-ietf-core-yang-cbor-15, 24 January 2021, <https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15>.

[DHCP-YANG-MODEL] Liu, B., Ed., Lou, K., and C. Chen, «Yang Data Model for DHCP Protocol», Work in Progress, Internet-Draft, draft-liu-dhc-dhcp-yang-model-07, 12 October 2018, <https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-07>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC3046] Patrick, M., «DHCP Relay Agent Information Option», RFC 3046, DOI 10.17487/RFC3046, January 2001, <https://www.rfc-editor.org/info/rfc3046>.

[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, «Lightweight DHCPv6 Relay Agent», RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>.

[RFC6346] Bush, R., Ed., «The Address plus Port (A+P) Approach to the IPv4 Address Shortage», RFC 6346, DOI 10.17487/RFC6346, August 2011, <https://www.rfc-editor.org/info/rfc6346>.

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

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, «General Gap Analysis for Autonomic Networking», RFC 7576, DOI 10.17487/RFC7576, June 2015, <https://www.rfc-editor.org/info/rfc7576>.

[RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and A. Bierman, «Dynamic Subscription to YANG Events and Datastores over RESTCONF», RFC 8650, DOI 10.17487/RFC8650, November 2019, <https://www.rfc-editor.org/info/rfc8650>.

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

[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, «A Reference Model for Autonomic Networking», RFC 8993, DOI 10.17487/RFC8993, May 2021, <https://www.rfc-editor.org/info/rfc8993>.

Приложения A. Обзор внедрения

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

Параграф A.1 посвящён двум наиболее распространенным моделям развёртывания DHCP, параграф A.2 — модели PD, описанной в этом документе. Следует отметить, что на практике применяется большее число моделей.

A.1. Управление адресами и префиксами через DHCP

Развёртывание граничного сервера DHCP требует, чтобы каждый маршрутизатор, соединённый с устройствами на стороне клиента (Customer Premises Equipment или CPE), был сервером DHCP выделяющий адреса IPv4/IPv6 устройствам CPE и, возможно, префиксы IPv6 через DHCPv6-PD для поддерживающих IPv6 устройств CPE, являющихся маршрутизаторами, за которыми размещены ЛВС.

Это требует выполнения различных конфигурационных функций через некую внутреннюю (backend) систему (сервер конфигурации на рисунке 2). Число адресных префиксов на граничных интерфейсах следует поддерживать с некоторым запасом — больше числа подключённых CPE, чтобы адресное пространство использовалось эффективно.

                                              Граничные
         динамическ., NETCONF/YANG            интерфейсы
          <---------------> +--------------+
+-------+    <- домен       |Гранич. маршр/|-+  -----  +-----+
|Сервер | ... телеметрии ...|сервер DHCP   | |  ...    | CPE |+  ЛВС
|конфиг.|                   +--------------+ |  -----  +-----+| (---| )
+-------+                    +---------------+  DHCP/   +-----+
                                             DHCPv6-PD

Рисунок . Модель развёртывания DHCP без центрального сервера.


Сервер конфигурации должен предоставить адресные префиксы краевых интерфейсов и параметры DHCP для каждого граничного маршрутизатора. Использование слишком мелких префиксов ведёт к росту таблиц маршрутизации в домене, показанном на рисунке, а использование больших префиксов ведёт к избыточному расходу адресов. Это не очень актуально для IPv6, но при включении в модель IPv4 проблема становится серьёзной. Нет стандарта, описывающего алгоритмы, с помощью которых серверы конфигурации могли бы наилучшим способом выполнять такую динамическую настройку для оптимизации размера таблиц маршрутизации и эффективного использования адресного пространства. В настоящее время нет полной модели данных YANG, которую сервер конфигурации мог бы использовать для выполнения этих действий (включая телеметрию адресов, назначенных распределенными серверами DHCP). Например, модель данных YANG для управления операциями сервера DHCP находится в стадии разработки [DHCP-YANG-MODEL].

В связи с упомянутыми и другими проблемами применяется описанная ниже модель развёртывания DHCP.

+-------+                                    Граничные
|Сервер |    исходн., CLI                    интерфейсы
|конфиг.| ----------------> +--------------+
+-------+                   |Гранич. маршр/|-+  -----  +-----+
    |      .... домен ...   |ретрансл. DHCP| |  ...    | CPE |+  ЛВС
+------+                    +--------------+ |  -----  +-----+| (---| )
|Сервер|                      +--------------+  DHCP/   +-----+
|DHCP  |                                     DHCPv6-PD
+------+

Рисунок . Модель развёртывания DHCP с центральным сервером.


Распространение динамических изменений граничным маршрутизаторам исключается за счёт использования центрального сервера DHCP и смены роли граничного маршрутизатора с сервера на ретранслятор DHCP. Конфигурация граничных маршрутизаторов остаётся статичной. Функция ретранслятора DHCP включает граничный интерфейс и/или опции идентификации абонента в запросы DHCP от устройств CPE (например, [RFC3046] [RFC6221]), а у сервера DHCP имеются полные правила назначения адресов и префиксов для каждого граничного маршрутизатора, интерфейса, группы абонентов. Когда ретранслятор DHCP видит отклик DHCP, он вставляет статические маршруты для назначенных адресов и префиксов в таблицу граничного маршрутизатора и эти маршруты распространяются протоколом IGP (или BGP) внутри домена, чтобы все CPE и ЛВС были доступны через домен, показанный на рисунке.

Полной стандартизации таких решений не существует. Например, в параграфе 19.1.3 [RFC8415] просто говорится о «(неопределённом) протоколе или ином обмене по отдельному каналу (out-of-band) для настройки маршрутной информации для делегированных префиксов на любом маршрутизаторе, через который клиент может пересылать трафик».

A.2. Управление префиксами через ANI/GRASP

Для вариант использования ANI и агентов ASA, управляющих префиксами (PM-ASA) с помощью GRASP, модель развёртывания показана на рисунке 4.

|<............ домен ANI  / ACP............>| (...) ........->

                                   Роли
                                     |
                                     v   Граничные маршрутизаторы
Параметр GRASP                +----------+
Общесетевые                   |  PM-ASA  | Нисходящие
параметры и правила           | (Функции | интерфейсы
     |                        |  DHCP)   | ------
     v Центральное устройство +----------+
+------+                            ^             +--------+
|PM-ASA|      <............GRASP ....      ....   |  CPE   |-+ (ЛВС)
+------+             .              v             |(PM-ASA)| |  ---|
     .           +........+   +----------+        +--------+ |
+...........+    . PM-ASA .   |  PM-ASA  | ------  +---------+
.Сервер DHCP.    +........+   | (Функции | SLAAC/
+...........+   Промежуточный |  DHCP)   | DHCP/DHCP-PD
                маршрутизатор +----------+

Рисунок . Модель развёртывания с использованием ANI/GRASP.


В сети применяется домен ANI с ACP [RFC8994] между центральным устройством (например, маршрутизатором или устройством управления с поддержкой ANI) и граничными маршрутизаторами. ANI/ACP предоставляет создаваемый автоматически (zero-touch) канал связи между устройствами и разрешает использовать протокол GRASP [RFC8990] не только для взаимодействия партнёров, но и для распространения и лавинной рассылки информации.

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

Граничные маршрутизаторы могут исполнять разные роли в зависимости от типа и числа присоединённых устройств CPE. Каждый граничный маршрутизатор может быть RSG, ASG или CSG в сетях агрегирования мобильных устройств (см. параграф 6.1). Механизмы осознания маршрутизаторами своей роли выходят за рамки этого документа.

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

  1. В решении с минимальным управлением префиксами центральное устройство использует описанную в этом документе задачу GRASP PrefixManager.Params для распространения параметров граничным маршрутизаторам сети в соответствии с их ролями. Агент PM-ASA использует параметры, относящиеся к его роли для локальной настройки функций имеющейся адресации. Поскольку PM-ASA не управляет динамическим назначением фактических префиксов IPv6, можно рассмотреть указанные ниже варианты:

    1. Граничный маршрутизатор соединяется через интерфейсы нисходящего направления с каждым (хостом) CPE, которому нужен адрес. PM-ASA устанавливает для каждого такого интерфейса маршрутизатор, запрашивающий DHCP (в соответствии с [RFC8415]) для запроса префикса IPv6 для интерфейса. Адрес маршрутизатора на нисходящем интерфейсе может быть параметром из задачи GRASP. CPE назначает адреса из префикса через анонсы маршрутизаторов (Router Advertisement или RA) или PM-ASA управляет локальным сервером DHCPv6 для назначения адресов устройствам CPE. Нужен центральный сервер DHCP, выполняющий функции делегирующего маршрутизатора DHCP (в соответствии с [RFC8415]). Его адрес может быть параметром из задачи GRASP.

    2. Граничный маршрутизатор подключается через нисходящие интерфейсы к (управляемым клиентом) устройствам CPE, которые являются маршрутизаторами и запрашивают DHCPv6. Необходимость этого может выводиться из роли или параметров GRASP, а PM-ASA устанавливает функцию ретрансляции DHCP для пересылки запросов центральному серверу DHCP как в п. 1.a.

  2. В решении без центрального сервера DHCP агенты PM-ASA на граничных маршрутизаторах не только изучают параметры из PrefixManager.Params, но и применяют GRASP для запроса и согласования фактического выделения префиксов IPv6 через задачу GRASP PrefixManager, как описано ниже. В простейшем случае префиксы делегируются через эту задачу GRASP от PM-ASA в центральном устройстве, которое должно изначально иметь большой пул адресов. Затем делегированные префиксы используются PM-ASA на граничных маршрутизаторах для настройки префиксов нисходящих интерфейсов с целью их назначения через RA/SLAAC хостам CPE. Агенты PM-ASA могут также запускать локальные серверы DHCP (как в п. 1.a) для назначения через DHCP адресов из выделенных префиксов устройствам CPE. Это включает хосты CPE, запрашивающие адреса IPv6 и маршрутизаторы CPE, которым нужны префиксы IPv6. Агентам PM-ASA нужно управлять пулами адресов, запрошенными через GRASP, и выделять части этих пулов интерфейсам и запущенным серверам DHCP. Они должны отслеживать использование адресов и в соответствии с этим запрашивать дополнительные префиксы при нехватке или возвращать ненужные адреса.

    Это решение весьма похоже на предыдущую модель развёртывания IPv6 DHCP без центрального сервера DHCP, а ANI/ACP/GRASP и PM-ASA обеспечивают автоматизацию позволяющую упростить этот подход.

  3. Пулы адресов для выделения префиксов не обязательно брать из одного центрального узла. Агент PM-ASA на граничном маршрутизаторе, получивший большой (короткий) префикс от центрального PM-ASA, может предлагать более мелкие префиксы агентам PM-ASA в соседних маршрутизаторах. Протокол GRASP можно использовать так, чтобы агенты PM-ASA могли находить и выбирать задачи у ближайших соседних PM-ASA, что позволит максимизировать агрегирование. PM-ASA будет впоследствии запрашивать более мелкие префиксы, когда исчерпает свой пул (от центрального узла) и не сможет больше получить от того большой префикс. Поскольку дополнительные префиксы получаются от топологически ближайшего PM-ASA, число более длинных префиксов, включаемых в таблицы маршрутизации, будет ограничено и топологическая близость повышает шансы того, что агрегирование префиксов в IGP скорей всего ограничит область, в которой требуется маршрутизировать более длинные префиксы.

  4. Вместо оптимизации делегирования префиксов между партнёрами (peer-to-peer) можно организовать иерархию PM-ASA (на рисунке 4 показан точками промежуточного маршрутизатора). Это потребует дополнительных параметров в задаче PrefixManager для построения иерархии PM-ASA, через которую можно делегировать префиксы.

  5. В случаях, когда CPE являются частью домена ANI (например, управляемые CPE), GRASP будет распространяться на сайты фактических клиентов и сможет управлять PM-ASA. Все варианты, описанные в пп. 1 — 4, подойдут для CPE, выступающего граничным маршрутизатором, с некоторыми изменениями — (a) маршрутизатору CPE, скорей всего, не потребуется самому запускать DHCPv6-PD и достаточно назначать адреса DHCP и (b) граничные маршрутизаторы, к которым подключён CPE, скорей всего, будут идеальным местом для запуска иерархических экземпляров PD-ASA, как описано в п. 1.

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

Значимые комментарии были получены от William Atwood, Fred Baker, Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan Romascanu, Chongfeng Xie.

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

Sheng Jiang (editor)
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No. 156 Beiqing Road
Hai-Dian District, Beijing
100095
China
Email: jiangsheng@huawei.com
 
Zongpeng Du
China Mobile
32 Xuanwumen West St
Xicheng District, Beijing
100053
China
Email: duzongpeng@chinamobile.com
 
Brian Carpenter
University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
 
Qiong Sun
China Telecom
118 Xizhimennei St
Beijing
100035
China
Email: sunqiong@chinatelecom.cn

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

nmalykh@protokols.ru


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

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

3Опубликовано в RFC 9254. Прим. перев.

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