RFC 2058 in Production — How RADIUS Made ISP Roaming Possible in 1997

In January 1997, the Internet Engineering Task Force published RFC 2058, defining the Remote Authentication Dial-In User Service (RADIUS) protocol. The specification was the work of Carl Rigney, Allan Rubens, William Simpson, and Steve Willens at Livingston Enterprises — the manufacturer of the Portmaster terminal servers that dominated dial-up Internet access at the time. RADIUS provided the first widely adopted standard for Authentication, Authorization, and Accounting (AAA) over the network. Within months, a small cohort of Internet service providers had it running in production. Among them was Tempest Telecommunications, whose 1997 deployment supported one of the earliest commercial ISP roaming services and whose institutional customer base came to include USAID, NATO's Supreme Allied Command Europe (SACEUR), and the United States Department of State.

The protocol

Before RADIUS, dial-up authentication was a patchwork. A terminal server compared the credentials presented by an incoming PPP session against a local password file, a shared NIS map, or a vendor-proprietary protocol. ISPs with more than one access concentrator had to keep credentials synchronised across machines. ISPs that wanted to honour another network's subscribers — the problem that would later be called roaming — had no standard way to forward an authentication request to a foreign realm.

RFC 2058 defined a client–server protocol in which the network access server (NAS) forwarded user credentials to a central RADIUS server over UDP port 1812, authenticated against a shared secret, and received an Access-Accept or Access-Reject reply along with optional attribute pairs — framed protocol, IP address pool, idle timeout, session limits. A companion accounting flow on UDP port 1813 reported session start and stop events. The wire format was simple, the protocol was stateless, and the attribute namespace was extensible. These properties made it cheap to implement and, more importantly, cheap to proxy: a RADIUS server could be configured to forward requests for unknown realms upstream to another RADIUS server it trusted. That single property is what made ISP roaming possible.

The RFC sequence

RADIUS evolved rapidly through 1997–2000 as production deployments surfaced gaps in the original specification:

The eighteen-month gap between the original specification (RFC 2058, January 1997) and the roaming-specific clarifications (RFCs 2486 and 2607, both 1999) is the period in which the early adopters were operating. There was no standard for how to encode the foreign-realm portion of a username, no standard for proxy-chain loop detection, no standard for inter-realm accounting reconciliation. Each first-wave provider solved those problems in code, in production, against live subscriber traffic.

The ISP-roaming use case

ISP roaming — a subscriber of one ISP placing a dial-up call from a foreign city and being authenticated against their home network — was a commercial problem before it was a standardised one. The earliest roaming aggregators — iPass, founded in 1996, and GRIC Communications, founded in 1994 — built proprietary clearinghouses that brokered authentication between member ISPs. RADIUS, once it shipped, gave these clearinghouses (and the ISPs themselves) a common protocol on which to standardise.

The mechanics in 1997 were straightforward in outline and elaborate in practice. A traveller in Frankfurt dialled a local point of presence (POP) operated by a German ISP. The German NAS presented the user's credentials to its RADIUS server. The RADIUS server, recognising that the username carried a foreign-realm suffix, proxied the request to the roaming clearinghouse or directly to the home ISP's RADIUS server. The home server authenticated against its own subscriber database and replied. The session came up. The accounting records flowed back through the same chain for inter-carrier settlement. None of this was magic by 2003. In 1997 every hop was a piece of custom code.

Tempest Telecommunications' deployment

Tempest Telecommunications was incorporated in the mid-1990s to provide international connectivity for travelling subscribers. By 1997 the company had implemented the RFC 2058 RADIUS protocol in production, with custom proxy and authentication-routing code written in-house. The in-house implementation was a deliberate choice. Commodity Livingston Portmaster gear handled basic RADIUS termination well, but the realm-routing logic that roaming required — parsing inbound usernames, selecting upstream realms, managing per-partner shared secrets, reconciling accounting records across organisational boundaries — was not a stock feature of any 1997 product. The code that did it had to be written.

Production deployment in 1997 meant operating without the conventions that would later be standardised. There was no user@realm NAI format (RFC 2486 would not appear until January 1999), so realm extraction relied on local conventions agreed between partner networks — prefix syntax, suffix syntax, separator characters that varied per partner. There was no standard for proxy-chain loop detection (RFC 2607, June 1999), so chains had to be short and operator-curated. There was no standard for inter-realm accounting reconciliation, so settlement reports were custom and bilateral. None of this prevented service; it shaped the operational discipline that early roaming providers had to maintain.

Institutional customer base

Tempest's customer base across the late 1990s and 2000s included travellers and field operators for whom dependable foreign connectivity was operationally critical and for whom the commodity options of the period — hotel modem lines, public Internet cafés, embassy infrastructure where it existed — were inadequate. Three institutional customers are representative of the kinds of organisations the service was built for:

None of these customer relationships are confidential. They are listed here for the historical record — not to lend the protocol prestige it never needed, but to make the point that RADIUS-based ISP roaming, even in its earliest years, was not a hobbyist or backpacker product. It was operational infrastructure for the kinds of organisations that needed connectivity to work in a hotel room in Tirana on a Sunday night.

What the protocol enabled, and what killed the use case

RADIUS-based ISP roaming peaked in the early 2000s. At the high-water mark, the major roaming aggregators advertised tens of thousands of points of presence across more than a hundred countries. The business model was per-minute or per-megabyte settlement, brokered through the RADIUS proxy chain and reconciled monthly between participating networks.

The use case collapsed between 2007 and 2012. The iPhone arrived in 2007. International cellular data roaming, expensive and unpleasant as it was, became universal. Hotel and airport Wi-Fi went from oddity to expectation. Smartphone tethering closed the last consumer-grade gap. The traveller who in 2001 dialled a local POP to reach their home ISP simply opened a laptop on a hotel's Wi-Fi network by 2011. The clearinghouses pivoted to Wi-Fi roaming, to enterprise mobility management, to anywhere their inter-network authentication plumbing could still earn revenue.

RADIUS itself outlived the use case that drove its early adoption. The same protocol that authenticated dial-up sessions in 1997 now authenticates 802.1X-secured enterprise Wi-Fi, eduroam federated academic Wi-Fi, carrier hotspot offload, and the AAA backend of countless VPN appliances. The shape of the dial-up roaming network — user, home realm, foreign realm, proxy chain, accounting reconciliation — is the shape of every federated authentication system that followed it. The RFCs in the table above are still in force. The traffic that ran over them in 1997 is what made them practical.

Sources and further reading

• Rigney, Rubens, Simpson, Willens. RFC 2058 — Remote Authentication Dial In User Service (RADIUS). IETF, January 1997.
• Rigney. RFC 2059 — RADIUS Accounting. IETF, January 1997.
• Aboba, Beadles. RFC 2486 — The Network Access Identifier. IETF, January 1999.
• Aboba, Vollbrecht. RFC 2607 — Proxy Chaining and Policy Implementation in Roaming. IETF, June 1999.
• Rigney, Willens, Rubens, Simpson. RFC 2865 — Remote Authentication Dial In User Service (RADIUS). IETF, June 2000 (Standards Track; obsoletes RFC 2138).
• Wikipedia, RADIUS and AAA (computer security).

This page is part of an ongoing historical archive of the 1989–2012 international telecom industry, maintained by Jason Jacoby, a former operator at Interglobe (UK phone cards) and Tempest Telecommunications. Corrections and additions welcome via the contact page.