Summary

  • A proxy could add one private Proxy-State value after existing values of that type, then remove its own when the response returned. Other proxies had to preserve earlier values and their relative order without treating their contents as instructions.
  • The rule did not require a contiguous block at the end of a packet, or even that every earlier value travel to the final server. A proxy could retain received values locally if it restored them in the reply to its client.
  • Returning state, applying an access policy and authenticating a neighboring server were different commitments. Neither an opaque value nor a protected connection established trust in every decision along the chain.

The last label need not be the last attribute

Consider a RADIUS request with two Proxy-State attributes and an attribute of another type between them. A receiver expecting all the private labels to sit together at the end of the packet might dislike the arrangement. Under the rules set out in June 2000, that preference was not a sufficient reason to reject it.

RFC 2865 required proxies to preserve the order of attributes of the same type. It did not impose a fixed order among different types, and receivers could not insist that repeated attributes be contiguous. A proxy adding its own Proxy-State put it after the earlier Proxy-State values. Another type of attribute could still follow it.

This was not a minor concession to untidy formatting. It specified exactly which relationship carried meaning. The last Proxy-State belonged to the latest proxy that had added one; being last in that sequence did not mean being last in the packet. The shared rule preserved ownership without prescribing every implementation's preferred arrangement.

The example is a reading of the specification, not a reconstructed outage. It reveals the danger of making an implementation convention stronger than the agreement between implementations. A protocol could be precise about the order that mattered while leaving other ordering choices open.

One intermediary, two conversations

In a conventional RADIUS exchange, the network access server was the client. The human seeking access was not, simply by being the user, the RADIUS client in that exchange. The access equipment sent a request to a server, which could handle it or forward it to another server according to its configuration, including the authentication realm.

The forwarding machine was a server to the previous participant and a client to the next. It could be the final server for some realms and a proxy for others. Several forwarding servers could form a chain. Avoiding loops remained necessary; Proxy-State did not supply a routing algorithm that made the chain correct by itself.

The June 1999 Informational document RFC 2607 examined this arrangement for roaming between networks. Proxies could simplify relationships, accommodate different capabilities, apply policy and handle accounting traffic. The access point and the organization making an authentication decision no longer had to be the same place.

But the document also warned that the then-current security assumptions were unsuitable for wide Internet deployment. Trust within one administrative domain did not automatically survive movement among independent organizations. Its account of deployment at the time should not be turned into either a present-day adoption statistic or a blanket endorsement of the architecture's safety.

A private value with public handling rules

Proxy-State was already present in the April 1997 RFC 2138. The 2000 revision gave a fuller account of proxy behavior and attribute ordering. It allowed a forwarding server to add one Proxy-State value of its own, but not more than one. Adding a value was an option, not something every proxy had to do.

Values that earlier proxies had supplied were to be treated as opaque data. The forwarding server's protocol operation could not depend on their private contents. Their actual format and use were left to the site or application that produced them.

That division was deliberate. An intermediary needed to recognize the attribute's boundaries and preserve its bytes, but it did not need a common definition of the internal state of every other intermediary. The participants shared rules for handling values without sharing all the meanings inside them.

At the final server, received Proxy-State values were copied unchanged and in order into the response. The obligation applied to Access-Accept, Access-Reject and Access-Challenge. A refusal still had to return the information that intermediaries needed to complete their work. The value's safe return was not evidence that the user had been granted access.

On the way back, a proxy that had added its own value removed the last Proxy-State: its own. Earlier values remained for earlier proxies. A server that had added nothing was not entitled to remove somebody else's value merely because it was now forwarding a response.

The stack-like analogy is useful only within these limits. It explains the reverse sequence of owners reclaiming their information. It does not establish a mandatory contiguous stack at the physical end of the packet, a complete route record or a shared language for the labels themselves.

The exception that rules out a complete path history

There was another reason not to mistake Proxy-State for a record of every place a request had visited. A forwarding server could omit previously received Proxy-State values from the request it sent onward. If it did so, it had to attach them to the response before returning that response to its client.

It could, in other words, preserve another participant's state by keeping it locally rather than carrying it all the way to the final server. The outward packet might contain less of the earlier state while the eventual reply still fulfilled the earlier participant's expectation.

This matters to anyone examining a trace. An absent value on the next connection does not by itself prove loss. A value returned to its owner does not prove that the home server saw it. The relevant comparison is at the interface where the promise was made: what the proxy received from its client and what it returned to that client.

The choice transferred work rather than eliminating it. A proxy that retained values locally had to recover them when the reply arrived. The specification did not select its storage system. It did require the externally visible result. Local implementation freedom came with a local obligation to remember enough to finish the exchange.

Opaque did not mean encrypted

Proxy-State was binary data with a defined attribute length, not a text field awaiting cosmetic improvement. Its value could contain a zero octet. A program that treated that zero as a string terminator would cut off information that the originating implementation might still need.

Trimming whitespace, changing case or normalizing an apparent string could be equally misguided. The proxy was not the editor of another implementation's private representation. Knowing how to identify the value did not entitle it to improve the contents.

Yet opacity offered no magical confidentiality. It described how a participant should refrain from interpreting a value, not a cryptographic barrier preventing that participant from seeing it. A malicious intermediary's physical ability to copy or alter data was not removed by a rule telling compliant intermediaries how to behave.

The IANA RADIUS attribute registry supplies common identities for State, Class and Proxy-State: types 24, 25 and 33. Such a registry identifies the shared attribute space. It does not describe every private encoding, attest that a live proxy returned a value correctly or decide which organization may grant a particular user access.

State was not one undifferentiated thing

The three state-related attributes also followed different lifetimes. State could carry server information from an Access-Challenge into the next Access-Request, helping an authentication conversation continue. Class could accompany an Access-Accept into accounting traffic; the base specification recommended carrying it unchanged when accounting was supported. Proxy-State served a forwarding intermediary's return path and was removed by that intermediary.

The December 2007 RFC 5080 clarified that a new or restarted authentication request must not reuse the State of an earlier conversation simply because the user and port were the same. Identity of a person or access point did not establish continuity of a conversation.

Treating every opaque field as a generic session identifier obscures these differences. It can encourage a system to retain a value beyond the exchange that gave it meaning, remove it before its intended use or infer a stronger relationship than its producer promised.

Accounting supplied a separate example of a bounded commitment. Under the June 2000 Informational RFC 2866, an Accounting-Response followed receipt and successful recording of the request. It was not just an indication that a packet had reached a network interface.

But an intermediary could wait for a remote response or take responsibility for local storage and onward forwarding, as the roaming discussion explored. A confirmation from one participant did not necessarily mean that every other organization had already recorded the same event. Understanding a receipt required knowing who had issued it and what work that participant had undertaken.

The policy boundary inside the packet

A proxy could modify some attributes to enforce local policy. RFC 2865 nevertheless protected existing Proxy-State, State and Class values from modification. The message was not wholly immutable, and policy adaptation was not necessarily malicious. The prohibition concerned specific information whose preservation mattered to other participants.

The original response processing also operated between neighbors. The proxy checked the response authenticator using its secret with the remote server, discarded a failed response, restored the Identifier for its client's original request and calculated the response authenticator for that client. The same authenticated envelope did not remain untouched across every administrative boundary.

RFC 2607's security discussion separated intended behavior from the possibility of a malicious proxy violating it. A rule against manufacturing a favorable decision was not itself an end-to-end mechanism that made such manipulation impossible. Technical capability, permitted protocol behavior and legitimate authority over another organization were different claims.

The May 2012 Experimental RFC 6614 added RADIUS transport over TLS while retaining intermediaries that could process messages. The Experimental RADIUS/1.1 profile published in 2025 changed the protection of relevant TLS and DTLS connections further. Neither development made every intermediary disappear, nor did it turn private return state into end-to-end evidence of policy fidelity.

The earlier shared-secret and MD5 procedures are described here as history, not as current deployment advice. New transport specifications likewise do not prove universal adoption. Each protected relationship has to be understood where it actually begins and ends.

Proxy-State's achievement was narrower than universal trust. It made a return obligation precise enough for different implementations to honor without requiring a common interpretation of their private memories. The label belonged to a particular piece of work. Carrying it was not a license to command the whole conversation.