Diameter Details

Diameter is an enhanced version of RADIUS that provides several enhancements while still being backward-compatible. Diameter bridges the gap between the old world and the new world by being designed as a peer-to-peer architecture while at the same time keeping the client/server concept in place. This is achieved by referring to AAA elements as Diameter nodes, where a node can act as a client, server, or agent. The client node is usually the NAS where a user authenticates by providing credentials, such as username and password. The client forwards the access request to a Diameter server node, where authentication takes place. Depending on the success, a "succeed" or "reject" response message is sent back to the client. Note that the roles can change; in some cases a Diameter server can also act as a client. RADIUS deployments using proxy servers for aggregation and roaming support have been popular in the Service Provider space. Diameter has added enhanced support for such deployments by explicitly defining four types of intermediary agents:

Relay agents, which aggregate requests from different realms (Administrative domain piggybacked on the DNS domain) toward a central server.
Proxy agents, which can perform the relay agent role and modify the message content—for example, to apply policies.
Redirect agents, which act as a centralized repository. This simplifies the client configuration, because a client needs to know only the redirect agent (and potentially backup) instead of all servers in the network.
Translation agent, which can translate between Diameter and RADIUS or TACACS+.

Diameter is structured as a base protocol (RFC 3588, Diameter Base Protocol) upon which applications are layered. The base protocol provides AVP delivery, capabilities negotiation, error handling, basic services including accounting, and an extensibility framework for specific application support. Each application is assigned a unique identifier by the Internet Assigned Numbers Authority (IANA). These are used during capabilities negotiation:

NASREQ (Network Access Server Requirements) provides RADIUS-like functionality between a NAS and the AAA infrastructure.
Mobile IPv4 describes AAA services for mobile nodes.
Credit control provides a superset of basic prepaid functionality, including time and volume quota management (RFC 4006).
EAP adds support for Extensible Authentication Protocol to Diameter (RFC 4072).
SIP allows Session Initiation Protocol servers to act as Diameter clients to provide AAA services for SIP users (RFC 4740).

You can find the complete, maintained list of Diameter-based applications at http://www.iana.org/assignments/aaa-parameters under "Application IDs."

Diameter runs only over TCP or SCTP for increased reliability and congestion awareness. Diameter accounting records are provided either as a one-time request (EVENT_RECORD) or as continuous records (START_RECORD, INTERIM_RECORD, STOP_RECORD). Each record contains a Session-ID AVP and an Accounting-Record-Number AVP. The combination of these two fields makes records unique and enables a Diameter agent to de-duplicate records, which means eliminating records that have been collected twice.

Table 9-6 lists relevant AAA protocol characteristics and compares RADIUS and Diameter.

Table 9-6. Comparing RADIUS and Diameter Characteristics
Characteristic	RADIUS	Diameter
Transport protocol	Connectionless (UDP).	Connection-oriented (TCP, SCTP).
Transport security	Optional IPsec.	IPsec or Transport Layer Security (TLS) is required.
Client configuration	Static configuration.	Static configuration and peer discovery.
Server status (failover)	The server cannot indicate its status (running, going down).	Supports server status messages (keepalive, running, going down).
Server message acknowledgment	The client does not know whether the server received the request or if the message was silently discarded (because of errors or wrong message details).	The server can send error messages, authentication, and session termination messages.
Security model	Supports only hop-by-hop security. Every hop can modify information that cannot be traced to its origin.	Supports end-to-end and hop-to-hop security. End-to-end guarantees that information cannot be modified without notice.
Attribute data size	1 byte is reserved for the length of a data field (maximum 255) in its attribute header.	2 bytes are reserved for the length of a data field (maximum 16,535).
Vendor-specific support	Supports VSAs only.	Supports both vendor-specific messages and attributes (commands).