RADIUS 1.1 and the BlastRADIUS Fix: Secure the Servers First

Last month a leasing customer pinged me about scaling their authentication tier across a new block, and the conversation stalled the moment I asked what the RADIUS server was actually doing on the wire. Their ISP edge has spoken RADIUS to the same authentication server since before half their current staff were hired. Nobody touches it, it works, and that turned out to be the whole problem. The protocol underneath it was designed in 1991, leans on MD5 for the integrity of its most sensitive attribute, and has been quietly carrying that assumption forward for three decades while everything around it was hardened.

In May 2026, Alan DeKok, who wrote a large share of the RADIUS standards and has worked on the protocol since 1999, gave a talk at NZNOG in Christchurch and got quoted on a line that has stuck: RADIUS is the protocol that will never die. Diameter was supposed to replace it and ended up confined to a narrow set of carrier cases. In enterprise networks, ISP networks, eduroam, and 802.1X, RADIUS is still the only real option. So the live question is not how to retire it. It is how to make a 1991 protocol safe for the next thirty years, and that answer is moving through the IETF's RADEXT Working Group right now.

I sit on the commercial side of IP infrastructure, not in RADEXT. But the order of operations DeKok is laying out matters to anyone who runs authentication on space they lease or buy. My argument is simple: fix the servers before you chase the edge, and never let "we deployed TLS" stand in for verifying the one mitigation that actually stops the known attack.

Why a 1991 Protocol Is Still a Live Exposure

The cryptographic assumption baked into RADIUS in 1991 was MD5, and MD5 has been considered broken for the better part of twenty years. The practical consequence is narrower than "MD5 is broken" sounds, which is part of why it gets ignored. RADIUS/UDP over the Internet offers weaker protection than most operators assume, and the security of the User-Password attribute is only as strong as the shared secret behind it. With modern GPU hardware, a shared secret of eight characters or fewer can be cracked essentially immediately. Plenty of deployed infrastructure has historically run on exactly those weak secrets.

BlastRADIUS, disclosed in 2024, turned that abstract weakness into a concrete attack. An adversary positioned on the network path between a Network Attached Storage device and the RADIUS server can exploit the missing integrity protection on Access-Request packets to forge an authentication response, handing someone arbitrary access. What should give operators pause is how long the fix sat on the shelf.

DeKok first flagged the design flaw in 1997. He wrote RFC 5080 in 2007, recommending that servers include the Message-Authenticator attribute on every Access-Request packet. FreeRADIUS implemented that in 2013. BlastRADIUS, in 2024, revealed how many vendors had shipped a decade past that advice without acting on it. That gap, between what the standards say and what field equipment does, is the real subject, and it is an installed-base problem rather than something you can buy your way out of.

The Argument for Securing Servers Before the Edge

This is where I part company with the instinct to "patch everything." On a typical network there are a hundred or more edge devices for every RADIUS server, spread across dozens of vendors, each with its own firmware roadmap and its own track record on compliance. BlastRADIUS showed how slowly fixes travel through that population; some vendors, asked to implement the mitigations, were still not shipping recommendations from 2007.

Against that, there are fewer than ten RADIUS server implementations in widespread use, and nearly all of them are actively involved in RADEXT. That asymmetry is the whole strategy. New standards prioritize what can be implemented in servers and proxies first, because that is where a small number of changes produce immediate, broad protection, even while the NAS at the edge is still speaking plain RADIUS/UDP. The perimeter moves outward as edge devices catch up, which they will, slowly.

For an operator the takeaway is unglamorous and correct: you do not need to win the edge before you reduce risk. You secure the server-to-server and server-to-proxy links you control, today, and you stop treating the slow vendor refresh cycle as a reason to do nothing.

What RADIUS 1.1 Actually Changes

RADIUS 1.1 is the most significant document in the RADEXT pipeline, and it makes two changes worth understanding precisely.

First, it removes the dependency on MD5 by running over Transport Layer Security. The transport layer handles integrity and confidentiality, and MD5 is removed for all RADIUS traffic inside the TLS tunnel. That makes RADIUS fully FIPS-140 compliant, a hard requirement for government and regulated-industry deployments, and historically a sticking point because of MD5.

Second, it lifts the 8-bit packet identifier limit. The original protocol capped any single connection at 256 outstanding packets, which forced slow traffic across many connections. A 32-bit Token field raises that ceiling to four billion outstanding packets per connection, which matters for high-throughput ISP and carrier environments.

The detail that changes how you should plan: RADIUS 1.1 is negotiated per connection and is backwards compatible. If one end does not support it, the exchange falls back gracefully. From an operator's seat it is a configuration flag, not a migration project, and the language matters, because treating it as a project is how it gets deferred indefinitely.

Two companion documents round out the near-term work. One formalizes TLS-PSK, giving you the security of TLS without standing up a full PKI; pre-shared keys are administratively comparable to managing a shared secret, which removes the usual excuse that certificates are too much overhead. The other formally deprecates bare UDP and TCP for RADIUS across the public Internet. That advice is not new, but normative IETF language changes the conversation with a vendor from "optional" to "you are out of spec."

The Migration Decisions Operators Get Wrong

Reading the standards is rarely what stalls a rollout. What slows teams down is the handful of judgment calls around them, and those are worth talking through rather than tabulating, because the reasoning is what travels to your own deployment.

Start with the choice between TLS-PSK and full certificate-based TLS. The reflex is to reach for PKI on the theory that certificates sound more secure, and that reflex costs you. For the server-to-server and server-to-proxy links that this work targets, TLS-PSK is the better answer: it is in FreeRADIUS today, it sidesteps the certificate-renewal failures that take services down on their own, and a pre-shared key is administratively about as heavy as the shared secret you already manage. Pick PKI only where you genuinely need certificate-based identity, not because it reads as the premium option.

The decision that gets the most people, though, is believing the work is finished once TLS is on. A tunnel and Message-Authenticator enforcement are two different controls, and shipping the first while assuming it covers the second is exactly the mismatch BlastRADIUS exploited at the vendor level. So verify them separately: confirm the server enforces the Message-Authenticator attribute on every Access-Request packet, because that step, not the tunnel, was the actual BlastRADIUS mitigation. DeKok's own operator advice lists it as a distinct check for that reason. If you cannot confirm it is enforced, the inability to confirm is itself a finding worth surfacing.

Sourcing is the next call: self-managed FreeRADIUS or a managed cloud service. It is tempting to decide this on licensing cost, and that lens misleads, because FreeRADIUS carries no licence fee yet demands real Linux expertise to run safely, while a managed service converts that expertise into a recurring bill. Choose on the skills your team actually has, not on the headline price.

Finally, timing. The instinct is to wait for a tidy migration window before turning RADIUS 1.1 on, and there is no need to wait, because the feature is negotiated per connection and falls back gracefully when the far end does not speak it. Enable it on your server-to-server connections the moment your implementation supports it; there is no flag day to schedule around.

Of those four, the TLS-versus-enforcement confusion is the one I would push hardest on with a customer. The standards do the heavy lifting; the place deployments quietly stay exposed is the assumption that a visible TLS rollout has already closed the specific hole that made the headlines.

What This Has to Do With Leased Address Space

I run sales for an IPv4 marketplace, so my interest here is honest and narrow: when an organization scales a network on leased IPv4 blocks, the authentication layer riding on that space has to hold up over years, not quarters. A protocol that quietly depends on a 1991 hashing assumption is the kind of long-tail liability that never shows up in a procurement checklist and always shows up in an incident report. The work in RADEXT is the most substantial update to RADIUS security since the protocol was defined, and that is the same posture we take on the address space itself: get the foundation clean before you build volume on top of it.