Summary

  • RFC 5176 lets a Dynamic Authorization Client disconnect or change sessions already in progress, but a valid packet can match no session, one session or several. If several match, the requested change is an all-or-none operation across that entire set.
  • An ACK is meaningful: it is the NAS assertion that the requested transition succeeded. It is not, however, an independent measurement of accounting convergence, downstream enforcement or the subscriber's traffic. NAK is equally non-binary: Error-Cause 507 means another authorization exchange was successfully initiated.

The request arrived with a valid authenticator. That sentence is often allowed to settle three other questions it never answered. Was this sender entitled to alter this subscriber? Which live session did the attributes identify? Did the operational effect persist beyond the RADIUS-speaking device?

RFC 5176 exists in the uncomfortable space between login-time authorization and a network that changes while a user remains connected. Its Disconnect-Request asks a Network Access Server to end an existing session. Its Change-of-Authorization request asks the NAS to change the authorization of one already under way. The messages are useful because they create a defined control path. They are risky to summarize because the path contains several decisions that dashboards prefer to compress into one green light.

The selector determines the blast radius

A dynamic-authorization request carries attributes used to find session state: User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id, Chargeable-User-Identity and others permitted by the message tables. Those values are not decorative context. Together they define the set on which the NAS will act.

At least one session must match. If none does, the NAS returns a negative acknowledgment. But uniqueness is not assumed. A broad selector can legitimately find several sessions, and RFC 5176 says the request then applies to all of them. If the NAS cannot perform a multi-session operation, it returns Error-Cause 508, Multiple Session Selection Unsupported.

This changes the control question. It is not enough to ask whether the user name was correct. An operator must be able to reconstruct the exact attributes, the match cardinality and the identifiers of every selected session. A request aimed at one handset but expressed as a shared subscriber identity can have a larger blast radius without any failure of packet authentication.

The all-or-none rule limits partial damage but does not repair an overbroad selector. For a CoA, every requested change must succeed for every matching session before the NAS returns CoA-ACK. If one change cannot be applied to one member of the set, the NAS returns CoA-NAK and applies none. Disconnect follows the same discipline: either all matching sessions are terminated or none are.

Atomicity answers “did the NAS split the selected set?” It does not answer “was that the set the operator intended?”

An ACK is a strong claim at one layer

It would be wrong to dismiss the reply as mere packet delivery. A Disconnect-ACK is the NAS's protocol assertion that the associated session context was discarded and the selected sessions are no longer connected. A CoA-ACK says the requested authorization changes succeeded for the selected sessions. RFC 5176 gives those responses real state-transition meaning.

The boundary lies after that claim. The NAS may be the enforcement point, but it may also sit inside a larger service path. Accounting records can arrive later. A replicated policy store can lag. A downstream gateway can preserve state. Subscriber traffic can take a path whose observation belongs to another system. The ACK cannot testify for those systems merely because it is authentic.

The practical evidence chain is therefore cumulative. Preserve the request and its transport context; show why the client was authorized; record the match set; retain the exact response and Error-Cause values; then compare NAS session state, accounting records and traffic observations. The ACK remains evidence. It is not promoted into omniscience.

A NAK can mean “the next step started”

The sharpest warning against red/green reporting is Service-Type Authorize Only. When a NAS accepts that instruction, it does not return CoA-ACK. RFC 5176 requires CoA-NAK with Error-Cause 507, Request Initiated. The NAS then originates an Access-Request, and the later Access-Accept or Access-Reject decides the authorization outcome.

So the word NAK does not always mean that nothing useful happened. In this branch it is the correct receipt for successful initiation of another protocol exchange. Calling it a failed CoA erases the transition the operator most needs to follow. Calling it success would also be premature, because the Access-Request has not yet received its final policy decision.

Other Error-Cause values are equally specific. Session Context Not Found is different from Administratively Prohibited. Request Not Routable at a proxy is different from Resources Unavailable at the NAS. Unsupported Attribute is different from Multiple Session Selection Unsupported. The response code names a class; the cause and the next receipt supply the operational meaning.

Verified errata reinforce this discipline. Successful Error-Cause values in the 200 range are not confined to ACK packets, and Error-Cause is permitted in ACK responses as well. A parser that assumes success and failure are two non-overlapping columns can discard standards-defined information even while reporting that the exchange was parsed correctly.

Authentication is not delegated authority

In the legacy UDP design, the source address selects a shared secret and MD5-based RADIUS machinery authenticates the request; deployments may also use Message-Authenticator and the protections discussed across the RADIUS RFC family. RFC 5176 nonetheless warns that an authenticated client may not be authorized to change every session on a shared NAS. One provider must not acquire control over another provider's users because both reach the same box.

Freshness is separate again. Event-Timestamp constrains replay where stronger channel protection is absent, while retransmissions retain their identifier, authenticator, timestamp and source port so duplicates can be recognized. A valid cryptographic construction does not prove that the request is new unless the replay rules and state are also working.

The transport is no longer frozen in 2008. RFC 9765 updates this machinery for RADIUS/1.1 over negotiated TLS or DTLS, where the legacy shared-secret packet authenticator is replaced by the protected channel and Message-Authenticator is not sent. That is a material security improvement. It does not decide whether the authenticated peer may alter this realm, or whether its attributes resolve to the intended live session.

A proxy can find the NAS without finding the subscriber

RFC 5176 was published as Informational partly because deployed practice contained security weaknesses and semantic ambiguity that could not be removed without incompatibility. One ambiguity appeared in proxying: the base document did not standardize enough reverse-path identity for a proxy to route a dynamic-authorization request back to the originating NAS.

RFC 8559 later supplied Operator-Name and an opaque Operator-NAS-Identifier for that purpose. The mechanism gives an operator a way to find the correct NAS through a proxy chain. It does not turn the opaque routing token into a subscriber-session key. Routing to the right enforcement device and selecting the right state inside it remain two distinct operations.

That distinction is the durable leadership lesson. Coordination protocols are strongest when each participant says exactly what it knows. The client can say what it requested. The proxy can say where it routed. The NAS can say which protocol transition it accepted or rejected. Accounting can say what it recorded. Traffic instrumentation can say what moved. Reliability comes from joining those receipts without allowing any one of them to impersonate the rest.

Sources