In RFC 5176 RADIUS dynamic authorization, which party sends a CoA-Request, which party answers it, and on which transport port?
answer
- the usual answerer now does the asking
- unsolicited, not a reply to anything
- the access device has to listen
- Dynamic Authorization Client and Server
- UDP 3799, codes 40 and 43
basics
~20 sThe Dynamic Authorization Client — the policy side — sends CoA-Request (43) or Disconnect-Request (40) to the access device holding the session, which answers as Dynamic Authorization Server on UDP port 3799. The login-time roles are reversed.
solid answer
~50 sAt login the network access server is the RADIUS client and the server only ever answers. RFC 5176 adds the other direction: an unsolicited request sent at a session that is already running. The sender is the **Dynamic Authorization Client (DAC)** — a policy, billing or admission platform — and the receiver is the **Dynamic Authorization Server (DAS)**, which is the access device itself, because that is where the session lives. Three request/reply pairs exist: `Disconnect-Request (Code 40)` answered by `Disconnect-ACK (41)` or `Disconnect-NAK (42)`, and `CoA-Request (43)` answered by `CoA-ACK (44)` or `CoA-NAK (45)`. They run on **UDP port 3799**, not on 1812 or 1813, and the listener sits on the access device — so every device in the field needs an inbound socket and a shared secret for each DAC that may talk to it.
code
pseudocode · 16 lines// sender = Dynamic Authorization Client (policy/billing plane)
// receiver = Dynamic Authorization Server (the access device)
send to DAS at udp/3799:
Code = 40 // Disconnect-Request
Identifier = 7
attributes:
Acct-Session-Id = "5F2C-0A91"
NAS-IP-Address = 198.51.100.7
receive from DAS:
Code = 41 // Disconnect-ACK
Identifier = 7 // echoes the request
// on a refusal instead:
// Code = 42 (Disconnect-NAK) with Error-Cause = 503go deeper
Recall the shape: after a user is online, the policy side can reach back into that live session to change or end it, and the packet travels towards the access device rather than away from it.
Explain the reversal in the specification's own terms — Dynamic Authorization Client sends, Dynamic Authorization Server answers — and name the three request/reply pairs and UDP 3799 without confusing them with 1812 and 1813.
Show what enabling this costs in the field: an inbound listener and a shared secret on every access device, reachability from the policy plane, and the fact that no second device can answer for a session it does not hold.
Weigh a push path against letting sessions expire on their own timers: one adds an inbound control channel to every device in the estate, the other trades responsiveness for a far smaller exposed surface.
## What dynamic authorization adds In an ordinary RADIUS exchange the **network access server** — the switch port, wireless gateway or remote-access concentrator the user's device attaches to — is the client. It builds an `Access-Request`, sends it to a RADIUS server, and enforces whatever the single reply says. Nothing in that exchange lets the decision be revisited: once an `Access-Accept (Code 2)` has been enforced, the session runs until something local to the access device ends it, such as the `Session-Timeout (27)` it was handed at login. RFC 5176 supplies the missing direction. It defines **unsolicited** requests that the policy side sends at a session that is already up, so a live session can be changed or ended without waiting for the user to reconnect. Take a launderette chain selling prepaid customer wireless: the billing platform sits nowhere near the venue, and when a prepaid allowance runs out it has to reach into a session it never set up. ## The roles reverse, and the specification renames them RFC 5176 deliberately avoids the words *client* and *server* here, because at login they point at the other boxes: - the **Dynamic Authorization Client (DAC)** is the **sender** — the policy, billing or admission platform that has decided something about a running session must change; - the **Dynamic Authorization Server (DAS)** is the **receiver** — the access device that normally plays the RADIUS client, and that actually holds the session state. The practical consequence is infrastructural rather than conceptual. A DAS is a **listener**: each access device must accept inbound packets, be configured with a shared secret for every DAC allowed to reach it, and be reachable from the policy plane through whatever sits between them. That is new attack surface and new firewall policy on every device in the estate, which is why dynamic authorization is a deployment decision and not merely a feature toggle. ## The six codes | Code | Name | Direction | Meaning | |---|---|---|---| | 40 | `Disconnect-Request` | DAC to DAS | end this session now | | 41 | `Disconnect-ACK` | DAS to DAC | session context was removed | | 42 | `Disconnect-NAK` | DAS to DAC | not done; `Error-Cause (101)` says why | | 43 | `CoA-Request` | DAC to DAS | change this live session's authorization | | 44 | `CoA-ACK` | DAS to DAC | change applied | | 45 | `CoA-NAK` | DAS to DAC | not applied; `Error-Cause (101)` says why | Every request is answered by exactly one of its two replies, and a NAK carries `Error-Cause (101)` to say what went wrong. A `CoA-ACK (44)` is not an `Access-Accept (Code 2)`: it grants nothing and starts no session, it only confirms that a change to an existing one was applied. ## Where the packets go Dynamic authorization uses **UDP port 3799**. The two ports people know — `UDP 1812` for authentication and `UDP 1813` for accounting — carry packets the *access device* sends outward; 3799 carries packets it *receives*. Getting this wrong is the most common first mistake, because it makes the whole feature look like a server-side configuration item when it is really a new inbound path. A worked sequence in the launderette setting: 1. the customer authenticates, the session comes up, and the access device's accounting `Start` publishes an `Acct-Session-Id (44)` for it; 2. the billing platform, acting as DAC, decides the prepaid allowance is spent; 3. it sends a `Disconnect-Request (Code 40)` to the venue gateway's UDP 3799, carrying attributes that identify that one session; 4. the gateway removes the session context and answers `Disconnect-ACK (41)`, or refuses and answers `Disconnect-NAK (42)` with an `Error-Cause (101)` value. ## Retransmission, and why failover barely helps UDP gives no delivery guarantee, so the sender retransmits: the defaults are an initial retransmission time (**IRT**) of 2 seconds, a maximum retransmission count (**MRC**) of 5, a maximum retransmission time (**MRT**) of 16 seconds and a maximum retransmission duration (**MRD**) of 30 seconds. An unchanged retry reuses the same `Identifier`, the same Request Authenticator and the same source port so the receiver can recognise it as a duplicate; **change any attribute and it is a new request** that needs new ones. Unlike a login, there is no useful failover: the session exists on one specific access device, so a second address in the list is not an alternative that can answer. ## What this exchange is not - Not an `Access-Reject (Code 3)`, which can only answer a login attempt in progress. - Not an accounting `Stop`, which records that a session ended rather than causing it to end. - Not a message to the user's device, which never speaks RADIUS at all.
- The access device holding the session is unreachable. Can the sender fail over to a second device the way a login fails over to a second RADIUS server?No. A login can be answered by any server that holds the credential, but a session exists on exactly one access device, so no peer can apply the change. The sender retransmits — IRT 2 seconds, MRC 5, MRT 16 seconds, MRD 30 seconds — and then gives up. What follows is an operational decision, not a protocol one.
- Does a Disconnect-ACK prove the user is off the network?It proves the access device removed the session context it matched. If the session had already ended and only leftover state remained, the ACK may carry `Error-Cause (101)` value 201, Residual Session Context Removed — an acknowledgement that there was nothing live to tear down. Traffic may also continue briefly until the device's enforcement catches up.
- Why does a retry that changes one attribute need a new Identifier and Request Authenticator?Duplicate detection on the receiver keys on the `Identifier`, the Request Authenticator and the source port. Reusing them for a request whose content differs would let the device treat the new instruction as a duplicate of the old one and silently reuse its cached reply, so any change to the attributes makes it a genuinely new request.
A shop that normally phones head office for card approval now has to answer a call from head office telling it to take the goods back. Nothing in the old arrangement gives the shop a phone that rings, which is exactly the new port and listener a Dynamic Authorization Server needs.
saying these in an interview costs you the question
- Says the RADIUS server sends a CoA to the user's laptop.
- Thinks dynamic authorization rides UDP 1812 alongside login traffic.
- Believes an Access-Reject can end a session that is already running.
- Treats an accounting Stop record as the thing that tears a session down.
- Assumes a policy platform can change a session without the device listening.
- Calls a CoA-ACK an Access-Accept that re-grants the session.