skip to content

Why must a CoA-Request carrying Service-Type 'Authorize Only' include a State attribute, and what does the access device do next?

level: seniorimportance: nice to knowfreq 22%

answer

  1. a refusal that is really an acknowledgement
  2. push replaced by pull
  3. the device asks rather than accepts
  4. State correlates the follow-up Access-Request
  5. Error-Cause 507 Request Initiated

basics

~20 s

Authorize Only tells the access device not to apply the pushed attributes but to fetch fresh authorization itself. It answers CoA-NAK with Error-Cause 507 Request Initiated, then sends an Access-Request carrying the State attribute, which ties that pull to the CoA-Request that asked for it.

solid answer

~40 s

An ordinary `CoA-Request (43)` **pushes** attributes at a live session. Marking it with `Service-Type (6)` value `Authorize Only` inverts that: the device must not apply what was sent, and instead re-authorizes the session by asking the RADIUS server. Because nothing in the push is applied, the device answers `CoA-NAK (45)` with `Error-Cause (101)` value **507 Request Initiated** — a NAK that reports work started, not work refused. It then sends an `Access-Request` for that session and enforces whatever comes back. RFC 5176 requires the `CoA-Request` to carry a `State (24)` attribute, and the device includes it in that `Access-Request`; `State` is opaque to the device and exists purely so the server can correlate the pull with the change that triggered it. The session stays up throughout — nothing is torn down and rebuilt.

code

pseudocode · 15 lines
pseudocode
// 1. policy plane asks for a re-authorization, not a change
CoA-Request (43) to DAS udp/3799:
  Acct-Session-Id = "5F2C-0A91"
  Service-Type    = "Authorize Only"
  State           = <opaque bytes from the server>

// 2. the device does not apply anything pushed
CoA-NAK (45):
  Service-Type    = "Authorize Only"
  Error-Cause     = 507        // Request Initiated

// 3. the device pulls fresh authorization instead
Access-Request to RADIUS server udp/1812:
  User-Name       = "guest-4471"
  State           = <echoed unchanged>

go deeper

for a junior

Recall that the policy side has two options: tell the device exactly what to apply, or tell it to go and ask the server again. The second keeps the session running while it happens.

for a middle

Explain the marking and its reply: no pushed attribute is applied, a NAK carrying 507 reports that a re-authorization has begun, and the echoed State attribute is what lets the server correlate the follow-up request.

for a senior

Show why this shape survives contact with production — one authority for policy, no stale pushed attribute sets, no teardown — and make sure your alerting does not treat a 507 NAK as an error rate.

for a principal

Choose between pushing attributes and triggering a pull across an estate: a pull keeps policy in one place at the cost of an extra exchange per change and a device population that must implement the marking consistently.

## Push versus pull, in one exchange Most of RFC 5176 is a **push**: the Dynamic Authorization Client puts the new attributes in a `CoA-Request (43)` and the access device applies them to the live session. That is convenient and it has a structural drawback — the policy decision is now made in two places, because the sender must know what the full, correct authorization for that session should be. `Service-Type (6)` with the value `Authorize Only` converts the same packet into a **trigger for a pull**. It tells the access device: do not take authorization from me; go and get a fresh one from the RADIUS server for this session. The sender no longer has to know the policy, only that the policy for this session has changed. In the launderette's prepaid wireless, that is the difference between the billing platform hard-coding a replacement bandwidth attribute and simply saying *this customer's entitlement has changed, ask again*. ## The NAK that means yes Because nothing pushed is applied, an ACK would be the wrong answer, so the device replies `CoA-NAK (45)` carrying `Error-Cause (101)` value **507 Request Initiated**. This is the one reply on this leaf that is routinely misread: - it does **not** mean the request was rejected; - it does **not** mean the session is unchanged forever; - it means the device has **started** the re-authorization that was asked for, and the outcome will arrive by a different exchange. An operations dashboard counting NAKs as failures will show this normal path as an error rate. That is the practical reason to know the code. ## What State is for RFC 5176 requires a `CoA-Request` marked `Authorize Only` to carry a `State (24)` attribute, and the device echoes it in the `Access-Request` it then sends. `State` is **opaque**: the access device does not parse it, does not act on it, and must return it unchanged. Its only job is correlation — it lets the server recognise the incoming `Access-Request` as the consequence of the specific change that was requested, rather than an unrelated login for the same user. Without it the server sees an ordinary re-authorization request and cannot distinguish: - the pull it asked for a moment ago; - a periodic re-authorization the device does on its own schedule; - a genuinely new attachment by the same customer on another device. All three look alike on the wire otherwise, and the server would have to guess which policy state to answer from. ## The sequence end to end 1. The Dynamic Authorization Client sends `CoA-Request (43)` to the access device on **UDP 3799**, carrying the session identification attributes, `Service-Type (6)` = `Authorize Only`, and a `State (24)` value. 2. The access device matches the session, declines to apply anything from the request, and answers `CoA-NAK (45)` with `Error-Cause (101)` = 507. 3. The device sends an `Access-Request` to its RADIUS server for that session, including the `State (24)` it received. 4. The server answers with the current authorization, and the device enforces it on the session that is already running. | Path | What the sender must know | What the device applies | |---|---|---| | Plain `CoA-Request` | the exact replacement attributes | what the request carried | | `Authorize Only` | only that policy changed | what the server returns | ## Why this shape is worth the extra round trip - **One authority for policy.** The RADIUS server remains the only party that computes a session's authorization; the dynamic-authorization path becomes a notification rather than a decision. - **Nothing is torn down.** The session stays up while the device re-authorizes it, so the alternative of disconnecting and letting the user reconnect is avoided altogether. - **Fewer stale pushes.** A pushed attribute set computed from a policy platform's own view can be out of date by the time it lands; a pull reads current state at the moment it matters. The costs are real too: an extra exchange, a device that must implement the marking correctly, and an operations plane that has to understand a NAK code as success. ## The traps - **Reading 507 as a failure.** It belongs in the 500 band of `Error-Cause` values, so band-based alerting flags it; the band records which side reported the condition, not that something is broken. - **Omitting `State (24)`.** The specification requires it on this variant, and without it a device may answer `402 Missing Attribute`. - **Interpreting `State (24)`.** It is opaque to the device and to anything in between; only the issuing server gives it meaning. - **Also pushing attributes alongside the marking.** They will not be applied, and expecting otherwise produces a session that looks unchanged for reasons nobody can find. - **Assuming the pull always widens access.** The server answers with whatever the current policy is, which may be narrower than before, or a rejection.

  • Why is a NAK the right reply here rather than an ACK?
    An ACK would assert that the attributes in the `CoA-Request` were applied to the session, and under `Authorize Only` none of them are. The NAK plus `Error-Cause (101)` value 507 Request Initiated reports accurately what happened: nothing from the request was applied, and a re-authorization has been started instead.
  • Can the access device read or act on the State attribute?
    No. `State (24)` is opaque to the device, which must return it unchanged in the `Access-Request` it sends. Only the issuing server gives it meaning, using it to recognise the pull as the consequence of the change it asked for rather than an unrelated login by the same customer.

saying these in an interview costs you the question

  • Reads the CoA-NAK as the device refusing to re-authorize.
  • Expects the device to apply attributes sent alongside the Authorize Only marking.
  • Treats the State attribute as something the access device should interpret.
  • Assumes the session must be torn down before it can be re-authorized.
  • Thinks a pull always returns broader access than the session had.