Diameter Base Protocol
obsoletes
- rfc-3588 — Diameter Base Protocol
- rfc-5719 — Updated IANA Considerations for Diameter Command Code Allocations
updated by
Extracted elements (31)
The ability to re-exchange CER/CEA in the Open state was deprecated because the multiplicity of Application-Id AVP meanings during dynamic capability re-exchange was considered an abuse of Diameter extensibility and too ambiguous to implement correctly. This feature was later re-introduced in a clean form in RFC 6737 using explicitly defined new commands.
The Inband-Security AVP mechanism for negotiating TLS was deprecated because bootstrapping TLS through CER/CEA exchanges means those messages are sent unprotected, creating a window where an active attacker can observe or tamper with capability negotiation. The fix—a well-known port (5658) where TLS is established before any Diameter traffic—closes this vulnerability.
Diameter is designed for coexistence with RADIUS via translation agents (TLAs). AVP codes 1–255 are reserved for RADIUS backward compatibility. Translation agents MUST be session-stateful and MUST maintain transaction state; they MUST only advertise their locally supported applications. RADIUS deployments can migrate incrementally by inserting a TLA at the boundary without requiring all NAS devices to be upgraded simultaneously.
A new Command Code MUST be allocated when required AVPs are added to, deleted from, or redefined in an existing command's CCF, or when transport characteristics (e.g., number of round trips) change. Such a CCF change MUST also trigger the definition of a new Diameter application for any application using that command.
Before initiating a connection, a Diameter peer MUST verify that its peers are authorized to act in their claimed roles. The home server MUST check Route-Record AVPs to confirm that the traversed path is acceptable, returning DIAMETER_AUTHORIZATION_REJECTED if not. Diameter sessions MUST be routed only through nodes that have advertised support for the required Diameter application.
Diameter SCTP messages SHOULD be mapped to avoid head-of-line (HOL) blocking; the RECOMMENDED approach is to send every Diameter message over stream zero with the unordered flag set. The receiving entity MUST be ready to receive Diameter messages over any SCTP stream. During connection establishment, the responder SHOULD NOT use out-of-order delivery until the first message is received from the initiator, to avoid a race condition with CEA delivery.
If the M-bit is set in a received AVP and the receiver does not understand the AVP or its values, the receiver MUST return a failure (DIAMETER_AVP_UNSUPPORTED for unrecognized AVPs). The M-bit setting and the CCF occurrence specifier for an AVP are independent and serve different purposes; the M-bit is application-command scoped, not AVP-global.
Relay and proxy agents MUST NOT reorder AVPs in a Diameter message. Relay agents SHOULD NOT maintain session state but MUST maintain transaction state, saving the incoming Hop-by-Hop Identifier and replacing it with a locally unique value when forwarding, then restoring the original when the corresponding answer is received.
Session state MUST be freed upon receipt of Session-Termination-Request, Session-Termination-Answer, expiration of Session-Timeout, and per application-specific rules. A 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 instead.
The Diameter base protocol runs on port 3868 for both TCP and SCTP. A node initiating a TLS/TCP or DTLS/SCTP connection prior to any message exchange MUST use port 5658. When DNS SRV-based peer discovery is used, port numbers from SRV records take precedence over the defaults (3868 and 5658).
The Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec. All Diameter base protocol implementations MUST support TLS/TCP and DTLS/SCTP. Connections between Diameter peers SHOULD be protected by TLS/TCP and DTLS/SCTP.
The End-to-End Identifier MUST remain locally unique for at least 4 minutes even across reboots; request senders MUST insert a unique value on each message. Answer originators MUST copy the End-to-End Identifier from the corresponding request. Diameter agents MUST NOT modify it; the combination of Origin-Host and this field is used for duplicate detection.
The Hop-by-Hop Identifier MUST be unique on a given connection at any given time. The sender of an answer MUST copy the Hop-by-Hop Identifier from the corresponding request. An answer received with an unknown Hop-by-Hop Identifier MUST be discarded.
Capabilities Exchange uses CER (Capabilities-Exchange-Request, command code 257) and CEA messages exchanged at connection establishment. They carry Origin-Host, Origin-Realm, Host-IP-Address, Vendor-Id, Product-Name, and lists of supported Auth-Application-Id and Acct-Application-Id AVPs. Relay and redirect agents MUST advertise the Relay Application ID (0xffffffff); other nodes MUST advertise only locally supported applications.
The Command Flags byte carries four defined bits: R (set = Request, cleared = Answer), P (set = message MAY be proxied/relayed/redirected; cleared = MUST be processed locally), E (set = protocol error in message; MUST NOT be set in requests), and T (set = potentially retransmitted after link failover for duplicate detection). Remaining four bits are reserved, MUST be zero, and MUST be ignored by the receiver.
The Proxy-Info Grouped AVP contains Proxy-Host and Proxy-State sub-AVPs. It allows stateless agents to embed opaque local state in a Diameter request with the guarantee that the same state appears in the corresponding answer, enabling stateless proxy operation without per-session storage while preserving per-request context across the forwarding path.
The Result-Code AVP indicates the outcome of a Diameter request in five classes: Informational (1xxx), Success (2xxx), Protocol Errors (3xxx, used with E-bit set in the answer), Transient Failures (4xxx, retry may succeed), and Permanent Failures (5xxx). Key codes include DIAMETER_UNABLE_TO_DELIVER (3002), DIAMETER_AUTHORIZATION_REJECTED (5003), and DIAMETER_UNABLE_TO_COMPLY (5009).
The Route-Record AVP carries the DiameterIdentity of a relay or proxy that forwarded a request. Relay and proxy agents MUST append a Route-Record AVP containing the identity of the peer from which the request was received to all forwarded requests, enabling the home server to perform path authorization checks and detect routing loops via the Route-Record list.
The Session-Id AVP globally and eternally uniquely identifies a Diameter user session; its value MUST be globally unique and never reused. Its format is '<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]', where the high-order 32 bits commonly encode time and the low-order 32 bits are a monotonically increasing counter. All messages within a session MUST carry the same Session-Id.
Two SCTP payload protocol identifiers (PPIDs) are allocated for Diameter: PPID 46 for Diameter messages in cleartext SCTP DATA chunks, and PPID 47 for Diameter messages in DTLS/SCTP-protected DATA chunks. Diameter agents SHOULD use these dedicated PPIDs instead of the unspecified identifier (value 0) to allow distinguishing encrypted from unencrypted Diameter traffic.
IANA assigns Diameter Application IDs in a flat, unversioned space. Pre-assigned values include: Diameter common message (0), Diameter base accounting (3), and Relay (0xffffffff). Each Diameter application specification MUST have an IANA-assigned Application ID; there is no version relationship between applications sharing the same ID space.
IANA manages the 24-bit Diameter Command Code space. Values 16,777,214 (0xFFFFFE) and 16,777,215 (0xFFFFFF) are reserved for experimental use. Base protocol command codes include CER/CEA (257), RAR/RAA (258), ACR/ACA (271), ASR/ASA (274), STR/STA (275), DWR/DWA (280), and DPR/DPA (282). New codes for vendor-specific use may be allocated under a relaxed policy compared to RFC 3588.
IANA manages the Diameter AVP Code space. AVP codes 1–255 are reserved for backward compatibility with RADIUS attributes. Codes 256 and above are Diameter-native; new base protocol AVPs require a Standards Track RFC. Vendor-specific AVPs use the V-bit combined with a Vendor-ID field and are managed by the respective vendor organization.
AVPs containing sensitive user credentials or identity information must be protected by transport-level security (TLS/DTLS/IPsec) since Diameter no longer provides an end-to-end AVP-level security framework. Implementations must be aware that agents may inspect and modify AVPs in transit, so sensitive data should traverse only trusted paths.
Both connection-level authentication and session-level authorization are required: peers must verify that connecting nodes are authorized to act in their advertised roles, not merely that they authenticated. The home server MUST check Route-Record AVPs to authorize the full routing path. The End-to-End security framework (E2E-Sequence AVP and P-bit in the AVP header) has been deprecated; transport-level security replaces it.
TLS/TCP and DTLS/SCTP are the primary mandatory transport security mechanisms. Using a dedicated secured port (5658) where TLS is established before any Diameter messages is the required approach; the deprecated Inband-Security AVP negotiation left CER/CEA messages unprotected. IPsec is an acceptable alternative but secondary to TLS/DTLS.
The Accounting Session State Machine manages accounting lifecycle on both client and server with states Idle, Pending S (awaiting Start ACK), Open, Pending E (awaiting End ACK), and Pending B (buffered records). Transitions are driven by Accounting-Request/Answer exchanges, interim record timers (Acct-Interim-Interval), and session termination events.
The Authorization Session State Machine defines client and server state machines with states Idle, Pending, Open, and Discon. Transitions occur on access requests (AA-Request), authorization responses (AA-Answer), Re-Auth-Request, Session-Termination-Request, and session timeout. Separate machines handle stateful (server stores session state) and stateless (server does not maintain state) modes.
The Diameter peer state machine defines states: Closed, Wait-Conn-Ack, Wait-I-CEA, Wait-Conn-Ack/Elect, Wait-Returns, R-Open, I-Open, and Closing. Key transitions are triggered by Start (initiator), R-Conn-CER (responder receives connection), I-Rcv-CEA (initiator receives CEA), Timeout, and Disconnect. An election process using Origin-Host string comparison resolves simultaneous connection attempts between the same pair of peers.
The AVP header contains AVP Code (4 octets), AVP Flags (1 octet: V, M, P bits plus 5 reserved bits), AVP Length (3 octets, includes header and value but not padding), optionally Vendor-ID (4 octets, present only when V-bit is set), followed by data padded to a 4-octet boundary.
The Diameter header is 20 octets: Version (1 octet, MUST be 1), Message Length (3 octets, always a multiple of 4 including header and padded AVPs), Command Flags (1 octet), Command Code (3 octets), Application-ID (4 octets), Hop-by-Hop Identifier (4 octets, unsigned 32-bit), and End-to-End Identifier (4 octets, unsigned 32-bit). All fields are transmitted in network byte order.