RADIUS: The Packet Protocol Behind Centralized Network Access

RADIUS helped network operators centralize a job that was otherwise repeated on every modem bank, access concentrator, or network device: deciding who could connect and what that connection was allowed to do. The Remote Authentication Dial-In User Service protocol lets a Network Access Server (NAS) ask a shared authentication server to evaluate a user or device. The NAS enforces the decision; RADIUS carries the request, result, and policy attributes between the two.

RFC 2058 documented RADIUS in January 1997 as an informational protocol associated with Livingston Enterprises. RFC 2865 replaced it in June 2000 as a standards-track specification. The early RFC describes Access-Request, Access-Accept, Access-Reject, and Access-Challenge packet types, and explains the packet identifier, length, authenticator, and attribute fields. The protocol’s earliest operational niche was dial-up and PPP access, but the same split between a network enforcement point and a shared decision service became useful for other access technologies.

The NAS enforces; the RADIUS server decides

A RADIUS client is commonly the network device that receives a connection: a dial-up access server, VPN concentrator, wireless controller, switch, or another NAS. It collects information about the connection and sends an Access-Request to the RADIUS server. The request can include a username, a password or challenge response, the NAS identity, the port, and other attributes.

The server evaluates credentials and policy, then returns an Access-Accept, Access-Reject, or Access-Challenge. An accept can include attributes that shape the session, such as a VLAN, address, session limit, or filter. The NAS remains responsible for enforcing that result. A server response cannot make a device secure if the NAS ignores the attributes, maps them incorrectly, or applies a weaker local policy.

The protocol’s packet format is compact. A packet includes a one-octet code, an identifier used to match a response to a request, a packet length, a 16-octet authenticator, and a series of typed attributes. The format let one shared service support many kinds of network access without a separate authentication database embedded in every device. The attributes also made the protocol extensible, although vendor-specific attributes mean that interoperability depends on both ends understanding the same semantics.

Centralized decisions simplify administration

Before a shared authentication service, operators had to manage user accounts or authorization rules independently on many network devices. A user who changed teams or left an organization could remain enabled on a forgotten access server. Centralized policy lets an organization place credentials and access rules in a shared service and apply them at multiple network edges.

RADIUS also separates authentication from authorization and accounting, often called AAA. Authentication checks evidence of identity. Authorization determines what the connection may do. Accounting records events such as session start, interim updates, and session stop. RFC 2866 specifies RADIUS Accounting separately. Centralized logs can help operators reconcile session durations, investigate access, and bill or report usage, but the accounting data is only as complete as the NAS configuration and network path.

An Access-Challenge supports multi-step methods. The server can request another response, such as a one-time code or a challenge response, rather than accepting or rejecting after one packet. The NAS presents the challenge to the user and sends the response back to the server. This made RADIUS adaptable to authentication systems whose interaction did not fit a single password check.

UDP and shared secrets were pragmatic, not modern transport security

Classic RADIUS uses UDP. Its design includes identifiers and authenticators to associate responses with requests and detect some forms of tampering, while retransmissions and timeouts are handled by clients and servers. UDP made the protocol relatively simple to deploy on network devices, but it leaves operators to manage loss, duplicate messages, failover, and server selection. A timeout does not tell the NAS whether a request was lost, delayed, or processed while the reply disappeared.

The original protocol assumes a shared secret between the NAS and server. The password-hiding algorithm in early RADIUS uses the shared secret and request authenticator with MD5-derived processing; this is not equivalent to encrypting the entire packet. Many attributes and metadata were not confidential. RFC 2865 itself notes that early deployment used UDP port 1645, which conflicted with an existing service, and assigns RADIUS port 1812 as the official port.

This historical design must not be mistaken for a current secure deployment recommendation. Operators should isolate RADIUS traffic, use strong random shared secrets, restrict which NAS devices can query the service, monitor for spoofing, and choose a protected transport supported by both ends. Later specifications define RADIUS over TLS and DTLS. RFC 9765, published in 2025, defines RADIUS/1.1 using ALPN to remove the legacy MD5-based packet behavior when run with modern secure transports. These are distinct protocol developments; an organization cannot simply set port 1812 and assume that its older equipment is now encrypted.

From modem pools to enterprise identity

The dial-up era made centralized access policy an immediate operational need. An Internet service provider could operate a large collection of modems and access servers while using one backend to verify accounts and apply connection policy. As access moved to DSL, campus wireless, VPNs, and enterprise Ethernet, the enforcement device changed but the AAA pattern remained useful.

RADIUS became part of 802.1X network access control deployments, where a switch or wireless access point serves as the authenticator and forwards EAP messages toward an authentication server. The EAP exchange is not simply a password attribute; RADIUS carries information among the network access device and server while the EAP method performs its own authentication steps. Misunderstanding those roles can lead to a network that appears to use a strong authentication method while still trusting an unauthenticated or misconfigured edge device.

The protocol also illustrates the difference between an identity store and a policy transport. RADIUS can consult a directory, token system, or local database, but it does not prescribe one universal backend. It carries requests and decisions. A central policy server may return group-based attributes, but each NAS needs a consistent mapping from those attributes to local enforcement. A VLAN assignment, for example, is not meaningful if two switches interpret it differently.

Reliability and failure policy are architectural choices

Because the NAS sits on the edge of a network, it must decide what to do when the RADIUS server is unavailable. A fail-closed policy can deny new access but may block legitimate users during an outage. A fail-open or cached authorization policy improves continuity but may grant access after a user’s credentials or account have been disabled. Different network classes may justify different policies; the choice should be explicit and tested.

Multiple RADIUS servers can provide redundancy, but shared state, failover order, and timeout settings matter. If a NAS waits too long for one server before trying another, users experience slow logins. If it retries aggressively, an outage can amplify traffic. If both servers use inconsistent secrets or policy, failover can silently change authorization. Operators should test both authentication and accounting paths during failover exercises.

Packet-level diagnosis follows the transaction. Confirm the NAS can reach the configured server and source address, validate the shared secret at both ends, check the request’s identifier and authenticator, inspect the server’s policy result, and ensure the NAS applies returned attributes. A local Access-Accept in a log does not prove that the user entered the network or received the intended access level. Correlate the RADIUS response with the NAS session and accounting record.

RADIUS’s historical contribution is architectural as much as protocol-level. It provided a common packet exchange through which many network devices could consult a shared policy service and produce centralized accounting. The design reflects its time: UDP, a compact attribute protocol, shared secrets, and early packet protection rather than modern encrypted transports. Later extensions address new requirements, but those do not erase the limits of older deployments. Understanding both the original contract and its security evolution is essential when maintaining the infrastructure that decides who may connect.

Related:

Sources: