skip to content

When a RADIUS forwarding server relays an Access-Request, what does it do with Proxy-State (33) each way?

level: seniorimportance: should knowfreq 34%

answer

  1. how does a hop find its pending request?
  2. append on the way out
  3. the decider echoes, never reads
  4. the chain unwinds in reverse
  5. the access device sees none

basics

~20 s

On the way out it may append one Proxy-State (33) of its own, after any already present. The deciding server copies every Proxy-State it received into its reply unchanged. On the way back each forwarding server removes the one it added.

solid answer

~50 s

Going up the chain, a forwarding server **may append a single** `Proxy-State (33)` attribute, placed after any `Proxy-State` attributes already in the request - that is how it will recognise the reply as belonging to a request it is holding. The server that finally decides must copy **every** `Proxy-State` it received into its reply, unchanged and in the same order, and must not interpret them: the contents are the adding server's own business. Coming back down, each forwarding server strips **its own** `Proxy-State` before passing the reply on, so the chain unwinds in reverse - last to add is first to strip - and the network access server that began the exchange sees none at all. Getting the order or the stripping wrong leaves state in the reply that nobody downstream can make sense of.

code

pseudocode · 15 lines
pseudocode
on forwarding a request:
    append one Proxy-State (33) after any Proxy-State already present
    remember (my_marker -> the request I am holding)
    send onward to the next hop

on deciding a request:
    copy every received Proxy-State (33) into the reply
    unchanged, and in the same order
    interpret none of them

on receiving a reply:
    my_marker = the last Proxy-State (33) in the reply
    remove it
    match my_marker to the request I am holding
    send the reply toward the access device

go deeper

for a junior

Know only that a proxied request can come back with extra state that the proxy itself put there, and that the access device at the start of the chain never sees it.

for a middle

State the three rules in order: append one after any present, echo them all unchanged at the decision, strip your own on the way back. Say why the ordering has to be last-in-first-out.

for a senior

Diagnose from the symptom: an unmatched marker one hop below the fault, replies returned with attributes reordered, repeats overtaking originals on a slow chain. Say how you would walk the chain.

for a principal

Count the hops as an operational cost, not a topology detail. Each one is a relationship, a failure point and a rewrite opportunity, and the diagnosis cost grows faster than the path.

## The problem this solves A forwarding server relays many requests at once and has to match each reply to the request it is still holding. It cannot rely on anything the originating access device chose, because several access devices may be behind it and their choices are not coordinated. So it leaves itself a marker that will come back with the answer. `Proxy-State (33)` is that marker. Its contents are opaque - the adding server is the only party that interprets them, and nothing else on the path is entitled to look. ## The three rules, in the order they fire 1. **Going up.** A forwarding server may append one `Proxy-State (33)` of its own, and it places it **after** any `Proxy-State` attributes already present. The existing ones belong to servers further down the chain and must not be disturbed. 2. **At the decision.** The server that answers copies every `Proxy-State` it received into its reply, unchanged and in the same order. It does not act on them, reorder them, merge them or drop them. 3. **Coming down.** Each forwarding server takes off the one it added, then passes the reply on. The chain unwinds in reverse: the last server to add is the first to strip. By the time the reply reaches the network access server that started the exchange, no `Proxy-State` remains. An access device never has to know that a chain existed. ## Why the ordering is load-bearing The stack discipline is the whole mechanism. Appending in the middle, or stripping something you did not add, breaks another hop's ability to match its pending request - and it breaks it for a *different* server, which is why the symptom appears somewhere other than the misbehaving box. | Position in the chain | On the request | On the reply | |---|---|---| | originating access device | adds none | expects none | | first forwarding server | appends its own, after any present | strips its own, passes the rest | | second forwarding server | appends its own, last | strips its own, passes the rest | | deciding server | reads none | echoes all of them, unchanged and in order | ## What a chain costs beyond this - **Latency accumulates per hop**, and it is paid on every login, not only the first. - **Every hop is an administrative relationship** that somebody has to configure, monitor and keep correct - routing entries and per-hop trust both. - **Every hop is a place a request can be dropped**, and a drop looks to the hop below like a slow server rather than a routing fault. - **Every hop can rewrite attributes** on the way through, so what the deciding server sees is not necessarily what the access device sent, and what the access device enforces is not necessarily what the deciding server said. - **A slow chain produces repeats.** If the whole path takes longer than the originating device is prepared to wait, it re-sends, and the servers upstream see requests they may already be working on. ## Where it shows up in production At a showground running a dozen visiting exhibitor realms, the on-site forwarding server holds thousands of short-lived requests on a busy morning. The failures that bite are not exotic: - a hop that leaves its own `Proxy-State (33)` in the reply, so the next one down finds a marker it cannot match; - a deciding server that returns a reply with the attributes reordered, breaking the last-in-first-out unwind; - a chain long enough that repeats overtake the original replies, so a hop matches an answer to a request it has already retired. Each of these is diagnosed by walking the chain hop by hop, because the symptom never appears where the fault is. That is the real cost of a proxy chain: not the latency, but the number of places you have to look.

  • Why must the deciding server echo Proxy-State (33) unchanged instead of acting on it?
    Because it is another server's private matching state. Nothing on the path is entitled to interpret it, and altering, reordering or dropping it destroys a hop's ability to match the reply to the request it is holding. The deciding server gains nothing by reading it and breaks somebody else's exchange by touching it.
  • Besides latency, what does adding a hop to a RADIUS proxy chain cost?
    Another administrative relationship to configure and monitor, another place a request can be dropped or its attributes rewritten, and another set of matching state to keep correct. A chain slow enough to outlast the originating device's patience also produces repeats that upstream servers have to recognise, so the operational surface grows faster than the path length.
  • A hop finds a Proxy-State (33) in a reply that it cannot match. What is the most likely cause?
    A server above it did not strip its own marker, so the hop is looking at somebody else's state, or the deciding server returned the attributes reordered and the last-in-first-out unwind no longer lines up. Both faults appear one hop below the misbehaving server, which is why these are diagnosed by walking the chain rather than by reading one log.

Each relay in a courier chain clips its own docket to the parcel on the way out and takes that same docket back off on the way home, so the last relay to add is the first to remove and the sender never sees any of them.

saying these in an interview costs you the question

  • A forwarding server leaves its own Proxy-State (33) in the reply
  • The deciding server should parse Proxy-State to see the chain
  • A new Proxy-State goes before the ones already present
  • The access device strips the Proxy-State attributes
  • Proxy-State makes the whole chain trustworthy end to end