What Is the User Datagram Protocol (UDP)?

UDP is one of the two foundational transport protocols in the TCP/IP stack. The protocol is simple, fast and stateless — and those same properties make it the right choice for some workloads and the wrong choice for others. RADIUS, the protocol that authenticates users and devices on enterprise Wi-Fi, VPN and wired networks, has run over UDP since its earliest implementations.

This article explains what UDP is, how it works, and why the networking community chose it for RADIUS. It also covers the security gaps that choice creates and why it’s time to consider a migration to RadSec, the IETF-recommended replacement that encrypts RADIUS traffic in transit.

What Is UDP?

User Datagram Protocol (UDP) is a connectionless transport layer protocol defined in RFC 768 (1980). It sends discrete packets (datagrams) from a source to a destination without first establishing a session. There is no handshake, no acknowledgment of receipt and no guarantee that packets arrive at all or in the order they were sent.

The UDP header is just eight bytes: source port (2 bytes), destination port (2 bytes), length (2 bytes) and checksum (2 bytes). The checksum validates that the data was not corrupted in transit but provides no authentication or encryption.

UDP sits at Layer 4, the transport layer, of the OSI model. Applications that use UDP are responsible for handling retransmission, ordering and error recovery — or accepting that some packets will be lost.

How UDP Works

The UDP send process is direct:

1. An application passes data to UDP: The sending application calls the UDP socket with a payload and a destination address (IP + port).
2. UDP adds an 8-byte header: This includes source port, destination port, total length and checksum. No connection state is tracked.
3. IP encapsulates the datagram: The IP layer adds source and destination IP addresses and routes the packet toward the destination.
4. Packet is transmitted immediately: Unlike in Transmission Control Protocol (TCP) there is no SYN/SYN-ACK/ACK handshake. The packet leaves as soon as the application calls send.
5. Receiver processes the packet: The receiving UDP layer strips the header and passes the payload to the listening application on the specified port.
6. No acknowledgment is sent: The sender has no way to know whether the packet arrived. There is no TCP ACK equivalent.
7. Lost packets are gone: If the packet is dropped in transit, the application must detect the loss through its own timeout or sequence-number logic — or simply accept the loss.

UDP’s speed comes directly from what it omits: the session management, ordering and retransmission logic that TCP handles at the transport layer.

UDP vs. TCP: The Core Tradeoffs

Both UDP and TCP sit at Layer 4 and use the same IP addressing infrastructure. The difference is what each protocol does after handing off to IP. The reliability guarantees TCP offers make it the protocol of choice for modern RADIUS deployments.

Common UDP Ports and Their Security Relevance

UDP is used by a wide range of protocols. Several are directly relevant to network security and infrastructure operations.

RADIUS ports 1812 and 1813 were formally assigned to UDP by IANA in RFC 2865 and RFC 2866, replacing the legacy assignments of 1645 and 1646 that some deployments used before standardization. Both the old and new port assignments carry the same security characteristics because the underlying protocol has not changed.

Why RADIUS Uses UDP

RADIUS was developed by Livingston Enterprises in the early 1990s and standardized in RFC 2058 (1997), with the current version in RFC 2865 (2000). The choice to use UDP was deliberate, and it made sense given the constraints of that era.

In 1991, Network Access Servers (NAS devices — dial-up terminal servers and early network access points) had limited processing capacity. TCP’s three-way handshake and session state management added enough overhead to strain the hardware of that era. UDP offered a simpler request/response model: the NAS sends an Access-Request packet, the RADIUS server responds with an Access-Accept or Access-Reject. It limited interactions to a single round trip with no persistent session.

RADIUS also handles its own application-layer retransmission. When a NAS sends an Access-Request, it starts a timer. If no response arrives within the timeout window, it retries — either to the same RADIUS server or to a failover server. This application-layer retry logic reduces the dependency on transport-layer guarantees.

The design assumption behind this approach was that RADIUS traffic would travel over trusted internal network segments — between the NAS in the wiring closet and the RADIUS server in the data center. On a physically secured LAN, transport-layer encryption was not considered necessary. That assumption has not aged well.

For a broader overview of how RADIUS authentication fits into enterprise network design, see our guide to enterprise RADIUS fundamentals.

RADIUS/UDP Security Limitations

RADIUS was designed for a different threat model. Running it over UDP on modern enterprise networks — with traffic crossing WAN links, cloud interconnects and shared segments — leaves organizations exposed to several concrete problems.

MD5-Based Shared Secrets

RADIUS/UDP uses MD5 to obfuscate the shared secret between the NAS and the RADIUS server. The User-Password attribute is XOR’d with an MD5 hash derived from the shared secret and a random Authenticator value. MD5 is cryptographically broken. Collision attacks date to 2004, and MD5’s preimage resistance doesn’t stand up to modern hardware. An attacker with a modest GPU cluster who captures RADIUS/UDP traffic can crack an MD5 shared secret with offline dictionary attacks relatively easily.

Plaintext Attributes

Only the User-Password attribute is obfuscated in RADIUS/UDP, while the rest of the packet is unencrypted. Attributes transmitted in cleartext include:

• Calling-Station-Id (the MAC address of the connecting device)
• Called-Station-Id (the identifier of the access point or NAS)
• NAS-IP-Address (infrastructure topology)
• VLAN assignment policies
• User-Name (in some configurations)

Anyone with packet-capture access on any network segment the RADIUS traffic crosses can read this data.

No Transport Encryption

RADIUS/UDP provides no TLS or transport-layer encryption by default. Adding IPsec between the NAS and RADIUS server is possible, but it increases operational complexity and is not universally supported across NAS vendors. The common deployment pattern is simply unencrypted UDP.

Replay Attacks

The RADIUS Authenticator field provides limited protection against replay attacks, but it is not replay-proof under all configurations. A captured Access-Request or Access-Accept packet from a UDP stream can, under certain conditions, be replayed against servers that do not implement strict duplicate detection.

UDP Packet Loss Causes Authentication Failures

On WAN links, satellite connections, or congested network segments, UDP packet loss directly causes authentication timeouts. This happens when a user’s device sends an 802.1X authentication request, the NAS forwards it via RADIUS/UDP, but the packet is dropped in transit. The NAS retries, but if the configured retry count is exceeded and the authentication fails. Ultimately, the user sees a login error that is actually a transport failure. This is a documented operational problem in geographically distributed deployments.

The IETF has formally recognized these problems, and recommends deprecating RADIUS/UDP and RADIUS/TCP for any use case where traffic crosses untrusted network segments.

How to Update From RADIUS/UDP to RadSec

RadSec is RADIUS over Transport Layer Security (TLS) and is defined in RFC 6614. It replaces UDP with TCP and wraps the entire RADIUS stream in TLS, running on port 2083. Every attribute — including all the plaintext fields described above — is encrypted in transit. The shared-secret MD5 authentication model is replaced by TLS mutual certificate authentication between the NAS and the RADIUS server.

RadSec solves the full set of RADIUS/UDP security limitations:

• Encryption: TLS protects all RADIUS attributes. No plaintext is shared.
• Authentication: Mutual TLS verifies both endpoints with certificates, so there are no shared secrets.
• Integrity: The TLS record layer detects tampering. No reliance on MD5.
• Reliability: TCP provides guaranteed ordered delivery. No authentication failures from UDP packet loss.
• Replay protection: TLS session mechanics prevent replay of captured records.

The migration path depends on your NAS and RADIUS server. Most modern wireless controllers, VPN concentrators, and access points support RadSec. The RADIUS server must be configured to accept TLS connections and present a valid certificate. For organizations using eduroam, RadSec is required for inter-institutional roaming traffic. The eduroam federation infrastructure runs RadSec between member institutions.

For a deeper look at when RadSec is necessary versus optional, see Is RadSec Necessary if I Already Use EAP-TLS? and our dedicated guide What Is RadSec?

Migrate RADIUS Authentication to a Modern Standard

Organizations still running RADIUS/UDP over untrusted segments are accepting MD5-based shared secrets and cleartext attribute exposure as a standing condition.

That was a reasonable architectural tradeoff in 1991, when RADIUS traffic traveled over physically controlled serial links. It is not a reasonable tradeoff when that traffic crosses cloud interconnects, SD-WAN overlays, or co-located data center segments in 2026.

The path forward is not complex, as RadSec is a mature standard with many associated hardware options. The challenge is finding a RADIUS server that supports RadSec natively alongside the identity integrations — Entra ID, Okta, Google Workspace — that modern IT environments depend on.

JoinNow Cloud RADIUS from SecureW2 supports RadSec natively, eliminating the need to manage shared secrets or run unencrypted RADIUS over untrusted links. Cloud RADIUS integrates directly with your existing identity provider for real-time user and device validation, and pairs with SecureW2 managed PKI to replace password-based authentication with certificate-based authentication entirely. There is no on-premises hardware to maintain and no complex RadSec proxy configuration.

If you’re still operating on-prem RADIUS with NPS or another server, check out RADIUS server authentication explained to see what the migration involves.

If you’re ready to migrate, schedule a demo to see how JoinNow Cloud RADIUS handles RadSec deployment alongside certificate-based authentication, or contact SecureW2 to discuss your specific network architecture.