Summary

  • RFC 10065 adds group-based matching and time conditions to YANG access-control lists, and defines a RADIUS attribute for carrying a user-group identifier.
  • The identifier does not settle who assigned the group, how it maps to packet fields, or whether every enforcement point applied the intended rule.

Analysis

An address is a poor long-term proxy for a person, device or workload when that endpoint moves. VPN users roam, virtual machines migrate, IPv6 addresses can change, and several endpoints may sit behind translation. An ACL tied to an address or five-tuple can still work, but administrators have to keep the rule aligned with a changing endpoint. RFC 10065 addresses that maintenance problem by making endpoint groups a reusable policy handle.

The specification extends the YANG ACL model in RFC 8519. Its ietf-ucl-acl module can define user, device and application groups, give each group an identifier, and let an ACL entry match the source or destination group. It also adds an effective-schedule with either a period or recurrence, reusing the common YANG schedule model in RFC 9922. One default matters operationally: if no schedule is configured, the access-control entry applies immediately and remains in effect.

For user access, the new User-Access-Group-ID RADIUS attribute carries the group identifier in the authentication path. RFC 10065 assigns it extended attribute 241.12 and defines it as a string, with a maximum group-ID value of 64 octets. An Access-Accept may return one or more group IDs after authentication. An Access-Request may include a preferred ID, but the server does not have to honor it. The attribute may also appear in a Change-of-Authorization request or an Accounting-Request. In the latter, a NAS can acknowledge that it received the attribute and is enforcing the policy.

That packet is one link in a longer chain. The AAA server classifies the user under locally configured criteria. A controller may then map the group ID to packet fields and program policy-enforcement points with ordinary address- or five-tuple-based ACLs. Another design lets the enforcement device match group IDs directly. The first can avoid custom group-processing logic on every device, but it depends on timely controller updates. The second can reduce repeated controller interaction, but devices may need software or hardware support; direct enforcement at a NAS can also affect forwarding performance.

The distinction matters because the RFC defines the interface, not an enterprise's identity authority. It does not prescribe the authentication method, the evidence needed to place someone in a group, or the mapping from a group ID to packet fields in an encapsulation. It says that this mapping must be adequately set up and warns operators to keep it consistent when several mechanisms, including RADIUS, coexist. A group label is therefore not a portable proof of identity or entitlement. Its meaning depends on the local assignment and mapping that consume it.

RFC 10065 also makes the configuration surface consequential. The endpoint-group list, group match criteria and schedules are writable YANG data. Unauthorized changes could create or remove a group, permit traffic that should be denied, block traffic that should be allowed, or move a rule into the wrong time window. Read access to schedules can reveal when a rule is active. The RFC calls for secure, mutually authenticated NETCONF or RESTCONF management and points to NACM for limiting what each operator can read or change. For RADIUS, it assumes a trusted client-server relationship; IPsec or TLS protection is described as optional.

The standard is a Proposed Standard, not evidence of deployment. Its value is a common control vocabulary for shifting endpoints and time-bound policy. The operational question is whether each local system can preserve the relationship among authentication, group assignment, policy mapping, rule installation and observed traffic.

Sources