Standardising Protocol-Error

Introduction The Remote Authentication Dial In User Service (RADIUS) protocol is designed as a request / response protocol, where clients send requests to servers, and servers send responses to clients. There are a few different types of requests defined, and each type of request has one or more associated valid responses. However, these requests and responses are limited to indicating success or failure of the requested action, such as authentication or accounting. There is no way for clients and servers to exchange information about their state, or their inability to perform the requested action. Instead, for actions such as authentication, servers can only reply with accept, reject, or simply fail to respond to the request. There is no way for the server to respond to a client with an error indicating "invalid request" or "unable to answer this request". The result is that when the server experiences a failure, it either stops responding to requests, or returns a type-specific response which is arguably wrong. Depending on the kind of failure, the server may stop responding to only one request, or else the server could stop responding to all requests. The client then has to make sense of the situation where some requests get a positive acknowledgement (ACK) response, other requests get negative acknowledgement (NAK) response, and other requests simply never see a response. This failure for the server to respond meaningfully means that the client has no way of knowing if the server is slow, is off line, or else if the server is a proxy and one of the next hops has failed. The only course of action that the client can take is to guess as what it should do when the server fails to respond. Such guesses are likely to be wrong. Incorrect decisions based on incomplete knowledge contribute to network instability and to congestive collapse. This failure of RADIUS to provide for protocol level signaling has caused issues with deployments for decades. The network as a whole operates not because the underlying protocol is robust, but instead because of local workarounds built by implementers and operators. It is time to address this deficiency. This document standardises the Protocol-Error packet code, which was first defined as an experimental code in . This packet code allows for servers to reply to any request with a Protocol-Error packet, which serves as an explicit protocol layer signal that the server has received a request, but is unable to process it. The Protocol-Error packet contains an Error-Cause attribute () which indicates whether the error is limited to just this packet or to the connection as a whole. The Error-Cause attribute also indicates whether this error is temporary or permanent. Explicitly signaling errors for protocol-layer failures increases the stability of the network, and decreases the likelihood of congestive collapse on failure. Where gives a very short description of the Protocol-Error packet Code, this document gives a more detailed definition. It explains the reasons for standardising Protocol-Error, fully defines the behavior of clients and servers with respect to Protocol-Error, and gives suggestions for migrations paths for implementations and deployments.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Review and Motivation This specification defines an extension to the RADIUS protocol which makes significant changes to how the protocol operates in the event of a failure. In order to motivate this change, we need to describe the historic issues with the protocol. We describe how the request / response nature of RADIUS is not, in fact, fully met: only some packet types have a NAK response defined, and there are other cases where the existing standards require that valid requests do not get any response at all. The result is that the RADIUS protocol is missing an important piece: signaling of protocol-level errors. This section explains the numerous situations where these errors are not signaled, and what impact this problem has for running networks.

Request / Response Packets This section reviews what types of request and responses are defined in RADIUS, along with their behavior. The Access-Request packet Code is defined in , with Access-Accept () as an ACK indicating that authentication has succeeded, and Access-Reject () as an explicit NAK that authentication has failed. The Accounting-Request packet Code is defined in , with Accounting-Response defined in , as an ACK that the accounting data has been stored. There is, however, no corresponding NAK which indicates that accounting has failed. Instead, states:

Upon receipt of an Accounting-Request, the server MUST transmit an Accounting-Response reply if it successfully records the accounting packet, and MUST NOT transmit any reply if it fails to record the accounting packet.

Failing to acknowledge a request with a response is, at best, impolite. More practically, it causes problems with networks. These problems will be discussed in more detail later in this document. The CoA-Request packet code is defined in , along with CoA-ACK to indicate that the change was successful, and CoA-NAK as an acknowledgement that the change of authorization action could not be performed. The Disconnect-Request packet code is defined in , along with Disconnect-ACK to indicate that the disconnection was successful, and Disconnect-NAK as an acknowledgement that the user or device could not be disconnected. While most requests have an ACK and NAK response defined, Accounting-Request packets only have an ACK response defined. If a request does not receive a response, clients retransmit as per. For Accounting-Request packets, these retransmits are unlikely to yield a positive response. Even when the request has a NAK response defined, there are still situations where a valid request could never have a response returned. Some implementations choose to discard well-formed and authentic packets, in violation of previous specifications. Even where implementations follow the specificiations there are many cases where those specifications suggest or even require that a server discard authentic requests, and therefore never send a response.

Silently Discard The existing RADIUS specifications require that a server "silently discard" requests without a response for many reasons. In some cases, this discard process is necessary for security reasons, such as when the Message-Authenticator ( fails verification. Discarding packets for security reasons is necessary, and this specification does not change that behavior. In other cases, this "silently discard" process is done for reasons which are not related to security. For example, a server could discard a request which contains data that the server does not understand, but which also does not affect the requested action. Or, the server could discard a request which has been authenticated, and is well-formed, but which contains unexpected protocol state. In an ideal world, the server would instead either ignore only the portions of the packet which it could not understand, or else the server would respond to the client with an indication that the request was improper. A server could also respond to a request containing invalid protocol state, and indicate that the request was authentic and well-formed, but it could not be processed because it contained unexpected protocol state. All of these issues are grouped under the term "silently discard", which is defined in as:

This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.

The specifications for other packet Codes contain the exact same text in , and in . While there is not a lot of quantitative data publicly available, these silent discards are colloquially known to be a large source of instability in RADIUS deployments. There has been substantial work done by server implementations and operators of proxy networks to stablize the network by attempting to determine whether or not the lack of a response indicates an actual failure, or only an illusory one due to the limitations of the RADIUS protocol. One ad-hoc workaround to failures involves increasing the number of Status-Server checks , in violation of the suggestion of "Keep-Alives Considered Harmful", which we quote in full here:

Some implementers have adopted the practice of sending test RADIUS requests to see if a server is alive. This practice is strongly discouraged, since it adds to load and harms scalability without providing any additional useful information. Since a RADIUS request is contained in a single datagram, in the time it would take you to send a ping you could just send the RADIUS request, and getting a reply tells you that the RADIUS server is up. If you do not have a RADIUS request to send, it does not matter if the server is up or not, because you are not using it. If you want to monitor your RADIUS server, use SNMP. That's what SNMP is for.

Experience has shown that this analysis is incomplete. SNMP is not suitable for monitoring servers across the wider Internet, and it is not suitable for monitoring servers in a different administrative domain. The quoted text also does not address the situation where a server is responding to only a subset of requests. This position is implied in , which says:

The Status-Server packet is not a "Keep-Alive" as discussed in . "Keep-Alives" are Access-Request packets sent to determine whether a downstream server is responsive. These packets are typically sent only when a server is suspected to be down, and they are no longer sent as soon as the server is available again.

In some cases, there is a sufficiently low volume of packets that the large inter-packet spacing triggers these Status-Server checks. In other cases, implementations will send Status-Server when some requests do not get a response, even if the server is actively responding to other requests. Some implementations and deployments have chosen to continuously send Status-Server requests, in contradiction to the recommendations of . Feedback from those systems indicate that this practice increases the information available to administrators, and decreases operational outages. The rest of this section describes in more detail the numerous situations where requests are silently discarded.

Unknown Attributes Some implementations discard requests when the request contains attributes which the implementation does not recognize. The behavior of servers with respect to unknown attributes is defined by which says that implementations:

MAY ignore Attributes with an unknown Type.

makes a stronger suggestion that:

It is RECOMMENDED that Attributes with unknown Type, Extended-Type, TLV-Type, or EVS-Type are treated as "invalid attributes".

Despite this recommendation to ignore these unknown attributes, some implementations will instead silently discard the entire request. This behavior is not standards compliant, and is not allowed by any interpretation of the text in . For example, the BlastRADIUS mitigations (TBD) were negatively affected by some implementations which would discard packets which contain a Message-Authenticator attribute. This behavior was seen in 2024, even though that the attribute had been defined decades earlier in (2000). This failure to handle unknown attributes in a reasonable manner made it difficult and expensive for operators to secure their networks via the recommended BlastRADIUS mitigations.

Invalid Attributes defines "invalid attributes" as attributes where the Type is known, but the Value is malformed. This topic was not discussed in the previous RADIUS specifications, which led to a wide range of implementation-specific behavior, including ones where the packet would be silently discarded. The behavior of implementations with respect to invalid attributes was clarified in , which requires the following behavior:

The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet ...

Even though this specification being over a decade old, some implementations still do not follow this requirement. Instead, some implementations will silently discard the entire request. This behavior has caused wide-spread issues in proxy networks, most notably with Operator-Name . One widely used implementation had erroneously created a local definition for attribute 126, which was then in conflict with Operator-Name when that attribute was defined. The implemenation also discarded requests which contained invalid attributes. The combination of the two behaviors led to wide-spread outages and significant effort by operators to perform a root-cause analyis and then to correct the issue. The behavior of discarding authentic, but unexpected data violates the robustness principle on which the Internet was founded.

Attribute Order XXXX attributes in "unexpected" order cause the packet to be dropped.

Unknown State In some cases, as server can receive a request which contains a State attribute () with an unknown value. This situation can occur, for example, when EAP authentications are sent through a load balancer, and one of the final home servers fails. The load balancer does not necessarily know anything about the underlying EAP session, and therefore may redistribute requests for an ongoing EAP session to a server which is unaware of that session. The result is that a home server receives a request which is in the middle of an EAP session. Since the server recieving the request did not start the EAP session, it does not recognize the value of the State attribute, and is unable to process the request. Some implementations will response with an Access-Reject. Others will silently discard the request. Both behaviors cause problems, just different ones.

Unexpected Request Code and defined different ports for Access-Request and Accounting-Request packets. defines a different port entirely for both CoA-Request and Disconnect-Request packets. In contrast, , , and define one port for all request Codes. Some implementations have also chosen to accept multiple request Codes on one port, even for RADIUS/UDP. As more than one port is used for RADIUS, there is a potential for mismatched configuration between a client and server. Each RADIUS specification (, , and ) has the same text related to receiving packets:

The Code field is one octet, and identifies the type of RADIUS packet. Packets received with an invalid Code field MUST be silently discarded.

However, this text does not address the issue where a client sends a packet which is authenticated, but where the request Code is unexpected. It is reasonable for the server to not perform the requested action, as there is no requirement for every server to support every possible request Code. It is not reasonable, however, for the server to fail to respond to authentic requests.

Accounting Failure says that servers need to respond to Accounting-Request packets when the accounting action is successful, but not when the accounting action fails:

Upon receipt of an Accounting-Request, the server MUST transmit an Accounting-Response reply if it successfully records the accounting packet, and MUST NOT transmit any reply if it fails to record the accounting packet.

In other words, servers are mandated to silently discard packets which are authentic, and which are sent to the correct destination. The packets are discarded not because the server is offline, but are discarded instead due to a transient operational failure.

Network Loss and Fragmentation When RADIUS/UDP is used, it is possible for either valid requests or responses to be lost in the network. RADIUS/UDP has another issue noted in , which notes that packets can be fragmented. also notes that:

Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed.

RADIUS/TCP and RADIUS/TLS are only partial solutions to the above problems. While they solve the fragmentation issue, there is still the issue where a server can receive a request, and then the connection can drop before the response is sent. From the clients point of view then, the request was sent, and then was silently discarded by the server. This specification cannot address the issue where packets are lost due to connection failures. We simply note that issue here for completeness.

Proxy Chains Even when none of the above problems are seen, a server which is correctly configured, operating normally, and responsive could still fail to respond when it is acting as a proxy. A proxy is conceptually just a server which then acts as a client to another server. The client side of the proxy can therefore run into the above issues when the next hop in the proxy chain fails to respond to a request. When the next hop fails to respond to the proxied request, there is very little meaningful action that the proxy can take. It can sometimes send the request over a different connection to the same server, or to a different server entirely. At some point, a proxy will run out of options, and decide that it is unable to forward the packet. It then has to determine the correct course of action. A proxy could originate an answer itself (e.g. Access-Reject, CoA-NAK, etc.), in the interest of replying to the client. Or, it may just silently discard the request. As noted earlier, both of these behaviors have problems.

Mismatched Timers When a client sends a request, it has to set a timeout as per in case it never sees a response. This timeout is set not just on the NAS which originated the request, but also on any proxy which forwards the request. Since there are multiple clients involved in forwarding a packet, there is the near-certainty that different parts of the proxy chain will have different timers. One possibility is that a client will have shorter timers than a subsequent proxy. The client will therefore give up on the request while a subsequent proxy erroneously believes the request to still be active. This specification does not help with that issue. Fixing that would require additional protocol-layer signaling as to timer values. Another possibility is that client will have longer timers than a subsequent proxy. The proxy will then give up on the request while the client is still waiting for a response. In that case, the proxy has the same two choices as noted earlier for similar situations: either synthesize a response, or silently discard the request.

Impact Thare a number of impacts which result from NAK responses which do not distinguish between different types of failures, and frqqrom requests simply disappearing into the network without response. It may seem useful for a server or a proxy to NAK an action which it cannot perform, but this response is not appropriate for a number of reasons. The most relevant one is that the NAK is an inaccurate response. A NAK response is typically made when the packet containing a requested action is authentic and expected, but where the action itself is not appropriate. For example, the requested action could violate a policy, or else request that action be taken for a user session which does not exist. In contrast, sending a NAK response for protocol-layer issues is overloading a NAK to contain protocol-layer signaling, which is inappropriate. An NAK informs the user or device that its requested action is inappropriate. It does not inform any network element that there is a protocol-layer problem. For example, if a user is attempting to access the network, an Access-Reject is normally interpreted as indicating that the users credentials are invalid. Sending an inappropriate Access-Reject could result in the user device taking an action such as invalidating or discarding the users password. The user device could even present the user with a prompt which indicates that the password is incorrect, and that the user should re-enter it. Such actions are likely to confuse the user, and to cause problems for network administrators. For accounting, the situation is made worse by the behavior of Acct-Delay-Time (). Instead of retransmitting the same request over a long period of time, the client instead updates the Acct-Delay-Time attribute, and sends a new request. This behavior greatly decreases the time available for a server to respond to a request. It also negates the benefits of the packet deduplication cache, and the multiple new packets then contribute to congestive collapse of the network. The impact for CoA-Request and Disconnect-Request packets is similar: either an inappropriate NAK is sent back, or the request never sees a response. The lack of responses contributes to network instability. When a client sends a request which never yields a response, it can only assume that the server is down. The client may then fail over to a different server, or open new connections to the same server, or simply stop sending packets to the server. In contrast, a server instead could respond to the client with a protocol-layer signal indicating that the request was received but not acted on. The client could then be better informed, and would be more likely to take an appropriate action to address the issue. The result would then be increased network stability, and decreased congestion. This specification standardizes the Protocol-Error packet Code as a response packet which carries this signal about protocol-layer issues.

Protocol-Error Code This document make the RADIUS packet Code 52 (Protocol-Error) standard instead of experimental, as an update to . In order to have one document defining this RADIUS packet Code, the definition of Protocol-Error is repeated here with only minor edits from the original in . The Protocol-Error packet Code may be used in response to any request packet, such as Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. It is a response packet sent by a server to a client. The packet indicates to the client that the server is unable to process the request for some reason. A Protocol-Error packet MUST contain an Original-Packet-Code attribute, along with an Error-Cause attribute. Other attributes MAY be included if desired. The Original-Packet-Code contains the code from the request that generated the protocol error so that clients can disambiguate requests with different codes and the same ID. Regardless of the original packet code, the RADIUS Server calculates the Message-Authenticator attribute as if the original packet were an Access-Request packet. The identifier is copied from the original request. Clients processing Protocol-Error MUST ignore unknown or unexpected attributes. This RADIUS packet Code is hop by hop. Proxies MUST NOT simply forward a Protocol-Error response that they receive. Instead, a proxy MUST examine the Error-Cause attribute to determine whether the error is due to a fault at the home server, or if it is a fault in the RADIUS proxy network. Where the Error-Cause value indicates a fault in the RADIUS proxy network, the proxy which receives the Protocol-Error SHOULD try to proxy the request over a different connection to the same destination, or to a different destination. That is, it should try to re-proxy the original request, as if it had just been received. This re-proxy process MUST NOT send the packet over the same connection as the previous proxied packet. Futher handling of proxy fail-over is out of scope of this specification. The following values for Error-Cause indicate a fault in the RADIUS proxy network. Other values for Error-Cause are possible, and may be defined in a future specification:

502, Request Not Routable (Proxy)
505, Other Proxy Processing Error

The remainder of the Error-Cause values SHOULD be interpreted as originating at the home server. The proxy SHOULD return the Protocol-Error to the client, and include the Error-Cause attribute from the response to the Proxied Request.

Impact on existing systems TBD - clients ignore packet Codes they don't understand. Therefore Protocol-Error is always safe to send. Even if the client does not process it and take action, an administrator can see the packet and take action.

Negotiation and Configuration TBD - no negotiation, but configuration based on agreement of administrators of client and servers. TBD - if a proxy knows that a client does not understand Protocol-Error, it MAY instead respond to the client with a relevant NAK packet. This SHOULD NOT be done when the client is another proxy, but only when the client is a NAS.

When to send Protocol-Error Responses TBD - mainly authentic packets, where there is no NAK (Accounting-Request), or where the NAK is not appropriate (unknown EAP State, etc.) See the (TBD Solutions) section below for more details.

Original-Packet-Code Attribute This document standardizes the Original-Packet-Code attribute, which was originally defined in . Description

The Original-Packet-Code contains the packet Code from the request that generated the Protocol-Error response. It allows clients to disambiguate requests with different packet Codes which use the same ID. The Original-Packet-Code attribute MUST NOT be sent in any packet Code other than Protocol-Error. A client which receives a Protocol-Error in a packet Code other than Protocol-Error MUST treat it as an "invalid attribute" as per .

Type

241.4

Length

Data Type

integer

Value

The Value is taken from the original request packet Code which was received by the server. Values which are not in the the IANA "RADIUS Packet Type Codes" registry are likely to be invalid. A client which receives an Original-Packet-Code attribute that does not match any outstanding request MUST silently discard the response.

Fewer Silent Discard This section defines new behavior which addresses the issues noted above in .

Invalid Attributes We reiterate here the mandate of :

The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet ...

Implementations which discard packets due to invalid attributes are not standards compliant.

Unknown Attributes Some implementations discard requests when the request contains attributes which the implementation does not recognize. This behavior is permitted by which says that implementations:

MAY ignore Attributes with an unknown Type.

makes a stronger suggestion that:

It is RECOMMENDED that Attributes with unknown Type, Extended-Type, TLV-Type, or EVS-Type are treated as "invalid attributes".

We update , , and here to say that implementations MUST NOT silently discard packets which contain attributes of an known Type, Extended-Type, TLV-Type, or EVS-Type. This mandate applies to all RADIUS packets, for all values of the packet Code field. Note that this prohibition does not apply to known attributes which have unknown values. For example, says that for the Service-Type attribute:

A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.

That requirement is not changed by this specification.

Unknown State TBD - try not to send Access-Reject. Maybe recommend a new Error-Cause value?

TBD This section outlines some notes which should be addressed by further discussion.

We may want to omit Proxy-State from Protocol-Error. It isn't needed for link-local signalling. However, it is an odd corner case, and it may be more consistent with other practices to leave it it. At the minimum, the client MUST accept Protocol-Error even if it is missing Proxy-State.
One new corner case provided by Protocol-Error is a next hop which responds to all packets with Protocol-Error.
- Without Protocol-Error, the next hop won't reply, and the proxy will think it's down, and do a fail-over.
- With Protocol-Error, the next hop is "up", and the proxy will continually send packets to it. Only for it to reply, and say "send the packets elsewhere". There isn't a way to signal that an entire realm is down.
suggest to use Protocol-Error instead of CoA-NAK, as it's likely better. CoA-NAK goes back to the client immediately, and does not allow for the packet to be proxied to a different destination
Migration path needs to be addressed:
- servers MUST always accept Protocol-Error as a valid reply.
- existing clients will discard it, if they follow the RFCs. But some may misbehave.
- servers SHOULD have a flag which controls whether or not they send Protocol-Error to clients. The flag should be global and also per client. The default SHOULD be to enable it.
- if a client doesn't support Protocol-Error, the server can swap the response to Access-Reject, CoA-NAK, etc. This behavior could likely also be configurable.
Add more Error-Cause valuesL
- unknown attribute
- invalid attribute, for malformed ones
- no room to add Proxy-State
- all next hops are down
- all next hops are busy
- next hop didn't get a response to its forwarded packet
- accounting failure (can't write data, etc.)
- CoA-NAK failure - unable to take requested action
  - RFC8559 already says send NAK with Error-Cause
- overload - try again later
- Perhaps also for TCP buffering issues?
require that implementations MUST check that packets are well-formed, AND a reply to an outstanding request before checking M-A in Protocol-Error. "well-formed" here includes checking that Original-Packet-Code matches an outstanding request.
if a server sends a Protocol-Error response, and the client sends a duplicate request, the server should reply with a duplicate response. We don't know if the response was lost due to networking issues, or if the client doesn't support Protocol-Error.

IANA Considerations IANA is instructed to update the "RADIUS Packet Type Codes" registry, and change the Protocol-Error entry from Reference RFC7930 to THIS-DOCUMENT. IANA is instructed to update the "RADIUS Attribute Types" registry, and change the Original-Packet-Code entry from Reference RFC7930 to THIS-DOCUMENT.

Privacy Considerations There are no privacy considerations in this specification. It does not add or change any transport protocols, and it does not change the roles of any participant in the RADIUS ecosystem.

Security Considerations This specification has no direct impact on security. It does not add or change any existing cryprography in RADIUS. It is compatible with all RADIUS standards, including (ALPN draft). This specification does, however, recommend ways that networks can be better protected from a variety of problems, misconfigurations, and erroneous implementations. As a result, RADIUS proxy networks which implement this specification should become more stable, and therefore more secure.

Acknowledgements This document came out of discussions both in the RADEXT WG, and in the 2025 RADIUS Technical Conference in Tampere, Finland.