RADIUS and AAA: How ISPs Authenticate and Account for Subscribers

When a subscriber session comes up, three questions get answered in a fraction of a second: who are you, what are you allowed to do, and how much did you use? Those map exactly onto AAA — Authentication, Authorization and Accounting — and for the overwhelming majority of ISPs, the protocol that carries them is RADIUS. It is not glamorous. Most operators only learn how central it is the first time it falls over and every customer on the network drops at once.

The thing worth internalising is that RADIUS is not really a networking protocol in the routing sense — it is the place where your business meets your network. The speed a customer gets, whether their account is permitted online at all, and the byte counts behind their invoice all pass through this one exchange. Understanding it well is the difference between a billing system that drives the network automatically and one that needs an engineer logging into a router every time a plan changes.

The three A's, precisely

People blur the three A's together, but they are genuinely distinct steps with different failure consequences.

Authentication verifies identity — a username and password, or a credential tied to the access line so the customer never types anything. Authorization decides the shape of the service: the speed profile, the address pool to draw from, session timeouts, and any per-subscriber policy. Accounting is the bookkeeping that runs for the life of the session and feeds billing, audit and capacity planning. A network can authenticate flawlessly and still bill wrong if accounting is misconfigured.

The exchange between BNG and server

The conversation starts at the edge. When a session forms on your BNG (or another access concentrator), the BNG builds an Access-Request carrying the subscriber's identity and context — which port, which line, the calling station. It sends that to the RADIUS server and waits. The server looks the subscriber up in its database and replies with one of two things: an Access-Reject, and the session never comes up, or an Access-Accept stuffed with attributes that tell the BNG exactly how to provision the session.

Those returned attributes are the heart of authorization. Typical ones include the rate-limit or speed profile, the IP pool or framed address to assign, a session timeout, and a filter or policy identifier. The BNG applies them and the customer is online with precisely the service they are paying for. Then accounting begins: the BNG sends an Accounting-Start, periodic Interim-Update records while the session runs, and an Accounting-Stop when it ends, carrying input and output byte and packet counters plus session duration. Those Stop and Interim records are what your billing and usage reporting are built on.

There is also a reverse direction worth knowing about. A Change-of-Authorization (CoA) lets the server push a change into a live session — bump a speed, move a customer into a walled garden, or disconnect them — without waiting for them to reconnect. That capability is what makes real-time enforcement (suspend on non-payment, instant plan upgrade) possible.

It is worth being precise about what RADIUS does and does not protect. The shared secret between BNG and server is used to authenticate the parties to each other and to hide the password attribute — it is not full transport encryption of every field. That historical limitation is exactly why the link between BNG and RADIUS server belongs on trusted, well-segmented infrastructure rather than traversing anything you would not trust with your subscriber database. Treat the path between them as part of the secret, not just the secret itself.

Why it is the billing integration point

Trace the data flow and the reason RADIUS sits at the centre becomes obvious. A customer pays an invoice in your management system; their status flips to active. A customer upgrades; their plan record changes. In a well-built setup, none of that touches a router by hand — the management system simply updates what the RADIUS server returns, and the next authentication (or a CoA on the existing session) carries the new reality into the network. Conversely, accounting flows the other way: byte counts come back from the network into the billing system to drive usage-based plans, fair-use enforcement and reports.

This is exactly the seam an ISP management platform plugs into. ISP Digital's billing and provisioning is designed around this loop — plan and payment changes propagate to the subscriber's authorization, and accounting records flow back into invoicing — so an operator manages customers in one place and the network follows automatically. The protocol is the mechanism; the integration is what makes it a product rather than a pile of scripts.

How it fails in production

The classic catastrophe is the login storm. A power event, an upstream blip, or a BNG reboot drops thousands of sessions, and then every one of them tries to re-authenticate within a few seconds. A RADIUS deployment sized for steady-state load — the gentle trickle of normal reconnects — can be buried under that surge. Authentications queue, time out, and the BNG retries, which adds more load, and the whole thing spirals. Customers who never actually lost their physical link still cannot get online because the AAA layer is saturated.

A subtler failure is the database behind RADIUS becoming the bottleneck. RADIUS itself is light; the lookup it performs may not be. If every Access-Request triggers an expensive query against a slow or contended subscriber database, latency climbs under load even when the RADIUS daemon is idle. Accounting can fail quietly too — if Stop records are dropped and not retried, sessions appear to run forever in your records, inflating usage and corrupting bills, with no alarm because authentication still works fine.

Running it reliably

Because every login depends on it, treat RADIUS as tier-one infrastructure:

• Redundancy first. Run at least two servers on independent infrastructure, and configure your BNGs to fail over between them. One server going down — for a reboot, a patch, a disk failure — must never lock out the customer base.
• Size for the storm, not the average. Capacity-plan for the worst case: a mass reconnect after an outage, not Tuesday afternoon. Headroom here is cheap relative to a network-wide auth meltdown.
• Watch the database. The store behind RADIUS needs to be fast and resilient under concurrent load. Cache where you safely can, and keep authentication lookups cheap.
• Protect accounting integrity. Ensure Interim and Stop records are buffered and retried on failure, so byte counts and session closes survive a transient outage rather than vanishing.
• Secure the secrets and the data. The shared secret between BNG and server, and the subscriber database itself, are sensitive. Guard them, rotate secrets sanely, and keep the AAA tier off general-access networks.

Common mistakes

A handful of errors show up again and again. Running a single RADIUS server because it has been stable for a year — until the day it is not. Testing only the happy path and never simulating a login storm, so the first real one is also the first load test. Letting authentication and accounting share a fragile database with no read scaling. And building plan changes as manual router edits instead of routing them through RADIUS attributes, which throws away the entire reason the protocol exists. If you find yourself logging into a BNG to change a customer's speed, your billing-to-network integration is incomplete.

The takeaway

RADIUS is the invisible machinery that turns a paid invoice into a connected customer and a connection into a billable record. It earns no attention until it breaks, and then everything breaks with it — so build it redundant, size it for the worst minute rather than the average hour, protect the accounting stream as carefully as the authentication path, and wire it tightly into billing so the network follows your business automatically. Done well, nobody ever thinks about it, which is exactly the point.