]> Huawei

101 Software Avenue, Yuhua District Jiangsu 210012 China maqiufang1@huawei.com

Huawei

101 Software Avenue, Yuhua District Jiangsu 210012 China bill.wu@huawei.com

Orange

Rennes 35000 France mohamed.boucadair@orange.com

Lancaster University

United Kingdom d.king@lancaster.ac.uk

Operations and Management OPSAWG ACL Policy-based BYOD Access control This document defines a YANG data model for policy-based network access control, which provides 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. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease 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, the 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. Discussion Venues Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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

• Endpoints do not have stable and unique IP addresses. For example, Wireless LAN (WLAN) and VPN clients, as well as back-end Virtual Machine (VM)-based servers, can move; their IP addresses could change as a result. Furthermore, mechanisms such as IPv6 temporary addresses , and Network Address Port Translation (NAPT) 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.
• 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 users' access location, source network reputation, users' role, time-of- day, type of network device used (e.g., corporate-issued device versus personal device), device's security posture, etc. This means that the network needs to recognize the endpoints' identity and their current context, and map the endpoints to their correct access grant to the network.

This document defines a YANG data model () for policy-based network access control, which extends the IETF Access Control Lists (ACLs) module defined in . 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. The ACL concept has been generalized to be device-nonspecific, and can be defined at network/administrative domain level . To allow for all ACL applications, the YANG module for policy-based network ACL defined in does not 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., MAC address) to execute the policy-based access control. Additionally, the 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 (). Although the document cites MAC addresses as an example in some sections, the 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 . The document does not specify how to map the policy group identifiers to dedicated packet fields. Group-Based Policy (GBP), discussed in , provides an example of how that may be achieved.

Editorial Note (To be removed by RFC Editor) Note to the RFC Editor: This section is to be removed prior to publication. This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Please apply the following replacements:

• XXXX --> the assigned RFC number for this document
• 2026-01-12 --> the actual date of the publication of this document

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 when, and only when, they appear in all capitals, as shown here. The meanings of the symbols in tree diagrams are defined in . The document uses the following terms defined in :

• 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 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 deliver 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), etc.

While a personal device (BYOD) is not a physical asset of the enterprise, it is subject to the enterprise' access control policies when accessing the enterprise resources controlled by the centrally managed authority.

Endpoint:

Refers to an entity which could be an end-user, enterprise device, or application that actually connects to a network.

Endpoint group:

Refers to 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 for more details.

device group:

A collection of enterprise devices that share a common access control policies. Refer to for more details.

Application group:

A collection of applications that share a common access control policies. An application is a software program used for a specific service. Refer to 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 . 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 .

Sample Usage Access to some networks (e.g., enterprise networks) requires recognizing the endpoints' identities no matter how, where, and 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 , 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 the ACL resources. The network ACLs can be provisioned on devices using specific mechanisms, such as or . 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 () and policing () during peak hours in order to not affect other data services.

Policy-based Network Access Control

Overview An example architecture of a system that provides real-time and consistent enforcement of access control policies is shown in . This architecture illustrates a user-centric flow, which includes the following functional entities and interfaces:

• A service orchestrator which 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) controller which 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) and pushes the required access control policies to relevant Policy Enforcement Points (PEPs) . A PDP is also known as "policy server" . An SDN controller may interact with an Authentication, Authorization, and Accounting (AAA) server or a Network Access Server (NAS) .
• A NAS entity which handles authentication requests. The NAS interacts with an AAA server to complete user authentication using protocols like RADIUS . 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. A new RADIUS attribute is defined in for this purpose.
• 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).
• The Policy Enforcement Point (PEP) is the central entity which 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 packet header fields based ACL policies 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 acts upon the endpoint-group ID-based ACL policies (e.g., a group identifier may be carried in packet headers such as discussed in ). Multiple PEPs may be involved in a network. A PEP exposes a YANG-based interface (e.g., NETCONF ) to an SDN controller.

provides the overall architecture and procedure for policy-based access control management.

An Example Architecture for User Group-based Policy Management

In reference to , the following typical flow is experienced:

Step 1:

Administrators (or a service orchestrator) configure an SDN controller with network-level ACLs using the YANG module defined in . An example is provided in .

Step 2:

When a user first logs onto the network, they are required to be authenticated (e.g., using username and password) at the NAS.

Step 3:

The authentication request is then relayed to the AAA server using a protocol such as RADIUS . 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., 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 ). If the authentication fails, the user is not assigned any user group, which also means that the user has no access (i.e., Access-Reject 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 that IP address are discarded (or rate-limited) by the network.

In some implementations, the AAA server can be integrated with an SDN controller.

Step 4:

Either the AAA server or the NAS notifies an 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 scope of this specification.

Step 5:

Either group-based or packet header field-based access control policies are maintained on relevant PEPs under the SDN controller's management. Both types of ACL policy may exist on the PEP. and 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 (). provides additional operational considerations.

Endpoint Group

User Group The 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 their composite attributes, environment, and/or local enterprise policy change. A user is authenticated, and 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. 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, 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 user groups R&D Regular and R&D BYOD may share the same set of users that belong to the R&D organization, and differ only in the type of clients (firm-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. User Group Examples

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

Device Group The device group ID is an identifier that represents the collective identity of a group of enterprise devices. shows an example of how device group definitions may be characterized. Device Group Example

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

Matching abstract device group ID instead of specified addresses in ACL polices helps shield the consequences of address change (e.g., back-end VM-based server migration).

Application Group An application group is a collection of applications that share a 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 application group eases the process of application migration. For example, the policy does not depend on the transport coordinates (i.e., 5-tuple). shows an example of how application group definitions may be characterized. Application Group Examples

Group Name	Group ID	Group Description
Audio/Video Streaming	baz-70	Audio/Video conferencing application
Instant Messaging	baz-80	Messaging application
document Collaboration	baz-90	Real-time document editing application

Relations Between Different Endpoint Groups Policies 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.

The UCL Extension to the ACL Module

Module Overview This module specifies an extension to the "ietf-access-control-list" module . This extension adds endpoint groups so that an endpoint group identifier can be matched upon, and also enable access control policy activation based on date and time conditions. provides the tree structure of the "ietf-ucl-acl" module.

UCL Extension

The first part of the "ietf-ucl-acl" module augments the "acl" list in the "ietf-access-control-list" module with an "endpoint-groups" container having a list of "endpoint group" inside, each entry has a "group-id" that uniquely identifies the endpoint group and a "group-type" parameter to specify the endpoint group type.

• "group-id" is defined as a string rather than unsigned integer (e.g., uint32) to accommodate deployments which 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 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 so that a source and/or destination endpoint group index can be referenced as the match criteria. The third part of the module augments the "ace" list in the "ietf-access-control-list" module with date and time specific parameters to allow ACE to be activated based on a date/time condition. Two types of time range are defined, which reuse "recurrence" and "period" groupings defined in the "ietf-schedule" YANG module in , respectively.

The "ietf-ucl-acl" YANG Module This module imports types and groupings defined in the "ietf-schedule" module . It also augments the "ietf-access-control-list" module (). file "ietf-ucl-acl@2026-01-12.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 OPSWG Working Group"; contact "WG Web: WG List: OPSAWG Editor: Qiufang Ma Author: Qin Wu Editor: Mohamed Boucadair Author: Daniel King "; description "The User group-based Control List (UCL) YANG module augments the IETF Access Control Lists (ACLs) module and 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 XXXX; see the RFC itself for full legal notices."; revision 2026-01-12 { description "Initial revision."; reference "RFC XXXX: 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 "Eth 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 "Eth, 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 "Eth, 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 "Eth, 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 identity, which can represent the collective identity of a group of authenticated users, end-devices, or applications. An endpoint group identity may be carried in the outer/inner packet header (e.g., via 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 identities, 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 identities, 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 identities, 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 identities, 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 identities, 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 identities, 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 identities, 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 endpoint group type."; } } } } 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 index 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 types."; leaf source-group-id { type group-id-reference; description "The matched source endpoint group ID."; } 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 condition. If it is not configured, the access control entry 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; } } } } } ]]>

User Access Control Group ID RADIUS Attribute This section defines a 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 group or application group, the identifiers are typically pre-provisioned on the SDN controller based on an inventory or an application registry. The User-Access-Group-ID RADIUS attribute is defined with a globally unique name. The definition of the attribute follows the guidelines in . When the User-Access-Group-ID RADIUS attribute is present in the RADIUS Access-Accept, the system applies the related access control to the users after the user authenticates. The User-Access-Group-ID Attribute is of type "string" as defined in . The User-Access-Group-ID 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 Attribute appears in a RADIUS Access-Accept packet, this means that the user is a member of many groups. The User-Access-Group-ID Attribute MAY appear in a RADIUS CoA-Request packet. The User-Access-Group-ID 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-Request and the NAS is enforcing that policy. The User-Access-Group-ID Attribute MUST NOT appear in any other RADIUS packet. The User-Access-Group-ID Attribute is structured as follows:

Type

TBA1

Length

This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and the "Value".

The Length MUST be at most 67 octets. The maximum length is 67 octets to accommodate the maximum group ID of 64 octets plus one octet for Type, one octet for Length, and one octet for Extended-Length.

Data Type

string ()

Value

This field contains the user group ID.

RADIUS Attributes provides a guide as what type of RADIUS packets that may contain User-Access-Group-ID Attribute, and in what quantity. Table of Attributes

Access-Request	Access-Accept	Access-Reject	Access-Challenge	Attribute
0+	0+	0	0	User-Access-Group-ID
Accounting-Request	CoA-Request	CoA-ACK	CoA-NACK	Attribute
0+	0+	0	0	User-Access-Group-ID

Notation for :

0

This attribute MUST NOT be present in packet.

0+

Zero or more instances of this attribute MAY be present in packet.

Operational Considerations

Deployment Options The UCL model can be implemented in different ways. In some cases, the UCL data model is implemented at the network/administrative domain level with an SDN controller maintaining the dynamical mapping from endpoint group ID to IP/transport fields (e.g., the 5-tuple) and programing the PEPs with IP address/5-tuple based ACLs. In such cases, PEPs do not require to implement specific logic (including hardware) compared to the enforcement of conventional ACLs. 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 which acquires the source and/or destination endpoint group ID from the AAA server, ACL policy enforcement based on the group identity without being encapsulated into packet headers might affect the forwarding performance. Implementations need to evaluate the operational tradeoff (flexibility brought to the network vs. the complexity of implementation) carefully. Such assessment is out of scope for this document.

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 feature by involved PEPs.

Mapping Consistency The specification requires that adequate setup is put in place to map a Group ID to packets 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 network.

Security Considerations

YANG This section is modeled after the template described in . 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) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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 endpoint group index as match criteria in the ACEs. Unauthorized write access to this data node may allow intruders to modify the group identity 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 secheduling 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 must be implemented for write operations on this subtree to ensure that only authorized users can modify it.

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. An unauthorized read access of the list will allow the attacker to determine which rules are applied, to better craft an attack.

RADIUS RADIUS-related security considerations are discussed in . An effort to deprecating insecure practices in RADIUS is provided in . 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) .

IANA Considerations

YANG This document registers the following URIs in the "IETF XML Registry" . This document registers the following YANG modules in the "YANG Module Names" registry .

RADIUS This document requests IANA to assign a new RADIUS attribute type in the 241-245 range from the IANA registry "Radius Attribute Types" : RADIUS Attribute

Value	Description	Data Type	Reference
TBA1	User-Access-Group-ID	string	This-Document

References Normative References This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines common types and groupings that are meant to be used for scheduling purposes, such as events, policies, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling statuses. The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References IANA This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community. RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability. This document also creates initial versions of IANA-maintained modules for ICMP types and IPv6 extension headers. To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the purpose of MAC address randomization. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency. The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 Working Group starting from the output of the NVO3 encapsulation Design Team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats. There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, Operations, Administration, and Maintenance (OAM) functions such as path MTU discovery become challenging with multiple encapsulations along the data path. Based on these considerations, the NVO3 Working Group determined that Generic Network Virtualization Encapsulation (Geneve) with a few modifications is the common encapsulation. This document provides more details, particularly in Section 7. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community. This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK] In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] InkBridge Networks RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks, and have recently been standardized in [I-D.ietf-radext-radiusdtls-bis]. TLS has proven to be a useful replacment for UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. YumaWorks Orange Huawei This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK] Deutsches Forschungsnetz | German National Research and Education Network Painless Security Fondation Restena | Restena Foundation This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. Cisco Systems Arrcus, Inc. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Tenant System Interface (TSI) Group Identifier to be carried for the purposes of policy enforcement. Huawei Goldman Sachs France Telecom France Telecom Huawei Huawei F5 Networks This draft defines the User-group Aware Policy Control (UAPC) framework, which facilitates consistent enforcement of security policies based on user group identity. Policies are used to control security policy enforcement using a policy server and a security controller. Northbound APIs are also discussed. Huawei Technologies Huawei Technologies Huawei Technologies This document defines the autonomic technical Objectives for IP address/prefix to access control group IDs mapping information. The Objectives defined can be used in Generic Autonomic Signaling Protocol (GRASP) to make the policy enforcement point receive IP address and its tied access control groups information directly from the access authentication points and facilitate the group based policy enforcement.

Examples Usage

Configuring the Controller Using Group based ACL Let's consider an organization that would like to manage the access of R&D employees that bring personally owned devices (BYOD) into the workplace. The access requirements are as follows:

• Permit traffic from R&D BYOD of employees, destined to R&D employees' devices every work day from 8:00:00 to 18:00:00 UTC, starting in January 1st, 2026.
• Deny traffic from R&D BYOD of employees, destined to finance servers located in the enterprise DC network starting at 8:30:00 of 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.

The example shown in illustrates the configuration of an SDN controller using the group-based ACL:

Example of UCL Configuration

Configuring a PEP Using Group-based ACL This section illustrates an example to configure a PEP using the group-based ACL. The PEP which enforces group-based ACL may acquire group identities from the AAA server if working as a NAS authenticating both the source endpoint and the destination endpoint users. Another case for a PEP enforcing a group-based ACL is to obtain the group identity of the source endpoint directly from the packet field . Assume the mapping between device group ID and IP addresses is predefined or acquired via device authentication. shows the ACL configuration delivered from the controller to the PEP. This example is consistent with the example presented in . 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.

Example of PEP Configuration

shows an example of the same policy but with a destination IPv6 prefix.

Example of PEP Configuration (ipv6)

Configuring PEPs Using Address-based ACLs The section describes an example of configuring a PEP using IP address based ACL. IP address based access control policies could be applied to the PEP that may not understand the group information (e.g., firewall). 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 address according to steps 1 to 4 in . Assume the mapping between device group ID and IP addresses is predefined or acquired via device authentication. shows an IPv4 address based ACL configuration delivered from the controller to the PEP. This example is consistent with the example presented in .

Example of PEP Configuration

shows an example of the same policy but with a destination IPv6 prefix.

Example of PEP Configuration (IPv6)

Acknowledgments This work has benefited from the discussions of User-group-based Security Policy over the years. In particular, and provided 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. 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 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, and Ketan Talaulikar for the IESG review.