For the past 30 years, RADIUS has had a fundamental problem: in some cases, servers must discard well-formed, authentic packets from known clients.
When something goes wrong in a multi-hop proxy environment (and things do go wrong) you're left guessing. Is the next hop up? Is it down? Is it slow? Does it just not like you today? You simply don't know.
At IETF 124 in Montreal (November 1–7, 2025), we tackled this problem head-on. Our team championed a hackathon project called “Improving RADIUS Proxy Fabrics,” working alongside major RADIUS implementers to solve challenges that have plagued the protocol since its inception.
As a result, FreeRADIUS is now the first RADIUS server with full Protocol-Error support across all corner cases, and this functionality is available today in v3 and what will become v4.
Understanding the Protocol-Error challenge
Here's the problem in plain terms: you send a RADIUS request to a server. The server receives it, verifies it's authentic, confirms it's well-formed, knows exactly who sent it – which is all well and good. But then in some cases, the server throws the request away, and never replies to it. That's pretty unfriendly, and it's also a recipe for network instability.
This becomes especially problematic in proxy environments like eduroam, where authentication requests might traverse multiple hops before reaching their destination.
When a proxy can't route a packet, it has historically just discarded it. The original client has no idea what happened. Was the packet lost? Is there a configuration problem? Is the destination realm offline? Without feedback, troubleshooting becomes guesswork.
It’s a known problem in Accounting, where a server that can’t store the accounting data simply doesn’t respond to the request. The client is then unsure if it should send the request to another destination, or if it should instead just try again later. The result is lost accounting data, and network instability.
Back in 2013, I co-authored RFC 7930, which defined Protocol-Error as a response type. This gave servers a way to say “I received your packet, but I can't process it - here's why.” Despite being a sensible solution, adoption never took off. The specification lacked the details needed by implementers to handle all the corner cases.
Over the past year, I've been writing an updated draft specification that goes through every scenario: when to use Protocol-Error, when not to use it, how to handle edge cases, and what error causes to return. The goal was to implement the document, test it, and prove it works across different RADIUS servers.
Industry collaboration in action
The IETF operates on a principle called “rough consensus and running code.” It's not enough to write a specification and declare victory. You need to build it, test it, and verify that different implementations can work together. Otherwise, you end up with “finished” standards that turn out to be faulty when people actually try to use them.
That's what we set out to do at the IETF 124 hackathon. The project was co-championed by Jan-Frederik Rieckers from DFN and myself, and focused on some draft specifications:
- RADIUS over DTLS
- RADIUS congestion control
- Protocol-Error (our primary focus)
- Proxy best current practices
Our core team included Heikki Vatiainen from Radiator Software and Fabian Mauchle from radsecproxy. Because Montreal is just down the road from Ottawa, our local engineering team was able to participate as well - a nice home-turf advantage.
We spent the hackathon implementing Protocol-Error in our respective servers and testing interoperability. This is where theory meets reality. I had already pushed changes to FreeRADIUS to implement the draft specification. During the hackathon, we tested these changes with Radsecproxy and got feedback from the Radiator team.
In the process, we found compatibility issues. We fixed them. We identified gaps in the specification that needed clarification. We documented everything that implementers would need to know. This is how standards should be developed - not in isolation, but through collaborative implementation and testing.
What this means for network reliability
As of today, FreeRADIUS v3 and the upcoming v4 both support Protocol-Error. You can download it today and start using this functionality immediately. It is 100% compatible with existing RADIUS systems, and it is only used when explicitly enabled.
Here's what changes for network operators:
Better error handling: When a server receives a packet it can't process, it can now send a Protocol-Error response with a specific Error-Cause attribute. Instead of silence, you get actionable information.
Improved proxy chain stability: In multi-hop environments, proxies can now return Protocol-Error with an Error-Cause of “Proxy-Request-Not-Routable” when they can't forward a packet. The original client knows immediately what happened and can take appropriate action.
Faster failover: When servers are overloaded and can't enqueue new packets, they can immediately return Protocol-Error instead of leaving clients waiting for a timeout. This enables quicker error discovery and faster failover to alternative servers.
Congestion control: Busy servers can signal their status explicitly rather than dropping packets silently. This helps clients make better routing decisions.
We've also submitted patches to HostAP, which is used as the basis for many access points. If these patches are accepted and vendors upgrade their access points, Protocol-Error support will become widespread across the industry.
The implementation includes sensible defaults. In FreeRADIUS, Protocol-Error support is controlled by a configuration flag (protocol_error = yes) on a per-client basis. This means you can enable it selectively without changing behaviour for existing deployments. For proxied requests, the server always accepts Protocol-Error responses - there's no good reason to ignore useful error information.
Shaping the future of authentication standards
The hackathon was productive, but it was just one part of a busy week. Throughout IETF 124, our core RADIUS team of five to eight people effectively took over a corner of the Montreal conference centre. We'd filter in and out to attend different working groups, but largely spent our time working through Protocol-Error, advancing the TLS document, and making progress on other specifications.
At IETF Montreal 124 with the RADIUS cabal. From left to right, Heikki, Jan-Frederik, Fabian, Mark, Alex, Margaret, and hidden on the far right, an honorary member discussing QUIC.
Ending authentication misconceptions
One of the outcomes I'm particularly pleased about: we're finally deprecating MS-CHAP. It's been 20 years overdue. This internet-draft, Deprecating Insecure Practices in RADIUS, clearly defines where it's still acceptable to use MS-CHAP and where it's not. Along with this, we're publishing best practices for PAP versus CHAP.
This matters because there are endless pages on the internet claiming that CHAP is more secure than PAP. That's nonsense. Now there will be an official IETF RFC stating clearly: use PAP where possible, here are the trade-offs. This should help counter the “alleged security experts” making recommendations that are, shall we say, surprising.
Having an official standard to point people toward has significant marketing value. When customers or prospects cite bad advice they've found online, we can now reference an IETF RFC rather than just insisting they trust our expertise.
TEAP version 2 advancement
I also presented updates on TEAP version 2 at the EAP Method Update (EMU) working group. The backstory here is somewhat embarrassing for the industry.
Thirteen years ago, when I was co-chair of EMU, we published RFC 7171 defining TEAP version 1. No one implemented it until years later. When Jouni Malinen finally looked at it for HostAP, he discovered many things wrong with the specification. I've spent the last three years trying to fix the document. It turns out it's effectively unfixable.
The TEAP v1 update document is now in its final stages of IETF publication. We've essentially labelled it as “this is what we wrote, here are the parts people implemented, everything else is Here Be Dragons.” We're learning from those mistakes with TEAP v2, which I presented at IETF 122 in Madrid and again at IETF 124 with further updates.
Other standards progress
We're also advancing the EAP.ARPA document, which defines how to handle captive portals in 802.1X environments. This should be published shortly, and there are already three or four documents proposing to use it.
The TLS document received significant attention throughout the week. Getting these specifications right matters, because they'll form the foundation for secure authentication for years to come.
Formalising RADIUS leadership
Beyond the technical work, IETF 124 advanced our industry relationships in important ways.
The Wireless Broadband Alliance (WBA) submitted an official liaison statement to the IETF. I attended a meeting with the IETF chair, the IAB chair, and Bruno Tomas from the WBA to discuss how our organisations should work together. The outcome, which should be formalised around January 2026, is that I'll be appointed the official liaison between the WBA and the IETF.
This formalises what has been a somewhat ad hoc relationship. When people in the WBA have IETF questions, they can ask me. When people in the IETF have questions about the WBA, they can ask me. It's not a lot of work, but it creates an official channel for coordination.
We also discussed hosting the RADIUS Conference as a side meeting at next summer's TNC conference in Helsinki. Klaas Wierenga from GÉANT is in favour of this idea. More details on that as plans develop.
The reality of Wi-Fi standards
I'd be remiss not to mention one of the more entertaining aspects of the past few weeks. The Wi-Fi Alliance held a session in Amsterdam where they spent 30 minutes discussing why their Passpoint profiles don't work.
Passpoint was designed to make Wi-Fi configuration easier. In practice, many elements are broken, and OS vendors often implement it incorrectly. Most Wi-Fi attendees did not use Passpoint profiles to join the conference Wi-Fi network.
The Alliance also discussed challenges with locked-down enterprise devices. Many corporate devices require IT admin access to install new Wi-Fi profiles, which creates accessibility problems. They're working on solutions, though I suspect this is one of those problems that's easier to describe than solve.
Available today
The RADIUS community has spent 30 years working around the protocol's limitations. With Protocol-Error support now implemented and tested, we're finally addressing one of those fundamental issues.
FreeRADIUS is the first RADIUS server to fully support Protocol-Error across all corner cases. The functionality is available today in FreeRADIUS v3 and the upcoming v4.
Over the next year or two, we expect other RADIUS servers to roll out similar support. When that happens, proxy chains will become more stable, failover will happen faster, and troubleshooting will become less of a guessing game.
Implementation notes for Protocol-Error in FreeRADIUS are available on GitHub.
If you're running eduroam infrastructure, managing authentication for a large enterprise, or operating RADIUS in any multi-hop environment, Protocol-Error support can improve your network's reliability. The implementation is controlled by configuration flags, so you can enable it selectively without disrupting existing deployments.
Need help?
Implementing RADIUS Active Directory integration correctly requires deep expertise in both technologies. InkBridge Networks has helped hundreds of organisations deploy secure, scalable RADIUS infrastructure.
Whether you're implementing your first RADIUS server or upgrading enterprise infrastructure, InkBridge Networks has the expertise to ensure your success. We're the team behind FreeRADIUS and have been solving network authentication challenges for over 25 years.
Get in touch to request a quote or explore FreeRADIUS support options.
Related Articles
How to connect FreeRADIUS to Active Directory for authentication
Active Directory is widely used in the enterprise and university systems. This article describes how to connect FreeRADIUS with Active Directory, allowing you to authenticate users against your existing directory service while leveraging the power of your RADIUS server for network access control.
Configuring FreeRADIUS authentication with PAP (Password Authentication Protocol)
Password Authentication Protocol (PAP) is one of the most fundamental authentication methods used in Remote Authentication Dial-In User Service (RADIUS). Despite being one of the oldest authentication protocols, PAP remains an essential starting point for configuring your authentication server properly.