Internet Engineering Task Force (IETF) Q. Ma, Ed.
Request for Comments: 10065 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 M. Boucadair, Ed.
Orange
D. King
Lancaster University
October 2026
A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control
Модель данных YANG и расширение RADIUS для контроля доступа в сеть на основе правил
Аннотация
В этом документе определена модель данных YANG для управления доступом в сеть на основе правил, которая позволяет применять политику управления доступом на основе отождествления групп. Эта модель расширяет списки контроля доступа (Access Control List или ACL) параметрами даты и времени для поддержки расписаний применения правил. В сценариях, где доступ в сеть определяется аутентификацией пользователей, этот документ задаёт механизм, который упрощает сопоставление идентификатора группы пользователя с набором полей заголовка пакета для применения контроля доступа в сеть на основе правил. Кроме того, документ определяет атрибут RADIUS (Remote Authentication Dial-in User Service) для передачи идентификатора группы пользователя как части сведений для проверки подлинности и полномочий.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительные сведения о документах Internet Standard приведены в разделе 2 RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc10065.
Авторские права
Авторские права (Copyright (c) 2026) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с пересмотренной лицензией BSD (Revised BSD License), как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Введение
Широкое внедрение технологий удалённого доступа (например, VPN3 и правил BYOD4) обеспечивает предприятиям большую гибкость в части местоположения сотрудников и способов их взаимодействия. Однако такая гибкость сопряжена с повышением рисков. Возможность гибкой организации рабочего процесса (например, мобильность сотрудников) создаёт крупным организациям ряд проблем, которых не возникало при традиционном подходе к доступу в сеть. Примеры таких проблем приведены ниже.
-
Конечные точки не имеют стабильных и уникальных адресов IP. Например, клиенты беспроводных сетей (Wireless LAN или WLAN) и VPN, а также back-end-серверы на основе виртуальных машин (Virtual Machine или VM) могут перемещаться, а их адреса IP могут меняться с течением времени. Кроме того, такие механизмы как временные адреса IPv6 [RFC8981] и трансляция сетевых адресов и портов (Network Address Port Translation или NAPT) [RFC3022] могут вносить свой вклад в нестабильность и неуникальность адресов. Это усложняет согласованное применение правил доступа на основе полей IP и транспорта (например, 5-tuple). Правила на основе адресов IP могут оказаться недостаточно гибкими для конечных точек с изменчивыми адресами IP.
-
Массовое распространение удалённой работы вызывает необходимость применения различных правил безопасности для одного набора конечных точек в разных обстоятельствах (например, для предотвращения ретрансляционных атак на локальные точки подключения к сети предприятия). Доступ в сеть может предоставляться, например, на основе таких критериев, как местоположение пользователя, репутация сети доступа, роль пользователя, время суток, тип применяемого устройства (например, устройство работодателя или пользователя), уровень защиты устройства и т. п. Это означает, что сеть должна распознавать отождествления конечных точек и их текущий контекст, а также сопоставлять конечные точки с действующими для них правами доступа в сеть.
Этот документ задаёт модель данных YANG (параграф 5.2) для управления доступом в сеть на основе правил, которая расширяет модуль IETF для списков управления доступом (ACL) заданный в [RFC8519]. Модуль можно использовать для согласованного применения правил ACL на основе идентификации групп. Кроме того, модель добавляет в ACL параметры даты и времени для поддержки применения правил по расписанию.
Концепция ACL была обобщена как не зависимая от устройства и её можно применять на уровне сети или административного домена [RFC9899]. Для поддержки всех приложений ACL в параграфе 5.2. задан модуль YANG для ACL на основе правил, не имеющий ограничений на применение.
Для сценариев, в которых доступ в сеть инициируется проверкой подлинности пользователя, этот документ определяет механизм сопоставления (1) идентификатора группы пользователей (ID) со (2) стандартными полями заголовка пакета IP и другими данными инкапсуляции пакета (например, MAC5-адресом) для управления доступом на основе правил. Документ также задаёт атрибут RADIUS [RFC2865], применяемый для передачи идентификатора группы как части сведений для идентификации и проверки полномочий (раздел 6).
Хотя в примерах используются MAC-адреса, документ не принимает допущений о типе идентификаторов, используемых в ACL. Примеры не следует рассматривать как рекомендации. Читателю следует осознавать, что ACL на основе MAC можно обойти путём сброса или изменения MAC-адресов. Другие аспекты, связанные с изменением MAC-адресов, рассмотрены в [RFC9797].
Документ не задаёт сопоставления идентификаторов групп с выделенными полями пакетов. Основанная на группах политика (Group-Based Policy или GBP), рассмотренная в параграфе 6.2.3 [RFC9638], является примером такого сопоставления.
2. Соглашения и определения
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
Использование символов в диаграммах деревьев описано в [RFC8340].
В документе используются термины из [RFC8519]:
-
Access Control Entry (ACE) — запись управления доступом;
-
Access Control List (ACL) — список управления доступом.
Ниже приведены определения дополнительных терминов, используемых в документе.
Enterprise device — корпоративное устройство
Устройство, входящее в домен контроля доступа с централизованным управлением (обычно администратор предприятия). Это устройство обеспечивает вычислительные мощности, память, хранилище, сетевые возможности и само подключено к сети. Таким устройством может быть сервер, на котором размещены приложения или программы для предоставления услуг корпоративным пользователям, или устройство IoT6 с ограниченным набором функций. Хотя личные устройства (BYOD) не являются физическими активами предприятия, при доступе к корпоративным ресурсам с централизованным управлением для них тоже применяются правила контроля доступа.
Endpoint — конечная точка
Конечный пользователь, корпоративное устройство или приложение, фактически подключаемое к сети.
Endpoint group — группа конечных точек
Группа конечных точек с общим набором правил управления доступом.
User group — группа пользователей
Группа конечных пользователей, которым назначены общие правила доступа в сеть. Конечным пользователем считается человек (см. параграф 4.2.1).
Device group — группа устройств
Набор корпоративных устройств с общими правилами управления доступом (см. параграф 4.2.2).
Application group — группа приложений
Набор приложений с общими правилами управления доступом. Приложением считается программа, используемая для конкретной службы (см. параграф 4.2.3).
Endpoint group identifier — идентификатор группы конечных точек
Идентификатор, служащий для коллективного отождествления группы конечных точек, которой может быть группа пользователей, группа устройств или группа приложений.
User-group-based Control List (UCL) data model — модель данных контроля доступа по группам пользователей
Модель данных YANG для физического контроля доступа в сеть, задающая расширение модуля ietf-access-control-list [RFC8519]. Модель позволяет применять правила на основе идентификатора группы на уровне сетевого устройства или сети (административного домена).
Policy — правила (политика)
Набор правил для администрирования, поддержки и управления доступом к ресурсам сети [RFC3198].
3. Варианты применения
Доступ в некоторые сети (например, корпоративные) требует распознавания конечных точек, независимо от способа, времени и точки подключения к ресурсам сети. Сеть сопоставляет подключающиеся конечные точки с предоставленными им правами доступа, которые задаются локальными правилами. Как указано в разделе 1, из-за (1) наличия большого числа подключающихся конечных точек и (2) различных IP-адресов этих точек в разных сегментах сети реализация политики управления доступом для каждого адреса IP или сегмента сети требует высоких затрат. Другим подходом является организация групп конечных точек для классификации пользователей, корпоративных устройств и приложений с настройкой ACL для каждой группы конечных точек с правилами, подходящими для всех членов конкретной группы. Это существенно снижает издержки на администрирование и оптимизацию ресурсов ACL. Сетевые ACL могут быть заданы на устройствах с помощью разных механизмов (см., например, [RFC8519] или [RFC9899]).
В разных ситуациях могут потребоваться различные правила. Например, компания может предоставлять сотрудникам доступ к конкретным внутренним или внешним ресурсам в рабочие часы, а в остальное время будут применяться другие правила. Администратор сети может также задать формирование трафика (параграф 2.3.3.3 в [RFC2475]) и управление им (параграф 2.3.3.4 в [RFC2475]) в часы пиковой нагрузки, чтобы не возникало препятствий для данных других служб.
4. Управление доступом в сеть на основе правил
4.1. Обзор
Пример архитектуры системы с согласованным применением правил управления доступом в реальном масштабе времени представлен на рисунке 1. Архитектура иллюстрирует ориентированный на пользователя поток, включающий указанные ниже функциональные элементы и интерфейсы.
-
Оркестратор координирует службу в целом, включая политику безопасности. Услугой может быть подключение или иной доступ к ресурсам, размещённым в сети или предоставляемым ею.
-
Контроллер SDN7 [RFC7149] [RFC7426] отвечает за поддержку ACL по группам конечных точек и сопоставление групп с соответствующими атрибутами (например, фильтрами по заголовкам пакетов). Контроллер SDN также служит точкой принятия решений (Policy Decision Point или PDP) [RFC3198] и передаёт требуемые правила управления доступом соответствующим точкам применения правил (Policy Enforcement Point или PEP) [RFC3198]. PDP также называют сервером политики (policy server) [RFC2753].
Контроллер SDN может взаимодействовать с сервером аутентификации, предоставления полномочий и учёта (Authentication, Authorization, and Accounting или AAA) [RFC3539] или сервером доступа в сеть (Network Access Server или NAS) [RFC7542].
-
NAS обрабатывает запросы аутентификации, взаимодействуя с сервером AAA для завершения аутентификации по протоколу, такому как RADIUS [RFC2865]. Когда доступ разрешён, сервер AAA предоставляет идентификатор группы, к которой относится пользователь, для первого входа пользователя в сеть. Для этого в разделе 6 задан новый атрибут RADIUS.
-
Сервер AAA предоставляет набор функций аутентификации, предоставления полномочий и учёта. Сервер отвечает за централизованную поддержку информации о пользователях. На сервере AAA заранее задаются свидетельства пользователей (например, имя и пароль), возможные идентификаторы групп и другие атрибуты пользователя (пользователи могут делиться на группы по их атрибутам).
-
PEP является центральным элементом, отвечающим за применение соответствующих правил доступа. Один вариант внедрения предполагает, что контроллер SDN сопоставляет идентификатор группы с соответствующим общим заголовком пакета и предоставляет правила ACL на основе полей заголовка соответствующим PEP. Другой вариант может требовать от PEP сопоставления входящих пакетов со связанными с ними идентификаторами групп отправителя и/или получателя и действий на основе правил ACL для группы (например, идентификатор группы может передаваться в заголовках пакетов, как описано в параграфе 6.2.3 [RFC9638]). В сети может быть несколько узлов PEP.
PEP предоставляет контроллеру SDN интерфейс на основе YANG (например, NETCONF [RFC6241]).
На рисунке 1 представлена общая архитектура и процедуры управления доступом на основе правил.
.------------.
|Оркестратор |
'------+-----'
Служба | (Этап 1)
-------------------------------------------)-------------
Сеть |
Этап 4 |
.-------. .--------. .--------+--------.
|User #1+--+ | Сервер | | Контроллер SDN |
'-------' | | AAA +-----+ PDP |
| '----+---' '--------+--------'
| | |
| | +------+--------+ Этап 5
Этап 2 | | Этап 3 | |
| | | |
| .-+-----------+---------------+-------------.
+--------+ |
| .----------------------. .--------------. |
.-------. | | Сервер доступа в сеть| | МСЭ и т. п. | |
|User #2+-----------+ | (NAS) | '--------------' |
'-------' | '----------------------' |
| PEP |
'-------------------------------------------'
Рисунок 1. Пример архитектуры для управления правилами по группам.
Ниже описан типичный поток операций.
Этап 1
Администраторы (или оркестратор службы) настраивают на контроллере SDN списки ACL сетевого уровня с использованием модуля YANG из параграфа 5.2. Пример конфигурации представлен в Приложении A.1.
Этап 2
При первом подключении пользователя к сети нужно проверить его подлинность (например, по имени и паролю) на узле NAS.
Этап 3
Запрос аутентификации передаётся серверу AAA с помощью протокола, такого как RADIUS [RFC2865]. Предполагается, что на сервере AAA хранятся учётные данные пользователей, такие как имя, пароль, принадлежность к группам и другие атрибуты. Этот документ не ограничивает выбор методов аутентификации. Администраторы могут обратиться за рекомендациями, например, к параграфу 7.4 в [RADIUS-DEPRECATE].
Если проверка подлинности пользователя прошла, он помещается в группу, идентификатор которой возвращается NAS как результат аутентификации (см. раздел 6). Если проверка не прошла, пользователь не включается ни в какую группу, что означает отказ от предоставления доступа (т. е. возврат Access-Reject), или включается в особую группу с ограниченным доступом в сеть (в соответствии с локальной политикой) и применяются ACL, отбрасывающие потоки с IP-адресом пользователя или ограничивающие их скорость.
В некоторых реализациях сервер AAA может быть объединён с контроллером SDN.
Этап 4
Сервер AAA или NAS передаёт контроллеру SDN сопоставление идентификатора группы пользователя с соответствующими атрибутами заголовка пакета (например, 5-tuple). Детали таких уведомлений выходят за рамки этой спецификации.
Этап 5
В соответствующих PEP, управляемых контроллером SDN, поддерживаются правила управления доступом по группам или полям заголовка пакета. PEP может включать оба типа ACL, примеры даны в приложениях A.2 и A.3.
Аналогичный процесс применяется и для управления политикой на основе других типов конечных точек, таких как группы устройств или приложений, за исключением того, что сопоставления идентификатора группы с атрибутами заголовка пакета (например, 5-tuple) могут поддерживаться в контроллере SDN на основе инвентаризации или реестра приложений и в таких случаях обмен RADIUS не требуется (раздел 6).
Эксплуатационные рекомендации приведены в разделе 8.
4.2. Группы конечных точек
4.2.1. Группа пользователей
Группа пользователей определяется набором предопределённых критериев политики (например, IP-адрес источника, данные местоположения, время суток, сертификат устройства). Группа имеет идентификатор для коллективного представления входящих в неё пользователей. Пользователи могут перемещаться из одной группы в другую при изменении их атрибутов, среды или локальной политики предприятия.
Пользователь проходит аутентификацию, классифицируется на сервере AAA и ему назначается группа. Принадлежность к группе может меняться при изменении тех или иных аспектов пользователя. Например, если принадлежность к группе определяется лишь IP-адресом источника, идентификатор группы будет меняться при получении пользователем другого адреса IP, не относящегося к диапазону адресов прежней группы пользователей.
В этом документе не принимаются какие-либо допущения об определении групп пользователей, поскольку это зависит от конкретной системы. Однако для иллюстрации в таблице 1 приведён пример определения групп. Группы могут иметь пересекающиеся критерии, т. е. не быть взаимоисключающими. Например, в группы R&D Regular и R&D BYOD могут входить одни и те же сотрудники R&D и вхождение в группу определяется используемым устройством (личное или корпоративное). Аналогично, один и тот же пользователь может относиться к разным группа в зависимости от времени или дня недели (например, выходной или рабочий день) и т. д.
Таблица 1. Примеры групп пользователей.
|
Имя группы |
Идентификатор |
Описание группы |
|---|---|---|
|
R&D Regular |
foo-10 |
Сотрудники R&D |
|
R&D BYOD |
foo-11 |
Личные устройства сотрудников R&D |
|
Отдел продаж |
foo-20 |
Сотрудники отдела продаж |
|
VIP |
foo-30 |
VIP-сотрудники |
4.2.2. Группа устройств
Идентификатор группы устройств представляет набор устройств предприятия. Примеры таких групп даны в таблице 2.
Таблица 2. Примеры групп устройств.
|
Имя группы |
Идентификатор |
Описание группы |
|---|---|---|
|
Рабочий процесс |
bar-40 |
Серверы ресурсов рабочего процесса |
|
Ресурс R&D |
bar-50 |
Серверы ресурсов R&D |
|
Принтерный ресурс |
bar-60 |
Принтерные ресурсы |
Сопоставление с абстрактным идентификатором группы вместо конкретного адреса в правилах ACL помогает избежать проблем, связанных со сменой адресов (например, при переносе сервера в среде виртуальных машин).
4.2.3. Группа приложений
Группой приложений является набор приложений с общими правилами управления доступом. На устройстве может работать множество приложений, для которых могут применяться разные правила доступа, наряду с правилами доступа для устройства. Одному приложению может потребоваться запуск на нескольких устройствах, виртуальных машинах и/или контейнерах. Абстракция группы приложений упрощает процесс миграции приложения, например, правила могут не зависеть от транспортных параметров (к примеру, 5-tuple). В таблице 3 показаны примеры определения групп приложений.
Таблица 3. Примеры групп приложений.
|
Имя группы |
Идентификатор |
Описание группы |
|---|---|---|
|
Голосовые и видеопотоки |
baz-70 |
Приложения аудио- и видеоконференций |
|
Мгновенные сообщения |
baz-80 |
Мессенджеры |
|
Совместная работа с документами |
baz-90 |
Работа с документами в реальном масштабе времени |
4.3. Связи между разными группами конечных точек
Применение правил может быть нацелено на разные группы конечных точек. Например, при подключении пользователя к сети и доступе к приложению, размещённому на одном или нескольких устройствах, политика может применяться к разным группам пользователей. В некоторых случаях приложения и устройства могут работать без участия пользователя или требовать аутентификации пользователя, но правила доступа не различают пользователей. Это позволяет применять правила к группе приложений или устройств. Группа устройств может применяться, когда на устройстве работает только одно приложение или разные приложения с общими правилами контроля доступа. Если приложение работает на разных устройствах, VM или контейнерах, проще применять правила для группы приложений.
5. Расширение UCL для модуля ACL
5.1. Обзор модуля
Этот модуль задаёт расширение модуля ietf-access-control-list [RFC8519], добавляющее группы конечных точек с идентификатором для сопоставления, а также позволяющее управлять правилами доступа с учётом даты и времени. Дерево модуля ietf-ucl-acl представлено на рисунке 2.
module: ietf-ucl-acl
augment /acl:acls:
+--rw endpoint-groups {ucl:group}?
+--rw endpoint-group* [group-id]
+--rw group-id string
+--rw group-type? identityref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw endpoint-group {ucl:match-on-group}?
+--rw source-group-id? group-id-reference
+--rw destination-group-id? group-id-reference
augment /acl:acls/acl:acl/acl:aces/acl:ace:
+--rw effective-schedule {ucl:schedule}?
+--rw (schedule-type)?
+--:(period)
| +--rw period
| +--rw period-description? string
| +--rw period-start? yang:date-and-time
| +--rw time-zone-identifier? sys:timezone-name
| +--rw (period-type)?
| +--:(explicit)
| | +--rw period-end? yang:date-and-time
| +--:(duration)
| +--rw duration? duration
+--:(recurrence)
+--rw recurrence {schedule:icalendar-recurrence}?
+--rw recurrence-first
| +--rw start-time? yang:date-and-time
| +--rw duration? duration
+--rw time-zone-identifier? sys:timezone-name
+--rw (recurrence-end)?
| +--:(until)
| | +--rw until? yang:date-and-time
| +--:(count)
| +--rw count? uint32
+--rw recurrence-description? string
+--rw frequency? identityref
+--rw interval? uint32
+--rw period* [period-start]
| +--rw period-description? string
| +--rw period-start yang:date-and-time
| +--rw time-zone-identifier? sys:timezone-name
| +--rw (period-type)?
| +--:(explicit)
| | +--rw period-end? yang:date-and-time
| +--:(duration)
| +--rw duration? duration
+--rw bysecond* uint32
+--rw byminute* uint32
+--rw byhour* uint32
+--rw byday* [weekday]
| +--rw direction* int32
| +--rw weekday schedule:weekday
+--rw bymonthday* int32
+--rw byyearday* int32
+--rw byyearweek* int32
+--rw byyearmonth* uint32
+--rw bysetpos* int32
+--rw workweek-start? schedule:weekday
+--rw exception-dates* yang:date-and-time
Рисунок 2. Структура дерева модуля ietf-ucl-acl.
Первая часть модуля ietf-ucl-acl дополняет контейнер acls модуля ietf-access-control-list [RFC8519] контейнером endpoint-groups, включающим список endpoint-group, где каждая запись имеет group-id для идентификации группы конечных точек и параметр group-type, указывающий тип группы.
Параметр group-id определён как строка, а не целое число без знака (например, uint32), чтобы соответствовать имеющимся системам, где нужна определённая иерархия идентификации в домене, предназначенная для упрощения координации в административном домене. Возможны ситуации, когда домену требуется помечать пакеты для указания группы, к которой они относятся. Маркировка не обязана точно следовать group ID в политике. Сопоставление group-id с тегами или полями в заголовке пакета при инкапсуляции выходит за рамки этого документа. В будущем может быть добавлено расширение, учитывающее инкапсуляцию.
Вторая часть модуля ietf-ucl-acl дополняет контейнер matches в модуле ietf-access-control-list [RFC8519], чтобы можно было указывать идентификатор группы конечной точки источника и/или получателя как критерий соответствия.
Третья часть модуля дополняет список ace в модуле ietf-access-control-list [RFC8519] параметрами даты и времени, чтобы обеспечить активацию записей списка контроля доступа (ACE) по расписанию. Заданы два типа интервалов (period и recurrence), которые используют группировки period-of-time и icalendar-recurrence (соответственно) из модуля YANG ietf-schedule [RFC9922].
5.2. Модуль ietf-ucl-acl
Этот модуль импортирует типы и группировки из модуля ietf-schedule [RFC9922], а также дополняет модуль ietf-access-control-list (параграф 4.1 в [RFC8519]).
<CODE BEGINS> file "ietf-ucl-acl@2026-10-07.yang"
module ietf-ucl-acl {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ucl-acl";
prefix ucl;
import ietf-access-control-list {
prefix acl;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)";
}
import ietf-schedule {
prefix schedule;
reference
"RFC 9922: A Common YANG Data Model for Scheduling";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: https://datatracker.ietf.org/wg/opsawg
WG List: OPSAWG <mailto:opsawg@ietf.org>
Editor: Qiufang Ma
<mailto:maqiufang1@huawei.com>
Author: Qin Wu
<mailto:bill.wu@huawei.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Daniel King
<mailto:d.king@lancaster.ac.uk>";
description
"Модуль YANG для списков управления по группам пользователей (UCL)
дополняет модуль IETF для списков контроля доступа (ACL). UCL
предназначен для согласованного применения правил ACL на основе
принадлежности к группе.
Авторские права (Copyright (c) 2026) принадлежат IETF Trust
и лицам, указанным в качестве авторов кода. Все права защищены.
Распространение и использование в исходной или двоичной форме с
изменениями или без таковых разрешено в соответствии с лицензией
Simplified BSD, изложенной в разделе 4 IETF Trust's Legal
Provisions применительно к документам IETF
(http://trustee.ietf.org/license-info).
Все выпуски модулей, опубликованных IETF и IANA можно найти в
группе реестров YANG Parameters
(https://www.iana.org/assignments/yang-parameters).
Эта версия данного модуля YANG является частью RFC 10065, где
правовые вопросы рассмотрены более полно.";
revision 2026-10-07 {
description
"Исходный выпуск.";
reference
"RFC 10065: A YANG Data Model and RADIUS Extension for
Policy-Based Network Access Control";
}
feature schedule {
description
"Указывает поддержку записей ACE по расписанию.";
}
feature match-on-group {
description
"Указывает поддержку сопоставления групп конечных точек.";
}
feature group {
if-feature "ucl:match-on-group";
description
" Указывает поддержку ACL по группам.";
}
feature mixed-ipv4-group {
if-feature "acl:match-on-ipv4 and ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv4.";
}
feature mixed-ipv6-group {
if-feature "acl:match-on-ipv6 and ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv6.";
}
feature mixed-ipv4-ipv6-group {
if-feature "acl:match-on-ipv4 and acl:match-on-ipv6 and "
+ "ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv4 и IPv6.";
}
feature mixed-eth-group {
if-feature "acl:match-on-eth and ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам Ethernet.";
}
feature mixed-eth-ipv4-group {
if-feature "acl:match-on-eth and acl:match-on-ipv4 and "
+ "ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv4 и Ethernet.";
}
feature mixed-eth-ipv6-group {
if-feature "acl:match-on-eth and acl:match-on-ipv6 and "
+ "ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv6 и Ethernet.";
}
feature mixed-eth-ipv4-ipv6-group {
if-feature "acl:match-on-eth and acl:match-on-ipv4 and "
+ "acl:match-on-ipv6 and ucl:match-on-group";
description
"Поддерживаются ACL по группам и адресам IPv4, IPv6 и Ethernet.";
}
identity group-acl-type {
if-feature "group";
base acl:acl-base;
description
"ACL, соответствующий по идентификатору группы конечных точек,
который отождествляет набор аутентифицированных пользователей,
оконечных устройств или приложений. Идентификатор группы
конечных точек может передаваться во внешнем или внутреннем
заголовке пакета (например, в инкапсуляции NVO38 или не
соответствовать ни одному из полей заголовков. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-ipv4-group-type {
if-feature "mixed-ipv4-group";
base acl:ipv4-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовка
IPv4 и идентификаторами групп конечных точек, которые могут
отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-ipv6-group-type {
if-feature "mixed-ipv6-group";
base acl:ipv6-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовка
IPv6 и идентификаторами групп конечных точек, которые могут
отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-ipv4-ipv6-group-type {
if-feature "mixed-ipv4-ipv6-group";
base acl:ipv4-acl-type;
base acl:ipv6-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовков
IPv4, IPv6 и идентификаторами групп конечных точек, которые
могут отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-eth-group-type {
if-feature "mixed-eth-group";
base acl:eth-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовков
Ethernet и идентификаторами групп конечных точек, которые
могут отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-eth-ipv4-group-type {
if-feature "mixed-eth-ipv4-group";
base acl:eth-acl-type;
base acl:ipv4-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовков
Ethernet, IPv4 и идентификаторами групп конечных точек, которые
могут отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-eth-ipv6-group-type {
if-feature "mixed-eth-ipv6-group";
base acl:eth-acl-type;
base acl:ipv6-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовков
Ethernet, IPv6 и идентификаторами групп конечных точек, которые
могут отождествлять группы аутентифицированных пользователей,
оконечных устройств или приложений. Поля заголовка
L4 также могут применяться в записях ACE.";
}
identity mixed-eth-ipv4-ipv6-group-type {
if-feature "mixed-eth-ipv4-ipv6-group";
base acl:eth-acl-type;
base acl:ipv4-acl-type;
base acl:ipv6-acl-type;
base ucl:group-acl-type;
description
"ACL с сочетанием записей, сопоставляемых с полями заголовков
Ethernet, IPv4, IPv6 и идентификаторами групп конечных точек,
которые могут отождествлять группы аутентифицированных
пользователей,оконечных устройств или приложений. Поля
заголовка L4 также могут применяться в записях ACE.";
}
identity endpoint-group-type {
description
"Тип группы конечных точек.";
}
identity user-group {
base ucl:endpoint-group-type;
description
"Группа пользователей.";
}
identity device-group {
base ucl:endpoint-group-type;
description
"Группа устройств.";
}
identity application-group {
base ucl:endpoint-group-type;
description
"Группа приложений.";
}
typedef group-id-reference {
type leafref {
path "/acl:acls/ucl:endpoint-groups"
+ "/ucl:endpoint-group/ucl:group-id";
}
description
"Ссылка на идентификатор группы.";
}
augment "/acl:acls" {
if-feature "ucl:group";
description
"Добавляет контейнер для задания группы конечных точек.";
container endpoint-groups {
description
"Контейнер для листа группы конечных точек.";
list endpoint-group {
key "group-id";
description
"Определение листа группы конечных точек.";
leaf group-id {
type string {
length "1..64";
}
description
"Уникальный идентификатор группы конечных точек.";
}
leaf group-type {
type identityref {
base endpoint-group-type;
}
description
"Задаёт тип группы конечных точек (пользователи,
устройства, приложения). По умолчанию группа не имеет
типа (базовая).";
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
if-feature "ucl:match-on-group";
description
"Задаёт способ указания идентификаторов групп источника и/или
получателя в качестве критерия сопоставления в ACE.";
container endpoint-group {
when "derived-from-or-self(/acl:acls/acl:acl/acl:type, "
+ "'ucl:group-acl-type')";
description
"Добавляет новый способ сопоставления на основе идентификатора
группы, связанного с конечной точкой отправителя и/или
получателя пакета.
Отметим, сто этот контейнер действителен только с ACL типа
group-acl-type или производного от него типа, зависящего от
свойства group. Реализации, анонсирующей match-on-group,
необходимо также поддерживать свойство group для
обеспечения пригодности этого контейнера.";
leaf source-group-id {
type group-id-reference;
description
"Соответствующий идентификатор группы конечных точек,
являющейся источником.";
}
leaf destination-group-id {
type group-id-reference;
description
"Соответствующий идентификатор группы конечных точек,
являющейся получателем.";
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace" {
if-feature "ucl:schedule";
description
"Добавляет параметры расписания для применения ACE
по дате и времени.";
container effective-schedule {
description
"Определяет время и дату, когда правила записи контроля
доступа будут применены. По умолчанию ACE применяется
сразу и всегда.";
choice schedule-type {
description
"Выбор по типу диапазона времени.";
container period {
description
"ACE применяется в точный период времени.";
uses schedule:period-of-time;
}
container recurrence {
if-feature "schedule:icalendar-recurrence";
description
"ACE применяется рекуррентно.";
uses schedule:icalendar-recurrence;
}
}
}
}
}
<CODE ENDS>
6. Атрибут RADIUS User-Access-Group-ID
В этом разделе задан атрибут RADIUS User-Access-Group-ID, предназначенный для сценариев управления доступом на уровне пользователей и служащий для указания идентификатора группы, который будет использоваться NAS. Для других типов групп конечных точек, таких как группы устройств и приложений, идентификаторы обычно предоставляет контроллер SDN на основе инвентаризации или реестра приложений. Определение атрибута следует рекомендациям параграфа 2.7.1 в [RFC6929]. При наличии атрибута User-Access-Group-ID в RADIUS Access-Accept система применяет соответствующие правила управления доступом пользователя после аутентификации того. Атрибут User-Access-Group-ID имеет тип string, как указано в параграфе 3.5 [RFC8044].
Атрибут User-Access-Group-ID может включаться в пакет RADIUS Access-Accept, а также может указываться в пакете RADIUS Access-Request как совет серверу RADIUS в части предпочтения (сервер не обязан следовать предпочтению). Наличие в пакете RADIUS Access-Accept нескольких экземпляров атрибута User-Access-Group-ID говорит о принадлежности пользователя к нескольким группам.
Атрибут User-Access-Group-ID можно включать в пакет RADIUS CoA-Request, а также в пакет RADIUS Accounting-Request. В частности, его может использовать NAS для подтверждения получения атрибута в RADIUS Access-Accept и применения правил сервером NAS. Атрибут User-Access-Group-ID недопустимо включать в другие пакеты RADIUS.
Структура атрибута RADIUS User-Access-Group-ID показана ниже.
Type
241.12
Length
Общий размер (в октетах) всех полей атрибута, включая Type, Length, Extended-Type и Value. Значение поля Length должно быть не менее 4 и недопустимы значения больше 67. Максимум в 67 октетов задан с учётом максимального размера идентификатора группы (64 октета) и размеров полей Type, Length, Extended-Type.
Data Type
Тип данных — string (параграф 3.5 в [RFC8044]).
Value
Идентификатор группы пользователей ID.
7. Таблица атрибутов RADIUS
В таблице 4 указано, какие пакеты RADIUS могут включать атрибут User-Access-Group-ID и в каком количестве.
Таблица 4. Атрибуты.
|
Access-Request |
Access-Accept |
Access-Reject |
Access-Challenge |
Атрибут |
|---|---|---|---|---|
|
0+ |
0+ |
0 |
0 |
User-Access-Group-ID |
|
Accounting-Request |
CoA-Request |
CoA-ACK |
CoA-NACK |
Атрибут |
|
0+ |
0+ |
0 |
0 |
User-Access-Group-ID |
0
Атрибут недопустимо включать в пакет.
0+
Можно включать в пакет один или несколько экземпляров атрибута.
8. Эксплуатационные соображения
8.1. Варианты внедрения
Модель данных UCL можно реализовать разными способами. В некоторых случаях модель реализуется на уровне сетевого (административного) домена, где контроллер SDN поддерживает динамическое сопоставление идентификаторов групп с полями IP/транспорта (например, 5-tuple) и программирует в PEP списки ACL по адресам IP и кортежам 5-tuple. В таких случаях от PEP не требуется реализация (в том числе аппаратная) специальной логики по сравнению с традиционными ACL.
Модель данных UCL может быть реализована и на уровне устройства. Хотя это избавляет от необходимости частого взаимодействия контроллера SDN с PEP, в таких случаях, как изменение контекста подключения пользователя к сети или переноса VM/приложения, узлам PEP может потребоваться специальная аппаратная/программная поддержка для понимания идентификаторов групп конечных точек. В ситуациях, где NAS выступает в качестве PEP, получающего идентификатор группы конечных точек отправителя и/или получателя от сервера AAA, применение правил ACL на основе идентификаторов групп без инкапсуляции в заголовки пакетов может влиять на производительность пересылки. При внедрении следует внимательно учитывать операционные компромиссы (гибкость сети и сложность внедрения). Такие оценки выходят за рамки документа.
8.2. Влияние на программы и оборудования
У некоторых устройств может не быть встроенных возможностей применения правил на основе сопоставления групп. Для поддержки этого узлами PEP может потребоваться обновление программ или оборудования.
8.3. Согласованность сопоставлений
Эта спецификация требует настройки для сопоставления идентификаторов групп с полями пакетов, обычно поддерживаемого контроллером. Особое внимание следует уделять надлежащему использованию таких сопоставлений при поддержке в сети различных механизмов (RADIUS и т. п.).
9. Вопросы безопасности
9.1. YANG
Этот раздел создан по образцу из параграфа 3.7.1 в [RFC9907].
Модуль YANG ietf-ucl-acl задаёт модель данных, доступ к которой осуществляется с помощью протоколов управления на основе YANG, таких как протокол настройки сети (Network Configuration Protocol или NETCONF) [RFC6241] и RESTCONF [RFC8040]. Эти протоколы управления используют (1) защищённый транспорт (например Secure Shell (SSH) [RFC4252], TLS [RFC9846], QUIC [RFC9000]) и (2) взаимную аутентификацию.
Модель доступа к конфигурации сети (NACM — Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.
В заданном здесь модуле определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.
/acl:acls/ucl:endpoint-groups/ucl:endpoint-group
Этот список содержит все записи групп конечных точек. Несанкционированная запись в список может позволить злоумышленнику создать фальшивую группу или удалить имеющуюся, что может послужить организации атак.
/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/ucl:endpoint-group
Эта ветвь задаёт идентификаторы групп конечных точек (отправители и получатели) в качестве критериев соответствия в ACE. Несанкционированная запись может позволить злоумышленнику изменить идентификаторы групп для получения несанкционированного доступа или запрета легитимного.
/acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule:
Задаёт расписание для ACL. Несанкционированная запись может позволить злоумышленнику менять расписание, что может приводить к нарушению или недоступности обслуживания. Для операций записи в этой ветви требуется строгий контроль, чтобы менять содержимое могли только уполномоченные пользователи.
Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). В частности уязвимыми или конфиденциальными могут быть указанные ниже ветви и узлы данных.
/acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule
Указывает, когда применяются правила управления доступом. Несанкционирование чтение этих сведений может позволить злоумышленнику узнать, какие правила применяются, чтобы лучше организовать атаку.
Этот модуль YANG использует группировки из других модулей, определяющие узлы, которые могут уязвимыми или конфиденциальными в некоторых сетевых средах. В разделе «Вопросы безопасности» [RFC9922] сказано, какие узлы могут быть уязвимыми или конфиденциальными в сетевых средах.
9.2. RADIUS
Связанные с RADIUS вопросы безопасности рассмотрены в [RFC2865], а в [RADIUS-DEPRECATE] описана попытка отказа от небезопасных методов в RADIUS.
Этот документ нацелен на системы с доверительными отношениями между клиентами и серверами RADIUS с возможной защитой взаимодействий между ними на основе IPsec или TLS (Transport Layer Security) [RFC6614] [RadSec].
10. Взаимодействие с IANA
10.1. YANG
Агентство IANA выделило в реестре ns группы IETF XML Registry [RFC3688] приведённый ниже идентификатор URI.
URI: urn:ietf:params:xml:ns:yang:ietf-ucl-acl Registrant Contact: The IESG XML: N/A; URI является пространством имён XML.
Агентство IANA зарегистрировало в реестре YANG Module Names [RFC6020] группы YANG Parameters указанный ниже модуль YANG.
Name: ietf-ucl-acl Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-ucl-acl Prefix: ucl Reference: RFC 10065
10.2. RADIUS
Агентство IANA выделило в реестре ns указанный в таблице 5 тип атрибута в реестре RADIUS Attribute Types группы RADIUS Types [RADIUS-Types].
Таблица 5. Атрибут RADIUS.
|
Значение |
Описание |
Тип данных |
Документ |
|---|---|---|---|
|
241.12 |
User-Access-Group-ID |
string |
RFC 10065 |
11. Литература
11.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>.
[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>.
[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>.
[RFC6929] DeKok, A. and A. Lior, «Remote Authentication Dial In User Service (RADIUS) Protocol Extensions», RFC 6929, DOI 10.17487/RFC6929, April 2013, <https://www.rfc-editor.org/info/rfc6929>.
[RFC8044] DeKok, A., «Data Types in RADIUS», RFC 8044, DOI 10.17487/RFC8044, January 2017, <https://www.rfc-editor.org/info/rfc8044>.
[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, «YANG Data Model for Network Access Control Lists (ACLs)», RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.
[RFC9922] Ma, Q., Ed., Wu, Q., Boucadair, M., Ed., and D. King, «A Common YANG Data Model for Scheduling», RFC 9922, DOI 10.17487/RFC9922, March 2026, <https://www.rfc-editor.org/info/rfc9922>.
11.2. Дополнительная литература
[ID-MAPPING] Li, Y., Shen, L., and Y. Zhou, «Autonomic IP Address To Access Control Group ID Mapping», Work in Progress, Internet-Draft, draft-yizhou-anima-ip-to-access-control-groups-02, 15 November 2021, <https://datatracker.ietf.org/doc/html/draft-yizhou-anima-ip-to-access-control-groups-02>.
[RADIUS-DEPRECATE] DeKok, A., «Deprecating Insecure Practices in RADIUS», Work in Progress, Internet-Draft, draft-ietf-radext-deprecating-radius-10, 3 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-10>.
[RADIUS-Types] IANA, «RADIUS Types», <https://www.iana.org/assignments/radius-types>.
[RadSec] Rieckers, J., Cullen, M., Ed., and S. Winter, «RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», Work in Progress, Internet-Draft, draft-ietf-radext-radiusdtls-bis-18, 30 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-radext-radiusdtls-bis-18>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, «A Framework for Policy-based Admission Control», RFC 2753, DOI 10.17487/RFC2753, January 2000, <https://www.rfc-editor.org/info/rfc2753>.
[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>.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, «Terminology for Policy-Based Management», RFC 3198, DOI 10.17487/RFC3198, November 2001, <https://www.rfc-editor.org/info/rfc3198>.
[RFC3539] Aboba, B. and J. Wood, «Authentication, Authorization and Accounting (AAA) Transport Profile», RFC 3539, DOI 10.17487/RFC3539, June 2003, <https://www.rfc-editor.org/info/rfc3539>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Authentication Protocol», RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[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>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, «Transport Layer Security (TLS) Encryption for RADIUS», RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.
[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>.
[RFC7542] DeKok, A., «The Network Access Identifier», RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[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>.
[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>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6», RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9638] Boutros, S. and D. Eastlake 3rd, Ed., «Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations», RFC 9638, DOI 10.17487/RFC9638, September 2024, <https://www.rfc-editor.org/info/rfc9638>.
[RFC9797] Henry, J. and Y. Lee, «Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases», RFC 9797, DOI 10.17487/RFC9797, June 2025, <https://www.rfc-editor.org/info/rfc9797>.
[RFC9846] Rescorla, E., «The Transport Layer Security (TLS) Protocol Version 1.3», RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/info/rfc9846>.
[RFC9899] Gonzalez de Dios, O., Barguil, S., Boucadair, M., and Q. Wu, «Extensions to the YANG Data Model for Access Control Lists (ACLs)», RFC 9899, DOI 10.17487/RFC9899, December 2025, <https://www.rfc-editor.org/info/rfc9899>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[SECURITY-POLICY] You, J., Zarny, M., Jacquenet, C., Boucadair, M., Li, Y., Strassner, J., and S. Majee, «User-group-based Security Policy for Service Layer», Work in Progress, Internet-Draft, draft-you-i2nsf-user-group-based-policy-02, 8 July 2016, <https://datatracker.ietf.org/doc/html/draft-you-i2nsf-user-group-based-policy-02>.
[VXLAN] Smith, M. and L. Kreeger, «VXLAN Group Policy Option», Work in Progress, Internet-Draft, draft-smith-vxlan-group-policy-05, 22 October 2018, <https://datatracker.ietf.org/doc/html/draft-smith-vxlan-group-policy-05>.
Приложение A. Примеры использования
A.1. Настройка контроллера, использующего ACL для групп
Рассмотрим организацию, которой нужно управлять доступом сотрудников отдела исследований и разработки (R&D) к рабочему место с их личных устройств (BYOD). Требования к доступу приведены ниже.
-
Разрешать трафик с личных устройств сотрудников R&D на корпоративные устройства сотрудников R&D в рабочие дни с 8:00:00 до 18:00:00 UTC, начиная с 1 января 2026 г.
-
Запрещать трафик с личных устройств сотрудников R&D на финансовые серверы в корпоративном ЦОД, начиная с 8:30:00 20 января 2026 г. с учётом часового пояса -08:00 (Pacific Standard Time) и заканчивая в 18:00:00 31 декабря 2026 г. в том же часовом поясе.
На рисунке 3 представлен пример конфигурации контроллера SDN с использованием ACL по группам.
{
"ietf-access-control-list:acls": {
"ietf-ucl-acl:endpoint-groups": {
"endpoint-group": [
{
"group-id": "R&D",
"group-type": "ietf-ucl-acl:user-group"
},
{
"group-id": "R&D BYOD",
"group-type": "ietf-ucl-acl:user-group"
},
{
"group-id": "finance server",
"group-type": "ietf-ucl-acl:device-group"
}
]
},
"acl": [
{
"name": "sample-group-acl",
"type": "ietf-ucl-acl:group-acl-type",
"aces": {
"ace": [
{
"name": "rule1",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD",
"destination-group-id": "R&D"
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
},
"ietf-ucl-acl:effective-schedule": {
"recurrence": {
"recurrence-first": {
"start-time": "2026-01-01T08:00:00Z",
"duration": "PT10:00:00"
},
"frequency": "ietf-schedule:daily",
"byday": [
{
"weekday": "monday"
},
{
"weekday": "tuesday"
},
{
"weekday": "wednesday"
},
{
"weekday": "thursday"
},
{
"weekday": "friday"
}
]
}
}
},
{
"name": "rule2",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD",
"destination-group-id": "finance server"
}
},
"actions": {
"forwarding": "ietf-access-control-list:reject"
},
"ietf-ucl-acl:effective-schedule": {
"period": {
"period-start": "2026-01-20T08:30:00-08:00",
"period-end": "2026-12-31T18:00:00-08:00"
}
}
}
]
}
}
]
}
}
Рисунок 3. Пример конфигурации UCL в контроллере SDN.
A.2. Конфигурация PEP с ACL по группам
В этом параграфе приведён пример конфигурации PEP с использованием ACL по группам.
Узел PEP, применяющий ACL для группы, может получать идентификатор группы от сервера AAA при работе в качестве NAS, проверяющего подлинность исходной и целевой конечной точки. В другом варианте PEP, применяющий ACL по группам, может получать идентификатор группы напрямую от исходной конечной точки в поле пакета [VXLAN].
Предположим, что сопоставление идентификатора группы устройств с адресом IP задано заранее или получено в результате аутентификации устройства. На рисунке 4 показана конфигурация ACL, полученная PEP от контроллера. Этот пример соответствует примеру из Приложения A.1.
Примеры этого параграфа не являются исчерпывающими. В частности, адреса IP (destination-ipv4-network и destination-ipv6-network) приведены лишь для одного правила, чтобы продемонстрировать, как сопоставления идентификатора группы с адресом IP преобразуется в запись правила ACL.
{
"ietf-access-control-list:acls": {
"ietf-ucl-acl:endpoint-groups": {
"endpoint-group": [
{
"group-id": "R&D",
"group-type": "ietf-ucl-acl:user-group"
},
{
"group-id": "R&D BYOD",
"group-type": "ietf-ucl-acl:user-group"
}
]
},
"acl": [
{
"name": "sample-ucl-ipv4",
"type": "ietf-ucl-acl:mixed-ipv4-group-type",
"aces": {
"ace": [
{
"name": "rule1",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD",
"destination-group-id": "R&D"
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
},
"ietf-ucl-acl:effective-schedule": {
"recurrence": {
"recurrence-first": {
"start-time": "2026-01-01T08:00:00Z",
"duration": "PT10:00:00"
},
"frequency": "ietf-schedule:daily",
"byday": [
{
"weekday": "monday"
},
{
"weekday": "tuesday"
},
{
"weekday": "wednesday"
},
{
"weekday": "thursday"
},
{
"weekday": "friday"
}
]
}
}
},
{
"name": "rule2",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD"
},
"ipv4": {
"destination-ipv4-network": "203.0.113.1/24"
}
},
"actions": {
"forwarding": "ietf-access-control-list:reject"
},
"ietf-ucl-acl:effective-schedule": {
"period": {
"period-start": "2026-01-20T08:30:00-08:00",
"period-end": "2026-12-31T18:00:00-08:00"
}
}
}
]
}
}
]
}
}
Рисунок 4. Пример конфигурации PEP с использованием ACL по группам.
На рисунке 5 представлен пример той же политики с префиксами IPv6.
{
"ietf-access-control-list:acls": {
"ietf-ucl-acl:endpoint-groups": {
"endpoint-group": [
{
"group-id": "R&D",
"group-type": "ietf-ucl-acl:user-group"
},
{
"group-id": "R&D BYOD",
"group-type": "ietf-ucl-acl:user-group"
}
]
},
"acl": [
{
"name": "sample-ucl-ipv6",
"type": "ietf-ucl-acl:mixed-ipv6-group-type",
"aces": {
"ace": [
{
"name": "rule1",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD",
"destination-group-id": "R&D"
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
},
"ietf-ucl-acl:effective-schedule": {
"recurrence": {
"recurrence-first": {
"start-time": "2026-01-01T08:00:00Z",
"duration": "PT10:00:00"
},
"frequency": "ietf-schedule:daily",
"byday": [
{
"weekday": "monday"
},
{
"weekday": "tuesday"
},
{
"weekday": "wednesday"
},
{
"weekday": "thursday"
},
{
"weekday": "friday"
}
]
}
}
},
{
"name": "rule2",
"matches": {
"ietf-ucl-acl:endpoint-group": {
"source-group-id": "R&D BYOD"
},
"ipv6": {
"destination-ipv6-network": "2001:db8:1234::/64"
}
},
"actions": {
"forwarding": "ietf-access-control-list:reject"
},
"ietf-ucl-acl:effective-schedule": {
"period": {
"period-start": "2026-01-20T08:30:00-08:00",
"period-end": "2026-12-31T18:00:00-08:00"
}
}
}
]
}
}
]
}
}
Рисунок 5. Пример конфигурации PEP с использованием ACL по группам (IPv6).
A.3. Конфигурация PEP с ACL на основе адресов
В этом параграфе рассмотрен пример конфигурации PEP с использованием ACL по адресам IP. Правила доступа могут применяться в узле PEP, который не понимает информации о группе (например, МСЭ).
Предположим, что сотрудник департамента R&D подключается через беспроводную сеть, используя не принадлежащий компании ноутбук. Контроллер SDN связывает группу, к которой относится сотрудник, с адресом пользователя в соответствии с этапами 1 — 4 из параграфа 4.1. Пусть сопоставление идентификатора группы устройств с адресом IP задано заранее или получено при проверке подлинности устройства. На рисунке 6 показана конфигурация ACL по адресам IPv4, передаваемая PEP от контроллера. Пример соответствует примеру из Приложения A.1.
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "sample-acl-ipv4",
"type": "ietf-access-control-list:ipv4-acl-type",
"aces": {
"ace": [
{
"name": "rule1",
"matches": {
"ipv4": {
"destination-ipv4-network": "192.168.2.1/24",
"source-ipv4-network": "192.168.1.1/24"
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
},
"ietf-ucl-acl:effective-schedule": {
"recurrence": {
"recurrence-first": {
"start-time": "2026-01-01T08:00:00Z",
"duration": "PT10:00:00"
},
"frequency": "ietf-schedule:daily",
"byday": [
{
"weekday": "monday"
},
{
"weekday": "tuesday"
},
{
"weekday": "wednesday"
},
{
"weekday": "thursday"
},
{
"weekday": "friday"
}
]
}
}
},
{
"name": "rule2",
"matches": {
"ipv4": {
"destination-ipv4-network": "203.0.113.1/24",
"source-ipv4-network": "192.168.1.1/24"
}
},
"actions": {
"forwarding": "ietf-access-control-list:reject"
},
"ietf-ucl-acl:effective-schedule": {
"period": {
"period-start": "2026-01-20T08:30:00-08:00",
"period-end": "2026-12-31T18:00:00-08:00"
}
}
}
]
}
}
]
}
}
Рисунок 6. Пример конфигурации PEP с ACL по адресам.
На рисунке 7 представлен пример той же политики с префиксами IPv6.
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "sample-acl-ipv6",
"type": "ietf-access-control-list:ipv6-acl-type",
"aces": {
"ace": [
{
"name": "rule1",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:0:2::/64",
"source-ipv6-network": "2001:db8:0:1::/64"
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
},
"ietf-ucl-acl:effective-schedule": {
"recurrence": {
"recurrence-first": {
"start-time": "2026-01-01T08:00:00Z",
"duration": "PT10:00:00"
},
"frequency": "ietf-schedule:daily",
"byday": [
{
"weekday": "monday"
},
{
"weekday": "tuesday"
},
{
"weekday": "wednesday"
},
{
"weekday": "thursday"
},
{
"weekday": "friday"
}
]
}
}
},
{
"name": "rule2",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:1234::/64",
"source-ipv6-network": "2001:db8:0:1::/64"
}
},
"actions": {
"forwarding": "ietf-access-control-list:reject"
},
"ietf-ucl-acl:effective-schedule": {
"period": {
"period-start": "2026-01-20T08:30:00-08:00",
"period-end": "2026-12-31T18:00:00-08:00"
}
}
}
]
}
}
]
}
}
Рисунок 7. Пример конфигурации PEP с ACL по адресам (IPv6).
Благодарности
Данная работа много получила от длительных обсуждений правил безопасности на основе групп пользователей. В частности, [SECURITY-POLICY] и [ID-MAPPING] предоставляют механизмы сопоставления адресов и префиксов IP у пользователей с идентфикаторами групп контроля доступа. Авторы благодарны Jianjie You, Myo Zarny, Christian Jacquenet, Yizhou Li за вклад в работу.
Спасибо Joe Clarke, Bill Fenner, Benoît Claise, Rob Wilton, David Somers-Harris, Alan DeKok, Heikki Vatiainen, Wen Xiang, Wei Wang, Hongwei Li, Jensen Zhang за их рецензии и комментарии.
Спасибо Dhruv Dhody за рецензию OPSDIR, Alexander Pelov за рецензию INTDIR, Valery Smyslov за рецензию SECDIR и Acee Lindem за рецензию YANGDOCTORS. Спасибо Mahesh Jethanandani за рецензию AD. Спасибо Christopher Inacio, Andy Newton, Charles Eckel, Éric Vyncke, Deb Cooley, Gorry Fairhurst, Gunter Van de Velde, Jim Guichard, Ketan Talaulikar, Mike Bishop за рецензии IESG.
Адреса авторов
Qiufang Ma (editor)
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: maqiufang1@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: bill.wu@huawei.com
Mohamed Boucadair (editor)
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Daniel King
Lancaster University
United Kingdom
Email: d.king@lancaster.ac.uk
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.
3Virtual Private Network — виртуальная частная сеть.
4Bring Your Own Device — использование своего устройства.
5Media Access Control — управление доступом к среде.
6Internet of Things — интернет вещей.
7Software-Defined Networking — программно-определяемая сеть.
8Network Virtualization over Layer 3 — сетевая виртуализация через уровень L3.