JBoss.orgCommunity Documentation
Diameter is a computer networking protocol for AAA (Authentication, Authorization and Accounting) defined in RFC 3588. It is a successor to RADIUS (and its name is a reference to it, a diameter is twice the radius). Diameter has been desgined to overcome certain RADIUS limitations:
No transport reliability and flexibility (Diameter uses TCP/SCTP instead of UDP)
No security within protocol (Diameter supports IPSec (mandatory) and TLS (optional))
Limited address space for AVPs (Diameter uses 32-bit address space instead of 8-bit)
Only stateless mode is possible (Diameter supports both stateful and stateless modes)
Static peers (Diameter offers dynamic discovery, using DNS SRV and NAPTR)
No peer alignment capabilities (Diameter introduce capabilities negotiation)
No support for transport layer failover (Diameter follows RFC3539, which introduces proper procedures)
Limited support for roaming (Diameter introduces mechanisms for secure and scalable roaming)
No extension possible (Diameter allows extension - new commands and avps to be defined)
Diameter offers all capabilities of RADIUS protocol. Also as a logical successor, it is comptibile with RADIUS.
Diameter also allows to define extensions. Each extension is called "Application".
Each application may introduce new types of messages, AVP codes, and state machines. The Message and AVP codes are assigned by the IANA. Furthermore, each application has its own Application ID and Vendor ID that is used to distinguish between applications. In addition, application code is used to signal to other peers which operations are supported by connecting peer (Capabilities Exchange / Negotiation).
Diameter is a byte based protocol. Each message has a fixed structure, which consists of two parts: header and payload.
Message header structure is common for all messages, it has a fixed length and content. It identifies message (by code, application and certain bit flags) in Diameter scope.
Payload is the message part built of carried AVPs. Its content differs for each command and application (however ALL define Session-Id AVP as mandatory).
Header has following fields:
Message Headers
Indicates the Diameter protocol version. This value is always set to 1
.
Indicates the Diameter message length, including the header fields.
Composed by eight bits, to provide information regarding message. First four bits in Flags octet have following meaning:
R = Message is a request (1)
or an answer (0)
;
P = Message is proxiable (1)
and may be proxied, relayed or redirected, otherwise it must be processed locally (0)
;
E = Message is an error message (1)
or a regular message(0)
;
T = Message is being potentially re-transmitted (1)
or being sent for the first time (0)
The last four bits are reserved for future use, and should be set to 0
.
Indicates the command associated with the message.
Identifies application to which the message is applicable for. The application can be an authentication, accounting, or 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.
Unique ID that is used to match requests and answer. The Answer message must ensure this header field contains the same value present in the corresponding request. This is how answers are routed back to peer which sent message.
Time-limited unique ID that is used to to detect duplicate messages. The ID must be unique for at least four minutes. The Answer message originator must ensure that this header contains the same value present in the corresponding request.
Message payload is built up from AVPs. Each AVP has similar structure: header and encoded data. Data can be simple (eg, integer, long) or complex (another encoded AVP).
Payload AVPs
Uniquely identifies the attribute, by combining the specified code with the value contained within the Vendor-ID header field.
AVP numbers 1 to 255 are reserved for RADIUS backwards compatibility, and do not require the Vendor-ID header field. AVP numbers 256 and above are used exclusively for the Diameter protocol, and are allocated by IANA.
Bit flags, which specify how each attribute must be handled. Flags octet has following structure: V M P r r r r r.
Full description can be found in Section 4.1 of RFC3588.
First three bits have the following meaning:
V = If set, indicates that optional octets (Vendor-ID) is present in AVP header.
M = If set, it indicates that receiveing peer must understand this AVP or send error answer.
P = If set, it indicates the need for encryption for end-to-end security.
The last 5 bits are reserved for future use, and should be set to 0
.
Indicates the number of octets in the AVP, including the following information:
AVP Code
AVP Length
AVP Flags
Vendor-ID field (if present)
AVP Data
Optional octet identifying AVP in application space. AVP code and AVP Vendor-ID create unique identifier for AVP.
Mobicents Diameter core is built on top of three basic components:
Extensible Diameter stack. It provides basic session support along with application specific sessions.
Diameter Stack multiplexer. Allows different listeners to share the same stack instance.
Diameter Message and AVP dictionary. Provides an API to access information about AVP: Flags, Type, assigned values, etc. Dictionary is embeded in the MUX.