Vienna was quiet on the RADIUS front. The AI problem was anything but.
Alan DeKok, CEO and Founder, InkBridge Networks
I was in Vienna for IETF 126 in July, and I came back thinking about spam.
Starting in the 1990s, spam arrived uninvited, clogged email inboxes, and consumed enormous amounts of time from the people who had to deal with it. Every serious email provider was eventually forced to build increasingly sophisticated filters just to keep systems functional.
The IETF has a spam problem now, in the form of AI-generated contributions.
The report from IETF 126: AI has removed the limits to bad participation
The IETF is built on openness. Anyone can join a working group, submit a document, or post to a mailing list.
For most of the organisation’s history, this openness worked because participation had a natural cost: time, effort, and expertise. If you wanted to submit a serious proposal, you had to read the existing literature, understand the constraints, and produce something coherent. That was a filter, even if nobody thought of it that way.
AI has removed that filter.
What I saw in Vienna, and what was discussed publicly at the IETF 126 plenary, with video on record, is that several working groups are now getting deluged with AI-generated documents and mailing list messages. The content uses the right vocabulary and is structured like a standards document, but it’s mostly nonsense.
The people producing this content fall into two rough groups.
The first are straightforward bad actors, the digital equivalent of internet trolls. Those bad actors are now equipped with a tool that lets them generate a thousand times more noise than they could previously create. Before AI, even the most committed troll was constrained by the hours in a day. That constraint is now gone.
The second group is subtler, and in some ways more difficult to address. These are people with genuine ideas (or what they believe are genuine ideas) who have discovered that typing a prompt into an AI system can produce a 70-page document. They submit it to the relevant working group as a contribution, believing they have done something useful. The document may contain a real insight buried under layers of generated scaffolding. But nobody can find it, because finding it would take longer than it took to produce the document in the first place.
I call this AI-supported incompetence, to distinguish it from what people usually mean by “AI slop.”
AI slop implies carelessness about quality. AI-supported incompetence is what happens when someone who lacks the technical grounding to participate in a standards process is given a tool that makes participation frictionless.
Why the IETF is especially exposed
The IETF’s openness is a core value. The organisation has always believed that good technical ideas should be able to enter the process regardless of who proposes them. That belief has produced some of the most important protocols on the internet.
But openness has a cost, and AI has made that cost much higher.
There is an asymmetry at the heart of this problem: it is far easier to generate a submission than to review one. A working group participant who has spent 20 years developing expertise in a narrow area of network protocols has a fixed amount of time. Reviewing a poor submission wastes that time. A hundred poor submissions make the working group functionally unusable. The cost of generating the noise is close to zero; the cost of filtering it falls entirely on the community.
This is the same dynamic that made email spam so destructive, and the same dynamic that made it so difficult to solve. With spam, the sender pays almost nothing to reach your inbox; you pay real time and attention to deal with it. The asymmetry is structural, and the IETF has no obvious mechanism to change it.
Other standards bodies do not have this problem in the same way. If your company pays $50,000 a year for membership in a standards body, its employees are not going to send hundreds of garbage submissions. The IETF’s free-to-participate model is a genuine strength, but it is also a vulnerability.
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!)
What might work to cut down on AI-supported incompetence
There are a few approaches being discussed, and I think one of them has real promise.
The most obvious response is AI-against-AI: writing detection tools to flag and discard generated content before it reaches reviewers. Some working groups are already experimenting with this. I am sceptical. Detection is a statistical game, and the people generating this content can use AI to fight back against the filters. It is an arms race, and arms races tend not to end well for the defenders.
Again, think of spam. In thirty years, no one has fixed the spam problem. We have every reason to believe that AI submissions will be similarly hard to address.
Watermarking has also been proposed, requiring AI systems to embed identifiable signals in generated text. The problem is similar: watermarking is statistical, and sophisticated AI systems can be trained to strip watermarks from other systems’ output.
What I think will work is reputation. The IETF already runs informally on reputation. If you have been on a mailing list for 20 years, people know your name, read your documents, and (generally) trust your contributions. If you have never appeared before, you are an unknown quantity, and unknown quantities are increasingly being treated with suspicion.
That approach can be formalised by rate-limiting new participants, deprioritising documents from authors with no track record, and giving community interaction a measurable weight in how submissions are surfaced. These processes don’t have to be formalised by the IETF, I suspect that most people are doing this already in an informal / personal matter.
Such filtering is not perfect, but it is neutral. It does not require content filtering, which immediately raises questions about who decides what is valid. A new email address that has never posted before is a fact, not an editorial judgement. That distinction matters when you are trying to build a solution that the community will accept.
The historical parallel is instructive. The internet’s spam problem was never fully solved; it was managed. The solutions that worked best were not content-based but behaviour-based: reputation scoring, rate limiting, community feedback loops. I expect the IETF can end up in a similar place.
What moved on the RADIUS front
There was not a great deal of technical progress in the RADEXT working group at Vienna. The blocks on the charter are being removed, which is genuinely welcome news. It means documents that have been waiting in the queue can start moving again.
The document I am most closely watching is RadSec (technically the RADIUS over TLS update, or DTLS-bis) which is still working through the IESG review process. Once it clears, it opens the door to publish the companion documents that have been waiting behind it: the review of RADIUS security and privacy, and the deprecating insecure practices document.
Those two pieces effectively tell the complete story of how RADIUS got here and what operators need to do differently. I have written about this security direction at length in Making RADIUS more secure. The sequencing matters: publish the historical review document first, then the RadSec standard, then the document that deprecates insecure / historical practices. The group has already largely approved all documents; the bottleneck is currently TLS-bis, and I am hopeful that it moves quickly.
I also brought a new problem statement to RADEXT: accounting overload with AP roaming. This is something ISPs and Wi-Fi operators have been dealing with for years. When devices roam between access points rapidly, the accounting messages can flood the RADIUS server in ways the protocol was never designed to handle.
There was strong support for the idea on the mailing list before Vienna, and the working group response confirmed it is worth pursuing, even if the current documents rightly take priority. There is no draft yet, but I expect that to change before San Francisco.
Looking ahead to IETF in San Francisco
The November meeting is in San Francisco, and I will be there, partly for the work, partly to see people I have not seen in a while.
There has been substantial discussion in the IETF community about whether San Francisco is the right venue, given the current political climate. The visa situation for international participants is difficult, and some people who attended previous meetings were unable to get through previous US border crossings.
The IETF’s response has been measured: there is no country in the world that lets everyone in, and every venue takes someone out of the conversation. The Shenzhen meeting in March was difficult for some participants for different reasons, and the Kuala Lumpur meeting coming up in 2027 will be legally impossible for others.
I am curious to see who turns up in San Francisco and who does not. On the technical side, the goal is clear: keep the RADIUS security documents moving, get RadSec across the finish line, and start building the accounting overload work into something the group can act on.
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
IETF 124, Montreal QC, Canada Global RADIUS standards taking shape in Canada
InkBridge Networks joins IETF 124 in Montreal to advance secure RADIUS standards, collaborate with global experts, test implementations, and shape authentication infrastructure’s future worldwide.
IETF Bangkok 122 recap: What we're doing to advance RADIUS standards
At IETF 122 in Bangkok, experts reached consensus on RADIUS proxy standards and failover improvements, which InkBridge plans to implement across FreeRADIUS and commercial products.