aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/standard/rfc6733.txt
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2012-11-23 15:43:37 +0100
committerAnders Svensson <[email protected]>2012-11-23 15:43:37 +0100
commitd8d53aefc3234a37ad9308949d122c265f90cca9 (patch)
treeafbaed05738399b660fa967c88bb9ae8c67a4c2d /lib/diameter/doc/standard/rfc6733.txt
parent744c5e4232fd010c6630831a6b15ecd19ec7ac80 (diff)
parent2810e848c24d93b2292a08f2df0293166cf32ee6 (diff)
downloadotp-d8d53aefc3234a37ad9308949d122c265f90cca9.tar.gz
otp-d8d53aefc3234a37ad9308949d122c265f90cca9.tar.bz2
otp-d8d53aefc3234a37ad9308949d122c265f90cca9.zip
Merge branch 'anders/diameter/doc/OTP-10568' into maint
* anders/diameter/doc/OTP-10568: Update doc for RFC 6733 Add copies of RFC's 6733 and 6737
Diffstat (limited to 'lib/diameter/doc/standard/rfc6733.txt')
-rw-r--r--lib/diameter/doc/standard/rfc6733.txt8515
1 files changed, 8515 insertions, 0 deletions
diff --git a/lib/diameter/doc/standard/rfc6733.txt b/lib/diameter/doc/standard/rfc6733.txt
new file mode 100644
index 0000000000..2f5a477347
--- /dev/null
+++ b/lib/diameter/doc/standard/rfc6733.txt
@@ -0,0 +1,8515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) V. Fajardo, Ed.
+Request for Comments: 6733 Telcordia Technologies
+Obsoletes: 3588, 5719 J. Arkko
+Category: Standards Track Ericsson Research
+ISSN: 2070-1721 J. Loughney
+ Nokia Research Center
+ G. Zorn, Ed.
+ Network Zen
+ October 2012
+
+
+ Diameter Base Protocol
+
+Abstract
+
+ The Diameter base protocol is intended to provide an Authentication,
+ Authorization, and Accounting (AAA) framework for applications such
+ as network access or IP mobility in both local and roaming
+ situations. This document specifies the message format, transport,
+ error reporting, accounting, and security services used by all
+ Diameter applications. The Diameter base protocol as defined in this
+ document obsoletes RFC 3588 and RFC 5719, and it must be supported by
+ all new Diameter implementations.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6733.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 1]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, 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, except to format
+ it for publication as an RFC or to translate 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
+
+
+
+Fajardo, et al. Standards Track [Page 2]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 ...............................74
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 3]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 4]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 5]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 .......................151
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 6]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+1. Introduction
+
+ Authentication, Authorization, and Accounting (AAA) protocols such as
+ TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
+ provide dial-up PPP [RFC1661] and terminal server access. Over time,
+ AAA support was needed on many new access technologies, the scale and
+ complexity of AAA networks grew, and AAA was also used on new
+ applications (such as voice over IP). This led to new demands on AAA
+ protocols.
+
+ Network access requirements for AAA protocols are summarized in
+ Aboba, et al. [RFC2989]. These include:
+
+ Failover
+
+ [RFC2865] does not define failover mechanisms and, as a result,
+ failover behavior differs between implementations. In order to
+ provide 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. While [RFC2869] defines an additional authentication and
+ integrity mechanism, use is only required during Extensible
+ Authentication Protocol (EAP) [RFC3748] sessions. While attribute
+ hiding is supported, [RFC2865] does not provide support for per-
+ packet confidentiality. In accounting, [RFC2866] assumes that
+ replay protection is provided by the backend billing server rather
+ than within the protocol itself.
+
+ While [RFC3162] defines the use of IPsec with RADIUS, support for
+ IPsec is not required. In order to provide universal support for
+ transmission-level security, and enable both intra- and inter-
+ domain AAA deployments, Diameter provides support for TLS/TCP and
+ DTLS/SCTP. Security is discussed in Section 13.
+
+ Reliable transport
+
+ RADIUS runs over UDP, and does not define retransmission behavior;
+ as a result, reliability varies between implementations. As
+ described in [RFC2975], this is a major issue in accounting, where
+ packet loss may translate directly into revenue loss. In order to
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 7]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ provide well-defined transport behavior, Diameter runs over
+ reliable transport mechanisms (TCP, Stream Control Transmission
+ Protocol (SCTP)) as defined in [RFC3539].
+
+ Agent support
+
+ RADIUS does not provide for explicit support for agents, including
+ proxies, redirects, and relays. Since the expected behavior is
+ not defined, it varies between implementations. Diameter defines
+ agent behavior explicitly; this is described in Section 2.8.
+
+ Server-initiated messages
+
+ While server-initiated messages are defined in RADIUS [RFC5176],
+ support is optional. This makes it difficult to implement
+ features such as unsolicited disconnect or re-authentication/
+ re-authorization on demand across a heterogeneous deployment. To
+ address this issue, support for server-initiated messages is
+ mandatory in Diameter.
+
+ Transition support
+
+ While Diameter does not share a common protocol data unit (PDU)
+ with RADIUS, considerable effort has been expended in enabling
+ backward compatibility with RADIUS so that the two protocols may
+ be deployed in the same network. Initially, it is expected that
+ Diameter will be deployed within new network devices, as well as
+ within gateways enabling communication between legacy RADIUS
+ devices and Diameter agents. This capability enables Diameter
+ support to be added to legacy networks, by addition of a gateway
+ or server speaking both RADIUS and Diameter.
+
+ In addition to addressing the above requirements, Diameter also
+ provides support for the following:
+
+ Capability negotiation
+
+ RADIUS does not support error messages, capability negotiation, or
+ a mandatory/non-mandatory flag for attributes. Since RADIUS
+ clients and servers are not aware of each other's capabilities,
+ they may not be able to successfully negotiate a mutually
+ acceptable service or, in some cases, even be aware of what
+ service has been implemented. Diameter includes support for error
+ handling (Section 7), capability negotiation (Section 5.3), and
+ mandatory/non-mandatory Attribute-Value Pairs (AVPs)
+ (Section 4.1).
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 8]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Peer discovery and configuration
+
+ RADIUS implementations typically require that the name or address
+ of servers or clients be manually configured, along with the
+ corresponding shared secrets. This results in a large
+ administrative burden and creates the temptation to reuse the
+ RADIUS shared secret, which can result in major security
+ vulnerabilities if the Request Authenticator is not 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, the capabilities of Network Access Server (NAS) devices
+ have increased substantially. As a result, while Diameter is a
+ considerably more sophisticated protocol than RADIUS, it remains
+ feasible to implement it within embedded devices.
+
+1.1. Diameter Protocol
+
+ The Diameter base protocol provides the following facilities:
+
+ o Ability to exchange messages and deliver AVPs
+
+ o Capabilities negotiation
+
+ o Error notification
+
+ o Extensibility, required in [RFC2989], through addition of new
+ applications, commands, and AVPs
+
+ o 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 of
+ these AVP values are used by the Diameter protocol itself, while
+ others deliver data associated with particular applications that
+ employ Diameter. AVPs may be arbitrarily added to Diameter messages,
+ the only restriction being that the Command Code Format (CCF)
+ specification (Section 3.2) be satisfied. AVPs are used by the base
+ Diameter protocol to support the following required features:
+
+ o Transporting of user authentication information, for the purposes
+ of enabling the Diameter server to authenticate the user
+
+ o Transporting of service-specific authorization information,
+ between client and servers, allowing the peers to decide whether a
+ user's access request should be granted
+
+
+
+Fajardo, et al. Standards Track [Page 9]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o Exchanging resource usage information, which may be used for
+ accounting purposes, capacity planning, etc.
+
+ o Routing, relaying, proxying, and redirecting of Diameter messages
+ through a server hierarchy
+
+ The Diameter base protocol satisfies the minimum requirements for a
+ 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]. It is also possible for the base protocol to be
+ extended for use in new applications, via the addition of new
+ commands or AVPs. The initial focus of Diameter was network access
+ and accounting applications. A truly generic AAA protocol used by
+ many applications might provide functionality not provided by
+ Diameter. Therefore, it is imperative that the designers of new
+ applications understand their requirements before using Diameter.
+ See Section 1.3.4 for more information on Diameter applications.
+
+ Any node can initiate a request. 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, such as 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 does not provide local user authentication or
+ authorization services; 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.
+
+ The Diameter protocol also supports server-initiated messages, such
+ as a request to abort service to a particular user.
+
+1.1.1. Description of the Document Set
+
+ The Diameter specification consists 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. A
+ summary of the base protocol updates included in this document can be
+ found in Section 1.1.3.
+
+ This document defines the base protocol specification for AAA, which
+ includes support for accounting. There are also a myriad of
+ applications 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.
+
+
+
+Fajardo, et al. Standards Track [Page 10]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The Transport Profile document [RFC3539] discusses transport layer
+ issues that arise with AAA protocols and recommendations on how to
+ overcome these issues. 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 on how to
+ route 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].
+
+1.1.3. Changes from RFC 3588
+
+ This document obsoletes RFC 3588 but is fully backward compatible
+ with that document. The changes introduced in this document focus on
+ fixing issues that have surfaced during the implementation of
+ Diameter (RFC 3588). An overview of some the major changes are given
+ below.
+
+ o Deprecated the use of the Inband-Security AVP for negotiating
+ Transport Layer Security (TLS) [RFC5246]. It has been generally
+ considered that bootstrapping of TLS via Inband-Security AVP
+ creates certain security risks because it does not completely
+ protect the information carried in the CER/CEA (Capabilities-
+ Exchange-Request/Capabilities-Exchange-Answer). This version of
+ Diameter 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.
+
+ o Deprecated the exchange of CER/CEA messages in the open state.
+ This feature was implied in the peer state machine table of RFC
+ 3588, but it was not clearly defined anywhere else in that
+ document. 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 and thus required
+ simplification. Capabilities exchange in the open state has been
+ re-introduced in a separate specification [RFC6737], which clearly
+ defines new commands for this feature.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 11]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o 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.
+
+ o 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.
+
+ o Clarified Application Id usage. Clarify the proper use of
+ Application Id information, which can be found in multiple places
+ within a Diameter message. This 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.
+
+ o 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 the prioritization of
+ redirect routing criteria when multiple route entries are found
+ via redirects has also been added (see Section 6.13).
+
+ o Simplified Diameter peer discovery. The Diameter discovery
+ process now supports only widely used discovery schemes; the rest
+ have been deprecated (see Section 5.2 for details).
+
+ There are many other miscellaneous fixes that have been introduced in
+ this document that may not be considered significant, but they have
+ value nonetheless. Examples are removal of obsolete types, fixes to
+ the state machine, clarification of the election process, message
+ validation, 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
+
+ AAA
+
+ Authentication, Authorization, and Accounting.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 12]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ 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.
+
+ Authentication
+
+ The act of verifying the identity of an entity (subject).
+
+ Authorization
+
+ The act of determining whether a requesting entity (subject) will
+ be allowed access to a resource (object).
+
+ 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.
+
+ Command Code Format (CCF)
+
+ A modified form of ABNF used to define Diameter commands (see
+ Section 3.2).
+
+ Diameter Agent
+
+ A Diameter Agent is a Diameter node that provides relay, proxy,
+ redirect, or translation services.
+
+
+
+
+Fajardo, et al. Standards Track [Page 13]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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).
+
+ 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.
+
+ Diameter Peer
+
+ Two Diameter nodes sharing a direct TCP or SCTP transport
+ connection are called Diameter peers.
+
+ 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.
+
+ Downstream
+
+ Downstream is used to identify the direction of a particular
+ Diameter message from the home server towards the Diameter client.
+
+ Home Realm
+
+ A Home Realm is the administrative domain with which the user
+ maintains an account relationship.
+
+ Home Server
+
+ A Diameter server that serves 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 14]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 15]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+Fajardo, et al. Standards Track [Page 16]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Upstream
+
+ Upstream is used to identify the direction of a particular
+ Diameter message from the Diameter client towards the home server.
+
+ User
+
+ The entity or device requesting or using some resource, in support
+ of which a Diameter client has generated a request.
+
+1.3. Approach to Extensibility
+
+ The Diameter protocol is designed to be extensible, using several
+ mechanisms, including:
+
+ o Defining new AVP values
+
+ o Creating new AVPs
+
+ o Creating new commands
+
+ o Creating new applications
+
+
+
+
+Fajardo, et al. Standards Track [Page 17]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ From the point of view of extensibility, Diameter authentication,
+ authorization, and accounting applications are treated in the same
+ way.
+
+ 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.
+
+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.
+
+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.
+
+ 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).
+
+ 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.
+
+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.
+
+
+
+Fajardo, et al. Standards Track [Page 18]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ 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.
+
+ The IANA considerations for Command Codes are discussed in
+ Section 3.1.
+
+1.3.4. Creating New Diameter Applications
+
+ Every Diameter application specification MUST have an IANA-assigned
+ Application Id (see Section 2.4). The managed Application ID space
+ is flat, and there is no relationship between different Diameter
+ applications with respect to their Application Ids. As such, there
+ is no versioning support provided by these Application Ids
+ themselves; every Diameter application is a standalone application.
+ If the application has a relationship with other Diameter
+ applications, such a relationship is not known to Diameter.
+
+ Before describing the rules for creating new Diameter applications,
+ it is important to discuss the semantics of the AVP occurrences as
+ stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There
+ is no relationship imposed between the two; they are set
+ independently.
+
+ o The CCF indicates what AVPs are placed into a Diameter command by
+ the sender of that command. Often, since there are multiple modes
+ of protocol interactions, many of the AVPs are indicated as
+ optional.
+
+ o The M-bit allows the sender to indicate to the receiver whether or
+ not understanding the semantics of an AVP and its content is
+ mandatory. If the M-bit is set by the sender and the receiver
+ does not understand the AVP or the values carried within that AVP,
+ then a failure is generated (see Section 7).
+
+ It is the decision of the protocol designer when to develop a new
+ Diameter application rather than extending Diameter in other ways.
+ However, a new Diameter application MUST be created when one or more
+ of the following criteria are met:
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 19]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ M-bit Setting
+
+ An AVP with the M-bit in the MUST column of the AVP flag table is
+ added to an existing Command/Application. An AVP with the M-bit
+ in the MAY column of the AVP flag table is added to an existing
+ Command/Application.
+
+ Note: The M-bit setting for a given AVP is relevant to an
+ Application and each command within that application that includes
+ the AVP. That is, if an AVP appears in two commands for
+ application Foo and the M-bit settings are different in each
+ command, then there should be two AVP flag tables describing when
+ to set the M-bit.
+
+ Commands
+
+ A new command is used within the existing application because
+ either an additional command is added, an existing command has
+ been modified so that a new Command Code had to be registered, or
+ a command has been deleted.
+
+ AVP Flag bits
+
+ If an existing application changes the meaning/semantics of its
+ AVP Flags 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 without needing to define a new
+ application. Please refer to Section 11.1.1 for details.
+
+2. Protocol Overview
+
+ The base Diameter protocol concerns itself with establishing
+ connections to peers, capabilities negotiation, how messages are sent
+ and routed through peers, and how the connections are eventually torn
+ down. The base protocol also defines certain rules that apply to all
+ message exchanges between Diameter nodes.
+
+ Communication between Diameter peers begins with one peer sending a
+ message to another Diameter peer. The set of AVPs included in the
+ message is determined by a particular Diameter application. One AVP
+ that is included to reference a user's session is the Session-Id.
+
+ The initial request for authentication and/or authorization of a user
+ would include the Session-Id AVP. The Session-Id is then used in all
+ subsequent messages to identify the user's session (see Section 8 for
+
+
+
+Fajardo, et al. Standards Track [Page 20]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ more information). The communicating party may accept the request or
+ reject it by returning an answer message with the Result-Code AVP set
+ to indicate that an error occurred. The specific behavior of the
+ Diameter server or client receiving a request depends on the Diameter
+ application employed.
+
+ Session state (associated with a Session-Id) MUST be freed upon
+ receipt of the Session-Termination-Request, Session-Termination-
+ Answer, expiration of authorized service time in the Session-Timeout
+ AVP, and according to rules established in a particular Diameter
+ application.
+
+ The base Diameter protocol may be used by itself for accounting
+ applications. For authentication and authorization, it is always
+ extended for a particular application.
+
+ Diameter clients MUST support the base protocol, which includes
+ accounting. In addition, they MUST fully support each Diameter
+ application that is needed to implement the client's service, e.g.,
+ Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile
+ IPv4. A Diameter client MUST be referred to as "Diameter X Client"
+ where X is the application that it supports and not a "Diameter
+ Client".
+
+ Diameter servers MUST support the base protocol, which includes
+ accounting. In addition, they MUST fully support each Diameter
+ application that is needed to implement the intended service, e.g.,
+ NASREQ and/or Mobile IPv4. A Diameter server MUST be referred to as
+ "Diameter X Server" where X is the application that it supports, and
+ not a "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. In addition, they MUST fully support each Diameter
+ application that is needed to implement proxied services, e.g.,
+ NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as
+ "Diameter X Proxy" where X is the application which it supports, and
+ not a "Diameter Proxy".
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 21]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+2.1. Transport
+
+ The Diameter Transport profile is defined in [RFC3539].
+
+ The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
+ and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer
+ Security (DTLS) [RFC6347], a Diameter node that initiates a
+ connection prior to any message exchanges MUST run on port 5658. It
+ is assumed that TLS is run on top of TCP when it is used, and DTLS is
+ run on top of SCTP when it is used.
+
+ If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
+ connections on port 5658 (i.e., the peer complies only with RFC
+ 3588), then the initiator MAY revert to using TCP or SCTP on port
+ 3868. Note that this scheme is kept only for the purpose of backward
+ compatibility and that there are inherent security vulnerabilities
+ when the initial CER/CEA messages are sent unprotected (see
+ Section 5.6).
+
+ Diameter clients MUST support either TCP or SCTP; agents and servers
+ SHOULD support both.
+
+ A Diameter node MAY initiate connections from a source port other
+ than the one that it declares it accepts incoming connections on, and
+ it MUST always be prepared 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 take precedence over the default ports
+ (3868 and 5658).
+
+ A given Diameter instance of the peer state machine MUST NOT use more
+ than one transport connection to communicate with a given peer,
+ unless multiple instances exist on the peer, in which, case a
+ separate connection per process is allowed.
+
+ When no transport connection exists with a peer, an attempt to
+ connect SHOULD be made periodically. This behavior is handled via
+ the Tc timer (see Section 12 for details), whose recommended value is
+ 30 seconds. There are certain exceptions to this rule, such as when
+ a peer has terminated the transport connection stating that it does
+ not wish to communicate.
+
+ When connecting to a peer and either zero or more transports are
+ specified, TLS SHOULD be tried first, followed by DTLS, then by TCP,
+ and finally by SCTP. See Section 5.2 for more information on peer
+ discovery.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 22]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Diameter implementations SHOULD be able to interpret ICMP protocol
+ port unreachable messages as explicit indications that the server is
+ not reachable, subject to security policy on trusting such messages.
+ Further guidance regarding the treatment of ICMP errors can be found
+ in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be
+ able to interpret a reset from the transport and timed-out connection
+ attempts. If Diameter receives data from the lower layer that cannot
+ be parsed or identified as a Diameter error made by the peer, the
+ stream is compromised and cannot be recovered. The transport
+ connection MUST be closed using a RESET call (send a TCP RST bit) or
+ an SCTP ABORT message (graceful closure is compromised).
+
+2.1.1. SCTP Guidelines
+
+ Diameter messages SHOULD be mapped into SCTP streams in a way that
+ avoids head-of-the-line (HOL) blocking. Among different ways of
+ performing the mapping that fulfill this requirement it is
+ RECOMMENDED that a Diameter node send every Diameter message (request
+ or response) over stream zero with the unordered flag set. However,
+ Diameter nodes MAY select and implement other design alternatives for
+ avoiding HOL blocking such as 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 is free to return responses
+ over a different stream. This way, both sides manage the available
+ streams in the sending direction, independently of the streams chosen
+ by the other side to send a particular Diameter message. These
+ messages can be out-of-order and belong to different Diameter
+ sessions.
+
+ Out-of-order delivery has special concerns during a connection
+ establishment and termination. 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 is sent shortly
+ after the CEA and delivered out-of-order, the initiator side, still
+ in Wait-I-CEA state, will discard the application message and close
+ the connection. In order 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, proving that it has
+ moved to I-Open state. To trigger such a message, the receiver side
+ could send a DWR immediately after sending a CEA. Upon reception of
+ the corresponding DWA, the receiver side should start using out-of-
+ order delivery methods to counter the HOL blocking.
+
+ Another race condition may occur when DPR and DPA messages are used.
+ Both DPR and DPA are small in size; thus, they may be delivered to
+ the peer faster than application messages when an out-of-order
+ delivery mechanism is used. Therefore, it is possible that a DPR/DPA
+
+
+
+Fajardo, et al. Standards Track [Page 23]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ exchange completes while application messages are still in transit,
+ resulting in a loss of these messages. An implementation could
+ mitigate this race condition, for example, using timers, and wait for
+ a short period of time for pending application level messages to
+ arrive before proceeding to disconnect 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). For
+ this purpose, two PPID values are allocated: the PPID value 46 is for
+ Diameter messages in clear text SCTP DATA chunks, and the PPID value
+ 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 desired, alternative security
+ mechanisms that are independent of Diameter, such as IPsec [RFC4301],
+ can be deployed to secure connections between peers. The Diameter
+ protocol MUST NOT be used without one of TLS, DTLS, or IPsec.
+
+2.3. Diameter Application Compliance
+
+ Application Ids are advertised during the capabilities exchange phase
+ (see Section 5.3). Advertising support of an application implies
+ that the sender supports the functionality specified in the
+ respective 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 for 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 does not require an Application Id since its
+ support is mandatory. During the capabilities exchange, Diameter
+ nodes inform their peers of locally supported applications.
+ Furthermore, all Diameter messages contain an Application Id, which
+ is used in the message forwarding process.
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 24]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The following Application Id values are defined:
+
+ Diameter common message 0
+ Diameter base accounting 3
+ Relay 0xffffffff
+
+ Relay 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
+ advertising 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
+
+ This section attempts to provide the reader with an understanding of
+ the difference between "connection" and "session", which are terms
+ used extensively throughout this document.
+
+ A connection refers to a transport-level connection between two peers
+ that is 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; it is identified via the
+ Session-Id AVP.
+
+ +--------+ +-------+ +--------+
+ | Client | | Relay | | Server |
+ +--------+ +-------+ +--------+
+ <----------> <---------->
+ peer connection A peer connection B
+
+ <----------------------------->
+ User session x
+
+ Figure 1: Diameter Connections and Sessions
+
+ In the example provided in Figure 1, peer connection A is established
+ between the client and the relay. 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
+ accepted by the server, both the client and the server are aware of
+ the session.
+
+
+
+
+Fajardo, et al. Standards Track [Page 25]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ It is important to note that there is no relationship between a
+ connection and a session, and that Diameter messages for multiple
+ sessions are all multiplexed through a single connection. Also, note
+ that Diameter messages pertaining to the session, both application-
+ specific and those that are defined in this document such as ASR/ASA,
+ RAR/RAA, and STR/STA, MUST carry the Application Id of the
+ application. Diameter messages pertaining to peer connection
+ establishment and maintenance such as 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 contains the
+ contents of the Origin-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.
+
+ 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).
+
+
+
+Fajardo, et al. Standards Track [Page 26]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+2.7. Routing Table
+
+ All Realm-Based routing lookups are performed against what is
+ commonly known as the routing table (see Section 12). Each routing
+ table entry contains the following fields:
+
+ Realm Name
+
+ This is the field that MUST be used as a primary key in the
+ routing table lookups. Note that some implementations perform
+ their lookups based on longest-match-from-the-right on the realm
+ rather than requiring an exact match.
+
+ Application Identifier
+
+ An application is identified by an Application Id. A route entry
+ can have a different destination based 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 is used to identify how a message should be
+ treated. The following actions are supported:
+
+ 1. LOCAL - Diameter messages that can be satisfied locally and do
+ not need to be routed to another Diameter entity.
+
+ 2. RELAY - All Diameter messages that fall within this category
+ MUST be routed to a next-hop Diameter entity that is indicated
+ by the identifier described below. Routing is done without
+ modifying any non-routing AVPs. See Section 6.1.9 for
+ relaying guidelines.
+
+ 3. PROXY - All Diameter messages that fall within this category
+ MUST be routed to a next Diameter entity that is 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.
+
+ 4. REDIRECT - Diameter messages that fall within 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 27]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Server Identifier
+
+ The identity of one or more servers to which the message is to be
+ routed. 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) to which the message MUST be routed. When the Local
+ Action field is set to REDIRECT, this field contains the identity
+ of one or more servers to which the message MUST be redirected.
+
+ 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 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 of operation in order 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
+
+ In addition to clients and servers, the Diameter protocol introduces
+ relay, proxy, redirect, and translation agents, each of which is
+ defined in Section 1.2. Diameter agents are useful for several
+ reasons:
+
+ o They can distribute administration of systems to a configurable
+ grouping, including the maintenance of security associations.
+
+
+
+
+Fajardo, et al. Standards Track [Page 28]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o 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.
+
+ o They can do value-added processing to the requests or responses.
+
+ o They can be used for load balancing.
+
+ o A complex network will have multiple authentication sources, they
+ can sort requests and forward 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:
+
+ o Protocol translation (e.g., RADIUS <-> Diameter)
+
+ o Limiting resources authorized to a particular user
+
+ o 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 29]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+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 is 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 messages
+
+ The example provided in Figure 2 depicts a request issued from a NAS,
+ which is an access device, for the user [email protected]. Prior to
+ 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 30]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+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 that the
+ consortium 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 provided in Figure 3 depicts a request issued from the
+ access device, NAS, for the user [email protected]. 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.
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 31]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ +------+
+ | |
+ | 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 Message
+
+ Since 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
+
+ A translation agent is a device that provides translation between two
+ protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation
+ agents are likely to be used as aggregation servers to communicate
+ with a Diameter infrastructure, while allowing for the embedded
+ systems to be migrated at a slower pace.
+
+ Given that the Diameter protocol introduces the concept of long-lived
+ authorized sessions, translation agents MUST be session stateful and
+ MUST maintain transaction state.
+
+ Translation of messages can only occur if the agent recognizes the
+ application of a particular request; therefore, 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.com
+
+ Figure 4: Translation of RADIUS to Diameter
+
+
+
+
+Fajardo, et al. Standards Track [Page 32]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+2.9. Diameter Path Authorization
+
+ As noted in Section 2.2, Diameter provides transmission-level
+ security for each connection using TLS/TCP and DTLS/SCTP. Therefore,
+ each connection can be authenticated and can be replay and integrity
+ protected.
+
+ In addition to authenticating each connection, the entire session
+ MUST also be authorized. Before initiating a connection, a Diameter
+ peer MUST check that its peers are authorized to act in their roles.
+ For example, a Diameter peer may be authentic, but that does not mean
+ that it is authorized to act as a Diameter server advertising a set
+ of Diameter applications.
+
+ Prior to bringing up a connection, authorization checks are performed
+ at each connection along the path. Diameter capabilities negotiation
+ (CER/CEA) also MUST be carried out, in order to determine what
+ Diameter applications are supported by each peer. Diameter sessions
+ MUST be routed only through authorized nodes that have advertised
+ support for the Diameter application required by the session.
+
+ As noted in Section 6.1.9, a relay or proxy agent MUST append a
+ Route-Record AVP to all requests forwarded. The AVP contains the
+ identity of the peer from which the request was received.
+
+ The home Diameter server, prior to authorizing a session, MUST check
+ the Route-Record AVPs to make sure that the route traversed by the
+ request is acceptable. For example, administrators within the home
+ realm may not wish to honor requests that have been routed through an
+ untrusted realm. By authorizing a request, the home Diameter server
+ is implicitly indicating its willingness to engage in the business
+ transaction as specified by any contractual relationship between the
+ server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
+ message (see Section 7.1.5) is sent if the route traversed by the
+ request is unacceptable.
+
+ A home realm may also wish to check that each accounting request
+ message corresponds to a Diameter response authorizing the session.
+ Accounting requests without corresponding authorization responses
+ SHOULD be subjected to further scrutiny, as should accounting
+ requests indicating a difference between the requested and provided
+ service.
+
+ Forwarding of an authorization response is considered evidence of a
+ willingness to take on financial risk relative to the session. A
+ local realm may wish to limit this exposure, for example, by
+ establishing credit limits for intermediate realms and refusing to
+ accept responses that would violate those limits. By issuing an
+
+
+
+Fajardo, et al. Standards Track [Page 33]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ accounting request corresponding to the authorization response, the
+ local realm implicitly indicates its agreement to provide the service
+ indicated in the authorization response. If the service cannot be
+ provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
+ message MUST be sent within the accounting request; a Diameter client
+ receiving an authorization response for a service that it cannot
+ perform MUST NOT substitute an alternate service and then send
+ accounting requests for the alternate service instead.
+
+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
+
+ This Version field MUST be set to 1 to indicate Diameter Version
+ 1.
+
+ Message Length
+
+ The Message Length field is three octets and indicates the length
+ of the Diameter message including the header fields and the padded
+ AVPs. Thus, the Message Length field is always a multiple of 4.
+
+ Command Flags
+
+ The Command Flags field is eight bits. The following bits are
+ assigned:
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 34]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 the message
+ will not conform to the CCF described for this command.
+ Messages with the 'E' bit set are commonly referred to as error
+ messages. This bit MUST NOT be set in request messages (see
+ Section 7.2).
+
+ T(Potentially retransmitted message)
+
+ This flag is set after a link failover procedure, to aid the
+ removal of duplicate requests. It is set when resending
+ requests not yet acknowledged, as an indication of a possible
+ duplicate due to a link failure. This bit MUST be cleared when
+ sending a request for the first time; otherwise, the sender
+ MUST set this flag. Diameter agents only need to be concerned
+ about the number of requests they send based on a single
+ received request; retransmissions by other entities need not be
+ tracked. Diameter agents that receive a request with the T
+ flag set, MUST keep the T flag set in the forwarded request.
+ This flag MUST NOT be set if an error answer message (e.g., a
+ protocol error) has been received for the earlier message. It
+ can be set only in cases where no answer has been received from
+ the server for a request, and the request 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 35]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Command Code
+
+ The Command Code field is three octets and is used in order 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 is used to identify for which
+ application the message is applicable. 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 aids in matching requests and replies.
+ The sender MUST ensure that the Hop-by-Hop Identifier in a request
+ is unique on a given connection at any given time, and it MAY
+ attempt to ensure that 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 found in the
+ corresponding request. The Hop-by-Hop Identifier is normally a
+ monotonically increasing number, whose start value was randomly
+ generated. An answer message that is 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) that is used to detect duplicate messages.
+ Upon reboot, implementations MAY set the high order 12 bits to
+ contain the low order 12 bits of current time, and the low order
+ 20 bits to a random value. Senders of request messages MUST
+ insert a unique identifier on each message. The identifier MUST
+ remain locally unique for a period of at least 4 minutes, even
+ across reboots. The originator of an answer message MUST ensure
+ that the End-to-End Identifier field contains the same value that
+ was found 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
+
+
+
+Fajardo, et al. Standards Track [Page 36]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 locally
+ consumed (see Section 6.2) SHOULD be silently discarded.
+
+ AVPs
+
+ AVPs are a method of encapsulating information relevant to the
+ Diameter message. See Section 4 for more information on AVPs.
+
+3.1. Command Codes
+
+ Each command Request/Answer pair is assigned a Command Code, and the
+ sub-type (i.e., request or answer) is identified via the 'R' bit in
+ the Command Flags field of the Diameter header.
+
+ Every Diameter message MUST contain a Command Code in its header's
+ Command Code field, which is used to determine the action that is to
+ be taken for a particular message. The following Command Codes are
+ 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
+ Answer
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 37]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+3.2. Command Code Format Specification
+
+ Every Command Code defined MUST include a corresponding Command Code
+ Format (CCF) specification, which is used to define the AVPs that
+ MUST or MAY be present when sending the message. The following ABNF
+ specifies the CCF used in the definition:
+
+ 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 38]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 39]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The following is a definition of a fictitious Command Code:
+
+ Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
+ { User-Name }
+ 1* { Origin-Host }
+ * [ AVP ]
+
+3.3. Diameter Command Naming Conventions
+
+ Diameter command names typically includes one or more English words
+ followed by the verb "Request" or "Answer". Each English word is
+ delimited by a hyphen. A three-letter acronym for both the request
+ and answer is also normally provided.
+
+ An example is a message set used to terminate a session. The command
+ name is Session-Terminate-Request and Session-Terminate-Answer, while
+ the acronyms are STR and STA, respectively.
+
+ Both the request and the answer for a given command share the same
+ Command Code. The request is identified by the R(equest) bit in the
+ Diameter header set to one (1), to ask that a particular action be
+ performed, such as authorizing a user or terminating a session. Once
+ the receiver has completed the request, it issues the corresponding
+ answer, which includes a result code that communicates one of the
+ following:
+
+ o The request was successful
+
+ o The request failed
+
+ o An additional request has to be sent to provide information the
+ peer requires prior to returning a successful or failed answer.
+
+ o The receiver could not process the request, but provides
+ information about a Diameter peer that is able to satisfy the
+ request, known as redirect.
+
+ Additional information, encoded within AVPs, may also be included in
+ answer messages.
+
+4. Diameter AVPs
+
+ Diameter AVPs carry specific authentication, accounting,
+ authorization, and routing information as well as configuration
+ details for the request and reply.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 40]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Each AVP of type OctetString MUST be padded to align on a 32-bit
+ boundary, while other AVP types align naturally. A number of zero-
+ valued bytes are added to the end of the AVP Data field until a word
+ boundary is reached. The length of the padding is not reflected in
+ the AVP Length field.
+
+4.1. AVP Header
+
+ The fields in the AVP header MUST be sent in network byte order. The
+ format of the header is:
+
+ 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, combined with the Vendor-Id field, identifies the
+ attribute uniquely. AVP numbers 1 through 255 are reserved for
+ reuse of RADIUS attributes, without setting the Vendor-Id field.
+ AVP numbers 256 and above are used for Diameter, which are
+ allocated by IANA (see Section 11.1.1).
+
+ AVP Flags
+
+ The AVP Flags field informs the receiver how each attribute must
+ be handled. New Diameter applications SHOULD NOT define
+ additional AVP Flag bits. However, note that 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 usage of end-to-end security. At the time of writing,
+ there are no end-to-end security mechanisms specified; therefore,
+ the 'P' bit SHOULD be set to 0.
+
+ The 'M' bit, known as the Mandatory bit, indicates 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 receives an AVP that has the M-bit
+
+
+
+Fajardo, et al. Standards Track [Page 41]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ set but does not understand it. An exception applies when the AVP
+ is embedded within a Grouped AVP. 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 receives a message with such an AVP that is not supported, or
+ whose value is not supported, MAY simply ignore the AVP.
+
+ The 'V' bit, known as the Vendor-Specific bit, indicates whether
+ the optional Vendor-ID field is present in the AVP header. When
+ set, the AVP Code belongs to the specific vendor code address
+ space.
+
+ AVP Length
+
+ The AVP Length field is three octets, and indicates the number of
+ octets in this AVP including the AVP Code field, AVP Length field,
+ AVP Flags field, Vendor-ID field (if present), and the AVP Data
+ field. If a message is received with an invalid attribute length,
+ the message MUST be rejected.
+
+4.1.1. Optional Header Elements
+
+ The AVP header contains one optional field. This field is only
+ present if the respective bit-flag is enabled.
+
+ Vendor-ID
+
+ The Vendor-ID field is present if the 'V' bit is set in the AVP
+ Flags field. The optional four-octet Vendor-ID field contains the
+ IANA-assigned "SMI Network Management Private Enterprise Codes"
+ [ENTERPRISE] value, encoded in network byte order. Any vendors or
+ standardization organizations that are also treated like vendors
+ in the IANA-managed "SMI Network Management Private Enterprise
+ Codes" space wishing to implement a vendor-specific Diameter AVP
+ MUST use their own Vendor-ID along with their privately managed
+ AVP address space, guaranteeing that they will not collide with
+ any other vendor's vendor-specific AVP(s) or with future IETF
+ AVPs.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 42]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ A Vendor-ID value of zero (0) corresponds to the IETF-adopted AVP
+ values, as managed by IANA. Since the absence of the Vendor-ID
+ field implies that the AVP in question is not vendor specific,
+ 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 and contains information
+ specific to the Attribute. The format and length of the Data field
+ is 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. In the event that a new Basic
+ AVP Data Format is needed, a new version of this RFC MUST be created.
+
+ OctetString
+
+ The data contains 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 are
+ not a multiple of 4 octets in length are followed by the necessary
+ padding so that the next AVP (if any) will start on a 32-bit
+ boundary.
+
+ Integer32
+
+ 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
+
+ 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
+
+ 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
+
+ 64-bit unsigned value, in network byte order. The AVP Length
+ field MUST be set to 16 (20 if the 'V' bit is enabled).
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 43]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Float32
+
+ This represents floating point values of single precision as
+ described by [FLOATPOINT]. The 32-bit value is transmitted in
+ network byte order. The AVP Length field MUST be set to 12 (16 if
+ the 'V' bit is enabled).
+
+ Float64
+
+ This represents floating point values of double precision as
+ described by [FLOATPOINT]. The 64-bit value is transmitted 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 specified as a sequence of AVPs. These AVPs are
+ concatenated -- including their headers and padding -- in the
+ order in which they are specified and the result encapsulated 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 included AVPs,
+ including their headers and padding. Thus, the AVP Length field
+ of an AVP of type Grouped is always a multiple of 4.
+
+4.3. Derived AVP Data Formats
+
+ In addition to using the Basic AVP Data Formats, applications may
+ define data formats derived from the Basic AVP Data Formats. 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
+
+ The following are commonly used Derived AVP Data Formats.
+
+ Address
+
+ The Address format is derived from the OctetString Basic AVP
+ Format. It is a discriminated union representing, 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
+ represent the AddressType, which contains an Address Family,
+ defined in [IANAADFAM]. The AddressType is used to discriminate
+ the content and format of the remaining octets.
+
+
+
+
+Fajardo, et al. Standards Track [Page 44]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Time
+
+ The Time format is derived from the OctetString Basic AVP Format.
+ The string MUST contain four octets, in the same format as the
+ first four bytes are in the NTP timestamp format. The NTP
+ timestamp format is defined in Section 3 of [RFC5905].
+
+ This represents the number of seconds since 0h on 1 January 1900
+ with respect to the 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
+
+ The UTF8String format is derived from the OctetString Basic AVP
+ Format. This is a human-readable string represented using the
+ ISO/IEC IS 10646-1 character set, encoded as an OctetString using
+ the UTF-8 transformation format [RFC3629].
+
+ Since additional code points are added by amendments to the 10646
+ standard from time to time, implementations MUST be prepared to
+ encounter any code point from 0x00000001 to 0x7fffffff. Byte
+ sequences that do not correspond to the valid encoding of a code
+ point into UTF-8 charset or are outside this range are prohibited.
+
+ The use of control codes SHOULD be avoided. When it is necessary
+ 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 not directly supported by user interface hardware
+ or software, 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 require multiple bytes to represent a single character /
+ code point; thus, the length of a UTF8String in octets may be
+ different from the number of characters encoded.
+
+ Note that the AVP Length field of an UTF8String is measured in
+ octets not characters.
+
+
+
+
+Fajardo, et al. Standards Track [Page 45]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DiameterIdentity
+
+ The DiameterIdentity format is derived from the OctetString Basic
+ AVP Format.
+
+ DiameterIdentity = FQDN/Realm
+
+ The DiameterIdentity value is used to uniquely identify either:
+
+ * A Diameter node for purposes of duplicate connection and
+ routing loop detection.
+
+ * A Realm to determine whether messages can be satisfied locally
+ or whether they must be routed or redirected.
+
+ When a DiameterIdentity value is used to identify a Diameter node,
+ the contents of the string MUST be the Fully Qualified Domain Name
+ (FQDN) of the Diameter 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, whatever the connection on
+ which it is sent. In this document, note that DiameterIdentity is
+ in ASCII form in order to be compatible with existing DNS
+ infrastructure. See Appendix D for interactions between the
+ Diameter protocol and Internationalized Domain Names (IDNs).
+
+ DiameterURI
+
+ The DiameterURI MUST follow the Uniform Resource Identifiers (RFC
+ 3986) syntax [RFC3986] rules specified below:
+
+ "aaa://" FQDN [ port ] [ transport ] [ protocol ]
+
+ ; No transport security
+
+ "aaas://" FQDN [ port ] [ transport ] [ protocol ]
+
+ ; Transport security used
+
+ FQDN = < Fully Qualified Domain Name >
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 46]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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+" )
+
+ The following are 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=radius
+
+ Enumerated
+
+ The Enumerated format is derived from the Integer32 Basic AVP
+ Format. The definition contains a list of valid values and their
+ interpretation and is described in the Diameter application
+ introducing the AVP.
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 47]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ IPFilterRule
+
+ The IPFilterRule format is 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 may be filtered based on
+ the following information that is associated with it:
+
+ 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 types
+
+ Rules for the appropriate direction are evaluated in order, with the
+ first matched rule terminating 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 the 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.
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 48]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 49]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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:
+
+
+
+Fajardo, et al. Standards Track [Page 50]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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).
+
+ There is one kind of packet that the access device MUST always
+ discard, that is an IP fragment with a fragment offset of one. This
+ is a valid packet, but it only has one use, to try to circumvent
+ firewalls.
+
+ An access device that is unable to interpret or apply a deny rule
+ MUST terminate the session. An access device that is unable to
+ interpret or apply a permit rule MAY apply a more restrictive rule.
+ An access device MAY apply deny rules of its own before the supplied
+ rules, for example to protect the access device owner's
+ infrastructure.
+
+4.4. Grouped AVP Values
+
+ The Diameter protocol allows AVP values of type 'Grouped'. This
+ implies that the Data field is actually a sequence of AVPs. It is
+ possible to include an AVP with a Grouped type within a Grouped type,
+ that is, to nest them. AVPs within an AVP of type Grouped have 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. Receivers of a Grouped AVP that
+ does not have the 'M' (mandatory) bit set and one or more of the
+ encapsulated AVPs within the group has the 'M' (mandatory) bit set
+ MAY simply be ignored if the Grouped AVP itself is unrecognized. The
+ rule applies even if the encapsulated AVP with its 'M' (mandatory)
+ bit set is further encapsulated within other sub-groups, i.e., 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 / "-")
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 51]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+ The Example-AVP (AVP Code 999999) is of type Grouped and is used to
+ clarify how Grouped AVP values work. The Grouped Data field has the
+ following CCF grammar:
+
+ Example-AVP ::= < AVP Header: 999999 >
+ { Origin-Host }
+ 1*{ Session-Id }
+ *[ AVP ]
+
+ An Example-AVP with Grouped Data follows.
+
+ The Origin-Host AVP (Section 6.3) is required. In this case:
+
+ Origin-Host = "example.com".
+
+ One or more Session-Ids must follow. Here there are two:
+
+ Session-Id =
+ "grump.example.com:33041;23432;893;0AF3B81"
+
+ Session-Id =
+ "grump.example.com:33054;23561;2358;0AF3B82"
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 52]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ optional AVPs included are
+
+ Recovery-Policy = <binary>
+ 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
+ 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
+ c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
+ f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
+ cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
+ 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
+ 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
+
+ Futuristic-Acct-Record = <binary>
+ fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
+ 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
+ 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
+ 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
+ d3427475e49968f841
+
+ The data for the optional AVPs is represented in hexadecimal form
+ since the format of these AVPs is not known at the time of definition
+ of the Example-AVP group nor (likely) at the time when the example
+ instance of this AVP is interpreted -- except by Diameter
+ implementations that support the same set of AVPs. The encoding
+ example illustrates how padding is used and how length fields are
+ calculated. Also, note that AVPs may be present in the Grouped AVP
+ value that the receiver cannot interpret (here, the Recover-Policy
+ and Futuristic-Acct-Record AVPs). The length of the Example-AVP is
+ the sum of all the length of the member AVPs, including their
+ padding, plus the Example-AVP header size.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 53]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ This AVP would be encoded as follows:
+
+ 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|
+ +-------+-------+-------+-------+-------+-------+-------+-------+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 54]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+4.5. Diameter Base Protocol AVPs
+
+ The following table describes the Diameter AVPs defined in the base
+ protocol, their AVP Code values, types, and possible flag values.
+
+ Due to space constraints, the short form DiamIdent is used to
+ represent DiameterIdentity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 55]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ +----------+
+ | 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 | | |
+ -----------------------------------------|----+-----|
+
+
+
+
+Fajardo, et al. Standards Track [Page 56]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ +----------+
+ | 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 | | |
+ -----------------------------------------|----+-----|
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 57]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5. Diameter Peers
+
+ This section describes how Diameter nodes establish connections and
+ communicate with peers.
+
+5.1. Peer Connections
+
+ Connections between diameter peers are established using their valid
+ DiameterIdentity. A Diameter node initiating a connection to a peer
+ MUST know the peer's DiameterIdentity. Methods for discovering a
+ Diameter peer can be found in Section 5.2.
+
+ Although a Diameter node may have many possible peers with which it
+ is able to communicate, it may not be economical to have an
+ established connection to all of them. At a minimum, a Diameter node
+ SHOULD have an established connection with two peers per realm, known
+ as the primary and secondary peers. Of course, a node MAY have
+ additional connections, if it is deemed necessary. Typically, all
+ messages for a realm are sent to the primary peer but, in the event
+ that failover procedures are invoked, any pending requests are sent
+ to the secondary peer. However, implementations are free to load
+ balance requests between a set of peers.
+
+ Note that a given peer MAY act as a primary for a given realm while
+ acting as a secondary for another realm.
+
+ When a peer is deemed suspect, which could occur for various reasons,
+ including not receiving a DWA within an allotted time frame, no new
+ requests should be forwarded to the peer, but failover procedures are
+ invoked. When an active peer is moved to this mode, additional
+ connections SHOULD be established to ensure that the necessary number
+ of active connections exists.
+
+ There are two ways that a peer is removed from the suspect peer list:
+
+ 1. The peer is no longer reachable, causing the transport connection
+ to be shut down. The peer is moved to the closed state.
+
+ 2. Three watchdog messages are exchanged with accepted round-trip
+ times, and the connection to the peer is considered stabilized.
+
+ In the event the peer being removed is either the primary or
+ secondary, an alternate peer SHOULD replace the deleted peer and
+ assume the role of either primary or secondary.
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 58]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5.2. Diameter Peer Discovery
+
+ Allowing for dynamic Diameter agent discovery makes possible simpler
+ and more robust deployment of Diameter services. In order to promote
+ interoperable implementations of Diameter peer discovery, the
+ following mechanisms (manual configuration and DNS) are described.
+ These are based on existing IETF standards. Both mechanisms MUST be
+ supported by all Diameter implementations; either MAY be used.
+
+ There are two cases where Diameter peer discovery may be performed.
+ The first is when a Diameter client needs to discover a first-hop
+ Diameter agent. The second case is when a Diameter agent needs to
+ discover another agent for further handling of a Diameter operation.
+ In both cases, the following 'search order' is recommended:
+
+ 1. The Diameter implementation consults its list of statically
+ (manually) configured Diameter agent locations. These will be
+ used if they exist and respond.
+
+ 2. The Diameter implementation performs a NAPTR query for a server
+ in a particular realm. The Diameter implementation has to know,
+ in advance, in which realm to look for a Diameter agent. This
+ could be deduced, for example, from the 'realm' in an NAI on
+ which a Diameter implementation needed to perform a Diameter
+ operation.
+
+ The NAPTR usage in Diameter follows the S-NAPTR DDDS application
+ [RFC3958] in which the SERVICE field includes tags for the
+ desired application and supported application protocol. The
+ application service tag for a Diameter application is 'aaa' and
+ the supported application 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 of a suitable peer. The domain suffixes in the NAPTR
+ replacement field SHOULD match the domain of the original query.
+ An example can be found in Appendix B.
+
+ 3. If no NAPTR records are found, the requester directly queries for
+ one of the following SRV records: for Diameter over TCP, use
+ "_diameter._tcp.realm"; for Diameter over TLS, use
+ "_diameters._tcp.realm"; for Diameter over SCTP, use
+ "_diameter._sctp.realm"; for Diameter over DTLS, use
+ "_diameters._sctp.realm". If SRV records are found, then the
+ requester can perform address record query (A RR's and/or AAAA
+
+
+
+
+Fajardo, et al. Standards Track [Page 59]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ RR's) for the target hostname specified in the SRV records
+ following the rules given 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 handed out by the server in the
+ TLS/TCP and DTLS/SCTP or Internet Key Exchange Protocol (IKE)
+ exchange. Similarly, the domain name in the SRV query and the domain
+ name in the target in the SRV record MUST both be valid based on the
+ same site certificate. Otherwise, an attacker could modify the DNS
+ records to contain replacement values in a different domain, and the
+ client could not validate whether this was the desired behavior or
+ the result of an attack.
+
+ Also, the Diameter peer MUST check to make sure that the discovered
+ peers are authorized to act in its role. Authentication via IKE or
+ TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not
+ sufficient to conclude this. For example, a web server may have
+ obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs
+ may be included in the DNS, but this does not imply that it is
+ authorized to act as a Diameter server.
+
+ Authorization can be achieved, for example, by the configuration of a
+ Diameter server Certification Authority (CA). The server CA issues a
+ certificate to the Diameter server, which includes an Object
+ Identifier (OID) to indicate the subject is a Diameter server in the
+ Extended Key Usage extension [RFC5280]. This certificate is then
+ used during TLS/TCP, DTLS/SCTP, or IKE security negotiation.
+ However, note that, at the time of writing, no Diameter server
+ Certification Authorities exist.
+
+ A dynamically discovered peer causes an entry in the peer table (see
+ Section 2.6) to be created. Note that entries created via DNS MUST
+ expire (or be refreshed) within the DNS Time to Live (TTL). If a
+ peer is discovered outside of the local realm, a routing table entry
+ (see Section 2.7) for the peer's realm is 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 the Capabilities Exchange messages, as specified in the peer
+ state machine (see Section 5.6). This message allows the discovery
+ of a peer's identity and its capabilities (protocol version number,
+ the identifiers of supported Diameter applications, security
+ mechanisms, etc.).
+
+
+
+
+Fajardo, et al. Standards Track [Page 60]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The receiver only issues commands to its peers that have advertised
+ support for the Diameter application that defines the command. A
+ Diameter node MUST cache the supported Application Ids in order to
+ ensure that unrecognized commands and/or AVPs are not unnecessarily
+ sent to a peer.
+
+ A receiver of a Capabilities-Exchange-Request (CER) message that does
+ not have any 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. Note that 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 the peer.
+
+ The receiver of the Capabilities-Exchange-Request (CER) MUST
+ determine common applications by computing the intersection of its
+ own set of supported Application Ids against 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 computation. The sender of the Capabilities-Exchange-Answer
+ (CEA) SHOULD include all of its supported applications as a hint to
+ the receiver regarding all of its application capabilities.
+
+ Diameter implementations SHOULD first attempt to establish a TLS/TCP
+ and DTLS/SCTP connection prior to the CER/CEA exchange. This
+ protects the capabilities information of both peers. To support
+ older Diameter implementations that do not fully conform to this
+ document, the transport security MAY still be negotiated via an
+ Inband-Security AVP. In this case, the receiver of a Capabilities-
+ Exchange-Request (CER) message that does not have any 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 received from unknown peers MAY be silently discarded, or a CEA
+ MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
+ In both cases, the transport connection is closed. If the local
+ policy permits receiving CERs from unknown hosts, a successful CEA
+ MAY be returned. If a CER from an unknown peer is answered with a
+ successful CEA, the lifetime of the peer entry is equal to the
+ lifetime of the transport connection. In case of a transport
+ failure, all the pending transactions destined to the unknown peer
+ can be discarded.
+
+ The CER and CEA messages MUST NOT be proxied, redirected, or relayed.
+
+
+
+
+Fajardo, et al. Standards Track [Page 61]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Since the CER/CEA messages cannot be proxied, it is still possible
+ that an upstream agent will receive a message for which it has no
+ available peers to handle the application that corresponds to the
+ Command Code. In such instances, the 'E' bit is set in the answer
+ message (Section 7) with the Result-Code AVP set to
+ DIAMETER_UNABLE_TO_DELIVER to inform the downstream agent to take
+ action (e.g., re-routing 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), indicated by the Command
+ Code set to 257 and the Command Flags' 'R' bit set, is sent to
+ exchange local capabilities. Upon detection of a transport failure,
+ this message MUST NOT be sent to an alternate peer.
+
+ When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
+ which allow for 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 ]
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 62]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5.3.2. Capabilities-Exchange-Answer
+
+ The Capabilities-Exchange-Answer (CEA), indicated by the Command Code
+ set to 257 and the Command Flags' 'R' bit cleared, is sent in
+ response to a CER message.
+
+ When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
+ which allow connections to span multiple interfaces, hence, multiple
+ IP addresses, the Capabilities-Exchange-Answer message MUST contain
+ one Host-IP-Address AVP for each potential IP address that MAY be
+ locally used when transmitting Diameter messages.
+
+ 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 of type Unsigned32 and contains
+ the IANA "SMI Network Management Private Enterprise Codes"
+ [ENTERPRISE] value assigned to the Diameter Software vendor. It is
+ envisioned that the combination of the Vendor-Id, Product-Name
+ (Section 5.3.7), and Firmware-Revision (Section 5.3.4) AVPs may
+ provide useful debugging information.
+
+ A Vendor-Id value of zero in the CER or CEA message is reserved and
+ indicates that this field is ignored.
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 63]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5.3.4. Firmware-Revision AVP
+
+ The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
+ used to inform a Diameter peer of the firmware revision of the
+ issuing device.
+
+ For devices that do not have a firmware revision (general-purpose
+ computers running Diameter software modules, for instance), the
+ revision of the Diameter software module may be reported instead.
+
+5.3.5. Host-IP-Address AVP
+
+ The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
+ to inform a Diameter peer of the sender's IP address. All source
+ addresses that a Diameter node expects to use with SCTP [RFC4960] or
+ DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
+ including a Host-IP-Address AVP for each address.
+
+5.3.6. Supported-Vendor-Id AVP
+
+ The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
+ contains the IANA "SMI Network Management Private Enterprise Codes"
+ [ENTERPRISE] value assigned to a vendor other than the device vendor
+ but including the application vendor. This is used in the CER and
+ CEA messages in order to inform the peer that the sender supports (a
+ subset of) the Vendor-Specific AVPs defined by the vendor identified
+ in this AVP. The value of this AVP MUST NOT be set to zero.
+ Multiple instances of this AVP containing the same value SHOULD NOT
+ be sent.
+
+5.3.7. Product-Name AVP
+
+ The Product-Name AVP (AVP Code 269) is of type UTF8String and
+ contains the vendor-assigned name for the product. The Product-Name
+ AVP SHOULD remain constant across firmware revisions for the same
+ product.
+
+5.4. Disconnecting Peer Connections
+
+ When a Diameter node disconnects one of its transport connections,
+ its peer cannot know the reason for the disconnect and will most
+ likely assume that a connectivity problem occurred or that the peer
+ has rebooted. In these cases, the peer may periodically attempt to
+ reconnect, as stated in Section 2.1. In the event that the
+ disconnect was a result of either a shortage of internal resources or
+ simply that the node in question has no intentions of forwarding any
+ Diameter messages to the peer in the foreseeable future, a periodic
+
+
+
+
+Fajardo, et al. Standards Track [Page 64]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ connection request would not be welcomed. The Disconnection-Reason
+ AVP contains the reason the Diameter node issued the Disconnect-Peer-
+ Request message.
+
+ The Disconnect-Peer-Request message is used by a Diameter node to
+ inform its peer of its intent to disconnect the transport layer and
+ that the peer shouldn't reconnect unless it has a valid reason to do
+ so (e.g., message to be forwarded). Upon receipt of the message, the
+ Disconnect-Peer-Answer message is returned, which SHOULD contain an
+ error if messages have recently been forwarded, and are likely in
+ flight, which would otherwise cause a race condition.
+
+ The receiver of the Disconnect-Peer-Answer message initiates the
+ transport disconnect. The sender of the Disconnect-Peer-Answer
+ message should be able to detect the transport closure and clean up
+ the connection.
+
+5.4.1. Disconnect-Peer-Request
+
+ The Disconnect-Peer-Request (DPR), indicated by the Command Code set
+ to 282 and the Command Flags' 'R' bit set, is sent to a peer to
+ inform it of its intentions to shut down the transport connection.
+ Upon detection of a transport failure, 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), indicated by the Command Code set
+ to 282 and the Command Flags' 'R' bit cleared, is sent as a response
+ to the Disconnect-Peer-Request message. Upon receipt of this
+ message, the transport connection is shut down.
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 65]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 of type Enumerated. A
+ Diameter node MUST include this AVP in the Disconnect-Peer-Request
+ message to inform the peer of the reason for its intention to shut
+ down the transport connection. The following values are supported:
+
+ REBOOTING 0
+ A scheduled reboot is imminent. A receiver of a DPR with
+ above result code MAY attempt reconnection.
+
+ BUSY 1
+ The peer's internal resources are constrained, and it has
+ determined that the transport connection needs to be closed.
+ A receiver of a DPR with above result code SHOULD NOT attempt
+ reconnection.
+
+ DO_NOT_WANT_TO_TALK_TO_YOU 2
+ The peer has determined that it does not see a need for the
+ transport connection to exist, since it does not expect any
+ messages to be exchanged in the near future. A receiver of a
+ DPR with above result code SHOULD NOT attempt reconnection.
+
+5.5. Transport Failure Detection
+
+ Given the nature of the Diameter protocol, it is recommended that
+ transport failures be detected as soon as possible. Detecting such
+ failures will minimize the occurrence of messages sent to unavailable
+ agents, resulting in unnecessary delays, and will provide better
+ failover performance. The Device-Watchdog-Request and Device-
+ Watchdog-Answer messages, defined in this section, are used to pro-
+ actively detect transport failures.
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 66]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5.5.1. Device-Watchdog-Request
+
+ The Device-Watchdog-Request (DWR), indicated by the Command Code set
+ to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
+ traffic has been exchanged between two peers (see Section 5.5.3).
+ Upon detection of a transport failure, 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), indicated by the Command Code set
+ to 280 and the Command Flags' 'R' bit cleared, is sent as a response
+ to the Device-Watchdog-Request message.
+
+ 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]. All
+ Diameter implementations MUST support the algorithm defined in that
+ specification in order to be compliant to the Diameter base protocol.
+
+5.5.4. Failover and Failback Procedures
+
+ In the event that a transport failure is detected with a peer, it is
+ necessary for all pending request messages to be forwarded to an
+ alternate agent, if possible. This is commonly referred to as
+ "failover".
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 67]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ In order for a Diameter node to perform failover procedures, it is
+ necessary for the node to maintain a pending message queue for a
+ given peer. When an answer message is received, the corresponding
+ request is removed from the queue. The Hop-by-Hop Identifier field
+ is used to match the answer with the queued request.
+
+ When a transport failure is detected, if possible, all messages in
+ the queue are sent to an alternate agent with the T flag set. On
+ booting a Diameter client or agent, the T flag is also set on any
+ remaining records in non-volatile storage that are still waiting to
+ be transmitted. An example of a case where it is not possible to
+ forward the message to an alternate server is when the message has a
+ fixed destination, and the unavailable peer is the message's final
+ destination (see Destination-Host AVP). Such an error requires that
+ the agent return an answer message with the 'E' bit set and the
+ Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
+
+ It is important to note that multiple identical requests or answers
+ MAY be received as a result of a failover. The End-to-End Identifier
+ field in the Diameter header along with the Origin-Host AVP MUST be
+ used to identify duplicate messages.
+
+ As described in Section 2.1, a connection request should be
+ periodically attempted with the failed peer in order to re-establish
+ the transport connection. Once a connection has been successfully
+ established, messages can once again be forwarded to the peer. This
+ is commonly referred to as "failback".
+
+5.6. Peer State Machine
+
+ This section contains a finite state machine that MUST be observed by
+ all Diameter implementations. Each Diameter node MUST follow the
+ state machine described below when communicating with each peer.
+ Multiple actions are separated by commas, and may continue on
+ succeeding lines, as space requires. Similarly, state and next state
+ may also span multiple lines, as space requires.
+
+ This state machine is closely coupled with the state machine
+ described in [RFC3539], which is used to open, close, failover,
+ probe, and reopen transport connections. In particular, note that
+ [RFC3539] requires the use of watchdog messages to probe connections.
+ For Diameter, DWR and DWA messages are to be used.
+
+ The I- prefix is used to represent the initiator (connecting)
+ connection, while the R- prefix is used to represent the responder
+ (listening) connection. The lack of a prefix indicates that the
+ event or action is the same regardless of the connection on which the
+ event occurred.
+
+
+
+Fajardo, et al. Standards Track [Page 68]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The stable states that a state machine may be in are Closed, I-Open,
+ and R-Open; all other states are intermediate. Note that I-Open and
+ R-Open are equivalent except for whether the initiator or responder
+ transport connection is used for communication.
+
+ A CER message is always sent on the initiating connection immediately
+ after the connection request is successfully completed. In the case
+ of an election, one of the two connections will shut down. The
+ responder connection will survive if the Origin-Host of the local
+ Diameter entity is higher than that of the peer; the initiator
+ connection will survive if the peer's Origin-Host is higher. All
+ subsequent messages are sent on the surviving connection. Note that
+ the results of an election on one peer are guaranteed to be the
+ inverse of the results on the other.
+
+ For TLS/TCP and DTLS/SCTP usage, a TLS/TCP and DTLS/SCTP handshake
+ SHOULD begin when both ends are in the closed state prior to any
+ Diameter message exchanges. The TLS/TCP and DTLS/SCTP connection
+ SHOULD be established before sending any CER or CEA message to secure
+ and protect the capabilities information of both peers. The TLS/TCP
+ and DTLS/SCTP connection SHOULD be disconnected when the state
+ machine moves to the closed state. When connecting to responders
+ that do not conform to this document (i.e., older Diameter
+ implementations that are not prepared to received TLS/TCP and DTLS/
+ SCTP connections in the closed state), the initial TLS/TCP and DTLS/
+ SCTP connection attempt will fail. The initiator MAY then attempt to
+ connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP
+ handshake when both ends are in the open state. If the handshake is
+ successful, all further messages will be sent via TLS/TCP and DTLS/
+ SCTP. If the handshake fails, both ends move to the closed state.
+
+ The state machine constrains only the behavior of a Diameter
+ implementation as seen by Diameter peers through events on the wire.
+
+ Any implementation that produces equivalent results is considered
+ compliant.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 69]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 70]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 Closed
+
+5.6.1. Incoming Connections
+
+ When a connection request is received from a Diameter peer, it is
+ not, in the general case, possible to know the identity of that peer
+ until a CER is received from it. This is because host and port
+ determine the identity of a Diameter peer; the source port of an
+ incoming connection is arbitrary. Upon receipt of a CER, the
+ identity of the connecting peer can be uniquely determined from the
+ Origin-Host.
+
+ For this reason, a Diameter peer must employ logic separate from the
+ state machine to receive connection requests, accept them, and await
+ the CER. Once the CER arrives on a new connection, the Origin-Host
+ that identifies the peer is used to locate the state machine
+ associated with that peer, and the new connection and CER are passed
+ to the state machine as an R-Conn-CER event.
+
+ The logic that handles incoming connections SHOULD close and discard
+ the connection if any message other than a CER arrives or if an
+ implementation-defined timeout occurs prior to receipt of CER.
+
+ Because handling of incoming connections up to and including receipt
+ of a CER requires logic, separate from that of any individual state
+ machine associated with a particular peer, it is described separately
+ in this section rather than in the state machine above.
+
+5.6.2. Events
+
+ Transitions and actions in the automaton are caused by events. In
+ this section, we will ignore the I- and R- prefixes, since the actual
+ event would be identical, but it would occur on one of two possible
+ connections.
+
+
+
+Fajardo, et al. Standards Track [Page 71]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Start The Diameter application has signaled that a
+ connection should be initiated with the peer.
+
+ R-Conn-CER An acknowledgement is received stating that the
+ transport connection has been 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 was received stating that
+ 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, other than a CEA, from the peer 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 (e.g., on system
+ shutdown).
+
+5.6.3. Actions
+
+ Actions in the automaton are caused by events and typically indicate
+ the transmission of packets and/or an action to be taken on the
+ connection. In this section, we will ignore the I- and R- prefixes,
+ since the actual action would be identical, but it would occur on one
+ of two possible connections.
+
+
+
+Fajardo, et al. Standards Track [Page 72]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Snd-Conn-Req A transport connection is initiated with the peer.
+
+ Accept The incoming connection associated with the R-Conn-CER
+ is accepted as the responder connection.
+
+ Reject The incoming connection associated with the R-Conn-CER
+ is disconnected.
+
+ Process-CER The CER associated with the R-Conn-CER is 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.
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 73]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+5.6.4. The Election Process
+
+ The election is performed on the responder. The responder compares
+ the Origin-Host received in the CER with its own Origin-Host as two
+ streams of octets. If the local Origin-Host lexicographically
+ succeeds the received Origin-Host, a Win-Election event is issued
+ locally. Diameter identities are in ASCII form; therefore, the
+ lexical comparison is consistent with DNS case insensitivity, where
+ octets that fall in the ASCII range 'a' through 'z' MUST compare
+ equally to their uppercase counterparts between 'A' and 'Z'. See
+ Appendix D for interactions between the Diameter protocol and
+ Internationalized Domain Name (IDNs).
+
+ The winner of the election MUST close the connection it initiated.
+ Historically, maintaining the responder side of a connection was more
+ efficient than maintaining the initiator side. However, current
+ practices makes this distinction irrelevant.
+
+6. Diameter Message Processing
+
+ This section describes how Diameter requests and answers are created
+ and processed.
+
+6.1. Diameter Request Routing Overview
+
+ A request is sent towards its final destination using one of the
+ following three combinations of the Destination-Realm and
+ Destination-Host AVPs:
+
+ o A request that is not able to be proxied (such as a CER) MUST NOT
+ contain either Destination-Realm or Destination-Host AVPs.
+
+ o A request that needs to be sent to a home server serving a
+ specific realm, but not to a specific server (such as the first
+ request of a series of round trips), MUST contain a Destination-
+ Realm AVP but MUST NOT contain a Destination-Host AVP. For
+ Diameter clients, the value of the Destination-Realm AVP MAY be
+ extracted from the User-Name AVP, or other methods.
+
+ o Otherwise, a request that needs to be sent to a specific home
+ server among those serving a given realm MUST contain both the
+ Destination-Realm and Destination-Host AVPs.
+
+ The Destination-Host AVP is used as described above when the
+ destination of the request is fixed, which includes:
+
+ o Authentication requests that span multiple round trips.
+
+
+
+
+Fajardo, et al. Standards Track [Page 74]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o A Diameter message that uses a security mechanism that makes use
+ of a pre-established session key shared between the source and the
+ final destination of the message.
+
+ o Server-initiated messages that MUST be received by a specific
+ Diameter client (e.g., access device), such as the Abort-Session-
+ Request message, which is used to request that a particular user's
+ session be terminated.
+
+ Note that an agent can only forward a request to a host described in
+ the Destination-Host AVP if the host in question is included in its
+ peer table (see Section 2.6). Otherwise, the request is routed based
+ on the Destination-Realm only (see Section 6.1.6).
+
+ When a message is received, the message is processed in the following
+ order:
+
+ o If the message is destined for the local host, the procedures
+ listed in Section 6.1.4 are followed.
+
+ o If the message is intended for a Diameter peer with whom the local
+ host is able to directly communicate, the procedures listed in
+ Section 6.1.5 are followed. This is known as "Request
+ Forwarding".
+
+ o The procedure listed in Section 6.1.6 is followed, which is known
+ as "Request Routing".
+
+ o If none of the above are successful, an answer is returned with
+ the Result-Code set to DIAMETER_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.
+
+ The overview contained in this section (6.1) is intended to provide
+ general guidelines to Diameter developers. 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, in addition to any other procedures
+ described in the application definition for that specific request,
+ the following procedures MUST be followed:
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 75]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o the Command Code is set to the appropriate value;
+
+ o the 'R' bit is set;
+
+ o the End-to-End Identifier is set to a locally unique value;
+
+ o the Origin-Host and Origin-Realm AVPs MUST be set to the
+ appropriate values, used to identify the source of the message;
+ and
+
+ o the Destination-Host and Destination-Realm AVPs MUST be set to the
+ appropriate values, as described in Section 6.1.
+
+6.1.2. Sending a Request
+
+ When sending a request, originated either locally or as the result of
+ a forwarding or routing operation, the following procedures SHOULD be
+ followed:
+
+ o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
+
+ o 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 such an event occurs, the agent MUST answer
+ with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
+
+6.1.4. Processing Local Requests
+
+ A request is known to be for local consumption when one of the
+ following conditions occurs:
+
+ o The Destination-Host AVP contains the local host's identity;
+
+ o The Destination-Host AVP is not present, the Destination-Realm AVP
+ contains a realm the server is configured to process locally, and
+ the Diameter application is locally supported; or
+
+ o Both the Destination-Host and the Destination-Realm are not
+ present.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 76]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ When a request is locally processed, the rules in Section 6.2 should
+ be used to generate the corresponding answer.
+
+6.1.5. Request Forwarding
+
+ Request forwarding is done using the Diameter peer table. The
+ Diameter peer table contains all of the peers with which the local
+ node is able to directly communicate.
+
+ When a request is received, and the host encoded in the Destination-
+ Host AVP is one that is present in the peer table, the message SHOULD
+ be forwarded to the 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 aid in 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 have a list of locally supported realms and
+ applications, and they MAY have a list of externally supported realms
+ and applications. When a request is received 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 performing the processing described in Section 6.1.3, SHOULD check
+ for the presence of a candidate route's peer identity in any of the
+ Route-Record AVPs. In the event of the agent detecting the presence
+ of a candidate route's peer identity in a Route-Record AVP, the agent
+ MUST ignore such a route for the Diameter request message and attempt
+ alternate routes if any exist. In case all the candidate routes are
+ eliminated by the above criteria, the agent SHOULD return a
+ DIAMETER_UNABLE_TO_DELIVER message.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 77]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+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 to DIAMETER_REDIRECT_INDICATION. Each of
+ the servers associated with the routing entry are added in a separate
+ Redirect-Host AVP.
+
+ +------------------+
+ | Diameter |
+ | Redirect Agent |
+ +------------------+
+ ^ | 2. command + 'E' bit
+ 1. Request | | Result-Code =
+ [email protected] | | DIAMETER_REDIRECT_INDICATION +
+ | | Redirect-Host AVP(s)
+ | v
+ +-------------+ 3. Request +-------------+
+ | example.com |------------->| example.net |
+ | Relay | | Diameter |
+ | Agent |<-------------| Server |
+ +-------------+ 4. Answer +-------------+
+
+ Figure 5: Diameter Redirect Agent
+
+ The 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 identify the request in the
+ pending message queue (see Section 5.5.4) that is 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 selects 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 such a route
+ entry is set by the value of Redirect-Host-Usage AVP and the lifetime
+ of the cached route entry is set by Redirect-Max-Cache-Time AVP
+ value.
+
+ It is possible that multiple redirect indications can create multiple
+ cached route entries differing only in their redirect usage and the
+ peer to forward messages to. As an example, two(2) route entries
+ that are created by two(2) redirect indications results in two(2)
+
+
+
+Fajardo, et al. Standards Track [Page 78]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ cached routes for the same realm and Application Id. However, one
+ has a redirect usage of ALL_SESSION, where matching requests will be
+ forwarded to one peer; the other has a redirect usage of ALL_REALM,
+ where request are forwarded to another peer. Therefore, an incoming
+ request that matches the realm and Application Id of both routes will
+ need additional resolution. In such a case, a routing precedence
+ rule MUST be used against the redirect usage value to resolve the
+ contention. The precedence rule can be found in Section 6.13.
+
+6.1.9. Relaying and Proxying Requests
+
+ A relay or proxy agent MUST append a Route-Record AVP to all requests
+ forwarded. The AVP contains the identity of the peer from which the
+ request was received.
+
+ The Hop-by-Hop Identifier in the request is saved and replaced with a
+ locally unique value. The source of the request is also saved, which
+ includes the IP address, port, and protocol.
+
+ A relay or proxy agent MAY include the Proxy-Info AVP in requests if
+ it requires access to any local state information when the
+ corresponding response is received. The Proxy-Info AVP has security
+ implications as state information is distributed to other entities.
+ As such, it is RECOMMENDED that the content of the Proxy-Info AVP be
+ protected with cryptographic mechanisms, for example, by using a
+ keyed message digest such as HMAC-SHA1 [RFC2104]. Such a mechanism,
+ however, requires the management of keys, although only locally at
+ the Diameter server. Still, a full description of the management of
+ the keys used to protect the Proxy-Info AVP is beyond the scope of
+ this document. Below is a list of common recommendations:
+
+ o The keys should be generated securely following the randomness
+ recommendations in [RFC4086].
+
+ o The keys and cryptographic protection algorithms should be at
+ least 128 bits in strength.
+
+ o The keys should not be used for any other purpose than generating
+ and verifying instances of the Proxy-Info AVP.
+
+ o The keys should be changed regularly.
+
+ o 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 79]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Figure 6 provides an example of message routing using the procedures
+ listed in 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 perform full inspection of
+ incoming messages. At a minimum, validation of the message header
+ and relevant routing AVPs has to be done when relaying messages.
+ Proxy agents may optionally perform more in-depth message validation
+ for applications in which it is interested.
+
+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:
+
+ o The same Hop-by-Hop Identifier in the request is used in the
+ answer.
+
+ o The local host's identity is encoded in the Origin-Host AVP.
+
+ o The Destination-Host and Destination-Realm AVPs MUST NOT be
+ present in the answer message.
+
+ o The Result-Code AVP is added with its value indicating success or
+ failure.
+
+ o If the Session-Id is present in the request, it MUST be included
+ in the answer.
+
+ o Any Proxy-Info AVPs in the request MUST be added to the answer
+ message, in the same order they were present in the request.
+
+
+
+
+Fajardo, et al. Standards Track [Page 80]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o The 'P' bit is set to the same value as the one in the request.
+
+ o The same End-to-End identifier in the request is used in the
+ answer.
+
+ Note that the error messages (see Section 7) are also subjected to
+ the above processing rules.
+
+6.2.1. Processing Received Answers
+
+ A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
+ answer received against the list of pending requests. The
+ corresponding message should be removed from the list of pending
+ requests. It SHOULD ignore answers received that do not 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 receives an answer
+ message with a Result-Code AVP indicating success, and it wishes to
+ modify the AVP 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 that 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.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 81]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 as
+ 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 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 to which the message is to be routed. 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 is known a priori). When present, the
+ Destination-Realm AVP is used to perform 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 82]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 in order 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 83]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+6.9. Acct-Application-Id AVP
+
+ The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
+ is used in order 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 in order 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
+
+ The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
+ Grouped and is used to advertise support of 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 Auth-Application-Id or Acct-
+ Application-Id AVP MUST comply with vendor-specific Application Id
+ assignment described in Section 11.3. It MUST also match the
+ Application Id present in the Diameter header except when used in a
+ CER or CEA message.
+
+ The Vendor-Id AVP is an informational AVP pertaining to the vendor
+ who may have authorship of the vendor-specific Diameter application.
+ It MUST NOT be used as a means of defining a completely separate
+ vendor-specific Application Id space.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 84]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 of 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.
+
+ Upon receiving the above, the receiving Diameter node 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 of type Enumerated.
+ This AVP MAY be present in answer messages whose 'E' bit is set and
+ the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
+
+ When present, this AVP provides hints about how the routing entry
+ resulting from the Redirect-Host is to be used. The following values
+ are supported:
+
+
+
+
+Fajardo, et al. Standards Track [Page 85]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DONT_CACHE 0
+
+ The host specified in the Redirect-Host AVP SHOULD NOT be cached.
+ This is the default value.
+
+ ALL_SESSION 1
+
+ All messages within the same session, as defined by the same value
+ of the Session-ID AVP SHOULD be sent to the host specified in the
+ Redirect-Host AVP.
+
+ ALL_REALM 2
+
+ All messages destined for the realm requested SHOULD be sent to
+ the host specified in the Redirect-Host AVP.
+
+ REALM_AND_APPLICATION 3
+
+ All messages for the application requested to the realm specified
+ SHOULD be sent to the host specified in the Redirect-Host AVP.
+
+ ALL_APPLICATION 4
+
+ All messages for the application requested SHOULD be sent to the
+ host specified in the Redirect-Host AVP.
+
+ ALL_HOST 5
+
+ All messages that would be sent to the host that generated the
+ Redirect-Host SHOULD be sent to the host specified in the
+ Redirect-Host AVP.
+
+ ALL_USER 6
+
+ All messages for the user requested SHOULD be sent to the host
+ specified in the Redirect-Host AVP.
+
+ 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 dictate which redirect usage should be considered before any
+ other as they appear. The order is as follows:
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 86]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 1. ALL_SESSION
+
+ 2. ALL_USER
+
+ 3. REALM_AND_APPLICATION
+
+ 4. ALL_REALM
+
+ 5. ALL_APPLICATION
+
+ 6. ALL_HOST
+
+6.14. Redirect-Max-Cache-Time AVP
+
+ The Redirect-Max-Cache-Time AVP (AVP Code 262) is of 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 set to a non-zero value.
+
+ This AVP contains 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.
+
+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 (e.g., a
+ message routing error). Application errors, on the other hand,
+ generally occur due to a problem with a function specified in a
+ Diameter application (e.g., user authentication, 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.
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 87]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 provides 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.
+
+ +---------+ 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 provides 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;
+ therefore, the message would be forwarded back to the originator of
+ the request.
+
+ 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.
+
+
+
+Fajardo, et al. Standards Track [Page 88]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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:
+
+ o A request with an unrecognized AVP is received with the 'M' bit
+ (Mandatory bit) set causes an answer to be sent with the Result-
+ Code AVP set to DIAMETER_AVP_UNSUPPORTED and the Failed-AVP AVP
+ containing the offending AVP.
+
+ o 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.
+
+ o A received command that is missing AVPs that are defined as
+ required in the commands CCF; examples are AVPs indicated as
+ {AVP}. The receiver issues an answer with the Result-Code set to
+ DIAMETER_MISSING_AVP and 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 of 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:
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 89]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o 1xxx (Informational)
+
+ o 2xxx (Success)
+
+ o 3xxx (Protocol Errors)
+
+ o 4xxx (Transient Failures)
+
+ o 5xxx (Permanent Failure)
+
+ An unrecognized class (one whose first digit is not defined in this
+ section) MUST be handled as a permanent failure.
+
+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.
+
+7.1.2. Success
+
+ Errors that fall within the Success category are used to inform a
+ peer that a request has been successfully completed.
+
+ DIAMETER_SUCCESS 2001
+
+ The request was successfully completed.
+
+ DIAMETER_LIMITED_SUCCESS 2002
+
+ When returned, the request was successfully completed, but
+ additional processing is required by the application in order to
+ provide service to the user.
+
+7.1.3. Protocol Errors
+
+ Errors that fall within the Protocol Error category SHOULD be treated
+ on a per-hop basis, and Diameter proxies MAY attempt to correct the
+ error, if it is possible. Note that these errors MUST only be used
+ in answer messages whose 'E' bit is set.
+
+
+
+
+Fajardo, et al. Standards Track [Page 90]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DIAMETER_COMMAND_UNSUPPORTED 3001
+
+ This error code is used when a Diameter entity receives a message
+ with a Command Code that it does not support.
+
+ DIAMETER_UNABLE_TO_DELIVER 3002
+
+ This error is given when Diameter cannot deliver the message to
+ the destination, either because no host within the realm
+ supporting the required application was available to process the
+ request or because the Destination-Host AVP was given without the
+ associated Destination-Realm AVP.
+
+ DIAMETER_REALM_NOT_SERVED 3003
+
+ The intended realm of the request is not recognized.
+
+ DIAMETER_TOO_BUSY 3004
+
+ When returned, a Diameter node SHOULD attempt to send the message
+ to an alternate peer. This error MUST only be used when a
+ specific server is requested, and it cannot provide the requested
+ service.
+
+ DIAMETER_LOOP_DETECTED 3005
+
+ An agent detected 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
+ identified a configuration problem.
+
+ DIAMETER_REDIRECT_INDICATION 3006
+
+ A redirect agent has determined that the request could not be
+ satisfied locally, and the initiator of the request SHOULD direct
+ the request directly to the server, whose contact information has
+ been added to the response. When set, the Redirect-Host AVP MUST
+ be present.
+
+ DIAMETER_APPLICATION_UNSUPPORTED 3007
+
+ A request was sent for an application that is not supported.
+
+ DIAMETER_INVALID_HDR_BITS 3008
+
+ A request was received whose bits in the Diameter header were set
+ either to an invalid combination or to a value that is
+ inconsistent with the Command Code's definition.
+
+
+
+Fajardo, et al. Standards Track [Page 91]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DIAMETER_INVALID_AVP_BITS 3009
+
+ A request was received that included an AVP whose flag bits are
+ set to an unrecognized value or that is inconsistent with the
+ AVP's definition.
+
+ DIAMETER_UNKNOWN_PEER 3010
+
+ A CER was received from an unknown peer.
+
+7.1.4. Transient Failures
+
+ Errors that fall within the transient failures category are used to
+ inform a peer that the request could not be satisfied at the time it
+ was received but MAY be able to satisfy the request 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 due to
+ an invalid password used by the user. Further attempts MUST only
+ be tried after prompting the user for a new password.
+
+ DIAMETER_OUT_OF_SPACE 4002
+
+ A Diameter node received the accounting request but was unable to
+ commit it to stable storage due to a temporary lack of space.
+
+ ELECTION_LOST 4003
+
+ The peer has determined that it has lost the election process and
+ has therefore disconnected the transport connection.
+
+7.1.5. Permanent Failures
+
+ Errors that fall within the permanent failures category are used to
+ inform the peer that the request failed and should not be attempted
+ again. Note that these errors SHOULD be used in answer messages
+ whose 'E' bit is not set. In error conditions where it is not
+ possible or efficient to compose application-specific answer grammar,
+ answer messages with the 'E' bit set and which comply to the grammar
+ described in Section 7.2 MAY also be used for permanent errors.
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 92]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DIAMETER_AVP_UNSUPPORTED 5001
+
+ The peer received a message that contained an AVP that is not
+ recognized or supported and was marked with the 'M' (Mandatory)
+ bit. A Diameter message with this error MUST contain one or more
+ Failed-AVP AVPs containing the AVPs that caused the failure.
+
+ DIAMETER_UNKNOWN_SESSION_ID 5002
+
+ The request contained an unknown Session-Id.
+
+ DIAMETER_AUTHORIZATION_REJECTED 5003
+
+ A request was received for which the user could not be authorized.
+ This error could occur if the service requested is not permitted
+ to the user.
+
+ DIAMETER_INVALID_AVP_VALUE 5004
+
+ The request contained an AVP with an invalid value in its data
+ portion. A Diameter message indicating this error MUST include
+ the offending AVPs within a Failed-AVP AVP.
+
+ DIAMETER_MISSING_AVP 5005
+
+ The request did not contain an AVP that is required by the Command
+ Code definition. If this value is sent 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 was received that cannot be authorized because the user
+ has already expended allowed resources. An example of this error
+ condition is when a user that is restricted to one dial-up PPP
+ port attempts to establish a second PPP connection.
+
+ DIAMETER_CONTRADICTING_AVPS 5007
+
+ The Home Diameter server has detected AVPs in the request that
+ contradicted each other, and it is not willing to provide service
+ to the user. The Failed-AVP AVP MUST be present, which contain
+ the AVPs that contradicted each other.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 93]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ DIAMETER_AVP_NOT_ALLOWED 5008
+
+ A message was received 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 was received that included an AVP that appeared more
+ often than permitted in the message definition. The Failed-AVP
+ AVP MUST be included and contain a copy of the first instance of
+ the offending AVP that exceeded the maximum number of occurrences.
+
+ DIAMETER_NO_COMMON_APPLICATION 5010
+
+ This error is returned by a Diameter node that receives a CER
+ whereby no applications are common between the CER sending peer
+ and the CER receiving peer.
+
+ DIAMETER_UNSUPPORTED_VERSION 5011
+
+ This error is returned when a request was received, whose version
+ number is unsupported.
+
+ DIAMETER_UNABLE_TO_COMPLY 5012
+
+ This error is returned when a request is rejected for unspecified
+ reasons.
+
+ DIAMETER_INVALID_BIT_IN_HEADER 5013
+
+ This error is returned when a reserved bit in the Diameter header
+ is set to one (1) or the bits in the Diameter header are set
+ incorrectly.
+
+ DIAMETER_INVALID_AVP_LENGTH 5014
+
+ The request contained an AVP with an invalid length. A Diameter
+ message indicating this error MUST include the offending AVPs
+ within a Failed-AVP AVP. In cases where the erroneous AVP length
+ value exceeds the message length or is less than the minimum AVP
+ header length, it is sufficient to include the offending AVP
+ header and a zero filled payload of the minimum required length
+ for the payloads data type. If the AVP is a Grouped AVP, the
+ Grouped AVP header with an empty payload would be sufficient to
+ indicate the offending AVP. In the case where the offending AVP
+ header cannot be fully decoded when the AVP length is less than
+
+
+
+
+Fajardo, et al. Standards Track [Page 94]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ the minimum AVP header length, it is sufficient to include an
+ offending AVP header that is formulated by padding the incomplete
+ AVP header with zero up to the minimum AVP header length.
+
+ DIAMETER_INVALID_MESSAGE_LENGTH 5015
+
+ This error is returned when a request is received with an invalid
+ message length.
+
+ DIAMETER_INVALID_AVP_BIT_COMBO 5016
+
+ The request contained an AVP with which is not allowed to have the
+ given value in the AVP Flags field. A Diameter message indicating
+ this error MUST include the offending AVPs within a Failed-AVP
+ AVP.
+
+ DIAMETER_NO_COMMON_SECURITY 5017
+
+ This error is returned when a CER message is received, and there
+ are no common security mechanisms supported between the 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 is 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 is still subjected to the
+ processing rules defined in Section 6.2. When set, the answer
+ message will not conform to the CCF specification for the command;
+ instead, it and will conform to the following 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 ]
+
+
+
+
+Fajardo, et al. Standards Track [Page 95]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Note that the code used in the header is the same than the one found
+ in the request message, but with the 'R' bit cleared and the 'E' bit
+ set. The 'P' bit in the header is set to the same value as the one
+ found in the request message.
+
+7.3. Error-Message AVP
+
+ The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY
+ accompany a Result-Code AVP as a human-readable error message. The
+ Error-Message AVP is not intended to be useful in an environment
+ where error messages are processed automatically. It SHOULD NOT be
+ expected that the content of this AVP be parsed by network entities.
+
+7.4. Error-Reporting-Host AVP
+
+ The Error-Reporting-Host AVP (AVP Code 294) is of type
+ DiameterIdentity. This AVP contains the identity of the Diameter
+ host that sent the Result-Code AVP to a value other than 2001
+ (Success), only if the host setting the Result-Code is different from
+ the one encoded in the Origin-Host AVP. This AVP is intended to be
+ used for troubleshooting purposes, and it MUST be set when the
+ Result-Code AVP indicates a failure.
+
+7.5. Failed-AVP AVP
+
+ The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
+ debugging information in cases where a request is rejected or not
+ fully processed due to erroneous information in a specific AVP. The
+ value of the Result-Code AVP will provide information on the reason
+ for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
+ instance of the Failed-AVP AVP that corresponds to the error
+ indicated by the Result-Code AVP. For practical purposes, this
+ Failed-AVP would typically refer to the first AVP processing error
+ that a Diameter node encounters.
+
+ The possible reasons for this AVP are the presence of an improperly
+ constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
+ value, the omission of a required AVP, the presence of an explicitly
+ excluded AVP (see tables in Section 10) or the presence of two or
+ more occurrences of an AVP that is restricted to 0, 1, or 0-1
+ occurrences.
+
+ A Diameter message SHOULD contain one Failed-AVP AVP, containing the
+ entire AVP that could not be processed successfully. If the failure
+ reason is omission of a required AVP, an AVP with the missing AVP
+ code, the missing Vendor-Id, and a zero-filled payload of the minimum
+ required length for the omitted AVP will be added. If the failure
+ reason is an invalid AVP length where the reported length is less
+
+
+
+Fajardo, et al. Standards Track [Page 96]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ In the case where 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 itself is embedded in yet another grouped AVP and so on.
+ In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
+ to the single offending AVP. This enables the recipient to detect
+ the location of the offending AVP when embedded in 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
+ indicates whether a particular vendor-specific request was completed
+ successfully or whether an error occurred. This AVP has the
+ following structure:
+
+ 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 the assignment of 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.
+
+7.7. Experimental-Result-Code AVP
+
+ The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32
+ and contains 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 regarding the different
+ types of result codes and the handling of errors (for non-2xxx
+ values).
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 97]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+8. Diameter User Sessions
+
+ 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. The
+ auth request is defined in a service-specific Diameter application
+ (e.g., NASREQ). The request contains a Session-Id AVP, which is used
+ in subsequent messages (e.g., subsequent authorization, accounting,
+ etc.) relating to the user's session. The Session-Id AVP is a means
+ for the client and servers to correlate a Diameter message with a
+ user session.
+
+ When a Diameter server authorizes a user to implement network
+ resources for a finite amount of time, and it is willing to extend
+ the 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 another authorization
+ request is expected by the server. The Auth-Grace-Period AVP
+ contains the number of seconds following the expiration of the
+ Authorization-Lifetime, after which the server will release all state
+ information related to the user's session. Note that 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 for which the home
+ realm is willing to be fiscally responsible. Services provided past
+ the expiration of the Authorization-Lifetime and Auth-Grace-Period
+ AVPs are the responsibility of the access device. Of course, the
+ actual cost of services rendered is clearly outside the scope of the
+ protocol.
+
+ 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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 98]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The base protocol does not include any authorization request
+ messages, since these are largely application-specific and are
+ defined in a Diameter application document. However, the base
+ protocol does define a set of messages that are used to terminate
+ user sessions. These are used to allow servers that maintain state
+ information to free 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, the
+ session termination messages are not used, since a session is
+ signaled as being terminated by issuing an accounting stop message.
+
+ Diameter may also be used for services that cannot be easily
+ categorized as authentication, authorization, or accounting (e.g.,
+ certain Third Generation Partnership Project Internet Multimedia
+ System (3GPP IMS) interfaces). In such 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,
+ ASR/ASA messages for stateful sessions.
+
+8.1. Authorization Session State Machine
+
+ This section contains a set of finite state machines, which represent
+ the life cycle of Diameter sessions and which MUST be observed by all
+ Diameter implementations that make use of the authentication and/or
+ authorization portion of a Diameter application. The term "Service-
+ Specific" below refers to a message defined in a Diameter application
+ (e.g., Mobile IPv4, NASREQ).
+
+ There are four different authorization session state machines
+ supported in the Diameter base protocol. The first two describe a
+ session in which the server is maintaining session state, indicated
+ by the value of the Auth-Session-State AVP (or its absence). One
+ describes the session from a client perspective, the other from a
+ server perspective. The second two state machines are used when the
+ server does not maintain session state. Here again, one describes
+ the session from a client perspective, the other from a server
+ perspective.
+
+ When a session is moved to the Idle state, any resources that were
+ allocated for the particular session must be released. Any event not
+ listed in the state machines MUST be considered an error condition,
+ and an answer, if applicable, MUST be returned to the originator of
+ the message.
+
+
+
+Fajardo, et al. Standards Track [Page 99]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ In the case that an application does not support re-auth, the state
+ transitions related to server-initiated re-auth, when both client and
+ server sessions maintain state (e.g., Send RAR, Pending, Receive
+ RAA), MAY be ignored.
+
+ In the state table, the event "Failure to send X" means that the
+ Diameter agent is unable to send command X to the desired
+ destination. This could be due to the peer being down or due to the
+ peer sending back a transient failure or temporary protocol error
+ notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the
+ Result-Code AVP of the corresponding Answer command. The event 'X
+ successfully sent' is the complement of 'Failure to send X'.
+
+ The following state machine is observed by a client when state is
+ maintained on the server:
+
+ 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
+
+
+
+Fajardo, et al. Standards Track [Page 100]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 101]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Discon STA received Discon. Idle
+ user/device
+
+ The following state machine is observed by a server when it is
+ maintaining 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
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 102]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 up
+
+ The following state machine is observed by a client when state is not
+ maintained on the server:
+
+ 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/device
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 103]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ The following state machine is observed by a server when it is not
+ maintaining state for the session:
+
+ SERVER, STATELESS
+ State Event Action New State
+ ---------------------------------------------------------------
+ Idle Service-specific authorization Send Idle
+ request received, and service-
+ successfully processed specific
+ answer
+
+8.2. Accounting Session State Machine
+
+ The following state machines MUST be supported for applications that
+ have an accounting portion or that require only accounting services.
+ The first state machine is to be observed by clients.
+
+ See Section 9.7 for Accounting Command Codes and Section 9.8 for
+ Accounting AVPs.
+
+ The server side in the accounting state machine depends in some cases
+ on the particular application. The Diameter base protocol defines a
+ default state machine that MUST be followed by all applications that
+ have not specified other state machines. This is the second state
+ machine in this section described below.
+
+ The default server side state machine requires the reception of
+ accounting records in any order and at any time, and it does not
+ place any standards requirement on the processing of these records.
+ Implementations of Diameter may perform checking, ordering,
+ correlation, fraud detection, and other tasks based on these records.
+ AVPs may need to be inspected as a part of these tasks. The tasks
+ can happen either immediately after record reception or in a post-
+ processing phase. However, as these tasks are typically application
+ or even policy dependent, they are not standardized by the Diameter
+ specifications. Applications MAY define requirements on when to
+ accept accounting records based on the used value of Accounting-
+ Realtime-Required AVP, credit-limit checks, and so on.
+
+ However, the Diameter base protocol defines one optional server side
+ state machine that MAY be followed by applications that require
+ keeping track of the session state at the accounting server. Note
+ that such tracking is incompatible with the ability to sustain long
+ duration connectivity problems. Therefore, the use of this state
+ machine is recommended only in applications where the value of the
+ Accounting-Realtime-Required AVP is DELIVER_AND_GRANT; hence,
+ accounting connectivity problems are required to cause the serviced
+ user to be disconnected. Otherwise, records produced by the client
+
+
+
+Fajardo, et al. Standards Track [Page 104]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ may be lost by the server, which no longer accepts them after the
+ connectivity is re-established. This state machine is the third
+ state machine in this section. The state machine is supervised by a
+ supervision session timer Ts, whose value should be reasonably higher
+ than the Acct_Interim_Interval value. Ts MAY be set to two times the
+ value of the Acct_Interim_Interval so as to avoid the accounting
+ session in the Diameter server to change to Idle state in case of
+ short transient network failure.
+
+ Any event not listed in the state machines MUST be considered as an
+ error condition, and a corresponding answer, if applicable, MUST be
+ returned to the originator of the message.
+
+ In the state table, the event "Failure to send" means that the
+ Diameter client is unable to communicate with the desired
+ destination. This could be due to the peer being down, or due to the
+ peer sending back a transient failure or temporary protocol error
+ notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
+ DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
+ Answer command.
+
+ The event "Failed answer" means that the Diameter client received a
+ non-transient failure notification in the Accounting Answer command.
+
+ Note that the action "Disconnect user/dev" MUST also have an effect
+ on the authorization session state table, e.g., cause the STR message
+ to be sent, if the given application has both authentication/
+ authorization and accounting portions.
+
+ The states PendingS, PendingI, PendingL, PendingE, and PendingB stand
+ for pending states to wait for an answer to an accounting request
+ related to a Start, Interim, Stop, Event, or buffered record,
+ respectively.
+
+ 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
+
+
+
+
+Fajardo, et al. Standards Track [Page 105]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 106]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+Fajardo, et al. Standards Track [Page 107]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 108]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+ expired
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 109]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+8.3. Server-Initiated Re-Auth
+
+ A Diameter server may initiate a re-authentication and/or re-
+ authorization service for a particular session by issuing a Re-Auth-
+ Request (RAR).
+
+ For example, for prepaid services, the Diameter server that
+ originally authorized a session may need some confirmation that the
+ user is still using the services.
+
+ An access device that receives an RAR message with the Session-Id
+ equal to a currently active session MUST initiate a re-auth towards
+ the user, if the service supports this particular feature. Each
+ Diameter application MUST state whether server-initiated re-auth is
+ supported, since some applications do not allow access devices to
+ prompt the user for re-auth.
+
+8.3.1. Re-Auth-Request
+
+ The Re-Auth-Request (RAR), indicated by the Command Code set to 258
+ and the message flags' 'R' bit set, may be sent by any server to the
+ access device that is providing session service, to request that the
+ user be re-authenticated and/or re-authorized.
+
+
+ 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), indicated by the Command Code set to 258
+ and the message flags' 'R' bit clear, is sent in response to the RAR.
+ The Result-Code AVP MUST be present, and it indicates the disposition
+ of the request.
+
+
+
+
+Fajardo, et al. Standards Track [Page 110]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ A successful RAA message MUST be followed by an application-specific
+ authentication and/or authorization message.
+
+ 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
+
+ It is necessary for a Diameter server that authorized a session, for
+ which it is maintaining state, to be notified when that session is no
+ longer active, both for tracking purposes as well as to allow
+ stateful agents to release any resources that they may have provided
+ for the user's session. For sessions whose state is not being
+ maintained, this section is not used.
+
+ When a user session that required Diameter authorization terminates,
+ the access device that provided the service MUST issue a Session-
+ Termination-Request (STR) message to the Diameter server that
+ authorized the service, to notify it that the session is no longer
+ active. An STR MUST be issued when a user session terminates for any
+ reason, including user logoff, expiration of Session-Timeout,
+ administrative action, termination upon receipt of an Abort-Session-
+ Request (see below), orderly shutdown of the access device, etc.
+
+ The access device also MUST issue an STR for a session that was
+ authorized but never actually started. This could occur, for
+ example, due to a sudden resource shortage in the access device, or
+ because the access device is unwilling to provide the type of service
+ requested in the authorization, or because the access device does not
+ support a mandatory AVP returned in the authorization, etc.
+
+ It is also possible that a session that was authorized is never
+ actually started due to action of a proxy. For example, a proxy may
+
+
+
+Fajardo, et al. Standards Track [Page 111]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ modify an authorization answer, converting the result from success to
+ failure, prior to forwarding the message to the access device. If
+ the answer did not contain an Auth-Session-State AVP with the value
+ NO_STATE_MAINTAINED, a proxy that causes an authorized session not to
+ be started MUST issue an STR to the Diameter server that authorized
+ the session, since the access device has no way of knowing that the
+ session had been authorized.
+
+ A Diameter server that receives an STR message MUST clean up
+ resources (e.g., session state) associated with the Session-Id
+ specified in the STR and return 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 receipt of a re-authorization
+ request, regardless of whether an STR for that session is received.
+ The access device is not expected to provide service beyond the
+ expiration of these timers; thus, expiration of either of these
+ timers implies that the access device may have unexpectedly shut
+ down.
+
+8.4.1. Session-Termination-Request
+
+ The Session-Termination-Request (STR), indicated by the Command Code
+ set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter
+ client or by a Diameter proxy to inform the Diameter server that an
+ authenticated and/or authorized session is being terminated.
+
+ 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 ]
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 112]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+8.4.2. Session-Termination-Answer
+
+ The Session-Termination-Answer (STA), indicated by the Command Code
+ set to 275 and the message flags' 'R' bit clear, is sent by the
+ Diameter server to acknowledge the notification that the session has
+ been terminated. The Result-Code AVP MUST be present, and it MAY
+ contain an indication that an error occurred while servicing the STR.
+
+ Upon sending or receipt of the STA, the Diameter server MUST release
+ all resources for the session indicated by the Session-Id AVP. Any
+ intermediate server in the Proxy-Chain MAY also release any
+ resources, if necessary.
+
+ 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
+
+ A Diameter server may request that the access device stop providing
+ service for a particular session by issuing an Abort-Session-Request
+ (ASR).
+
+ For example, the Diameter server that originally authorized the
+ session may be required to cause that session to be stopped for lack
+ of credit or other reasons that were not anticipated when the session
+ was first authorized.
+
+ An access device that receives an ASR with Session-ID equal to a
+ currently active session MAY stop the session. Whether the access
+ device stops the session or not is implementation and/or
+ configuration dependent. For example, an access device may honor
+ ASRs from certain agents only. In any case, the access device MUST
+
+
+
+Fajardo, et al. Standards Track [Page 113]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ respond with an Abort-Session-Answer, including a Result-Code AVP to
+ indicate what action it took.
+
+8.5.1. Abort-Session-Request
+
+ The Abort-Session-Request (ASR), indicated by the Command Code set to
+ 274 and the message flags' 'R' bit set, may be sent by any Diameter
+ server or any Diameter proxy to the access device that is providing
+ session service, to request that the session identified by the
+ Session-Id be stopped.
+
+ 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), indicated by the Command Code set to
+ 274 and the message flags' 'R' bit clear, is sent in response to the
+ ASR. The Result-Code AVP MUST be present and indicates the
+ disposition of the request.
+
+ If the session identified by Session-Id in the ASR was successfully
+ terminated, the Result-Code is set to DIAMETER_SUCCESS. If the
+ session is not currently active, the Result-Code is set to
+ DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
+ session for any other reason, the Result-Code is set to
+ DIAMETER_UNABLE_TO_COMPLY.
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 114]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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 used to allow detection of terminated sessions
+ for which no STR would have been issued, due to unanticipated
+ shutdown of an access device.
+
+ A Diameter client or access device increments the value of the
+ Origin-State-Id every time it is started or powered up. The new
+ Origin-State-Id is then sent in the CER/CEA message immediately upon
+ connection to the server. The Diameter server receiving the new
+ Origin-State-Id can determine whether the sending Diameter client had
+ abruptly shut down by comparing the old value of the Origin-State-Id
+ it has kept for that specific client is less than the new value and
+ whether it has un-terminated sessions originating from that client.
+
+ An access device can also include the Origin-State-Id in request
+ messages other than the CER if there are relays or proxies in between
+ the access device and the server. In this case, however, the server
+ cannot discover that the access device has been restarted unless and
+ until it receives a new request from it. Therefore, this mechanism
+ is more opportunistic across proxies and relays.
+
+ The Diameter server may assume that all sessions that were active
+ prior to detection of a client restart have been terminated. The
+ Diameter server MAY clean up all session state associated with such
+ lost sessions, and it MAY also issue STRs for all such lost sessions
+ that were authorized on upstream servers, to allow session state to
+ be cleaned up globally.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 115]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+8.7. Auth-Request-Type AVP
+
+ The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
+ included in application-specific auth requests to inform the peers
+ whether a user is to be authenticated only, authorized only, or both.
+ Note any value other than both MAY cause RADIUS interoperability
+ issues. The following values are defined:
+
+ AUTHENTICATE_ONLY 1
+
+ The request being sent is for authentication only, and it MUST
+ contain the relevant application-specific authentication AVPs that
+ are needed by the Diameter server to authenticate the user.
+
+ AUTHORIZE_ONLY 2
+
+ The request being sent is for authorization only, and it MUST
+ contain the application-specific authorization AVPs that are
+ necessary to identify the service being requested/offered.
+
+ AUTHORIZE_AUTHENTICATE 3
+
+ The request contains a request for both authentication and
+ authorization. The request MUST include both the relevant
+ application-specific authentication information and authorization
+ information necessary to identify the service being requested/
+ offered.
+
+8.8. Session-Id AVP
+
+ The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
+ to identify a specific session (see Section 8). All messages
+ pertaining to a specific session MUST include only one Session-Id
+ AVP, and the same value MUST be used throughout the life of a
+ session. When present, the Session-Id SHOULD appear immediately
+ following the Diameter header (see Section 3).
+
+ The Session-Id MUST be globally and eternally unique, as it is meant
+ to uniquely identify a user session without reference to any other
+ information, and it may be needed to correlate historical
+ authentication information with accounting information. The
+ Session-Id includes a mandatory portion and an implementation-defined
+ portion; a recommended format for the implementation-defined portion
+ is outlined below.
+
+ The Session-Id MUST begin with the sender's identity encoded in the
+ DiameterIdentity type (see Section 4.3.1). The remainder of the
+ Session-Id is delimited by a ";" character, and it MAY be any
+
+
+
+Fajardo, et al. Standards Track [Page 116]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ sequence that the client can guarantee to be eternally unique;
+ however, the following format is recommended, (square brackets []
+ indicate an optional element):
+
+ <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
+
+ <high 32 bits> and <low 32 bits> are decimal representations of the
+ high and low 32 bits of a monotonically increasing 64-bit value. The
+ 64-bit value is rendered in two part to simplify formatting by 32-bit
+ processors. At startup, the high 32 bits of the 64-bit value MAY be
+ initialized to the time in NTP format [RFC5905], and the low 32 bits
+ MAY be initialized to zero. This will for practical purposes
+ eliminate the possibility of overlapping Session-Ids after a reboot,
+ assuming the reboot process takes longer than a second.
+ Alternatively, an implementation MAY keep track of the increasing
+ value in non-volatile memory.
+
+
+ <optional value> is implementation specific, but it may include a
+ modem's device Id, a Layer 2 address, timestamp, etc.
+
+ Example, in which there is no optional value:
+
+ accesspoint7.example.com;1876543210;523
+
+ Example, in which there is an optional value:
+
+ accesspoint7.example.com;1876543210;523;[email protected]
+
+ The Session-Id is created by the Diameter application initiating the
+ session, which, in most cases, is done by the client. Note that a
+ Session-Id MAY be used for both the authentication, authorization,
+ and accounting commands of a given application.
+
+8.9. Authorization-Lifetime AVP
+
+ The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
+ and contains the maximum number of seconds of service to be provided
+ to the user before the user is to be re-authenticated and/or re-
+ authorized. Care should be taken when the Authorization-Lifetime
+ value is determined, since a low, non-zero value could create
+ significant Diameter traffic, which could congest both the network
+ and the agents.
+
+ A value of zero (0) means that immediate re-auth is necessary by the
+ access device. The absence of this AVP, or a value of all ones
+ (meaning all bits in the 32-bit field are set to one) means no re-
+ auth is expected.
+
+
+
+Fajardo, et al. Standards Track [Page 117]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ If both this AVP and the Session-Timeout AVP are present in a
+ message, the value of the latter MUST NOT be smaller than the
+ Authorization-Lifetime AVP.
+
+ An Authorization-Lifetime AVP MAY be present in re-authorization
+ messages, and it contains the number of seconds the user is
+ authorized to receive service from the time the re-auth answer
+ message is received by the access device.
+
+ This AVP MAY be provided by the client as a hint of the maximum
+ lifetime that it is willing to accept. The server MUST return a
+ value that is equal to, or smaller than, the one provided by the
+ client.
+
+8.10. Auth-Grace-Period AVP
+
+ The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
+ contains the number of seconds the Diameter server will wait
+ following the expiration of the Authorization-Lifetime AVP before
+ cleaning up resources for the session.
+
+8.11. Auth-Session-State AVP
+
+ The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
+ specifies whether state is maintained for a particular session. The
+ client MAY include this AVP in requests as a hint to the server, but
+ the value in the server's answer message is binding. The following
+ values are supported:
+
+ STATE_MAINTAINED 0
+
+ This value is used to specify that session state is being
+ maintained, and the access device MUST issue a session termination
+ message when service to the user is terminated. This is the
+ default value.
+
+ NO_STATE_MAINTAINED 1
+
+ This value is used to specify that no session termination messages
+ will be sent by the access device upon expiration of the
+ Authorization-Lifetime.
+
+8.12. Re-Auth-Request-Type AVP
+
+ The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
+ is included in application-specific auth answers to inform the client
+ of the action expected upon expiration of the Authorization-Lifetime.
+
+
+
+
+Fajardo, et al. Standards Track [Page 118]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ If the answer message contains an Authorization-Lifetime AVP with a
+ positive value, the Re-Auth-Request-Type AVP MUST be present in an
+ answer message. The following values are defined:
+
+ AUTHORIZE_ONLY 0
+
+ An authorization only re-auth is expected upon expiration of the
+ Authorization-Lifetime. This is the default value if the AVP is
+ not present in answer messages that include the Authorization-
+ Lifetime.
+
+ AUTHORIZE_AUTHENTICATE 1
+
+ An authentication and authorization re-auth is expected upon
+ expiration of the Authorization-Lifetime.
+
+8.13. Session-Timeout AVP
+
+ The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32
+ and contains the maximum number of seconds of service to be provided
+ to the user before termination of the session. When both the
+ Session-Timeout and the Authorization-Lifetime AVPs are present in an
+ answer message, the former MUST be equal to or greater than the value
+ of the latter.
+
+ A session that terminates on an access device due to the expiration
+ of the Session-Timeout MUST cause an STR to be issued, unless both
+ the access device and the home server had previously agreed that no
+ session termination messages would be sent (see Section 8).
+
+ A Session-Timeout AVP MAY be present in a re-authorization answer
+ message, and it contains the remaining number of seconds from the
+ beginning of the re-auth.
+
+ A value of zero, or the absence of this AVP, means that this session
+ has an unlimited number of seconds before termination.
+
+ This AVP MAY be provided by the client as a hint of the maximum
+ timeout that it is willing to accept. However, the server MAY return
+ a value that is equal to, or smaller than, the one provided by the
+ client.
+
+8.14. User-Name AVP
+
+ The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which
+ contains the User-Name, in a format consistent with the NAI
+ specification [RFC4282].
+
+
+
+
+Fajardo, et al. Standards Track [Page 119]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+8.15. Termination-Cause AVP
+
+ The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
+ is used to indicate the reason why a session was terminated on the
+ access device. The currently assigned values for this AVP 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), of type Unsigned32, is a
+ monotonically increasing value that is advanced whenever a Diameter
+ entity restarts with loss of previous state, for example, upon
+ reboot. Origin-State-Id MAY be included in any Diameter message,
+ including CER.
+
+ A Diameter entity issuing this AVP MUST create a higher value for
+ this AVP each time its state is reset. A Diameter entity MAY set
+ Origin-State-Id to the time of startup, or it MAY use an incrementing
+ counter retained in non-volatile memory across restarts.
+
+ The Origin-State-Id, if present, MUST reflect the state of the entity
+ indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST
+ either remove Origin-State-Id or modify it appropriately as well.
+ Typically, Origin-State-Id is used by an access device that always
+ starts up with no active sessions; that is, any session active prior
+ to restart will have been lost. By including Origin-State-Id in a
+ message, it allows other Diameter entities to infer that sessions
+ associated with a lower Origin-State-Id are no longer active. If an
+ access device does not intend for such inferences to be made, it MUST
+ either not include Origin-State-Id in any message or set its value to
+ 0.
+
+8.17. Session-Binding AVP
+
+ The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and it
+ MAY be present in application-specific authorization answer messages.
+ If present, this AVP MAY inform the Diameter client that all future
+ application-specific re-auth and Session-Termination-Request messages
+ for this session MUST be sent to the same authorization server.
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 120]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ This field is a bit mask, and the following bits have been defined:
+
+ RE_AUTH 1
+
+ When set, future re-auth messages for this session MUST NOT
+ include the Destination-Host AVP. When cleared, the default
+ value, the Destination-Host AVP MUST be present in all re-auth
+ messages for this session.
+
+ STR 2
+
+ When set, the STR message for this session MUST NOT include the
+ Destination-Host AVP. When cleared, the default value, the
+ Destination-Host AVP MUST be present in the STR message for this
+ session.
+
+ ACCOUNTING 4
+
+ When set, all accounting messages for this session MUST NOT
+ include the Destination-Host AVP. When cleared, the default
+ value, the Destination-Host AVP, if known, MUST be present in all
+ accounting messages for this session.
+
+8.18. Session-Server-Failover AVP
+
+ The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated
+ and MAY be present in application-specific authorization answer
+ messages that either do not include the Session-Binding AVP or
+ include the Session-Binding AVP with any of the bits set to a zero
+ value. If present, this AVP MAY inform the Diameter client that if a
+ re-auth or STR message fails due to a delivery problem, the Diameter
+ client SHOULD issue a subsequent message without the Destination-Host
+ AVP. When absent, the default value is REFUSE_SERVICE.
+
+ The following values are supported:
+
+ REFUSE_SERVICE 0
+
+ If either the re-auth or the STR message delivery fails, terminate
+ service with the user and do not attempt any subsequent attempts.
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 121]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ TRY_AGAIN 1
+
+ If either the re-auth or the STR message delivery fails, resend
+ the failed message without the Destination-Host AVP present.
+
+ ALLOW_SERVICE 2
+
+ If re-auth message delivery fails, assume that re-authorization
+ succeeded. If STR message delivery fails, terminate the session.
+
+ TRY_AGAIN_ALLOW_SERVICE 3
+
+ 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 of type Unsigned32 and
+ SHOULD be present in application-specific authorization answer
+ messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
+ This AVP contains the maximum number of seconds that the access
+ device MUST provide the user in responding to an authentication
+ request.
+
+8.20. Class AVP
+
+ The Class AVP (AVP Code 25) is of type OctetString and is used by
+ Diameter servers to return state information to the access device.
+ When one or more Class AVPs are present in application-specific
+ authorization answer messages, they MUST be present in subsequent re-
+ authorization, session termination and accounting messages. Class
+ AVPs found in a re-authorization answer message override the ones
+ found in any previous authorization answer message. Diameter server
+ implementations SHOULD NOT return Class AVPs that require more than
+ 4096 bytes of storage on the Diameter client. A Diameter client that
+ receives Class AVPs whose size exceeds local available storage MUST
+ terminate the session.
+
+8.21. Event-Timestamp AVP
+
+ The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
+ in an Accounting-Request and Accounting-Answer messages to record the
+ time that the reported event occurred, in seconds since January 1,
+ 1900 00:00 UTC.
+
+
+
+
+Fajardo, et al. Standards Track [Page 122]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+9. Accounting
+
+ This accounting protocol is based on a server directed model with
+ capabilities for real-time delivery of accounting information.
+ Several fault resilience methods [RFC2975] have been built into the
+ protocol in order minimize loss of accounting data in various fault
+ situations and under different assumptions about the capabilities of
+ the used devices.
+
+9.1. Server Directed Model
+
+ The server directed model means that the device generating the
+ accounting data gets information from either the authorization server
+ (if contacted) or the accounting server regarding the way accounting
+ data shall be forwarded. This information includes accounting record
+ timeliness requirements.
+
+ As discussed in [RFC2975], real-time transfer of accounting records
+ is a requirement, such as the need to perform credit-limit checks and
+ fraud detection. Note that batch accounting is not a requirement,
+ and is therefore not supported by Diameter. Should batched
+ accounting be required in the future, a new Diameter application will
+ need to be created, or it could be handled using another protocol.
+ Note, however, that even if at the Diameter layer, accounting
+ requests are processed one by one; transport protocols used under
+ Diameter typically batch several requests in the same packet under
+ heavy traffic conditions. This may be sufficient for many
+ applications.
+
+ The authorization server (chain) directs the selection of proper
+ transfer strategy, based on its knowledge of the user and
+ relationships of roaming partnerships. The server (or agents) uses
+ the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
+ control the operation of the Diameter peer operating as a client.
+ The Acct-Interim-Interval AVP, when present, instructs the Diameter
+ node acting as a client to produce accounting records continuously
+ even during a session. Accounting-Realtime-Required AVP is used to
+ control the behavior of the client when the transfer of accounting
+ records from the Diameter client 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 in further accounting activities for the same session.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 123]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+9.2. Protocol Messages
+
+ A Diameter node that receives a successful authentication and/or
+ authorization message from the Diameter server SHOULD collect
+ accounting information for the session. The Accounting-Request
+ message is used to transmit the accounting information to the
+ Diameter server, which MUST reply with the Accounting-Answer message
+ to confirm reception. The Accounting-Answer message includes the
+ Result-Code AVP, which MAY indicate that an error was present 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 only their respective service-specific
+ AVPs need to be defined in that section.
+
+ Applications have the option of using one or both of the following
+ accounting application extension models:
+
+ Split Accounting Service
+
+ The accounting message will carry 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. These nodes might be
+ centralized accounting servers that provide accounting service for
+ multiple different Diameter applications. These nodes MUST
+ advertise the Diameter base accounting Application Id during
+ capabilities exchange.
+
+ Coupled Accounting Service
+
+ The accounting message will carry the Application Id of the
+ application that is using it. The application itself will process
+ the received accounting records or forward them to an accounting
+ server. There is no accounting application advertisement required
+ during capabilities exchange, and the accounting messages will be
+ routed the same way as any of the other application messages.
+
+ In cases where an application does not define its own accounting
+ service, it is preferred that the split accounting model be used.
+
+
+
+Fajardo, et al. Standards Track [Page 124]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+9.4. Fault Resilience
+
+ Diameter base protocol mechanisms are used to overcome small message
+ loss and network faults of a temporary nature.
+
+ Diameter peers acting as clients MUST implement the use of 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 the
+ sending of the same record to several servers and duplication of
+ messages in transit. This detection MUST be based on the inspection
+ of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C
+ discusses duplicate detection needs and implementation issues.
+
+ Diameter clients MAY have non-volatile memory for the safe storage of
+ accounting records over reboots or extended network failures, network
+ partitions, and server failures. If such memory is available, the
+ client SHOULD store new accounting records there as soon as the
+ records are created and until a positive acknowledgement of their
+ reception from the Diameter server has been received. Upon a reboot,
+ the client MUST start sending the records in the non-volatile memory
+ to the accounting server with the appropriate modifications in
+ termination cause, session length, and other relevant information in
+ the records.
+
+ A further application of this protocol may include AVPs to control
+ the maximum number of accounting records that may be stored in the
+ Diameter client without committing them to the non-volatile memory or
+ transferring them to the Diameter server.
+
+ The client SHOULD NOT remove the accounting data from any of its
+ memory areas before the correct Accounting-Answer has been received.
+ The client MAY remove the oldest, undelivered, or as yet
+ unacknowledged accounting data if it runs out of resources such as
+ memory. It is an implementation-dependent matter for the client to
+ accept new sessions under this condition.
+
+9.5. Accounting Records
+
+ In all accounting records, the Session-Id AVP MUST be present; the
+ User-Name AVP MUST be present if it is available to the Diameter
+ client.
+
+ Different types of accounting records are sent depending on the
+ actual type of accounted service and the authorization server's
+ directions for interim accounting. If the accounted service is a
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 125]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ one-time event, meaning that the start and stop of the event are
+ simultaneous, then the Accounting-Record-Type AVP MUST be present and
+ set to the value EVENT_RECORD.
+
+ If the accounted service is of a measurable length, then the AVP MUST
+ use the values START_RECORD, STOP_RECORD, and possibly,
+ INTERIM_RECORD. If the authorization server has not directed interim
+ accounting to be enabled for the session, two accounting records MUST
+ be generated for each service of type session. When the initial
+ Accounting-Request for a given session is sent, the Accounting-
+ Record-Type AVP MUST be set to the value START_RECORD. When the last
+ Accounting-Request is sent, the value MUST be STOP_RECORD.
+
+ If the authorization server has directed interim accounting to be
+ enabled, the Diameter client MUST produce additional records between
+ the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
+ production of these records is directed by Acct-Interim-Interval as
+ well as any re-authentication or re-authorization of the session.
+ The Diameter client MUST overwrite any previous interim accounting
+ records that are locally stored for delivery, if a new record is
+ being generated for the same session. This ensures that 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
+ the purposes of retransmission. The one sequence that is sent MUST
+ be either one record with Accounting-Record-Type AVP set to the value
+ EVENT_RECORD or several records starting with one having 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 application uses accounting messages, it can correlate
+ accounting records with a specific application session by using the
+ Session-Id of the particular application session 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 perform correlation.
+
+ In cases where an application requires multiple accounting sub-
+ sessions, an Accounting-Sub-Session-Id AVP is used to differentiate
+ each sub-session. The Session-Id would remain constant for all sub-
+ sessions and is used to correlate all the sub-sessions to a
+ particular application session. Note that receiving a STOP_RECORD
+
+
+
+
+Fajardo, et al. Standards Track [Page 126]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ with no Accounting-Sub-Session-Id AVP when sub-sessions were
+ originally used in the START_RECORD messages implies that all sub-
+ sessions are terminated.
+
+ There are also cases where an application needs to correlate multiple
+ application sessions into a single accounting record; the accounting
+ record may span multiple different Diameter applications and sessions
+ used by the same user at a given time. In such cases, 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.
+
+ In addition to the AVPs listed below, Accounting-Request messages
+ SHOULD include service-specific accounting AVPs.
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 127]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+ In addition to the AVPs listed below, Accounting-Answer messages
+ SHOULD include service-specific accounting AVPs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 128]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 129]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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:
+
+ 1. 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.
+
+ 2. 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
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 130]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+ The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
+ following the format specified in Section 8.8. The Acct-Multi-
+ Session-Id AVP is used to link multiple related accounting sessions,
+ where each session would have a unique Session-Id but the same Acct-
+ Multi-Session-Id AVP. This AVP MAY be returned by the Diameter
+ server in an authorization answer, and it MUST be used in all
+ accounting messages for the given session.
+
+9.8.6. Accounting-Sub-Session-Id AVP
+
+ The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
+ Unsigned64 and contains the accounting sub-session identifier. The
+ combination of the Session-Id and this AVP MUST be unique per sub-
+ session, and the value of this AVP MUST be monotonically increased by
+ one for all new sub-sessions. The absence of this AVP implies no
+ sub-sessions are in use, with the exception of an Accounting-Request
+ whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
+ message with no Accounting-Sub-Session-Id AVP present will signal the
+ termination of all sub-sessions for a given Session-Id.
+
+
+
+Fajardo, et al. Standards Track [Page 131]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+9.8.7. Accounting-Realtime-Required AVP
+
+ The Accounting-Realtime-Required AVP (AVP Code 483) is of type
+ Enumerated and is sent from the Diameter home authorization server to
+ the Diameter client or in the Accounting-Answer from the accounting
+ server. The client uses information in this AVP to decide what to do
+ if the sending of accounting records to the accounting server has
+ been temporarily prevented due to, for instance, a network problem.
+
+ DELIVER_AND_GRANT 1
+
+ The AVP with Value field set to DELIVER_AND_GRANT means that the
+ service MUST only be granted as long as there is a connection to
+ an accounting server. Note that the set of alternative accounting
+ servers are treated as one server in this sense. Having to move
+ the accounting record stream to a backup server is not a reason to
+ discontinue the service to the user.
+
+ GRANT_AND_STORE 2
+
+ The AVP with Value field set to GRANT_AND_STORE means that service
+ SHOULD be granted if there is a connection, or as long as records
+ can still be stored as described in Section 9.4.
+
+ This is the default behavior if the AVP isn't included in the
+ reply from the authorization server.
+
+ GRANT_AND_LOSE 3
+
+ The AVP with Value field set to GRANT_AND_LOSE means that service
+ SHOULD be granted even if the records cannot be delivered or
+ stored.
+
+10. AVP Occurrence Tables
+
+ The following tables present the AVPs defined in this document and
+ specify in which Diameter messages they MAY or MAY NOT be present.
+ AVPs that occur only inside a Grouped AVP are not shown in these
+ tables.
+
+ The tables use the following 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.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 132]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 0-1 Zero or one instance of the AVP MAY be present in the message.
+ It is considered an error if there are more than one instance
+ of the AVP.
+
+ 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
+
+ The table in this section is limited to the non-Accounting Command
+ Codes defined in this specification.
+
+ +-----------------------------------------------+
+ | 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 |
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 133]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+ The table in this section is used to represent which AVPs defined in
+ this document are to be present in the Accounting messages. These
+ AVP occurrence requirements are guidelines, which may be expanded,
+ and/or overridden by application-specific requirements in the
+ Diameter applications documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 134]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ +-----------+
+ | 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 provides guidance to the Internet Assigned Numbers
+ Authority (IANA) regarding registration of values related to the
+ Diameter protocol, in accordance with [RFC5226]. Existing IANA
+ registries and assignments put in place by RFC 3588 remain the same
+ unless explicitly updated or deprecated in this section.
+
+11.1. AVP Header
+
+ As defined in Section 4, the AVP header contains three fields that
+ require IANA namespace management: the AVP Code, Vendor-ID, and Flags
+ fields.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 135]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+11.1.1. AVP Codes
+
+ There are multiple namespaces. Vendors can have their own AVP Codes
+ namespace that will be identified by their Vendor-ID (also known as
+ Enterprise-Number), and they control the assignments of their vendor-
+ specific AVP Codes within their own namespace. The absence of a
+ Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP
+ Codes namespace, which is under IANA control. The AVP Codes and
+ sometimes possible values in 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
+
+ For the Diameter header, the Command Code namespace allocation has
+ changed. The new allocation rules are as follows:
+
+ 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.
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 136]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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].
+
+11.3. AVP Values
+
+ For AVP values, the Experimental-Result-Code AVP value allocation has
+ been added; see Section 11.3.1. The old AVP value allocation rule,
+ IETF Consensus, has been updated to IETF Review as per [RFC5226], and
+ affected AVPs are listed as reminders.
+
+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.
+
+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].
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 137]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+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.
+
+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].
+
+ Service Name: _diameters
+
+ Transport Protocols: TCP, SCTP
+
+ Assignee: IESG <[email protected]>
+
+ Contact: IETF Chair <[email protected]>
+
+ Description: Diameter over TLS/TCP and DTLS/SCTP
+
+ Reference: RFC 6733
+
+ Port Number: 5868, from the User Range
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 138]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+11.5. SCTP Payload Protocol Identifiers
+
+ Two SCTP payload protocol identifiers have been registered in the
+ SCTP Payload Protocol Identifiers registry:
+
+
+ Value | SCTP Payload Protocol Identifier
+ -------|-----------------------------------
+ 46 | Diameter in a SCTP DATA chunk
+ 47 | Diameter in a DTLS/SCTP DATA chunk
+
+
+11.6. S-NAPTR Parameters
+
+ The following tag has been registered in the S-NAPTR Application
+ Protocol Tags registry:
+
+ Tag | Protocol
+ -------------------|---------
+ diameter.dtls.sctp | DTLS/SCTP
+
+12. Diameter Protocol-Related Configurable Parameters
+
+ This section contains the configurable parameters that are found
+ 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.
+
+ 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.
+
+
+
+Fajardo, et al. Standards Track [Page 139]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+13. Security Considerations
+
+ 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.
+
+ 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.
+
+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.
+
+ 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_SHA
+
+ Diameter nodes SHOULD be able to negotiate the following TLS/TCP and
+ DTLS/SCTP cipher suite:
+
+ TLS_RSA_WITH_AES_128_CBC_SHA
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 140]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ Note 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.
+
+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.
+
+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:
+
+ o Acct-Interim-Interval
+
+ o Accounting-Realtime-Required
+
+ o Acct-Multi-Session-Id
+
+ o Accounting-Record-Number
+
+ o Accounting-Record-Type
+
+ o Accounting-Session-Id
+
+ o Accounting-Sub-Session-Id
+
+ o Class
+
+
+
+Fajardo, et al. Standards Track [Page 141]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ o Session-Id
+
+ o Session-Binding
+
+ o Session-Server-Failover
+
+ o 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.
+
+14. References
+
+14.1. Normative References
+
+ [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.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 142]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ [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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 143]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ [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
+
+ [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.
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 144]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ [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.
+
+
+
+
+Fajardo, et al. Standards Track [Page 145]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 146]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+Appendix A. Acknowledgements
+
+A.1. This Document
+
+ The authors would like to thank the following people that have
+ provided proposals and contributions to this document:
+
+ 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, which
+ helped resolve the tricky question of mandatory AVPs and ABNF
+ semantics. The members of this team are as follows:
+
+ Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga
+ Asveren, Jouni Korhonen, and Glenn McGregor.
+
+ Special thanks also to people who have provided invaluable comments
+ and inputs especially in resolving 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.
+
+ Finally, we would like to thank the original authors of this
+ document:
+
+ Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn.
+
+ Their invaluable knowledge and experience has given us a robust and
+ flexible AAA protocol that many people have seen great value in
+ adopting. We greatly appreciate their support and stewardship for
+ the continued improvements of Diameter as a protocol. We would also
+ like to extend our gratitude to folks aside from the authors who have
+
+
+
+
+Fajardo, et al. Standards Track [Page 147]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ assisted and contributed to the original version of this document.
+ Their efforts significantly contributed to the success of Diameter.
+
+A.2. RFC 3588
+
+ The authors would like to thank Nenad Trifunovic, Tony Johansson and
+ Pankaj Patel for their participation in the pre-IETF Document Reading
+ Party. Allison Mankin, Jonathan Wood, and Bernard Aboba provided
+ invaluable assistance in working out transport issues and this was
+ also the case with Steven Bellovin in the security area.
+
+ Paul Funk and David Mitton were instrumental in getting the Peer
+ State Machine correct, and our deep thanks go to them for their time.
+
+ Text in this document was also provided by Paul Funk, Mark Eklund,
+ Mark Jones, and Dave Spence. Jacques Caron provided many great
+ comments as a result of a thorough review of the spec.
+
+ The authors would also like to acknowledge the following people for
+ their contribution in the development of 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.
+
+ Finally, Pat Calhoun would like to thank Sun Microsystems since most
+ of the effort put into this document was done while he was in their
+ employ.
+
+Appendix B. S-NAPTR Example
+
+ As an example, consider a client that wishes to resolve aaa:
+ ex1.example.com. The client performs a NAPTR query for that domain,
+ and the following NAPTR records are returned:
+
+ ;; 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.com
+
+ This indicates that the server supports TLS, TCP, and SCTP in that
+ order. If the client supports TLS, TLS will be used, targeted to a
+
+
+
+Fajardo, et al. Standards Track [Page 148]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ host determined by 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.com
+
+ As an alternative example, a client that wishes to resolve aaa:
+ ex2.example.com. The client performs a NAPTR query for that domain,
+ and the following NAPTR records are returned:
+
+ ;; 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.com
+
+ This indicates that the server supports TCP available at the returned
+ host names.
+
+Appendix C. Duplicate Detection
+
+ As described in Section 9.4, accounting record duplicate detection is
+ based on session identifiers. Duplicates can appear for various
+ reasons:
+
+ o Failover to an alternate server. Where close to real-time
+ performance is required, failover thresholds need to be kept low.
+ This may lead to an increased likelihood of duplicates. Failover
+ can occur at the client or within Diameter agents.
+
+ o Failure of a client or agent after sending a record from non-
+ volatile memory, but prior to receipt of an application-layer ACK
+ and deletion of the record to be sent. This will result in
+ retransmission of the record soon after the client or agent has
+ rebooted.
+
+ o Duplicates received from RADIUS gateways. Since the
+ retransmission behavior of RADIUS is not defined within [RFC2865],
+ the likelihood of duplication will vary according to the
+ implementation.
+
+ o Implementation problems and misconfiguration.
+
+ The T flag is used as an indication of an application-layer
+ retransmission event, e.g., due to failover to an alternate server.
+ It is defined only for request messages sent by Diameter clients or
+ agents. For instance, after a reboot, a client may not know whether
+
+
+
+Fajardo, et al. Standards Track [Page 149]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ it has already tried to send the accounting records in its non-
+ volatile memory before the reboot occurred. Diameter servers MAY use
+ the T flag as an aid when processing requests and detecting duplicate
+ messages. However, servers that do this MUST ensure that duplicates
+ are found even when the first transmitted request arrives at the
+ server after the retransmitted request. It can be used only in cases
+ where no answer has been received from the server for a request and
+ the request is sent again, (e.g., due to a failover to an alternate
+ peer, due to a recovered primary peer or due to a client re-sending a
+ stored record from non-volatile memory such as after reboot of a
+ client or agent).
+
+ In some cases, the Diameter accounting server can delay the duplicate
+ detection and accounting record processing until a post-processing
+ phase takes place. At that time records are likely to be sorted
+ according to the included User-Name and duplicate elimination is easy
+ in this case. In other situations, it may be necessary to perform
+ real-time duplicate detection, such as when credit limits are imposed
+ or real-time fraud detection is desired.
+
+ In general, only generation of duplicates due to failover or re-
+ sending of records in non-volatile storage can be reliably detected
+ by Diameter clients or agents. In such cases, the Diameter client or
+ agents can mark the message as a possible duplicate by setting the T
+ flag. Since the Diameter server is responsible for duplicate
+ detection, it can choose whether or not to make use of the T flag, in
+ order to optimize duplicate detection. Since the T flag does not
+ affect interoperability, and it may not be needed by some servers,
+ generation of the T flag is REQUIRED for Diameter clients and agents,
+ but it MAY be implemented by Diameter servers.
+
+ As an example, it can be usually be assumed that duplicates appear
+ within a time window of longest recorded network partition or device
+ fault, perhaps a day. So only records within this time window need
+ to be looked at in the backward direction. Secondly, hashing
+ techniques or other schemes, such as the use of the T flag in the
+ received messages, may be used to eliminate the need to do a full
+ search even in this set except for rare cases.
+
+ The following is an example of how the T flag may be used by the
+ server 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
+
+
+
+Fajardo, et al. Standards Track [Page 150]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+ 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
+
+ To be compatible with the existing DNS infrastructure and simplify
+ host and domain name comparison, Diameter identities (FQDNs) are
+ represented in ASCII form. This allows the Diameter protocol to fall
+ in-line with the DNS strategy of being transparent from the effects
+ of Internationalized Domain Names (IDNs) by following the
+ recommendations in [RFC4690] and [RFC5890]. Applications that
+ provide support for IDNs outside of the Diameter protocol but
+ interacting with it SHOULD use the representation and conversion
+ framework described in [RFC5890], [RFC5891], and [RFC3492].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 151]
+
+RFC 6733 Diameter Base Protocol October 2012
+
+
+Authors' Addresses
+
+ Victor Fajardo (editor)
+ Telcordia Technologies
+ One Telcordia Drive, 1S-222
+ Piscataway, NJ 08854
+ USA
+
+ Phone: +1-908-421-1845
+ EMail: [email protected]
+
+
+ Jari Arkko
+ Ericsson Research
+ 02420 Jorvas
+ Finland
+
+ Phone: +358 40 5079256
+ EMail: [email protected]
+
+
+ John Loughney
+ Nokia Research Center
+ 955 Page Mill Road
+ Palo Alto, CA 94304
+ US
+
+ Phone: +1-650-283-8068
+ EMail: [email protected]
+
+
+ Glen Zorn (editor)
+ Network Zen
+ 227/358 Thanon Sanphawut
+ Bang Na, Bangkok 10260
+ Thailand
+
+ Phone: +66 (0) 87-0404617
+ EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+Fajardo, et al. Standards Track [Page 152]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-20 01:31:52 +0000