Diameter Base Protocol
Extracted elements (31)
Diameter runs over reliable transport (TCP/SCTP) rather than UDP as used by RADIUS because RADIUS's undefined retransmission behavior caused variable reliability across implementations, and in accounting, UDP packet loss translates directly into revenue loss. SCTP is preferred when available because multi-streaming prevents head-of-line blocking that TCP suffers from.
IPsec was made mandatory (not merely optional as in RADIUS/RFC 3162) because IKE authentication occurs only in Phase 1 prior to SA establishment in Phase 2, making it impossible to define separate trust or authorization schemes per application — a critical limitation for inter-domain AAA roaming requiring distinct certificate hierarchies per deployment.
New Command Codes are restricted to IETF Consensus to prevent proliferation; instead, application extensibility is achieved by adding non-mandatory AVPs to existing commands or by defining new mandatory AVPs within a new Application Identifier. A new application must define at least one new Command Code or add new mandatory AVPs to justify its Application Identifier allocation.
Translation agents provide protocol interoperability between Diameter and RADIUS or TACACS+. They allow legacy RADIUS-only devices to communicate with a Diameter infrastructure without requiring simultaneous migration. Translation can only occur when the agent recognizes the application of the request, so translation agents MUST advertise only their locally supported applications.
Before initiating a connection, a Diameter peer MUST check that its peer is authorized to act in its role. The home server MUST inspect Route-Record AVPs to verify that the route traversed by a request is acceptable; unauthorized paths MUST be rejected with DIAMETER_AUTHORIZATION_REJECTED.
Diameter clients MUST support either TCP or SCTP. Diameter agents and servers MUST support both TCP and SCTP. All Diameter nodes MUST be prepared to receive connections on port 3868. A given peer state machine instance MUST NOT use more than one transport connection to communicate with a given peer.
Diameter clients MUST support IPsec and MAY support TLS. Diameter servers MUST support both TLS and IPsec. The Diameter protocol MUST NOT be used without a security mechanism (TLS or IPsec). IPsec is recommended for intra-domain traffic; TLS for inter-domain.
Each Diameter application MUST have an IANA-assigned Application Identifier. Relay and redirect agents MUST advertise the Relay Application Identifier (0xffffffff). All other nodes MUST advertise only locally supported applications. The Application-ID in the header MUST match that in relevant AVPs.
Every Diameter implementation MUST support accounting. A new accounting application MUST NOT be created unless it defines a new command or adds new mandatory AVPs. Within an accounting command, the M bit MUST NOT be set on AVPs irrelevant to billing, even if M is set when the same AVP appears in auth commands.
Proxies that wish to limit resources MUST maintain session state; all proxies MUST maintain transaction state. Relay agents MUST NOT reorder AVPs, and proxies MUST NOT reorder AVPs. Translation agents MUST be session-stateful and MUST maintain transaction state.
Session state MUST be freed upon receipt of Session-Termination-Request or Session-Termination-Answer, upon expiry of the Session-Timeout AVP, and according to rules established by the particular Diameter application.
The E (Error) bit MUST NOT be set in request messages. The T (potentially re-transmitted) flag MUST be cleared when sending a request for the first time and MUST be set when resending an unacknowledged request after link failover. Agents receiving a request with T set MUST forward it with T set.
The End-to-End Identifier MUST remain locally unique for at least 4 minutes even across reboots, MUST NOT be modified by any Diameter agent, and MUST be echoed unchanged in answers. Duplicate requests SHOULD elicit the same answer and MUST NOT alter state set when the original was processed.
The Hop-by-Hop Identifier in a request MUST be unique on a given connection at any given time. An answer MUST echo the same Hop-by-Hop Identifier as the corresponding request. An answer received with an unknown Hop-by-Hop Identifier MUST be discarded.
Capabilities Exchange (CER/CEA, Command Code 257) is the first message pair exchanged between Diameter peers. It negotiates supported applications (via Auth-Application-Id, Acct-Application-Id), host identity, IP addresses, security mechanisms (Inband-Security-Id), and vendor information. A peer receiving an unsupported application MUST reply with DIAMETER_NO_COMMON_APPLICATION.
Device-Watchdog-Request/Answer (DWR/DWA, Code 280) are used for transport failure detection between peers. The transport failure algorithm uses watchdog messages to detect failures when no traffic is flowing, triggering failover and failback procedures as defined in the Diameter Transport Profile.
Re-Auth-Request (RAR) and Re-Auth-Answer (RAA) messages (Command Code 258) allow a server to initiate re-authentication or re-authorization of an active session. The Re-Auth-Request-Type AVP specifies AUTHORIZE_ONLY or AUTHORIZE_AUTHENTICATE. Server-initiated re-auth support is mandatory in Diameter.
Result-Code AVP (Section 7.1) classifies outcomes as: Informational (1xxx), Success (2xxx), Protocol Errors (3xxx — carried with E bit set, may be generated by any node), Transient Failures (4xxx — retry may succeed), and Permanent Failures (5xxx — retry will not help). Experimental outcomes use Experimental-Result AVP with a vendor-assigned code.
Route-Record AVP and Proxy-Info AVP (Section 6.7) support routing audit and stateless proxy operation. Relay and proxy agents MUST append a Route-Record AVP containing the identity of the upstream peer to all forwarded requests. Proxy-Info allows stateless agents to embed opaque local state that is returned verbatim in the corresponding answer.
Session-Id AVP (Section 8.8) uniquely identifies a Diameter session globally and eternally. It MUST be present in all messages associated with a session and is formatted as: DiameterIdentity ';' high-32-bits-of-time ';' low-32-bits ';' optional-value. The same Session-Id binds all messages for a given user session.
The Realm Routing Table entries contain: Realm Name (primary lookup key), Application Identifier (secondary key), Local Action (LOCAL/RELAY/PROXY/REDIRECT), Server Identifier(s), and Static/Dynamic flag with expiration time. Agents MUST support at least one of LOCAL, RELAY, PROXY, or REDIRECT action types.
IANA manages the Diameter Application Identifier registry. Defined values: Diameter Common Messages (0), NASREQ (1), Mobile-IP (2), Diameter Base Accounting (3), Relay (0xffffffff). Every Diameter application specification MUST have an IANA-assigned or vendor-specific Application Identifier.
IANA manages the Diameter AVP Code namespace (Section 11.1.1). New AVP codes require an IANA request with specification and list of commands that use the AVP. The registry also covers AVP Flags, Result-Code AVP Values, Accounting-Record-Type, Termination-Cause, Disconnect-Cause, and other enumerated AVP value spaces.
IANA manages the Diameter Command Code registry (24-bit space); new codes can only be created by IETF Consensus. Values 16,777,214–16,777,215 (0xFFFFFE–0xFFFFFF) are reserved for experimental use. Base protocol defines codes 257 (CER/CEA), 258 (RAR/RAA), 271 (ACR/ACA), 274 (ASR/ASA), 275 (STR/STA), 280 (DWR/DWA), 282 (DPR/DPA).
Accounting requests without corresponding authorization responses SHOULD be subjected to further scrutiny. A Diameter client receiving an authorization response for a service it cannot perform MUST NOT substitute an alternate service and then send accounting requests for that alternate service.
IPsec provides hop-by-hop security but does not protect the full end-to-end Diameter path when agents are involved. End-to-end security (data-object integrity and confidentiality for sensitive AVPs such as keys, passwords, and accounting data) is provided by the CMS-based extension [AAACMS]. All Diameter implementations are strongly RECOMMENDED to support end-to-end security.
The Accounting Session State Machine (Section 8.2) has states: Idle, Pending-S, Pending-E, Pending-B, Open, and Pending-I. Transitions are driven by application accounting events (START, INTERIM, STOP, EVENT), ACR/ACA exchanges, timer expirations, and success or failure responses from the accounting server.
The Authorization Session State Machine (Section 8.1) has states: Idle, Pending, Open, and Disconnected. Two variants exist — stateful (server maintains session state) and stateless. Transitions are triggered by authorization requests and answers, re-auth requests (RAR/RAA), session timeouts, and session termination (STR/STA).
The Peer State Machine (Section 5.6) governs transport-level peer connections with states: Closed, Wait-Conn-Ack, Wait-I-CEA, Open, Closing, and Wait-Returns. Events include Start, R-Conn-CER (incoming connection), I-Rcv-CEA, Timeout, Disconnect, and Error; the Election Process resolves simultaneous open attempts.
The AVP format consists of: AVP Code (4 octets), AVP Flags (1 octet; V=vendor-specific, M=mandatory, P=end-to-end protected), AVP Length (3 octets covering header and data), optional Vendor-ID (4 octets, present only when V bit set), and variable-length Data. AVPs are padded to a 32-bit boundary though padding is not included in AVP Length.
The Diameter message header contains: Version (1 octet, MUST be 1), Message Length (3 octets, total message size), Command Flags (1 octet: R/P/E/T bits plus 4 reserved), Command-Code (3 octets), Application-ID (4 octets), Hop-by-Hop Identifier (4 octets, unsigned), and End-to-End Identifier (4 octets, unsigned). All fields transmitted in network byte order.