I've recently returned from IETF Bangkok, the Internet Engineering Task Force (IETF) 122 meeting, where I spent a week working with implementers, operators, and standards authors who are defining the future of RADIUS and other network protocols.
After decades of attending these meetings, I can honestly say this one was very productive for me. The jet lag was brutal (48+ hours of travel time due to a stop in Tampere for the RADIUS Conference and a few passenger emergencies on flights along the way), but the results were worth it.
A very positive result for RADEXT at IETF Bangkok
The RADIUS-related meetings went surprisingly well. We achieved more results than I've seen in years, with clear agreement between implementers and operators on how to move forward with several key initiatives.
I presented the outcomes of the RADIUS Conference to the IETF RADIUS Extensions (RADEXT) working group. There was consensus that the issues were real and that they should be added to the list of work items for RADEXT. These documents will likely be started in June, just in time for the next IETF in Madrid in July.
The outcomes were tangible:
- Technical consensus: We found common ground between implementers and operators on several thorny issues that have been lingering for years. The consensus has led to some concrete outcomes, which are outlined in the next item.
- New standards documents: We've got 3–4 new documents coming out of the meeting, and the good news is that I'm not on the hook to write all of them. That's a welcome change. The proposed documents are:
- Improved signalling between proxies when they cannot forward a packet. This change makes it easier for organizations to manage interactions between chains of proxies.
- Add a “negative cache”. Many proxies have a problem with invalid or abusive users overloading the systems. A negative cache will allow proxies to discard substantial amounts of inappropriate traffic.
- A “best practices” document for proxies. There is a substantial amount of experience running RADIUS proxies. It’s time that this experience was written down.
- Practical solutions: Some of the most valuable outcomes weren't massive protocol changes but elegant and tightly focussed solutions to everyday problems that network administrators face.
An elegant solution to a common problem
One of the highlights came during a discussion about proxy failover. Proxies historically have issues with failover and multi-packet exchanges (e.g. EAP). Proxies are stateless, so they don’t track EAP sessions. This is good for scalability, but it means that when a failover occurs, proxies don’t know which packets need to be sent to which home server. Discussions during the meeting led me to propose a very simple solution to this complicated problem.
The beauty of this solution is that it can be implemented unilaterally—there is no need for everyone to upgrade their servers simultaneously, or even to coordinate changes. Instead, you can implement it on your end, and you immediately get the benefits.
When I explained the solution at the meeting, I watched several experienced engineers have that "aha" moment where they immediately recognized the potential.
One colleague couldn’t help but blurt out, "Oh wow, that will work". We immediately had buy-in from multiple vendors who all agreed both that it will work, and that they will be implementing it in their products.
I won’t get into the technical details of the solution, as it involves some esoteric games with the RADIUS protocol. It’s useful enough that server vendors have agreed to implement it, but also weird enough that it won’t ever be in a standards document. That’s fine.
When I explained the solution at the meeting, I watched several experienced engineers have that "aha" moment where they immediately recognized the potential.
We'll be implementing this solution in our network protocol products over the next couple of months. I briefly considered patenting it, but honestly, I'd rather see the entire industry benefit. That's always been our approach at InkBridge Networks—raise all boats rather than build walls.
eduroam turns 25 next year
I also had a good chat with Klaas Wierenga about eduroam's upcoming 25th anniversary in 2026. As the founder of eduroam and current CITO at GÉANT, Klaas expressed interest in a commemorative event, potentially alongside the TNC conference (though the location for next year’s TNC hasn't been announced yet).
There's a natural synergy between eduroam and FreeRADIUS that goes back decades. In his RADIUS Conference presentation, Klaas specifically noted that "eduroam really couldn't exist without stuff like FreeRADIUS." We've been working in parallel all this time—our open-source RADIUS server is enabling their global roaming service, which in turn drives innovation in authentication protocols.
I've offered to sponsor some of the anniversary celebrations. After all, eduroam has been good for us, and FreeRADIUS has been good for eduroam. I’ve also suggested that I give a talk which draws parallels between the evolution of open source and eduroam over the past quarter-century. Both projects have transformed over time from niche technical solutions to become key global infrastructure that hundreds of millions of people rely on daily.
The lighter side of travel
It wasn't all technical discussions, of course. Bangkok provided a colourful backdrop, from the impressive skyline to the somewhat alarming electrical installations (picture rows of tangled cables with a technician 20 feet up on a bamboo ladder—safety third!).
And since I was in Finland during the Conference, I participated in the classic Finnish tradition of sauna followed by a plunge into an ice-cold lake. I have video evidence of this questionable decision, and I can confirm that it was heart-stoppingly cold—even with a couple glasses of rosé for courage.
What's next with IETF and RADIUS
We're already working to implement the insights and technical decisions from Bangkok. This work will strengthen InkBridge Network's authentication products and the open-source FreeRADIUS server that powers networks worldwide.
Looking ahead to IETF 123 in Madrid this July, we'll be continuing to build on this momentum. The new documents should be ready for initial review by then, and I expect we'll see even more implementations of the proxy failover solution we discussed in Bangkok.
The progress at IETF Bangkok reinforces my belief that collaboration between implementers and operators is essential for developing protocols that actually work in the real world. Over the years, I've learned that the best solutions emerge when people with different perspectives come together to solve common problems. Since the RADIUS conference was useful (both in person, and virtual), we are planning on holding a repeat event!
Stay tuned for some exciting announcements in the coming months as we roll out these innovations.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
Looking Forward to IETF 122
We have been involved in the Internet Engineering Task Force (IETF) for a few decades now. During that time, we have written many of the RADIUS standards. We are still involved in the standards process, and this post explains how the new standards will affect you.
Introducing RADIUS 1.1
RADIUS has a problem. The name of the problem is MD5. The MD5 hash algorithm was defined in 1991, and was used in RADIUS in 1993. However, MD5 is no longer secure. It is a bit of a miracle that RADIUS is still safe to use, even though it is using 30 year-old cryptographic primitives!