Summary

  • RFC 3169 treated information from a Network Access Server (NAS) as evidence or a “hint,” not a command; the AAA server made the final authorization decision.
  • The decision still had to be applied at the NAS, while allocation state, accounting records and delivered service remained separate things to verify.

The distinction appears in a document that is easy to mistake for a standard. Published in September 2001, RFC 3169 is Informational and says directly that it does not specify an Internet standard. Its title, “Criteria for Evaluating Network Access Server Protocols,” signals an evaluative checklist, not a new packet format. The paper divides NAS protocols into access, network, AAA and device-management spaces, concentrating on AAA. Its model includes equipment that aggregates dial, broadband and tunnel-based sessions, potentially serving thousands of connections.

The striking part is not the size of the list but its assignment of decision rights. In its authorization section, RFC 3169 says information the NAS sends to the AAA server must be treated as “hints,” not directives. The server makes the final authorization decision and should not rely on a particular state merely because the NAS expects it. This rule resists a common category error: the edge device reports facts about a session, but that report does not itself authorize the session.

Yet a server-side decision is not an applied policy. RFC 3169 describes authorization profiles that the protocol conveys so the NAS can enforce them. The AAA server can say what policy permits; the NAS must still install or apply the profile in its own operating context. A correct Access-Accept, policy response or dynamic authorization message is therefore evidence of a decision or request, not proof that the relevant interface changed state, a filter took effect or the user obtained working service.

The resource-management clauses make that gap concrete. RFC 3169 envisions allocating and deallocating shared resources during a session, including addresses, concurrent-use limits, ports and tunnels. It says this function is primarily aimed at NAS-local resources. In a proxy or multi-domain arrangement, the server that allocated a remote-domain resource—and perhaps its backups—should retain its resource information. Remote authorization changes should use dynamic authorization functions. The memo is separating who decides from who currently holds the ledger needed to reclaim or restore a resource.

That separation has operational consequences. If a server fails over, preserving authorization policy alone may not reconstruct a tunnel limit or address pool held by an allocating service. If a NAS restarts, its local view may no longer match the allocator’s record. A disconnect request may be delivered without being executed. RFC 3169 consequently calls for synchronization and recovery features and warns against relying on the accounting message stream for resource-management state. An accounting pipeline can report usage; it is not automatically the authoritative lock table for a live allocation.

Accounting is a fourth evidence path, not a substitute for the other three. RFC 3169 asks for delivery mechanisms for records, calls for real-time accounting to begin within one second of the triggering event, and specifies unambiguous timestamps. Those are requirements written for protocol evaluation. They do not show that a packet was delivered, that every event was captured, or that a later consumer reconstructed the correct session. Real-time receipt is not the same as real-time ground truth.

The surrounding protocol history shows why the checklist matters without proving that any successor passed it in full. RADIUS already provided separate authentication/authorization and accounting specifications. RFC 3169 asks candidate AAA protocols to handle their attributes and accounting sets, interoperation, extensibility, multiple servers and multi-domain relationships. Diameter, published later in RFC 6733, describes itself as a base protocol for AAA applications; dynamic authorization, EAP carriage and transport protection also evolved through separate specifications.

Their existence is not a compliance audit against every RFC 3169 requirement. Even later RADIUS design guidance recognized wire-size and data-model constraints rather than treating a very large attribute space as an unlimited implementation promise.

Read as history, RFC 3169 is a map of control boundaries. The NAS can contribute session evidence; the AAA server has the final authorization role; the NAS enforces; a resource allocator owns current allocation state; and accounting supplies a separate record. Those actors may communicate in one protocol family, but no single message proves the whole chain. This account makes no claim about adoption rates, products or present deployment. It follows the memo’s narrower lesson: a central decision is only one receipt in a distributed operation.

Sources: RFC 3169; RFC 3169 current record; RFC 3169 Datatracker record; RFC 2881 NAS model; RFC 2865 RADIUS; RFC 2866 RADIUS Accounting; RFC 2869 RADIUS Extensions; RFC 2989 AAA protocol evaluation; RFC 3579 EAP in RADIUS; RFC 5176 Dynamic Authorization; RFC 6158 RADIUS Design Guidelines; RFC 6614 RADIUS over TLS; RFC 6733 Diameter Base Protocol; RFC 9765 RADIUS/1.1; Lu Heng, “When the Bookkeeper Auditions for Olympus”.