RFC 10065

A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control

📅 published October 2026, from ietf

A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control 🎀

Title block, the tea ☕

  • RFC: 10065 🦋
  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Category: Standards Track (it's a real Internet Standards Track doc 🏆)
  • ISSN: 2070-1721
  • Date: October 2026
  • Authors: Q. Ma, Ed. (Huawei), Q. Wu (Huawei), M. Boucadair, Ed. (Orange), D. King (Lancaster University) 🧚
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates, so there's nothing to report there 🙈

Abstract 💖

okay so this doc defines a YANG data model for policy-based network access control, which lets you enforce network access control policies based on group identity ✨ The YANG model also extends Access Control Lists (ACLs) with date and time parameters, so the policies can be schedule-aware ⏰

bestie, here's the part I'm obsessed with 😭 When network access is triggered by user authentication, this doc defines a mechanism that makes it way easier to keep the mapping between a user group identifier and a set of packet header fields up to date, so you can enforce policy-based network access control. It also defines a Remote Authentication Dial-in User Service (RADIUS) attribute that carries the user group identifier as part of identification and authorization information 🔥

Status of This Memo 📜

bestie, this is an Internet Standards Track document 🏆

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 🫶

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 🔗

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. 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. ⚖️

Table of Contents 🗺️

   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

1. Introduction 🌸

okay, so remote access tech like Virtual Private Networks (VPNs) and Bring Your Own Device (BYOD) policies has blown up 📈 which means enterprises got way more flexible about how, where, and when employees work and collaborate. But more flexibility comes with more risk 💀 Enabling office flexibility (e.g., mobility across many access locations) gives large-scale enterprises a whole set of challenges that conventional network access management approaches don't handle as well. Here are some of those challenges:

  • Endpoints don't have stable and unique IP addresses. Wireless LAN (WLAN) and VPN clients, plus back-end servers based on Virtual Machines (VMs), can move, so their IP addresses could change as a result. Mechanisms like IPv6 temporary addresses [RFC8981] and Network Address Port Translation (NAPT) [RFC3022] may make address instability and non-uniqueness even worse 😩 That complicates consistent, efficient access control policy enforcement that relies on IP/transport fields (e.g., the 5-tuple). IP-address-based policies may not be flexible enough for endpoints with volatile IP addresses 🙃
  • Teleworking is everywhere, so the same endpoints need different security policies in different circumstances. For example, you might want to prevent relay attacks against a local attachment point to the enterprise network 🕵️‍♀️ Network access might be granted based on things like 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. So the network needs to recognize endpoints' identities and their current contexts, then map each endpoint to its correct access grants 🎯

This document defines a YANG data model (Section 5.2) for policy-based network access control. It extends the IETF Access Control Lists (ACLs) module defined in [RFC8519] ✨ The module can be used to make sure ACL policies are enforced consistently based on group identity. The YANG data model in this document also extends ACLs with date and time parameters for schedule-aware policy enforcement 🗓️

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 ACLs defined in Section 5.2 doesn't limit how it can be used 🌈

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), so the policy-based access control can run 🔐 It also defines a Remote Authentication Dial-in User Service (RADIUS) [RFC2865] attribute that communicates the user group identifier as part of identification and authorization information (Section 6) 🧾

Although this document cites MAC addresses as an example in some sections, it does not make assumptions about which identifiers are used to trigger ACLs. Those 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 changing MAC addresses are discussed in [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], gives an example of how that may be achieved 🧩

2. Conventions and Definitions 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅

The meanings of the symbols in tree diagrams are defined in [RFC8340] 🌳

This document uses the following terms defined in [RFC8519]:

  • Access Control Entry (ACE) 🎀
  • Access Control List (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 lets users scan and print) 🖨️

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 📱

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 👯‍♀️

Device group: A collection of enterprise devices that share common access control policies. Refer to Section 4.2.2 for more details 💻

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 📲

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: 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 🦋

Policy: A set of rules to administer, manage, and control access to network resources [RFC3198] 👑

3. Sample Usage ✨

okay so some networks (like enterprise ones) need to figure out who you are no matter how, where, or when you connect to their resources 🔐. then the network maps each connecting endpoint to what it's actually allowed to access, and those access rights are defined using local policies. as Section 1 covered, there's a huge number of connecting endpoints, and one endpoint can show up with different source IP addresses in different network segments. so writing a network access control policy for every single IP address or network segment is a LOT of overhead 😭

the alternate approach is way more iconic: you configure endpoint groups to classify users, enterprise devices, and applications, then attach ACLs to those groups so everyone in a group shares the same set of ACL rules. this greatly reduces the overhead for administrators and optimizes ACL resources 💅

the network ACLs can be provisioned on devices using specific mechanisms, such as those described in [RFC8519] or [RFC9899].

different policies may apply in different contextual situations, bestie 🌸 for example, a company might restrict (or grant) employees access to specific internal or external resources during work hours, while a different policy kicks in during off-hours and weekends. a network administrator may also want traffic shaping (Section 2.3.3.3 of [RFC2475]) and policing (Section 2.3.3.4 of [RFC2475]) during peak hours so they don't mess with other data services 🦋

4. Policy-Based Network Access Control 🎀

4.1. Overview

okay, so here's the main character architecture for a system that gives you real-time and consistent enforcement of access control policies 👑. it's shown in Figure 1, and it's a user-centric flow with these functional entities and interfaces:

  • A service orchestrator that coordinates the overall service, including security policies. the service can be connectivity or any other access to resources that a network can host and offer 🧚
  • A Software-Defined Networking (SDN) [RFC7149] [RFC7426] controller that's responsible for maintaining endpoint-group-based ACLs and mapping each endpoint group to its associated attributes information (e.g., packet header fields) 💖. an SDN controller also acts as a Policy Decision Point (PDP) [RFC3198] and pushes the required access control policies out to the relevant Policy Enforcement Points (PEPs) [RFC3198]. a PDP is also known as a "policy server" [RFC2753] 🫶

an SDN controller may interact with an Authentication, Authorization, and Accounting (AAA) [RFC3539] server or a Network Access Server (NAS) [RFC7542] 🌈

  • A NAS entity that handles authentication requests. the NAS works 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) that the user belongs to when they first log onto the network ✨

a new RADIUS attribute is defined in Section 6 for this purpose 🔥

  • The AAA server provides a collection of authentication, authorization, and accounting functions. it's 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) 💜
  • A PEP is the central entity responsible for enforcing appropriate access control policies 💅. a first deployment scenario assumes 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 PEPs to map incoming packets to their associated source and/or destination endpoint group IDs and act on 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]) 🍓

multiple PEPs may be involved in a network 🌸

a PEP exposes a YANG-based interface (e.g., NETCONF [RFC6241]) to an SDN controller 🦋

Figure 1 gives you the overall architecture and procedure for policy-based access control management, so here it is 👀:

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

in reference to Figure 1, here's the typical flow 🧁:

  • Step 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 📝
  • Step 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 🙈
  • Step 3: the authentication request is then relayed to the AAA server using a protocol such as RADIUS [RFC2865]. it's 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 🔑

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 either that the user has no access (i.e., an Access-Reject is returned) or that 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 🚫

in some implementations, the AAA server can be integrated with the SDN controller 💫

  • Step 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 that notification is performed are out of scope of this specification 🤫
  • Step 5: either group-based access control policies or access control policies based on packet header fields are maintained on the 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 🌈

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) 🧚

Section 8 provides additional operational considerations 🫶

4.2. Endpoint Group

4.2.1. User Group

okay so 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's a change in their composite attributes, environment, and/or local enterprise policy 🔄

a user is authenticated, classified at the AAA server, and assigned to a user group. a user's group membership can 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 the range of addresses of the previous user group 😱

this document doesn't make any assumption about how user groups are defined. those considerations are deployment-specific and 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. 🗓️

   +=============+==========+===================================+
   | 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

4.2.2. Device Group 💻

okay so a device group ID is an identifier that represents the collective identity of a whole group of enterprise devices 🫶. Table 2 shows an example of how device group definitions may be characterized ✨

        +==================+==========+===========================+
        | 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

Matching abstract device group IDs instead of specified addresses in ACL policies is giving shield 🛡️ energy. It helps protect against the consequences of address changes, like when a back-end VM-based server gets migrated 🦋

4.2.3. Application Group 🎀

An application group is a collection of applications that share common access control policies 🌸. A device can run multiple applications, and different policies might need to be applied to the applications and the device 🤔. A single application may need to run on multiple devices/VMs/containers, and 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 🧚

      +=======================+==========+==========================+
      | 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

4.3. Relations Between Different Endpoint Groups 🌈

Policy enforcement can be targeted at 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 when different applications are 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 💖

5. The UCL Extension to the ACL Module 👑

5.1. Module Overview 🦋

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 ⏰

Figure 2 provides the tree structure of the "ietf-ucl-acl" module 🌳

   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

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. Each entry has a "group-id" that uniquely identifies the endpoint group, plus a "group-type" parameter to specify the endpoint 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 🔥

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 🎯

The third part of the module augments the "ace" list in the "ietf-access-control-list" module [RFC8519] with date- and time-specific parameters, so that an ACE can 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] 🧠

5.2. The "ietf-ucl-acl" YANG Module 🧾

This module imports types and groupings defined in the "ietf-schedule" module [RFC9922]. It also augments the "ietf-access-control-list" module (Section 4.1 of [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
       "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; } } } } } <CODE ENDS>

6. User-Access-Group-ID RADIUS Attribute 🎀

okay bestie, this section is all about the User-Access-Group-ID RADIUS attribute 💅 It's built for user-centric access control, where network access gets triggered by user authentication and the attribute tells the NAS which user group ID to use. For other endpoint group types, like device or application groups, the IDs are usually preprovisioned on the SDN controller based on an inventory or an application registry 🧚

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 they authenticate 🔥

The User-Access-Group-ID RADIUS attribute is of type "string" as defined in Section 3.5 of [RFC8044] 🫶

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 👑

The User-Access-Group-ID RADIUS attribute MAY appear in a RADIUS CoA-Request packet 🦋

The User-Access-Group-ID RADIUS attribute MAY appear in a RADIUS Accounting-Request packet. Specifically, this can be used by a NAS to acknowledge that the attribute was received in the RADIUS Access-Accept and the NAS is enforcing that policy 💖

The User-Access-Group-ID RADIUS attribute MUST NOT appear in any other RADIUS packet. no exceptions, periodt 💀

The User-Access-Group-ID RADIUS attribute is structured as follows:

  • Type: 241.12
  • 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 🌸
  • Data Type: string (Section 3.5 of [RFC8044]).
  • Value: This field contains the user group ID.

7. Table of RADIUS Attributes 📋

Table 4 is your cheat sheet 🍓 It shows which types of RADIUS packets can contain a User-Access-Group-ID RADIUS attribute, and how many of them you're allowed to have.

+================+=========+=========+===========+==============+
| 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

Notation for Table 4:

  • 0: This attribute MUST NOT be present in the packet.
  • 0+: Zero or more instances of this attribute MAY be present in the packet. 🧚

8. Operational Considerations 🛠️

8.1. Deployment Options 🚀

The UCL data model can be implemented in different ways, so let's look at the options 👀

In some cases, the UCL data model is implemented at the network/administrative domain level. Here, an SDN controller maintains the dynamic mapping from an endpoint group ID to IP/transport fields (e.g., the 5-tuple), and it 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. easy mode 🌈

It is possible for the UCL data model to be implemented at the device level. While this 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. 🙈

8.2. Hardware/Software Implications 🔧

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.

8.3. Mapping Consistency 🧩

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. bestie, this is the part where things go sideways if nobody's watching 😭

9. Security Considerations 🚨

9.1. YANG 🔐

This section is modeled after the template described in Section 3.7.1 of [RFC9907].

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.

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:

  • /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: 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. 🚨
  • /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. no cap, this one is serious 😤

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:

  • /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.

9.2. RADIUS 📡

RADIUS-related security considerations are discussed in [RFC2865]. An effort to deprecate insecure practices in RADIUS is provided in [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]. 🔒

10. IANA Considerations 🦋

10.1. YANG 🌸

IANA has assigned the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-ucl-acl
Registrant Contact:  The IESG
XML:  N/A; the requested URI is an XML namespace.

IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:

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 has assigned the following attribute type in the "RADIUS Attribute Types" registry within the "RADIUS Types" registry group [RADIUS-Types]:

+========+======================+===========+===========+
| Value  | Description          | Data Type | Reference |
+========+======================+===========+===========+
| 241.12 | User-Access-Group-ID | string    | RFC 10065 |
+--------+----------------------+-----------+-----------+

Table 5: RADIUS Attribute

11. References 📚

11.1. Normative References 📚

okay bestie, here's the reading list the main text is built on 🫶

11.2. Informative References 🔍

these ones are more like extra reading, the vibes-and-context shelf 🧚

Appendix A. Usage Examples ✨

A.1. Configuring the Controller Using the Group-Based ACL ✨

okay so picture an org that wants to manage access for R&D employees who bring their own personal devices (BYOD) into the office 💻🎀. Here's what they need:

  • 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. 🌸
  • 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. 🙈

Figure 3 shows how to set up an SDN controller with the group-based ACL. It's giving config energy 🧚💜

{
  "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

A.2. Configuring a PEP Using the Group-Based ACL 🦋

okay this part is all about setting up a PEP with the group-based ACL, and it's honestly so satisfying 🫶. A PEP enforcing a group-based ACL may grab group IDs from the AAA server if it's working as a NAS that authenticates both the source endpoint and the destination endpoint users. Another option is for the PEP to pull the source endpoint's group ID straight out of a packet field [VXLAN]. 🔥

Assume the device group ID to IP address mapping is predefined, or it gets acquired through device authentication. Figure 4 shows the ACL configuration that the controller delivers to the PEP. This example lines up with the one from Appendix A.1, so it's all one consistent story 💅✨

These examples are not meant to be exhaustive, so don't expect every possible case 🙈 Explicit IP addresses ("destination-ipv4-network" or "destination-ipv6-network") only show up in one single rule, just to show how a mapping between a group ID and IP addresses gets turned into an ACL rule entry.

{
  "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

Figure 5 shows the same policy, but this time with a destination IPv6 prefix. Same vibe, different address family 🌈

{
  "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)

A.3. Configuring a PEP Using an Address-Based ACL 🦋

okay bestie, this one is about setting up a PEP with an IP-address-based ACL 🧚 Some policies could be applied to a PEP that may not understand group information at all, like a firewall. Not every gadget speaks group, and firewalls are literally the classic example 🙈

Assume an employee in the R&D department is on the network wirelessly from a non-corporate laptop 💻 The SDN controller links the user group they belong to with the user's address, following steps 1 to 4 in Section 4.1. So the group info is already attached to the address before any policy gets pushed.

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 one in Appendix A.1, so it all lines up 🫶

{
  "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

Figure 7 shows an example of the same policy but with IPv6 prefixes 💜

{
  "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)

Acknowledgments 💖

okay the people who helped make this happen deserve a whole parade 🎀 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 🌸

Huge 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 🙌

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 🧠

Thanks to Mahesh Jethanandani for the AD review ✨

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 👑

Authors' Addresses 🎀

Here are the people behind the document, with their addresses 💌

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
📦 where this page comes from