Summary

  • RFC 10065 makes a group identifier portable across RADIUS and YANG access-control models, but it does not define a global group namespace or membership authority.
  • The operational test is whether AAA, the controller and every enforcement point use the same current mapping from that identifier to traffic.

A user authenticates to a network, receives a group label, and then reaches a policy enforcement point. Somewhere between those steps, the label has to become a decision about packets. RFC 10065 gives the network a common way to model that path. It does not make the label self-explanatory.

That distinction is the standard’s central deployment boundary. The identifier can travel between systems; the meaning attached to it, and the evidence that each device applies the same meaning, remain operational work.

What the standard carries

RFC 10065 defines the User-group-based Control List YANG module, which augments the IETF ACL model. It adds endpoint groups and lets access rules match source or destination groups, with optional combinations of group, Ethernet, IPv4, IPv6 and transport-layer fields. A group can describe users, devices or applications. The model also permits an access-control entry to have an effective schedule, drawing on the common YANG scheduling model in RFC 9922.

For user-authenticated access, the RFC defines the RADIUS User-Access-Group-ID attribute, type 241.12. The attribute carries a string, up to 64 characters, naming the user group assigned by the AAA service. It can appear in an Access-Accept. It can also appear in an Access-Request as a preference for the server to consider; the server is not obliged to honor that hint. More than one identifier in an Access-Accept means the user belongs to multiple groups.

This can reduce the need to maintain an independent packet-address rule for every changing endpoint. A laptop that changes address need not, by that fact alone, require a new policy concept. The model can associate a group label with the packet fields or endpoint context used by the network.

Where the meaning is made

The RFC’s example flow exposes what the attribute cannot do by itself. A user authenticates at a network access server. The request reaches AAA; if accepted, AAA assigns a group ID. Either AAA or the NAS then notifies an SDN controller of the mapping between that ID and common packet-header attributes, such as a five-tuple. The controller maintains policies and programs relevant enforcement points.

RFC 10065 explicitly leaves the details of that notification out of scope. It also says that group definitions are deployment-specific. Criteria may include role, device certificate, address, location, time of day or local enterprise policy; membership can change when those inputs change. The model says how a group can be referenced. It does not establish who is entitled to define the group, how every change is propagated, or whether an identifier has the same meaning in another administrative domain.

The standard limits an identifier to a string and requires it to identify an endpoint group in the YANG model. That is a useful schema constraint, not a global naming authority. The same short value can be reused in different environments without representing the same people, devices or permissions.

Two clocks, two decisions

Time enters the model in two different places. A policy can put a schedule directly on an ACL entry: for example, allow a group’s traffic during a recurring weekday window. Separately, a deployment may use the time of day as one criterion for assigning a person to a group. One controls when a rule is effective; the other changes who the network considers to be in a group. Treating them as one switch can produce the wrong expectation at a boundary.

The model is intentionally flexible about enforcement. A controller can translate group membership into conventional packet fields and send ordinary ACLs to devices. Alternatively, a policy enforcement point may match group identifiers directly. The RFC notes that direct matching may require hardware or software upgrades and could affect forwarding performance. It supplies no measurement that would let an operator choose between those paths without local testing.

A data model can therefore align configurations while leaving important implementation choices visible. It provides common structures for groups, rule matches and schedules. It does not guarantee that every vendor supports the same feature combinations, update timing or device-level enforcement path.