Summary

  • RFC 10065, published in October 2026 as a Proposed Standard, extends the IETF ACL YANG model with endpoint-group matches and rules that apply for a set period or on a recurrence.
  • Its RADIUS User-Access-Group-ID attribute gives an authenticated user's group a defined place in the policy chain. The mapping from that group to packet fields or device-level enforcement remains a deployment job.

The rule can have office hours

Imagine a maintenance account that should reach a management subnet only during a 90-minute service window. An ordinary access list can match addresses and ports; RFC 10065 adds a way to express who belongs to an endpoint group and when an access-control entry takes effect. The rule can use a fixed period or a recurrence. Leave the schedule out, and the entry is immediately and always applied.

That last default is the sort of small line that becomes expensive when copied into a template. A time condition is a control only if the configured condition reaches the device that enforces it.

RFC 10065 extends the existing IETF model for access-control lists. Its User-group-based Control List module can match a source or destination endpoint-group identifier and can attach a date-and-time schedule to an individual entry. The two schedule forms reuse RFC 9922: a period, or a recurrence. The shared model includes a time-zone identifier where one is needed.

For people-based access, the document defines User-Access-Group-ID as RADIUS attribute 241.12. A RADIUS server can return one or more group IDs in an Access-Accept after authentication. An Access-Request may carry the attribute as a preference, but the server does not have to honour it. The distinction keeps the login request from choosing its own permissions.

The string is the easy part

The path from login to packet is longer. A user authenticates at a Network Access Server; an authentication, authorization and accounting server assigns a group; then a controller or enforcement device must relate that group to the traffic it sees. RFC 10065 describes two broad options. A controller can map the group to packet fields such as an IP address or five-tuple, then install conventional ACL rules at enforcement points. Or a device can match the group directly, if its software or hardware supports the feature.

The standard does not define the group-to-packet mapping or the exact notification that carries it to a controller. It explicitly tells operators to check mapping consistency when several mechanisms coexist. A user's group can also change when the attributes used to classify that user change. One clean RADIUS response is not a permanent identity binding.

The trade-off is practical. Controller-side translation can keep older enforcement points using familiar address rules, but it has to track identity, address and policy changes. Direct group matching can avoid frequent controller updates when a user or workload moves, but it requires capable devices and may affect forwarding performance. RFC 10065 says some equipment may need software or hardware upgrades; it does not report an adoption count or measured performance result.

The new schedule field also creates a management boundary. RFC 10065 warns that an unauthorized writer could alter a group's membership, its match criteria or the schedule itself. Reading the schedule can reveal when a rule is active. A clock beside an ACL is useful; a clock whose settings nobody can audit is another access path.

The next useful evidence is a device or controller declaring which group-match and schedule features it supports, followed by a trace that shows the returned group, the installed rule and the rule's state at the window's start and end. Until then, RFC 10065 is a common vocabulary for timed group policy. The map and the enforcement still belong to the operator's running systems.

Sources