Introduction to the Diameter Protocol

A number of working groups have specified their requirements for AAA protocols, and these requirements drove the design of the Diameter protocol.

• The Roaming Operations (ROAMOPS) Working Group of the IETF published a set of requirements for roaming networks.

• The NAS Requirements (NASREQ) Working Group of the IETF documented the next generation NAS AAA requirements.

• The Mobile IP Working Group of the IETF documented AAA requirements that would help Mobile IP scale for Inter-Domain mobility.

• The Telecommunication Industry Association (TIA) TR-45.6 Adjunct Wireless Packet Data Technology working group documented the CDMA2000 Wireless Data Requirements for AAA. Based on the work of TR-45.6, 3GPP2 has specified a two phased architecture for supporting Wireless IP networking based on IETF protocols; the second phase requiring AAA functionality not supportable in RADIUS.

The Diameter protocol was specifically designed to meet the requirements indicated by these various groups.

Diameter is focused on, and limited to, supporting access to IP networks. The Diameter protocol was designed as an improved version of the RADIUS protocol. A goal was to maximize compatibility and ease migration from the RADIUS Server to the Diameter Server. For example, a Diameter message, like a RADIUS message, conveys a collection of attribute value pairs.

Diameter is defined in terms of a base protocol and a set of applications. This design allows the protocol to be extended to new access technologies. The base protocol provides basic mechanisms for reliable transport, message delivery, and error handling.

The base protocol must be used in conjunction with a Diameter application. Each application relies on the services of the base protocol to support a specific type of network access. The two early applications were Mobile IPv4 and NASREQ (Network Access Server REQuirements). The NASREQ application supports dial-in PPP/IP and is the intended replacement for RADIUS.

The Case for Diameter

There are several general shortcomings of the RADIUS protocol that were addressed in the design of the Diameter base protocol. These are described in this section. In addition to the protocol shortcomings, there are further application-specific RADIUS protocol deficiencies that limit its capability to support AAA services in specific areas (e.g. Mobile IP).

Limited size of attribute data
A RADIUS attribute is carried in a RADIUS message as a variable-length {Attribute Type, Attribute Length, Attribute Value} 3-tuple. The Attribute Length field is one octet, hence its maximum value of 255 puts a ceiling on the number of octets of a given attribute's data.

A Diameter attribute is carried in a Diameter message as a variable-length {Attribute Type, Flags, Attribute Length, Vendor-ID, Attribute Value} 5-tuple. The Attribute Length field is three octets, hence its maximum value allows for over 16,000,000 octets of data for a given attribute.

Limited number of concurrent pending messages
An Identifier field in the header of the RADIUS packet is used to recognize retransmissions. The identifier field is one octet, imposing a maximum of 255 outstanding messages between a RADIUS client and a RADIUS server.

An End-to-End Identifier field in the header of a Diameter message is used to recognize retransmissions. This field is four octets, allowing over 4 billion outstanding messages from a Diameter client.

Inability to control flow to servers
RADIUS operates over UDP (User Datagram Protocol), a simple connectionless datagram delivery transport protocol that lacks any mechanism for the receiving node to regulate the data flow from the sending node.

Diameter operates over TCP (Transmission Control Protocol) or SCTP (Stream Control Transmission Protocol). TCP and SCTP are connection-oriented transport protocols with flow control and congestion avoidance mechanisms.

Limited server failure detection
There are many reasons why a NAS fails to receive a timely response to a given RADIUS request. These include network congestion, a temporary network failure in the path from the NAS to the home server, failure of the next-hop proxy server, failure of the home server, etc. With RADIUS/UDP, the NAS cannot distinguish the cause of the failure, assumes failure of the next-hop server and retransmits to an alternate nexthop server. This may be an inappropriate failover.

With a connection-oriented transport layer and Diameter keepalive messages, a Diameter node can detect the local failure of a peer.

Silent discarding of packets
The RADIUS protocol specifies that messages are silently discarded for a variety of error conditions. In such cases, the NAS will assume the home server did not receive the message, and will engage in futile retransmissions before finally abandoning the request.

The Diameter protocol returns a response for all but a few error conditions.

Inefficient Server Fail-Over
Most NAS implementations configure multiple RADIUS servers, a primary server and a set of alternate servers. When failing over to an alternate, the NAS doesn't know if the alternate server is even reachable. This can result in a lengthy delay of service to users until a suitable alternate is found.

With a connection-oriented transport layer and Diameter keepalive messages, a Diameter node can effectively failover. It can also fail back to the primary server when it becomes available without having to time out real requests.

Inefficient use of RADIUS server in proxy environments
Under RADIUS, all retransmissions are done by the NAS. Proxy servers do not retransmit RADIUS requests. The NAS, not knowing whether the failure is local or remote, may inappropriately retransmit to an alternate next-hop peer.

Under the Diameter protocol, each Diameter node that a message traverses on the path from the origin node to the home server will detect a failure of his next-hop peer and do failover and retransmission. Thus, failovers are locally performed at the place where the failures occur.

No unsolicited server messages
The RADIUS protocol does not allow a server to send unsolicited messages to the NAS. Where RADIUS server initiated actions are needed, vendors are forced into solutions outside of the RADIUS protocol (e.g. SNMP) or solutions involving proprietary extensions to the RADIUS protocol in ways that often compromise interoperability.

Diameter, a peer-to-peer rather than a client/server protocol, allows server-initiated messages. The base Diameter protocol defines two server-initiated messages, one requesting that the Diameter client terminate a specific user session, another requesting that the Diameter client re-authenticate and/or reauthorize a specific user.

Replay Attacks
The RADIUS protocol does not offer replay attack prevention. An old packet can be replayed without detection by a malicious NAS impersonator. This can result in denial of service if the server limits concurrent sessions for a user. Duplicate accounting messages can also create havoc.

Only Hop-by-Hop security; no End-to-End security
The RADIUS protocol offers only hop-by-hop security and has no facility for securing AVPs between the NAS and the home server. This offers proxy servers the opportunity to collect confidential information or modify messages (e.g. accounting information) without detection by the endpoints.

The Diameter protocol offers end-to-end security in addition to hop-by-hop security. Digital signatures can ensure the integrity of selected AVPs, and the confidentiality of selected AVPs can be ensured by encryption.

No support for vendor-specific commands
The RADIUS protocol supports vendor-specific attributes but not vendor-specific commands. This has enticed vendors to create private command codes with resulting interoperability problems.

The Diameter protocol supports both vendor-specific attributes and vendor-specific commands.

No alignment requirements

The RADIUS protocol imposes no alignment requirements, which can add an unnecessary burden on many processors. All fields within the header and attributes must be treated as byte aligned characters.

The Diameter protocol requires all attributes to align on 32-bit boundaries. Individual 32-bit fields in the Diameter message header and AVP header also align on 32-bit boundaries.

Mandatory Shared Secret
The RADIUS protocol requires that a shared secret exist between two peers, even if IP Security is employed over a local communication. The Diameter protocol can secure communications between peers with either IP Security or Transport Layer Security (TLS).

Summary of Diameter Advantages over RADIUS

Better Transport

• Diameter runs over a reliable transport, TCP or SCTP.
• Lost packets are retransmitted at each hop.
• A persistent connection with an application-level heartbeat message (called a Watchdog message) supports timely failover.
• TCP and SCTP adapt to network congestion.

Better Proxying

• Hop-by-hop transport failure detection allows failover to occur at the appropriate place — proxies can locally failover to an alternate next-hop peer.
• The proxy automatically does retransmission of pending request messages following a failover.
• An AVP that identifies the ultimate destination allows multiple transactions for a given session to be routed to the same home server.

Better Session Control

• Session management is independent of accounting. Accounting information can be routed to a different server than authentication/authorization messages. Session termination is conveyed by a specific Session-Termination message rather than an Accounting Stop message.
• The server may initiate a message to request session termination.
• The server may initiate a message to request re-authentication and/or reauthorization of a user.

Better Security

• Hop-by-hop security is provided using IPsec or TLS.
• End-to-end security protects the integrity and/or confidentiality of sensitive AVPs through intermediate proxies.

Overview of the Diameter Protocol

The Diameter model is a base protocol and a set of applications. The base protocol provides common functionality to the supported applications. The following figure depicts the Diameter server architecture.

The base protocol defines the basic Diameter message format. Data is carried within a Diameter message as a collection of Attribute Value Pairs (AVPs). An AVP is like a RADIUS attribute. An AVP consists of multiple fields: an AVP Code, a Length, some Flags, and Data. Some AVPs are used by the Diameter base protocol; other AVPs are intended for the Diameter application (e.g. NASREQ); while yet others may be used by the higher-level end-system application that employs Diameter.

Read the rest of the Introduction to the Diameter Protocol white paper.