A single misbehaving device can take an entire institution offline. At the RADIUS Conference Workshop 2026, the people who build and operate RADIUS spent a day working through why, and what to do about it.
By Alan DeKok, CEO, InkBridge Networks
At
the RADIUS Conference 2026 Workshop in Helsinki, one of the operators
in the room described a failure mode that stopped everyone cold: a
single misbehaving device,hammered the network until an entire institution lost connectivity. Just one device that didn't know when to stop.
It's an extreme case, but it illustrates why RADIUS stability is harder than most documentation lets on - and why a room full of the people who build and operate these systems decided they needed to meet in Finland to work through it together.
In commercial conversations with ISPs, we regularly encounter networks where the majority of authentication traffic is access rejects. The existing protocols has no mechanism to tell a device to stop retrying, so devices don't. Multiply that across thousands of lapsed accounts and you get proxy fabrics processing enormous volumes of traffic that will never succeed, with no clear way to stop that traffic.
The second RADIUS Conference took place at TNC26 and online in June 2026, co-organised by InkBridge Networks and Radiator Software. It brought together RADIUS implementors, operators, standards authors, and engineers from ISPs, educational networks, and roaming federations.
The workshop format was deliberately not a conference in the conventional sense. It was a working session. People came to solve problems.
RADIUS failover is a protocol problem
Most documentation on RADIUS failover treats it as a solved issue. Configure a primary server, configure a backup, set your timeouts, and when the primary goes down, the client retries against the secondary. Done.
If you operate a network at any meaningful scale, you know that is not the whole story.
RADIUS was designed in 1991 and runs over UDP. UDP has no built-in reliability - packets can disappear without any notification to the sender. Some of the original RFCs compound this by explicitly instructing servers to silently discard packets they cannot process. The result is that when something goes wrong in a RADIUS environment, the sending system often has no way to know whether the packet was received, rejected, or simply dropped into a void.
In a proxy chain - where authentication requests pass through one or more intermediate servers before reaching the home server - this becomes a serious operational problem. If a next-hop server is down, the proxy accepting the packet has no standard mechanism to signal the problem back upstream. It cannot say “I received your request for this realm but I cannot forward it - please send it somewhere else.” It can only wait, timeout, and hope.
The only discussion of proxying in RFC 2865, the original RADIUS specification, is one sentence: “This is a subject of future research.” Thirty years later, that research is finally being written down.
Three things the conference identified as the highest priorities
The 2025 conference established the agenda for 2026. Operators identified three structural problems they wanted solved: protocol error signalling, reject caching (congestion control), and proxy best current practices.
This year’s session reviewed progress on all three and worked through the harder implementation questions in depth.
Protocol error signalling
Most protocols designed after 1993 include a mechanism to signal errors explicitly. RADIUS does not. When a server receives a packet it cannot process - because it is overloaded, because the next hop is unreachable, because the realm is unknown - it is required by the standards to “silently discard” the packet. The sending system waits for a a response that it will never get. The sending system may then re-send the packet against the same or another server with no information about what went wrong.
The protocol error draft changes this. A server that cannot process a packet will now send a response saying, in effect, “I received your request and I cannot process it - please try elsewhere.” The client or proxy gets an immediate signal rather than waiting out a timeout. Failover happens in milliseconds rather than seconds. The 8-bit ID problem that forces clients to wait for timeouts before they can reuse packet identifiers is avoided entirely.
FreeRADIUS already supports protocol error - the result of work done at the IETF 124 hackathon in Montreal. Cisco has confirmed it is on their roadmap. The only thing preventing wider deployment at this point is operators enabling the configuration flags on systems that support it. If your network uses FreeRADIUS, you can turn protocol error on today and measure whether stability improves - the conference specifically asked operators to do this and report back.
Reject caching and congestion control
Reject caching addresses a problem most ISP operators will recognize: networks where the bulk of authentication traffic is access rejects from devices that never back off. When a home server sends a reject, it can include a signal that instructs the network - ideally pushed as close to the edge as possible - to suppress further requests from this device for a defined period. An account that has been deleted for three years does not need to be rejected five times a second indefinitely. A device that is authenticated but not authorised at a particular location should not hammer the proxy fabric trying harder.
The practical benefit is load reduction by orders of magnitude. Going from five retries per second to one retry per hour - for devices that will never succeed - is a significant change to the traffic profile of any network handling millions of authentication sessions.
The discussion in the room also covered a harder case: misbehaving devices sending thousands of packets per second, which can overwhelm proxies with no current mechanism to push back. Rate limiting recommendations are included in the current security document, but the question of how to handle extreme cases in real production environments is still being worked through.
Proxy best current practices
Thirty years of RADIUS deployments have produced a large body of operational knowledge about what works and what does not in proxy environments. Almost none of it is written down anywhere authoritative. The proxy best current practices document - currently an outline covering approximately 15 to 20 topics - is the attempt to change that.
A few of the issues it addresses: load balancing in proxy environments should generally be done on the Calling-Station-ID attribute rather than the source port. This ensures that all packets related to a single EAP session take the same path through the network - critical for protocols like EAP-TLS that maintain state across multiple exchanges. If one upstream hop fails, only sessions associated with that hop are affected rather than all active sessions simultaneously.
Intermediate proxies should not retry packets. If a proxy fails over from one server to another, it can redirect packets it is currently holding, but it should not generate new retransmissions. RFC 3539 documents this, but it is widely ignored. When proxies do retry, you get compounding retry loops across the entire chain - instability that grows geometrically with the number of hops. The transition from RADIUS over UDP to RadSec (RADIUS over TLS) changes this dynamic further: TCP provides its own reliability guarantees, removing the need for application-level retransmission while introducing different failure modes that also need to be understood.
There are also timing coordination issues that have caused real outages. One operator in the room described implementing rate limiting with a ten-second quiet period - reasonable in isolation, but long enough to trigger dead-server detection in ClearPass, which does not allow timeouts longer than five seconds. The interaction between two otherwise reasonable implementations created a failure that neither vendor’s documentation anticipated.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
Why this matters specifically for ISPs
Enterprise RADIUS deployments are typically contained within a single organisation’s infrastructure. The authentication path is short and predictable.
ISP
deployments are different: you are often handling authentication across
intermediate providers, resellers, and roaming partners, with devices
you did not provision and cannot control. The proxy chain can be several
hops long. Accounts churn constantly. Edge equipment from dozens of
vendors behaves inconsistently.
The problems discussed at the conference workshop -
silent packet drops, no error signalling, reject storms, proxy retry
loops, load balancing that breaks EAP state - are felt most acutely by
ISPs operating at scale.
A well-architected deployment using multiple RADIUS servers with proper load distribution is significantly more resilient than a primary/secondary configuration, but the protocol-level issues affect both. Separating your authentication and accounting infrastructure helps manage the load, but it does not fix the underlying signalling gaps.
The standards work underway at the IETF is focused on the server and proxy layer rather than the edge equipment, deliberately. There are far fewer RADIUS server implementations than there are access points, switches, and modems. Getting fixes into FreeRADIUS, Radiator, and a handful of other widely-deployed servers reaches the majority of the industry far faster than trying to update edge firmware across hundreds of vendors. Once the servers implement these features correctly, there is leverage to push the access point and NAS vendors to follow.
What the community is building and what you can do now
The standards work is progressing. Protocol error is available in FreeRADIUS today. The reject caching draft is being updated based on feedback from the conference. The proxy BCP document is an outline that will be developed in parallel with the other documents once the higher-priority items are complete. All of this is being done through the IETF RADEXT working group, which anyone can follow by joining the mailing list.
For ISPs running FreeRADIUS today, the most useful thing you can do is enable protocol error if you have not already, and monitor proxying and failover. The network as a whole should get more stable, with faster response times to failures. The operational impact is substantial - less server load, clearer logs, faster failover when something genuinely breaks, and a network that is easier to diagnose.
For ISPs evaluating whether their RADIUS architecture is as resilient as it should be, the questions worth asking are:
Do you know what percentage of your authentication traffic is rejects?
Do you have a mechanism to detect a dead next-hop server without waiting for a timeout?
Are your proxies load-balancing on Calling-Station-ID or on something that will break EAP sessions during failover?
Are your intermediate proxies configured to avoid retransmitting packets?
These are design questions that determine how your network behaves under pressure.
Other topics from the floor
Failover and stability dominated the day, but the conference covered more ground than that. A few other areas worth noting for anyone tracking where RADIUS is heading.
Getting standards into production: the avenues of influence
Karri Huhtanen presented on how RADIUS standards get turned into deployed implementations.
Writing a good IETF draft is necessary but not sufficient. The path from RFC to widespread deployment typically runs through multiple organisations: a specification gets written in the IETF, tested or validated in the WBA, required by the Wi-Fi Alliance in a product certification, and only then becomes something vendors are compelled to implement.
OpenRoaming followed exactly this path. The practical implication for the current standards work is that fixes will reach server implementations faster than edge devices, but the server layer is where the leverage is, and that is where the work is focused.
The other note from this session: the IETF RADEXT working group needs more contributors. If you work with RADIUS professionally, the mailing list is open and participation is free.
Antisocial vendor behaviour and the RADIUS wiki of shame
The proxy BCP document exists partly because operators have spent decades absorbing the consequences of vendor implementations that are technically permitted by the RFCs but operationally destructive.
One example discussed in the room: a GGSN with 10,000 open sessions that fires all its accounting interim updates simultaneously when a single timer ticks. Ten thousand accounting packets hitting a proxy at once, with no mechanism to push back.
Another: implementations that silently discard any access request containing a Proxy-State attribute (used for loop detection) for no documented reason. This behavior violates the standards, and is unfriendly to existing implementations.
When challenged on behaviour like this, vendors often respond that the RFCs do not explicitly prohibit it. The IETF RADEXT working group maintains a public wiki documenting known problematic implementations. This page is a useful reference when diagnosing unusual vendor behaviour. The proxy BCP document will give operators something more authoritative to point to: not “the RFC doesn’t say you can’t,” but “the BCP explicitly says this is wrong.”
EAP state, deduplication, and accounting store-and-forward
Two open questions surfaced in the proxy BCP discussion without clean resolutions.
First, EAP state across proxy paths: if a load balancer or mid-handshake failover sends successive EAP packets via different paths, some servers can handle that continuity and some cannot. There is currently no standard way to signal this or guarantee it. Packet deduplication is partly addressed in RFC 5080, but that document is nearly fifteen years old and not widely implemented outside server software.
Second, accounting store-and-forward in proxy environments: when an upstream is temporarily unreachable, the right behaviour (forward live or store locally and replay when the upstream recovers) has different implications for billing accuracy, session continuity, and data integrity depending on context. Neither question has a definitive answer in current standards. Both made it onto the proxy BCP outline as topics requiring documented guidance.
The throughline across all of it is the same: RADIUS has been deployed at enormous scale for three decades, and the operational knowledge required to run it well exists in engineering teams, mailing list threads, and institutional memory. The conference is the process of writing that knowledge down before it disappears.
Why we run this conference
Karri Huhtanen from Radiator Software and I started the RADIUS Conference because the people who build and operate these systems had never had a dedicated forum to work through hard problems together. The IETF handles standards. Vendor conferences handle product announcements. Operator forums cover operational issues, but rarely RADIUS specifically. There was no venue where implementors, operators, and standards authors could sit down and compare notes on what is actually happening in production networks.
The detail that an ISP in that room is processing 90% reject traffic does not appear in any RFC. It does not come out of lab testing. It comes from someone who has been running a production network for years and finally had the opportunity to say it in a room where people could do something with the information. That is what the conference is for.
The fixes being developed are real and they are progressing. The proxy BCP document will be the first authoritative record of what works in multi-hop RADIUS environments. The protocol error and reject caching drafts will give servers tools they should have had thirty years ago.
It is slower than anyone would like, but this is how standards get made: one room at a time.
Need more help?
If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise - we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote.
Related Articles
What is a RADIUS proxy?
A RADIUS proxy is a RADIUS server configured to forward authentication requests to one or more other RADIUS servers, rather than authenticating users directly. The proxy sits between the network access server (NAS) and the home RADIUS server that holds the user's credentials.
Separating Authentication from your RADIUS Accounting server
Many ISP networks and enterprise environments handle both Authentication and Accounting functions through the same RADIUS servers and databases. While this configuration works well for small and low-load systems, there are compelling reasons to separate these critical network security functions.