Diameter is an authentication, authorization, and accounting protocol for computer networks.
It evolved from and replaces the much less capable RADIUS protocol that preceded it.
Diameter Applications extend the base protocol by adding new commands and/or attributes,
such as those for use of the Extensible Authentication Protocol.
Comparison with RADIUS The name is a play on words, derived from
the RADIUS protocol, which is the predecessor.
Diameter is not directly backwards compatible but provides an upgrade path for RADIUS.
The main features provided by Diameter but lacking in RADIUS are:
Reliable transport protocols The IETF is in the process of standardizing
TCP Transport for RADIUS
Network or transport layer security The IETF is in the process of standardizing
Transport Layer Security for RADIUS
Transition support for RADIUS, although Diameter is not fully compatible with RADIUS
Larger address space for attribute-value pairs and identifiers
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
Capability negotiation Supports application layer acknowledgements,
defines failover methods and state machines 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 Applications
A Diameter Application is not a software application but is a protocol based on the Diameter base
protocol defined in RFC 6733.
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
Diameter Network Access Server Application Diameter Extensible Authentication Protocol
Application Diameter Credit-Control Application
Diameter Session Initiation Protocol Application 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 framework for authentication,
authorization and accounting that could overcome the limitations of RADIUS.
RADIUS had issues with reliability, scalability, security and flexibility.
RADIUS cannot deal effectively 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 it is using TCP and SCTP instead of UDP,
therefore logic for detection of communication problems is not included in the Diameter protocol
itself.
The Diameter protocol is enhanced further by the development of the 3rd Generation Partnership
Project IP Multimedia Subsystem.
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, accounting and resource management.
Protocol description The Diameter base protocol is defined by RFC
6733 and defines the minimum requirements for an AAA protocol.
Diameter Applications can extend the base protocol by adding new commands, attributes,
or both.
Diameter security is provided by IPsec or TLS.
The IANA has assigned TCP and SCTP port number 3868 to Diameter.
Packet format The packet consists of a Diameter header and
a variable number of Attribute-Value Pairs, or AVPs, for encapsulating information relevant
to the Diameter message.
The "R" bit – If set, the message is a request.
If cleared, the message is an answer.
The "P" bit – If set, the message MAY be proxied, relayed or redirected.
If cleared, the message MUST be locally processed.
The "E" bit – If set, the message contains a protocol error, and the message will not
conform to the ABNF described for this command.
Messages with the "E" bit set are commonly referred to as error messages.
This bit MUST NOT be set in request messages.
The "T" bit – This flag is set after a link failover procedure, to aid the removal of
duplicate requests.
It is set when resending requests not yet acknowledged as an indication of a possible
duplicate due to a link failure.
Commands Each command is assigned a command code, which
is used for both Requests and Answers.
The values 0-255 are reserved for RADIUS backward compatibility.
The values 256-16777213 are for permanent, standard commands allocated by IANA.
The values 16777214 and 16777215 are reserved for experimental and testing purposes.
Some common Diameter commands are: Attribute-Value Pairs
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.
State machines The RFC 3588 defines a core state machine
for maintaining connections between peers and processing messages.
This is part of the basic protocol functionality and all stacks should support it and as such
abstract from the connectivity related operations.
Additionally, application specific state machines can be introduced either later or at a higher
abstraction layer.
The RFC 3588 defines an authorization and an accounting state machine.
Message flows
The communication between two diameter peers starts with the establishment of a transport
connection.
The initiator then sends a Capabilities-Exchange-Request to the other peer, which responds with a Capabilities-Exchange-Answer.
For RFC3588 compliant peers TLS may optionally be negotiated.
For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA.
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
and the other peer must respond with Device-Watchdog-Answer.
Either side may terminate the communication by sending a Disconnect-Peer-Request which
the other peer must respond to with Disconnect-Peer-Answer.
After that the transport connection can be disconnected.
RFCs The Diameter protocol is currently defined
in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.
See also List of authentication protocols
Host Identity Protocol References
External links Introduction to Diameter - Get the next generation
AAA protocol Cisco page outlining differences between RADIUS
and DIAMETER Diameter: next generation’s AAA protocol
Paper about Diameter by Håkan Ventura The Open IMS Core JavaDiameterPeer The Open
IMS Core JavaDiameterPeer freeDiameter, open-source implementation of
Diameter Base Protocol and Extensions go-diameter, open-source implementation of
Diameter Base Protocol for the Go programming language
Reference page listing vendors of Diameter Gateways, Diameter Signaling Controllers and
Diameter Stacks