Description

Glossary

RFCs

Publications

Obsolete RFCs

Description:

RFC 3588:

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations.

The Diameter protocol consists of the Diameter header followed by one or more AVP structures.

Diameter header:

Version. 8 bits.
Diameter protocol version.

Message length. 24 bits.
Size of the Diameter message including the header fields.

Flags. 8 bits.

R, Request. 1 bit.
If set, the message is a request. Otherwise the message is an answer.

P, Proxiable. 1 bit.
If set, the message MAY be proxied, relayed or redirected. Otherwise the message MUST be locally processed.

E, Error. 1 bit.
If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with this bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages.

T, Potentially retransmitted message. 1 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. This bit MUST be cleared when sending a request for the first time, otherwise the sender MUST set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request. Retransmissions by other entities do not need to be tracked. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request and the request is sent again. This flag MUST NOT be set in answer messages.

reserved. 4 bits.
Must be cleared to zero.

Code. 24 bits.

Application ID. 32 bits.
Used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. The application ID in the header MUST be the same as what is contained in any relevant AVPs contained in the message.

Hop by Hop ID. 32 bits, unsigned.
This field aids in matching requests and replies. The sender MUST ensure that the identifier in a request is unique on a given connection at any given time, and MAY attempt to ensure that the number is unique across reboots. The sender of an Answer message MUST ensure that this field contains the same value that was found in the corresponding request. The identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown identifier MUST be discarded.

End to End ID. 32 bits, unsigned.
This field is used to detect duplicate messages. Upon reboot implementations MAY set the high order 12 bits to contain the low order 12 bits of current time, and the low order 20 bits to a random value. Senders of request messages MUST insert a unique identifier on each message. The identifier MUST remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an Answer message MUST ensure that the field contains the same value that was found in the corresponding request. This field MUST NOT be modified by Diameter agents of any kind. The combination of the Origin-Host and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the Hop by Hop ID field and any routing AVPs that may be present), and MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed SHOULD be silently discarded.

AVP, Attribute Value Pair.
A structure used to encapsulate protocol specific data as well as authentication, authorization and accounting information.

AVP code. 32 bits.
When combined with the Vendor ID the attribute is uniquely identified. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor ID field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.

AVP flags. 8 bits.

V, Vendor specific. 1 bit.
If set, the Vendor ID field is present.

M, Mandatory. 1 bit.
If set, support of this AVP is required.

P. 1 bit.
If set, encryption for end to end security is needed.

reserved. 5 bits.
Must be cleared to zero.

AVP length. 24 bits.
Total size of the AVP header and data in bytes.

Vendor ID. 32 bits.
This field is present if the V bit is set in the AVP Flags field. This field contains the IANA assigned "SMI Network Management Private Enterprise Codes" value, encoded in network byte order. Any vendor wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s), nor with future IETF applications. A value of zero corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of this field implies that the AVP in question is not vendor specific, implementations MUST NOT use the zero value.

Glossary:

Diameter Agent.
A Diameter node that provides either relay, proxy, redirect or translation services.

Diameter Client.
A device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA).

Diameter Node.
A host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.

Diameter Peer.
A Diameter Node to which a given Diameter Node has a direct transport connection.

Diameter Security Exchange.
A process through which two Diameter nodes establish end-to-end security.

Diameter Server.
A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server MUST support Diameter applications in addition to the base protocol.

Home Realm.
The administrative domain with which the user maintains an account relationship.

Local Realm.
The administrative domain providing services to a user. An administrative domain MAY act as a local realm for certain users, while being a home realm for others.

NAI, Network Access Identifier.
Used to extract the identity and realm of a user. The identity is used to recognize the user during authentication and/or authorization, while the realm is used for message routing purposes.

Realm.
The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally, or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it.

RFCs:

[RFC 2924] Accounting Attributes and Record Formats.

• Category: Informational.

[RFC 3127] Authentication, Authorization, and Accounting: Protocol Evaluation.

• Category: Informational.

[RFC 3588] Diameter Base Protocol.

• Category: Standards Track.
• Defines Diameter version 1.
• Defines URI schemes aaa:, aaas:.

[RFC 3589] Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5.

• Category: Informational.

[RFC 3955] Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX).

• Category: Informational.

[RFC 4004] Diameter Mobile IPv4 Application.

• Category: Standards Track.
• Defines Diameter command codes 260 and 262.
• Defines Diameter AVP codes 318 - 323, 325, 326, 328, 329, 331 - 348, 367.

[RFC 4005] Diameter Network Access Server Application.

• Category: Standards Track.
• Defines Diameter command codes 258, 265, 271, 274, 275.
• Defines Diameter AVP codes 295, 363 - 366, 400 - 408.

[RFC 4006] Diameter Credit-Control Application.

• Category: Standards Track.
• Defines Diameter command code 272 (Credit-Control-Request, Credit-Control-Answer).
• Defines Diameter AVP codes 411 - 461.

[RFC 4072] Diameter Extensible Authentication Protocol (EAP) Application.

• Category: Standards Track.
• Defines Diameter command code 268.
• Defines Diameter AVP codes 462 - 465.
• Defines RADIUS AVP code 102 (EAP-Key-Name).

Publications:

Obsolete RFCs:

Description

Glossary

RFCs

Publications

Obsolete RFCs