skip to content

In RFC 5176, what do Error-Cause values 402, 403 and 503 each tell the sender of a CoA-Request?

level: middleimportance: should knowfreq 36%

answer

  1. the reply says who could not proceed
  2. one attribute turns refusal into diagnosis
  3. value bands split success from fault
  4. 400s fault the request, 500s the receiver
  5. 402 missing, 403 wrong device, 503 no session

basics

~20 s

402 Missing Attribute means the request lacked something the access device needs; 403 NAS Identification Mismatch means the request named a different device; 503 Session Context Not Found means no session matched. All three arrive in a NAK, never an ACK.

solid answer

~50 s

`Error-Cause (101)` is the attribute that turns a bare refusal into a diagnosis. `402 Missing Attribute` says the request was incomplete — the device needed an attribute the sender did not include. `403 NAS Identification Mismatch` says the request's NAS-identification attributes, such as `NAS-IP-Address (4)` or `NAS-Identifier (32)`, describe some other device than the one that received it. `503 Session Context Not Found` says the device has no session matching what was sent. The values are banded: **200-299 is success and appears only in an ACK**, while **400-499 and 500-599 appear only in a NAK**. The band records which side reported the failure — a faulty request versus the receiver's own processing — not who has to fix it, and 503 is the standing example of a receiver-band value whose repair is nearly always at the sender.

code

pseudocode · 16 lines
pseudocode
function answer_coa_request(request):
    if not all_required_attributes_present(request):
        return nak(Error-Cause = 402)   // Missing Attribute

    if request.nas_identification names another device:
        return nak(Error-Cause = 403)   // NAS Identification Mismatch

    sessions = match_all_identification_attributes(request)

    if count(sessions) == 0:
        return nak(Error-Cause = 503)   // Session Context Not Found
    if count(sessions) > 1:
        return nak(Error-Cause = 508)   // Multiple Session Selection Unsupported

    apply(request.attributes, to = sessions[0])
    return ack()

go deeper

for a junior

Remember that a refused change of authorization comes back with a numeric reason attached, and that the number is what tells you whether to fix the request, the destination or your record of the session.

for a middle

Name 402, 403 and 503 and say what each blames, and explain the banding — success values only in an ACK, fault values only in a NAK — without treating the band as an assignment of repair work.

for a senior

Turn the code into an action in order: device identity first, then completeness of the request, then how the session was named, and know which codes such as 507 are normal traffic that alerting must not treat as failures.

for a principal

Decide what your operations plane does with these codes at estate scale: which values page someone, which are absorbed by a retry policy, and what a rising 503 rate tells you about drift between the policy inventory and the field.

## Why a refusal needs a reason A `CoA-NAK (45)` or `Disconnect-NAK (42)` on its own says only that the request was not applied as sent. Operationally that is almost useless: a prepaid wireless session in a launderette that refuses to end could be refusing because the billing platform addressed the wrong venue gateway, because it left out an attribute, or because the session ended thirty seconds earlier of its own accord. `Error-Cause (101)` is the attribute that separates those cases, and reading it correctly is most of the debugging on this exchange. ## The three you will actually see - **402 Missing Attribute** — the receiver needed an attribute that the request did not carry. The usual cause is a sender that identifies a session by something the device does not key on, or that omits a value the device requires before it will act. - **403 NAS Identification Mismatch** — the request carried NAS-identification attributes such as `NAS-IP-Address (4)` or `NAS-Identifier (32)`, and they name a different access device from the one that received the packet. This is a *routing* error, not a session error: the packet arrived somewhere, but not at the box it claims to be addressed to. It is common where packets traverse address translation or where a device's identity in the policy platform's inventory drifted from the one it reports. - **503 Session Context Not Found** — the receiver looked and holds no session matching what was sent. Either the session has genuinely ended, or the identification attributes do not describe it the way the device stored it. ## The bands, and what they really tell you RFC 5176 partitions the `Error-Cause` value space: | Band | Meaning | Appears in | |---|---|---| | 0-199, 300-399 | reserved | — | | 200-299 | success | ACK only | | 400-499 | fault in the request as sent | NAK only | | 500-599 | fault in the receiver's processing | NAK only | Two consequences follow, and both get asked. First, **an ACK can carry an Error-Cause too** — most usefully `201 Residual Session Context Removed`, which says the device cleaned up leftover state but there was no live session to end. Second, the band records **which side reported the failure, not which side must repair it**. `503` sits in the receiver band because the receiver is the party that came up empty, yet the fix is almost always in the sender's identification attributes or its choice of destination device. ## The rest of the value space, briefly Beyond the three above, the values that turn up in the field are `401 Unsupported Attribute`, `404 Invalid Request`, `405 Unsupported Service`, `406 Unsupported Extension`, `407 Invalid Attribute Value`, `501 Administratively Prohibited` (the device is configured not to accept this), `502 Request Not Routable (Proxy)`, `504 Session Context Not Removable`, `505 Other Proxy Processing Error`, `506 Resources Unavailable`, `507 Request Initiated` and `508 Multiple Session Selection Unsupported`. Two deserve separate attention: - **504 Session Context Not Removable** — the device found the session and will not tear it down. The session exists; the refusal is about the action, which is a different fix from 503. - **507 Request Initiated** — a NAK that is not a rejection at all. It is the answer to a `CoA-Request` marked with `Service-Type` value `Authorize Only`, and it means the device has started fetching fresh authorization instead of applying what was pushed. Treating every NAK as a failure and alerting on it will make this case look like an outage. ## A diagnosis order that works 1. **Read the code first.** A NAK plus no `Error-Cause` leaves you guessing; a NAK plus a value usually names the fix outright. 2. **403 before 503.** If the identification of the *device* is wrong, nothing about the session can be trusted either; fix the destination first. 3. **402 means look at what you sent**, not at the session. Compare the attributes in the request against what the device keys sessions on. 4. **503 means look at how you named the session.** Was the identifier captured from this session's own accounting `Start`, and is it still current? ## What Error-Cause does not tell you It says nothing about authenticity. A packet a device cannot validate — the wrong shared secret for that sender, for instance — is discarded without a reply at all, so a missing answer and a NAK are different symptoms with different causes. `Error-Cause` also says nothing about the user: `503` means *this device has no matching session*, not that the person is offline. They may be online on another device entirely, which is exactly the case a 403 should have caught earlier.

  • Is every NAK a failure?
    No. A `CoA-NAK (45)` carrying `Error-Cause (101)` value 507, Request Initiated, answers a `CoA-Request` marked `Service-Type` `Authorize Only`: the device has begun pulling fresh authorization rather than applying what was pushed at it. Alerting on NAK count alone will flag that normal path as an incident.
  • What does an ACK carrying Error-Cause 201 mean?
    201 Residual Session Context Removed is a success-band value, so it can only appear in an ACK. It says the device cleared leftover state for a session that was no longer live. The instruction was honoured, but nothing was actually torn down — useful when you are reconciling why a user's traffic stopped before your request arrived.

saying these in an interview costs you the question

  • Reads every NAK as a permanent failure needing no further action.
  • Thinks Error-Cause is optional decoration with no defined value bands.
  • Expects a 400-band Error-Cause in an ACK when part of a request succeeded.
  • Confuses 403 NAS Identification Mismatch with a shared-secret mismatch.
  • Assumes 503 proves the user is offline rather than unidentified.
  • Treats 504 Session Context Not Removable as another way of saying 503.