Summary

  • The RADEXT working draft would standardise RADIUS packet Code 52, Protocol-Error, which RFC 7930 introduced experimentally. The IANA register still points Code 52 to RFC 7930.
  • Every proposed Protocol-Error carries Error-Cause and Original-Packet-Code. The latter ties an error to a pending request when different request types reuse the same RADIUS Identifier.
  • The error is hop by hop. A proxy must inspect the cause; codes 502 and 505 mark a proxy-network fault, for which it should try another connection or destination. It must never retry that request on the same connection.

RADIUS traditionally offers a blunt menu to a server handling authentication or accounting: answer with the request type's success or failure packet, or leave the sender waiting. The draft describes how those choices can collapse very different events into one timeout. A server might be busy, a packet might be malformed, or a downstream proxy path might have failed. The access device sees silence and applies its own retry rule. The registry of causes exists on the inside; the client has been made to operate by inference.

Code 52 offers a more exact sentence: I received this request and could not process it. The draft, updated on 2 November, proposes to take the packet type from its experimental home in RFC 7930 and define its use across RADIUS requests. It lists Access-Request, Accounting-Request, CoA-Request and Disconnect-Request as examples. An accounting failure therefore has a way to report processing trouble without pretending the event was booked. An authentication failure can state a protocol fault without manufacturing an Access-Reject that a help desk may treat as a decision about a user.

The proposed packet carries two pieces of evidence. Error-Cause says what failed. Original-Packet-Code says which kind of request produced the error. RADIUS Identifiers are small and can be reused by distinct request types; a matching number alone does not prove which operation suffered the fault. The error copies the Identifier from the request, while the original-code attribute disambiguates it. The draft tells a client to discard a response whose original code matches no outstanding request. A neat error message attached to the wrong login is worse than a timeout: it can drive the wrong retry or the wrong customer explanation.

The proxy cannot pass the problem upstream unchanged

Section 4 makes Protocol-Error a hop-by-hop packet. A proxy receiving one must examine Error-Cause instead of forwarding the received packet as if the original client shared the same relationship with the downstream server. The distinction follows the route. The proxy owns its outbound connection. The access device owns the request it sent to the proxy. Those are separate transactions even when one user's authentication started both.

The draft names two causes that point to the proxy network: 502, Request Not Routable (Proxy), and 505, Other Proxy Processing Error. For these, the receiving proxy should try another connection to the same destination or another destination. It must avoid the connection that just produced the error. That last instruction is the practical hinge. A system that retries immediately through the same broken hop turns a useful failure signal into a packet mill. The draft leaves the broader failover strategy to implementations, so an operator still has to define how many routes, attempts and seconds a request may consume.

For other causes, the proxy should read the error as coming from the home server and construct a Protocol-Error to its own client with that cause. This is an upstream report of a downstream result, made by the actor that knows the intervening hop. It lets a trace separate the home server's reason, the proxy's routing decision and the eventual answer seen by the access device. The packet alone cannot prove that the user was authenticated or an accounting record was committed. The next operational state must be recorded where it happens.

There is unfinished work in the draft. The migration, negotiation and precise response-selection sections still contain TBD text. The public packet has no deployment trace through two proxies. An implementation test should record the original request type and Identifier, the returned cause, the rejected connection, any new route, and the final response at the access device. That trace would turn Code 52 from a sensible draft rule into inspectable behaviour.

RADEXT draft · Datatracker status · RFC 7930 · IANA RADIUS register