Diameter (protocol)

For the geometric term, see Diameter.

Diameter is a computer networking protocol for AAA (Authentication, Authorization and Accounting). It is a successor to RADIUS.

Upgrade from RADIUS

The name is a pun on the RADIUS protocol, which is the predecessor (a diameter is twice the radius). Diameter is not directly backwards compatible, but provides an upgrade path for RADIUS. The main differences are as follows:

• Reliable transport protocols (TCP or SCTP, not UDP)
• Network or transport level security (IPsec or TLS)
• Transition support for RADIUS, although Diameter is not fully compatible with RADIUS
• Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8 bits)
• Client-server protocol, with exception of supporting some server-initiated messages as well
• Both stateful and stateless models can be used
• Dynamic discovery of peers (using DNS SRV and NAPTR)
• Capability negotiation
• Supports application layer acknowledgements, defines failover methods and state machines (RFC 3539)
• Error notification
• Better roaming support
• More easily extended; new commands and attributes can be defined
• Aligned on 32-bit boundaries
• Basic support for user-sessions and accounting

Protocol description

The Diameter base protocol is defined by RFC 3588, and defines the minimum requirements for an AAA protocol. Diameter Applications can extend the base protocol, by adding new commands and/or attributes. An application is not a program, but a protocol based on Diameter. Diameter security is provided by IPSEC or TLS, both well-regarded protocols. The IANA has assigned TCP and SCTP port number 3868 to Diameter.

Packet format

File:DIAMETER packet format.png

Commands

Each command is assigned a command code, which is used for both requests and answers.

Command-Name	Abbr.	Code
AA-Request	AAR	265
AA-Answer	AAA	265
Diameter-EAP-Request	DER	268
Diameter-EAP-Answer	DEA	268
Abort-Session-Request	ASR	274
Abort-Session-Answer	ASA	274
Accounting-Request	ACR	271
Accounting-Answer	ACA	271
Credit-Control-Request	CCR	272
Credit-Control-Answer	CCA	272
Capabilities-Exchange-Request	CER	257
Capabilities-Exchange-Answer	CEA	257
Device-Watchdog-Request	DWR	280
Device-Watchdog-Answer	DWA	280
Disconnect-Peer-Request	DPR	282
Disconnect-Peer-Answer	DPA	282
Re-Auth-Request	RAR	258
Re-Auth-Answer	RAA	258
Session-Termination-Request	STR	275
Session-Termination-Answer	STA	275
User-Authorization-Request	UAR	300
User-Authorization-Answer	UAA	300
Server-Assignment-Request	SAR	301
Server-Assignment-Answer	SAA	301
Location-Info-Request	LIR	302
Location-Info-Answer	LIA	302
Multimedia-Auth-Request	MAR	303
Multimedia-Auth-Answer	MAA	303
Registration-Termination-Request	RTR	304
Registration-Termination-Answer	RTA	304
Push-Profile-Request	PPR	305
Push-Profile-Answer	PPA	305
User-Data-Request	UDR	306
User-Data-Answer	UDA	306
Profile-Update-Request	PUR	307
Profile-Update-Answer	PUA	307
Subscribe-Notifications-Request	SNR	308
Subscribe-Notifications-Answer	SNA	308
Push-Notification-Request	PNR	309
Push-Notification-Answer	PNA	309
Bootstrapping-Info-Request	BIR	310
Bootstrapping-Info-Answer	BIA	310
Message-Process-Request	MPR	311
Message-Process-Answer	MPA	311

Attribute-Value Pairs (AVP)

File:DIAMETER AVP Layout.png

For simplicity, 'V' Bit Means Vendor Specific; 'M' Bit means Mandatory; 'P' Bit means Protected.

The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.

The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.

The 'P' bit indicates the need for encryption for end-to-end security.

Attribute-Name	Code	Data Type
Acct-Interim-Interval	85	Unsigned32
Accounting-Realtime-Required	483	Enumerated
Acct-Multi-Session-Id	50	UTF8String
Accounting-Record-Number	485	Unsigned32
Accounting-Record-Type	480	Enumerated
Accounting-Session-Id	44	OctetString
Accounting-Sub-Session-Id	287	Unsigned64
Acct-Application-Id	259	Unsigned32
Auth-Application-Id	258	Unsigned32
Auth-Request-Type	274	Enumerated
Authorization-Lifetime	291	Unsigned32
Auth-Grace-Period	276	Unsigned32
Auth-Session-State	277	Enumerated
Re-Auth-Request-Type	285	Enumerated
Class	25	OctetString
Destination-Host	293	DiamIdent
Destination-Realm	283	DiamIdent
Disconnect-Cause	273	Enumerated
E2E-Sequence	300	Grouped
Error-Message	281	UTF8String
Error-Reporting-Host	294	DiamIdent
Event-Timestamp	55	Time
Experimental-Result	297	Grouped
Experimental-Result-Code	298	Unsigned32
Failed-AVP	279	Grouped
Firmware-Revision	267	Unsigned32
Host-IP-Address	257	Address
Inband-Security-Id	299	Unsigned32
Multi-Round-Time-Out	272	Unsigned32
Origin-Host	264	DiamIdent
Origin-Realm	296	DiamIdent
Origin-State-Id	278	Unsigned32
Product-Name	269	UTF8String
Proxy-Host	280	DiamIdent
Proxy-Info	284	Grouped
Proxy-State	33	OctetString
Redirect-Host	292	DiamURI
Redirect-Host-Usage	261	Enumerated
Redirect-Max-Cache-Time	262	Unsigned32
Result-Code	268	Unsigned32
Route-Record	282	DiamIdent
Session-Id	263	UTF8String
Session-Timeout	27	Unsigned32
Session-Binding	270	Unsigned32
Session-Server-Failover	271	Enumerated
Supported-Vendor-Id	265	Unsigned32
Termination-Cause	295	Enumerated
User-Name	1	UTF8String
Vendor-Id	266	Unsigned32
Vendor-Specific-Application-Id	260	Grouped

Message flows

The communication between two diameter peers starts the establishment of a transport connection (TCP or SCTP). The initiator then sends a capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). After that, TLS may be negotiated. (not shown in diagram)

The connection is then ready for exchanging application messages.

If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.

Applications

A Diameter Application is not a software application, but a protocol based on the Diameter base protocol (defined in RFC 3588). Each application is defined by an application identifier and can add new command codes and/or new mandatory AVPs. Adding a new optional AVP does not require a new application.

Examples of Diameter applications :

• Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
• Diameter Network Access Server Application (NASREQ, RFC 4005)
• Diameter Extensible Authentication Protocol Application (RFC 4072)
• Diameter Credit-Control Application (DCCA, RFC 4006)
• Diameter Session Initiation Protocol Application (RFC 4740)
• Various applications in the 3GPP IP Multimedia Subsystem

Both the HSS and the SLF communicate using the Diameter protocol.

(Generic Bootstrapping Architecture): Bootstrapping Server Function

History

The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn and Ping Pan in 1998 to provide a Authentication, Authorization, and Accounting (AAA) framework that could overcome the limitations of RADIUS. RADIUS had issues with reliability, scalability, security and flexibility. RADIUS cannot effectively deal well with remote access, IP mobility and policy control. The Diameter protocol defines a policy protocol used by clients to perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services.

Like RADIUS, Diameter provides AAA functionality, but in addition it is made more reliable by using TCP and SCTP instead of UDP. The Diameter protocol further enhanced by the development of the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). The Cx, Dh, Dx, Rf, Ro, and Sh interfaces are supported by Diameter applications. Through the use of extensions, the protocol was designed to be extensible to support Proxies, Brokers, Strong Security, Mobile-IP, Network Access Servers (NASREQ), Accounting and Resource Management.

RFCs

The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.

#	Title	Date published	Related article	Obsoleted by	Notes
RFC 3588	Diameter Base Protocol.	September 2003.	Diameter
RFC 3589	Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5.	September 2003.
RFC 4004	Diameter Mobile IPv4 Application.	August 2005.
RFC 4005	Diameter Network Access Server Application	August 2005.
RFC 4006	Diameter Credit-Control Application.	August 2005.
RFC 4072	Diameter Extensible Authentication Protocol (EAP) Application.	August 2005.
RFC 4740	Diameter Session Initiation Protocol (SIP) Application. M.	November 2006.
RFC 5224	Diameter Policy Processing Application.	March 2008.
RFC 5431	Diameter ITU-T Rw Policy Enforcement Interface Application.	March 2009.
RFC 5447	Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction.	February 2009.
RFC 5516	Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS).	April 2009.

See Also

• List of authentication protocols
• Host Identity Protocol (HIP)

External links

• Introduction to Diameter - Get the next generation AAA protocol
• Diameter Reference Guide
• List of all Diameter interfaces defined in IETF,3GPP,3GPP2, ETSI,PacketCable,MSF,ITU
• Cisco page outlining differences between RADIUS and DIAMETER
• Java IMS optimized Diameter Library
• Diameter: next generation’s AAA protocol Paper about Diameter by Håkan Ventura
• OpenDiameter Project
• Hewlett-Packard HSS