Port 1813: RADIUS Accounting — The Ledger of Every Connection

Port 1813 carries RADIUS Accounting traffic. Every time someone connects to a corporate network, authenticates to enterprise WiFi, or in the early days picked up a phone and dialed into the Internet, port 1813 recorded the evidence: when they connected, how long they stayed, and how much data they consumed.

This is the ledger of the networked world.

What RADIUS Accounting Does

RADIUS Accounting is half of a pair. Port 1812 handles RADIUS Authentication, the gatekeeper that asks "who are you?" and decides whether to let you in. Port 1813 handles Accounting, the bookkeeper that watches what happens after you're inside.

When you connect to a network that uses RADIUS, three things happen on port 1813¹:

1. Accounting-Start: The Network Access Server (NAS) sends a packet to the RADIUS server announcing that you've connected. This record includes your username, your IP address, your point of attachment, and a unique session identifier.

2. Interim-Updates: Periodically during your session, the NAS sends updates. Bytes transferred. Packets sent. Time elapsed. These updates ensure that if the connection drops unexpectedly, there's still a record of what happened.

3. Accounting-Stop: When you disconnect, a final packet captures the total session duration, total bytes in and out, total packets, and the reason the session ended.

The RADIUS server receives these packets, validates them using a shared secret (never transmitted over the network), timestamps them, and stores them. The data becomes billing records, audit trails, capacity planning metrics, security forensics.²

How the Protocol Works

RADIUS Accounting uses UDP, not TCP. This is a deliberate choice from an era when reliability was expensive and network access servers needed to be fast and cheap.³

The protocol is stateless. Each Accounting-Request packet stands alone. If the RADIUS server successfully records the data, it sends back an Accounting-Response. If it can't record the data for any reason, it stays silent. No response means the NAS should retry or try an alternate server.

The packet format uses Attribute-Length-Value (ALV) tuples, making the protocol extensible. RFC 2866 defines attributes 40 through 51⁴:

This simplicity is why RADIUS has survived for over thirty years. The protocol does exactly one thing: record what happened, reliably enough for billing.

The History: Why Counting Mattered

In 1991, the National Science Foundation had a problem.⁵

NSFnet, the backbone of what would become the Internet, needed dial-in access. People across America wanted to connect their computers to this new network using their phone lines and modems. But the NSF had a rule: no proprietary servers. Everything had to be commercial, interoperable, standards-based.

Merit Network, the organization running NSFnet, issued a Request for Information. They needed a way to let people dial in, authenticate them, and track their usage. Six months later, a small company in Pleasanton, California responded.

Livingston Enterprises, founded by Ronald and Steve Willens, proposed something new: a protocol for remote authentication that could work with any Network Access Server. They called it RADIUS, Remote Authentication Dial-In User Service.⁶

Merit awarded Livingston the contract. The first RADIUS servers went into production on Merit's MichNet network, letting people across Michigan dial in and connect to NSFnet. The protocol worked so well that other organizations started asking for it.

By April 1995, when Carl Rigney chaired the RADIUS Birds of a Feather meeting at the 32nd IETF in Danvers, Massachusetts, RADIUS had been in production use at "many sites for over two years."⁷ The protocol was standardized as RFC 2058 and RFC 2059 in 1997, then updated to RFC 2865 and RFC 2866 in 2000.

There's a detail in the RFC that reveals the protocol's rushed early deployment: the original port numbers were wrong. RADIUS Authentication started on port 1645, which conflicted with the "datametrics" service. RADIUS Accounting started on port 1646, which conflicted with "sa-msg-port." The IANA-assigned ports, 1812 and 1813, came later.⁸ To this day, many RADIUS servers listen on both sets of ports for backward compatibility.

The Weight of What It Carries

Think about what port 1813 has witnessed.

Every dial-up connection in the 1990s. The screech of modems negotiating at 56 kbps. The college student at 2am downloading their first MP3. The small business owner checking email for the first time. The researcher at a university library, suddenly able to search databases across the country. Port 1813 recorded when they connected, how long they stayed, how many bytes they transferred.

Those records became phone bills. ISPs charged by the minute in the dial-up era, and RADIUS Accounting was how they knew what to charge. The Acct-Session-Time attribute, measured in seconds, determined whether your monthly bill was $19.95 or $200.

When Lucent Technologies acquired Livingston Enterprises in 1997, they weren't buying a small hardware company. They were buying the protocol that powered dial-up access for much of the Internet.⁹

Today, port 1813 carries different traffic but serves the same purpose. Every corporate VPN connection. Every laptop authenticating to enterprise WiFi via 802.1X. Every guest connecting at a hotel or airport. The accounting records flow to RADIUS servers that log session data for security audits, compliance requirements, and capacity planning.¹⁰

The protocol that counted dial-up minutes now counts gigabytes on enterprise networks.

Security Considerations

RADIUS was designed in 1991, when the threat model was simpler. The protocol has survived, but it carries scars.

The BlastRADIUS Attack (2024): In July 2024, researchers from UC San Diego, CWI Amsterdam, Microsoft, and BastionZero disclosed CVE-2024-3596, a fundamental vulnerability in how RADIUS validates responses.¹¹ The attack exploits RADIUS's use of MD5 for authentication. An attacker positioned between a RADIUS client and server can forge responses, turning a Reject into an Accept, potentially granting unauthorized network access.

The attack requires the attacker to be on the network path and to compute an MD5 collision within the RADIUS timeout window (30-60 seconds). Modern GPUs make this feasible. The vulnerability affects all RADIUS/UDP deployments that don't use EAP authentication methods.

Recommended Mitigations¹²:

• Use RADIUS/TLS (RadSec) instead of RADIUS/UDP
• Require the Message-Authenticator attribute on all packets
• Tunnel RADIUS traffic through IPsec or VPN
• Block RADIUS/UDP from Internet-facing interfaces
• Never send RADIUS traffic over untrusted networks

The Shared Secret Problem: RADIUS authenticates packets using a shared secret between client and server. This secret is never transmitted, but if it's weak or compromised, all traffic between that client-server pair is vulnerable. Strong, unique shared secrets per client are essential.

Plaintext Attributes: While RADIUS encrypts the User-Password attribute, many other attributes travel in plaintext. Session IDs, usernames, IP addresses, byte counts, these are all visible to anyone who can capture the UDP packets. This is another reason to tunnel RADIUS traffic through encrypted channels.

Related Ports