[要約] ユーザグループなどのグループ識別子に基づいてネットワークアクセス制御を行うため、RFC 8519 のアクセス制御リスト (ACL) を拡張するYANGデータモデルを定義します。日時パラメータを追加し、時間帯に応じたポリシー適用にも対応します。ユーザ認証を契機にネットワークアクセスが許可される場面で、グループ識別子とパケットヘッダのフィールドとの対応付けを管理しやすくする仕組みを示します。あわせて、グループ識別子を認証・認可情報の一部として伝えるRADIUS属性 User-Access-Group-ID を定義します。
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
This document defines a YANG data model for policy-based network access control, which enables enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement.
本書は、グループアイデンティティに基づくネットワークアクセス制御ポリシーの実施を可能にする、ポリシーベースのネットワークアクセス制御のためのYANGデータモデルを定義します。このYANGデータモデルは、アクセス制御リスト (ACL) を日付と時刻のパラメータで拡張し、スケジュール対応のポリシー実施をサポートします。
Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism that eases the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, this document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information.
特に、ネットワークアクセスがユーザ認証によってトリガされるシナリオにおいて、本書は、ポリシーベースのネットワークアクセス制御を実施するための、ユーザグループ識別子とパケットヘッダフィールドの集合との対応付けの維持を容易にするメカニズムを定義します。さらに本書は、識別情報および認可情報の一部としてユーザグループ識別子を伝達するために使用される、Remote Authentication Dial-in User Service (RADIUS) 属性を定義します。
This is an Internet Standards Track document.
本書はInternet Standards Trackの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本書はInternet Engineering Task Force (IETF) の成果物です。IETFコミュニティのコンセンサスを表しています。本書は公開レビューを受け、Internet Engineering Steering Group (IESG) により発行が承認されました。Internet Standardsの詳細については、RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10065.
本書の現在の状況、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10065 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権 (c) 2026 IETF Trustおよび本書の著者として特定された者。All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
本書は、本書の発行日時点で有効なBCP 78およびIETF Trustの IETF文書に関する法的規定 (https://trustee.ietf.org/license-info) の適用を受けます。これらの文書は本書に関するあなたの権利と制限を記述しているため、注意深くレビューしてください。本書から抽出されるコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているとおりRevised BSD Licenseのテキストを含める必要があり、Revised BSD Licenseに記載されているとおり無保証で提供されます。
1. Introduction 2. Conventions and Definitions 3. Sample Usage 4. Policy-Based Network Access Control 4.1. Overview 4.2. Endpoint Group 4.2.1. User Group 4.2.2. Device Group 4.2.3. Application Group 4.3. Relations Between Different Endpoint Groups 5. The UCL Extension to the ACL Module 5.1. Module Overview 5.2. The "ietf-ucl-acl" YANG Module 6. User-Access-Group-ID RADIUS Attribute 7. Table of RADIUS Attributes 8. Operational Considerations 8.1. Deployment Options 8.2. Hardware/Software Implications 8.3. Mapping Consistency 9. Security Considerations 9.1. YANG 9.2. RADIUS 10. IANA Considerations 10.1. YANG 10.2. RADIUS 11. References 11.1. Normative References 11.2. Informative References Appendix A. Usage Examples A.1. Configuring the Controller Using the Group-Based ACL A.2. Configuring a PEP Using the Group-Based ACL A.3. Configuring a PEP Using an Address-Based ACL Acknowledgments Authors' Addresses
With the increased adoption of remote access technologies (e.g., Virtual Private Networks (VPNs) and Bring Your Own Device (BYOD) policies), enterprises adopted more flexibility related to how, where, and when employees work and collaborate. However, more flexibility comes with increased risks. Enabling office flexibility (e.g., mobility across many access locations) introduces a set of challenges for large-scale enterprises compared to conventional network access management approaches. Examples of such challenges are listed below:
リモートアクセス技術 (例: Virtual Private Networks (VPNs) や Bring Your Own Device (BYOD) ポリシー) の採用が増えたことで、企業は従業員がどのように、どこで、いつ働き、協働するかについて、より高い柔軟性を取り入れるようになりました。しかし、柔軟性が高まればリスクも増大します。オフィスの柔軟性を実現すること (例: 多数のアクセス拠点にまたがるモビリティ) は、従来のネットワークアクセス管理の手法と比べて、大規模企業にいくつもの課題をもたらします。そのような課題の例を以下に挙げます。
* Endpoints do not have stable and unique IP addresses. For example, Wireless LAN (WLAN) and VPN clients, as well as back-end servers based on Virtual Machines (VMs), can move; their IP addresses could change as a result. Furthermore, mechanisms such as IPv6 temporary addresses [RFC8981] and Network Address Port Translation (NAPT) [RFC3022] may further contribute to address instability and non-uniqueness. This complicates the consistent and efficient access control policy enforcement relying on IP/ transport fields (e.g., the 5-tuple). IP-address-based policies may not be flexible enough to accommodate endpoints with volatile IP addresses.
* エンドポイントは、安定した一意のIPアドレスを持ちません。たとえば、Wireless LAN (WLAN) やVPNのクライアント、およびVirtual Machines (VMs) に基づくバックエンドサーバは移動することがあり、その結果IPアドレスが変わる可能性があります。さらに、IPv6一時アドレス [RFC8981] やNetwork Address Port Translation (NAPT) [RFC3022] などのメカニズムも、アドレスの不安定性や非一意性を助長するおそれがあります。このため、IP/トランスポートのフィールド (例: 5-tuple) に依存する、一貫して効率的なアクセス制御ポリシーの実施が複雑になります。IPアドレスに基づくポリシーでは、IPアドレスが変動するエンドポイントに対応できるほど柔軟でない場合があります。
* With the massive adoption of teleworking, there is a need to apply different security policies to the same set of endpoints under different circumstances (e.g., prevent relay attacks against a local attachment point to the enterprise network). For example, network access might be granted based upon criteria such as a user's access location, source network reputation, a user's role, the time of day, the type of network device used (e.g., corporate-issued device versus personal device), a device's security posture, etc. This means that the network needs to recognize the endpoints' identities and their current contexts and map the endpoints to their correct access grants to the network.
* テレワークが大規模に採用されたことで、同じエンドポイントの集合に対して、状況に応じて異なるセキュリティポリシーを適用する必要が生じています (例: 企業ネットワークのローカルな接続ポイントに対するリレー攻撃の防止)。たとえば、ネットワークアクセスは、ユーザのアクセス場所、送信元ネットワークのレピュテーション、ユーザのロール、時間帯、使用されるネットワークデバイスの種類 (例: 会社支給デバイスと個人デバイス)、デバイスのセキュリティ態勢などの基準に基づいて許可される場合があります。これは、ネットワークがエンドポイントのアイデンティティと現在のコンテキストを認識し、エンドポイントを正しいネットワークアクセス権限に対応付ける必要があることを意味します。
This document defines a YANG data model (Section 5.2) for policy-based network access control, which extends the IETF Access Control Lists (ACLs) module defined in [RFC8519]. This module can be used to ensure consistent enforcement of ACL policies based on the group identity. Additionally, the YANG data model defined in the document also extends ACLs with date and time parameters to support schedule-aware policy enforcement.
本書は、[RFC8519] で定義されているIETF Access Control Lists (ACLs) モジュールを拡張する、ポリシーベースのネットワークアクセス制御のためのYANGデータモデル (セクション5.2) を定義します。このモジュールは、グループアイデンティティに基づくACLポリシーの一貫した実施を確保するために使用できます。さらに、本書で定義するYANGデータモデルは、ACLを日付と時刻のパラメータで拡張し、スケジュール対応のポリシー実施をサポートします。
The ACL concept has been generalized to be device-nonspecific, and it can be defined at the network/administrative domain level [RFC9899]. To allow for all ACL applications, the YANG module for policy-based network ACL defined in Section 5.2 does not limit how it can be used.
ACLの概念は、特定のデバイスに依存しないものへと一般化されており、ネットワーク/管理ドメインのレベルで定義できます [RFC9899]。あらゆるACLの用途に対応できるよう、セクション5.2で定義するポリシーベースのネットワークACL用YANGモジュールは、その使用方法を制限しません。
Specifically in scenarios where network access is triggered by user authentication, this document also defines a mechanism to establish a mapping between (1) the user group identifier (ID) and (2) common IP packet header fields and other encapsulating packet data (e.g., a Media Access Control (MAC) address) to execute the policy-based access control. Additionally, the document defines a Remote Authentication Dial-in User Service (RADIUS) [RFC2865] attribute that is used to communicate the user group identifier as part of identification and authorization information (Section 6).
特に、ネットワークアクセスがユーザ認証によってトリガされるシナリオにおいて、本書はさらに、ポリシーベースのアクセス制御を実行するために、(1) ユーザグループ識別子 (ID) と (2) 共通のIPパケットヘッダフィールドおよびその他のカプセル化パケットデータ (例: Media Access Control (MAC) アドレス) との対応付けを確立するメカニズムを定義します。加えて本書は、識別情報および認可情報の一部としてユーザグループ識別子を伝達するために使用される、Remote Authentication Dial-in User Service (RADIUS) [RFC2865] 属性を定義します (セクション6)。
Although this document cites MAC addresses as an example in some sections, this document does not make assumptions about which identifiers are used to trigger ACLs. These examples should not be considered as recommendations. Readers should be aware that MAC-based ACLs can be bypassed by clearing the MAC address. Other implications related to the change of MAC addresses are discussed in [RFC9797].
本書は一部のセクションで例としてMACアドレスを挙げていますが、ACLをトリガするためにどの識別子が使用されるかについて、何も前提としていません。これらの例は推奨事項とみなされるべきではありません。MACアドレスに基づくACLは、MACアドレスを消去することで回避できることに、読者は留意してください。MACアドレスの変更に関するその他の影響については、[RFC9797] で議論されています。
This document does not specify how to map the policy group identifiers to dedicated packet fields. Group-Based Policy (GBP), discussed in Section 6.2.3 of [RFC9638], provides an example of how that may be achieved.
本書は、ポリシーグループ識別子を専用のパケットフィールドに対応付ける方法を規定しません。[RFC9638] のセクション6.2.3で議論されているGroup-Based Policy (GBP) は、それを実現する方法の一例を示しています。
The meanings of the symbols in tree diagrams are defined in [RFC8340].
ツリー図における記号の意味は、[RFC8340] で定義されています。
* Access Control Entry (ACE)
* アクセス制御エントリ (ACE)
* Access Control List (ACL)
* アクセス制御リスト (ACL)
The following definitions are used throughout this document:
本書全体で、以下の定義を使用します。
Enterprise device:
エンタープライズデバイス:
A device that falls under the access control domain of a centrally managed authority (enterprise administrator, typically). An enterprise device provides compute, memory, storage, and networking capabilities and connects to a network.
一元管理される権限者 (通常は企業の管理者) のアクセス制御ドメインに属するデバイスです。エンタープライズデバイスは、計算、メモリ、ストレージ、ネットワーキングの各機能を提供し、ネットワークに接続します。
An enterprise device could be a server that hosts applications or software that delivers services to enterprise users. It could also be an enterprise Internet of Things (IoT) device that serves a limited purpose (e.g., a printer that allows users to scan and print).
エンタープライズデバイスは、企業ユーザにサービスを提供するアプリケーションやソフトウェアをホストするサーバである場合があります。また、限られた目的に使われる企業のInternet of Things (IoT) デバイス (例: ユーザがスキャンや印刷を行えるプリンタ) である場合もあります。
While a personal device (BYOD) is not a physical asset of the enterprise, it is subject to the enterprise's access control policies when accessing the enterprise resources controlled by the centrally managed authority.
個人デバイス (BYOD) は企業の物理的な資産ではありませんが、一元管理される権限者が管理する企業リソースにアクセスする際には、企業のアクセス制御ポリシーの適用を受けます。
Endpoint:
エンドポイント:
An entity that could be an end user, enterprise device, or application that actually connects to a network.
実際にネットワークに接続する、エンドユーザ、エンタープライズデバイス、またはアプリケーションとなりうるエンティティです。
Endpoint group:
エンドポイントグループ:
A group of endpoints that share common access control policies.
共通のアクセス制御ポリシーを共有するエンドポイントのグループです。
User group:
ユーザグループ:
A group of end users who will be assigned the same network access policy. An end user is defined as a person. Refer to Section 4.2.1 for more details.
同じネットワークアクセスポリシーが割り当てられるエンドユーザのグループです。エンドユーザとは人を指します。詳細はセクション4.2.1を参照してください。
Device group:
デバイスグループ:
A collection of enterprise devices that share common access control policies. Refer to Section 4.2.2 for more details.
共通のアクセス制御ポリシーを共有するエンタープライズデバイスの集合です。詳細はセクション4.2.2を参照してください。
Application group:
アプリケーショングループ：
A collection of applications that share common access control policies. An application is a software program used for a specific service. Refer to Section 4.2.3 for more details.
共通のアクセス制御ポリシーを共有するアプリケーションの集合です。アプリケーションとは、特定のサービスに使用されるソフトウェアプログラムです。詳細については、セクション 4.2.3 を参照してください。
Endpoint group identifier:
エンドポイントグループ識別子：
An identifier used to represent the collective identity of an endpoint group. An endpoint group may include a user group, device group, or application group.
エンドポイントグループの集合的なアイデンティティを表すために使用される識別子です。エンドポイントグループには、ユーザグループ、デバイスグループ、またはアプリケーショングループが含まれる場合があります。
User-group-based Control List (UCL) data model:
User-group-based Control List (UCL) データモデル：
A YANG data model for policy-based network access control that specifies an extension to the "ietf-access-control-list" module [RFC8519]. It allows policy enforcement based on a group identifier, which can be used both at the network device level and at the network/ administrative domain level.
ポリシーベースのネットワークアクセス制御のためのYANGデータモデルで、"ietf-access-control-list" モジュール [RFC8519] の拡張を規定します。グループ識別子に基づくポリシー実施を可能にし、これはネットワークデバイスレベルと、ネットワーク/管理ドメインレベルの両方で使用できます。
Policy:
ポリシー：
A set of rules to administer, manage, and control access to network resources [RFC3198].
ネットワークリソースへのアクセスを管理し、制御するための規則の集合です [RFC3198]。
Access to some networks (e.g., enterprise networks) requires recognizing the endpoints' identities no matter how, where, or when they connect to the network resources. Then, the network maps the (connecting) endpoints to their access authorization rights. Such rights are defined using local policies. As discussed in Section 1, because (1) there is a large number of connecting endpoints and (2) an endpoint may have different source IP addresses in different network segments, deploying a network access control policy for each IP address or network segment requires a high overhead. An alternate approach is to configure endpoint groups to classify users, enterprise devices, and applications, and to associate ACLs with endpoint groups so that endpoints in each group can share a group of ACL rules. This approach greatly reduces the overhead of the administrators and optimizes ACL resources.
一部のネットワーク（例：企業ネットワーク）へのアクセスでは、エンドポイントがどのように、どこから、いつネットワークリソースに接続する場合でも、そのアイデンティティを認識する必要があります。次に、ネットワークは（接続中の）エンドポイントを、そのアクセス認可権限に対応付けます。こうした権限はローカルポリシーを用いて定義されます。セクション 1 で述べたとおり、(1) 接続するエンドポイントが多数存在すること、(2) エンドポイントがネットワークセグメントごとに異なる送信元IPアドレスを持ちうることから、IPアドレスやネットワークセグメントごとにネットワークアクセス制御ポリシーを展開すると、高いオーバーヘッドが生じます。代替のアプローチは、ユーザ、エンタープライズデバイス、アプリケーションを分類するためにエンドポイントグループを設定し、各グループ内のエンドポイントがACLルールの集合を共有できるように、ACLをエンドポイントグループに関連付けることです。このアプローチにより、管理者のオーバーヘッドが大幅に削減され、ACLリソースが最適化されます。
Different policies may need to be applied in different contextual situations. For example, companies may restrict (or grant) employees access to specific internal or external resources during work hours, while another policy is adopted during off-hours and weekends. A network administrator may also require traffic shaping (Section 2.3.3.3 of [RFC2475]) and policing (Section 2.3.3.4 of [RFC2475]) during peak hours in order to not affect other data services.
An example architecture of a system that provides real-time and consistent enforcement of access control policies is shown in Figure 1. This architecture illustrates a user-centric flow, which includes the following functional entities and interfaces:
アクセス制御ポリシーのリアルタイムかつ一貫した実施を提供するシステムのアーキテクチャ例を図 1 に示します。このアーキテクチャは、次の機能エンティティとインタフェースを含む、ユーザ中心のフローを示しています。
* A service orchestrator that coordinates the overall service, including security policies. The service may be connectivity or any other access to resources that can be hosted and offered by a network.
* セキュリティポリシーを含むサービス全体を調整するサービスオーケストレータ。サービスは、接続性、またはネットワークがホストして提供できるリソースへのその他のアクセスの場合があります。
* A Software-Defined Networking (SDN) [RFC7149] [RFC7426] controller that is responsible for maintaining endpoint-group-based ACLs and mapping the endpoint group to the associated attributes information (e.g., packet header fields). An SDN controller also behaves as a Policy Decision Point (PDP) [RFC3198] and pushes the required access control policies to relevant Policy Enforcement Points (PEPs) [RFC3198]. A PDP is also known as a "policy server" [RFC2753].
* A NAS entity that handles authentication requests. The NAS interacts with a AAA server to complete user authentication using protocols like RADIUS [RFC2865]. When access is granted, the AAA server provides the group identifier (group ID) to which the user belongs when the user first logs onto the network.
* 認証要求を処理するNASエンティティ。NASは、RADIUS [RFC2865] などのプロトコルを用いてAAAサーバとやり取りし、ユーザ認証を完了します。アクセスが許可されると、ユーザが最初にネットワークにログオンしたときに、AAAサーバはそのユーザが属するグループ識別子 (グループID) を提供します。
A new RADIUS attribute is defined in Section 6 for this purpose.
この目的のために、セクション 6 で新しいRADIUS属性が定義されます。
* The AAA server provides a collection of authentication, authorization, and accounting functions. The AAA server is responsible for centralized user information management. The AAA server is preconfigured with user credentials (e.g., username and password), possible group identities, and related user attributes (users may be divided into different groups based on different user attributes).
* AAAサーバは、認証、認可、アカウンティングの機能群を提供します。AAAサーバは、ユーザ情報の集中管理を担います。AAAサーバには、ユーザの資格情報（例：ユーザ名とパスワード）、取りうるグループアイデンティティ、および関連するユーザ属性があらかじめ設定されています（ユーザは異なるユーザ属性に基づいて異なるグループに分けられる場合があります）。
* A PEP is the central entity that is responsible for enforcing appropriate access control policies. A first deployment scenario assumes that the SDN controller maps the group ID to the related common packet header and delivers ACL policies based on packet header fields to the required PEPs. Another deployment scenario may require that PEPs map incoming packets to their associated source and/or destination endpoint group IDs and act upon the corresponding group-based ACL policies (e.g., a group identifier may be carried in packet headers, as discussed in Section 6.2.3 of [RFC9638]).
* PEPは、適切なアクセス制御ポリシーの実施を担う中心的なエンティティです。第1の展開シナリオでは、SDNコントローラがグループIDを関連する共通のパケットヘッダに対応付け、パケットヘッダフィールドに基づくACLポリシーを必要なPEPに配信することを想定します。別の展開シナリオでは、PEPが着信パケットを、関連する送信元および/または宛先のエンドポイントグループIDに対応付け、対応するグループベースのACLポリシーに従って動作することが求められる場合があります（例：[RFC9638] のセクション 6.2.3 で述べられているように、グループ識別子がパケットヘッダで運ばれる場合があります）。
Multiple PEPs may be involved in a network.
ネットワークには複数のPEPが関与する場合があります。
A PEP exposes a YANG-based interface (e.g., NETCONF [RFC6241]) to an SDN controller.
PEPは、YANGベースのインタフェース（例：NETCONF [RFC6241]）をSDNコントローラに公開します。
Figure 1 provides the overall architecture and procedure for policy-based access control management.
図 1 は、ポリシーベースのアクセス制御管理の全体的なアーキテクチャと手順を示しています。
.------------.
|Orchestrator|
'------+-----'
Service | (Step 1)
------------------------------------------)-------------
Network |
Step 4 |
.-------. .--------. .--------+--------.
|User #1+--+ | AAA | | SDN Controller |
'-------' | | Server +-----+ PDP |
| '----+---' '--------+--------'
| | |
| | +------+--------+ Step 5
Step 2 | | Step 3 | |
| | | |
| .-+-----------+---------------+-------------.
+--------+ |
| .----------------------. .--------------. |
.-------. | | Network Access Server| |Firewall, etc.| |
|User #2+-----------+ | (NAS) | '--------------' |
'-------' | '----------------------' |
| PEP |
'-------------------------------------------'
Figure 1: An Example Architecture for User-Group-Based Policy Management
図 1: ユーザグループベースのポリシー管理のアーキテクチャ例
In reference to Figure 1, the following typical flow is experienced:
図 1 に関して、次のような典型的なフローになります。
Step 1:
ステップ 1：
Administrators (or a service orchestrator) configure an SDN controller with network-level ACLs using the YANG module defined in Section 5.2. An example is provided in Appendix A.1.
管理者（またはサービスオーケストレータ）は、セクション 5.2 で定義されるYANGモジュールを用いて、SDNコントローラにネットワークレベルのACLを設定します。例を付録 A.1 に示します。
Step 2:
ステップ 2：
When a user first logs onto the network, they are required to be authenticated (e.g., using a username and password) at the NAS.
ユーザが最初にネットワークにログオンするとき、NASで（例：ユーザ名とパスワードを用いて）認証される必要があります。
Step 3:
ステップ 3：
The authentication request is then relayed to the AAA server using a protocol such as RADIUS [RFC2865]. It is assumed that the AAA server has been appropriately configured to store user credentials, e.g., username, password, group information, and other user attributes. This document does not restrict what authentication method is used. Administrators may refer to, e.g., Section 7.4 of [RADIUS-DEPRECATE] for authentication method recommendations.
次に、認証要求はRADIUS [RFC2865] などのプロトコルを用いてAAAサーバに中継されます。AAAサーバには、ユーザ名、パスワード、グループ情報、その他のユーザ属性などの、ユーザの資格情報を保存するための適切な設定がなされていると想定します。本書では、どの認証方式を使用するかは制限しません。管理者は、認証方式に関する推奨事項として、例えば [RADIUS-DEPRECATE] のセクション 7.4 を参照してもよいでしょう。
If the authentication request succeeds, the user is placed in a user group with the identifier returned to the NAS as the authentication result (see Section 6). If the authentication fails, the user is not assigned any user group, which also means that the user has no access (i.e., an Access-Reject is returned) or the user is assigned a special group with very limited access permissions for the network (as a function of the local policy). ACLs are enforced so that flows from the user's IP address are discarded (or rate-limited) by the network.
認証要求が成功した場合、ユーザは、識別子を持つユーザグループに配置され、その識別子が認証結果としてNASに返されます（セクション 6 を参照）。認証が失敗した場合、ユーザはどのユーザグループにも割り当てられません。これは、ユーザがアクセスできない（すなわち、Access-Rejectが返される）ことを意味するか、または、（ローカルポリシーに応じて）ネットワークに対するアクセス権限が非常に限定された特別なグループにユーザが割り当てられることを意味します。ACLが実施され、ユーザのIPアドレスからのフローはネットワークによって破棄（またはレート制限）されます。
In some implementations, the AAA server can be integrated with the SDN controller.
実装によっては、AAAサーバをSDNコントローラと統合することができます。
Step 4:
ステップ 4：
Either the AAA server or the NAS notifies the SDN controller of the mapping between the user group ID and related common packet header attributes (e.g., the 5-tuple). The exact details of how such notification is performed are out of scope of this specification.
AAAサーバまたはNASのいずれかが、ユーザグループIDと関連する共通のパケットヘッダ属性（例：5タプル）との対応付けをSDNコントローラに通知します。この通知がどのように行われるかの詳細は、本仕様の範囲外です。
Step 5:
ステップ 5：
Either group-based access control policies or access control policies based on packet header fields are maintained on relevant PEPs under the SDN controller's management. Both types of ACL policy may exist on the PEP. Appendices A.2 and A.3 elaborate on each case.
グループベースのアクセス制御ポリシー、またはパケットヘッダフィールドに基づくアクセス制御ポリシーのいずれかが、SDNコントローラの管理下にある関連PEP上で維持されます。両方の種類のACLポリシーがPEP上に存在してもかまいません。付録 A.2 と A.3 で、それぞれのケースを詳しく説明します。
A similar flow applies to policy management based on other endpoint group types, such as device or application groups, except that the mapping between the group ID and related common packet header attributes (e.g., 5-tuple) may be maintained on the SDN controller based on an inventory or an application registry. Particularly, the use of RADIUS exchanges is not required in such cases (Section 6).
デバイスグループやアプリケーショングループなど、他のエンドポイントグループタイプに基づくポリシー管理にも同様のフローが適用されます。ただし、グループIDと関連する共通のパケットヘッダ属性（例：5タプル）との対応付けは、インベントリまたはアプリケーションレジストリに基づいてSDNコントローラ上で維持される場合があります。特に、このような場合にはRADIUSのやり取りを使用する必要はありません（セクション 6）。
Section 8 provides additional operational considerations.
セクション8では、運用上の追加の考慮事項を示します。
A user group is determined by a set of predefined policy criteria (e.g., source IP address, geolocation data, time of day, or device certificate). It uses an identifier (user group ID) to represent the collective identity of a group of users. Users may be moved to different user groups if there is a change in their composite attributes, environment, and/or local enterprise policy.
ユーザグループは、あらかじめ定義されたポリシー基準（例: 送信元IPアドレス、地理位置データ、時刻、デバイス証明書）の集合によって決定されます。ユーザグループは、ユーザの集まりの集合的なアイデンティティを表す識別子（ユーザグループID）を使用します。ユーザの複合的な属性、環境、および/またはローカルのエンタープライズポリシーに変更があった場合、ユーザは別のユーザグループに移されることがあります。
A user is authenticated, classified at the AAA server, and assigned to a user group. A user's group membership may change as aspects of the user change. For example, if the user group membership is determined solely by the source IP address, then a given user's group ID will change when the user is assigned a new IP address that falls outside of the range of addresses of the previous user group.
ユーザは認証され、AAAサーバで分類され、ユーザグループに割り当てられます。ユーザの側面が変化すると、ユーザのグループメンバーシップも変化することがあります。例えば、ユーザグループのメンバーシップが送信元IPアドレスのみで決定される場合、ユーザに新しいIPアドレスが割り当てられ、そのアドレスが以前のユーザグループのアドレス範囲の外にあるときは、そのユーザのグループIDが変わります。
This document does not make any assumption about how user groups are defined. Such considerations are deployment-specific and are out of scope. However, and for illustration purposes, Table 1 shows an example of how user group definitions may be characterized. User groups may share several common criteria. That is, user group criteria are not mutually exclusive. For example, the policy criteria of the user groups R&D Regular and R&D BYOD may share the same set of users that belong to the R&D organization but differ only in the type of clients (corporate-issued clients vs. users' personal clients). Likewise, the same user may be assigned to different user groups depending on the time of day or the type of day (e.g., weekdays versus weekends), etc.
本ドキュメントは、ユーザグループがどのように定義されるかについて、いかなる前提も置きません。そのような考慮事項は展開ごとに固有であり、対象範囲外です。ただし、説明のために、表1にユーザグループの定義を特徴づける方法の例を示します。ユーザグループは、いくつかの共通の基準を共有することがあります。つまり、ユーザグループの基準は互いに排他的ではありません。例えば、ユーザグループ R&D Regular と R&D BYOD のポリシー基準は、R&D組織に属する同じユーザの集合を共有しつつ、クライアントの種類（会社支給のクライアントと、ユーザ個人のクライアント）のみが異なる場合があります。同様に、同じユーザが、時刻や日の種類（例: 平日と週末）などに応じて、異なるユーザグループに割り当てられることもあります。
+=============+==========+===================================+
| Group Name | Group ID | Group Description |
+=============+==========+===================================+
| R&D Regular | foo-10 | R&D employees |
+-------------+----------+-----------------------------------+
| R&D BYOD | foo-11 | Personal devices of R&D employees |
+-------------+----------+-----------------------------------+
| Sales | foo-20 | Sales employees |
+-------------+----------+-----------------------------------+
| VIP | foo-30 | VIP employees |
+-------------+----------+-----------------------------------+
Table 1: User Group Examples
表1: ユーザグループの例
A device group ID is an identifier that represents the collective identity of a group of enterprise devices. Table 2 shows an example of how device group definitions may be characterized.
デバイスグループIDは、エンタープライズデバイスの集まりの集合的なアイデンティティを表す識別子です。表2にデバイスグループの定義を特徴づける方法の例を示します。
+==================+==========+===========================+
| Group Name | Group ID | Group Description |
+==================+==========+===========================+
| Workflow | bar-40 | Workflow resource servers |
+------------------+----------+---------------------------+
| R&D Resource | bar-50 | R&D resource servers |
+------------------+----------+---------------------------+
| Printer Resource | bar-60 | Printer resources |
+------------------+----------+---------------------------+
Table 2: Device Group Examples
表2: デバイスグループの例
Matching abstract device group IDs instead of specified addresses in ACL policies helps shield the consequences of address changes (e.g., back-end VM-based server migration).
ACLポリシーにおいて、特定のアドレスではなく抽象的なデバイスグループIDを照合することで、アドレス変更（例: バックエンドのVMベースのサーバの移行）による影響を緩和できます。
An application group is a collection of applications that share common access control policies. A device may run multiple applications, and different policies might need to be applied to the applications and device. A single application may need to run on multiple devices/VMs/containers; the abstraction of an application group eases the process of application migration. For example, the policy does not depend on the transport coordinates (i.e., 5-tuple). Table 3 shows an example of how application group definitions may be characterized.
アプリケーショングループは、共通のアクセス制御ポリシーを共有するアプリケーションの集合です。1つのデバイスが複数のアプリケーションを実行することがあり、アプリケーションとデバイスに異なるポリシーを適用する必要がある場合があります。1つのアプリケーションが複数のデバイス/VM/コンテナ上で実行される必要がある場合もあり、アプリケーショングループという抽象化によって、アプリケーションの移行の手順が容易になります。例えば、ポリシーはトランスポートの座標（すなわち5-tuple）に依存しません。表3にアプリケーショングループの定義を特徴づける方法の例を示します。
+=======================+==========+==========================+
| Group Name | Group ID | Group Description |
+=======================+==========+==========================+
| Audio/Video Streaming | baz-70 | Audio/Video conferencing |
| | | application |
+-----------------------+----------+--------------------------+
| Instant Messaging | baz-80 | Messaging application |
+-----------------------+----------+--------------------------+
| Document | baz-90 | Real-time document |
| Collaboration | | editing application |
+-----------------------+----------+--------------------------+
Table 3: Application Group Examples
表3: アプリケーショングループの例
Policy enforcement can be targeted to different endpoint groups in different scenarios. For example, when a user connects to the network and accesses an application hosted on one or multiple devices, access policies may be applied to different user groups. In some cases, applications and devices may operate and run without requiring any user interventions, or they may require user authentication, but access rules do not differentiate between different users. This enables policies to be applied to the application or device group. A device group can be used when there is only one single application running on the device or different applications running but with the same access control rules. If there is an application running on different devices/VMs/containers, it is simpler to apply a single policy to the application group.
ポリシーの実施は、シナリオに応じて異なるエンドポイントグループを対象にできます。例えば、ユーザがネットワークに接続し、1つまたは複数のデバイス上でホストされているアプリケーションにアクセスする場合、アクセスポリシーは異なるユーザグループに適用されることがあります。場合によっては、アプリケーションやデバイスがユーザの介入を必要とせずに動作・実行されたり、ユーザ認証を必要としても、アクセスルールが異なるユーザを区別しなかったりします。これにより、ポリシーをアプリケーショングループまたはデバイスグループに適用できます。デバイスグループは、デバイス上で動作するアプリケーションが1つだけの場合、または異なるアプリケーションが動作していても同じアクセス制御ルールを持つ場合に使用できます。アプリケーションが複数のデバイス/VM/コンテナ上で動作している場合は、アプリケーショングループに単一のポリシーを適用するほうが簡単です。
This module specifies an extension to the "ietf-access-control-list" module [RFC8519]. This extension adds endpoint groups so that an endpoint group identifier can be matched upon, and it also enables access control policy activation based on date and time conditions.
このモジュールは、"ietf-access-control-list" モジュール [RFC8519] への拡張を規定します。この拡張はエンドポイントグループを追加して、エンドポイントグループ識別子を照合できるようにするとともに、日付と時刻の条件に基づくアクセス制御ポリシーの有効化も可能にします。
Figure 2 provides the tree structure of the "ietf-ucl-acl" module.
図2に "ietf-ucl-acl" モジュールのツリー構造を示します。
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
Figure 2: Tree Structure of the "ietf-ucl-acl" Module
図2: "ietf-ucl-acl" モジュールのツリー構造
The first part of the "ietf-ucl-acl" module augments the "acls" container in the "ietf-access-control-list" module [RFC8519] with an "endpoint-groups" container that includes an "endpoint-group" list, where each entry has a "group-id" that uniquely identifies the endpoint group and a "group-type" parameter to specify the endpoint group type.
"ietf-ucl-acl" モジュールの第1の部分は、"ietf-access-control-list" モジュール [RFC8519] の "acls" コンテナを、"endpoint-groups" コンテナで拡張します。このコンテナは "endpoint-group" リストを含み、各エントリは、エンドポイントグループを一意に識別する "group-id" と、エンドポイントグループの種類を指定する "group-type" パラメータを持ちます。
"group-id" is defined as a string rather than an unsigned integer (e.g., uint32) to accommodate deployments that require some identification hierarchy within a domain. Such a hierarchy is meant to ease coordination within an administrative domain. There might be cases where a domain needs to tag packets with the group they belong to. The tagging does not need to mirror exactly the "group ID" used to populate the policy. How the "group-id" string is mapped to the tagging or field in the packet header in an encapsulation scenario is outside the scope of this document. Augmentation may be considered in the future to cover encapsulation considerations.
"group-id" は、ドメイン内で何らかの識別の階層を必要とする展開に対応するため、符号なし整数（例: uint32）ではなく文字列として定義されています。このような階層は、管理ドメイン内の調整を容易にすることを意図しています。ドメインが、パケットに所属するグループをタグ付けする必要がある場合も考えられます。タグ付けは、ポリシーの作成に使用される "group ID" と正確に一致する必要はありません。カプセル化のシナリオにおいて、"group-id" 文字列がパケットヘッダ内のタグ付けやフィールドにどのようにマッピングされるかは、本ドキュメントの対象範囲外です。カプセル化に関する考慮事項に対応するための拡張は、将来検討される可能性があります。
The second part of the "ietf-ucl-acl" module augments the "matches" container in the "ietf-access-control-list" module [RFC8519] so that a source and/or destination endpoint group ID can be referenced as the match criteria.
"ietf-ucl-acl" モジュールの第2の部分は、"ietf-access-control-list" モジュール [RFC8519] の "matches" コンテナを拡張し、送信元および/または宛先のエンドポイントグループIDを照合基準として参照できるようにします。
The third part of the module augments the "ace" list in the "ietf-access-control-list" module [RFC8519] with date- and time-specific parameters to allow an ACE to be activated based on a date/time condition. Two types of time ranges ("period" and "recurrence") are defined, which reuse the "period-of-time" and "icalendar-recurrence" groupings, respectively, defined in the "ietf-schedule" YANG module [RFC9922].
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
"The User-group-based Control List (UCL) YANG module augments
the IETF Access Control Lists (ACLs) module. UCL is meant
to ensure consistent enforcement of ACL policies based on
the group identity.
Copyright (c) 2026 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 Revised
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).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC 10065; see
the RFC itself for full legal notices.";
revision 2026-10-07 {
description
"Initial revision.";
reference
"RFC 10065: A YANG Data Model and RADIUS Extension for
Policy-Based Network Access Control";
}
feature schedule {
description
"Indicates support of schedule-based Access Control
Entries (ACEs).";
}
feature match-on-group {
description
"Indicates support of matching on endpoint groups.";
}
feature group {
if-feature "ucl:match-on-group";
description
"Indicates support of group-based ACLs.";
}
feature mixed-ipv4-group {
if-feature "acl:match-on-ipv4 and ucl:match-on-group";
description
"IPv4 and group ACL combinations supported.";
}
feature mixed-ipv6-group {
if-feature "acl:match-on-ipv6 and ucl:match-on-group";
description
"IPv6 and group ACL combinations supported.";
}
feature mixed-ipv4-ipv6-group {
if-feature "acl:match-on-ipv4 and acl:match-on-ipv6 and "
+ "ucl:match-on-group";
description
"IPv4, IPv6, and group ACL combinations supported.";
}
feature mixed-eth-group {
if-feature "acl:match-on-eth and ucl:match-on-group";
description
"Ethernet and group ACL combinations supported.";
}
feature mixed-eth-ipv4-group {
if-feature "acl:match-on-eth and acl:match-on-ipv4 and "
+ "ucl:match-on-group";
description
"Ethernet, IPv4, and group ACL combinations supported.";
}
feature mixed-eth-ipv6-group {
if-feature "acl:match-on-eth and acl:match-on-ipv6 and "
+ "ucl:match-on-group";
description
"Ethernet, IPv6, and group ACL combinations supported.";
}
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
"Ethernet, IPv4, IPv6, and group ACL combinations supported.";
}
identity group-acl-type {
if-feature "group";
base acl:acl-base;
description
"An ACL that matches based on an endpoint group identifier,
which can represent the collective identity of a group of
authenticated users, end devices, or applications. An
endpoint group identifier may be carried in the outer/inner
packet header (e.g., via Network Virtualization over Layer 3
(NVO3) encapsulation) or may not correspond to any field in
the packet header. Matching on Layer 4 header fields may
also exist in the ACEs.";
}
identity mixed-ipv4-group-type {
if-feature "mixed-ipv4-group";
base acl:ipv4-acl-type;
base ucl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in the IPv4 header and endpoint group identifiers, which can
represent the collective identity of a group of authenticated
users, end devices, or applications. Matching on Layer 4
header fields may also exist in the ACEs.";
}
identity mixed-ipv6-group-type {
if-feature "mixed-ipv6-group";
base acl:ipv6-acl-type;
base ucl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in the IPv6 header and endpoint group identifiers, which can
represent the collective identity of a group of authenticated
users, end devices, or applications. Matching on Layer 4
header fields may also exist in the ACEs.";
}
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
"An ACL that contains a mix of entries that match on fields
in the IPv4 header, IPv6 header, and endpoint group
identifiers, which can represent the collective identity of
a group of authenticated users, end devices, or applications.
Matching on Layer 4 header fields may also exist in the
ACEs.";
}
identity mixed-eth-group-type {
if-feature "mixed-eth-group";
base acl:eth-acl-type;
base ucl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in the Ethernet header and endpoint group identifiers,
which can represent the collective identity of a group of
authenticated users, end devices, or applications. Matching
on Layer 4 header fields may also exist in the ACEs.";
}
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
"An ACL that contains a mix of entries that match on fields
in the Ethernet header, IPv4 header, and endpoint group
identifiers, which can represent the collective identity of
a group of authenticated users, end devices, or applications.
Matching on Layer 4 header fields may also exist in the
ACEs.";
}
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
"An ACL that contains a mix of entries that match on fields
in the Ethernet header, IPv6 header, and endpoint group
identifiers, which can represent the collective identity of
a group of authenticated users, end devices, or applications.
Matching on Layer 4 header fields may also exist in the
ACEs.";
}
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
"An ACL that contains a mix of entries that match on fields
in the Ethernet header, IPv4 header, IPv6 header, and
endpoint group identifiers, which can represent the collective
identity of a group of authenticated users, end devices, or
applications. Matching on Layer 4 header fields may also
exist in the ACEs.";
}
identity endpoint-group-type {
description
"Identity for the type of endpoint group.";
}
identity user-group {
base ucl:endpoint-group-type;
description
"Indicates user endpoint group type.";
}
identity device-group {
base ucl:endpoint-group-type;
description
"Indicates device endpoint group type.";
}
identity application-group {
base ucl:endpoint-group-type;
description
"Indicates application endpoint group type.";
}
typedef group-id-reference {
type leafref {
path "/acl:acls/ucl:endpoint-groups"
+ "/ucl:endpoint-group/ucl:group-id";
}
description
"Defines a reference to a group identifier.";
}
augment "/acl:acls" {
if-feature "ucl:group";
description
"Adds a container for endpoint group definition.";
container endpoint-groups {
description
"Defines a container for the endpoint group list.";
list endpoint-group {
key "group-id";
description
"Definition of the endpoint group list.";
leaf group-id {
type string {
length "1..64";
}
description
"The endpoint group identifier that uniquely identifies
an endpoint group.";
}
leaf group-type {
type identityref {
base endpoint-group-type;
}
description
"Specifies the type of the endpoint group (e.g., user,
device, or application). When not configured, the
group is considered a generic or untyped endpoint
group.";
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
if-feature "ucl:match-on-group";
description
"Specifies how a source and/or destination endpoint group
ID can be referenced as the match criteria in the ACEs.";
container endpoint-group {
when "derived-from-or-self(/acl:acls/acl:acl/acl:type, "
+ "'ucl:group-acl-type')";
description
"Adds new match criteria based on the group identifier
associated with the packet's source and/or
destination endpoint.
Note that this container is only valid when the ACL
type is equal to or derived from 'group-acl-type',
which depends on the 'group' feature. That is,
implementations advertising 'match-on-group' need to
also support the 'group' feature to ensure the
validity of this container.";
leaf source-group-id {
type group-id-reference;
description
"The matched source endpoint group identifier.";
}
leaf destination-group-id {
type group-id-reference;
description
"The matched destination endpoint group identifier.";
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace" {
if-feature "ucl:schedule";
description
"Adds schedule parameters to allow the ACE to take effect
based on date and time.";
container effective-schedule {
description
"Defines when the access control entry rules
are applied based on date and time conditions.
If it is not configured, the ACE is immediately
and always applied.";
choice schedule-type {
description
"Choice based on the type of the time range.";
container period {
description
"The ACE is applied based on a precise period of
time.";
uses schedule:period-of-time;
}
container recurrence {
if-feature "schedule:icalendar-recurrence";
description
"The ACE is applied based on a recurrence rule.";
uses schedule:icalendar-recurrence;
}
}
}
}
}
This section defines the User-Access-Group-ID RADIUS attribute, which is designed for user-centric access control scenarios where network access is triggered by user authentication and used to indicate the user group ID to be used by the NAS. For other endpoint group types, such as device or application groups, the identifiers are typically preprovisioned on the SDN controller based on an inventory or an application registry.
本セクションでは、User-Access-Group-ID RADIUS属性を定義します。この属性は、ネットワークアクセスがユーザ認証を契機とするユーザ中心のアクセス制御シナリオ向けに設計されており、NASが使用するユーザグループIDを示すために使われます。デバイスグループやアプリケーショングループなどの他のエンドポイントグループの種類については、識別子は通常、インベントリまたはアプリケーションレジストリに基づいてSDNコントローラ上にあらかじめプロビジョニングされます。
The definition of the attribute follows the guidelines in Section 2.7.1 of [RFC6929]. When the User-Access-Group-ID RADIUS attribute is present in the RADIUS Access-Accept, the system applies the related access control to the user after the user authenticates.
この属性の定義は、[RFC6929] のセクション2.7.1のガイドラインに従います。User-Access-Group-ID RADIUS属性がRADIUS Access-Acceptに存在する場合、システムは、ユーザが認証された後に、そのユーザに関連するアクセス制御を適用します。
The User-Access-Group-ID RADIUS attribute is of type "string" as defined in Section 3.5 of [RFC8044].
User-Access-Group-ID RADIUS属性は、[RFC8044] のセクション3.5で定義されている "string" 型です。
The User-Access-Group-ID RADIUS attribute MAY appear in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server to indicate a preference. However, the server is not required to honor such a preference. If more than one instance of the User-Access-Group-ID RADIUS attribute appears in a RADIUS Access-Accept packet, it means that the user is a member of many groups.
User-Access-Group-ID RADIUS属性は、RADIUS Access-Acceptパケットに含まれてもよい (MAY)。また、RADIUSサーバに対して優先を示すヒントとして、RADIUS Access-Requestパケットに含まれてもよい (MAY)。ただし、サーバがそのような優先を尊重することは求められません。User-Access-Group-ID RADIUS属性の複数のインスタンスがRADIUS Access-Acceptパケットに含まれている場合、ユーザが多数のグループのメンバーであることを意味します。
The User-Access-Group-ID RADIUS attribute MAY appear in a RADIUS CoA-Request packet.
User-Access-Group-ID RADIUS属性は、RADIUS CoA-Requestパケットに含まれてもよい (MAY)。
The User-Access-Group-ID RADIUS attribute MAY appear in a RADIUS Accounting-Request packet. Specifically, this may be used by a NAS to acknowledge that the attribute was received in the RADIUS Access-Accept and the NAS is enforcing that policy.
User-Access-Group-ID RADIUS属性は、RADIUS Accounting-Requestパケットに含まれてもよい (MAY)。具体的には、NASが、RADIUS Access-Acceptで属性を受信し、そのポリシーを実施していることを通知するために使用される場合があります。
The User-Access-Group-ID RADIUS attribute MUST NOT appear in any other RADIUS packet.
User-Access-Group-ID RADIUS属性は、他のいかなるRADIUSパケットにも含まれてはなりません (MUST NOT)。
The User-Access-Group-ID RADIUS attribute is structured as follows:
User-Access-Group-ID RADIUS属性の構造は次のとおりです。
Type:
Type:
241.12
241.12
Length:
Length:
This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and Value. The Length MUST at least 4 octets and MUST NOT be more than 67 octets. The maximum length is 67 octets to accommodate the maximum group ID of 64 octets, plus one octet each for Type, Length, and Extended-Type.
このフィールドは、Type、Length、Extended-Type、Valueを含む、この属性の全フィールドの合計の長さをオクテット単位で示します。Lengthは少なくとも4オクテットでなければならず (MUST)、67オクテットを超えてはなりません (MUST NOT)。最大長が67オクテットなのは、最大64オクテットのグループIDに、Type、Length、Extended-Typeのそれぞれ1オクテットを加えた長さに対応するためです。
Data Type:
データ型：
Value:
値：
This field contains the user group ID.
このフィールドには、ユーザグループIDが入ります。
Table 4 provides a guide that indicates which types of RADIUS packets may contain a User-Access-Group-ID RADIUS attribute and in what quantity.
表4は、どの種類のRADIUSパケットにUser-Access-Group-ID RADIUS属性を含めることができ、その数がいくつであるかを示す指針です。
+================+=========+=========+===========+==============+
| Access-Request | Access- | Access- | Access- | Attribute |
| | Accept | Reject | Challenge | |
+================+=========+=========+===========+==============+
| 0+ | 0+ | 0 | 0 | User-Access- |
| | | | | Group-ID |
+----------------+---------+---------+-----------+--------------+
| Accounting- | CoA- | CoA-ACK | CoA-NACK | Attribute |
| Request | Request | | | |
+----------------+---------+---------+-----------+--------------+
| 0+ | 0+ | 0 | 0 | User-Access- |
| | | | | Group-ID |
+----------------+---------+---------+-----------+--------------+
Table 4: Table of Attributes
表4：属性の一覧表
Notation for Table 4:
表4の表記：
0
0
This attribute MUST NOT be present in the packet.
この属性は、パケットに含まれてはなりません (MUST NOT)。
0+
0+
Zero or more instances of this attribute MAY be present in the packet.
この属性のインスタンスが、パケットに0個以上含まれてもよい (MAY)。
The UCL data model can be implemented in different ways.
UCLデータモデルは、さまざまな方法で実装できます。
In some cases, the UCL data model is implemented at the network/ administrative domain level, where an SDN controller maintains the dynamic mapping from an endpoint group ID to IP/transport fields (e.g., the 5-tuple) and programs the PEPs with IP-address-based or 5- tuple-based ACLs. In such cases, PEPs do not require implementing specific logic (including hardware) compared to the enforcement of conventional ACLs.
場合によっては、UCLデータモデルはネットワーク/管理ドメインのレベルで実装されます。この場合、SDNコントローラがエンドポイントグループIDからIP/トランスポートフィールド (例：5タプル) への動的なマッピングを維持し、IPアドレスベースまたは5タプルベースのACLをPEPに設定します。このような場合、PEPは、従来のACLの実施と比べて、(ハードウェアを含む) 特別なロジックを実装する必要はありません。
It is possible for the UCL data model to be implemented at the device level. While it eliminates the need for an SDN controller to interact frequently with the PEPs for reasons like the user's context of network connection change or VM/application migration, dedicated hardware/software support might be needed for PEPs to understand the endpoint group identifier. In scenarios where the NAS behaves as the PEP that acquires the source and/or destination endpoint group ID from the AAA server, ACL policy enforcement based on the group ID without being encapsulated into packet headers might affect the forwarding performance. Implementations need to evaluate the operational trade-off (flexibility brought to the network vs. the complexity of implementation) carefully. Such an assessment is out of scope for this document.
UCLデータモデルをデバイスレベルで実装することも可能です。この方法では、ユーザのネットワーク接続のコンテキストの変更やVM/アプリケーションの移行などのために、SDNコントローラがPEPと頻繁にやり取りする必要がなくなります。一方で、PEPがエンドポイントグループ識別子を理解するには、専用のハードウェア/ソフトウェアのサポートが必要になる場合があります。NASがPEPとして動作し、AAAサーバから送信元および/または宛先のエンドポイントグループIDを取得するシナリオでは、パケットヘッダにカプセル化されていないグループIDに基づくACLポリシーの実施は、転送性能に影響する可能性があります。実装者は、運用上のトレードオフ (ネットワークにもたらされる柔軟性と実装の複雑さ) を慎重に評価する必要があります。このような評価は、本文書の範囲外です。
Some devices may not have built-in capabilities to enforce group-based match policies. Hardware or software upgrades may be required to support such features by the involved PEPs.
一部のデバイスには、グループベースのマッチポリシーを実施する組み込み機能がない場合があります。そのような機能をサポートするには、関係するPEPでハードウェアまたはソフトウェアのアップグレードが必要になる場合があります。
This specification requires that an adequate setup is put in place to map a group ID to packet fields, typically managed by a controller. Special care should be taken to ensure that such mapping is appropriately enforced when distinct mechanisms (RADIUS, etc.) are supported in the network.
本仕様では、グループIDをパケットフィールドにマッピングするための適切な設定 (通常はコントローラが管理) が整えられていることを求めます。ネットワーク内で異なる仕組み (RADIUSなど) がサポートされている場合は、そのようなマッピングが適切に実施されるよう、特に注意を払う必要があります。
This section is modeled after the template described in Section 3.7.1 of [RFC9907].
本節は、[RFC9907] の3.7.1節に記載されたテンプレートに基づいています。
The "ietf-ucl-acl" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC9846], and QUIC [RFC9000]) and (2) have to use mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Network Configuration Access Control Model (NACM) [RFC8341] は、特定のNETCONFまたはRESTCONFユーザによるアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツのうち、事前に設定された部分集合に制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
このYANGモジュールには、書き込み/作成/削除が可能な (つまり、デフォルトである "config true" の) データノードが多数定義されています。書き込み可能なデータノードはすべて、ネットワーク環境によっては機微であるか、脆弱である可能性があります。これらのデータノードに対する書き込み操作 (例：edit-config) や削除操作が、適切な保護や認証なしに行われると、ネットワーク運用に悪影響を及ぼす可能性があります。次のサブツリーおよびデータノードは、特に機微性/脆弱性があります。
* /acl:acls/ucl:endpoint-groups/ucl:endpoint-group:
* /acl:acls/ucl:endpoint-groups/ucl:endpoint-group:
This list specifies all the endpoint group entries. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an endpoint group that does not exist or maliciously delete an existing endpoint group, which could be used to craft an attack.
このリストは、すべてのエンドポイントグループエントリを指定します。このリストへの不正な書き込みアクセスを許すと、侵入者がエントリを改変して存在しないエンドポイントグループを偽造したり、既存のエンドポイントグループを悪意をもって削除したりできるようになり、攻撃の手段として利用される可能性があります。
* /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/ucl:endpoint-group:
* /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/ucl:endpoint-group:
This subtree specifies a source and/or destination endpoint group ID as match criteria in the ACEs. Unauthorized write access to this data node may allow intruders to modify the group ID so as to permit access that should not be permitted, or deny access that should be permitted.
このサブツリーは、ACEのマッチ基準として、送信元および/または宛先のエンドポイントグループIDを指定します。このデータノードへの不正な書き込みアクセスを許すと、侵入者がグループIDを改変して、許可されるべきでないアクセスを許可したり、許可されるべきアクセスを拒否したりする可能性があります。
* /acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule:
* /acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule:
It specifies the scheduling of ACLs. Unauthorized write access to this data node may allow intruders to alter it. This may lead to service disruption or unavailability. Strict access control is needed for write operations on this subtree to ensure that only authorized users can modify it.
ACLのスケジューリングを指定します。このデータノードへの不正な書き込みアクセスを許すと、侵入者がそれを変更する可能性があります。これにより、サービスの中断や利用不能が生じる可能性があります。許可されたユーザだけがこれを変更できるようにするため、このサブツリーへの書き込み操作には厳格なアクセス制御が必要です。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
このYANGモジュールの読み取り可能なデータノードの一部は、ネットワーク環境によっては機微であるか、脆弱であるとみなされる可能性があります。したがって、これらのデータノードへの読み取りアクセス (例：get、get-config、通知による) を制御することが重要です。特に、次のサブツリーおよびデータノードは、特に機微性/脆弱性があります。
* /acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule:
* /acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule:
It specifies when the access control entry rules are applied. Unauthorized read access of the list will allow an attacker to determine which rules are applied, to better craft an attack.
アクセス制御エントリのルールがいつ適用されるかを指定します。このリストへの不正な読み取りアクセスを許すと、攻撃者はどのルールが適用されるかを把握でき、攻撃をより巧妙に仕掛けられるようになります。
This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to the Security Considerations of [RFC9922] for information as to which nodes may be considered sensitive or vulnerable in network environments.
このYANGモジュールは、他のYANGモジュールのグルーピングを使用しており、それらはネットワーク環境によっては機微であるか、脆弱であるとみなされるノードを定義しています。どのノードが機微または脆弱とみなされる可能性があるかについては、[RFC9922] のセキュリティに関する考慮事項を参照してください。
RADIUS-related security considerations are discussed in [RFC2865]. An effort to deprecate insecure practices in RADIUS is provided in [RADIUS-DEPRECATE].
RADIUSに関するセキュリティ上の考慮事項は、[RFC2865] で論じられています。RADIUSにおける安全でない慣行を非推奨とする取り組みは、[RADIUS-DEPRECATE] に示されています。
This document targets deployments where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614] [RadSec].
本文書は、RADIUSクライアントとサーバの間に信頼関係があり、通信がIPsecまたはTransport Layer Security (TLS) [RFC6614] [RadSec] により任意で保護される展開を対象としています。
IANA has assigned the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:
IANAは、「IETF XML Registry」グループ [RFC3688] 内の「ns」レジストリに、次のURIを割り当てました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-ucl-acl
urn:ietf:params:xml:ns:yang:ietf-ucl-acl
Registrant Contact:
登録者連絡先：
The IESG
The IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
N/A。要求されたURIはXML名前空間です。
IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:
IANAは、「YANG Parameters」レジストリグループ内の「YANG Module Names」レジストリ [RFC6020] に、次のYANGモジュールを登録しました。
Name:
名前：
ietf-ucl-acl
ietf-ucl-acl
Maintained by IANA?
IANAが維持管理しているか：
N
N
Namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-ucl-acl
urn:ietf:params:xml:ns:yang:ietf-ucl-acl
Prefix:
プレフィックス：
ucl
ucl
Reference:
参照：
RFC 10065
RFC 10065
IANA has assigned the following attribute type in the "RADIUS Attribute Types" registry within the "RADIUS Types" registry group [RADIUS-Types]:
IANAは、「RADIUS Types」レジストリグループ [RADIUS-Types] 内の「RADIUS Attribute Types」レジストリに、次の属性タイプを割り当てました。
+========+======================+===========+===========+
| Value | Description | Data Type | Reference |
+========+======================+===========+===========+
| 241.12 | User-Access-Group-ID | string | RFC 10065 |
+--------+----------------------+-----------+-----------+
Table 5: RADIUS Attribute
表5: RADIUS属性
[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>.
[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>.
Let's consider an organization that would like to manage the access of R&D employees who bring personally owned devices (BYOD) into the workplace.
私物のデバイス (BYOD) を職場に持ち込む研究開発部門の従業員のアクセスを管理したい組織を考えます。
The access requirements are as follows:
アクセス要件は次のとおりです。
* Permit traffic from R&D employees' personal devices, destined to R&D employees' devices, every work day from 8:00:00 to 18:00:00 UTC, starting on January 1, 2026.
* 研究開発部門の従業員の私物デバイスから、研究開発部門の従業員のデバイス宛てのトラフィックを、2026年1月1日から、毎営業日のUTC 8:00:00から18:00:00まで許可する。
* Deny traffic from R&D employees' personal devices, destined to finance servers located in the enterprise data center (DC) network, starting at 8:30:00 on January 20, 2026, with an offset of -08:00 from UTC (Pacific Standard Time), and ending at 18:00:00 in Pacific Standard Time on December 31, 2026.
* 研究開発部門の従業員の私物デバイスから、企業のデータセンター (DC) ネットワークにある経理サーバ宛てのトラフィックを、UTCからのオフセットが-08:00 (太平洋標準時) として、2026年1月20日の8:30:00から2026年12月31日の太平洋標準時18:00:00まで拒否する。
The example shown in Figure 3 illustrates the configuration of an SDN controller using the group-based ACL:
図3の例は、グループベースのACLを用いたSDNコントローラの設定を示しています。
{
"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"
}
}
}
]
}
}
]
}
}
Figure 3: Example of UCL Configuration on the SDN Controller
図3: SDNコントローラにおけるUCL設定の例
This section illustrates an example of configuring a PEP using the group-based ACL.
本節では、グループベースのACLを用いてPEPを設定する例を示します。
The PEP that enforces a group-based ACL may acquire group IDs from the AAA server if working as a NAS authenticating both the source endpoint and destination endpoint users. Another case for a PEP enforcing a group-based ACL is to obtain the group ID of the source endpoint directly from a packet field [VXLAN].
グループベースのACLを実施するPEPは、送信元エンドポイントと宛先エンドポイントの両方のユーザを認証するNASとして動作している場合、AAAサーバからグループIDを取得することがあります。グループベースのACLを実施するPEPのもう1つのケースは、送信元エンドポイントのグループIDをパケットのフィールドから直接取得するものです [VXLAN]。
Assume the mapping between a device group ID and IP addresses is predefined or acquired via device authentication. Figure 4 shows the ACL configuration delivered from the controller to the PEP. This example is consistent with the example presented in Appendix A.1.
デバイスグループIDとIPアドレスとの対応付けは、あらかじめ定義されているか、デバイス認証を通じて取得されるものとします。図4は、コントローラからPEPへ配信されるACL設定を示しています。この例は、付録A.1で示した例と整合しています。
The examples in this section do not intend to be exhaustive. In particular, explicit IP addresses ("destination-ipv4-network" or "destination-ipv6-network") are provided only for one single rule to illustrate how the mapping between a group ID and IP addresses is translated into an ACL rule entry.
本節の例は、網羅的であることを意図していません。特に、明示的なIPアドレス ("destination-ipv4-network" または "destination-ipv6-network") は、グループIDとIPアドレスとの対応付けがどのようにACLルールエントリへ変換されるかを示すため、1つのルールに対してのみ示しています。
{
"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"
}
}
}
]
}
}
]
}
}
Figure 4: Example of PEP Configuration Using a Group-Based ACL
図4: グループベースのACLを用いたPEP設定の例
Figure 5 shows an example of the same policy but with a destination IPv6 prefix.
図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"
}
}
}
]
}
}
]
}
}
Figure 5: Example of PEP Configuration Using a Group-Based ACL (IPv6)
図5: グループベースのACLを用いたPEP設定の例 (IPv6)
This section describes an example of configuring a PEP using an IP-address-based ACL. IP-address-based access control policies could be applied to a PEP that may not understand the group information (e.g., a firewall).
本節では、IPアドレスベースのACLを使用してPEPを設定する例を説明します。IPアドレスベースのアクセス制御ポリシーは、グループ情報を理解しない可能性のあるPEP(例: ファイアウォール)に適用できます。
Assume an employee in the R&D department accesses the network wirelessly from a non-corporate laptop. The SDN controller associates the user group to which the employee belongs with the user's address according to steps 1 to 4 in Section 4.1.
R&D部門の従業員が、会社支給ではないノートPCから無線でネットワークにアクセスするものとします。SDNコントローラは、セクション4.1のステップ1から4に従って、その従業員が属するユーザグループをユーザのアドレスに関連付けます。
Assume the mapping between a device group ID and IP addresses is predefined or acquired via device authentication. Figure 6 shows an IPv4-address-based ACL configuration delivered from the controller to the PEP. This example is consistent with the example presented in Appendix A.1.
デバイスグループIDとIPアドレスとの対応付けは、あらかじめ定義されているか、デバイス認証によって取得されるものとします。図6は、コントローラからPEPに配信されるIPv4アドレスベースのACL設定を示しています。この例は、付録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"
}
}
}
]
}
}
]
}
}
Figure 6: Example of PEP Configuration Using an Address-Based ACL
図6: アドレスベースのACLを使用したPEP設定の例
Figure 7 shows an example of the same policy but with IPv6 prefixes.
図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"
}
}
}
]
}
}
]
}
}
Figure 7: Example of PEP Configuration Using an Address-Based ACL (IPv6)
図7: アドレスベースのACLを使用したPEP設定の例 (IPv6)
This work has benefited from the discussions of user-group-based security policies over the years. In particular, [SECURITY-POLICY] and [ID-MAPPING] provide mechanisms to establish a mapping between the IP address/prefix of users and access control group IDs. The authors would like to thank Jianjie You, Myo Zarny, Christian Jacquenet, and Yizhou Li for their early contributions to these works.
この作業は、長年にわたるユーザグループベースのセキュリティポリシーに関する議論の恩恵を受けています。特に、[SECURITY-POLICY]と[ID-MAPPING]は、ユーザのIPアドレス/プレフィックスとアクセス制御のグループIDとの対応付けを確立するメカニズムを提供しています。著者らは、これらの作業に対する初期の貢献について、Jianjie You、Myo Zarny、Christian Jacquenet、Yizhou Liに感謝します。
Thanks to Joe Clarke, Bill Fenner, Benoît Claise, Rob Wilton, David Somers-Harris, Alan DeKok, Heikki Vatiainen, Wen Xiang, Wei Wang, Hongwei Li, and Jensen Zhang for their review and comments.
レビューとコメントをいただいた Joe Clarke、Bill Fenner、Benoît Claise、Rob Wilton、David Somers-Harris、Alan DeKok、Heikki Vatiainen、Wen Xiang、Wei Wang、Hongwei Li、Jensen Zhang に感謝します。
Thanks to Dhruv Dhody for the OPSDIR review, Alexander Pelov for the INTDIR review, Valery Smyslov for the SECDIR review, and Acee Lindem for the YANGDOCTORS review.
OPSDIRレビューをいただいた Dhruv Dhody、INTDIRレビューをいただいた Alexander Pelov、SECDIRレビューをいただいた Valery Smyslov、YANGDOCTORSレビューをいただいた Acee Lindem に感謝します。
Thanks to Mahesh Jethanandani for the AD review.
ADレビューをいただいた Mahesh Jethanandani に感謝します。
Thanks to Christopher Inacio, Andy Newton, Charles Eckel, Éric Vyncke, Deb Cooley, Gorry Fairhurst, Gunter Van de Velde, Jim Guichard, Ketan Talaulikar, and Mike Bishop for their IESG reviews.
IESGレビューをいただいた Christopher Inacio、Andy Newton、Charles Eckel、Éric Vyncke、Deb Cooley、Gorry Fairhurst、Gunter Van de Velde、Jim Guichard、Ketan Talaulikar、Mike Bishop に感謝します。
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