RFC 6733
Diameter Base Protocol
RFC 6733: Diameter Base Protocol 🎀
- Internet Engineering Task Force (IETF) 🌸
- Request for Comments: 6733
- Obsoletes: 3588, 5719
- Category: Standards Track
- ISSN: 2070-1721
- Date: October 2012
- Authors: V. Fajardo, Ed. (Telcordia Technologies), J. Arkko (Ericsson Research), J. Loughney (Nokia Research Center), and G. Zorn, Ed. (Network Zen) 👑
Abstract 💖
Okay so the Diameter base protocol is basically the AAA framework (that's Authentication, Authorization, and Accounting) for stuff like network access or IP mobility, whether you're at home or roaming 🌍. This doc covers the message format, transport, error reporting, accounting, and security services that every Diameter application uses, so it's the foundation for everything else. It obsoletes RFC 3588 and RFC 5719, and every new Diameter implementation must support it, no exceptions 🫶.
Status of This Memo ✨
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🔥. If you want more info on Internet Standards, check out Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6733 💅.
Copyright Notice 🌈
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info and which are in effect on the date of publication. Please read them carefully, because they explain your rights and restrictions for this document 📜. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🧚.
Table of Contents 📖
1. Introduction ....................................................7
1.1. Diameter Protocol ..........................................9
1.1.1. Description of the Document Set ....................10
1.1.2. Conventions Used in This Document ..................11
1.1.3. Changes from RFC 3588 ..............................11
1.2. Terminology ...............................................12
1.3. Approach to Extensibility .................................17
1.3.1. Defining New AVP Values ............................18
1.3.2. Creating New AVPs ..................................18
1.3.3. Creating New Commands ..............................18
1.3.4. Creating New Diameter Applications .................19
2. Protocol Overview ..............................................20
2.1. Transport .................................................22
2.1.1. SCTP Guidelines ....................................23
2.2. Securing Diameter Messages ................................24
2.3. Diameter Application Compliance ...........................24
2.4. Application Identifiers ...................................24
2.5. Connections vs. Sessions ..................................25
2.6. Peer Table ................................................26
2.7. Routing Table .............................................27
2.8. Role of Diameter Agents ...................................28
2.8.1. Relay Agents .......................................30
2.8.2. Proxy Agents .......................................31
2.8.3. Redirect Agents ....................................31
2.8.4. Translation Agents .................................32
2.9. Diameter Path Authorization ...............................33
3. Diameter Header ................................................34
3.1. Command Codes .............................................37
3.2. Command Code Format Specification .........................38
3.3. Diameter Command Naming Conventions .......................40
4. Diameter AVPs ..................................................40
4.1. AVP Header ................................................41
4.1.1. Optional Header Elements ...........................42
4.2. Basic AVP Data Formats ....................................43
4.3. Derived AVP Data Formats ..................................44
4.3.1. Common Derived AVP Data Formats ....................44
4.4. Grouped AVP Values ........................................51
4.4.1. Example AVP with a Grouped Data Type ...............52
4.5. Diameter Base Protocol AVPs ...............................55
5. Diameter Peers .................................................58
5.1. Peer Connections ..........................................58
5.2. Diameter Peer Discovery ...................................59
5.3. Capabilities Exchange .....................................60
5.3.1. Capabilities-Exchange-Request ......................62
5.3.2. Capabilities-Exchange-Answer .......................63
5.3.3. Vendor-Id AVP ......................................63
5.3.4. Firmware-Revision AVP ..............................64
5.3.5. Host-IP-Address AVP ................................64
5.3.6. Supported-Vendor-Id AVP ............................64
5.3.7. Product-Name AVP ...................................64
5.4. Disconnecting Peer Connections ............................64
5.4.1. Disconnect-Peer-Request ............................65
5.4.2. Disconnect-Peer-Answer .............................65
5.4.3. Disconnect-Cause AVP ...............................66
5.5. Transport Failure Detection ...............................66
5.5.1. Device-Watchdog-Request ............................67
5.5.2. Device-Watchdog-Answer .............................67
5.5.3. Transport Failure Algorithm ........................67
5.5.4. Failover and Failback Procedures ...................67
5.6. Peer State Machine ........................................68
5.6.1. Incoming Connections ...............................71
5.6.2. Events .............................................71
5.6.3. Actions ............................................72
5.6.4. The Election Process ...............................74Okay bestie, the table of contents keeps going and it's giving main character energy 🎀✨
6. Diameter Message Processing ....................................74
6.1. Diameter Request Routing Overview .........................74
6.1.1. Originating a Request ..............................75
6.1.2. Sending a Request ..................................76
6.1.3. Receiving Requests .................................76
6.1.4. Processing Local Requests ..........................76
6.1.5. Request Forwarding .................................77
6.1.6. Request Routing ....................................77
6.1.7. Predictive Loop Avoidance ..........................77
6.1.8. Redirecting Requests ...............................78
6.1.9. Relaying and Proxying Requests .....................79
6.2. Diameter Answer Processing ................................80
6.2.1. Processing Received Answers ........................81
6.2.2. Relaying and Proxying Answers ......................81
6.3. Origin-Host AVP ...........................................81
6.4. Origin-Realm AVP ..........................................82
6.5. Destination-Host AVP ......................................82
6.6. Destination-Realm AVP .....................................82
6.7. Routing AVPs ..............................................83
6.7.1. Route-Record AVP ...................................83
6.7.2. Proxy-Info AVP .....................................83
6.7.3. Proxy-Host AVP .....................................83
6.7.4. Proxy-State AVP ....................................83
6.8. Auth-Application-Id AVP ...................................83
6.9. Acct-Application-Id AVP ...................................84
6.10. Inband-Security-Id AVP ...................................84
6.11. Vendor-Specific-Application-Id AVP .......................84
6.12. Redirect-Host AVP ........................................85
6.13. Redirect-Host-Usage AVP ..................................85
6.14. Redirect-Max-Cache-Time AVP ..............................87
7. Error Handling .................................................87
7.1. Result-Code AVP ...........................................89
7.1.1. Informational ......................................90
7.1.2. Success ............................................90
7.1.3. Protocol Errors ....................................90
7.1.4. Transient Failures .................................92
7.1.5. Permanent Failures .................................92
7.2. Error Bit .................................................95
7.3. Error-Message AVP .........................................96
7.4. Error-Reporting-Host AVP ..................................96
7.5. Failed-AVP AVP ............................................96
7.6. Experimental-Result AVP ...................................97
7.7. Experimental-Result-Code AVP ..............................97
8. Diameter User Sessions .........................................98
8.1. Authorization Session State Machine .......................99
8.2. Accounting Session State Machine .........................104
8.3. Server-Initiated Re-Auth .................................110
8.3.1. Re-Auth-Request ...................................110
8.3.2. Re-Auth-Answer ....................................110
8.4. Session Termination ......................................111
8.4.1. Session-Termination-Request .......................112
8.4.2. Session-Termination-Answer ........................113
8.5. Aborting a Session .......................................113
8.5.1. Abort-Session-Request .............................114
8.5.2. Abort-Session-Answer ..............................114
8.6. Inferring Session Termination from Origin-State-Id .......115
8.7. Auth-Request-Type AVP ....................................116
8.8. Session-Id AVP ...........................................116
8.9. Authorization-Lifetime AVP ...............................117
8.10. Auth-Grace-Period AVP ...................................118
8.11. Auth-Session-State AVP ..................................118
8.12. Re-Auth-Request-Type AVP ................................118
8.13. Session-Timeout AVP .....................................119
8.14. User-Name AVP ...........................................119
8.15. Termination-Cause AVP ...................................120
8.16. Origin-State-Id AVP .....................................120
8.17. Session-Binding AVP .....................................120
8.18. Session-Server-Failover AVP .............................121
8.19. Multi-Round-Time-Out AVP ................................122
8.20. Class AVP ...............................................122
8.21. Event-Timestamp AVP .....................................122
9. Accounting ....................................................123
9.1. Server Directed Model ....................................123
9.2. Protocol Messages ........................................124
9.3. Accounting Application Extension and Requirements ........124
9.4. Fault Resilience .........................................125
9.5. Accounting Records .......................................125
9.6. Correlation of Accounting Records ........................126
9.7. Accounting Command Codes .................................127
9.7.1. Accounting-Request ................................127
9.7.2. Accounting-Answer .................................128
9.8. Accounting AVPs ..........................................129
9.8.1. Accounting-Record-Type AVP ........................129
9.8.2. Acct-Interim-Interval AVP .........................130
9.8.3. Accounting-Record-Number AVP ......................131
9.8.4. Acct-Session-Id AVP ...............................131
9.8.5. Acct-Multi-Session-Id AVP .........................131
9.8.6. Accounting-Sub-Session-Id AVP .....................131
9.8.7. Accounting-Realtime-Required AVP ..................132
10. AVP Occurrence Tables ........................................132
10.1. Base Protocol Command AVP Table .........................133
10.2. Accounting AVP Table ....................................134
11. IANA Considerations ..........................................135
11.1. AVP Header ..............................................135
11.1.1. AVP Codes ........................................136
11.1.2. AVP Flags ........................................136
11.2. Diameter Header .........................................136
11.2.1. Command Codes ....................................136
11.2.2. Command Flags ....................................137
11.3. AVP Values ..............................................137
11.3.1. Experimental-Result-Code AVP .....................137
11.3.2. Result-Code AVP Values ...........................137
11.3.3. Accounting-Record-Type AVP Values ................137
11.3.4. Termination-Cause AVP Values .....................137
11.3.5. Redirect-Host-Usage AVP Values ...................137
11.3.6. Session-Server-Failover AVP Values ...............137
11.3.7. Session-Binding AVP Values .......................137
11.3.8. Disconnect-Cause AVP Values ......................138
11.3.9. Auth-Request-Type AVP Values .....................138
11.3.10. Auth-Session-State AVP Values ...................138
11.3.11. Re-Auth-Request-Type AVP Values .................138
11.3.12. Accounting-Realtime-Required AVP Values .........138
11.3.13. Inband-Security-Id AVP (code 299) ...............138
11.4. _diameters Service Name and Port Number Registration ....138
11.5. SCTP Payload Protocol Identifiers .......................139
11.6. S-NAPTR Parameters ......................................139
12. Diameter Protocol-Related Configurable Parameters ............139
13. Security Considerations ......................................140
13.1. TLS/TCP and DTLS/SCTP Usage .............................140
13.2. Peer-to-Peer Considerations .............................141
13.3. AVP Considerations ......................................141
14. References ...................................................142
14.1. Normative References ....................................142
14.2. Informative References ..................................144
Appendix A. Acknowledgements .....................................147
A.1. This Document .............................................147
A.2. RFC 3588 ..................................................148
Appendix B. S-NAPTR Example ......................................148
Appendix C. Duplicate Detection ..................................149
Appendix D. Internationalized Domain Names .......................1511. Introduction ✨
Okay bestie, so AAA protocols (Authentication, Authorization, and Accounting) are the stuff that decides who gets to use a network and keeps track of it. TACACS [RFC1492] and RADIUS [RFC2865] were first made for dial-up PPP [RFC1661] and terminal server access 📞🌸. Then AAA was needed on loads of new access technologies, the networks got way bigger and messier, and people started using it for new stuff like voice over IP. So AAA protocols had a lot of new demands to deal with 💅.
Aboba, et al. [RFC2989] summarizes the network access requirements for AAA protocols. Here's what they include:
Failover 🔁
[RFC2865] doesn't define failover mechanisms, so failover behavior is different from one implementation to the next, which is chaotic 🙈. To get well-defined failover behavior, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine 🧠.
Transmission-level security 🔐
RADIUS [RFC2865] defines an application-layer authentication and integrity scheme that is required only for use with response packets. [RFC2869] adds another authentication and integrity mechanism, but it's only required during Extensible Authentication Protocol (EAP) [RFC3748] sessions. Attribute hiding is supported, but [RFC2865] doesn't support per-packet confidentiality 😭. And in accounting, [RFC2866] assumes the backend billing server handles replay protection, not the protocol itself.
[RFC3162] defines using IPsec with RADIUS, but support for IPsec is not required. So to get universal support for transmission-level security, and to make both intra- and inter-domain AAA deployments work, Diameter supports TLS/TCP and DTLS/SCTP 🦋. Security is discussed in Section 13, so go read it, it's serious business.
Reliable transport 🚚
RADIUS runs over UDP and doesn't define retransmission behavior, so reliability varies between implementations. [RFC2975] explains why this is a major issue in accounting, because packet loss can translate directly into revenue loss 💸. To get well-defined transport behavior, Diameter runs over reliable transport mechanisms (TCP, Stream Control Transmission Protocol (SCTP)) as defined in [RFC3539] 🫶.
Agent support 🧚
RADIUS doesn't provide explicit support for agents, which includes proxies, redirects, and relays. Since the expected behavior isn't defined, it varies from implementation to implementation. Diameter defines agent behavior explicitly, and you can read about it in Section 2.8 ✨.
Server-initiated messages 📣
Server-initiated messages are defined in RADIUS [RFC5176], but support for them is optional. That makes it hard to build features like unsolicited disconnect or re-authentication/re-authorization on demand across a mixed deployment 🙃. To fix this, support for server-initiated messages is mandatory in Diameter 👑.
Transition support 🌈
Diameter doesn't share a common protocol data unit (PDU) with RADIUS, but a lot of effort went into backward compatibility so the two protocols can be deployed on the same network 🤝. At first, Diameter is expected to be deployed within new network devices, and also within gateways that let legacy RADIUS devices talk to Diameter agents. This lets Diameter support get added to legacy networks by adding a gateway or server that speaks both RADIUS and Diameter 💖.
Besides addressing the requirements above, Diameter also provides support for the following:
Capability negotiation 🤓
RADIUS doesn't support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS clients and servers don't know each other's capabilities, they may not be able to agree on an acceptable service, or even know what service got implemented, which is giving chaos 💀. Diameter includes support for error handling (Section 7), capability negotiation (Section 5.3), and mandatory/non-mandatory Attribute-Value Pairs (AVPs) (Section 4.1) 🎀.
Peer discovery and configuration 🗺️
RADIUS implementations usually need the name or address of servers or clients to be manually configured, along with the matching shared secrets. That's a huge admin burden, and it tempts people to reuse the RADIUS shared secret, which can lead to major security vulnerabilities if the Request Authenticator isn't globally and temporally unique as required in [RFC2865] 😱. Through DNS, Diameter enables dynamic discovery of peers (see Section 5.2) 🌸. Derivation of dynamic session keys is enabled via transmission-level security 🔑.
Over time, Network Access Server (NAS) devices have gotten a lot more capable. So even though Diameter is a way more sophisticated protocol than RADIUS, it's still feasible to implement it within embedded devices 🍓.
1.1. Diameter Protocol 💜
The Diameter base protocol gives you these facilities:
- Ability to exchange messages and deliver AVPs
- Capabilities negotiation
- Error notification
- Extensibility, required in [RFC2989], through addition of new applications, commands, and AVPs
- Basic services necessary for applications, such as the handling of user sessions or accounting
All data delivered by the protocol is in the form of AVPs 📦. Some AVP values are used by the Diameter protocol itself, and others deliver data tied to particular applications that use Diameter. AVPs can be arbitrarily added to Diameter messages, the only restriction being that the Command Code Format (CCF) specification (Section 3.2) be satisfied. The base Diameter protocol uses AVPs to support these required features:
- Transporting of user authentication information, so the Diameter server can authenticate the user
- Transporting of service-specific authorization information between client and servers, letting the peers decide whether a user's access request should be granted
- Exchanging resource usage information, which may be used for accounting purposes, capacity planning, etc.
- Routing, relaying, proxying, and redirecting of Diameter messages through a server hierarchy
The Diameter base protocol meets the minimum requirements for an AAA protocol, as specified by [RFC2989] 🙌. The base protocol may be used by itself for accounting purposes only, or it may be used with a Diameter application, such as Mobile IPv4 [RFC4004] or network access [RFC4005]. The base protocol can also be extended for new applications by adding new commands or AVPs. Diameter's initial focus was network access and accounting applications. A truly generic AAA protocol used by lots of applications might offer functionality that Diameter doesn't, so it's imperative that designers of new applications understand their requirements before using Diameter 🧐. See Section 1.3.4 for more on Diameter applications.
Any node can initiate a request, so in that sense Diameter is a peer-to-peer protocol 🤝. In this document, a Diameter client is a device at the edge of the network that performs access control, like a Network Access Server (NAS) or a Foreign Agent (FA). A Diameter client generates Diameter messages to request authentication, authorization, and accounting services for the user. A Diameter agent is a node that doesn't provide local user authentication or authorization services, and agents include proxies, redirects, and relay agents. A Diameter server performs authentication and/or authorization of the user 🛡️. A Diameter node may act as an agent for certain requests while acting as a server for others, which is very main character energy 👑.
The Diameter protocol also supports server-initiated messages, like a request to abort service to a particular user ✋.
1.1.1. Description of the Document Set 📚
The Diameter specification is made up of an updated version of the base protocol specification (this document) and the Transport Profile [RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. You can find a summary of the base protocol updates included in this document in Section 1.1.3 🦋.
This document defines the base protocol specification for AAA, which includes support for accounting. There's also a myriad of application documents describing applications that use this base specification for Authentication, Authorization, and Accounting. These application documents specify how to use the Diameter protocol within the context of their application 💖.
The Transport Profile document [RFC3539] covers transport layer issues that come up with AAA protocols, plus recommendations on how to get past them. This document also defines the Diameter failover algorithm and state machine 🔁.
"Clarifications on the Routing of Diameter Request Based on the Username and the Realm" [RFC5729] defines specific behavior for routing requests based on the content of the User-Name AVP (Attribute Value Pair) 🗺️.
1.1.2. Conventions Used in This Document 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
okay bestie, part 4 is here and it's all about what changed from RFC 3588 🦋✨
1.1.3. Changes from RFC 3588
This document obsoletes RFC 3588 but is fully backward compatible with that document 💖 so anyone already running the old version can still talk to this one, no drama. The changes here are mostly about fixing the stuff that got messy once people actually started implementing Diameter (RFC 3588) 🛠️ and an overview of some of the major ones is below. 🌸
- Deprecated the use of the Inband-Security AVP for negotiating Transport Layer Security (TLS) [RFC5246]. 🔐 The vibe is that bootstrapping TLS through the Inband-Security AVP creates certain security risks, because it doesn't fully protect the information carried in the CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer) 😭 This version adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP and DTLS/SCTP 🎀 This new approach augments the existing in-band security negotiation, but it does not completely replace it. The old method is kept for backward compatibility reasons, so it's still there, just not the main character anymore. 👑
- Deprecated the exchange of CER/CEA messages in the open state. 🙈 This was implied in the peer state machine table of RFC 3588, but it wasn't clearly defined anywhere else in that document, which was lowkey confusing. As work on this document progressed, it became clear that the multiplicity of meaning and use of Application-Id AVPs in the CER/CEA messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules, so it needed simplifying 💅 Capabilities exchange in the open state has been re-introduced in a separate specification [RFC6737], which clearly defines new commands for this feature. 🧚
- Simplified security requirements. The use of a secured transport for exchanging Diameter messages remains mandatory. 🫶 However, TLS/TCP and DTLS/SCTP have become the primary methods of securing Diameter, with IPsec as a secondary alternative. See Section 13 for details 🔥 The support for the End-to-End security framework (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been deprecated, so that one's officially retired 💀
- Changed Diameter extensibility. 🌈 This includes fixes to the Diameter extensibility description (Section 1.3 and others) to better aid Diameter application designers ✨ In addition, the new specification relaxes the policy with respect to the allocation of Command Codes for vendor-specific uses. 🍓
- Clarified Application Id usage. 💜 This clarifies the proper use of Application Id information, which can show up in multiple places within a Diameter message, and includes correlating Application Ids found in the message headers and AVPs. These changes also clearly specify the proper Application Id value to use for specific base protocol messages (ASR/ASA, STR/STA), as well as clarify the content and use of Vendor-Specific-Application-Id. 👑
- Clarified routing fixes. 🦋 This document more clearly specifies what information (AVPs and Application Ids) can be used for making general routing decisions. A rule for prioritizing redirect routing criteria when multiple route entries are found via redirects has also been added (see Section 6.13) 🧚♀️
- Simplified Diameter peer discovery. 🌸 The Diameter discovery process now supports only widely used discovery schemes, and the rest have been deprecated (see Section 5.2 for details). 🎀
There are many other miscellaneous fixes in this document that may not seem significant, but they have value nonetheless 💖 Examples include removal of obsolete types, fixes to the state machine, clarification of the election process, message validation, and fixes to Failed-AVP and Result-Code AVP values, etc. 🛠️ All of the errata filed against RFC 3588 prior to the publication of this document have been addressed ✅ A comprehensive list of changes is not shown here for practical reasons. 🫶
1.2. Terminology ✨
okay bestie, let's get into the vocab, because RFC 6733 has a whole glossary of terms and you need them locked in 💅
AAA 🔐
Authentication, Authorization, and Accounting.
ABNF 📜
Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own formal syntax and rules. It is based on the Backus-Naur Form and is used to define message exchanges in a bi-directional communications protocol. it's giving grammar-for-grammars energy 🤓
Accounting 🧾
The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing, or cost allocation. 💸
Accounting Record 📒
An accounting record represents a summary of the resource consumption of a user over the entire session. Accounting servers creating the accounting record may do so by processing interim accounting events or accounting events from several devices serving the same user. so the record is the big-picture recap, and it can be built from lots of little pieces 🧩
Authentication 🪪
The act of verifying the identity of an entity (subject). checking who you are, basically 🫶
Authorization 🗝️
The act of determining whether a requesting entity (subject) will be allowed access to a resource (object). the bouncer deciding if you get past the velvet rope 💜
Attribute-Value Pair (AVP) 🎀
The Diameter protocol consists of a header followed by one or more Attribute-Value-Pairs (AVPs). An AVP includes a header and is used to encapsulate protocol-specific data (e.g., routing information) as well as authentication, authorization, or accounting information. AVPs are the little boxes that carry all the good stuff, and they're literally everywhere ✨
Command Code Format (CCF) 🧱
A modified form of ABNF used to define Diameter commands (see Section 3.2). this is the blueprint format for commands, and it's giving structured and iconic 👑
Diameter Agent 🧚
A Diameter Agent is a Diameter node that provides relay, proxy, redirect, or translation services. the middle-person squad 🦋
Diameter Client 💻
A Diameter client is a Diameter node that supports Diameter client applications as well as the base protocol. Diameter clients are often implemented in devices situated at the edge of a network and provide access control services for that network. Typical examples of Diameter clients include the Network Access Server (NAS) and the Mobile IP Foreign Agent (FA). the edge devices doing the access control work, like the NAS and the FA 🌸
Diameter Node 🌐
A Diameter node is a host process that implements the Diameter protocol and acts as either a client, an agent, or a server. any host process running Diameter can play one of these three roles 🍓
Diameter Peer 🤝
Two Diameter nodes sharing a direct TCP or SCTP transport connection are called Diameter peers. direct connection = peer status, no cap 🔥
Diameter Server 🏰
A Diameter server is a Diameter node that handles authentication, authorization, and accounting requests for a particular realm. By its very nature, a Diameter server must support Diameter server applications in addition to the base protocol. the server is the one handling AAA for its realm, so it has to support server applications on top of the base protocol 💖
Downstream ⬇️
Downstream is used to identify the direction of a particular Diameter message from the home server towards the Diameter client. home server to client, going down the chain 🌈
Home Realm 🏡
A Home Realm is the administrative domain with which the user maintains an account relationship. home base for the user's account 🧸
Home Server 🛡️
A Diameter server that serves the Home Realm. the server that looks after the home realm 🫶
Interim Accounting ⏱️
An interim accounting message provides a snapshot of usage during a user's session. Typically, it is implemented in order to provide for partial accounting of a user's session in case a device reboot or other network problem prevents the delivery of a session summary message or session record. it's a mid-session progress update, so if the device crashes you still have partial receipts 🙈
Local Realm 📍
A local realm is 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. same domain, different hats depending on who you're talking about 🎭
Multi-session 🔗
A multi-session represents a logical linking of several sessions. Multi-sessions are tracked by using the Acct-Multi-Session-Id. An example of a multi-session would be a Multi-link PPP bundle. Each leg of the bundle would be a session while the entire bundle would be a multi-session. think of a Multi-link PPP bundle: each leg is a session, and the whole bundle is the multi-session 🧵
Network Access Identifier 🪧
The Network Access Identifier, or NAI [RFC4282], is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization while the realm is used for message routing purposes. the NAI is how Diameter pulls out the username and the realm 💅
Proxy Agent or Proxy 🪞
In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. Typically, this is accomplished by tracking the state of NAS devices. While proxies usually do not respond to client requests prior to receiving a response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and they may not support all Diameter applications. proxies forward AND make policy calls, so they need to really understand the messages going through them 🧠
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. the realm is the bit after the @, and it's basically the routing address 📬
Real-Time Accounting ⏰
Real-time accounting involves the processing of information on resource usage within a defined time window. Typically, time constraints are imposed in order to limit financial risk. The Diameter Credit-Control Application [RFC4006] is an example of an application that defines real-time accounting functionality. accounting on a clock, because money is at stake 💸
Relay Agent or Relay 🏃♀️
Relays forward requests and responses based on routing-related AVPs and routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type. Since relays make decisions based on information in routing AVPs and realm forwarding tables, they do not keep state on NAS resource usage or sessions in progress. the relay is the quiet forwarder: no policy, no originating messages, no peeking at non-routing AVPs 🦋
Redirect Agent 🚦
Rather than forwarding requests and responses between clients and servers, redirect agents refer clients to servers and allow them to communicate directly. Since redirect agents do not sit in the forwarding path, they do not alter any AVPs transiting between client and server. Redirect agents do not originate messages and are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types. As with relay agents, redirect agents do not keep state with respect to sessions or NAS resources. instead of passing messages along, the redirect agent just points the client to the right server and steps out of the way 🫧
Session 🎬
A session is a related progression of events devoted to a particular activity. Diameter application documents provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Id are considered to be part of the same session. same Session-Id means same session, period 💜
Stateful Agent 🗃️
A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise or until expiration. the stateful agent keeps a running list of who's allowed in right now 📋
Sub-session 🍰
A sub-session represents a distinct service (e.g., QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g., simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id. like different services layered inside one session, e.g. voice and data at the same time 🎂
Transaction State 🔁
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, the Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state. the agent has to remember the Hop-by-Hop Identifier so it can restore it later, and that's the whole "transaction" 🙌
Translation Agent 🌉
A translation agent (TLA in Figure 4) is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS. the translator bridging Diameter and other AAA protocols like RADIUS 🌸
Upstream ⬆️
Upstream is used to identify the direction of a particular Diameter message from the Diameter client towards the home server. client up to the home server, the opposite of downstream 🌤️
User 🙋
The entity or device requesting or using some resource, in support of which a Diameter client has generated a request. whoever (or whatever device) is asking to use the resource 🎀
1.3. Approach to Extensibility 🧩
Diameter is built to be extensible, and it's giving "add more features without breaking everything" energy 🌈 The main mechanisms are:
- Defining new AVP values
- Creating new AVPs
- Creating new commands
- Creating new applications
From the point of view of extensibility, Diameter authentication, authorization, and accounting applications are treated in the same way. so no app type gets the VIP treatment 👑
Note: Protocol designers should try to reuse existing functionality, namely AVP values, AVPs, commands, and Diameter applications. Reuse simplifies standardization and implementation. To avoid potential interoperability issues, it is important to ensure that the semantics of the reused features are well understood. Given that Diameter can also carry RADIUS attributes as Diameter AVPs, such reuse considerations also apply to existing RADIUS attributes that may be useful in a Diameter application. bestie, reuse what already exists, and actually understand what it means before you do 🫶
1.3.1. Defining New AVP Values 🎨
In order to allocate a new AVP value for AVPs defined in the Diameter base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.3.
The allocation of AVP values for other AVPs is guided by the IANA considerations of the document that defines those AVPs. Typically, allocation of new values for an AVP defined in an RFC would require IETF Review [RFC5226], whereas values for vendor-specific AVPs can be allocated by the vendor. base-protocol AVP values need an approved RFC, but everyone else follows their own doc's IANA rules, and vendor-specific ones are the vendor's call 💖
1.3.2. Creating New AVPs 🎁
A new AVP being defined MUST use one of the data types listed in Sections 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of a base data type to encourage reusability and good design practice. so pick from the approved data types, and grab a derived one if it already exists 🍓
In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used (see Section 4.4). if you need a logical grouping of AVPs, a Grouped AVP is the move 🧺
The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a Standards Track RFC approved by the IETF. However, as described in Section 11.1.1, there are other mechanisms. the go-to move is a general-purpose AVP in a Standards Track RFC, but there are other routes too 🦋
1.3.3. Creating New Commands 🚀
A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the CCF definition) are added to, deleted from, or redefined in (for example, by changing a required AVP into an optional one) an existing command. adding, removing, or changing a required AVP means a brand new Command Code, no exceptions 🙅♀️
Furthermore, if the transport characteristics of a command are changed (for example, with respect to the number of round trips required), a new Command Code MUST be registered. changing the round-trip behaviour also means a new Command Code gets registered ✨
A change to the CCF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter application for any application that will use that new command. so any CCF change creates a new Command Code, and then apps using it need a new Diameter application 🌟
The IANA considerations for Command Codes are discussed in Section 3.1. check Section 3.1 for the IANA details on Command Codes 📚
1.3.4. Creating New Diameter Applications 💖
okay so every Diameter application spec MUST have an IANA-assigned Application Id (see Section 2.4) 🎀. The managed Application ID space has no relationships in it. Different Diameter applications aren't connected to each other through their Application Ids, so the Ids give you zero versioning 🙅♀️. Every Diameter application is a standalone app. If one app is related to another, Diameter doesn't know about it at all 🤷♀️✨
before we get into how to make a new app, we need to talk about two things that get mixed up a lot: the CCF and the M-bit (Section 4.1) on an AVP 🧠. They have NOTHING to do with each other. You set them completely independently, so don't let one talk you into the other 💅
- The CCF tells you which AVPs the sender of a command puts into that command. Since there are lots of ways protocol exchanges can go, a bunch of AVPs get marked as optional 🌈
- The M-bit lets the sender say to the receiver, "hey, understanding this AVP and what's in it is mandatory." If the sender sets the M-bit and the receiver doesn't understand the AVP or the values inside it, a failure is generated (see Section 7) 😭
it's the protocol designer's call when to make a whole new Diameter application instead of extending Diameter some other way 🦋. But a new Diameter application MUST be created when one or more of these criteria are met:
M-bit Setting
An AVP with the M-bit in the MUST column of the AVP flag table gets added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table gets added to an existing Command/Application 🔥
The M-bit setting for an AVP only matters within one Application and each command in that application that includes the AVP. So if an AVP shows up in two commands for application Foo and the M-bit settings differ between those commands, then there should be two AVP flag tables describing when to set the M-bit 🙈
Commands
A new command gets used inside an existing application because either an extra command was added, an existing command got changed so it needed a brand-new Command Code registered, or a command was deleted 🍓
AVP Flag bits
If an existing application changes what its AVP Flags mean or adds new flag bits, then a new Diameter application MUST be created 💀
if the CCF definition of a command allows it, an implementation may add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to that command, and it doesn't need to define a new application for that 🫶. Check out Section 11.1.1 for the details 🌸
2. Protocol Overview 🌸
the base Diameter protocol is the foundation 🧚. It handles setting up connections to peers, negotiating capabilities, how messages get sent and routed through peers, and how connections eventually get torn down 👑. It also defines some rules that apply to every message exchange between Diameter nodes 💜
it all starts when one peer sends a message to another Diameter peer 🦋. Which AVPs go in that message depends on the particular Diameter application. One AVP that shows up to reference a user's session is the Session-Id 🎀
the initial request to authenticate and/or authorize a user includes the Session-Id AVP ✨. After that, every subsequent message uses the Session-Id to identify that user's session (see Section 8 for more information). The party on the other end can either accept the request or reject it by sending back an answer message with the Result-Code AVP set to show that an error happened 😬. How a Diameter server or client handles a request depends on which Diameter application is in use 💅
session state (tied to a Session-Id) MUST be freed when any of these happen: a Session-Termination-Request gets received, a Session-Termination-Answer gets received, the authorized service time in the Session-Timeout AVP expires, or the rules of a particular Diameter application say so 💀
the base protocol can be used all by itself for accounting apps 🌈. For authentication and authorization, though, it's always extended for a particular application 🔥
Diameter clients MUST support the base protocol, which includes accounting 💖. On top of that, they MUST fully support each Diameter application needed to build the client's service, like Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile IPv4 ✨. A Diameter client MUST be called "Diameter X Client", where X is the application it supports. It is NOT allowed to be called a plain "Diameter Client" 🙅♀️
Diameter servers MUST support the base protocol, which includes accounting 🍓. They also MUST fully support each Diameter application needed for the intended service, like NASREQ and/or Mobile IPv4 🫶. A Diameter server MUST be called "Diameter X Server", where X is the application it supports, and not a plain "Diameter Server" 👑
Diameter relays and redirect agents are transparent to the Diameter applications 🦋, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications 🔥
Diameter proxies MUST support the base protocol, which includes accounting 🌸. On top of that, they MUST fully support each Diameter application needed for the proxied services, like NASREQ and/or Mobile IPv4 🧚. A Diameter proxy MUST be called "Diameter X Proxy", where X is the application it supports, and not a plain "Diameter Proxy" 💅
2.1. Transport 🦋
the Diameter Transport profile is defined in [RFC3539] ✨.
the base Diameter protocol runs on port 3868 for both TCP [RFC0793] and SCTP [RFC4960] 🎀. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that starts a connection before any message exchanges MUST run on port 5658 🫶. TLS is assumed to run on top of TCP when it's used, and DTLS runs on top of SCTP when it's used 🌈
if the Diameter peer doesn't support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (meaning the peer only complies with RFC 3588) 🙈, then the initiator MAY fall back to using TCP or SCTP on port 3868. Heads up though: this scheme is only kept for backward compatibility, and there are inherent security vulnerabilities when the initial CER/CEA messages go unprotected (see Section 5.6) 😭
Diameter clients MUST support either TCP or SCTP. Agents and servers SHOULD support both 💜
a Diameter node MAY start connections from a source port other than the one it says it accepts incoming connections on. It MUST always be ready to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections 🧚. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records beat the default ports (3868 and 5658) 👑
a given Diameter instance of the peer state machine MUST NOT use more than one transport connection to talk to a given peer 🙅♀️. The one exception is when multiple instances exist on the peer, in which case a separate connection per process is allowed 🍓
when there's no transport connection with a peer, an attempt to connect SHOULD be made periodically 🦋. This is handled by the Tc timer (see Section 12 for details), whose recommended value is 30 seconds ⏰. There are some exceptions to this, like when a peer has ended the transport connection saying it doesn't want to communicate 🫶
when connecting to a peer and either zero or more transports are specified, TLS SHOULD be tried first, then DTLS, then TCP, and finally SCTP ✨. See Section 5.2 for more on peer discovery 🌸
Diameter implementations SHOULD be able to read ICMP protocol port unreachable messages as explicit signs that the server isn't reachable, subject to security policy on trusting those messages 🔥. More guidance on handling ICMP errors is in [RFC5927] and [RFC5461] 💅. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts 🙈
if Diameter gets data from the lower layer that can't be parsed or identified as a Diameter error made by the peer, the stream is compromised and can't be recovered 😭. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message, since graceful closure is compromised 💀
2.1.1. SCTP Guidelines ✨
Okay bestie, let's talk SCTP streams 🦋 Diameter messages SHOULD be mapped onto them in a way that dodges head-of-the-line (HOL) blocking, aka when one slow message holds up everyone stuck behind it 😭 Among the ways to do that, it is RECOMMENDED that a Diameter node send every Diameter message (request or response) over stream zero with the unordered flag set. Other designs are allowed too, though: Diameter nodes MAY select and implement other approaches to avoid HOL blocking, like using multiple streams with the unordered flag cleared (as originally instructed in RFC 3588) 💅 On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream, and it's free to send responses back over a different stream 🌈 This way, both sides manage their own sending streams independently of whichever streams the other side picked for a given message. The messages can arrive out of order and belong to different Diameter sessions, so keep up 🧚
Out-of-order delivery is extra spicy during connection establishment and termination 💀
Here's the tea. When a connection is established, the responder side sends a CEA message and moves to R-Open state, as specified in Section 5.6. If an application message gets sent shortly after that CEA and is delivered out of order, the initiator side is still in Wait-I-CEA state, so it will discard the application message and close the connection 😱 To avoid this race condition, the receiver side SHOULD NOT use out-of-order delivery methods until the first message has been received from the initiator, which proves that the initiator has moved to I-Open state. To trigger that message, the receiver side could send a DWR right after sending a CEA. Once the matching DWA comes back, the receiver side should start using out-of-order delivery methods to counter the HOL blocking 🙌
Another race condition can pop up with DPR and DPA messages. Both are small, so they can reach the peer faster than application messages when an out-of-order delivery mechanism is in use 🏃♀️ That means a DPR/DPA exchange can finish while application messages are still in transit, and those messages get lost 😩 An implementation could mitigate this race condition, for example by using timers, and wait a short period for pending application-level messages to arrive before it disconnects the transport connection. Eventually, lost messages are handled by the retransmission mechanism described in Section 5.5.4 🔁
A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks, instead of only using the unspecified payload protocol identifier (value 0). Two PPID values are allocated for this: PPID 46 is for Diameter messages in clear text SCTP DATA chunks, and PPID 47 is for Diameter messages in protected DTLS/SCTP DATA chunks 🎀
2.2. Securing Diameter Messages 🔐
Connections between Diameter peers SHOULD be protected by TLS/TCP and DTLS/SCTP. All Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP. If you want, you can deploy alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], to secure connections between peers. The Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec 🛡️
Security is not optional, bestie 🔒
2.3. Diameter Application Compliance 📋
Application Ids get advertised during the capabilities exchange phase (see Section 5.3) 🤝 Advertising support for an application means the sender supports the functionality laid out in that Diameter application specification ✨
Implementations MAY add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to a command defined in an application, but only if the command's CCF syntax specification allows it. Please refer to Section 11.1.1 for details 💖
2.4. Application Identifiers 🆔
Each Diameter application MUST have an IANA-assigned Application ID. The base protocol doesn't need an Application Id because its support is mandatory 🙌 During the capabilities exchange, Diameter nodes let their peers know which applications they support locally. On top of that, every Diameter message carries an Application Id, which is used in the message forwarding process 📬
The following Application Id values are defined:
Diameter common message 0
Diameter base accounting 3
Relay 0xffffffffRelay and redirect agents MUST advertise the Relay Application ID, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message that advertises relay service MUST assume that the sender supports all current and future applications 🌸
Diameter relay and proxy agents are responsible for finding an upstream server that supports the application of a particular message. If none can be found, an error message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER 😭
2.5. Connections vs. Sessions 🔗
Let's untangle "connection" vs. "session," because these two words show up EVERYWHERE in this doc 🧶
A connection is a transport-level connection between two peers that's used to send and receive Diameter messages. A session is a logical concept at the application layer that exists between the Diameter client and the Diameter server, and it's identified via the Session-Id AVP 🦋
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<----------------------------->
User session x
Figure 1: Diameter Connections and SessionsIn the example in Figure 1, peer connection A is established between the client and the relay, and peer connection B is established between the relay and the server. User session X spans from the client, via the relay, to the server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once the server accepts it, both the client and the server are aware of the session 🎀
It's super important to know that there's no relationship between a connection and a session, and Diameter messages for multiple sessions all get multiplexed through a single connection 🌈 Also, Diameter messages that pertain to the session, both application-specific ones and the ones defined in this document such as ASR/ASA, RAR/RAA, and STR/STA, MUST carry the Application Id of the application. Diameter messages about peer connection establishment and maintenance, like CER/CEA, DWR/DWA, and DPR/DPA, MUST carry an Application Id of zero (0) 💅
2.6. Peer Table 🗂️
The Diameter peer table is used in message forwarding and is referenced by the routing table. A peer table entry contains the following fields:
Host Identity: Following the conventions described for the DiameterIdentity-derived AVP data format in Section 4.3.1, this field holds the contents of theOrigin-Host(Section 6.3) AVP found in the CER or CEA message 🆔StatusT: This is the state of the peer entry, and it MUST match one of the values listed in Section 5.6 🚦
Yep, the field really is called StatusT 🙈 Copy it exactly, bestie.
Static or Dynamic: Specifies whether a peer entry was statically configured or dynamically discovered 📍Expiration Time: Specifies the time at which dynamically discovered peer table entries are to be either refreshed or expired. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry times in the relevant certificates ⏰TLS/TCP and DTLS/SCTP Enabled: Specifies whether TLS/TCP and DTLS/SCTP is to be used when communicating with the peer 🔐- Additional security information, when needed (e.g., keys, certificates) 🗝️
2.7. Routing Table ✨
Okay bestie, so every Realm-Based routing lookup happens against the routing table (see Section 12) 🗺️ Each routing table entry has these fields:
Realm Name
This is the field that MUST be used as a primary key in the routing table lookups 🔑 Some implementations do their lookups on longest-match-from-the-right for the realm instead of needing an exact match, which is a whole vibe 💅
Application Identifier
An application is identified by an Application Id 🦋 A route entry can point somewhere different depending on the Application Id in the message header. This field MUST be used as a secondary key field in routing table lookups 🫶
Local Action
The Local Action field tells you how a message should be treated 🎀 These actions are supported:
- LOCAL - Diameter messages that can be satisfied locally and do not need to be routed to another Diameter entity 🏠
- RELAY - All Diameter messages in this category MUST be routed to a next-hop Diameter entity indicated by the identifier described below. Routing is done without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines 🌸
- PROXY - All Diameter messages in this category MUST be routed to a next Diameter entity indicated by the identifier described below. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines 🧚
- REDIRECT - Diameter messages in this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See Section 6.1.8 for redirection guidelines 🍓
Server Identifier
This is the identity of one or more servers the message is going to be routed to 💜 This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message MUST be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message MUST be redirected to 👑
Static or Dynamic
Specifies whether a route entry was statically configured or dynamically discovered 🌈
Expiration Time
Specifies the time at which a dynamically discovered route table entry expires ⏰ If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry time in the relevant certificates 🔐
It is so important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY, or REDIRECT modes of operation 💖 Agents do not need to support all modes to conform with the protocol specification, but they MUST follow the protocol compliance guidelines in Section 2 📋 Relay agents and proxies MUST NOT reorder AVPs 🙅♀️
The routing table MAY include a default entry that MUST be used for any requests not matching any of the other entries 🛟 The routing table MAY consist of only such an entry ✨
When a request is routed, the target server MUST have advertised the Application Id (see Section 2.4) for the given message, or have advertised itself as a relay or proxy agent. Otherwise, an error is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER 😭
2.8. Role of Diameter Agents ✨
Okay so in addition to clients and servers, Diameter introduces relay, proxy, redirect, and translation agents, each defined in Section 1.2 🦋 Diameter agents are useful for several reasons:
- They can distribute administration of systems to a configurable grouping, including the maintenance of security associations 🔐
- They can be used for concentration of requests from a number of co-located or distributed NAS equipment sets to a set of like user groups 🌸
- They can do value-added processing to the requests or responses 💅
- They can be used for load balancing ⚖️
- A complex network will have multiple authentication sources, and they can sort requests and forward them towards the correct target 🧭
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes 🛟 Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved. The field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state 🫧
The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be present in the answer 🎀 However, the protocol's failover procedures require that agents maintain a copy of pending requests 😤
A stateful agent is one that maintains session state information by keeping track of all authorized active sessions 🗂️ Each authorized session is bound to a particular service, and its state is considered active until either the agent is notified otherwise or the session expires. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP ⏳
Maintaining session state may be useful in certain applications, such as:
- Protocol translation (e.g., RADIUS <-> Diameter) 🔁
- Limiting resources authorized to a particular user 🚦
- Per-user or per-transaction auditing 🔍
A Diameter agent MAY act in a stateful manner for some requests and be stateless for others. A Diameter implementation MAY act as one type of agent for some requests and as another type of agent for others 🦋
2.8.1. Relay Agents 🌸
Relay agents are Diameter agents that accept requests and route messages to other Diameter nodes based on information found in the messages (e.g., the value of the Destination-Realm AVP Section 6.6) 💌 This routing decision is performed using a list of supported realms and known peers. This is known as the routing table, as defined further in Section 2.7 🗺️
Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (Point of Presence, POP) 🌍 The use of relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms 🙌 Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed, or deleted 🧹
Relays modify Diameter messages by inserting and removing routing information, but they do not modify any other portion of a message 🎀 Relays SHOULD NOT maintain session state but MUST maintain transaction state 🛟
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 2: Relaying of Diameter messagesThe example in Figure 2 shows a request issued from a NAS, which is an access device, for the user bob@example.com 🧑💻 Before issuing the request, the NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to a DRL, which is a Diameter relay 🔎 The DRL performs the same route lookup as the NAS, and relays the message to the HMS, which is example.com's home server 🏡 The HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to the NAS using saved transaction state 💫
Since relays do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application Id 📣
2.8.2. Proxy Agents 🧚
Similar to relays, proxy agents route Diameter messages using the Diameter routing table 🗺️ However, they differ since they modify messages to implement policy enforcement 🛡️ This requires that proxies maintain the state of their downstream peers (e.g., access devices) to enforce resource usage, provide admission control, and provide provisioning 📊
Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections 📞 They can monitor the number and type of ports in use and make allocation and admission decisions according to their configuration 🔢
Since enforcing policies requires an understanding of the service being provided, proxies MUST only advertise the Diameter applications they support 🎯
2.8.3. Redirect Agents 👉
Redirect agents are useful in scenarios where the Diameter routing configuration needs to be centralized 🧭 An example is a redirect agent that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between realms 🙅♀️ This scenario is advantageous since it does not require the consortium to provide routing updates to its members when changes are made to a member's infrastructure 🥳
Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages 💅 Since redirect agents do not receive answer messages, they cannot maintain session state 🙈
The example in Figure 3 shows a request issued from the access device, NAS, for the user bob@example.com 📨 The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter routing table for example.com 🤔 The DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as the HMS' contact information 📇 Upon receipt of the redirect notification, the DRL establishes a transport connection with the HMS, if one doesn't already exist, and forwards the request to it 🚀
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 3: Redirecting a Diameter MessageSince redirect agents do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application ID 📢
2.8.4. Translation Agents 🔄✨
okay so a translation agent is a device that translates between two protocols, like RADIUS<->Diameter or TACACS+<->Diameter 💅. These are lowkey perfect as aggregation servers that talk to the Diameter infrastructure, while your embedded systems get migrated at a slower pace 🐢💖.
Diameter brings in the concept of long-lived authorized sessions, so translation agents MUST be session stateful and MUST maintain transaction state 🧠. That's a big ask, bestie, but it's what keeps the whole thing consistent 🫶.
Translation of messages can only happen if the agent recognizes the application of a particular request, so translation agents MUST only advertise their locally supported applications 🎀.
+------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.comFigure 4: Translation of RADIUS to Diameter 🦋
2.9. Diameter Path Authorization 🛣️
okay so, as we talked about in Section 2.2, Diameter gives you transmission-level security on every connection using TLS/TCP and DTLS/SCTP 🔐. That means each connection can be authenticated and can be protected against replay and tampering 🧊.
But authenticating each connection isn't the whole story 😤. The entire session MUST also be authorized. Before a Diameter peer opens a connection, it MUST check that its peers are authorized to act in their roles 👑. Being authentic doesn't automatically mean you're allowed to be a Diameter server advertising a set of Diameter applications, so no cap, that's a totally separate check 💀.
Before bringing up a connection, authorization checks happen at each connection along the path 🚦. Diameter capabilities negotiation (CER/CEA) also MUST be carried out, so everyone knows which Diameter applications each peer supports 📋. And Diameter sessions MUST be routed only through authorized nodes that have advertised support for the Diameter application the session needs 🌸.
As noted in Section 6.1.9, a relay or proxy agent MUST append a Route-Record AVP to all requests it forwards 🧚. That AVP holds the identity of the peer the request was received from, so the trail is literally right there 🍓.
The home Diameter server has to check the Route-Record AVPs before it authorizes a session, and it MUST make sure the route the request traveled is acceptable 🕵️♀️. For example, admins inside the home realm might not want to honor requests that went through an untrusted realm, and that's totally valid ✨. By authorizing a request, the home server is implicitly saying it's willing to take part in the business deal set out by any contract between itself and the previous hop 🤝. If the route is unacceptable, a DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) gets sent 🚫.
A home realm may also want to check that each accounting request lines up with a Diameter response that authorized the session 📚. Accounting requests without a matching authorization response SHOULD be subjected to further scrutiny, and so SHOULD accounting requests that show a difference between the requested and provided service 🔍.
Forwarding an authorization response is basically evidence of a willingness to take on financial risk for the session 💸. A local realm might want to limit that exposure, like by setting credit limits for intermediate realms and refusing responses that would break those limits 🙅♀️.
By issuing an accounting request that matches the authorization response, the local realm implicitly agrees to provide the service named in that response 🤍. If the local realm can't actually provide the service, a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request 😬. And a Diameter client that gets an authorization response for a service it can't perform MUST NOT swap in an alternate service and then send accounting requests for that alternate instead 🙈. Not allowed, periodt 💅.
3. Diameter Header ✨
A summary of the Diameter header format is shown below 📐. The fields are transmitted in network byte order 🌈.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Flags | Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Version 🔢
The Version field MUST be set to 1 to indicate Diameter Version 1 🎯.
Message Length 📏
The Message Length field is three octets and tells you the length of the Diameter message, including the header fields and the padded AVPs 📦. Because of that, the Message Length field is always a multiple of 4 ✨.
Command Flags 🚩
The Command Flags field is eight bits, and these bits are assigned 💖:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+- R(equest): If set, the message is a request 📨. If cleared, the message is an answer 📬.
- P(roxiable): If set, the message MAY be proxied, relayed, or redirected 🧚. If cleared, the message MUST be locally processed 🏠.
- E(rror): If set, the message contains a protocol error, and it won't conform to the CCF described for this command 💀. Messages with the 'E' bit set are commonly called error messages 🚨. This bit MUST NOT be set in request messages (see Section 7.2) 🙅♀️.
- T(Potentially retransmitted message): This flag gets set after a link failover procedure, to help get rid of duplicate requests 🔁. It's set when resending requests that haven't been acknowledged yet, as a hint that there might be a duplicate because of 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 care about how many requests they send based on a single received request; retransmissions by other entities don't 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 only be set when no answer has come back from the server for a request and that request has been sent again 🔄. This flag MUST NOT be set in answer messages 🚫.
- r(eserved): These flag bits are reserved for future use; they MUST be set to zero and ignored by the receiver 🤫.
Command Code 🧾
The Command Code field is three octets and is used to communicate the command associated with the message 📣. The 24-bit address space is managed by IANA (see Section 3.1) 🏛️. Command Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE-FFFFFF) are reserved for experimental use (see Section 11.2) 🧪.
Application-ID 🆔
Application-ID is four octets and identifies which application the message applies to 🎟️. The application can be an authentication application, an accounting application, or a vendor-specific application 🌟.
The value of the Application-ID field in the header MUST be the same as any relevant Application-Id AVPs contained in the message 💯.
Hop-by-Hop Identifier 🔑
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) that helps match requests with replies 🎯. The sender of a request MUST ensure that the Hop-by-Hop Identifier is unique on a given connection at any given time, and it MAY try to make sure the number is unique across reboots 🔄. The sender of an answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was in the corresponding request 🪞. The Hop-by-Hop Identifier is normally a monotonically increasing number, and its start value was randomly generated 🎲. An answer message received with an unknown Hop-by-Hop Identifier MUST be discarded 🗑️.
End-to-End Identifier 🧭
The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) used to detect duplicate messages 👯. Upon reboot, implementations MAY set the high order 12 bits to contain the low order 12 bits of the 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 End-to-End Identifier field contains the same value that was in the corresponding request 💞. The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind 🙅♀️. The combination of the Origin-Host AVP (Section 6.3) and this field is used to detect duplicates 👀. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the Hop-by-Hop Identifier field and any routing AVPs that may be present), and they MUST NOT affect any state that was set when the original request was processed 🧼. Duplicate answer messages that are to be consumed locally (see Section 6.2) SHOULD be silently discarded 🤐.
AVPs 📦
AVPs are a way of encapsulating information relevant to the Diameter message 🎁. See Section 4 for more information on AVPs 📖.
3.1. Command Codes 🦋
Okay so every Request/Answer pair gets its own Command Code 🫶 The request and the answer share it, and the sub-type (request or answer) is shown by the 'R' bit in the Command Flags field of the Diameter header. It's giving organized 💅
Every Diameter message MUST contain a Command Code in its header's Command Code field, because that's what decides the action to take for a message ✨ These are the Command Codes defined in the Diameter base protocol:
Section
Command Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer3.2. Command Code Format Specification 🌸
Every Command Code defined MUST include a corresponding Command Code Format (CCF) specification 🧚 The CCF is what defines the AVPs that MUST or MAY be present when the message gets sent. Here's the ABNF that describes the CCF, and it's a whole vibe 🤓
command-def = "<" command-name ">" "::=" diameter-message
command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header *fixed *required *optional
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
application-id = 1*DIGIT
command-id = 1*DIGIT
; The Command Code assigned to the command.
r-bit = ", REQ"
; If present, the 'R' bit in the Command
; Flags is set, indicating that the message
; is a request as opposed to an answer.
p-bit = ", PXY"
; If present, the 'P' bit in the Command
; Flags is set, indicating that the message
; is proxiable.
e-bit = ", ERR"
; If present, the 'E' bit in the Command
; Flags is set, indicating that the answer
; message contains a Result-Code AVP in
; the "protocol error" class.
fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP.
required = [qual] "{" avp-spec "}"
; The AVP MUST be present and can appear
; anywhere in the message.
optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name that is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
;
; NOTE: "[" and "]" have a slightly different
; meaning than in ABNF. These braces
; cannot be used to express optional fixed rules
; (such as an optional ICV at the end). To do
; this, the convention is '0*1fixed'.
qual = [min] "*" [max]
; See ABNF conventions, RFC 5234, Section 4.
; The absence of any qualifier depends on
; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present. If an optional rule has a qualifier,
; then the value of min MUST be 0 if present.
min = 1*DIGIT
; The minimum number of times the element may
; be present. If absent, the default value is 0
; for fixed and optional rules and 1 for
; required rules. The value MUST be at least 1
; for required rules.
max = 1*DIGIT
; The maximum number of times the element may
; be present. If absent, the default value is
; infinity. A value of 0 implies the AVP MUST
; NOT be present.
avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary AVP
; Name, not otherwise listed in that Command Code
; definition. The inclusion of this string
; is recommended for all CCFs to allow for
; extensibility.Here's a fictitious Command Code so you can see how it looks in action 💖
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]3.3. Diameter Command Naming Conventions 🌈
Diameter command names usually have one or more English words followed by the verb "Request" or "Answer" ✨ Each English word is separated by a hyphen, and there's normally a three-letter acronym for both the request and the answer too.
For example, a message set used to end a session is named Session-Terminate-Request and Session-Terminate-Answer, and the acronyms are STR and STA, in that order 🦋
Both the request and the answer for a command share the same Command Code. The request is identified by the R(equest) bit in the Diameter header being set to one (1), to ask that a particular action be performed, like authorizing a user or terminating a session. Once the receiver finishes the request, it sends back the matching answer, which includes a result code that says one of the following:
- The request was successful
- The request failed
- An additional request has to be sent to provide information the peer requires prior to returning a successful or failed answer.
- The receiver could not process the request, but provides information about a Diameter peer that is able to satisfy the request, known as redirect.
Extra info, encoded within AVPs, may also be included in answer messages 💅
4. Diameter AVPs 💖
AVPs are where the good stuff lives 🔥 They carry the authentication, accounting, authorization, and routing information, plus configuration details, for both the request and the reply.
Each AVP of type OctetString MUST be padded to line up on a 32-bit boundary, while other AVP types just align naturally. You add zero-valued bytes to the end of the AVP Data field until you hit a word boundary, and the padding length is NOT counted in the AVP Length field 🙈
4.1. AVP Header 🎀
The fields in the AVP header MUST be sent in network byte order. Here's what the header looks like 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+AVP Code
The AVP Code, together with the Vendor-Id field, identifies the attribute uniquely 🌸 AVP numbers 1 through 255 are reserved for reusing RADIUS attributes, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, and they're allocated by IANA (see Section 11.1.1) ✨
AVP Flags
The AVP Flags field tells the receiver how each attribute has to be handled 🦋 New Diameter applications SHOULD NOT define additional AVP Flag bits. However, new Diameter applications MAY define additional bits within the AVP header, and an unrecognized bit SHOULD be considered an error. The sender of the AVP MUST set 'R' (reserved) bits to 0, and the receiver SHOULD ignore all 'R' (reserved) bits. The 'P' bit has been reserved for future use of end-to-end security. At the time of writing, there are no end-to-end security mechanisms specified, so the 'P' bit SHOULD be set to 0 🔥
The 'P' bit is reserved, and there are no end-to-end security mechanisms specified yet, so keep it at 0 🙈
The 'M' bit, known as the Mandatory bit, shows whether the receiver of the AVP MUST parse and understand the semantics of the AVP, including its content. The receiving entity MUST return an appropriate error message if it gets an AVP that has the M-bit set but doesn't understand it. There's an exception when the AVP is embedded within a Grouped AVP, so see Section 4.4 for details. Diameter relay and redirect agents MUST NOT reject messages with unrecognized AVPs 🫶
The 'M' bit MUST be set according to the rules defined in the application specification that introduces or reuses this AVP. Within a given application, the M-bit setting for an AVP is defined either for all command types or for each command type 💅
AVPs with the 'M' bit cleared are informational only. A receiver that gets a message with such an AVP that isn't supported, or whose value isn't supported, MAY simply ignore the AVP 🌈
The 'V' bit, known as the Vendor-Specific bit, shows whether the optional Vendor-ID field is present in the AVP header. When it's set, the AVP Code belongs to the specific vendor code address space 🧚
AVP Length
The AVP Length field is three octets, and it shows the number of octets in this AVP. That count includes the AVP Code field, AVP Length field, AVP Flags field, Vendor-ID field (if present), and the AVP Data field 🍓 If a message comes in with an invalid attribute length, the message MUST be rejected 💀
4.1.1. Optional Header Elements ✨
okay so the AVP header only has one optional field, and it only shows up when its bit-flag is switched on 🎀
Vendor-ID
The Vendor-ID field is there if the 'V' bit is set in the AVP Flags field 💅. It's four octets, holds an IANA-assigned "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value, and goes in network byte order 🧚. Any vendors (or standards orgs that get treated like vendors in that same IANA space) who wanna implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space 🔥. That way they can't collide with another vendor's vendor-specific AVPs or with future IETF AVPs. no cap, it's iconic 👑
A Vendor-ID of zero (0) means the IETF-adopted AVP values, as managed by IANA 🌸. Leaving the Vendor-ID field out already tells you the AVP isn't vendor specific, so implementations MUST NOT use the value of zero (0) for the Vendor-ID field 🙈.
4.2. Basic AVP Data Formats 💖
The Data field is zero or more octets holding info specific to the Attribute. Its format and length are determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types, or a data type derived from the base data types. If a brand new Basic AVP Data Format is ever needed, a new version of this RFC MUST be created 😭
OctetString 🫶
This is arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that aren't a multiple of 4 octets long get padding after them, so the next AVP (if any) starts on a 32-bit boundary 🍓
Integer32
A 32-bit signed value in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled) ✨
Integer64
A 64-bit signed value in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled) 🌈
Unsigned32
A 32-bit unsigned value in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled) 🦋
Unsigned64
A 64-bit unsigned value in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled) 💜
Float32
This is a single precision floating point value, as described by [FLOATPOINT]. The 32-bit value is sent in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled) ⭐
Float64
This is a double precision floating point value, as described by [FLOATPOINT]. The 64-bit value is sent in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled) 🎀
Grouped
The Data field is a sequence of AVPs. These AVPs get concatenated (headers and padding included) in the order they're specified, and the result gets wrapped up in the Data field 🧩. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all the included AVPs, headers and padding included. So the AVP Length field of a Grouped AVP is always a multiple of 4 💅
4.3. Derived AVP Data Formats 🦋
Applications can also use the Basic AVP Data Formats to define their own data formats, derived from the basic ones. An application that defines new Derived AVP Data Formats MUST include them in a section titled "Derived AVP Data Formats", using the same format as the definitions below. Each new definition MUST be either defined or listed with a reference to the RFC that defines the format 📝
4.3.1. Common Derived AVP Data Formats 💫
These are the commonly used ones, bestie 🫶
Address
This one's derived from OctetString. It's a discriminated union that can represent, for example, a 32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most significant octet first. The first two octets of the Address AVP are the AddressType, which holds an Address Family defined in [IANAADFAM]. The AddressType is what tells you how to read the content and format of the remaining octets 🌸
Time
This one's derived from OctetString too. The string MUST contain four octets, in the same format as the first four bytes of the NTP timestamp format. The NTP timestamp format is defined in Section 3 of [RFC5905] ⏰
It represents the number of seconds since 0h on 1 January 1900, with respect to Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow 😭 Simple Network Time Protocol (SNTP) [RFC5905] describes a procedure to extend the time to 2104. This procedure MUST be supported by all Diameter nodes 🙌
UTF8String
This one's derived from OctetString as well. It's a human-readable string that uses the ISO/IEC IS 10646-1 character set, encoded as an OctetString with the UTF-8 transformation format [RFC3629] 🌍
Since 10646 gets new code points added by amendments from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that aren't a valid UTF-8 encoding of a code point, or that fall outside that range, are prohibited 🚫
The use of control codes SHOULD be avoided. When you need to represent a new line, the control code sequence CR LF SHOULD be used 📜
The use of leading or trailing white space SHOULD be avoided 🤍
For code points that user interface hardware or software doesn't directly support, an alternative means of entry and display, such as hexadecimal, MAY be provided 🔢
For information encoded in 7-bit US-ASCII, the UTF-8 charset is identical to the US-ASCII charset ✨
UTF-8 may need multiple bytes to represent a single character / code point, so the length of a UTF8String in octets may be different from the number of characters encoded 🧠
Note that the AVP Length field of a UTF8String is measured in octets, not characters 📏
DiameterIdentity
This one's derived from the OctetString Basic AVP Format 🪪
DiameterIdentity = FQDN/RealmA DiameterIdentity value is used to uniquely identify either:
- A Diameter node, for purposes of duplicate connection and routing loop detection.
- A Realm, to figure out whether messages can be satisfied locally or whether they must be routed or redirected.
When a DiameterIdentity value identifies a Diameter node, the contents of the string MUST be the Fully Qualified Domain Name (FQDN) of that node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity 👯. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup and used as the only DiameterIdentity for that node, no matter which connection it's sent on 🎯. In this document, DiameterIdentity is in ASCII form so it stays compatible with existing DNS infrastructure 🌐. For how Diameter interacts with Internationalized Domain Names (IDNs), check out Appendix D 🧚
DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (RFC 3986) syntax [RFC3986] rules below 📍
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
FQDN = < Fully Qualified Domain Name >
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )Here are some examples of valid Diameter host identities 🎀
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radiusEnumerated
This one's derived from the Integer32 Basic AVP Format 🔢. The definition contains a list of valid values and what they mean, and it's described in the Diameter application that introduces the AVP 📚
IPFilterRule
This one's derived from the OctetString Basic AVP Format and uses the ASCII charset. The rule syntax is a modified subset of ipfw(8) from FreeBSD 🛡️. Packets can be filtered based on the following info that's associated with them:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP typesRules for the appropriate direction are evaluated in order, and the first matched rule terminates the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny 🚦
IPFilterRule filters MUST follow this format 💅
action dir proto from src to dst [options]action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule. ipno/bits An IP number as above with a mask
width of the form 192.0.2.10/24. In
this case, all IP numbers from
192.0.2.0 to 192.0.2.255 will match.
The bit width MUST be valid for the
IP version, and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often "deny
in ip! assigned".
The sense of the match can be inverted by
preceding an address with the not modifier (!),
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.
With the TCP, UDP, and SCTP protocols, optional
ports may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports
(including boundaries).
Fragmented packets that have a non-zero offset
(i.e., not the first fragment) will never match
a rule that has one or more port
specifications. See the frag option for
details on matching fragmented packets.
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma-separated
list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route), and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec
Match if the TCP header contains the comma-separated
list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp), and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a '!'.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma-separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack, and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17),
and address mask reply (18).Okay bestie, this one is a hard rule 🙅♀️: an access device MUST always discard an IP fragment with a fragment offset of one. It's a totally valid packet 📦, but its only real job is trying to sneak past firewalls 👀. Not on our watch 💅.
An access device that can't interpret or apply a deny rule MUST terminate the session 🚫. But if it can't handle a permit rule, it MAY apply a more restrictive rule instead 🫶. An access device MAY also add its own deny rules in front of the supplied ones, like to protect the access device owner's infrastructure 🏰.
4.4. Grouped AVP Values ✨
Diameter lets AVP values be of type 'Grouped' 🧺. That means the Data field is actually a whole sequence of AVPs, and you can nest Grouped AVPs inside other Grouped AVPs (it's giving Russian doll 🪆). AVPs inside a Grouped AVP follow the same padding requirements as non-Grouped AVPs, as defined in Section 4.4.
The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-Grouped AVPs. So if a Grouped AVP doesn't have the 'M' (mandatory) bit set, and one or more of the AVPs inside it does have the 'M' (mandatory) bit set, and you don't recognise the Grouped AVP itself, that Grouped AVP MAY simply be ignored 🙈. This still applies even when the AVP with its 'M' (mandatory) bit set is tucked further down inside other sub-groups, meaning other Grouped AVPs embedded within the Grouped AVP.
Every Grouped AVP definition MUST include a corresponding grammar, using ABNF [RFC5234] (with modifications), as defined below 📝.
grouped-avp-def = "<" name ">" "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.
avp = header *fixed *required *optional
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP.
vendor = 1*DIGIT
; The Vendor-ID assigned to the Grouped AVP.
; If absent, the default value of zero is
; used.4.4.1. Example AVP with a Grouped Data Type ✨
okay bestie, this is the Example-AVP (AVP Code 999999) 🎀 It's type Grouped, and it exists to show how Grouped AVP values actually work. Its Grouped Data field follows this CCF grammar:
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]Here's an Example-AVP with Grouped Data 💅
The Origin-Host AVP (Section 6.3) is required, so in this case we set:
Origin-Host = "example.com".At least one Session-Id has to show up. This one has two:
Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"
Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"The optional AVPs that get included are:
Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841The optional AVP data is shown in hex, and that's on purpose 🙈 Nobody knows what format these AVPs will have when the Example-AVP group is defined, and probably not when someone reads this example later either. The only ones who can read them are Diameter implementations that support that same set of AVPs. The encoding example also shows how padding works and how the length fields get calculated.
Also, heads up: a Grouped AVP value can contain AVPs the receiver can't interpret. In this example that's the Recover-Policy and Futuristic-Acct-Record AVPs, and it's totally fine 🦋 The length of the Example-AVP is the sum of the lengths of all its member AVPs (padding included) plus the size of the Example-AVP header.
This is how the AVP gets encoded:
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+
88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+
128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+
136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+
336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+4.5. Diameter Base Protocol AVPs 🌸
This table lists the Diameter AVPs defined in the base protocol, along with their AVP Code values, types, and possible flag values.
To save space, the short form DiamIdent stands in for DiameterIdentity 🧚
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Acct- 85 9.8.2 Unsigned32 | M | V |
Interim-Interval | | |
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Acct- 50 9.8.5 UTF8String | M | V |
Multi-Session-Id | | |
Accounting- 485 9.8.3 Unsigned32 | M | V |
Record-Number | | |
Accounting- 480 9.8.1 Enumerated | M | V |
Record-Type | | |
Acct- 44 9.8.4 OctetString| M | V |
Session-Id | | |
Accounting- 287 9.8.6 Unsigned64 | M | V |
Sub-Session-Id | | |
Acct- 259 6.9 Unsigned32 | M | V |
Application-Id | | |
Auth- 258 6.8 Unsigned32 | M | V |
Application-Id | | |
Auth-Request- 274 8.7 Enumerated | M | V |
Type | | |
Authorization- 291 8.9 Unsigned32 | M | V |
Lifetime | | |
Auth-Grace- 276 8.10 Unsigned32 | M | V |
Period | | |
Auth-Session- 277 8.11 Enumerated | M | V |
State | | |
Re-Auth-Request- 285 8.12 Enumerated | M | V |
Type | | |
Class 25 8.20 OctetString| M | V |
Destination-Host 293 6.5 DiamIdent | M | V |
Destination- 283 6.6 DiamIdent | M | V |
Realm | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | V |
Error-Message 281 7.3 UTF8String | | V,M |
Error-Reporting- 294 7.4 DiamIdent | | V,M |
Host | | |
Event-Timestamp 55 8.21 Time | M | V |
Experimental- 297 7.6 Grouped | M | V |
Result | | |
-----------------------------------------|----+-----| +----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Experimental- 298 7.7 Unsigned32 | M | V |
Result-Code | | |
Failed-AVP 279 7.5 Grouped | M | V |
Firmware- 267 5.3.4 Unsigned32 | | V,M |
Revision | | |
Host-IP-Address 257 5.3.5 Address | M | V |
Inband-Security | M | V |
-Id 299 6.10 Unsigned32 | | |
Multi-Round- 272 8.19 Unsigned32 | M | V |
Time-Out | | |
Origin-Host 264 6.3 DiamIdent | M | V |
Origin-Realm 296 6.4 DiamIdent | M | V |
Origin-State-Id 278 8.16 Unsigned32 | M | V |
Product-Name 269 5.3.7 UTF8String | | V,M |
Proxy-Host 280 6.7.3 DiamIdent | M | V |
Proxy-Info 284 6.7.2 Grouped | M | V |
Proxy-State 33 6.7.4 OctetString| M | V |
Redirect-Host 292 6.12 DiamURI | M | V |
Redirect-Host- 261 6.13 Enumerated | M | V |
Usage | | |
Redirect-Max- 262 6.14 Unsigned32 | M | V |
Cache-Time | | |
Result-Code 268 7.1 Unsigned32 | M | V |
Route-Record 282 6.7.1 DiamIdent | M | V |
Session-Id 263 8.8 UTF8String | M | V |
Session-Timeout 27 8.13 Unsigned32 | M | V |
Session-Binding 270 8.17 Unsigned32 | M | V |
Session-Server- 271 8.18 Enumerated | M | V |
Failover | | |
Supported- 265 5.3.6 Unsigned32 | M | V |
Vendor-Id | | |
Termination- 295 8.15 Enumerated | M | V |
Cause | | |
User-Name 1 8.14 UTF8String | M | V |
Vendor-Id 266 5.3.3 Unsigned32 | M | V |
Vendor-Specific- 260 6.11 Grouped | M | V |
Application-Id | | |
-----------------------------------------|----+-----|5. Diameter Peers 🦋
This section is all about how Diameter nodes set up connections and talk to their peers. Let's get into it 💖
5.1. Peer Connections ✨
okay so connections between diameter peers get set up using their valid DiameterIdentity 💖. A Diameter node starting a connection to a peer MUST know that peer's DiameterIdentity. If you're wondering how to find peers, Section 5.2 has you covered 🔍.
Even though a Diameter node might have tons of possible peers, keeping a live connection to every single one isn't really worth it 💅. At the bare minimum, a Diameter node SHOULD have an established connection with two peers per realm, the primary and the secondary 👑. Of course, a node MAY add more connections if it feels it needs them 🦋. Usually every message for a realm goes to the primary, but if failover kicks in, anything still pending gets sent to the secondary instead 🔄. Implementations are also free to load balance requests across a group of peers, so no pressure 🌸.
A given peer MAY act as a primary for one realm while being a secondary for another realm 🧚.
When a peer gets flagged as suspect (which can happen for a bunch of reasons, like not getting a DWA back in time ⏰), no new requests should be forwarded to it, and failover procedures get invoked 🚨. When an active peer goes into this mode, additional connections SHOULD be set up so there are still enough active connections 🙌.
There are two ways a peer gets removed from the suspect list 💀:
- The peer is unreachable, so the transport connection gets shut down, and the peer lands in the closed state 🚫.
- Three watchdog messages get exchanged with accepted round-trip times, and the connection is considered stabilized ✅.
If the peer being removed is the primary or the secondary, an alternate peer SHOULD step in, replace the deleted peer, and take on that role 🫶.
5.2. Diameter Peer Discovery 🗺️
Dynamic agent discovery makes deployments simpler and more robust 😤. So that implementations play nicely together, the mechanisms below (manual configuration and DNS) are described. They're built on existing IETF standards. Both mechanisms MUST be supported by every Diameter implementation, but either one MAY be used 💜.
There are two situations where peer discovery happens. First, a Diameter client needs to find a first-hop Diameter agent. Second, a Diameter agent needs to find another agent to help handle a Diameter operation 🧭. In both cases, the following 'search order' is recommended:
- First, the implementation checks its list of statically (manually) configured Diameter agent locations. Those get used if they exist and respond 📋.
- Next, it does a NAPTR query for a server in a particular realm. The implementation has to know ahead of time which realm to look in, which could be worked out from the 'realm' in an NAI it needs to act on 🔎.
The NAPTR usage follows the S-NAPTR DDDS application [RFC3958], where the SERVICE field carries tags for the desired application and the supported application protocol. The application service tag for a Diameter application is 'aaa', and the protocol tags are 'diameter.tcp', 'diameter.sctp', 'diameter.dtls', or 'diameter.tls.tcp' [RFC6408] 🎀.
The client can follow the resolution process defined by the S-NAPTR DDDS [RFC3958] application to find a matching SRV, A, or AAAA record for a suitable peer. The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. There's an example in Appendix B 📝.
- If no NAPTR records are found, the requester directly queries one of these SRV records:
_diameter._tcp.realmfor Diameter over TCP,_diameters._tcp.realmfor Diameter over TLS,_diameter._sctp.realmfor Diameter over SCTP, or_diameters._sctp.realmfor Diameter over DTLS 🔤. If SRV records are found, the requester can do an address record query (A and/or AAAA) for the target hostname in them, following the rules in [RFC2782]. If no SRV records are found, the requester gives up 😭.
If the server is using a site certificate, the domain name in the NAPTR query and the domain name in the replacement field MUST both be valid based on the site certificate the server hands out during the TLS/TCP and DTLS/SCTP or Internet Key Exchange Protocol (IKE) exchange 🔐. Same deal for SRV: the domain name in the SRV query and the domain name in the target of the SRV record MUST both be valid based on that same site certificate. Otherwise, an attacker could tamper with the DNS records to point at replacement values in a different domain, and the client couldn't tell whether that was the intended behaviour or the result of an attack 🚨💀.
The Diameter peer MUST also check that discovered peers are authorized to act in its role 🛑. Authentication via IKE or TLS/TCP and DTLS/SCTP, or validating DNS RRs with DNSSEC, isn't enough to conclude this. For example, a web server might have a valid TLS/TCP and DTLS/SCTP certificate, and its DNS records might be secured, but that doesn't mean it's allowed to act as a Diameter server 🙃.
Authorization can be achieved by, for example, configuring a Diameter server Certification Authority (CA). The server CA issues a certificate to the Diameter server, which includes an Object Identifier (OID) to show the subject is a Diameter server in the Extended Key Usage extension [RFC5280]. That certificate is then used during TLS/TCP, DTLS/SCTP, or IKE security negotiation. Heads up though: at the time of writing, no Diameter server Certification Authorities exist 😬.
A dynamically discovered peer creates an entry in the peer table (see Section 2.6). Entries created via DNS MUST expire (or be refreshed) within the DNS Time to Live (TTL) ⏳. If a peer is discovered outside the local realm, a routing table entry (see Section 2.7) for the peer's realm gets created. The routing table entry's expiration MUST match the peer's expiration value 💖.
5.3. Capabilities Exchange 🤝
When two Diameter peers establish a transport connection, they MUST exchange Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6) 💬. This is how a peer's identity and capabilities get discovered: protocol version number, the identifiers of supported Diameter applications, security mechanisms, and so on 🪪.
The receiver only issues commands to peers that have advertised support for the Diameter application that defines the command 🎯. A Diameter node MUST cache the supported Application Ids, so that unrecognized commands and/or AVPs don't get sent to a peer unnecessarily 🧠.
A receiver of a Capabilities-Exchange-Request (CER) that has no applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection 🙅. Also, receiving a CER or CEA from a peer advertising itself as a relay (see Section 2.4) MUST be interpreted as having common applications with that peer 🪄.
The receiver of the Capabilities-Exchange-Request (CER) MUST work out common applications by intersecting its own supported Application Ids with all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER. The value of the Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used during that computation 🚫. The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint about everything it can do 💡.
Diameter implementations SHOULD first try to establish a TLS/TCP and DTLS/SCTP connection before the CER/CEA exchange 🔒, because that protects the capabilities information of both peers. To support older Diameter implementations that don't fully conform to this document, transport security MAY still be negotiated via an Inband-Security AVP 🧓. In this case, a receiver of a Capabilities-Exchange-Request (CER) with no security mechanisms in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the transport layer connection 🙈.
CERs from unknown peers MAY be silently discarded, or a CEA MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER 👀. Either way, the transport connection gets closed. If local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned. If a CER from an unknown peer gets a successful CEA, the peer entry lives exactly as long as the transport connection does. If there's a transport failure, all pending transactions headed for the unknown peer can be discarded 🗑️.
The CER and CEA messages MUST NOT be proxied, redirected, or relayed 🚷.
Since CER/CEA can't be proxied, an upstream agent might still get a message for which it has no available peers to handle the application that matches the Command Code 😵. When that happens, the 'E' bit is set in the answer message (Section 7) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER, which tells the downstream agent to take action, like re-routing the request to an alternate peer 🔀.
With the exception of the Capabilities-Exchange-Request message, a message of type Request that includes the Auth-Application-Id or Acct-Application-Id AVPs, or a message with an application-specific Command Code, MAY only be forwarded to a host that has explicitly advertised support for the application (or has advertised the Relay Application Id) 📮.
5.3.1. Capabilities-Exchange-Request 📣
The Capabilities-Exchange-Request (CER) is indicated by the Command Code set to 257 and the 'R' bit set in the Command Flags. It's sent to exchange local capabilities 🎁. If a transport failure is detected, this message MUST NOT be sent to an alternate peer 🙅.
When Diameter runs over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow connections to span multiple interfaces and multiple IP addresses 🌐, the Capabilities-Exchange-Request message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages 🧩.
Message Format
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]5.3.2. Capabilities-Exchange-Answer ✨
okay so the Capabilities-Exchange-Answer (CEA) 🎀 is the reply to a CER. It has Command Code 257 and the 'R' bit in the Command Flags is cleared, so you know it's an answer and not a request 💅.
when Diameter runs over SCTP [RFC4960] or DTLS/SCTP [RFC6083], those connections can span multiple interfaces, which means multiple IP addresses 🦋. so the CEA MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when sending Diameter messages. no skipping any, bestie 😭
Message Format
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
[ Failed-AVP ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]5.3.3. Vendor-Id AVP 🌸
the Vendor-Id AVP (AVP Code 266) is type Unsigned32 and holds the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value assigned to the Diameter Software vendor 👑. the combo of Vendor-Id, Product-Name (Section 5.3.7), and Firmware-Revision (Section 5.3.4) is giving debugging-info energy ✨.
a Vendor-Id value of zero in the CER or CEA message is reserved and means this field gets ignored 🙈.
5.3.4. Firmware-Revision AVP 🍓
the Firmware-Revision AVP (AVP Code 267) is type Unsigned32 and tells a Diameter peer what firmware revision the issuing device is running 💜.
if a device doesn't have a firmware revision (like a general-purpose computer running Diameter software modules, for instance), it's totally fine to report the revision of the Diameter software module instead 🫶.
5.3.5. Host-IP-Address AVP 🦋
the Host-IP-Address AVP (AVP Code 257) is type Address and tells a peer the sender's IP address. every source address a Diameter node expects to use with SCTP [RFC4960] or DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages, with a Host-IP-Address AVP for each address 🔥.
5.3.6. Supported-Vendor-Id AVP 🧚
the Supported-Vendor-Id AVP (AVP Code 265) is type Unsigned32 and holds the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value for a vendor that isn't the device vendor but does include the application vendor 💖. it goes in CER and CEA so the peer knows the sender supports (a subset of) the Vendor-Specific AVPs defined by that vendor. the value MUST NOT be set to zero 🙅♀️. multiple instances with the same value SHOULD NOT be sent, because nobody needs duplicates, periodt 💅.
5.3.7. Product-Name AVP 🌈
the Product-Name AVP (AVP Code 269) is type UTF8String and holds the vendor-assigned name for the product 🎀. it SHOULD stay the same across firmware revisions for the same product, so the name doesn't keep changing on people 🥹.
5.4. Disconnecting Peer Connections 👋
when a Diameter node drops one of its transport connections, the peer can't know why 😩. it'll most likely assume there was a connectivity problem or that the peer rebooted. in those cases the peer may periodically try to reconnect, as stated in Section 2.1 🔁. but if the disconnect happened because of a shortage of internal resources, or because the node simply has no plans to forward any Diameter messages to that peer anytime soon, then a periodic connection request would be totally unwelcome 🙅♀️. the Disconnection-Reason AVP holds the reason the Diameter node sent the Disconnect-Peer-Request message 💜.
the Disconnect-Peer-Request message is how a Diameter node tells its peer "I'm about to disconnect the transport layer, and please don't reconnect unless you've got a valid reason (like a message to forward)" 🫶. when it gets this message, the peer sends back a Disconnect-Peer-Answer, which SHOULD contain an error if messages were recently forwarded and are probably still in flight, since otherwise you'd get a race condition 😬.
the receiver of the Disconnect-Peer-Answer is the one that starts the transport disconnect ✨. the sender of the Disconnect-Peer-Answer should be able to notice the transport closing and clean up the connection 🧹.
5.4.1. Disconnect-Peer-Request 💌
the Disconnect-Peer-Request (DPR) has Command Code 282 and the 'R' bit set in the Command Flags. it gets sent to a peer to say it plans to shut down the transport connection 👋. if a transport failure is detected, this message MUST NOT be sent to an alternate peer 🚫.
Message Format
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
* [ AVP ]5.4.2. Disconnect-Peer-Answer 🫧
the Disconnect-Peer-Answer (DPA) has Command Code 282 and the 'R' bit cleared. it's the response to a Disconnect-Peer-Request 💅. once it's received, the transport connection gets shut down, and that's the end of that 👑.
Message Format
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
* [ AVP ]5.4.3. Disconnect-Cause AVP 🍓
the Disconnect-Cause AVP (AVP Code 273) is type Enumerated 🌸. a Diameter node MUST include this AVP in the Disconnect-Peer-Request message so the peer knows why it wants to shut down the transport connection 💖. these are the values that are supported:
REBOOTING(0): a scheduled reboot is coming up soon. a receiver of a DPR with this result code MAY attempt reconnection 🔁.BUSY(1): the peer's internal resources are stretched thin, and it has decided the transport connection needs to close 😮💨. a receiver of a DPR with this result code SHOULD NOT attempt reconnection 🚫.DO_NOT_WANT_TO_TALK_TO_YOU(2): the peer has decided it doesn't need the transport connection to exist, since it doesn't expect any messages in the near future 💀. a receiver of a DPR with this result code SHOULD NOT attempt reconnection 🙈.
5.5. Transport Failure Detection 🕵️♀️
given how Diameter works, it's recommended that transport failures get detected as soon as possible ⚡. catching them fast means fewer messages get sent to agents that aren't available anymore, which avoids unnecessary delays and gives you better failover performance 🚀. the Device-Watchdog-Request and Device-Watchdog-Answer messages, defined in this section, are what proactively detect transport failures 🦋.
5.5.1. Device-Watchdog-Request 🐶
the Device-Watchdog-Request (DWR) has Command Code 280 and the 'R' bit set. it gets sent to a peer when no traffic has been exchanged between the two peers (see Section 5.5.3) ⏰. if a transport failure is detected, this message MUST NOT be sent to an alternate peer 🙅♀️.
Message Format
<DWR> ::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
* [ AVP ]5.5.2. Device-Watchdog-Answer 🐥
the Device-Watchdog-Answer (DWA) has Command Code 280 and the 'R' bit cleared. it's the response to a Device-Watchdog-Request 💫.
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ AVP ]5.5.3. Transport Failure Algorithm 🧠
the transport failure algorithm is defined in [RFC3539] 📖. every Diameter implementation MUST support the algorithm from that specification to be compliant with the Diameter base protocol 🫶. no exceptions, bestie 👑.
5.5.4. Failover and Failback Procedures 🔄
so when a transport failure is detected with a peer, all the pending request messages need to get forwarded to an alternate agent, if that's possible 🏃♀️. this is commonly called "failover" ✨.
to pull off failover, a Diameter node has to keep a pending message queue for each peer 📋. when an answer comes in, the matching request gets removed from the queue. the Hop-by-Hop Identifier field is what matches the answer to the queued request 🔍.
when a transport failure is detected, all messages in the queue get sent to an alternate agent with the T flag set, if possible 📨. on booting a Diameter client or agent, the T flag also gets set on any leftover records in non-volatile storage that are still waiting to be sent 💾. one example of when you can't forward a message to an alternate server is when the message has a fixed destination and the unavailable peer is its final destination (see Destination-Host AVP) 🙃. that kind of error means the agent has to return an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER 😭.
it's important to note that multiple identical requests or answers MAY be received as a result of a failover 👀. to catch duplicates, the End-to-End Identifier field in the Diameter header, along with the Origin-Host AVP, MUST be used 🕵️♀️.
as described in Section 2.1, a connection request should be periodically attempted with the failed peer to re-establish the transport connection 🔁. once a connection is successfully set up, messages can start flowing to the peer again. this is commonly called "failback" 🌈💕
5.6. Peer State Machine ✨
Okay bestie, this is the big one 💅 This section has a finite state machine that all Diameter implementations MUST observe. Every Diameter node MUST follow the state machine below when talking to each peer. Multiple actions are separated by commas and can wrap onto the next line when space is tight, and the same goes for state and next state 🦋
This state machine is closely coupled with the one in [RFC3539], which handles opening, closing, failing over, probing, and reopening transport connections. Heads up: [RFC3539] requires the use of watchdog messages to probe connections, and for Diameter those are DWR and DWA messages 🫶
The I- prefix means the initiator (connecting) connection, and the R- prefix means the responder (listening) connection. If there's no prefix, the event or action is the same no matter which connection it happened on 🌸
The stable states are Closed, I-Open, and R-Open. Everything else is intermediate. I-Open and R-Open are basically twins, the only difference being whether the initiator or the responder transport connection is used for communication 💜
A CER is always sent on the initiating connection right after the connection request completes successfully ✨ If there's an election, one of the two connections shuts down. The responder connection survives if the local Origin-Host is higher than the peer's, and the initiator connection survives if the peer's Origin-Host is higher. All messages after that go over the survivor. The results of an election on one peer are guaranteed to be the inverse of the results on the other, so they always agree on who wins 👑
For TLS/TCP and DTLS/SCTP usage, the handshake SHOULD begin when both ends are in the closed state, before any Diameter messages get exchanged. The TLS/TCP or DTLS/SCTP connection SHOULD be established before any CER or CEA gets sent, so the capabilities info of both peers is secured and protected 🔐 The connection SHOULD be disconnected when the state machine moves to closed. Now, older Diameter implementations that aren't ready to accept TLS/TCP or DTLS/SCTP connections while closed will make that first attempt fail 🙈 In that case the initiator MAY then try plain TCP or SCTP and start the TLS/TCP or DTLS/SCTP handshake once both ends are open. If that handshake works, all further messages go over TLS/TCP or DTLS/SCTP. If it fails, both ends move to closed 💀
The state machine only constrains how an implementation behaves as seen by its peers through events on the wire. Any implementation that gives equivalent results counts as compliant, so you do you, as long as the wire behaviour matches 🧚
state event action next state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack
R-Conn-CER R-Accept, R-Open
Process-CER,
R-Snd-CEA
Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA
I-Rcv-Conn-Nack Cleanup Closed
R-Conn-CER R-Accept, Wait-Conn-Ack/
Process-CER Elect
Timeout Error Closed
Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
R-Conn-CER R-Accept, Wait-Returns
Process-CER,
Elect
I-Peer-Disc I-Disc Closed
I-Rcv-Non-CEA Error Closed
Timeout Error Closed
Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns
Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open
R-Peer-Disc R-Disc Wait-Conn-Ack
R-Conn-CER R-Reject Wait-Conn-Ack/
Elect
Timeout Error Closed
Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
I-Peer-Disc I-Disc, R-Open
R-Snd-CEA
I-Rcv-CEA R-Disc I-Open
R-Peer-Disc R-Disc Wait-I-CEA
R-Conn-CER R-Reject Wait-Returns
Timeout Error Closed
R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open
R-Rcv-DWR Process-DWR, R-Open
R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Reject R-Open
Stop R-Snd-DPR Closing
R-Rcv-DPR R-Snd-DPA Closing
R-Peer-Disc R-Disc Closed
I-Open Send-Message I-Snd-Message I-Open
I-Rcv-Message Process I-Open
I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open
Stop I-Snd-DPR Closing
I-Rcv-DPR I-Snd-DPA Closing
I-Peer-Disc I-Disc Closed
Closing I-Rcv-DPA I-Disc Closed
R-Rcv-DPA R-Disc Closed
Timeout Error Closed
I-Peer-Disc I-Disc Closed
R-Peer-Disc R-Disc Closed5.6.1. Incoming Connections
When a connection request comes in from a Diameter peer, you usually can't tell who it is until a CER shows up 🕵️♀️ That's because host and port are what identify a Diameter peer, and the source port of an incoming connection is arbitrary. Once the CER arrives, the Origin-Host uniquely identifies the connecting peer 💖
So a Diameter peer needs logic that sits outside the state machine to receive connection requests, accept them, and wait for the CER. Once the CER lands on a new connection, the Origin-Host is used to find the state machine for that peer, and the connection and CER get handed to it as an R-Conn-CER event 🎀
The logic handling incoming connections SHOULD close and discard the connection if any message other than a CER arrives, or if an implementation-defined timeout goes off before the CER is received. Since handling incoming connections up to and including the CER needs its own logic (separate from any single peer's state machine), it's described here instead of in the state machine above 🧠
5.6.2. Events
Transitions and actions in the automaton are triggered by events. In this section we ignore the I- and R- prefixes, because the event would be the same either way, just on one of two possible connections ✨
Start: The Diameter application has signaled that a connection should be initiated with the peer.R-Conn-CER: An acknowledgement comes in saying the transport connection is established, and the associated CER has arrived.Rcv-Conn-Ack: A positive acknowledgement is received confirming that the transport connection is established.Rcv-Conn-Nack: A negative acknowledgement is received saying the transport connection was not established.Timeout: An application-defined timer has expired while waiting for some event.Rcv-CER: A CER message from the peer was received.Rcv-CEA: A CEA message from the peer was received.Rcv-Non-CEA: A message from the peer, other than a CEA, was received.Peer-Disc: A disconnection indication from the peer was received.Rcv-DPR: A DPR message from the peer was received.Rcv-DPA: A DPA message from the peer was received.Win-Election: An election was held, and the local node was the winner 👑Send-Message: A message is to be sent.Rcv-Message: A message other than CER, CEA, DPR, DPA, DWR, or DWA was received.Stop: The Diameter application has signaled that a connection should be terminated (for example, on system shutdown) 🥀
5.6.3. Actions
Actions in the automaton are triggered by events, and they usually mean sending packets and/or doing something to the connection 🦋 Same deal here: we ignore the I- and R- prefixes, since the action would be identical on either connection.
Snd-Conn-Req: A transport connection is initiated with the peer.Accept: The incoming connection associated with theR-Conn-CERis accepted as the responder connection.Reject: The incoming connection associated with theR-Conn-CERis disconnected.Process-CER: The CER associated with theR-Conn-CERis processed.Snd-CER: A CER message is sent to the peer.Snd-CEA: A CEA message is sent to the peer.Cleanup: If necessary, the connection is shut down and any local resources are freed 🧹Error: The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed.Process-CEA: A received CEA is processed.Snd-DPR: A DPR message is sent to the peer.Snd-DPA: A DPA message is sent to the peer.Disc: The transport layer connection is disconnected, and local resources are freed.Elect: An election occurs (see Section 5.6.4 for more information) 🗳️Snd-Message: A message is sent.Snd-DWR: A DWR message is sent.Snd-DWA: A DWA message is sent.Process-DWR: The DWR message is serviced.Process-DWA: The DWA message is serviced.Process: A message is serviced.
5.6.4. The Election Process ✨
Okay so the election happens on the responder 🎀. The responder compares the Origin-Host it got in the CER with its own Origin-Host, treating both as streams of octets. If the local Origin-Host lexicographically succeeds the received one, a Win-Election event gets issued locally. Diameter identities are in ASCII, so the lexical comparison lines up with DNS case insensitivity: octets in the ASCII range 'a' through 'z' MUST compare equally to their uppercase counterparts between 'A' and 'Z'. Check Appendix D for how Diameter and Internationalized Domain Names (IDNs) work together 🌸.
The winner of the election MUST close the connection it initiated. Back in the day, keeping the responder side of a connection was more efficient than keeping the initiator side 👀. Current practice makes that distinction irrelevant, so it's not a big deal anymore 💅.
6. Diameter Message Processing 🦋
This section is all about how Diameter requests and answers get created and processed. Let's go 🫶.
6.1. Diameter Request Routing Overview 🗺️
A request heads toward its final destination using one of three combinations of the Destination-Realm and Destination-Host AVPs:
- A request that is not able to be proxied (such as a CER) MUST NOT contain either
Destination-RealmorDestination-HostAVPs. - A request that needs to go to a home server serving a specific realm, but not to a specific server (like the first request of a series of round trips), MUST contain a
Destination-RealmAVP but MUST NOT contain aDestination-HostAVP. For Diameter clients, the value of theDestination-RealmAVP MAY be extracted from theUser-NameAVP, or other methods. - Otherwise, a request that needs to go to a specific home server among those serving a given realm MUST contain both the
Destination-RealmandDestination-HostAVPs.
The Destination-Host AVP gets used as described above when the destination of the request is fixed, which includes:
- Authentication requests that span multiple round trips.
- A Diameter message that uses a security mechanism relying on a pre-established session key shared between the source and the final destination of the message.
- Server-initiated messages that MUST be received by a specific Diameter client (for example, an access device), such as the Abort-Session-Request message, which is used to request that a particular user's session be terminated.
Heads up 👀: an agent can only forward a request to a host described in the Destination-Host AVP if that host is included in its peer table (see Section 2.6). Otherwise, the request gets routed based on the Destination-Realm only (see Section 6.1.6).
When a message is received, it gets processed in the following order 📋:
- If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed.
- If the message is intended for a Diameter peer that the local host can directly communicate with, the procedures listed in Section 6.1.5 are followed. This is known as "Request Forwarding".
- The procedure listed in Section 6.1.6 is followed, which is known as "Request Routing".
- If none of the above are successful, an answer is returned with the
Result-Codeset toDIAMETER_UNABLE_TO_DELIVER, with the 'E' bit set.
For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers. Non-negotiable, bestie 🔥.
The overview in this section (6.1) is meant to give Diameter developers general guidelines. Implementations are free to use different methods than the ones described here, as long as they conform to the requirements specified in Sections 6.1.1 through 6.1.9. See Section 7 for more details on error handling 🫧.
6.1.1. Originating a Request 🚀
When creating a request, the following procedures MUST be followed, in addition to any other procedures described in the application definition for that specific request:
- the Command Code is set to the appropriate value;
- the 'R' bit is set;
- the End-to-End Identifier is set to a locally unique value;
- the
Origin-HostandOrigin-RealmAVPs MUST be set to the appropriate values, used to identify the source of the message; and - the
Destination-HostandDestination-RealmAVPs MUST be set to the appropriate values, as described in Section 6.1.
6.1.2. Sending a Request 📨
When sending a request, whether it originated locally or came from a forwarding or routing operation, the following procedures SHOULD be followed:
- The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
- The message SHOULD be saved in the list of pending requests.
Other actions to perform on the message, based on the particular role the agent is playing, are described in the following sections 💅.
6.1.3. Receiving Requests 🛡️
A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When that happens, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. Loop = immediately not it 🙅♀️.
6.1.4. Processing Local Requests 🏠
A request is known to be for local consumption when one of the following conditions occurs:
- The
Destination-HostAVP contains the local host's identity; - The
Destination-HostAVP is not present, theDestination-RealmAVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or - Both the
Destination-Hostand theDestination-Realmare not present.
When a request is processed locally, the rules in Section 6.2 should be used to generate the corresponding answer.
6.1.5. Request Forwarding 📬
Request forwarding runs on the Diameter peer table. The Diameter peer table holds all of the peers the local node can directly communicate with.
When a request is received, and the host encoded in the Destination-Host AVP is present in the peer table, the message SHOULD be forwarded to that peer.
6.1.6. Request Routing 🧭
Diameter request message routing is done via realms and Application Ids. A Diameter message that may be forwarded by Diameter agents (proxies, redirect agents, or relay agents) MUST include the target realm in the Destination-Realm AVP. Request routing SHOULD rely on the Destination-Realm AVP and the Application Id present in the request message header to help with the routing decision. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP.
Diameter agents MAY keep a list of locally supported realms and applications, and they MAY keep a list of externally supported realms and applications. When a request comes in that includes a realm and/or application that is not locally supported, the message is routed to the peer configured in the routing table (see Section 2.7).
Realm names and Application Ids are the minimum supported routing criteria. Additional information may be needed to support redirect semantics 🎯.
6.1.7. Predictive Loop Avoidance 🔮
Before forwarding or routing a request, Diameter agents, in addition to the processing described in Section 6.1.3, SHOULD check whether a candidate route's peer identity shows up in any of the Route-Record AVPs. If the agent detects a candidate route's peer identity in a Route-Record AVP, the agent MUST ignore that route for the Diameter request message and attempt alternate routes if any exist. If every candidate route gets eliminated by the above criteria, the agent SHOULD return a DIAMETER_UNABLE_TO_DELIVER message 🙃.
6.1.8. Redirecting Requests 🦘
When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry is added in a separate Redirect-Host AVP.
+------------------+
| Diameter |
| Redirect Agent |
+------------------+
^ | 2. command + 'E' bit
1. Request | | Result-Code =
joe@example.com | | DIAMETER_REDIRECT_INDICATION +
| | Redirect-Host AVP(s)
| v
+-------------+ 3. Request +-------------+
| example.com |------------->| example.net |
| Relay | | Diameter |
| Agent |<-------------| Server |
+-------------+ 4. Answer +-------------+
Figure 5: Diameter Redirect AgentThe receiver of an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the Hop-by-Hop Identifier in the Diameter header to find the request in the pending message queue (see Section 5.5.4) that needs to be redirected. If no transport connection exists with the new peer, one is created, and the request is sent directly to it 🛣️.
Multiple Redirect-Host AVPs are allowed. The receiver of the answer message with the 'E' bit set picks exactly one of these hosts as the destination of the redirected message ✨.
When the Redirect-Host-Usage AVP included in the answer message has a non-zero value, a route entry for the redirect indications is created and cached by the receiver. The redirect usage for that route entry is set by the value of the Redirect-Host-Usage AVP, and the lifetime of the cached route entry is set by the Redirect-Max-Cache-Time AVP value ⏳.
It's possible for multiple redirect indications to create multiple cached route entries that differ only in their redirect usage and in the peer they forward messages to. For example, two(2) route entries created by two(2) redirect indications result in two(2) cached routes for the same realm and Application Id. However, one has a redirect usage of ALL_SESSION, where matching requests get forwarded to one peer; the other has a redirect usage of ALL_REALM, where requests get forwarded to another peer. So an incoming request that matches the realm and Application Id of both routes will need additional resolution 😤. In that case, a routing precedence rule MUST be used against the redirect usage value to settle the contention. The precedence rule can be found in Section 6.13 💜.
6.1.9. Relaying and Proxying Requests ✨
okay so bestie, a relay or proxy agent MUST append a Route-Record AVP to every request it forwards 💅 that AVP holds the identity of the peer the request was received from 🫶
the Hop-by-Hop Identifier in the request gets saved and swapped for a locally unique value 🔥 and the source of the request gets saved too, which includes the IP address, port, and protocol 🎀
a relay or proxy agent MAY include the Proxy-Info AVP in requests if it needs access to local state information when the matching response comes back 🧚 but heads up, Proxy-Info has security implications because state info gets distributed to other entities 😭 so it is RECOMMENDED that the contents of Proxy-Info be protected with cryptographic mechanisms, like a keyed message digest such as HMAC-SHA1 [RFC2104] 🔐 that kind of mechanism does need key management, although only locally at the Diameter server 🌈 a full description of managing the keys used to protect Proxy-Info is beyond the scope of this document, so here are some common recommendations:
- The keys should be generated securely following the randomness recommendations in [RFC4086].
- The keys and cryptographic protection algorithms should be at least 128 bits in strength.
- The keys should not be used for any other purpose than generating and verifying instances of the
Proxy-InfoAVP. - The keys should be changed regularly.
- The keys should be changed if the AVP format or cryptographic protection algorithms change.
the message is then forwarded to the next hop, as identified in the routing table 🚀
Figure 6 shows message routing using the procedures from these sections 🗺️
(Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
(Origin-Realm=example.net) (Origin-Realm=example.net)
(Destination-Realm=example.com) (Destination-Realm=example.com)
(Route-Record=nas.example.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com)Figure 6: Routing of Diameter messages
relay and proxy agents are not required to do full inspection of incoming messages 🌸 at a minimum, they have to validate the message header and the relevant routing AVPs when relaying. proxy agents may optionally do more in-depth validation for the applications they're interested in 💖
6.2. Diameter Answer Processing 💅
when a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command 👑
- The same
Hop-by-Hop Identifierin the request is used in the answer. - The local host's identity is encoded in the
Origin-HostAVP. - The
Destination-HostandDestination-RealmAVPs MUST NOT be present in the answer message. - The
Result-CodeAVP is added with its value indicating success or failure. - If the
Session-Idis present in the request, it MUST be included in the answer. - Any
Proxy-InfoAVPs in the request MUST be added to the answer message, in the same order they were present in the request. - The 'P' bit is set to the same value as the one in the request.
- The same End-to-End identifier in the request is used in the answer.
heads up, the error messages (see Section 7) get the same processing rules too 😭
6.2.1. Processing Received Answers 🦋
a Diameter client or proxy MUST match the Hop-by-Hop Identifier in a received answer against the list of pending requests. the corresponding message should be removed from the list of pending requests. it SHOULD ignore answers received that don't match a known Hop-by-Hop Identifier 🙈
6.2.2. Relaying and Proxying Answers 🌷
if the answer is for a request that was proxied or relayed, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field 🎀
if the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded 🧹
if a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. any additional local errors detected SHOULD be logged but not reflected in the Result-Code AVP 📝 if the agent gets an answer with a Result-Code AVP indicating success, and it wants to change that to indicate an error, it MUST modify the Result-Code AVP to contain the appropriate error in the message destined towards the access device, as well as include the Error-Reporting-Host AVP. it MUST also issue an STR on behalf of the access device towards the Diameter server 🫣
the agent MUST then send the answer to the host it received the original request from 💌
6.3. Origin-Host AVP 🌈
the Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and it MUST be present in all Diameter messages ✨ this AVP identifies the endpoint that originated the Diameter message. relay agents MUST NOT modify this AVP 🔒
the value of the Origin-Host AVP is guaranteed to be unique within a single host 💜
note that the Origin-Host AVP may resolve to more than one address, since the Diameter peer may support more than one address 🧚
this AVP SHOULD be placed as close to the Diameter header as possible 🍓
6.4. Origin-Realm AVP 🎀
the Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. this AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages 👑
this AVP SHOULD be placed as close to the Diameter header as possible 🌸
6.5. Destination-Host AVP 🦋
the Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. this AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST NOT be present in answer messages 💅
the absence of the Destination-Host AVP will cause a message to be sent to any Diameter server supporting the application within the realm specified in the Destination-Realm AVP 🌍
this AVP SHOULD be placed as close to the Diameter header as possible 🫶
6.6. Destination-Realm AVP 🧭
the Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity and contains the realm the message is to be routed to 🗺️ the Destination-Realm AVP MUST NOT be present in answer messages. Diameter clients insert the realm portion of the User-Name AVP. Diameter servers initiating a request message use the value of the Origin-Realm AVP from a previous message received from the intended target host (unless it's known a priori). when present, the Destination-Realm AVP is used to make message routing decisions ✨
the CCF for a request message that includes the Destination-Realm AVP SHOULD list the Destination-Realm AVP as a required AVP (an AVP indicated as {AVP}). otherwise, the message is inherently a non-routable message 💀
this AVP SHOULD be placed as close to the Diameter header as possible 🍓
6.7. Routing AVPs 🛣️
the AVPs defined in this section are Diameter AVPs used for routing purposes 🧚 these AVPs change as Diameter messages are processed by agents 🦋
6.7.1. Route-Record AVP 📍
the Route-Record AVP (AVP Code 282) is of type DiameterIdentity. the identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message 🫶
6.7.2. Proxy-Info AVP 🎁
the Proxy-Info AVP (AVP Code 284) is of type Grouped. this AVP contains the identity and local state information of the Diameter node that creates and adds it to a message. the Grouped Data field has the following CCF grammar:
Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host }
{ Proxy-State }
* [ AVP ]6.7.3. Proxy-Host AVP 🏠
the Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. this AVP contains the identity of the host that added the Proxy-Info AVP 💖
6.7.4. Proxy-State AVP 🫧
the Proxy-State AVP (AVP Code 33) is of type OctetString. it contains state information that would otherwise be stored at the Diameter entity that created it 🧠 as such, this AVP MUST be treated as opaque data by other Diameter entities 🙊
6.8. Auth-Application-Id AVP 🔑
the Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used to advertise support of the Authentication and Authorization portion of an application (see Section 2.4). if present in a message other than CER and CEA, the value of the Auth-Application-Id AVP MUST match the Application Id present in the Diameter message header 🎀
6.9. Acct-Application-Id AVP 📊
the Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and is used to advertise support of the accounting portion of an application (see Section 2.4). if present in a message other than CER and CEA, the value of the Acct-Application-Id AVP MUST match the Application Id present in the Diameter message header 💜
6.10. Inband-Security-Id AVP 🔐
the Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and is used to advertise support of the security portion of the application. the use of this AVP in CER and CEA messages is NOT RECOMMENDED 🙅♀️ instead, discovery of a Diameter entity's security capabilities can be done either through static configuration or via Diameter Peer Discovery as described in Section 5.2 🧚
The following values are supported:
NO_INBAND_SECURITY 0
This peer does not support TLS/TCP and DTLS/SCTP. This is the
default value, if the AVP is omitted.
TLS 1
This node supports TLS/TCP [RFC5246] and DTLS/SCTP [RFC6083]
security.6.11. Vendor-Specific-Application-Id AVP ✨
Okay bestie, the Vendor-Specific-Application-Id AVP (AVP Code 260) is type Grouped, and it's how a node advertises support for a vendor-specific Diameter application 🎀. Exactly one instance of either Auth-Application-Id or Acct-Application-Id AVP MUST be present. The Application Id carried by either of those AVPs MUST comply with the vendor-specific Application Id assignment described in Section 11.3. It MUST also match the Application Id present in the Diameter header, except when it's used in a CER or CEA message 💅.
The Vendor-Id AVP is an informational AVP about the vendor who may have authorship of the vendor-specific Diameter application 🦋. It MUST NOT be used as a way to define a completely separate vendor-specific Application Id space. Don't be that person 🙈.
The Vendor-Specific-Application-Id AVP SHOULD be placed as close to the Diameter header as possible 🫶.
AVP Format
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]A Vendor-Specific-Application-Id AVP MUST contain exactly one of either Auth-Application-Id or Acct-Application-Id. If a Vendor-Specific-Application-Id is received without one of these two AVPs, then the recipient SHOULD issue an answer with a Result-Code set to DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP, which MUST contain an example of an Auth-Application-Id AVP and an Acct-Application-Id AVP 😭.
If a Vendor-Specific-Application-Id is received that contains both Auth-Application-Id and Acct-Application-Id, then the recipient MUST issue an answer with Result-Code set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a Failed-AVP, which MUST contain the received Auth-Application-Id AVP and Acct-Application-Id AVP 💀.
6.12. Redirect-Host AVP 🧚
The Redirect-Host AVP (AVP Code 292) is type DiameterURI. One or more instances of this AVP MUST be present if the answer message's 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. Main character redirect energy 👑.
Once a node receives the above, it SHOULD forward the request directly to one of the hosts identified in these AVPs 🦋. The server contained in the selected Redirect-Host AVP SHOULD be used for all messages matching the criteria set by the Redirect-Host-Usage AVP ✨.
6.13. Redirect-Host-Usage AVP 🌸
The Redirect-Host-Usage AVP (AVP Code 261) is type Enumerated. This AVP MAY be present in answer messages whose 'E' bit is set and whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
When it's present, this AVP gives hints about how the routing entry resulting from the Redirect-Host is supposed to be used. These are the supported values, and they're giving a lot of options 🍓:
DONT_CACHE0: The host specified in theRedirect-HostAVP SHOULD NOT be cached. This is the default value.ALL_SESSION1: All messages within the same session, as defined by the same value of theSession-IDAVP, SHOULD be sent to the host specified in theRedirect-HostAVP.ALL_REALM2: All messages destined for the realm requested SHOULD be sent to the host specified in theRedirect-HostAVP.REALM_AND_APPLICATION3: All messages for the application requested to the realm specified SHOULD be sent to the host specified in theRedirect-HostAVP.ALL_APPLICATION4: All messages for the application requested SHOULD be sent to the host specified in theRedirect-HostAVP.ALL_HOST5: All messages that would be sent to the host that generated theRedirect-HostSHOULD be sent to the host specified in theRedirect-HostAVP.ALL_USER6: All messages for the user requested SHOULD be sent to the host specified in theRedirect-HostAVP.
When multiple cached routes are created by redirect indications and they differ only in redirect usage and peers to forward requests to (see Section 6.1.8), a precedence rule MUST be applied to the redirect usage values of the cached routes during normal routing to resolve contentions that may occur. The precedence rule is the order that dictates which redirect usage should be considered before any other, as they appear. The order is as follows 🥹:
ALL_SESSIONALL_USERREALM_AND_APPLICATIONALL_REALMALL_APPLICATIONALL_HOST
6.14. Redirect-Max-Cache-Time AVP ⏳
The Redirect-Max-Cache-Time AVP (AVP Code 262) is type Unsigned32. This AVP MUST be present in answer messages whose 'E' bit is set, whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and whose Redirect-Host-Usage AVP is set to a non-zero value.
This AVP holds the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, SHOULD be cached. Note that once a host is no longer reachable, any associated cache, peer, and routing table entries MUST be deleted. Trust me, you don't want stale routes hanging around 🙅♀️.
7. Error Handling 🚨
There are two different types of errors in Diameter: protocol errors and application errors. A protocol error is one that occurs at the base protocol level and MAY require per-hop attention (for example, a message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (for example, user authentication or a missing AVP) 🫠.
Result-Code AVP values that are used to report protocol errors MUST only be present in answer messages whose 'E' bit is set. When a request message is received that causes a protocol error, an answer message is returned with the 'E' bit set, and the Result-Code AVP is set to the appropriate protocol error value. As the answer is sent back towards the originator of the request, each proxy or relay agent MAY take action on the message 🔥.
1. Request +---------+ Link Broken
+-------------------------->|Diameter |----///----+
| +---------------------| | v
+------+--+ | 2. answer + 'E' set | Relay 2 | +--------+
|Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
| | | Home |
| Relay 1 |--+ +---------+ | Server |
+---------+ | 3. Request |Diameter | +--------+
+-------------------->| | ^
| Relay 3 |-----------+
+---------+Figure 7: Example of Protocol Error Causing Answer Message
Figure 7 gives an example of a message forwarded upstream by a Diameter relay 🧩. When the message is received by Relay 2, and it detects that it cannot forward the request to the home server, an answer message is returned with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Relay 1 would take special action, and given the error, attempt to route the message through its alternate Relay 3. Rerouting in real time, iconic 😤.
+---------+ 1. Request +---------+ 2. Request +---------+
| Access |------------>|Diameter |------------>|Diameter |
| | | | | Home |
| Device |<------------| Relay |<------------| Server |
+---------+ 4. Answer +---------+ 3. Answer +---------+
(Missing AVP) (Missing AVP)Figure 8: Example of Application Error Answer Message
Figure 8 gives an example of a Diameter message that caused an application error 📋. When application errors occur, the Diameter entity reporting the error clears the 'R' bit in the Command Flags and adds the Result-Code AVP with the proper value. Application errors do not require any proxy or relay agent involvement, so the message would be forwarded back to the originator of the request. No middleman drama here 💅.
In the case where the answer message itself contains errors, any related session SHOULD be terminated by sending an STR or ASR message. The Termination-Cause AVP in the STR MAY be filled with the appropriate value to indicate the cause of the error. An application MAY also send an application-specific request instead of an STR or ASR message to signal the error in the case where no state is maintained, or to allow for some form of error recovery with the corresponding Diameter entity 🩹.
There are certain Result-Code AVP application errors that require additional AVPs to be present in the answer. In these cases, the Diameter node that sets the Result-Code AVP to indicate the error MUST add the AVPs. Examples are as follows 👀:
- A request with an unrecognized AVP is received with the 'M' bit (Mandatory bit) set, which causes an answer to be sent with the Result-Code AVP set to
DIAMETER_AVP_UNSUPPORTEDand the Failed-AVP AVP containing the offending AVP. - A request with an AVP that is received with an unrecognized value causes an answer to be returned with the Result-Code AVP set to
DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the AVP causing the error. - A received command that is missing AVPs that are defined as required in the command's CCF is an error; examples are AVPs indicated as {AVP}. The receiver issues an answer with the Result-Code set to
DIAMETER_MISSING_AVPand creates an AVP with the AVP Code and other fields set as expected in the missing AVP. The created AVP is then added to the Failed-AVP AVP.
The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation-dependent order). The specific errors that can be described by this AVP are described in the following section 🎯.
7.1. Result-Code AVP 💖
The Result-Code AVP (AVP Code 268) is type Unsigned32 and indicates whether a particular request was completed successfully or an error occurred. All Diameter answer messages in IETF-defined Diameter application specifications MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non-2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP 📣.
The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see Section 11.3.2). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation 🌈:
- 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Protocol Errors)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure)
An unrecognized class (one whose first digit is not defined in this section) MUST be handled as a permanent failure. Not on my watch 🙅♀️.
7.1.1. Informational 🧠
Errors that fall within this category are used to inform the requester that a request could not be satisfied, and additional action is required on its part before access is granted 🔑.
DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter server to inform the access device that the authentication mechanism being used requires multiple round trips, and a subsequent request needs to be issued in order for access to be granted. Ping-pong era, but make it iconic 🏓✨.
7.1.2. Success 🌸
Okay so this category is the happy one, bestie 💖 Errors in the Success category just tell a peer that the request got completed ✨
DIAMETER_SUCCESS 2001
The request was successfully completed. 🎀
DIAMETER_LIMITED_SUCCESS 2002
When this one comes back, the request was successfully completed, but the application still has more processing to do before the user actually gets service 🦋
7.1.3. Protocol Errors 🔥
These ones are giving protocol drama 💅 Errors in the Protocol Error category SHOULD be handled per-hop, and Diameter proxies MAY try to fix the error if it's possible. ngl these MUST only show up in answer messages where the 'E' bit is set 🙈
DIAMETER_COMMAND_UNSUPPORTED 3001
This one shows up when a Diameter entity gets a message with a Command Code it doesn't support 💀
DIAMETER_UNABLE_TO_DELIVER 3002
This error is given when Diameter can't deliver the message to the destination. That happens either because no host in the realm supporting the required application was available to handle the request, or because the Destination-Host AVP showed up without its associated Destination-Realm AVP 😭
DIAMETER_REALM_NOT_SERVED 3003
The intended realm of the request isn't recognized 🙅♀️
DIAMETER_TOO_BUSY 3004
When this is returned, a Diameter node SHOULD try sending the message to an alternate peer. This error MUST only be used when a specific server was requested and it can't provide the service 🍓
DIAMETER_LOOP_DETECTED 3005
An agent spotted a loop while trying to get the message to the intended recipient. The message MAY be sent to an alternate peer if one is available, but the peer reporting the error has figured out there's a configuration problem 🌀
DIAMETER_REDIRECT_INDICATION 3006
A redirect agent figured out the request couldn't be satisfied locally, so the initiator SHOULD send the request straight to the server whose contact info got added to the response. When this is set, the Redirect-Host AVP MUST be present 🧚
DIAMETER_APPLICATION_UNSUPPORTED 3007
A request was sent for an application that isn't supported 🚫
DIAMETER_INVALID_HDR_BITS 3008
A request came in with bits in the Diameter header set either to an invalid combination or to a value that doesn't match the Command Code's definition. Messy 🙈
DIAMETER_INVALID_AVP_BITS 3009
A request came in with an AVP whose flag bits are set to an unrecognized value, or to a value that doesn't fit the AVP's definition 😵
DIAMETER_UNKNOWN_PEER 3010
A CER was received from a peer that nobody knows 👀
7.1.4. Transient Failures ⏳
This category is for the "not right now, but maybe later" errors 🦋 They tell a peer the request couldn't be satisfied when it arrived, but it MAY be able to satisfy it in the future. Note that these errors MUST be used in answer messages whose 'E' bit is not set ✨
DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely because the user typed in an invalid password. Further attempts MUST only be tried after the user has been prompted for a new password 🔐
DIAMETER_OUT_OF_SPACE 4002
A Diameter node got the accounting request but couldn't commit it to stable storage because it temporarily ran out of space 💾
ELECTION_LOST 4003
The peer figured out it lost the election, so it disconnected the transport connection 👋
7.1.5. Permanent Failures 🚫
These are the "absolutely not, don't try again" errors 💅 They tell the peer the request failed and it should not be attempted again. Note that these errors SHOULD be used in answer messages whose 'E' bit is not set. If it's not possible or efficient to build application-specific answer grammar in error conditions, answer messages with the 'E' bit set that comply with the grammar in Section 7.2 MAY also be used for permanent errors 🙈
DIAMETER_AVP_UNSUPPORTED 5001
The peer got a message with an AVP it doesn't recognize or support, and that AVP was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one or more Failed-AVP AVPs holding the AVPs that caused the failure 🙅♀️
DIAMETER_UNKNOWN_SESSION_ID 5002
The request contained a Session-Id nobody has ever heard of 🤷♀️
DIAMETER_AUTHORIZATION_REJECTED 5003
A request came in for a user who couldn't be authorized. This could happen if the requested service isn't permitted for that user 🔒
DIAMETER_INVALID_AVP_VALUE 5004
The request had an AVP with an invalid value in its data portion. A Diameter message indicating this error MUST include the offending AVPs inside a Failed-AVP AVP 🫠
DIAMETER_MISSING_AVP 5005
The request didn't include an AVP that the Command Code definition requires. If this value goes in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP, complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes 🧸
DIAMETER_RESOURCES_EXCEEDED 5006
A request came in that can't be authorized because the user already used up their allowed resources. For example, a user restricted to one dial-up PPP port trying to set up a second PPP connection 📞
DIAMETER_CONTRADICTING_AVPS 5007
The Home Diameter server noticed AVPs in the request that contradict each other, and it's not willing to provide service to the user. The Failed-AVP AVP MUST be present and contain the AVPs that contradicted each other 🙅♀️
DIAMETER_AVP_NOT_ALLOWED 5008
A message came in with an AVP that MUST NOT be present. The Failed-AVP AVP MUST be included and contain a copy of the offending AVP 🚫
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message came in with an AVP that showed up more often than the message definition allows. The Failed-AVP AVP MUST be included and contain a copy of the first instance of the offending AVP that went over the maximum number of occurrences 🔁
DIAMETER_NO_COMMON_APPLICATION 5010
This error comes back from a Diameter node that receives a CER where no applications are shared between the CER sender and the CER receiver 🤝
DIAMETER_UNSUPPORTED_VERSION 5011
This error is returned when a request arrives with a version number that isn't supported 🕰️
DIAMETER_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for reasons that aren't specified 🤐
DIAMETER_INVALID_BIT_IN_HEADER 5013
This error is returned when a reserved bit in the Diameter header is set to one (1), or when the bits in the Diameter header are set incorrectly ⚠️
DIAMETER_INVALID_AVP_LENGTH 5014
The request had an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs inside a Failed-AVP AVP. When the erroneous AVP length is bigger than the message length, or smaller than the minimum AVP header length, it's enough to include the offending AVP header plus a zero-filled payload of the minimum required length for that payload's data type. If the AVP is a Grouped AVP, the Grouped AVP header with an empty payload is enough to show which AVP is the problem. And if the offending AVP header can't be fully decoded because the AVP length is below the minimum AVP header length, it's enough to include an offending AVP header made by padding the incomplete header with zeros up to the minimum AVP header length 📏
DIAMETER_INVALID_MESSAGE_LENGTH 5015
This error is returned when a request arrives with an invalid message length 📐
DIAMETER_INVALID_AVP_BIT_COMBO 5016
The request had an AVP that isn't allowed to have the value it was given in the AVP Flags field. A Diameter message indicating this error MUST include the offending AVPs inside a Failed-AVP AVP 🧩
DIAMETER_NO_COMMON_SECURITY 5017
This error is returned when a CER message is received and there are no security mechanisms supported by both peers. A Capabilities-Exchange-Answer (CEA) message MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY 🔐
7.2. Error Bit ⚡
The 'E' (Error Bit) in the Diameter header gets set when the request caused a protocol-related error (see Section 7.1.3). A message with the 'E' bit MUST NOT be sent as a response to an answer message. Note that a message with the 'E' bit set still goes through the processing rules in Section 6.2 💅 When the 'E' bit is set, the answer won't follow the CCF for the command. Instead, it follows this CCF:
Message Format
<answer-message> ::= < Diameter Header: code, ERR [, PXY] >
0*1< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Experimental-Result ]
* [ Proxy-Info ]
* [ AVP ]The code in the header is the same as the one in the request message, but with the 'R' bit cleared and the 'E' bit set 🎀 The 'P' bit in the header gets set to the same value it had in the request message 🦋
7.3. Error-Message AVP 💬
The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY come along with a Result-Code AVP as a human-readable error message. It's not meant for environments where error messages get processed automatically, so it SHOULD NOT be expected that network entities parse the content of this AVP 🤖🚫
7.4. Error-Reporting-Host AVP 🔍
The Error-Reporting-Host AVP (AVP Code 294) is of type DiameterIdentity. It holds the identity of the Diameter host that set the Result-Code AVP to something other than 2001 (Success), but only if that host is different from the one in the Origin-Host AVP. It's for troubleshooting, and it MUST be set when the Result-Code AVP indicates a failure 🛠️✨
7.5. Failed-AVP AVP 💅
Okay so the Failed-AVP AVP (AVP Code 279) is a Grouped one 🎀, and it's basically the debugging tea ☕ for when a request gets rejected or only half-processed because something in one specific AVP was messed up. The Result-Code AVP tells you the reason, and a Diameter answer SHOULD contain a Failed-AVP that matches the error Result-Code points to. Practically speaking, this Failed-AVP is usually gonna be about the first AVP processing error a Diameter node runs into 👀.
The sus reasons it shows up: an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, a required AVP that got left out, an explicitly excluded AVP (check the tables in Section 10 bestie), or two or more copies of an AVP that's only allowed 0, 1, or 0-1 times 🙈.
Now the packing rules. A Diameter message SHOULD contain one Failed-AVP, holding the entire AVP that couldn't be processed successfully. If the problem is a missing required AVP, the Failed-AVP gets the missing AVP code, the missing Vendor-Id, and a zero-filled payload of the minimum required length for the omitted AVP. If the AVP length is invalid (the reported length is less than the minimum AVP header length, or greater than the reported message length), a copy of the offending AVP header and a zero-filled payload of the minimum required length SHOULD be added. 🧩
Here's the nesting situation. If the offending AVP is embedded within a Grouped AVP, the Failed-AVP MAY contain the grouped AVP, which in turn contains the single offending AVP. The same method MAY be employed if the grouped AVP is itself embedded in yet another grouped AVP, and so on. In that case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the single offending AVP. This lets the recipient detect exactly where the offending AVP is hiding inside a group 🔍✨
AVP Format
<Failed-AVP> ::= < AVP Header: 279 >
1* {AVP}7.6. Experimental-Result AVP 🧪
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and it tells you whether a particular vendor-specific request was completed successfully or whether an error occurred. It's structured like this:
AVP Format
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies the vendor responsible for assigning the result code that follows. All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Experimental-Result AVP. No skipping, no vibes-only answers 💅
7.7. Experimental-Result-Code AVP 🌸
The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32, and it holds a vendor-assigned value representing the result of processing the request.
It is recommended that vendor-specific result codes follow the same conventions given for the Result-Code AVP, covering the different types of result codes and the handling of errors (for non-2xxx values). Basically, same rulebook, different author 📖💜
8. Diameter User Sessions 🦋
Okay, big picture time 🌈 In general, Diameter can provide two different types of services to applications. The first involves authentication and authorization, and it can optionally make use of accounting. The second only makes use of accounting.
When a service makes use of the authentication and/or authorization portion of an application, and a user requests access to the network, the Diameter client issues an auth request to its local server. That auth request is defined in a service-specific Diameter application (e.g., NASREQ). The request contains a Session-Id AVP, which gets used in subsequent messages (like later authorization, accounting, etc.) relating to the user's session. The Session-Id AVP is basically how the client and servers match a Diameter message up with a user session 🔗
When a Diameter server authorizes a user to use network resources for a finite amount of time, and it's willing to extend that authorization via a future request, it MUST add the Authorization-Lifetime AVP to the answer message. The Authorization-Lifetime AVP defines the maximum number of seconds a user MAY make use of the resources before the server expects another authorization request. The Auth-Grace-Period AVP holds the number of seconds after the Authorization-Lifetime expires, after which the server will release all state information related to the user's session ⏳
Now, the money part 💸 If payment for services is expected by the serving realm from the user's home realm, the Authorization-Lifetime AVP combined with the Auth-Grace-Period AVP implies the maximum length of the session that the home realm is willing to be fiscally responsible for. Services provided past the expiration of the Authorization-Lifetime and Auth-Grace-Period AVPs are the responsibility of the access device. And of course, the actual cost of services rendered is clearly outside the scope of the protocol. Not its problem, bestie 🙅♀️
An access device that does not expect to send a re-authorization or a session termination request to the server MAY include the Auth-Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint to the server. If the server accepts the hint, it agrees that since no session termination message will be received once service to the user is terminated, it cannot maintain state for the session. If the answer message from the server contains a different value in the Auth-Session-State AVP (or the default value if the AVP is absent), the access device MUST follow the server's directives. Note that the value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-authorization requests and answers. Once it's been set aside, it stays set aside 🚫
The base protocol doesn't include any authorization request messages, since those are largely application-specific and get defined in a Diameter application document. What the base protocol does define is a set of messages used to terminate user sessions. These let servers that maintain state information free up resources 🧹
When a service only makes use of the accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, session termination messages aren't used, since a session gets signaled as terminated by issuing an accounting stop message 🛑
Diameter may also be used for services that can't be easily categorized as authentication, authorization, or accounting (e.g., certain Third Generation Partnership Project Internet Multimedia System (3GPP IMS) interfaces). In those cases, the finite state machine defined in subsequent sections may not be applicable. Therefore, the application itself MAY need to define its own finite state machine. However, such application-specific state machines SHOULD follow the general state machine framework outlined in this document, such as the use of Session-Id AVPs and the use of STR/STA and ASR/ASA messages for stateful sessions. Same vibe, different outfit 👗✨
8.1. Authorization Session State Machine ✨
okay bestie, this section is where the life cycle of a Diameter session gets mapped out as finite state machines 🦋 Every Diameter implementation that does the authentication and/or authorization part of a Diameter application MUST follow these, no exceptions 💅 When the text says "Service-Specific," it means a message defined inside a Diameter application, like Mobile IPv4 or NASREQ 🎀
There are four authorization session state machines in the base protocol 💖 The first two are for sessions where the server keeps session state, which is decided by the Auth-Session-State AVP (or by it being absent) ✨ One is the client's view and the other is the server's view 👑 The last two are for when the server does NOT keep session state, and yep, one is the client's view and one is the server's 🌸
When a session goes to the Idle state, any resources that were given to it have to be let go 🧚 And any event that isn't in the state machines MUST be treated as an error condition, and if there's an answer that applies, it MUST be sent back to whoever sent the message 😭
If an application doesn't support re-auth, then the state transitions for server-initiated re-auth (like Send RAR, Pending, Receive RAA, when both sides keep state) MAY be ignored 🙈
In the state table, "Failure to send X" means the Diameter agent can't send command X to the place it's supposed to go 💀 That could be because the peer is down, or because the peer sends back a transient failure or temporary protocol error, DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED, in the Result-Code AVP of the matching Answer command 🫶 And "X successfully sent" is just the opposite of "Failure to send X" 🍓
Here's the state machine a client follows when the server keeps state:
CLIENT, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Idle ASR Received Send ASA Idle
for unknown session with
Result-Code =
UNKNOWN_
SESSION_ID
Idle RAR Received Send RAA Idle
for unknown session with
Result-Code =
UNKNOWN_
SESSION_ID
Pending Successful service-specific Grant Open
authorization answer Access
received with default
Auth-Session-State value
Pending Successful service-specific Sent STR Discon
authorization answer received,
but service not provided
Pending Error processing successful Sent STR Discon
service-specific authorization
answer
Pending Failed service-specific Clean up Idle
authorization answer received
Open User or client device Send Open
requests access to service service-
specific
auth req
Open Successful service-specific Provide Open
authorization answer received service
Open Failed service-specific Discon. Idle
authorization answer user/device
received.
Open RAR received and client will Send RAA Open
perform subsequent re-auth with
Result-Code =
SUCCESS
Open RAR received and client will Send RAA Idle
not perform subsequent with
re-auth Result-Code !=
SUCCESS,
Discon.
user/device
Open Session-Timeout expires on Send STR Discon
access device
Open ASR received, Send ASA Discon
client will comply with
with request to end the Result-Code =
session = SUCCESS,
Send STR.
Open ASR Received, Send ASA Open
client will not comply with
with request to end the Result-Code !=
session != SUCCESS
Open Authorization-Lifetime + Send STR Discon
Auth-Grace-Period expires on
access device
Discon ASR received Send ASA Discon
Discon STA received Discon. Idle
user/deviceNext up is the state machine a server follows when it IS keeping state for the session 🌈
SERVER, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Service-specific authorization Send Open
request received, and successful
user is authorized service-
specific
answer
Idle Service-specific authorization Send Idle
request received, and failed
user is not authorized service-
specific
answer
Open Service-specific authorization Send Open
request received, and user successful
is authorized service-
specific
answer
Open Service-specific authorization Send Idle
request received, and user failed
is not authorized service-
specific
answer,
Clean up
Open Home server wants to confirm Send RAR Pending
authentication and/or
authorization of the user
Pending Received RAA with a failed Clean up Idle
Result-Code
Pending Received RAA with Result-Code Update Open
= SUCCESS session
Open Home server wants to Send ASR Discon
terminate the service
Open Authorization-Lifetime (and Clean up Idle
Auth-Grace-Period) expires
on home server
Open Session-Timeout expires on Clean up Idle
home server
Discon Failure to send ASR Wait, Discon
resend ASR
Discon ASR successfully sent and Clean up Idle
ASA Received with Result-Code
Not ASA Received None No Change
Discon
Any STR Received Send STA, Idle
Clean upNow the client side when the server does NOT keep state 🦋
CLIENT, STATELESS
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Pending Successful service-specific Grant Open
authorization answer access
received with Auth-Session-
State set to
NO_STATE_MAINTAINED
Pending Failed service-specific Clean up Idle
authorization answer
received
Open Session-Timeout expires on Discon. Idle
access device user/device
Open Service to user is terminated Discon. Idle
user/deviceAnd last but not least, the server side when it is NOT keeping state for the session 💜
SERVER, STATELESS
State Event Action New State
---------------------------------------------------------------
Idle Service-specific authorization Send Idle
request received, and service-
successfully processed specific
answer8.2. Accounting Session State Machine 🎀
okay so the accounting state machines are a must for applications that have an accounting part or that only do accounting stuff 💅 MUST be supported, bestie, so don't skip them 😭 The first one is what clients observe 🌸
Check out Section 9.7 for the Accounting Command Codes and Section 9.8 for the Accounting AVPs ✨
The server side depends on the application in some cases 🧚 The base protocol defines a default state machine that MUST be followed by every application that hasn't specified its own, and that's the second one in this section 👑
That default server side is super chill 🌈 It takes accounting records in any order and at any time, and it doesn't put any standards requirements on how those records get processed 💖 Diameter implementations can do checking, ordering, correlation, fraud detection, and other stuff with them 🫶 Any inspecting of AVPs for those tasks might happen right when a record shows up or later during post-processing 🍓 But since those tasks are usually application or even policy specific, the Diameter specs don't standardise them 🙈
Applications MAY define when to accept accounting records based on the value of the Accounting-Realtime-Required AVP, credit-limit checks, and so on 🦋
However, the Diameter base protocol has one optional server-side state machine that applications MAY follow if they need to track session state at the accounting server. 💅 Heads up, though: that tracking doesn't play nicely with long connectivity outages. So this state machine is only recommended when the application's Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, which means accounting connectivity trouble has to get the served user disconnected. Otherwise the client's records could get dropped by the server, which stops accepting them once the connection comes back. 😭 This is the third state machine in this section, and it's supervised by a session timer Ts. Ts should be reasonably higher than the Acct_Interim_Interval value. And honestly, setting Ts MAY be set to two times the Acct_Interim_Interval, because that stops the accounting session on the Diameter server from slipping into Idle during a short blip in the network. 🦋
Any event that isn't in the state machines MUST be treated as an error condition, and if an answer applies, one MUST be sent back to whoever originated the message. 🫶
Quick decoder ring for the state table: "Failure to send" means the Diameter client can't reach where it's trying to go. That could be because the peer is down, or because the peer replied with a transient failure or temporary protocol error, meaning DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command. "Failed answer" means the Diameter client got a non-transient failure notification in the Accounting Answer command. 💀
Also, the action "Disconnect user/dev" MUST also affect the authorization session state table. For example, it has to cause the STR message to be sent, if the application has both authentication/authorization and accounting parts. Main character energy, but make it consistent. 👑
The states PendingS, PendingI, PendingL, PendingE, and PendingB are the "waiting for an answer" states, for an accounting request about a Start, Interim, Stop, Event, or buffered record, in that order. 🌸
CLIENT, ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingS
access accounting
start req.
Idle Client or device requests Send PendingE
a one-time service accounting
event req
Idle Records in storage Send PendingB
record
PendingS Successful accounting Open
start answer received
PendingS Failure to send and buffer Store Open
space available and real time Start
not equal to DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer Open
space available and real time
equal to GRANT_AND_LOSE
PendingS Failure to send and no Disconnect Idle
buffer space available and user/dev
real time not equal to
GRANT_AND_LOSE
PendingS Failed accounting start answer Open
received and real time equal
to GRANT_AND_LOSE
PendingS Failed accounting start answer Disconnect Idle
received and real time not user/dev
equal to GRANT_AND_LOSE
PendingS User service terminated Store PendingS
stop
record
Open Interim interval elapses Send PendingI
accounting
interim
record
Open User service terminated Send PendingL
accounting
stop req.
PendingI Successful accounting interim Open
answer received
PendingI Failure to send and (buffer Store Open
space available or old interim
record can be overwritten) record
and real time not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open
space available and real time
equal to GRANT_AND_LOSE
PendingI Failure to send and no Disconnect Idle
buffer space available and user/dev
real time not equal to
GRANT_AND_LOSE
PendingI Failed accounting interim Open
answer received and real time
equal to GRANT_AND_LOSE
PendingI Failed accounting interim Disconnect Idle
answer received and user/dev
real time not equal to
GRANT_AND_LOSE
PendingI User service terminated Store PendingI
stop
record
PendingE Successful accounting Idle
event answer received
PendingE Failure to send and buffer Store Idle
space available event
record
PendingE Failure to send and no buffer Idle
space available
PendingE Failed accounting event answer Idle
received
PendingB Successful accounting answer Delete Idle
received record
PendingB Failure to send Idle
PendingB Failed accounting answer Delete Idle
received record
PendingL Successful accounting Idle
stop answer received
PendingL Failure to send and buffer Store Idle
space available stop
record
PendingL Failure to send and no buffer Idle
space available
PendingL Failed accounting stop answer Idle
received
SERVER, STATELESS ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Accounting start request Send Idle
received and successfully accounting
processed. start
answer
Idle Accounting event request Send Idle
received and successfully accounting
processed. event
answer
Idle Interim record received Send Idle
and successfully processed. accounting
interim
answer
Idle Accounting stop request Send Idle
received and successfully accounting
processed stop answer
Idle Accounting request received; Send Idle
no space left to store accounting
records answer;
Result-Code =
OUT_OF_
SPACE
SERVER, STATEFUL ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Accounting start request Send Open
received and successfully accounting
processed. start
answer;
Start Ts
Idle Accounting event request Send Idle
received and successfully accounting
processed. event
answer
Idle Accounting request received; Send Idle
no space left to store accounting
records answer;
Result-Code =
OUT_OF_
SPACE
Open Interim record received Send Open
and successfully processed. accounting
interim
answer;
Restart Ts
Open Accounting stop request Send Idle
received and successfully accounting
processed stop answer;
Stop Ts
Open Accounting request received; Send Idle
no space left to store accounting
records answer;
Result-Code =
OUT_OF_
SPACE;
Stop Ts
Open Session supervision timer Ts Stop Ts Idle
expired8.3. Server-Initiated Re-Auth ✨
A Diameter server can kick off a re-authentication and/or re-authorization for a particular session by sending a Re-Auth-Request (RAR). 🧚
For example, with prepaid services, the Diameter server that first authorized a session might want to double-check that the user is still actually using the service. 💖
An access device that gets an RAR message whose Session-Id matches a session that's currently active MUST start a re-auth towards the user, but only if the service supports that feature. 🔥 Also, every Diameter application MUST say whether server-initiated re-auth is supported, because some applications don't let access devices prompt the user for re-auth at all. 🙈
8.3.1. Re-Auth-Request 🎀
okay so the Re-Auth-Request (RAR) is how any server can poke the access device that's giving the session service and be like "hey, can we re-authenticate and/or re-authorize this user?" 💅 It's Command Code 258 with the 'R' bit set in the message flags, and any server can send one. 🦋
Message Format
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.3.2. Re-Auth-Answer 🌸
The Re-Auth-Answer (RAA) is the reply to the RAR, same Command Code 258 but with the 'R' bit cleared. 🫶 The Result-Code AVP MUST be present, because it's how you find out what happened to the request. 💖
ok and here's the big deal: a successful RAA MUST be followed by an application-specific authentication and/or authorization message. no skipping that step, bestie 😭
Message Format
<RAA> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]8.4. Session Termination ✨
so a Diameter server that authorized a session it's keeping state for really needs to know when that session is over. 👑 This is for tracking, and also so the stateful agents can free up whatever resources they gave the user. If the state isn't being kept, this section just doesn't apply, so you can chill. 🧚
When a user session that needed Diameter authorization ends, the access device that provided the service MUST send a Session-Termination-Request (STR) to the Diameter server that authorized it, so the server knows the session is done. 🔥 An STR MUST be issued when a user session ends for ANY reason, like user logoff, Session-Timeout running out, an admin doing admin things, getting terminated after an Abort-Session-Request (more on that below), the access device shutting down in an orderly way, etc. 🙈
The access device also MUST issue an STR for a session that got authorized but never actually started. 💀 This could happen because of something like a sudden resource shortage on the access device, or because the access device isn't willing to provide the type of service that was asked for in the authorization, or because it doesn't support a mandatory AVP that came back in the authorization, etc.
It's also possible that an authorized session never starts because of a proxy. 👀 For example, a proxy might change an authorization answer from success to failure before forwarding it to the access device. If the answer did NOT contain an Auth-Session-State AVP with the value NO_STATE_MAINTAINED, then a proxy that stops an authorized session from starting MUST issue an STR to the Diameter server that authorized it, since the access device has no way of knowing that the session was authorized in the first place. 😭🫶
A Diameter server that receives an STR MUST clean up resources (e.g., session state) tied to the Session-Id in the STR, and then send back a Session-Termination-Answer. 💅
A Diameter server also MUST clean up resources when the Session-Timeout expires, or when the Authorization-Lifetime and the Auth-Grace-Period AVPs expire without any re-authorization request coming in, and this happens whether or not an STR for that session shows up. ⏰ The access device isn't expected to keep providing service past those timers, so when either one runs out, it means the access device might have shut down unexpectedly. 😬
8.4.1. Session-Termination-Request 🦋
The Session-Termination-Request (STR) has Command Code 275 and the Command Flags' 'R' bit set. A Diameter client or a Diameter proxy sends it to tell the Diameter server that an authenticated and/or authorized session is ending. 🎀
Message Format
<STR> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ User-Name ]
[ Destination-Host ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.4.2. Session-Termination-Answer 💜
The Session-Termination-Answer (STA) is Command Code 275 with the 'R' bit cleared. The Diameter server sends it to acknowledge that the session has ended. ✨ The Result-Code AVP MUST be present, and it MAY contain an indication that something went wrong while the STR was being handled. 🙈
Once the STA is sent or received, the Diameter server MUST release all resources for the session named by the Session-Id AVP. 🔥 Any intermediate server in the Proxy-Chain MAY also release resources if it needs to. 🌈
Message Format
<STA> ::= < Diameter Header: 275, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
* [ Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]8.5. Aborting a Session 🛑
sometimes a Diameter server needs the access device to stop giving service for a session, and it does that by sending an Abort-Session-Request (ASR). 😤
For example, the server that first authorized the session might need to stop it because the user ran out of credit, or for some other reason nobody saw coming when the session was authorized. 💸
An access device that gets an ASR whose Session-ID matches a currently active session MAY stop the session. 🎀 Whether it actually does is implementation and/or configuration dependent. For example, an access device might only honor ASRs from certain agents. 🧚 Either way, the access device MUST respond with an Abort-Session-Answer, with a Result-Code AVP that says what action it took. 💅
8.5.1. Abort-Session-Request 🌸
The Abort-Session-Request (ASR) has Command Code 274 and the message flags' 'R' bit set. Any Diameter server or any Diameter proxy may send it to the access device that's providing session service, asking it to stop the session identified by the Session-Id. 🫶
Message Format
<ASR> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.5.2. Abort-Session-Answer 💖
The Abort-Session-Answer (ASA) is Command Code 274 with the 'R' bit cleared, and it's the reply to the ASR. 🦋 The Result-Code AVP MUST be present and tells you what happened to the request. 💅
here's the breakdown of the Result-Code values, bestie 📝:
- If the session named in the ASR's Session-Id was successfully terminated, the Result-Code is
DIAMETER_SUCCESS🎉 - If the session isn't active right now, the Result-Code is
DIAMETER_UNKNOWN_SESSION_ID🙈 - If the access device doesn't stop the session for any other reason, the Result-Code is
DIAMETER_UNABLE_TO_COMPLY💀
Message Format
<ASA> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]8.6. Inferring Session Termination from Origin-State-Id 🕵️♀️
the Origin-State-Id is the clever bit that lets a server spot sessions that never got an STR, because the access device crashed or shut down unexpectedly. 🧠✨
a Diameter client or access device bumps its Origin-State-Id every time it starts or powers up. 🔥 The new value then goes out in the CER/CEA message right when it connects to the server. The server compares the old value it has stored for that specific client with the new one. If the new value is bigger, and the client still has sessions that never got terminated, the server can figure out the client shut down abruptly. 👀
an access device can also put the Origin-State-Id in request messages other than the CER, but only if there are relays or proxies in between. 🌈 Heads up though: in that case, the server can't tell the access device restarted until it gets a new request from it. So this method is more opportunistic when proxies and relays are involved. 🤷♀️
The Diameter server may assume that every session active before it detected a client restart is over. 💅 The Diameter server MAY clean up all session state tied to those lost sessions, and it MAY also send STRs for all those lost sessions that were authorized on upstream servers, so the session state gets cleaned up globally. 🧹💖
8.7. Auth-Request-Type AVP ✨
The Auth-Request-Type AVP (AVP Code 274) is an Enumerated AVP that shows up in application-specific auth requests to tell the peers whether a user should be authenticated only, authorized only, or both 🔐. Heads up, bestie: any value other than both MAY cause RADIUS interoperability issues 😬. Here are the values:
AUTHENTICATE_ONLY 1: The request is for authentication only 🔑. It MUST contain the application-specific authentication AVPs that the Diameter server needs to authenticate the user.AUTHORIZE_ONLY 2: The request is for authorization only 🎟️. It MUST contain the application-specific authorization AVPs needed to identify the service being requested or offered.AUTHORIZE_AUTHENTICATE 3: The request asks for both authentication and authorization 👑. It MUST include both the relevant application-specific authentication information and the authorization information needed to identify the service being requested or offered.
8.8. Session-Id AVP 🦋
The Session-Id AVP (AVP Code 263) is a UTF8String that identifies one specific session (see Section 8) 🫶. Every message about a session MUST include only one Session-Id AVP, and the same value MUST be used for the whole life of the session 💅. When it's present, the Session-Id SHOULD show up right after the Diameter header (see Section 3).
The Session-Id MUST be globally and eternally unique 🌍. It's meant to identify a user session on its own, with no other info needed, and it may be needed to link historical authentication info with accounting info 📚. It has a mandatory part and an implementation-defined part, and there's a recommended format for that second part, shown below 🧩.
The Session-Id MUST begin with the sender's identity, encoded as a DiameterIdentity (see Section 4.3.1) 🪪. The rest is split up with a ; character, and it MAY be any sequence that the client can guarantee to be eternally unique. That said, the following format is recommended (square brackets [] mark an optional element):
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]The <high 32 bits> and <low 32 bits> parts are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value 🔢. The 64-bit value is written in two parts so it's easier for 32-bit processors to handle 🖥️. At startup, the high 32 bits MAY be initialized to the time in NTP format [RFC5905], and the low 32 bits MAY be initialized to zero ⏰. For practical purposes, this kills any chance of overlapping Session-Ids after a reboot, as long as the reboot takes longer than a second 🔄. Or, an implementation MAY keep track of the increasing value in non-volatile memory 💾.
The <optional value> is up to the implementation 🎀. It might include a modem's device Id, a Layer 2 address, a timestamp, and so on.
Here's an example with no optional value:
accesspoint7.example.com;1876543210;523And here's one with an optional value:
accesspoint7.example.com;1876543210;523;mobile@200.1.1.88The Diameter application that starts the session creates the Session-Id, which in most cases is the client 🙌. Also, a Session-Id MAY be used for the authentication, authorization, and accounting commands of a given application 💜.
8.9. Authorization-Lifetime AVP ⏳
The Authorization-Lifetime AVP (AVP Code 291) is an Unsigned32 that holds the maximum number of seconds of service the user gets before they need to be re-authenticated and/or re-authorized 🕰️. Be careful when you pick this value 🙈. A low, non-zero value could create a ton of Diameter traffic, and that could congest both the network and the agents 🚦.
A value of zero (0) means the access device needs to do an immediate re-auth 🏃♀️. If the AVP is absent, or the value is all ones (every bit in the 32-bit field set to one), no re-auth is expected 🌸.
If both this AVP and the Session-Timeout AVP are in a message, the Session-Timeout value MUST NOT be smaller than the Authorization-Lifetime AVP 📏.
An Authorization-Lifetime AVP MAY be in re-authorization messages 💫. It holds the number of seconds the user is authorized to get service, counted from when the access device receives the re-auth answer message ⭐.
The client MAY send this AVP as a hint for the longest lifetime it's willing to accept 🫧. The server MUST return a value that is equal to or smaller than the one the client gave 🎯.
8.10. Auth-Grace-Period AVP 🌙
The Auth-Grace-Period AVP (AVP Code 276) is an Unsigned32 that holds the number of seconds the Diameter server waits after the Authorization-Lifetime AVP expires, before it cleans up the session's resources 🧹.
8.11. Auth-Session-State AVP 🧠
The Auth-Session-State AVP (AVP Code 277) is an Enumerated AVP that says whether state is kept for a particular session 📝. The client MAY include this AVP in requests as a hint for the server, but the value in the server's answer is binding 👑. These values are supported:
STATE_MAINTAINED 0: Session state is being kept, so the access device MUST send a session termination message when service to the user stops 🛑. This is the default value 💖.NO_STATE_MAINTAINED 1: The access device won't send session termination messages when the Authorization-Lifetime expires 🙅♀️.
8.12. Re-Auth-Request-Type AVP 🔁
The Re-Auth-Request-Type AVP (AVP Code 285) is an Enumerated AVP that goes in application-specific auth answers to tell the client what to do when the Authorization-Lifetime runs out ⏰.
If the answer message has an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be in the answer message 📬. These values are defined:
AUTHORIZE_ONLY 0: When the Authorization-Lifetime expires, an authorization-only re-auth is expected 🎟️. This is the default if the AVP isn't in answer messages that include the Authorization-Lifetime.AUTHORIZE_AUTHENTICATE 1: When the Authorization-Lifetime expires, an authentication and authorization re-auth is expected 🔐.
8.13. Session-Timeout AVP ⌛
The Session-Timeout AVP (AVP Code 27) [RFC2865] is an Unsigned32 that holds the maximum number of seconds of service the user gets before the session ends 🏁. When an answer message has both the Session-Timeout and the Authorization-Lifetime AVPs, the Session-Timeout MUST be equal to or greater than the Authorization-Lifetime value 💅.
If a session ends on an access device because the Session-Timeout expired, an STR MUST be issued 📨. The exception is when both the access device and the home server had already agreed that no session termination messages would be sent (see Section 8) 🙈.
A Session-Timeout AVP MAY be in a re-authorization answer message 💬. It holds the number of seconds left, counted from the start of the re-auth ⏳.
A value of zero, or no AVP at all, means the session can last an unlimited number of seconds before it ends ♾️.
The client MAY send this AVP as a hint for the longest timeout it's willing to accept 🌷. The server MAY return a value that is equal to or smaller than the one the client gave 🎀.
8.14. User-Name AVP 🧑💻
The User-Name AVP (AVP Code 1) [RFC2865] is a UTF8String that holds the User-Name, in a format that matches the NAI specification [RFC4282] 🪪.
8.15. Termination-Cause AVP 🚪
The Termination-Cause AVP (AVP Code 295) is an Enumerated AVP that says why a session ended on the access device 🌅. The values that are currently assigned can be found in the IANA registry for Termination-Cause AVP Values [IANATCV] 📖.
8.16. Origin-State-Id AVP 🕰️
The Origin-State-Id AVP (AVP Code 278) is an Unsigned32 that's a monotonically increasing value. It goes up whenever a Diameter entity restarts and loses its previous state, like after a reboot 🔄. Origin-State-Id MAY be included in any Diameter message, including CER 💌.
A Diameter entity that sends this AVP MUST create a higher value each time its state is reset ⬆️. The entity MAY set Origin-State-Id to its startup time, or it MAY use an incrementing counter kept in non-volatile memory across restarts 💾.
The Origin-State-Id, if present, MUST reflect the state of the entity named in Origin-Host 🪞. If a proxy changes Origin-Host, it MUST either remove Origin-State-Id or update it appropriately too 🔧.
This is usually used by an access device that always starts with no active sessions. So any session that was active before a restart has been lost 💔. When an Origin-State-Id is included in a message, other Diameter entities can infer that sessions tied to a lower Origin-State-Id are no longer active 🕵️♀️. If an access device doesn't want those inferences made, it MUST either leave Origin-State-Id out of every message or set its value to 0 🙅♀️.
8.17. Session-Binding AVP 🔗
The Session-Binding AVP (AVP Code 270) is an Unsigned32, and it MAY be in application-specific authorization answer messages 💫. If it's there, it MAY tell the Diameter client that all future application-specific re-auth and Session-Termination-Request messages for this session MUST go to the same authorization server 🎯.
This field is a bit mask, and these bits are defined 🎀:
RE_AUTH 1: When this bit is set, future re-auth messages for this session MUST NOT include the Destination-Host AVP 🚫. When it's cleared, which is the default, the Destination-Host AVP MUST be in all re-auth messages for this session 📬.STR 2: When this bit is set, the STR message for this session MUST NOT include the Destination-Host AVP 🙅♀️. When it's cleared, which is the default, the Destination-Host AVP MUST be in the STR message for this session 📨.ACCOUNTING 4: When this bit is set, all accounting messages for this session MUST NOT include the Destination-Host AVP 📊. When it's cleared, which is the default, the Destination-Host AVP, if known, MUST be in all accounting messages for this session 💜.
8.18. Session-Server-Failover AVP 🦋
okay so the Session-Server-Failover AVP (AVP Code 271) is an Enumerated type 🧚 and it MAY show up in application-specific authorization answer messages that either don't include the Session-Binding AVP or include it with any of the bits set to zero 🙈. If it's there, it MAY tell the Diameter client that when a re-auth or STR message fails because of a delivery problem, the client SHOULD send a follow-up message without the Destination-Host AVP 💅. When it's absent, the default is REFUSE_SERVICE ✨.
These are the supported values:
REFUSE_SERVICE0
if either the re-auth or the STR message delivery fails, end service with the user and don't try again 💀
TRY_AGAIN1
if either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present 🔁
ALLOW_SERVICE2
if re-auth message delivery fails, assume re-authorization succeeded 🌸. If STR message delivery fails, terminate the session.
TRY_AGAIN_ALLOW_SERVICE3
if either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present 💜. If the second delivery fails for re-auth, assume re-authorization succeeded. If the second delivery fails for STR, terminate the session.
8.19. Multi-Round-Time-Out AVP ⏰
the Multi-Round-Time-Out AVP (AVP Code 272) is Unsigned32 and it SHOULD be present in application-specific authorization answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH 🌈. It holds the maximum number of seconds the access device MUST give the user to respond to an authentication request ⭐.
8.20. Class AVP 🎀
the Class AVP (AVP Code 25) is OctetString and Diameter servers use it to send state information back to the access device 🫧. When one or more Class AVPs show up in application-specific authorization answer messages, they MUST be present in later re-authorization, session termination and accounting messages 👑. Class AVPs in a re-authorization answer message override the ones from any earlier authorization answer message 🔥. Diameter server implementations SHOULD NOT send back Class AVPs that need more than 4096 bytes of storage on the Diameter client 😭. And if a Diameter client gets Class AVPs bigger than its local storage can handle, it MUST terminate the session 💀.
8.21. Event-Timestamp AVP ⌚
the Event-Timestamp (AVP Code 55) is Time and it MAY be included in Accounting-Request and Accounting-Answer messages to record when the reported event happened, in seconds since January 1, 1900 00:00 UTC 🍓.
9. Accounting ✨
okay this accounting protocol is a server directed model with real-time delivery of accounting info, which is so iconic 💅. It has a bunch of fault resilience methods [RFC2975] built in to keep accounting data loss low in different fault situations and under different assumptions about what the devices can do 🫶.
9.1. Server Directed Model 🧭
in the server directed model, the device generating the accounting data gets info from the authorization server (if it's contacted) or the accounting server about how accounting data shall be forwarded 🦋. That info includes accounting record timeliness requirements ⏱️.
as [RFC2975] talks about, real-time transfer of accounting records is a requirement, because things like credit-limit checks and fraud detection need it 🔥. Batch accounting is NOT a requirement, so Diameter doesn't support it 🙈. If batched accounting is needed later, a new Diameter application will need to be created, or it could be handled with another protocol. But even at the Diameter layer, accounting requests are processed one by one, though transport protocols used under Diameter typically batch several requests in the same packet under heavy traffic 🌸. This may be enough for lots of applications ✨.
the authorization server (chain) decides the right transfer strategy, based on what it knows about the user and roaming partnerships 👑. The server (or agents) uses the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to control how the Diameter peer acting as a client operates 🎀. When it's present, the Acct-Interim-Interval AVP tells the Diameter node acting as a client to produce accounting records continuously, even during a session ⏳. The Accounting-Realtime-Required AVP controls how the client behaves when transfer of accounting records from it is delayed or unsuccessful 💜.
The Diameter accounting server MAY override the interim interval or the real-time requirements by including the Acct-Interim-Interval or Accounting-Realtime-Required AVP in the Accounting-Answer message 🦄. When one of these AVPs is present, the latest value received SHOULD be used for further accounting activities in the same session 💖.
9.2. Protocol Messages 📨
a Diameter node that gets a successful authentication and/or authorization message from the Diameter server SHOULD collect accounting info for the session 🫶. The Accounting-Request message sends that accounting info to the Diameter server, which MUST reply with the Accounting-Answer message to confirm it got it 💌. The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that there was an error in the accounting message 😭. The value of the Accounting-Realtime-Required AVP received earlier for the session in question may indicate that the user's session has to be terminated when a rejected Accounting-Request message was received 💀.
9.3. Accounting Application Extension and Requirements 🧩
each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message, in a section titled "Accounting AVPs" 📝. The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so it only needs to define its own service-specific AVPs in that section 🌈.
applications can use one or both of these accounting application extension models 👑:
- Split Accounting Service
the accounting message carries the Application Id of the Diameter base accounting application (see Section 2.4) 🍓. Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. Those nodes might be centralized accounting servers that serve multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange 📢.
- Coupled Accounting Service
the accounting message carries the Application Id of the application that's using it 🫧. The application itself processes the received accounting records or forwards them to an accounting server. No accounting application advertisement is required during capabilities exchange, and accounting messages get routed the same way as any other application messages ✨.
when an application doesn't define its own accounting service, the split accounting model is preferred 🌸.
9.4. Fault Resilience 🛡️
Diameter base protocol mechanisms are used to get past small message loss and temporary network faults 🦋.
Diameter peers acting as clients MUST implement failover to guard against server failures and certain network failures 🔁. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by sending the same record to several servers, and duplicated messages in transit 👀. This detection MUST be based on inspecting the Session-Id and Accounting-Record-Number AVP pairs 💅. Appendix C talks about duplicate detection needs and implementation issues 📚.
Diameter clients MAY have non-volatile memory to safely store accounting records across reboots, extended network failures, network partitions, and server failures 💾. If that memory is available, the client SHOULD store new accounting records there as soon as they're created, and keep them until it gets a positive acknowledgement of their reception from the Diameter server 🫶. After a reboot, the client MUST start sending the records in non-volatile memory to the accounting server, with the appropriate changes to termination cause, session length, and other relevant info in the records 🔄.
a future application of this protocol may include AVPs to control the maximum number of accounting records that can be stored in the Diameter client without being committed to non-volatile memory or transferred to the Diameter server 🧠.
The client SHOULD NOT remove accounting data from any of its memory areas before the correct Accounting-Answer has been received 🙅♀️. The client MAY remove the oldest, undelivered, or still-unacknowledged accounting data if it runs out of resources such as memory 🗑️. Whether the client accepts new sessions under this condition is an implementation-dependent matter 🤷♀️.
9.5. Accounting Records 📜✨
Okay bestie, for every accounting record the Session-Id AVP MUST be present 💖, and the User-Name AVP MUST be present if the Diameter client has it available 🫶.
The kind of record you send depends on two things: what type of service is being accounted, and what the authorization server said about interim accounting ✨. If the accounted service is a one-time event (the start and stop happen at the exact same moment), then the Accounting-Record-Type AVP MUST be present and set to the value EVENT_RECORD 🎀.
If the service has a measurable length, the AVP MUST use the values START_RECORD, STOP_RECORD, and possibly, INTERIM_RECORD 🦋. If the authorization server has not directed interim accounting for the session, two accounting records MUST be generated for each service of type session 🌸. The very first Accounting-Request for a given session has the Accounting-Record-Type AVP MUST be set to the value START_RECORD 🚀. When the last Accounting-Request goes out, the value MUST be STOP_RECORD 🏁.
If the authorization server has turned on interim accounting, the Diameter client MUST produce additional records between the START_RECORD and STOP_RECORD, marked INTERIM_RECORD 💅. Those records are driven by Acct-Interim-Interval, plus any re-authentication or re-authorization of the session 🔥. The Diameter client MUST overwrite any previous interim accounting records that are stored locally for delivery, if a new record is being generated for the same session 🧹. That way, only one pending interim record can exist on an access device for any given session 💜.
A particular value of Accounting-Sub-Session-Id MUST appear only in one sequence of accounting records from a Diameter client, except for retransmission purposes 🔁. The one sequence that is sent MUST be either one record with the Accounting-Record-Type AVP set to EVENT_RECORD, or several records starting with one that has the value START_RECORD, followed by zero or more INTERIM_RECORDs and a single STOP_RECORD ✨. A particular Diameter application specification MUST define the type of sequences that MUST be used 📚.
9.6. Correlation of Accounting Records 🔗
If an app sends accounting messages, it can tie accounting records to a specific application session by using that session's Session-Id in the accounting messages 🧩. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case other session-related information is needed to do the correlation 🤔.
When an application needs multiple accounting sub-sessions, the Accounting-Sub-Session-Id AVP tells each one apart 🍰. The Session-Id stays constant across all the sub-sessions, so it's what links every sub-session back to one application session 💕. Heads up: receiving a STOP_RECORD with no Accounting-Sub-Session-Id AVP, when sub-sessions were used in the START_RECORD messages, means all sub-sessions are terminated 🛑.
Sometimes an application needs to squish multiple application sessions into a single accounting record. That record can span different Diameter applications and sessions used by the same user at a given time 🌈. For that, the Acct-Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD be signaled by the server to the access device (typically, during authorization) when it determines that a request belongs to an existing session 📡. The access device MUST then include the Acct-Multi-Session-Id AVP in all subsequent accounting messages 📨.
The Acct-Multi-Session-Id AVP MAY include the value of the original Session-Id 🪄. Its contents are implementation specific, but the MUST be globally unique across other Acct-Multi-Session-Ids and MUST NOT change during the life of a session 🔐.
A Diameter application document MUST define the exact concept of a session that is being accounted, and it MAY define the concept of a multi-session 📖. For instance, the NASREQ DIAMETER application treats a single PPP connection to a Network Access Server as one session, and a set of Multilink PPP sessions as one multi-session 💜.
9.7. Accounting Command Codes 🧾
This section defines Command Code values that MUST be supported by all Diameter implementations that provide accounting services 👑.
9.7.1. Accounting-Request 📨
The Accounting-Request (ACR) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit set, is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer 💌.
On top of the AVPs listed below, Accounting-Request messages SHOULD include service-specific accounting AVPs 🎀.
Message Format
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Destination-Host ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]9.7.2. Accounting-Answer 🙋
The Accounting-Answer (ACA) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit cleared, is used to acknowledge an Accounting-Request command. The Accounting-Answer command contains the same Session-Id as the corresponding request 💫.
Only the target Diameter server, known as the home Diameter server, SHOULD respond with the Accounting-Answer command 🏠.
On top of the AVPs listed below, Accounting-Answer messages SHOULD include service-specific accounting AVPs ✨.
Message Format
<ACA> ::= < Diameter Header: 271, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ AVP ]9.8. Accounting AVPs 💎
This section contains AVPs that describe accounting usage information related to a specific session 🧃.
9.8.1. Accounting-Record-Type AVP 🏷️
The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated and contains the type of accounting record being sent. The following values are currently defined for the Accounting-Record-Type AVP:
EVENT_RECORD 1
An Accounting Event Record is used to indicate that a one-time event has occurred (meaning that the start and end of the event are simultaneous). This record contains all information relevant to the service, and it is the only record of the service 🎯.
START_RECORD 2
Accounting Start, Interim, and Stop Records are used to indicate that a service of a measurable length has been given. An Accounting Start Record is used to initiate an accounting session and contains accounting information that is relevant to the initiation of the session 🚦.
INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting information for an existing accounting session. Interim Accounting Records SHOULD be sent every time a re-authentication or re-authorization occurs. Further, additional interim record triggers MAY be defined by application-specific Diameter applications. The selection of whether to use INTERIM_RECORD records is done by the Acct-Interim-Interval AVP ⏰.
STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting session and contains cumulative accounting information relevant to the existing session 🛑.
9.8.2. Acct-Interim-Interval AVP ⏱️
The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide how and when to produce accounting records. With different values in this AVP, service sessions can result in one, two, or two+N accounting records, based on the needs of the home organization. The following accounting record production behavior is directed by the inclusion of this AVP:
- The omission of the Acct-Interim-Interval AVP or its inclusion with Value field set to 0 means that EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as appropriate for the service.
- The inclusion of the AVP with Value field set to a non-zero value means that INTERIM_RECORD records MUST be produced between the START_RECORD and STOP_RECORD records. The Value field of this AVP is the nominal interval between these records in seconds. The Diameter node that originates the accounting information, known as the client, MUST produce the first INTERIM_RECORD record roughly at the time when this nominal interval has elapsed from the START_RECORD, the next one again as the interval has elapsed once more, and so on until the session ends and a STOP_RECORD record is produced.
The client MUST ensure that the interim record production times are randomized so that large accounting message storms are not created either among records or around a common service start time 🌪️🚫.
9.8.3. Accounting-Record-Number AVP 🔢
The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting-Record-Number AVPs is also globally unique and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD 🧮.
9.8.4. Acct-Session-Id AVP 🪪
The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only used when RADIUS/Diameter translation occurs. This AVP contains the contents of the RADIUS Acct-Session-Id attribute 🌉.
9.8.5. Acct-Multi-Session-Id AVP 🦋
okay so the Acct-Multi-Session-Id AVP (AVP Code 50) is a UTF8String that follows the format from Section 8.8 💅 it's how you link a bunch of related accounting sessions together. each session still gets its own unique Session-Id, but they all share the same Acct-Multi-Session-Id 🔗 the Diameter server MAY send it back in an authorization answer, and every accounting message for that session MUST use it. no cap, non-negotiable 🫶
9.8.6. Accounting-Sub-Session-Id AVP 🌸
the Accounting-Sub-Session-Id AVP (AVP Code 287) is an Unsigned64 that holds the accounting sub-session identifier ✨ the combo of Session-Id plus this AVP MUST be unique for each sub-session, and the value MUST go up by exactly one for every new sub-session. bestie, that's the rule 📈
if the AVP isn't there, it means no sub-sessions are in use, except for an Accounting-Request whose Accounting-Record-Type is set to STOP_RECORD 🙈 a STOP_RECORD message with no Accounting-Sub-Session-Id AVP present is the signal that ends all sub-sessions for that Session-Id 💀
9.8.7. Accounting-Realtime-Required AVP 👑
the Accounting-Realtime-Required AVP (AVP Code 483) is an Enumerated, and it gets sent from the Diameter home authorization server to the Diameter client, or inside the Accounting-Answer from the accounting server 💖 the client looks at it to decide what to do when sending accounting records has been temporarily blocked, like because of a network problem 🌈
DELIVER_AND_GRANT(1): with this value, the service MUST only be granted as long as there's a connection to an accounting server 🔥 all the alternative accounting servers count as one server here. moving the record stream over to a backup server is NOT a reason to cut off the user's service, periodt 💅GRANT_AND_STORE(2): with this value, service SHOULD be granted if there's a connection, or as long as records can still be stored as described in Section 9.4 ✨ this is also the default if the AVP isn't in the reply from the authorization server 🧚GRANT_AND_LOSE(3): with this value, service SHOULD be granted even if the records can't be delivered or stored 😭 it's giving "the show must go on" energy 🎀
10. AVP Occurrence Tables 📋
the next bit lists the AVPs defined in this document and says which Diameter messages they MAY or MAY NOT show up in 🦋 AVPs that only live inside a Grouped AVP aren't in these tables, so don't go looking 🙈
the tables use these symbols:
0: the AVP MUST NOT be present in the message 🚫0+: zero or more instances of the AVP MAY be present in the message 🍓0-1: zero or one instance of the AVP MAY be present in the message. it's an error if there's more than one instance 🫣1: one instance of the AVP MUST be present in the message 💜1+: at least one instance of the AVP MUST be present in the message 💖
10.1. Base Protocol Command AVP Table 🧁
this table only covers the non-Accounting Command Codes defined in this spec 🌷
+-----------------------------------------------+
| Command Code |
+---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+
Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Interval | | | | | | | | | | | | |
Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Required | | | | | | | | | | | | |
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Lifetime | | | | | | | | | | | | |
Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Failed-AVP |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-State-Id |0-1|0-1|0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Time | | | | | | | | | | | | |
Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Failover | | | | | | | | | | | | |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Application-Id | | | | | | | | | | | | |
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+10.2. Accounting AVP Table 🧾
this table shows which AVPs from this document should be in the Accounting messages 🌈 these occurrence requirements are guidelines, which may be expanded, and/or overridden by application-specific requirements in the Diameter applications documents ✨
+-----------+
| Command |
| Code |
+-----+-----+
Attribute Name | ACR | ACA |
------------------------------+-----+-----+
Acct-Interim-Interval | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Accounting-Record-Number | 1 | 1 |
Accounting-Record-Type | 1 | 1 |
Acct-Session-Id | 0-1 | 0-1 |
Accounting-Sub-Session-Id | 0-1 | 0-1 |
Accounting-Realtime-Required | 0-1 | 0-1 |
Acct-Application-Id | 0-1 | 0-1 |
Auth-Application-Id | 0 | 0 |
Class | 0+ | 0+ |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0-1 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0 |
Result-Code | 0 | 1 |
Session-Id | 1 | 1 |
Termination-Cause | 0 | 0 |
User-Name | 0-1 | 0-1 |
Vendor-Specific-Application-Id| 0-1 | 0-1 |
------------------------------+-----+-----+11. IANA Considerations 🎀
this section gives IANA (the Internet Assigned Numbers Authority) guidance on registering values for the Diameter protocol, in accordance with [RFC5226] 💖 the existing IANA registries and assignments from RFC 3588 stay the same, unless this section explicitly updates or deprecates them 📚
11.1. AVP Header 🫧
as defined in Section 4, the AVP header has three fields that need IANA namespace management: the AVP Code, Vendor-ID, and Flags fields 🔐
11.1.1. AVP Codes 🔢
there are multiple namespaces 🌍 vendors can have their own AVP Codes namespace, identified by their Vendor-ID (also known as Enterprise-Number), and they control the assignments of their vendor-specific AVP Codes inside that namespace 💅 no Vendor-ID, or a Vendor-ID of zero (0), means the IETF AVP Codes namespace, which is under IANA control 👑 the AVP Codes, and sometimes the possible values inside an AVP, are controlled and maintained by IANA. AVP Code 0 is not used 🙈 AVP Codes 1-255 are managed separately as RADIUS Attribute Types 🧚 where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead 🌸
AVPs may be allocated following Expert Review (by a Designated Expert) with Specification Required [RFC5226] ✨ a block allocation (release of more than three AVPs at a time for a given purpose) requires IETF Review [RFC5226] 🫶
11.1.2. AVP Flags 🚩
Section 4.1 describes the existing AVP Flags 💜 the remaining bits can only be assigned via a Standards Action [RFC5226] 🔥
11.2. Diameter Header 🌈
11.2.1. Command Codes
okay so the Command Code namespace in the Diameter header got a whole glow-up 💅✨ here are the new allocation rules:
The Command Code values 256 - 8,388,607 (0x100 to 0x7fffff) are for permanent, standard commands, allocated by IETF Review [RFC5226].
The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific Command Codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific Command Code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command. the vibe is "show your receipts, bestie" 🧾🫶
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands. 🧪🙈
11.2.2. Command Flags
Section 3 describes the existing Command Flags field. The remaining bits can only be assigned via a Standards Action [RFC5226]. ngl the leftover bits are super guarded 🔒🦋
11.3. AVP Values
okay AVP values time 🎀 the Experimental-Result-Code AVP value allocation has been added, so check out Section 11.3.1. The old AVP value allocation rule, IETF Consensus, has been updated to IETF Review as per [RFC5226], and the affected AVPs are listed as reminders. a glow-up with receipts 💖
11.3.1. Experimental-Result-Code AVP
Values for this AVP are purely local to the indicated vendor, and no IANA registry is maintained for them. it's a vendor-only secret club, iykyk 🤫🌸
11.3.2. Result-Code AVP Values
New values are available for assignment via IETF Review [RFC5226]. ✨
11.3.3. Accounting-Record-Type AVP Values
New values are available for assignment via IETF Review [RFC5226]. 📒
11.3.4. Termination-Cause AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🛑
11.3.5. Redirect-Host-Usage AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🧭
11.3.6. Session-Server-Failover AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🔁
11.3.7. Session-Binding AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🔗
11.3.8. Disconnect-Cause AVP Values
New values are available for assignment via IETF Review [RFC5226]. 👋
11.3.9. Auth-Request-Type AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🔑
11.3.10. Auth-Session-State AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🧠
11.3.11. Re-Auth-Request-Type AVP Values
New values are available for assignment via IETF Review [RFC5226]. 🔄
11.3.12. Accounting-Realtime-Required AVP Values
New values are available for assignment via IETF Review [RFC5226]. ⏱️
11.3.13. Inband-Security-Id AVP (code 299)
The use of this AVP has been deprecated. 💀 so we don't use this one anymore, periodt
11.4. _diameters Service Name and Port Number Registration
IANA has registered the "_diameters" service name and assigned port numbers for TLS/TCP and DTLS/SCTP according to the guidelines given in [RFC6335]. main character registration energy 📝👑
Service Name: _diameters
Transport Protocols: TCP, SCTP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Diameter over TLS/TCP and DTLS/SCTP
Reference: RFC 6733
Port Number: 5868, from the User Range11.5. SCTP Payload Protocol Identifiers
Two SCTP payload protocol identifiers have been registered in the SCTP Payload Protocol Identifiers registry: 46 and 47, both Diameter 🎉
Value | SCTP Payload Protocol Identifier
-------|-----------------------------------
46 | Diameter in a SCTP DATA chunk
47 | Diameter in a DTLS/SCTP DATA chunk11.6. S-NAPTR Parameters
The following tag has been registered in the S-NAPTR Application Protocol Tags registry: 🏷️
Tag | Protocol
-------------------|---------
diameter.dtls.sctp | DTLS/SCTP12. Diameter Protocol-Related Configurable Parameters
okay, the configurable parameters, all in one place 🧁 this section lists the ones that show up throughout this document:
Diameter Peer
A Diameter entity MAY communicate with peers that are statically configured. A statically configured Diameter peer would require that either the IP address or the fully qualified domain name (FQDN) be supplied, which would then be used to resolve through DNS. 🗺️
Routing Table
A Diameter proxy server routes messages based on the realm portion of a Network Access Identifier (NAI). The server MUST have a table of Realm Names, and the address of the peer to which the message must be forwarded. The routing table MAY also include a "default route", which is typically used for all messages that cannot be locally processed. the routing table is basically the group chat contact list 📇💜
Tc timer
The Tc timer controls the frequency that transport connection attempts are done to a peer with whom no active transport connection exists. The recommended value is 30 seconds. ⏲️✨
13. Security Considerations
ok, this part is SERIOUS and I'm not playing with it 🚨 the full security stuff, no shortcuts:
The Diameter base protocol messages SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms such as IPsec [RFC4301] MAY also be deployed to secure connections between peers. However, all Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP, and the Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec. 🔐😭
If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior to any Diameter message exchange. All security parameters for TLS/TCP and DTLS/SCTP or IPsec are configured independent of the Diameter protocol. All Diameter messages will be sent through the TLS/TCP and DTLS/SCTP or IPsec connection after a successful setup. the setup comes first, then the messages, always 🛡️
For TLS/TCP and DTLS/SCTP connections to be established in the open state, the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP handshake will begin when both ends successfully reach the open state, after completion of the CER/CEA exchange. If the TLS/TCP and DTLS/SCTP handshake is successful, all further messages will be sent via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST move to the closed state. See Section 13.1 for more details. no handshake, no vibes 🤝💀
13.1. TLS/TCP and DTLS/SCTP Usage
Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually authenticate as part of TLS/TCP and DTLS/SCTP session establishment. In order to ensure mutual authentication, the Diameter node acting as the TLS/TCP and DTLS/SCTP server MUST request a certificate from the Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to supply a certificate on request. both sides have to show their ID at the door 🪪✨
Diameter nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suites:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHADiameter nodes SHOULD be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suite:
TLS_RSA_WITH_AES_128_CBC_SHANote that it is quite possible that support for the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/SCTP cipher suites. 🔮
If public key certificates are used for Diameter security (for example, with TLS), the value of the expiration times in the routing and peer tables MUST NOT be greater than the expiry time in the relevant certificates. don't let your tables outlive your certs, that's just rude 📅🫠
13.2. Peer-to-Peer Considerations
As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. With certificate authentication, Diameter peers may not be known beforehand and therefore peer discovery may be required. 🤝🔍 trust is a whole vibe, bestie, you can't just let anyone in
13.3. AVP Considerations
Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive:
- Acct-Interim-Interval
- Accounting-Realtime-Required
- Acct-Multi-Session-Id
- Accounting-Record-Number
- Accounting-Record-Type
- Accounting-Session-Id
- Accounting-Sub-Session-Id
- Class
- Session-Id
- Session-Binding
- Session-Server-Failover
- User-Name
Diameter messages containing these or any other AVPs considered to be security-sensitive MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document. 🚫📨 sensitive stuff stays in the secure lane, always, no exceptions 😤💖
14. References
14.1. Normative References ✨
okay bestie, these are the foundations you literally need to have read before the rest of the doc makes sense 📚🎀
[FLOATPOINT]Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985", August 1985.[IANAADFAM]IANA, "Address Family Numbers",http://www.iana.org/assignments/address-family-numbers.[RFC0791]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.[RFC0793]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3492]Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.[RFC3539]Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC3958]Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RFC4004]Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.[RFC4005]Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.[RFC4006]Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.[RFC4086]Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.[RFC4282]Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.[RFC4291]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.[RFC4960]Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[RFC5234]Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC5280]Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.[RFC5729]Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.[RFC5890]Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.[RFC5891]Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.[RFC6083]Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.[RFC6347]Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.[RFC6408]Jones, M., Korhonen, J., and L. Morand, "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage", RFC 6408, November 2011.
14.2. Informative References 🦋
these ones are the bonus reading, the context and the backstory that makes everything click 💅
[ENTERPRISE]IANA, "SMI Network Management Private Enterprise Codes",http://www.iana.org/assignments/enterprise-numbers.[IANATCV]IANA, "Termination-Cause AVP Values (code 295)",http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-16.[RFC1492]Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.[RFC1661]Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.[RFC2104]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[RFC2782]Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.[RFC2865]Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.[RFC2866]Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.[RFC2869]Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.[RFC2881]Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.[RFC2975]Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.[RFC2989]Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.[RFC3162]Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.[RFC3748]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[RFC4690]Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.[RFC5176]Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.[RFC5461]Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.[RFC5905]Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.[RFC5927]Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.[RFC6335]Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.[RFC6737]Kang, J. and G. Zorn, "The Diameter Capabilities Update Application", RFC 6737, October 2012.
Appendix A. Acknowledgements 🌸
A.1. This Document
the authors wanted to give a shoutout to everyone who threw in proposals and contributions to this doc, and honestly the list is iconic 🫶
To Vishnu Ram and Satendra Gera for their contributions on capabilities updates, predictive loop avoidance, as well as many other technical proposals. To Tolga Asveren for his insights and contributions on almost all of the proposed solutions incorporated into this document. To Timothy Smith for helping on the capabilities Update and other topics. To Tony Zhang for providing fixes to loopholes on composing Failed-AVPs as well as many other issues and topics. To Jan Nordqvist for clearly stating the usage of Application Ids. To Anders Kristensen for providing needed technical opinions. To David Frascone for providing invaluable review of the document. To Mark Jones for providing clarifying text on vendor command codes and other vendor-specific indicators. To Victor Pascual and Sebastien Decugis for new text and recommendations on SCTP/DTLS. To Jouni Korhonen for taking over the editing task and resolving last bits from versions 27 through 29.
special thanks to the Diameter extensibility design team, who helped crack the tricky question of mandatory AVPs and ABNF semantics 🧚 the members of that team are:
Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga Asveren, Jouni Korhonen, and Glenn McGregor.
also big thanks to the people who gave invaluable comments and inputs, especially on the controversial issues 💜
Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick, Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry Leiba, and Pasi Eronen.
and finally, the original authors of this document, who deserve all the flowers 🌷
Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn.
their invaluable knowledge and experience gave us a robust and flexible AAA protocol that so many people have seen great value in adopting. the authors are so grateful for their support and stewardship over the continued improvements of Diameter as a protocol. we also want to extend our gratitude to everyone aside from the authors who helped and contributed to the original version of this document. their efforts significantly contributed to the success of Diameter 👑✨
A.2. RFC 3588 🌸
Okay bestie, we have to thank the people who made this happen 🫶. Nenad Trifunovic, Tony Johansson and Pankaj Patel joined the pre-IETF Document Reading Party. Allison Mankin, Jonathan Wood, and Bernard Aboba were a huge help with the transport issues, and Steven Bellovin helped out in the security area too. The whole thing was honestly iconic.
Paul Funk and David Mitton are the reason the Peer State Machine is correct, and the authors are so grateful for their time 💜.
Text in this document was also written by Paul Funk, Mark Eklund, Mark Jones, and Dave Spence. Jacques Caron gave a ton of amazing comments after a super thorough review of the spec ✨.
The authors also want to shout out everyone who helped build the Diameter protocol 🎀:
Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
And finally, Pat Calhoun wants to thank Sun Microsystems 🌈, because most of the work on this document happened while he was working there.
Appendix B. S-NAPTR Example 🧚
Let's walk through an example 💅. Say a client wants to resolve aaa:ex1.example.com. It runs a NAPTR query for that domain and gets these NAPTR records back:
;; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" ""
_diameter._tls.ex1.example.com
IN NAPTR 100 50 "s" "aaa:diameter.tcp" ""
_aaa._tcp.ex1.example.com
IN NAPTR 150 50 "s" "aaa:diameter.sctp" ""
_diameter._sctp.ex1.example.comSo the server supports TLS, TCP, and SCTP, in that order 🦋. If the client supports TLS, then TLS gets used, aimed at a host found with an SRV lookup of _diameter._tls.ex1.example.com. That lookup would return:
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.ex1.example.com
IN SRV 0 2 5060 server2.ex1.example.comNow here's a different one 👑. Say a client wants to resolve aaa:ex2.example.com. It runs a NAPTR query and gets these back:
;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server2.ex2.example.comThis means the server supports TCP at the host names that came back 🍓.
Appendix C. Duplicate Detection 💀
Okay, so Section 9.4 covers accounting record duplicate detection, and it's all based on session identifiers. Duplicates can show up for a bunch of different reasons 🙈:
- Failover to an alternate server. When you need close to real-time performance, failover thresholds have to be kept low. That can make duplicates more likely. Failover can happen at the client or inside Diameter agents.
- A client or agent fails after sending a record out of non-volatile memory, but before it gets an application-layer ACK and deletes the record that was sent. This results in retransmission of the record soon after the client or agent has rebooted.
- Duplicates received from RADIUS gateways. Because the retransmission behavior of RADIUS is not defined within [RFC2865], how likely duplication is depends on the implementation.
- Implementation problems and misconfiguration.
The T flag is an indication of an application-layer retransmission event, like when there's been a failover to an alternate server ✨. It's only defined for request messages sent by Diameter clients or agents. For example, after a reboot, a client might not know whether it already tried to send the accounting records sitting in its non-volatile memory before the reboot happened. Diameter servers MAY use the T flag as a helper when they process requests and detect duplicate messages 💖. But servers that do this MUST make sure duplicates are still found even when the first transmitted request reaches the server after the retransmitted one. The T flag can only be used when no answer has come back from the server for a request and that request is sent again. That can happen with a failover to an alternate peer, with a recovered primary peer, or when a client re-sends a stored record from non-volatile memory after a client or agent reboot.
Sometimes the Diameter accounting server can hold off on duplicate detection and accounting record processing until a post-processing phase happens 🧁. At that point, records are likely sorted by the included User-Name, so eliminating duplicates is easy. Other times you might need real-time duplicate detection, like when credit limits are imposed or when real-time fraud detection is wanted 🚨.
Generally speaking, only duplicates caused by failover or by re-sending records from non-volatile storage can be reliably detected by Diameter clients or agents 🌷. In those cases, the Diameter client or agent can mark the message as a possible duplicate by setting the T flag. The Diameter server is the one responsible for duplicate detection, so it can decide whether or not to use the T flag to optimize duplicate detection. The T flag doesn't affect interoperability, and some servers might not need it at all. So generation of the T flag is REQUIRED for Diameter clients and agents, but it MAY be implemented by Diameter servers 💅.
For an example, duplicates can usually be assumed to appear within a time window of the longest recorded network partition or device fault, which is maybe a day 🕰️. So only records inside this time window need to be looked at going backward. Also, hashing techniques or other schemes, like using the T flag in received messages, can be used to skip the need for a full search even inside this set, except in rare cases 🔍.
Here's an example of how a server might use the T flag to detect duplicate requests 🎀:
A Diameter server MAY check the T flag of the received message to
determine if the record is a possible duplicate. If the T flag is
set in the request message, the server searches for a duplicate
within a configurable duplication time window backward and
forward. This limits database searching to those records where
the T flag is set. In a well-run network, network partitions and
device faults will presumably be rare events, so this approach
represents a substantial optimization of the duplicate detection
process. During failover, it is possible for the original record
to be received after the T-flag-marked record, due to differences
in network delays experienced along the path by the original and
duplicate transmissions. The likelihood of this occurring
increases as the failover interval is decreased. In order to be
able to detect duplicates that are out of order, the Diameter
server should use backward and forward time windows when
performing duplicate checking for the T-flag-marked request. For
example, in order to allow time for the original record to exit
the network and be recorded by the accounting server, the Diameter
server can delay processing records with the T flag set until a
time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after
the closing of the original transport connection. After this time
period, it may check the T-flag-marked records against the
database with relative assurance that the original records, if
sent, have been received and recorded.Appendix D. Internationalized Domain Names 🌈
Here's the deal: to stay compatible with the existing DNS infrastructure and make host and domain name comparison simple, Diameter identities (FQDNs) are represented in ASCII form ✨. That lets the Diameter protocol match the DNS approach of being transparent to the effects of Internationalized Domain Names (IDNs), by following the recommendations in [RFC4690] and [RFC5890]. Applications that support IDNs outside of the Diameter protocol, but still interact with it, SHOULD use the representation and conversion framework described in [RFC5890], [RFC5891], and [RFC3492] 🦋.
Authors' Addresses 💖
Victor Fajardo (editor)
Telcordia Technologies
One Telcordia Drive, 1S-222
Piscataway, NJ 08854
USA
Phone: +1-908-421-1845
EMail: vf0213@gmail.com
Jari Arkko
Ericsson Research
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
John Loughney
Nokia Research Center
955 Page Mill Road
Palo Alto, CA 94304
US
Phone: +1-650-283-8068
EMail: john.loughney@nokia.com
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-0404617
EMail: glenzorn@gmail.comAnd that's a wrap on RFC 6733! 🎉 Diameter is seriously the protocol that never stops being iconic 👑🌸
📦 where this page comes from
- ietf: rfc6733 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms