Summary

  • Revision 15 of the OPSAWG UCL draft defines a YANG extension for group-based ACLs, schedule-aware ACEs and a RADIUS User-Access-Group-ID. It is in the RFC Editor queue but is still an Internet-Draft, not an RFC or deployment result.
  • A Group ID can simplify policy administration without proving the chain from authentication through mapping, ACL distribution and activation to packet handling. A NAS accounting assertion is one receipt inside that chain, not the verdict for all PEPs.

The post-change report looked reassuring. Authentication had succeeded. The Access-Accept contained a User-Access-Group-ID. An Accounting-Request later carried the same value, allowing the Network Access Server to acknowledge that it had received the attribute and was enforcing the policy. The change record turned green.

Packets from the user were still crossing a firewall that had retained yesterday's mapping.

Nothing in that sequence requires the NAS to lie. The accounting record can accurately describe what the NAS knows and does. The error begins when a system promotes that local assertion into a proof about every Policy Enforcement Point, every mapping from group to packet fields, every active schedule and the resulting service outcome.

Revision 15 of A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control makes this boundary unusually visible. The draft defines an ietf-ucl-acl YANG module that extends the RFC 8519 ACL model. It adds endpoint groups, source and destination Group-ID matches, and effective schedules. It also defines a RADIUS User-Access-Group-ID for user-centric access control triggered by authentication.

The document is close to publication. Datatracker places it in the RFC Editor queue, in final review, with IANA review complete and actions required. It is an OPSAWG working-group document in the IETF stream intended for Proposed Standard. Revision 15 is dated 2 April 2026 and expires on 4 October 2026. It has no RFC number. Its maturity deserves attention, but “near RFC” is not the same proposition as “RFC,” and neither status would prove a particular network installed or enforced the model.

The draft's abstraction is attractive for a real reason. Endpoints move. IPv6 temporary addresses rotate. NAPT breaks a simple one-to-one relationship between an identity and an address. Applications migrate among virtual machines and containers. Maintaining policy only as IP addresses and transport coordinates makes control brittle. A durable group reference can separate an intended policy from a volatile location.

That separation does not remove the volatile mapping. It moves it.

One identifier sits above several changing links

The draft allows endpoint groups for users, devices and applications. A group-id is a string; its group-type is separate. A controller can maintain group-based ACLs, map the group to packet attributes, act as a Policy Decision Point and push policies to relevant Policy Enforcement Points. The architecture explicitly allows multiple PEPs.

There are two broad deployment choices. At the administrative-domain level, a controller dynamically maps the Group ID to ordinary IP or transport fields such as a five-tuple and programs conventional ACLs. The PEP need not understand the group abstraction. At the device level, a PEP can understand group identity and map incoming packets to source or destination groups itself. That may require dedicated hardware or software and may affect forwarding performance.

Both choices are legitimate. They create different evidence requirements.

In the controller-expansion model, the durable symbolic object is translated into short-lived coordinates. An installation receipt should identify the subject, Group ID, mapping revision, resulting packet fields, ACL revision, target PEP, activation time and device response. If a user reconnects or a VM moves between the mapping calculation and installation, a perfectly valid ACL can enforce a stale identity projection.

In the device-level model, the PEP needs a trustworthy way to derive the group from a packet or current context. The draft notes that a packet tag does not need to mirror the Group-ID string and leaves the mapping from the string to a tag or header field outside scope. RFC 9638's Group Policy Option is an example, not a universal binding. A trace showing the tag arrived still needs the mapping version that says what the tag meant at that moment.

Section 8.3 does not hide the problem. It calls for adequate setup to map a Group ID to packet fields and says special care is needed to ensure the mapping is appropriately enforced when distinct mechanisms, including RADIUS, are supported. That sentence is not an implementation recipe. It is a warning that semantic consistency crosses system boundaries.

A request hint is not the server's decision

The RADIUS attribute has packet-specific semantics. User-Access-Group-ID may appear in an Access-Accept. When it does, the related access control is applied after authentication. It may also appear in an Access-Request, but there it is only a hint expressing a preference. The server is not required to honor it.

This distinction can disappear in event pipelines that flatten every occurrence into the same field. If a dashboard joins messages by username and retains only group=engineering, it may no longer reveal whether the value came from a requester or from the authority that accepted the session. A downstream policy process can then turn a preference into an entitlement.

The minimum record must preserve packet type, direction, RADIUS client and server identities, request and response identifiers, authentication session, attribute occurrence and decision status. The Access-Accept value can supersede a request hint for that exchange; silence from the server must not be interpreted as implicit acceptance.

An Access-Reject or Access-Challenge cannot carry this attribute under the proposed table. Nor can CoA-ACK or CoA-NACK. The absence of the value in those packets is not a membership statement. It follows the attribute-placement contract.

The draft also permits multiple instances in Access-Accept, meaning the user belongs to many groups. That is valuable expressiveness, but it does not establish a universal rule for conflicts among ACLs. One group may allow a destination while another denies it; schedules may overlap; device vendors may compose entries differently unless the complete ACL semantics and ordering are fixed. A log that stores one winning group discards the evidence needed to reconstruct why a packet was permitted.

CoA turns consistency into a race

User-Access-Group-ID may appear in a Change-of-Authorization request. CoA is where the difference between a correct decision and a completed change becomes impossible to ignore.

Suppose a user moves from contractor to incident-responder during an active session. The AAA server sends a CoA-Request. The NAS updates its context and responds through the ordinary CoA protocol. A controller recalculates mappings. Three PEPs need new policy. The first applies it immediately, the second waits for its transaction queue, and the third is offline.

Which group is the user in?

At the institutional layer, the authoritative assignment may have changed. At the AAA layer, the CoA may have been emitted. At the NAS, session state may be new. At the controller, one mapping revision may be current. At each PEP, installed state can differ. In the data plane, packets can traverse different devices and receive different outcomes. A single group_current=true field cannot faithfully represent all of those facts.

The safe state machine should expose partial convergence. It should know the intended PEP set, record each distribution attempt, validate the candidate configuration, obtain installation and activation receipts, and keep unknown or degraded status until the required set is complete. A CoA acknowledgement is not an excuse to hide a missing PEP receipt.

Failure policy must be explicit. Some changes should fail closed; others should preserve the previous policy to avoid an outage. The choice depends on the rule, subject and service. What matters is that “preserved old policy,” “blocked pending convergence” and “new policy active” remain distinct outcomes rather than one generic success.

An accounting assertion is evidence from one observer

The draft says User-Access-Group-ID may appear in an Accounting-Request and may be used by a NAS to acknowledge receipt of the attribute and that the NAS is enforcing the policy. That is a useful protocol-level statement. It can tie accounting to the group used by the NAS.

Its scope still matters. The speaker is the NAS. The record says what that NAS asserts. It does not independently sample packets. It does not enumerate every external firewall, fabric switch or service gateway that may also be a PEP. It does not include the controller's mapping revision or prove that a schedule has become effective everywhere. It does not show whether a permitted connection delivered an application response.

This is not an argument to distrust accounting. It is an argument to retain provenance. A high-quality audit can say: the AAA server authorised groups A and B; the NAS reported that it received and enforced them; controller revision 417 mapped the session to these coordinates; PEPs 1 and 2 acknowledged ACL revision 902; PEP 3 was unavailable; counters at 1 and 2 matched packets; the application probe succeeded through path 1; path 3 remained unknown.

That account is more cautious than one green icon. It is also more useful. It localises the missing evidence instead of treating all disagreement as fraud or all acknowledgement as reality.

Schedules add a clock to the policy boundary

The YANG extension lets an ACE have an effective schedule. It can use a period or an iCalendar-style recurrence from RFC 9922. If no schedule is configured, the ACE is immediately and always applied.

Schedule awareness solves a practical problem: some access should exist only during a maintenance window, business interval or temporary response period. It also adds clock, time-zone, recurrence and exception-date semantics to the execution chain.

A configuration readback can prove that a PEP stores the intended schedule. It cannot by itself prove the rule was active for a packet at 01:59:59 after a clock adjustment or at a daylight-saving transition. Distributed enforcement needs a declared time source, time-zone identifier, clock-health evidence and observation of the active rule. If one PEP interprets or activates a boundary later than another, the Group ID remains identical while access differs.

The draft's security considerations note two directions of risk. Unauthorized write access to the effective schedule can cause service disruption or unavailability. Unauthorized read access can reveal when rules apply and help an attacker craft activity. The schedule is therefore not harmless metadata. It is sensitive control information whose confidentiality and integrity matter separately.

An audit should not publish operational windows casually. Public evidence can state that schedule controls exist and were verified without exposing a live exception calendar. Internal receipts can retain exact recurrence, time zone, activation result and authorised change.

Formal validity is not operating proof

Datatracker records zero YANG validation errors and zero warnings for revision 15. That is valuable evidence that the module passed the recorded formal checks. It does not show that a controller implements every feature correctly, that two vendors interpret the same schedule identically, or that packets saw the configured action.

The revision 14-to-15 diff is similarly bounded. It updates the date and expiry, improves wording, expands an acronym and points the security template to RFC 9907. It does not add an interoperability test or measured deployment. A responsible publication should celebrate precision without inventing operational results.

The module relies on NETCONF or RESTCONF-style management. Its security section requires secure transport and mutual authentication and points to NACM for restricting users and operations. These protections establish who may read or write configuration. They do not prove that an authorised write expressed the right institutional decision or that the device produced the desired service state.

Unauthorized access to the endpoint-group list can forge or delete groups. Unauthorized changes to Group-ID match criteria can permit traffic that should be denied or deny traffic that should be allowed. Those are direct examples of symbolic records acquiring operational power. Authentication protects the write path; evidence must still bind the write to approved intent, exact state and observed result.

RADIUS transport has its own boundary. The draft assumes a trusted client/server relationship and refers to optional IPsec or TLS protection, while current RADEXT work is moving away from insecure practices and refining RadSec. Transport confidentiality and integrity matter. Even a perfectly protected RADIUS message, however, proves only that the protected message was exchanged. It does not cause every downstream mapping and PEP to agree.

The minimum enforcement receipt

A reusable receipt begins before the Group ID appears. It records the authenticated subject, session and relevant context. It identifies the authority that assigned each group and the version of the decision. It distinguishes a request hint from an accepted value and retains all groups rather than a convenient winner.

Next it records the mapping. For controller expansion, that means the Group ID, mapping revision, source data, five-tuple or address set, validity interval and migration trigger. For tag-based enforcement, it means the Group ID-to-tag binding, encapsulation context and trust boundary. For device-local classification, it means the classifier version and inputs.

Then it records the policy: ACL revision, source and destination group references, action, precedence, conflict handling, effective schedule, time-zone basis and exception set. The receipt should name the target PEP set and explain why each device belongs in it.

Distribution needs one result per PEP. sent is not validated; validated is not installed; installed is not active. Transaction or commit identifiers, readback hashes and activation times prevent a central controller from reporting intent as fleet state.

Finally, observation must remain separate. Packet counters, sampled flows, denied and permitted traces, path-specific probes and application outcomes answer progressively broader questions. A counter increment can show that one rule matched. It does not prove that all legitimate traffic worked or that every prohibited path was blocked. The receipt should preserve uncertainty instead of filling missing layers with inference.

A small specification can prevent a large fiction

Heng Lu's Minimum Initial Specification principle does not require every network to use one controller or packet tag. It suggests a smaller common contract: subject, authoritative group decision, mapping version, ACL and schedule revision, target PEP set, per-PEP state and observed outcome. Local systems can implement those fields differently while keeping the handoff testable.

Reality-layer discipline explains why the contract matters. The Group ID is a symbolic reference. The AAA decision and ACL are institutional and control records. The installed rule is executable state. The packet and service result are observed reality. Each layer can be valid while the next is stale, incomplete or contradictory.

Running-Code Primacy supplies the test suite. Rotate an IPv6 address during a session and watch the mapping. Move a VM before all conventional ACLs update. return several groups with conflicting rules. Send a CoA while one PEP is unavailable. Cross a recurrence boundary with clock skew. Restart the controller between distribution and acknowledgement. Preserve the differences in the result instead of grading only the happy path.

The draft gives operators a useful abstraction and a serious warning. Group identity can reduce the cost of maintaining policy under mobility. The price of that abstraction is not blind trust; it is explicit mapping provenance and distributed execution evidence.

The accounting record in the opening incident should remain in the audit. It proved something important: the NAS said it received the Group ID and was enforcing policy. The packet trace proved something else: another enforcement point had not joined that reality. Good governance does not choose one record and discard the other. It preserves the boundary until the system can explain both.

Sources