idnits 2.17.1
draft-ietf-dime-rfc3588bis-31.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
-- The draft header indicates that this document obsoletes RFC5719, but the
abstract doesn't seem to directly say this. It does mention RFC5719
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 1785 has weird spacing: '...equired rules...'
== Line 6694 has weird spacing: '...service rege...'
== Line 6715 has weird spacing: '...service rege...'
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 11, 2012) is 4429 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'TBD' is mentioned on line 996, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'FLOATPOINT'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM'
** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733)
** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155)
** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group V. Fajardo, Ed.
3 Internet-Draft Telcordia Technologies
4 Obsoletes: 3588 5719 J. Arkko
5 (if approved) Ericsson Research
6 Intended status: Standards Track J. Loughney
7 Expires: September 12, 2012 Nokia Research Center
8 G. Zorn, Ed.
9 Network Zen
10 March 11, 2012
12 Diameter Base Protocol
13 draft-ietf-dime-rfc3588bis-31.txt
15 Abstract
17 The Diameter base protocol is intended to provide an Authentication,
18 Authorization and Accounting (AAA) framework for applications such as
19 network access or IP mobility in both local and roaming situations.
20 This document specifies the message format, transport, error
21 reporting, accounting and security services used by all Diameter
22 applications. The Diameter base protocol as defined in this document
23 obsoletes RFC 3588 and RFC 5719 and must be supported by all new
24 Diameter implementations.
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on September 12, 2012.
43 Copyright Notice
45 Copyright (c) 2012 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 This document may contain material from IETF Documents or IETF
59 Contributions published or made publicly available before November
60 10, 2008. The person(s) controlling the copyright in some of this
61 material may not have granted the IETF Trust the right to allow
62 modifications of such material outside the IETF Standards Process.
63 Without obtaining an adequate license from the person(s) controlling
64 the copyright in such materials, this document may not be modified
65 outside the IETF Standards Process, and derivative works of it may
66 not be created outside the IETF Standards Process, except to format
67 it for publication as an RFC or to translate it into languages other
68 than English.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
73 1.1. Diameter Protocol . . . . . . . . . . . . . . . . . . . . 10
74 1.1.1. Description of the Document Set . . . . . . . . . . 11
75 1.1.2. Conventions Used in This Document . . . . . . . . . 12
76 1.1.3. Changes from RFC3588 . . . . . . . . . . . . . . . . 12
77 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14
78 1.3. Approach to Extensibility . . . . . . . . . . . . . . . . 19
79 1.3.1. Defining New AVP Values . . . . . . . . . . . . . . 20
80 1.3.2. Creating New AVPs . . . . . . . . . . . . . . . . . 20
81 1.3.3. Creating New Commands . . . . . . . . . . . . . . . 20
82 1.3.4. Creating New Diameter Applications . . . . . . . . . 21
83 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22
84 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23
85 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 24
86 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 25
87 2.3. Diameter Application Compliance . . . . . . . . . . . . . 26
88 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 26
89 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 26
90 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 27
91 2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 28
92 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 30
93 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 31
94 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 32
95 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 32
96 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 33
97 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 34
98 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
99 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38
100 3.2. Command Code Format Specification . . . . . . . . . . . . 39
101 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 41
102 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42
103 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42
104 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44
105 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
106 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46
107 4.3.1. Common Derived AVP Data Formats . . . . . . . . . . 46
108 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 53
109 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 54
110 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 57
111 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 60
112 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 60
113 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 61
114 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62
115 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 64
116 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 65
117 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 65
118 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 65
119 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 66
120 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 66
121 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 66
122 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 66
123 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 67
124 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 67
125 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 68
126 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 68
127 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 68
128 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 69
129 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 69
130 5.5.4. Failover and Failback Procedures . . . . . . . . . . 69
131 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 70
132 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 72
133 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 73
134 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 74
135 5.6.4. The Election Process . . . . . . . . . . . . . . . . 76
136 6. Diameter Message Processing . . . . . . . . . . . . . . . . . 76
137 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76
138 6.1.1. Originating a Request . . . . . . . . . . . . . . . 77
139 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 78
140 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78
141 6.1.4. Processing Local Requests . . . . . . . . . . . . . 78
142 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 79
143 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 79
144 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 79
145 6.1.8. Redirecting Requests . . . . . . . . . . . . . . . . 79
146 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 81
147 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 82
148 6.2.1. Processing Received Answers . . . . . . . . . . . . 83
149 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 83
150 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 83
151 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 84
152 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 84
153 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 84
154 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 85
155 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 85
156 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 85
157 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 85
158 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 85
159 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 85
160 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 86
161 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 86
162 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 86
163 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 87
164 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87
165 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 89
167 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 89
168 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 91
169 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92
170 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 92
171 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 92
172 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94
173 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95
174 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98
175 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 98
176 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 98
177 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 99
178 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 100
179 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100
180 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 100
181 8.1. Authorization Session State Machine . . . . . . . . . . . 102
182 8.2. Accounting Session State Machine . . . . . . . . . . . . 106
183 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112
184 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112
185 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113
186 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 113
187 8.4.1. Session-Termination-Request . . . . . . . . . . . . 114
188 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 115
189 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 116
190 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 116
191 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 117
192 8.6. Inferring Session Termination from Origin-State-Id . . . 117
193 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 118
194 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 119
195 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 120
196 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 120
197 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 120
198 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 121
199 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 121
200 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 122
201 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 122
202 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 123
203 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 124
204 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 124
205 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 125
206 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 125
207 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 126
208 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 126
209 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 126
210 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 127
211 9.3. Accounting Application Extension and Requirements . . . . 127
212 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 128
213 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 129
214 9.6. Correlation of Accounting Records . . . . . . . . . . . . 130
215 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 130
216 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 130
217 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 131
218 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 132
219 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 132
220 9.8.2. Acct-Interim-Interval AVP . . . . . . . . . . . . . 133
221 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 134
222 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 134
223 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 134
224 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 134
225 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 135
226 10. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 135
227 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 136
228 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 137
229 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 138
230 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 138
231 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 139
232 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 139
233 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 139
234 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 139
235 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 140
236 11.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 140
237 11.3.1. Experimental-Result-Code AVP . . . . . . . . . . . . 140
238 11.3.2. Result-Code AVP Values . . . . . . . . . . . . . . . 140
239 11.3.3. Accounting-Record-Type AVP Values . . . . . . . . . 140
240 11.3.4. Termination-Cause AVP Values . . . . . . . . . . . . 140
241 11.3.5. Redirect-Host-Usage AVP Values . . . . . . . . . . . 140
242 11.3.6. Session-Server-Failover AVP Values . . . . . . . . . 140
243 11.3.7. Session-Binding AVP Values . . . . . . . . . . . . . 140
244 11.3.8. Disconnect-Cause AVP Values . . . . . . . . . . . . 141
245 11.3.9. Auth-Request-Type AVP Values . . . . . . . . . . . . 141
246 11.3.10. Auth-Session-State AVP Values . . . . . . . . . . . 141
247 11.3.11. Re-Auth-Request-Type AVP Values . . . . . . . . . . 141
248 11.3.12. Accounting-Realtime-Required AVP Values . . . . . . 141
249 11.3.13. Inband-Security-Id AVP (code 299) . . . . . . . . . 141
250 11.4. _diameter Service Name and Port Number Registration . . . 141
251 11.5. SCTP Payload Protocol Identifiers . . . . . . . . . . . . 142
252 11.6. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . 142
253 12. Diameter Protocol-related Configurable Parameters . . . . . . 142
254 13. Security Considerations . . . . . . . . . . . . . . . . . . . 143
255 13.1. TLS/TCP and DTLS/SCTP Usage . . . . . . . . . . . . . . . 143
256 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 144
257 13.3. AVP Considerations . . . . . . . . . . . . . . . . . . . 144
258 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 144
259 14.1. Normative References . . . . . . . . . . . . . . . . . . 144
260 14.2. Informational References . . . . . . . . . . . . . . . . 146
261 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 148
262 A.1. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . . 148
263 A.2. RFC3588 . . . . . . . . . . . . . . . . . . . . . . . . . 149
264 Appendix B. S-NAPTR Example . . . . . . . . . . . . . . . . . . 150
265 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 150
266 Appendix D. Internationalized Domain Names . . . . . . . . . . . 152
267 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 153
269 1. Introduction
271 Authentication, Authorization and Accounting (AAA) protocols such as
272 TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
273 provide dial-up PPP [RFC1661] and terminal server access. Over time,
274 AAA support was needed on many new access technologies, the scale and
275 complexity of AAA networks grew, and AAA was also used on new
276 applications (such as voice over IP). This lead to new demands on
277 AAA protocols.
279 Network access requirements for AAA protocols are summarized in
280 [RFC2989]. These include:
282 Failover
284 [RFC2865] does not define failover mechanisms, and as a result,
285 failover behavior differs between implementations. In order to
286 provide well-defined failover behavior, Diameter supports
287 application-layer acknowledgements, and defines failover
288 algorithms and the associated state machine. This is described in
289 Section 5.5 [RFC3539].
291 Transmission-level security
293 [RFC2865] defines an application-layer authentication and
294 integrity scheme that is required only for use with Response
295 packets. While [RFC2869] defines an additional authentication and
296 integrity mechanism, use is only required during Extensible
297 Authentication Protocol (EAP) [RFC3748] sessions. While
298 attribute-hiding is supported, [RFC2865] does not provide support
299 for per-packet confidentiality. In accounting, [RFC2866] assumes
300 that replay protection is provided by the backend billing server,
301 rather than within the protocol itself.
303 While [RFC3162] defines the use of IPsec with RADIUS, support for
304 IPsec is not required. In order to provide universal support for
305 transmission-level security, and enable both intra- and inter-
306 domain AAA deployments, Diameter provides support for TLS/TCP and
307 DTLS/SCTP. Security is discussed in Section 13.
309 Reliable transport
311 RADIUS runs over UDP, and does not define retransmission behavior;
312 as a result, reliability varies between implementations. As
313 described in [RFC2975], this is a major issue in accounting, where
314 packet loss may translate directly into revenue loss. In order to
315 provide well defined transport behavior, Diameter runs over
316 reliable transport mechanisms (TCP, SCTP) as defined in [RFC3539].
318 Agent support
320 [RFC2865] does not provide for explicit support for agents,
321 including Proxies, Redirects and Relays. Since the expected
322 behavior is not defined, it varies between implementations.
323 Diameter defines agent behavior explicitly; this is described in
324 Section 2.8.
326 Server-initiated messages
328 While RADIUS server-initiated messages are defined [RFC5176],
329 support is optional. This makes it difficult to implement
330 features such as unsolicited disconnect or re-authentication/
331 re-authorization on demand across a heterogeneous deployment. To
332 address this issue, support for server-initiated messages is
333 mandatory in Diameter.
335 Transition support
337 While Diameter does not share a common protocol data unit (PDU)
338 with RADIUS, considerable effort has been expended in enabling
339 backward compatibility with RADIUS, so that the two protocols may
340 be deployed in the same network. Initially, it is expected that
341 Diameter will be deployed within new network devices, as well as
342 within gateways enabling communication between legacy RADIUS
343 devices and Diameter agents. This capability enables Diameter
344 support to be added to legacy networks, by addition of a gateway
345 or server speaking both RADIUS and Diameter.
347 In addition to addressing the above requirements, Diameter also
348 provides support for the following:
350 Capability negotiation
352 RADIUS does not support error messages, capability negotiation, or
353 a mandatory/non-mandatory flag for attributes. Since RADIUS
354 clients and servers are not aware of each other's capabilities,
355 they may not be able to successfully negotiate a mutually
356 acceptable service, or in some cases, even be aware of what
357 service has been implemented. Diameter includes support for error
358 handling (Section 7), capability negotiation (Section 5.3), and
359 mandatory/non-mandatory Attribute-Value Pairs (AVPs)
360 (Section 4.1).
362 Peer discovery and configuration
364 RADIUS implementations typically require that the name or address
365 of servers or clients be manually configured, along with the
366 corresponding shared secrets. This results in a large
367 administrative burden, and creates the temptation to reuse the
368 RADIUS shared secret, which can result in major security
369 vulnerabilities if the Request Authenticator is not globally and
370 temporally unique as required in [RFC2865]. Through DNS, Diameter
371 enables dynamic discovery of peers (see Section 5.2). Derivation
372 of dynamic session keys is enabled via transmission-level
373 security.
375 Over time, the capabilities of Network Access Server (NAS) devices
376 have increased substantially. As a result, while Diameter is a
377 considerably more sophisticated protocol than RADIUS, it remains
378 feasible to implement it within embedded devices.
380 1.1. Diameter Protocol
382 The Diameter base protocol provides the following facilities:
384 o Ability to exchange messages and deliver AVPs
386 o Capabilities negotiation
388 o Error notification
390 o Extensibility, through addition of new applications, commands and
391 AVPs (required in [RFC2989]).
393 o Basic services necessary for applications, such as handling of
394 user sessions or accounting
396 All data delivered by the protocol is in the form of AVPs. Some of
397 these AVP values are used by the Diameter protocol itself, while
398 others deliver data associated with particular applications that
399 employ Diameter. AVPs may be arbitrarily added to Diameter messages,
400 the only restriction being that the Command Code Format specification
401 Section 3.2 is satisfied. AVPs are used by the base Diameter
402 protocol to support the following required features:
404 o Transporting of user authentication information, for the purposes
405 of enabling the Diameter server to authenticate the user.
407 o Transporting of service-specific authorization information,
408 between client and servers, allowing the peers to decide whether a
409 user's access request should be granted.
411 o Exchanging resource usage information, which may be used for
412 accounting purposes, capacity planning, etc.
414 o Routing, relaying, proxying and redirecting of Diameter messages
415 through a server hierarchy.
417 The Diameter base protocol satisfies the minimum requirements for an
418 AAA protocol, as specified by [RFC2989]. The base protocol may be
419 used by itself for accounting purposes only, or it may be used with a
420 Diameter application, such as Mobile IPv4 [RFC4004], or network
421 access [RFC4005]. It is also possible for the base protocol to be
422 extended for use in new applications, via the addition of new
423 commands or AVPs. The initial focus of Diameter was network access
424 and accounting applications. A truly generic AAA protocol used by
425 many applications might provide functionality not provided by
426 Diameter. Therefore, it is imperative that the designers of new
427 applications understand their requirements before using Diameter.
428 See Section 1.3.4 for more information on Diameter applications.
430 Any node can initiate a request. In that sense, Diameter is a peer-
431 to-peer protocol. In this document, a Diameter Client is a device at
432 the edge of the network that performs access control, such as a
433 Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
434 client generates Diameter messages to request authentication,
435 authorization, and accounting services for the user. A Diameter
436 agent is a node that does not provide local user authentication or
437 authorization services; agents include proxies, redirects and relay
438 agents. A Diameter server performs authentication and/or
439 authorization of the user. A Diameter node may act as an agent for
440 certain requests while acting as a server for others.
442 The Diameter protocol also supports server-initiated messages, such
443 as a request to abort service to a particular user.
445 1.1.1. Description of the Document Set
447 The Diameter specification consists of an updated version of the base
448 protocol specification (this document) and the Transport Profile
449 [RFC3539]. This document obsoletes RFC 3588. A summary of the base
450 protocol updates included in this document can be found in
451 Section 1.1.3.
453 This document defines the base protocol specification for AAA, which
454 includes support for accounting. There are also a myriad of
455 applications documents describing applications that use this base
456 specification for Authentication, Authorization and Accounting.
457 These application documents specify how to use the Diameter protocol
458 within the context of their application.
460 The Transport Profile document [RFC3539] discusses transport layer
461 issues that arise with AAA protocols and recommendations on how to
462 overcome these issues. This document also defines the Diameter
463 failover algorithm and state machine.
465 Clarifications on the Routing of Diameter Request based on Username
466 and the Realm [RFC5729] defines specific behavior on how to route
467 requests based on the content of the User-Name AVP (Attribute Value
468 Pair).
470 1.1.2. Conventions Used in This Document
472 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
473 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
474 document are to be interpreted as described in [RFC2119].
476 1.1.3. Changes from RFC3588
478 This document obsoletes RFC 3588 but is fully backward compatible
479 with that document. The changes introduced in this document focus on
480 fixing issues that have surfaced during implementation of [RFC3588].
481 An overview of some the major changes are given below.
483 o Deprecated the use of Inband-Security AVP for negotiating
484 transport layer security. It has been generally considered that
485 bootstrapping of TLS via Inband-Security AVP creates certain
486 security risk because it does not completely protect the
487 information carried in the CER (Capabilities Exchange Request)/CEA
488 (Capabilities Exchange Answer). This version of Diameter adopted
489 a common approach of defining a well-known secured port that peers
490 should use when communicating via TLS/TCP and DTLS/SCTP. This new
491 approach augments the existing Inband-Security negotiation but
492 does not completely replace it. The old method is kept for
493 backwards compatibility reasons.
495 o Deprecated the exchange of CER/CEA messages in the open state.
496 This feature was implied in the peer state machine table of
497 [RFC3588] but it was not clearly defined anywhere else in that
498 document. As work on this document progressed, it became clear
499 that the multiplicity of meaning and use of Application Id AVPs in
500 the CER/CEA messages (and the messages themselves) is seen as an
501 abuse of the Diameter extensibility rules and thus required
502 simplification. It is assumed that the capabilities exchange in
503 the open state will be re-introduced in a separate specification
504 which clearly defines new commands for this feature.
506 o Simplified Security Requirements. The use of a secured transport
507 for exchanging Diameter messages remains mandatory. However, TLS/
508 TCP and DTLS/SCTP has become the primary method of securing
509 Diameter and IPsec is a secondary alternative. See Section 13 for
510 details. The support for the End-to-End security framework (E2E-
511 Sequence AVP and 'P'-bit in the AVP header) has also been
512 deprecated.
514 o Diameter Extensibility Changes. This includes fixes to the
515 Diameter extensibility description (Section 1.3 and others) to
516 better aid Diameter application designers; in addition, the new
517 specification relaxes the policy with respect to the allocation of
518 command codes for vendor-specific uses.
520 o Application Id Usage. Clarify the proper use of Application Id
521 information which can be found in multiple places within a
522 Diameter message. This includes correlating Application Ids found
523 in the message headers and AVPs. These changes also clearly
524 specify the proper Application Id value to use for specific base
525 protocol messages (ASR/ASA, STR/STA) as well as clarifying the
526 content and use of Vendor-Specific-Application-Id.
528 o Routing Fixes. This document more clearly specifies what
529 information (AVPs and Application Id) can be used for making
530 general routing decisions. A rule for the prioritization of
531 redirect routing criteria when multiple route entries are found
532 via redirects has also been added (see Section 6.13.
534 o Simplification of Diameter Peer Discovery. The Diameter discovery
535 process now supports only widely used discovery schemes; the rest
536 have been deprecated (see Section 5.2 for details).
538 There are many other many miscellaneous fixes that have been
539 introduced in this document that may not be considered significant
540 but they are important nonetheless. Examples are removal of obsolete
541 types, fixes to command ABNFs, fixes to the state machine,
542 clarification of the election process, message validation, fixes to
543 Failed-AVP and Result-Code AVP values, etc. All of the errata
544 previously filed against RFC 3588 have been fixed. A comprehensive
545 list of changes is not shown here for practical reasons.
547 1.2. Terminology
549 AAA
551 Authentication, Authorization and Accounting.
553 ABNF
555 Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own
556 formal syntax and rules. It is based on the Backus-Naur Form and
557 is used to define message exchanges in a bi-directional
558 communications protocol.
560 Accounting
562 The act of collecting information on resource usage for the
563 purpose of capacity planning, auditing, billing or cost
564 allocation.
566 Accounting Record
568 An accounting record represents a summary of the resource
569 consumption of a user over the entire session. Accounting servers
570 creating the accounting record may do so by processing interim
571 accounting events or accounting events from several devices
572 serving the same user.
574 Authentication
576 The act of verifying the identity of an entity (subject).
578 Authorization
580 The act of determining whether a requesting entity (subject) will
581 be allowed access to a resource (object).
583 AVP
585 The Diameter protocol consists of a header followed by one or more
586 Attribute-Value-Pairs (AVPs). An AVP includes a header and is
587 used to encapsulate protocol-specific data (e.g., routing
588 information) as well as authentication, authorization or
589 accounting information.
591 Diameter Agent
593 A Diameter Agent is a Diameter Node that provides either relay,
594 proxy, redirect or translation services.
596 Diameter Client
598 A Diameter Client is a Diameter Node that supports Diameter client
599 applications as well as the base protocol. Diameter Clients are
600 often implemented in devices situated at the edge of a network and
601 provide access control services for that network. Typical
602 examples of Diameter Clients include the Network Access Server
603 (NAS) and the Mobile IP Foreign Agent (FA).
605 Diameter Node
607 A Diameter Node is a host process that implements the Diameter
608 protocol, and acts either as a Client, Agent or Server.
610 Diameter Peer
612 Two Diameter Nodes sharing a direct TCP or SCTP transport
613 connection are called Diameter Peers.
615 Diameter Server
617 A Diameter Server is a Diameter Node that handles authentication,
618 authorization and accounting requests for a particular realm. By
619 its very nature, a Diameter Server must support Diameter server
620 applications in addition to the base protocol.
622 Downstream
624 Downstream is used to identify the direction of a particular
625 Diameter message from the Home Server towards the Diameter Client.
627 Home Realm
629 A Home Realm is the administrative domain with which the user
630 maintains an account relationship.
632 Home Server
634 A Diameter Server which serves the Home Realm.
636 Interim accounting
638 An interim accounting message provides a snapshot of usage during
639 a user's session. It is typically implemented in order to provide
640 for partial accounting of a user's session in the case a device
641 reboot or other network problem prevents the delivery of a session
642 summary message or session record.
644 Local Realm
646 A local realm is the administrative domain providing services to a
647 user. An administrative domain may act as a local realm for
648 certain users, while being a home realm for others.
650 Multi-session
652 A multi-session represents a logical linking of several sessions.
653 Multi-sessions are tracked by using the Acct-Multi-Session-Id. An
654 example of a multi-session would be a Multi-link PPP bundle. Each
655 leg of the bundle would be a session while the entire bundle would
656 be a multi-session.
658 Network Access Identifier
660 The Network Access Identifier, or NAI [RFC4282], is used in the
661 Diameter protocol to extract a user's identity and realm. The
662 identity is used to identify the user during authentication and/or
663 authorization, while the realm is used for message routing
664 purposes.
666 Proxy Agent or Proxy
668 In addition to forwarding requests and responses, proxies make
669 policy decisions relating to resource usage and provisioning.
670 This is typically accomplished by tracking the state of NAS
671 devices. While proxies typically do not respond to client
672 Requests prior to receiving a Response from the server, they may
673 originate Reject messages in cases where policies are violated.
674 As a result, proxies need to understand the semantics of the
675 messages passing through them, and may not support all Diameter
676 applications.
678 Realm
680 The string in the NAI that immediately follows the '@' character.
681 NAI realm names are required to be unique, and are piggybacked on
682 the administration of the DNS namespace. Diameter makes use of
683 the realm, also loosely referred to as domain, to determine
684 whether messages can be satisfied locally, or whether they must be
685 routed or redirected. In RADIUS, realm names are not necessarily
686 piggybacked on the DNS namespace but may be independent of it.
688 Real-time Accounting
690 Real-time accounting involves the processing of information on
691 resource usage within a defined time window. Time constraints are
692 typically imposed in order to limit financial risk. The Diameter
693 Credit Control Application [RFC4006] is an example of an
694 application that defines real-time accounting functionality.
696 Relay Agent or Relay
698 Relays forward requests and responses based on routing-related
699 AVPs and routing table entries. Since relays do not make policy
700 decisions, they do not examine or alter non-routing AVPs. As a
701 result, relays never originate messages, do not need to understand
702 the semantics of messages or non-routing AVPs, and are capable of
703 handling any Diameter application or message type. Since relays
704 make decisions based on information in routing AVPs and realm
705 forwarding tables they do not keep state on NAS resource usage or
706 sessions in progress.
708 Redirect Agent
710 Rather than forwarding requests and responses between clients and
711 servers, redirect agents refer clients to servers and allow them
712 to communicate directly. Since redirect agents do not sit in the
713 forwarding path, they do not alter any AVPs transiting between
714 client and server. Redirect agents do not originate messages and
715 are capable of handling any message type, although they may be
716 configured only to redirect messages of certain types, while
717 acting as relay or proxy agents for other types. As with relay
718 agents, redirect agents do not keep state with respect to sessions
719 or NAS resources.
721 Session
723 A session is a related progression of events devoted to a
724 particular activity. Diameter application documents provide
725 guidelines as to when a session begins and ends. All Diameter
726 packets with the same Session-Id are considered to be part of the
727 same session.
729 Stateful Agent
731 A stateful agent is one that maintains session state information,
732 by keeping track of all authorized active sessions. Each
733 authorized session is bound to a particular service, and its state
734 is considered active either until it is notified otherwise, or by
735 expiration.
737 Sub-session
739 A sub-session represents a distinct service (e.g., QoS or data
740 characteristics) provided to a given session. These services may
741 happen concurrently (e.g., simultaneous voice and data transfer
742 during the same session) or serially. These changes in sessions
743 are tracked with the Accounting-Sub-Session-Id.
745 Transaction state
747 The Diameter protocol requires that agents maintain transaction
748 state, which is used for failover purposes. Transaction state
749 implies that upon forwarding a request, the Hop-by-Hop identifier
750 is saved; the field is replaced with a locally unique identifier,
751 which is restored to its original value when the corresponding
752 answer is received. The request's state is released upon receipt
753 of the answer. A stateless agent is one that only maintains
754 transaction state.
756 Translation Agent
758 A translation agent is a stateful Diameter node that performs
759 protocol translation between Diameter and another AAA protocol,
760 such as RADIUS.
762 Upstream
764 Upstream is used to identify the direction of a particular
765 Diameter message from the Diameter Client towards the Home Server.
767 User
769 The entity or device requesting or using some resource, in support
770 of which a Diameter client has generated a request.
772 1.3. Approach to Extensibility
774 The Diameter protocol is designed to be extensible, using several
775 mechanisms, including:
777 o Defining new AVP values
779 o Creating new AVPs
781 o Creating new commands
783 o Creating new applications
785 From the point of view of extensibility Diameter authentication,
786 authorization and accounting applications are treated in the same
787 way.
789 Note: Protocol designers should try to re-use existing functionality,
790 namely AVP values, AVPs, commands, and Diameter applications. Reuse
791 simplifies standardization and implementation. To avoid potential
792 interoperability issues it is important to ensure that the semantics
793 of the re-used features are well understood. Given that Diameter can
794 also carry RADIUS attributes as Diameter AVPs, such re-use
795 considerations apply also to existing RADIUS attributes that may be
796 useful in a Diameter application.
798 1.3.1. Defining New AVP Values
800 In order to allocate a new AVP value for AVPs defined in the Diameter
801 Base protocol, the IETF needs to approve a new RFC that describes the
802 AVP value. IANA considerations for these AVP values are discussed in
803 Section 11.3.
805 The allocation of AVP values for other AVPs is guided by the IANA
806 considerations of the document that defines those AVPs. Typically,
807 allocation of new values for an AVP defined in an IETF RFC would
808 require IETF Review [RFC5226], whereas values for vendor-specific
809 AVPs can be allocated by the vendor.
811 1.3.2. Creating New AVPs
813 A new AVP being defined MUST use one of the data types listed in
814 Section 4.2 or Section 4.3. If an appropriate derived data type is
815 already defined, it SHOULD be used instead of a base data type to
816 encourage reusability and good design practice.
818 In the event that a logical grouping of AVPs is necessary, and
819 multiple "groups" are possible in a given command, it is recommended
820 that a Grouped AVP be used (see Section 4.4).
822 The creation of new AVPs can happen in various ways. The recommended
823 approach is to define a new general-purpose AVP in a standards track
824 RFC approved by the IETF. However, as described in Section 11.1.1
825 there are also other mechanisms.
827 1.3.3. Creating New Commands
829 A new Command Code MUST be allocated when required AVPs (those
830 indicated as {AVP} in the CCF definition) are added to, deleted from
831 or redefined in (for example, by changing a required AVP into an
832 optional one) an existing command.
834 Furthermore, if the transport characteristics of a command are
835 changed (for example, with respect to the number of round trips
836 required) a new Command Code MUST be registered.
838 A change to the CCF of a command, such as described above, MUST
839 result in the definition of a new Command Code. This subsequently
840 leads to the need to define a new Diameter Application for any
841 application that will use that new Command.
843 The IANA considerations for command codes are discussed in
844 Section 3.1.
846 1.3.4. Creating New Diameter Applications
848 Every Diameter application specification MUST have an IANA assigned
849 Application Id (see Section 2.4). The managed Application Id space
850 is flat and there is no relationship between different Diameter
851 applications with respect to their Application Ids. As such, there is
852 no versioning support provided by these application Ids itself; every
853 Diameter application is a standalone application. If the application
854 has a relationship with other Diameter applications, such a
855 relationship is not known to Diameter.
857 Before describing the rules for creating new Diameter applications it
858 is important to discuss the semantics of the AVP occurrences as
859 stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There
860 is no relationship imposed between the two; they are set
861 independently.
863 o The CCF indicates what AVPs are placed into a Diameter Command by
864 the sender of that Command. Often, since there are multiple modes
865 of protocol interactions many of the AVPs are indicated as
866 optional.
868 o The M-bit allows the sender to indicate to the receiver whether or
869 not understanding the semantics of an AVP and its content is
870 mandatory. If the M-bit is set by the sender and the receiver
871 does not understand the AVP or the values carried within that AVP
872 then a failure is generated (see Section 7).
874 It is the decision of the protocol designer when to develop a new
875 Diameter application rather than extending Diameter in other ways.
876 However, a new Diameter application MUST be created when one or more
877 of the following criteria are met:
879 M-bit Setting
881 An AVP with the M-bit in the MUST column of the AVP flag table is
882 added to an existing Command/Application.
884 An AVP with the M-bit in the MAY column of the AVP flag table is
885 added to an existing Command/Application.
887 Note: The M-bit setting for a given AVP is relevant to an
888 Application and each command within that application which
889 includes the AVP. That is, if an AVP appears in two commands for
890 application Foo and the M-bit settings are different in each
891 command, then there should be two AVP flag tables describing when
892 to set the M-bit.
894 Commands
896 A new command is used within the existing application either
897 because an additional command is added, an existing command has
898 been modified so that a new Command Code had to be registered, or
899 a command has been deleted.
901 AVP Flag bits
903 An existing application changes the meaning/semantics of their AVP
904 Flags or adds new flag bits then a new Diameter application MUST
905 be created.
907 If the CCF definition of a command allows it, an implementation may
908 add arbitrary optional AVPs with the M-bit cleared (including vendor-
909 specific AVPs) to that command without needing to define a new
910 application. Please refer to Section 11.1.1 for details.
912 2. Protocol Overview
914 The base Diameter protocol concerns itself with establishing
915 connections to peers, capabilities negotiation, how messages are sent
916 and routed through peers, and how the connections are eventually torn
917 down. The base protocol also defines certain rules that apply to all
918 message exchanges between Diameter nodes.
920 Communication between Diameter peers begins with one peer sending a
921 message to another Diameter peer. The set of AVPs included in the
922 message is determined by a particular Diameter application. One AVP
923 that is included to reference a user's session is the Session-Id.
925 The initial request for authentication and/or authorization of a user
926 would include the Session-Id AVP. The Session-Id is then used in all
927 subsequent messages to identify the user's session (see Section 8 for
928 more information). The communicating party may accept the request,
929 or reject it by returning an answer message with the Result-Code AVP
930 set to indicate an error occurred. The specific behavior of the
931 Diameter server or client receiving a request depends on the Diameter
932 application employed.
934 Session state (associated with a Session-Id) MUST be freed upon
935 receipt of the Session-Termination-Request, Session-Termination-
936 Answer, expiration of authorized service time in the Session-Timeout
937 AVP, and according to rules established in a particular Diameter
938 application.
940 The base Diameter protocol may be used by itself for accounting
941 applications. For authentication and authorization, it is always
942 extended for a particular application.
944 Diameter Clients MUST support the base protocol, which includes
945 accounting. In addition, they MUST fully support each Diameter
946 application that is needed to implement the client's service, e.g.,
947 NASREQ and/or Mobile IPv4. A Diameter Client MUST be referred to as
948 "Diameter X Client" where X is the application which it supports, and
949 not a "Diameter Client".
951 Diameter Servers MUST support the base protocol, which includes
952 accounting. In addition, they MUST fully support each Diameter
953 application that is needed to implement the intended service, e.g.,
954 NASREQ and/or Mobile IPv4. A Diameter Server MUST be referred to as
955 "Diameter X Server" where X is the application which it supports, and
956 not a "Diameter Server".
958 Diameter Relays and redirect agents are transparent to the Diameter
959 applications but they MUST support the Diameter base protocol, which
960 includes accounting, and all Diameter applications.
962 Diameter proxies MUST support the base protocol, which includes
963 accounting. In addition, they MUST fully support each Diameter
964 application that is needed to implement proxied services, e.g.,
965 NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as
966 "Diameter X Proxy" where X is the application which it supports, and
967 not a "Diameter Proxy".
969 2.1. Transport
971 The Diameter Transport profile is defined in [RFC3539].
973 The base Diameter protocol is run on port 3868 for both TCP [RFC793]
974 and SCTP [RFC4960]. For TLS [RFC5246] and DTLS [RFC6347], a Diameter
975 node that initiate a connection prior to any message exchanges MUST
976 run on port [TBD]. It is assumed that TLS is run on top of TCP when
977 it is used and DTLS is run on top of SCTP when it is used.
979 If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
980 connections on port [TBD] (i.e., the peer complies only with
981 [RFC3588]), then the initiator MAY revert to using TCP or SCTP on
982 port 3868. Note that this scheme is kept only for the purpose of
983 backward compatibility and that there are inherent security
984 vulnerabilities when the initial CER/CEA messages are sent
985 unprotected (see Section 5.6).
987 Diameter clients MUST support either TCP or SCTP; agents and servers
988 SHOULD support both.
990 A Diameter node MAY initiate connections from a source port other
991 than the one that it declares it accepts incoming connections on, and
992 MUST always be prepared to receive connections on port 3868 for TCP
993 or SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When
994 DNS-based peer discovery (Section 5.2) is used, the port numbers
995 received from SRV records take precedence over the default ports
996 (3868 and [TBD]).
998 A given Diameter instance of the peer state machine MUST NOT use more
999 than one transport connection to communicate with a given peer,
1000 unless multiple instances exist on the peer in which case a separate
1001 connection per process is allowed.
1003 When no transport connection exists with a peer, an attempt to
1004 connect SHOULD be periodically made. This behavior is handled via
1005 the Tc timer (see Section 12 for details), whose recommended value is
1006 30 seconds. There are certain exceptions to this rule, such as when
1007 a peer has terminated the transport connection stating that it does
1008 not wish to communicate.
1010 When connecting to a peer and either zero or more transports are
1011 specified, TLS SHOULD be tried first, followed by DTLS, then by TCP
1012 and finally by SCTP. See Section 5.2 for more information on peer
1013 discovery.
1015 Diameter implementations SHOULD be able to interpret ICMP protocol
1016 port unreachable messages as explicit indications that the server is
1017 not reachable, subject to security policy on trusting such messages.
1018 Further guidance regarding the treatment of ICMP errors can be found
1019 in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be
1020 able to interpret a reset from the transport and timed-out connection
1021 attempts. If Diameter receives data from the lower layer that cannot
1022 be parsed or identified as a Diameter error made by the peer, the
1023 stream is compromised and cannot be recovered. The transport
1024 connection MUST be closed using a RESET call (send a TCP RST bit) or
1025 an SCTP ABORT message (graceful closure is compromised).
1027 2.1.1. SCTP Guidelines
1029 Diameter messages SHOULD be mapped into SCTP streams in a way that
1030 avoids head-of-the-line (HOL) blocking. Among different ways of
1031 performing the mapping that fulfill this requirement it is
1032 RECOMMENDED that a Diameter node sends every Diameter message
1033 (request or response) over the stream zero with the unordered flag
1034 set. However, Diameter nodes MAY select and implement other design
1035 alternatives for avoiding HOL blocking such as using multiple streams
1036 with the unordered flag cleared (as originally instructed in
1037 RFC3588). On the receiving side, a Diameter entity MUST be ready to
1038 receive Diameter messages over any stream and it is free to return
1039 responses over a different stream. This way, both sides manage the
1040 available streams in the sending direction, independently of the
1041 streams chosen by the other side to send a particular Diameter
1042 message. These messages can be out-of-order and belong to different
1043 Diameter sessions.
1045 Out-of-order delivery has special concerns during a connection
1046 establishment and termination. When a connection is established, the
1047 responder side sends a CEA message and moves to R-Open state as
1048 specified in Section 5.6. If an application message is sent shortly
1049 after the CEA and delivered out-of-order, the initiator side, still
1050 in Wait-I-CEA state, will discard the application message and close
1051 the connection. In order to avoid this race condition, the receiver
1052 side SHOULD NOT use out-of-order delivery methods until the first
1053 message has been received from the initiator, proving that it has
1054 moved to I-Open state. To trigger such message, the receiver side
1055 could send a DWR immediatly after sending CEA. Upon reception of the
1056 corresponding DWA, the receiver side should start using out-of-order
1057 delivery methods to counter the HOL blocking.
1059 Another race condition may occur when DPR and DPA messages are used.
1060 Both DPR and DPA are small in size, thus they may be delivered faster
1061 to the peer than application messages when out-of-order delivery
1062 mechanism is used. Therefore, it is possible that a DPR/DPA exchange
1063 completes while application messages are still in transit, resulting
1064 to a loss of these messages. An implementation could mitigate this
1065 race condition, for example, using timers and wait for a short period
1066 of time for pending application level messages to arrive before
1067 proceeding to disconnect the transport connection. Eventually, lost
1068 messages are handled by the retransmission mechanism described in
1069 Section 5.5.4.
1071 A Diameter agent SHOULD use dedicated payload protocol identifiers
1072 (PPID) for clear text and encrypted SCTP DATA chunks instead of only
1073 using the unspecified payload protocol identifier (value 0). For
1074 this purpose two PPID values are allocated. The PPID value TBD2 is
1075 for Diameter messages in clear text SCTP DATA chunks and the PPID
1076 value TBD3 is for Diameter messages in protected DTLS/SCTP DATA
1077 chunks.
1079 2.2. Securing Diameter Messages
1081 Connections between Diameter peers SHOULD be protected by TLS/TCP and
1082 DTLS/SCTP. All Diameter base protocol implementations MUST support
1083 the use of TLS/TCP and DTLS/SCTP. If desired, alternative security
1084 mechanisms that are independent of Diameter, such as IPsec [RFC4301],
1085 can be deployed to secure connections between peers. The Diameter
1086 protocol MUST NOT be used without one of TLS, DTLS or IPsec.
1088 2.3. Diameter Application Compliance
1090 Application Ids are advertised during the capabilities exchange phase
1091 (see Section 5.3). Advertising support of an application implies
1092 that the sender supports the functionality specified in the
1093 respective Diameter application specification.
1095 Implementations MAY add arbitrary optional AVPs with the M-bit
1096 cleared (including vendor-specific AVPs) to a command defined in an
1097 application, but only if the command's CCF syntax specification
1098 allows for it. Please refer to Section 11.1.1 for details.
1100 2.4. Application Identifiers
1102 Each Diameter application MUST have an IANA assigned Application Id.
1103 The base protocol does not require an Application Id since its
1104 support is mandatory. During the capabilities exchange, Diameter
1105 nodes inform their peers of locally supported applications.
1106 Furthermore, all Diameter messages contain an Application Id, which
1107 is used in the message forwarding process.
1109 The following Application Id values are defined:
1111 Diameter Common Messages 0
1112 Diameter Base Accounting 3
1113 Relay 0xffffffff
1115 Relay and redirect agents MUST advertise the Relay Application
1116 Identifier, while all other Diameter nodes MUST advertise locally
1117 supported applications. The receiver of a Capabilities Exchange
1118 message advertising Relay service MUST assume that the sender
1119 supports all current and future applications.
1121 Diameter relay and proxy agents are responsible for finding an
1122 upstream server that supports the application of a particular
1123 message. If none can be found, an error message is returned with the
1124 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1126 2.5. Connections vs. Sessions
1128 This section attempts to provide the reader with an understanding of
1129 the difference between connection and session, which are terms used
1130 extensively throughout this document.
1132 A connection refers to a transport level connection between two peers
1133 that is used to send and receive Diameter messages. A session is a
1134 logical concept at the application layer existing between the
1135 Diameter client and the Diameter server; it is identified via the
1136 Session-Id AVP.
1138 +--------+ +-------+ +--------+
1139 | Client | | Relay | | Server |
1140 +--------+ +-------+ +--------+
1141 <----------> <---------->
1142 peer connection A peer connection B
1144 <----------------------------->
1145 User session x
1147 Figure 1: Diameter connections and sessions
1149 In the example provided in Figure 1, peer connection A is established
1150 between the Client and the Relay. Peer connection B is established
1151 between the Relay and the Server. User session X spans from the
1152 Client via the Relay to the Server. Each "user" of a service causes
1153 an auth request to be sent, with a unique session identifier. Once
1154 accepted by the server, both the client and the server are aware of
1155 the session.
1157 It is important to note that there is no relationship between a
1158 connection and a session, and that Diameter messages for multiple
1159 sessions are all multiplexed through a single connection. Also note
1160 that Diameter messages pertaining to the session, both application
1161 specific and those that are defined in this document such as ASR/ASA,
1162 RAR/RAA and STR/STA MUST carry the Application Id of the application.
1163 Diameter messages pertaining to peer connection establishment and
1164 maintenance such as CER/CEA, DWR/DWA and DPR/DPA MUST carry an
1165 Application Id of zero (0).
1167 2.6. Peer Table
1169 The Diameter Peer Table is used in message forwarding, and referenced
1170 by the Routing Table. A Peer Table entry contains the following
1171 fields:
1173 Host identity
1175 Following the conventions described for the DiameterIdentity
1176 derived AVP data format in Section 4.3.1, this field contains the
1177 contents of the Origin-Host (Section 6.3) AVP found in the CER or
1178 CEA message.
1180 StatusT
1182 This is the state of the peer entry, and MUST match one of the
1183 values listed in Section 5.6.
1185 Static or Dynamic
1187 Specifies whether a peer entry was statically configured or
1188 dynamically discovered.
1190 Expiration time
1192 Specifies the time at which dynamically discovered peer table
1193 entries are to be either refreshed, or expired.
1195 TLS/TCP and DTLS/SCTP Enabled
1197 Specifies whether TLS/TCP and DTLS/SCTP is to be used when
1198 communicating with the peer.
1200 Additional security information, when needed (e.g., keys,
1201 certificates).
1203 2.7. Routing Table
1205 All Realm-Based routing lookups are performed against what is
1206 commonly known as the Routing Table (see Section 12). Each Routing
1207 Table entry contains the following fields:
1209 Realm Name
1211 This is the field that MUST be used as a primary key in the
1212 routing table lookups. Note that some implementations perform
1213 their lookups based on longest-match-from-the-right on the realm
1214 rather than requiring an exact match.
1216 Application Identifier
1218 An application is identified by an Application Id. A route entry
1219 can have a different destination based on the Application Id in
1220 the message header. This field MUST be used as a secondary key
1221 field in routing table lookups.
1223 Local Action
1225 The Local Action field is used to identify how a message should be
1226 treated. The following actions are supported:
1228 1. LOCAL - Diameter messages that can be satisfied locally, and
1229 do not need to be routed to another Diameter entity.
1231 2. RELAY - All Diameter messages that fall within this category
1232 MUST be routed to a next hop Diameter entity that is indicated
1233 by the identifier described below. Routing is done without
1234 modifying any non-routing AVPs. See Section 6.1.9 for
1235 relaying guidelines.
1237 3. PROXY - All Diameter messages that fall within this category
1238 MUST be routed to a next Diameter entity that is indicated by
1239 the identifier described below. The local server MAY apply
1240 its local policies to the message by including new AVPs to the
1241 message prior to routing. See Section 6.1.9 for proxying
1242 guidelines.
1244 4. REDIRECT - Diameter messages that fall within this category
1245 MUST have the identity of the home Diameter server(s)
1246 appended, and returned to the sender of the message. See
1247 Section 6.1.8 for redirection guidelines.
1249 Server Identifier
1251 The identity of one or more servers to which the message is to be
1252 routed. This identity MUST also be present in the Host Identity
1253 field of the Peer Table (Section 2.6). When the Local Action is
1254 set to RELAY or PROXY, this field contains the identity of the
1255 server(s) to which the message MUST be routed. When the Local
1256 Action field is set to REDIRECT, this field contains the identity
1257 of one or more servers to which the message MUST be redirected.
1259 Static or Dynamic
1261 Specifies whether a route entry was statically configured or
1262 dynamically discovered.
1264 Expiration time
1266 Specifies the time at which a dynamically discovered route table
1267 entry expires.
1269 It is important to note that Diameter agents MUST support at least
1270 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
1271 Agents do not need to support all modes of operation in order to
1272 conform with the protocol specification, but MUST follow the protocol
1273 compliance guidelines in Section 2. Relay agents and proxies MUST
1274 NOT reorder AVPs.
1276 The routing table MAY include a default entry that MUST be used for
1277 any requests not matching any of the other entries. The routing
1278 table MAY consist of only such an entry.
1280 When a request is routed, the target server MUST have advertised the
1281 Application Id (see Section 2.4) for the given message, or have
1282 advertised itself as a relay or proxy agent. Otherwise, an error is
1283 returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1285 2.8. Role of Diameter Agents
1287 In addition to clients and servers, the Diameter protocol introduces
1288 relay, proxy, redirect, and translation agents, each of which is
1289 defined in Section 1.2. Diameter agents are useful for several
1290 reasons:
1292 o They can distribute administration of systems to a configurable
1293 grouping, including the maintenance of security associations.
1295 o They can be used for concentration of requests from an number of
1296 co-located or distributed NAS equipment sets to a set of like user
1297 groups.
1299 o They can do value-added processing to the requests or responses.
1301 o They can be used for load balancing.
1303 o A complex network will have multiple authentication sources, they
1304 can sort requests and forward towards the correct target.
1306 The Diameter protocol requires that agents maintain transaction
1307 state, which is used for failover purposes. Transaction state
1308 implies that upon forwarding a request, its Hop-by-Hop identifier is
1309 saved; the field is replaced with a locally unique identifier, which
1310 is restored to its original value when the corresponding answer is
1311 received. The request's state is released upon receipt of the
1312 answer. A stateless agent is one that only maintains transaction
1313 state.
1315 The Proxy-Info AVP allows stateless agents to add local state to a
1316 Diameter request, with the guarantee that the same state will be
1317 present in the answer. However, the protocol's failover procedures
1318 require that agents maintain a copy of pending requests.
1320 A stateful agent is one that maintains session state information by
1321 keeping track of all authorized active sessions. Each authorized
1322 session is bound to a particular service, and its state is considered
1323 active either until the agent is notified otherwise, or the session
1324 expires. Each authorized session has an expiration, which is
1325 communicated by Diameter servers via the Session-Timeout AVP.
1327 Maintaining session state may be useful in certain applications, such
1328 as:
1330 o Protocol translation (e.g., RADIUS <-> Diameter)
1332 o Limiting resources authorized to a particular user
1334 o Per user or transaction auditing
1336 A Diameter agent MAY act in a stateful manner for some requests and
1337 be stateless for others. A Diameter implementation MAY act as one
1338 type of agent for some requests, and as another type of agent for
1339 others.
1341 2.8.1. Relay Agents
1343 Relay Agents are Diameter agents that accept requests and route
1344 messages to other Diameter nodes based on information found in the
1345 messages (e.g., Destination-Realm). This routing decision is
1346 performed using a list of supported realms, and known peers. This is
1347 known as the Routing Table, as is defined further in Section 2.7.
1349 Relays may, for example, be used to aggregate requests from multiple
1350 Network Access Servers (NASes) within a common geographical area
1351 (POP). The use of Relays is advantageous since it eliminates the
1352 need for NASes to be configured with the necessary security
1353 information they would otherwise require to communicate with Diameter
1354 servers in other realms. Likewise, this reduces the configuration
1355 load on Diameter servers that would otherwise be necessary when NASes
1356 are added, changed or deleted.
1358 Relays modify Diameter messages by inserting and removing routing
1359 information, but do not modify any other portion of a message.
1360 Relays SHOULD NOT maintain session state but MUST maintain
1361 transaction state.
1363 +------+ ---------> +------+ ---------> +------+
1364 | | 1. Request | | 2. Request | |
1365 | NAS | | DRL | | HMS |
1366 | | 4. Answer | | 3. Answer | |
1367 +------+ <--------- +------+ <--------- +------+
1368 example.net example.net example.com
1370 Figure 2: Relaying of Diameter messages
1372 The example provided in Figure 2 depicts a request issued from NAS,
1373 which is an access device, for the user bob@example.com. Prior to
1374 issuing the request, NAS performs a Diameter route lookup, using
1375 "example.com" as the key, and determines that the message is to be
1376 relayed to DRL, which is a Diameter Relay. DRL performs the same
1377 route lookup as NAS, and relays the message to HMS, which is
1378 example.com's Home Diameter Server. HMS identifies that the request
1379 can be locally supported (via the realm), processes the
1380 authentication and/or authorization request, and replies with an
1381 answer, which is routed back to NAS using saved transaction state.
1383 Since Relays do not perform any application level processing, they
1384 provide relaying services for all Diameter applications, and
1385 therefore MUST advertise the Relay Application Id.
1387 2.8.2. Proxy Agents
1389 Similarly to relays, proxy agents route Diameter messages using the
1390 Diameter Routing Table. However, they differ since they modify
1391 messages to implement policy enforcement. This requires that proxies
1392 maintain the state of their downstream peers (e.g., access devices)
1393 to enforce resource usage, provide admission control, and
1394 provisioning.
1396 Proxies may, for example, be used in call control centers or access
1397 ISPs that provide outsourced connections, they can monitor the number
1398 and types of ports in use, and make allocation and admission
1399 decisions according to their configuration.
1401 Since enforcing policies requires an understanding of the service
1402 being provided, Proxies MUST only advertise the Diameter applications
1403 they support.
1405 2.8.3. Redirect Agents
1407 Redirect agents are useful in scenarios where the Diameter routing
1408 configuration needs to be centralized. An example is a redirect
1409 agent that provides services to all members of a consortium, but does
1410 not wish to be burdened with relaying all messages between realms.
1412 This scenario is advantageous since it does not require that the
1413 consortium provide routing updates to its members when changes are
1414 made to a member's infrastructure.
1416 Since redirect agents do not relay messages, and only return an
1417 answer with the information necessary for Diameter agents to
1418 communicate directly, they do not modify messages. Since redirect
1419 agents do not receive answer messages, they cannot maintain session
1420 state.
1422 The example provided in Figure 3 depicts a request issued from the
1423 access device, NAS, for the user bob@example.com. The message is
1424 forwarded by the NAS to its relay, DRL, which does not have a routing
1425 entry in its Diameter Routing Table for example.com. DRL has a
1426 default route configured to DRD, which is a redirect agent that
1427 returns a redirect notification to DRL, as well as HMS' contact
1428 information. Upon receipt of the redirect notification, DRL
1429 establishes a transport connection with HMS, if one doesn't already
1430 exist, and forwards the request to it.
1432 +------+
1433 | |
1434 | DRD |
1435 | |
1436 +------+
1437 ^ |
1438 2. Request | | 3. Redirection
1439 | | Notification
1440 | v
1441 +------+ ---------> +------+ ---------> +------+
1442 | | 1. Request | | 4. Request | |
1443 | NAS | | DRL | | HMS |
1444 | | 6. Answer | | 5. Answer | |
1445 +------+ <--------- +------+ <--------- +------+
1446 example.net example.net example.com
1448 Figure 3: Redirecting a Diameter Message
1450 Since redirect agents do not perform any application level
1451 processing, they provide relaying services for all Diameter
1452 applications, and therefore MUST advertise the Relay Application
1453 Identifier.
1455 2.8.4. Translation Agents
1457 A translation agent is a device that provides translation between two
1458 protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation
1459 agents are likely to be used as aggregation servers to communicate
1460 with a Diameter infrastructure, while allowing for the embedded
1461 systems to be migrated at a slower pace.
1463 Given that the Diameter protocol introduces the concept of long-lived
1464 authorized sessions, translation agents MUST be session stateful and
1465 MUST maintain transaction state.
1467 Translation of messages can only occur if the agent recognizes the
1468 application of a particular request, and therefore translation agents
1469 MUST only advertise their locally supported applications.
1471 +------+ ---------> +------+ ---------> +------+
1472 | | RADIUS Request | | Diameter Request | |
1473 | NAS | | TLA | | HMS |
1474 | | RADIUS Answer | | Diameter Answer | |
1475 +------+ <--------- +------+ <--------- +------+
1476 example.net example.net example.com
1478 Figure 4: Translation of RADIUS to Diameter
1480 2.9. Diameter Path Authorization
1482 As noted in Section 2.2, Diameter provides transmission level
1483 security for each connection using TLS/TCP and DTLS/SCTP. Therefore,
1484 each connection can be authenticated, replay and integrity protected.
1486 In addition to authenticating each connection, each connection as
1487 well as the entire session MUST also be authorized. Before
1488 initiating a connection, a Diameter Peer MUST check that its peers
1489 are authorized to act in their roles. For example, a Diameter peer
1490 may be authentic, but that does not mean that it is authorized to act
1491 as a Diameter Server advertising a set of Diameter applications.
1493 Prior to bringing up a connection, authorization checks are performed
1494 at each connection along the path. Diameter capabilities negotiation
1495 (CER/CEA) also MUST be carried out, in order to determine what
1496 Diameter applications are supported by each peer. Diameter sessions
1497 MUST be routed only through authorized nodes that have advertised
1498 support for the Diameter application required by the session.
1500 As noted in Section 6.1.9, a relay or proxy agent MUST append a
1501 Route-Record AVP to all requests forwarded. The AVP contains the
1502 identity of the peer the request was received from.
1504 The home Diameter server, prior to authorizing a session, MUST check
1505 the Route-Record AVPs to make sure that the route traversed by the
1506 request is acceptable. For example, administrators within the home
1507 realm may not wish to honor requests that have been routed through an
1508 untrusted realm. By authorizing a request, the home Diameter server
1509 is implicitly indicating its willingness to engage in the business
1510 transaction as specified by the contractual relationship between the
1511 server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
1512 message (see Section 7.1.5) is sent if the route traversed by the
1513 request is unacceptable.
1515 A home realm may also wish to check that each accounting request
1516 message corresponds to a Diameter response authorizing the session.
1517 Accounting requests without corresponding authorization responses
1518 SHOULD be subjected to further scrutiny, as should accounting
1519 requests indicating a difference between the requested and provided
1520 service.
1522 Forwarding of an authorization response is considered evidence of a
1523 willingness to take on financial risk relative to the session. A
1524 local realm may wish to limit this exposure, for example, by
1525 establishing credit limits for intermediate realms and refusing to
1526 accept responses which would violate those limits. By issuing an
1527 accounting request corresponding to the authorization response, the
1528 local realm implicitly indicates its agreement to provide the service
1529 indicated in the authorization response. If the service cannot be
1530 provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
1531 message MUST be sent within the accounting request; a Diameter client
1532 receiving an authorization response for a service that it cannot
1533 perform MUST NOT substitute an alternate service, and then send
1534 accounting requests for the alternate service instead.
1536 3. Diameter Header
1538 A summary of the Diameter header format is shown below. The fields
1539 are transmitted in network byte order.
1541 0 1 2 3
1542 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
1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1544 | Version | Message Length |
1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1546 | command flags | Command-Code |
1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1548 | Application-ID |
1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1550 | Hop-by-Hop Identifier |
1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1552 | End-to-End Identifier |
1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1554 | AVPs ...
1556 +-+-+-+-+-+-+-+-+-+-+-+-+-
1558 Version
1560 This Version field MUST be set to 1 to indicate Diameter Version
1561 1.
1563 Message Length
1565 The Message Length field is three octets and indicates the length
1566 of the Diameter message including the header fields and the padded
1567 AVPs. Thus the message length field is always a multiple of 4.
1569 Command Flags
1571 The Command Flags field is eight bits. The following bits are
1572 assigned:
1574 0 1 2 3 4 5 6 7
1575 +-+-+-+-+-+-+-+-+
1576 |R P E T r r r r|
1577 +-+-+-+-+-+-+-+-+
1579 R(equest)
1581 If set, the message is a request. If cleared, the message is
1582 an answer.
1584 P(roxiable)
1586 If set, the message MAY be proxied, relayed or redirected. If
1587 cleared, the message MUST be locally processed.
1589 E(rror)
1591 If set, the message contains a protocol error, and the message
1592 will not conform to the CCF described for this command.
1593 Messages with the 'E' bit set are commonly referred to as error
1594 messages. This bit MUST NOT be set in request messages (see
1595 Section 7.2).
1597 T(Potentially re-transmitted message)
1599 This flag is set after a link failover procedure, to aid the
1600 removal of duplicate requests. It is set when resending
1601 requests not yet acknowledged, as an indication of a possible
1602 duplicate due to a link failure. This bit MUST be cleared when
1603 sending a request for the first time, otherwise the sender MUST
1604 set this flag. Diameter agents only need to be concerned about
1605 the number of requests they send based on a single received
1606 request; retransmissions by other entities need not be tracked.
1607 Diameter agents that receive a request with the T flag set,
1608 MUST keep the T flag set in the forwarded request. This flag
1609 MUST NOT be set if an error answer message (e.g., a protocol
1610 error) has been received for the earlier message. It can be
1611 set only in cases where no answer has been received from the
1612 server for a request and the request is sent again. This flag
1613 MUST NOT be set in answer messages.
1615 r(eserved)
1617 These flag bits are reserved for future use, and MUST be set to
1618 zero, and ignored by the receiver.
1620 Command-Code
1622 The Command-Code field is three octets, and is used in order to
1623 communicate the command associated with the message. The 24-bit
1624 address space is managed by IANA (see Section 3.1).
1626 Command-Code values 16,777,214 and 16,777,215 (hexadecimal values
1627 FFFFFE -FFFFFF) are reserved for experimental use (see
1628 Section 11.2).
1630 Application-ID
1632 Application-ID is four octets and is used to identify to which
1633 application the message is applicable for. The application can be
1634 an authentication application, an accounting application or a
1635 vendor specific application.
1637 The value of the application-id field in the header MUST be the
1638 same as any relevant application-id AVPs contained in the message.
1640 Hop-by-Hop Identifier
1642 The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
1643 network byte order) and aids in matching requests and replies.
1644 The sender MUST ensure that the Hop-by-Hop identifier in a request
1645 is unique on a given connection at any given time, and MAY attempt
1646 to ensure that the number is unique across reboots. The sender of
1647 an Answer message MUST ensure that the Hop-by-Hop Identifier field
1648 contains the same value that was found in the corresponding
1649 request. The Hop-by-Hop identifier is normally a monotonically
1650 increasing number, whose start value was randomly generated. An
1651 answer message that is received with an unknown Hop-by-Hop
1652 Identifier MUST be discarded.
1654 End-to-End Identifier
1656 The End-to-End Identifier is an unsigned 32-bit integer field (in
1657 network byte order) and is used to detect duplicate messages.
1658 Upon reboot implementations MAY set the high order 12 bits to
1659 contain the low order 12 bits of current time, and the low order
1660 20 bits to a random value. Senders of request messages MUST
1661 insert a unique identifier on each message. The identifier MUST
1662 remain locally unique for a period of at least 4 minutes, even
1663 across reboots. The originator of an Answer message MUST ensure
1664 that the End-to-End Identifier field contains the same value that
1665 was found in the corresponding request. The End-to-End Identifier
1666 MUST NOT be modified by Diameter agents of any kind. The
1667 combination of the Origin-Host AVP (Section 6.3 and this field is
1668 used to detect duplicates. Duplicate requests SHOULD cause the
1669 same answer to be transmitted (modulo the hop-by-hop Identifier
1670 field and any routing AVPs that may be present), and MUST NOT
1671 affect any state that was set when the original request was
1672 processed. Duplicate answer messages that are to be locally
1673 consumed (see Section 6.2) SHOULD be silently discarded.
1675 AVPs
1677 AVPs are a method of encapsulating information relevant to the
1678 Diameter message. See Section 4 for more information on AVPs.
1680 3.1. Command Codes
1682 Each command Request/Answer pair is assigned a command code, and the
1683 sub-type (i.e., request or answer) is identified via the 'R' bit in
1684 the Command Flags field of the Diameter header.
1686 Every Diameter message MUST contain a command code in its header's
1687 Command-Code field, which is used to determine the action that is to
1688 be taken for a particular message. The following Command Codes are
1689 defined in the Diameter base protocol:
1691 Command-Name Abbrev. Code Reference
1692 --------------------------------------------------------
1693 Abort-Session-Request ASR 274 8.5.1
1694 Abort-Session-Answer ASA 274 8.5.2
1695 Accounting-Request ACR 271 9.7.1
1696 Accounting-Answer ACA 271 9.7.2
1697 Capabilities-Exchange- CER 257 5.3.1
1698 Request
1699 Capabilities-Exchange- CEA 257 5.3.2
1700 Answer
1701 Device-Watchdog-Request DWR 280 5.5.1
1702 Device-Watchdog-Answer DWA 280 5.5.2
1703 Disconnect-Peer-Request DPR 282 5.4.1
1704 Disconnect-Peer-Answer DPA 282 5.4.2
1705 Re-Auth-Request RAR 258 8.3.1
1706 Re-Auth-Answer RAA 258 8.3.2
1707 Session-Termination- STR 275 8.4.1
1708 Request
1709 Session-Termination- STA 275 8.4.2
1710 Answer
1712 3.2. Command Code Format Specification
1714 Every Command Code defined MUST include a corresponding Command Code
1715 Format (CCF) specification, which is used to define the AVPs that
1716 MUST or MAY be present when sending the message. The following ABNF
1717 specifies the CCF used in the definition:
1719 command-def = "<" command-name ">" "::=" diameter-message
1721 command-name = diameter-name
1723 diameter-name = ALPHA *(ALPHA / DIGIT / "-")
1725 diameter-message = header *fixed *required *optional
1727 header = "<" "Diameter Header:" command-id
1728 [r-bit] [p-bit] [e-bit] [application-id] ">"
1730 application-id = 1*DIGIT
1732 command-id = 1*DIGIT
1733 ; The Command Code assigned to the command
1735 r-bit = ", REQ"
1736 ; If present, the 'R' bit in the Command
1737 ; Flags is set, indicating that the message
1738 ; is a request, as opposed to an answer.
1740 p-bit = ", PXY"
1741 ; If present, the 'P' bit in the Command
1742 ; Flags is set, indicating that the message
1743 ; is proxiable.
1745 e-bit = ", ERR"
1746 ; If present, the 'E' bit in the Command
1747 ; Flags is set, indicating that the answer
1748 ; message contains a Result-Code AVP in
1749 ; the "protocol error" class.
1751 fixed = [qual] "<" avp-spec ">"
1752 ; Defines the fixed position of an AVP
1754 required = [qual] "{" avp-spec "}"
1755 ; The AVP MUST be present and can appear
1756 ; anywhere in the message.
1758 optional = [qual] "[" avp-name "]"
1759 ; The avp-name in the 'optional' rule cannot
1760 ; evaluate to any AVP Name which is included
1761 ; in a fixed or required rule. The AVP can
1762 ; appear anywhere in the message.
1763 ;
1764 ; NOTE: "[" and "]" have a slightly different
1765 ; meaning than in ABNF (RFC 5234]). These braces
1766 ; cannot be used to express optional fixed rules
1767 ; (such as an optional ICV at the end). To do
1768 ; this, the convention is '0*1fixed'.
1770 qual = [min] "*" [max]
1771 ; See ABNF conventions, RFC 5234, Section 4.
1772 ; The absence of any qualifiers depends on
1773 ; whether it precedes a fixed, required, or
1774 ; optional rule. If a fixed or required rule has
1775 ; no qualifier, then exactly one such AVP MUST
1776 ; be present. If an optional rule has no
1777 ; qualifier, then 0 or 1 such AVP may be
1778 ; present. If an optional rule has a qualifier,
1779 ; then the value of min MUST be 0 if present.
1781 min = 1*DIGIT
1782 ; The minimum number of times the element may
1783 ; be present. If absent, the default value is zero
1784 ; for fixed and optional rules and one for
1785 ; required rules. The value MUST be at least one
1786 ; for required rules.
1788 max = 1*DIGIT
1789 ; The maximum number of times the element may
1790 ; be present. If absent, the default value is
1791 ; infinity. A value of zero implies the AVP MUST
1792 ; NOT be present.
1794 avp-spec = diameter-name
1795 ; The avp-spec has to be an AVP Name, defined
1796 ; in the base or extended Diameter
1797 ; specifications.
1799 avp-name = avp-spec / "AVP"
1800 ; The string "AVP" stands for *any* arbitrary AVP
1801 ; Name, not otherwise listed in that command code
1802 ; definition. Addition this AVP is recommended for
1803 ; all command ABNFs to allow for extensibility.
1805 The following is a definition of a fictitious command code:
1807 Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
1808 { User-Name }
1809 1* { Origin-Host }
1810 * [ AVP ]
1812 3.3. Diameter Command Naming Conventions
1814 Diameter command names typically includes one or more English words
1815 followed by the verb Request or Answer. Each English word is
1816 delimited by a hyphen. A three-letter acronym for both the request
1817 and answer is also normally provided.
1819 An example is a message set used to terminate a session. The command
1820 name is Session-Terminate-Request and Session-Terminate-Answer, while
1821 the acronyms are STR and STA, respectively.
1823 Both the request and the answer for a given command share the same
1824 command code. The request is identified by the R(equest) bit in the
1825 Diameter header set to one (1), to ask that a particular action be
1826 performed, such as authorizing a user or terminating a session. Once
1827 the receiver has completed the request it issues the corresponding
1828 answer, which includes a result code that communicates one of the
1829 following:
1831 o The request was successful
1832 o The request failed
1834 o An additional request has to be sent to provide information the
1835 peer requires prior to returning a successful or failed answer.
1837 o The receiver could not process the request, but provides
1838 information about a Diameter peer that is able to satisfy the
1839 request, known as redirect.
1841 Additional information, encoded within AVPs, may also be included in
1842 answer messages.
1844 4. Diameter AVPs
1846 Diameter AVPs carry specific authentication, accounting,
1847 authorization and routing information as well as configuration
1848 details for the request and reply.
1850 Each AVP of type OctetString MUST be padded to align on a 32-bit
1851 boundary, while other AVP types align naturally. A number of zero-
1852 valued bytes are added to the end of the AVP Data field till a word
1853 boundary is reached. The length of the padding is not reflected in
1854 the AVP Length field.
1856 4.1. AVP Header
1858 The fields in the AVP header MUST be sent in network byte order. The
1859 format of the header is:
1861 0 1 2 3
1862 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
1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1864 | AVP Code |
1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1866 |V M P r r r r r| AVP Length |
1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1868 | Vendor-ID (opt) |
1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1870 | Data ...
1871 +-+-+-+-+-+-+-+-+
1873 AVP Code
1875 The AVP Code, combined with the Vendor-Id field, identifies the
1876 attribute uniquely. AVP numbers 1 through 255 are reserved for
1877 re-use of RADIUS attributes, without setting the Vendor-Id field.
1879 AVP numbers 256 and above are used for Diameter, which are
1880 allocated by IANA (see Section 11.1.1).
1882 AVP Flags
1884 The AVP Flags field informs the receiver how each attribute must
1885 be handled. New Diameter applications SHOULD NOT define
1886 additional AVP Flag bits. Note however, that new Diameter
1887 applications MAY define additional bits within the AVP Header, and
1888 an unrecognized bit SHOULD be considered an error. The sender of
1889 the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD
1890 ignore all 'r' (reserved) bits. The 'P' bit has been reserved for
1891 future usage of end-to-end security. At the time of writing there
1892 are no end-to-end security mechanisms specified therefore the 'P'
1893 bit SHOULD be set to 0.
1895 The 'M' Bit, known as the Mandatory bit, indicates whether the
1896 receiver of the AVP MUST parse and understand the semantic of the
1897 AVP including its content. The receiving entity MUST return an
1898 appropriate error message if it receives an AVP that has the M-bit
1899 set but does not understand it. An exception applies when the AVP
1900 is embedded within a Grouped AVP. See Section 4.4 for details.
1901 Diameter Relay and redirect agents MUST NOT reject messages with
1902 unrecognized AVPs.
1904 The 'M' bit MUST be set according to the rules defined in the
1905 application specification which introduces or re-uses this AVP.
1906 Within a given application, the M-bit setting for an AVP is either
1907 defined for all command types or for each command type.
1909 AVPs with the 'M' bit cleared are informational only and a
1910 receiver that receives a message with such an AVP that is not
1911 supported, or whose value is not supported, MAY simply ignore the
1912 AVP.
1914 The 'V' bit, known as the Vendor-Specific bit, indicates whether
1915 the optional Vendor-ID field is present in the AVP header. When
1916 set the AVP Code belongs to the specific vendor code address
1917 space.
1919 AVP Length
1921 The AVP Length field is three octets, and indicates the number of
1922 octets in this AVP including the AVP Code, AVP Length, AVP Flags,
1923 Vendor-ID field (if present) and the AVP data. If a message is
1924 received with an invalid attribute length, the message MUST be
1925 rejected.
1927 4.1.1. Optional Header Elements
1929 The AVP Header contains one optional field. This field is only
1930 present if the respective bit-flag is enabled.
1932 Vendor-ID
1934 The Vendor-ID field is present if the 'V' bit is set in the AVP
1935 Flags field. The optional four-octet Vendor-ID field contains the
1936 IANA assigned "SMI Network Management Private Enterprise Codes"
1937 [ENTERPRISE] value, encoded in network byte order. Any vendor or
1938 standardization organization that are also treated like vendors in
1939 the IANA managed "SMI Network Management Private Enterprise Codes"
1940 space wishing to implement a vendor-specific Diameter AVP MUST use
1941 their own Vendor-ID along with their privately managed AVP address
1942 space, guaranteeing that they will not collide with any other
1943 vendor's vendor-specific AVP(s), nor with future IETF AVPs.
1945 A vendor ID value of zero (0) corresponds to the IETF adopted AVP
1946 values, as managed by the IANA. Since the absence of the vendor
1947 ID field implies that the AVP in question is not vendor specific,
1948 implementations MUST NOT use the zero (0) vendor ID.
1950 4.2. Basic AVP Data Formats
1952 The Data field is zero or more octets and contains information
1953 specific to the Attribute. The format and length of the Data field
1954 is determined by the AVP Code and AVP Length fields. The format of
1955 the Data field MUST be one of the following base data types or a data
1956 type derived from the base data types. In the event that a new Basic
1957 AVP Data Format is needed, a new version of this RFC MUST be created.
1959 OctetString
1961 The data contains arbitrary data of variable length. Unless
1962 otherwise noted, the AVP Length field MUST be set to at least 8
1963 (12 if the 'V' bit is enabled). AVP Values of this type that are
1964 not a multiple of four-octets in length is followed by the
1965 necessary padding so that the next AVP (if any) will start on a
1966 32-bit boundary.
1968 Integer32
1970 32 bit signed value, in network byte order. The AVP Length field
1971 MUST be set to 12 (16 if the 'V' bit is enabled).
1973 Integer64
1975 64 bit signed value, in network byte order. The AVP Length field
1976 MUST be set to 16 (20 if the 'V' bit is enabled).
1978 Unsigned32
1980 32 bit unsigned value, in network byte order. The AVP Length
1981 field MUST be set to 12 (16 if the 'V' bit is enabled).
1983 Unsigned64
1985 64 bit unsigned value, in network byte order. The AVP Length
1986 field MUST be set to 16 (20 if the 'V' bit is enabled).
1988 Float32
1990 This represents floating point values of single precision as
1991 described by [FLOATPOINT]. The 32-bit value is transmitted in
1992 network byte order. The AVP Length field MUST be set to 12 (16 if
1993 the 'V' bit is enabled).
1995 Float64
1997 This represents floating point values of double precision as
1998 described by [FLOATPOINT]. The 64-bit value is transmitted in
1999 network byte order. The AVP Length field MUST be set to 16 (20 if
2000 the 'V' bit is enabled).
2002 Grouped
2004 The Data field is specified as a sequence of AVPs. Each of these
2005 AVPs follows - in the order in which they are specified -
2006 including their headers and padding. The AVP Length field is set
2007 to 8 (12 if the 'V' bit is enabled) plus the total length of all
2008 included AVPs, including their headers and padding. Thus the AVP
2009 length field of an AVP of type Grouped is always a multiple of 4.
2011 4.3. Derived AVP Data Formats
2013 In addition to using the Basic AVP Data Formats, applications may
2014 define data formats derived from the Basic AVP Data Formats. An
2015 application that defines new Derived AVP Data Formats MUST include
2016 them in a section entitled "Derived AVP Data Formats", using the same
2017 format as the definitions below. Each new definition MUST be either
2018 defined or listed with a reference to the RFC that defines the
2019 format.
2021 4.3.1. Common Derived AVP Data Formats
2023 The following are commonly used Derived AVP Data Formats.
2025 Address
2027 The Address format is derived from the OctetString AVP Base
2028 Format. It is a discriminated union, representing, for example a
2029 32-bit (IPv4) [RFC791] or 128-bit (IPv6) [RFC4291] address, most
2030 significant octet first. The first two octets of the Address AVP
2031 represents the AddressType, which contains an Address Family
2032 defined in [IANAADFAM]. The AddressType is used to discriminate
2033 the content and format of the remaining octets.
2035 Time
2037 The Time format is derived from the OctetString AVP Base Format.
2038 The string MUST contain four octets, in the same format as the
2039 first four bytes are in the NTP timestamp format. The NTP
2040 Timestamp format is defined in Chapter 3 of [RFC5905].
2042 This represents the number of seconds since 0h on 1 January 1900
2043 with respect to the Coordinated Universal Time (UTC).
2045 On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
2046 SNTP [RFC5905] describes a procedure to extend the time to 2104.
2047 This procedure MUST be supported by all Diameter nodes.
2049 UTF8String
2051 The UTF8String format is derived from the OctetString AVP Base
2052 Format. This is a human readable string represented using the
2053 ISO/IEC IS 10646-1 character set, encoded as an OctetString using
2054 the UTF-8 transformation format [RFC3629].
2056 Since additional code points are added by amendments to the 10646
2057 standard from time to time, implementations MUST be prepared to
2058 encounter any code point from 0x00000001 to 0x7fffffff. Byte
2059 sequences that do not correspond to the valid encoding of a code
2060 point into UTF-8 charset or are outside this range are prohibited.
2062 The use of control codes SHOULD be avoided. When it is necessary
2063 to represent a new line, the control code sequence CR LF SHOULD be
2064 used.
2066 The use of leading or trailing white space SHOULD be avoided.
2068 For code points not directly supported by user interface hardware
2069 or software, an alternative means of entry and display, such as
2070 hexadecimal, MAY be provided.
2072 For information encoded in 7-bit US-ASCII, the UTF-8 charset is
2073 identical to the US-ASCII charset.
2075 UTF-8 may require multiple bytes to represent a single character /
2076 code point; thus the length of an UTF8String in octets may be
2077 different from the number of characters encoded.
2079 Note that the AVP Length field of an UTF8String is measured in
2080 octets, not characters.
2082 DiameterIdentity
2084 The DiameterIdentity format is derived from the OctetString AVP
2085 Base Format.
2087 DiameterIdentity = FQDN/Realm
2089 DiameterIdentity value is used to uniquely identify either:
2091 * A Diameter node for purposes of duplicate connection and
2092 routing loop detection.
2094 * A Realm to determine whether messages can be satisfied locally,
2095 or whether they must be routed or redirected.
2097 When a DiameterIdentity is used to identify a Diameter node the
2098 contents of the string MUST be the FQDN of the Diameter node. If
2099 multiple Diameter nodes run on the same host, each Diameter node
2100 MUST be assigned a unique DiameterIdentity. If a Diameter node
2101 can be identified by several FQDNs, a single FQDN should be picked
2102 at startup, and used as the only DiameterIdentity for that node,
2103 whatever the connection it is sent on. Note that in this
2104 document, DiameterIdentity is in ASCII form in order to be
2105 compatible with existing DNS infrastructure. See Appendix D for
2106 interactions between the Diameter protocol and Internationalized
2107 Domain Name (IDNs).
2109 DiameterURI
2111 The DiameterURI MUST follow the Uniform Resource Identifiers
2112 (RFC3986) syntax [RFC3986] rules specified below:
2114 "aaa://" FQDN [ port ] [ transport ] [ protocol ]
2116 ; No transport security
2118 "aaas://" FQDN [ port ] [ transport ] [ protocol ]
2120 ; Transport security used
2122 FQDN = < Fully Qualified Domain Name >
2124 port = ":" 1*DIGIT
2126 ; One of the ports used to listen for
2127 ; incoming connections.
2128 ; If absent, the default Diameter port
2129 ; (3868) is assumed if no transport
2130 ; security is used and port (TBD) when
2131 ; transport security (TLS/TCP and DTLS/SCTP)
2132 ; is used.
2134 transport = ";transport=" transport-protocol
2136 ; One of the transports used to listen
2137 ; for incoming connections. If absent,
2138 ; the default protocol is assumed to be TCP.
2139 ; UDP MUST NOT be used when the aaa-protocol
2140 ; field is set to diameter.
2142 transport-protocol = ( "tcp" / "sctp" / "udp" )
2144 protocol = ";protocol=" aaa-protocol
2146 ; If absent, the default AAA protocol
2147 ; is Diameter.
2149 aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
2151 The following are examples of valid Diameter host identities:
2153 aaa://host.example.com;transport=tcp
2154 aaa://host.example.com:6666;transport=tcp
2155 aaa://host.example.com;protocol=diameter
2156 aaa://host.example.com:6666;protocol=diameter
2157 aaa://host.example.com:6666;transport=tcp;protocol=diameter
2158 aaa://host.example.com:1813;transport=udp;protocol=radius
2160 Enumerated
2162 Enumerated is derived from the Integer32 AVP Base Format. The
2163 definition contains a list of valid values and their
2164 interpretation and is described in the Diameter application
2165 introducing the AVP.
2167 IPFilterRule
2169 The IPFilterRule format is derived from the OctetString AVP Base
2170 Format and uses the ASCII charset. The rule syntax is a modified
2171 subset of ipfw(8) from FreeBSD. Packets may be filtered based on
2172 the following information that is associated with it:
2174 Direction (in or out)
2175 Source and destination IP address (possibly masked)
2176 Protocol
2177 Source and destination port (lists or ranges)
2178 TCP flags
2179 IP fragment flag
2180 IP options
2181 ICMP types
2183 Rules for the appropriate direction are evaluated in order, with
2184 the first matched rule terminating the evaluation. Each packet is
2185 evaluated once. If no rule matches, the packet is dropped if the
2186 last rule evaluated was a permit, and passed if the last rule was
2187 a deny.
2189 IPFilterRule filters MUST follow the format:
2191 action dir proto from src to dst [options]
2193 action permit - Allow packets that match the rule.
2194 deny - Drop packets that match the rule.
2196 dir "in" is from the terminal, "out" is to the
2197 terminal.
2199 proto An IP protocol specified by number. The "ip"
2200 keyword means any protocol will match.
2202 src and dst
[ports]
2204 The may be specified as:
2205 ipno An IPv4 or IPv6 number in dotted-
2206 quad or canonical IPv6 form. Only
2207 this exact IP number will match the
2208 rule.
2209 ipno/bits An IP number as above with a mask
2210 width of the form 192.0.2.10/24. In
2211 this case, all IP numbers from
2212 192.0.2.0 to 192.0.2.255 will match.
2213 The bit width MUST be valid for the
2214 IP version and the IP number MUST
2215 NOT have bits set beyond the mask.
2216 For a match to occur, the same IP
2217 version must be present in the
2218 packet that was used in describing
2219 the IP address. To test for a
2220 particular IP version, the bits part
2221 can be set to zero. The keyword
2222 "any" is 0.0.0.0/0 or the IPv6
2223 equivalent. The keyword "assigned"
2224 is the address or set of addresses
2225 assigned to the terminal. For IPv4,
2226 a typical first rule is often "deny
2227 in ip! assigned"
2229 The sense of the match can be inverted by
2230 preceding an address with the not modifier (!),
2231 causing all other addresses to be matched
2232 instead. This does not affect the selection of
2233 port numbers.
2235 With the TCP, UDP and SCTP protocols, optional
2236 ports may be specified as:
2238 {port/port-port}[,ports[,...]]
2240 The '-' notation specifies a range of ports
2241 (including boundaries).
2243 Fragmented packets that have a non-zero offset
2244 (i.e., not the first fragment) will never match
2245 a rule that has one or more port
2246 specifications. See the frag option for
2247 details on matching fragmented packets.
2249 options:
2250 frag Match if the packet is a fragment and this is not
2251 the first fragment of the datagram. frag may not
2252 be used in conjunction with either tcpflags or
2253 TCP/UDP port specifications.
2255 ipoptions spec
2256 Match if the IP header contains the comma
2257 separated list of options specified in spec. The
2258 supported IP options are:
2260 ssrr (strict source route), lsrr (loose source
2261 route), rr (record packet route) and ts
2262 (timestamp). The absence of a particular option
2263 may be denoted with a '!'.
2265 tcpoptions spec
2266 Match if the TCP header contains the comma
2267 separated list of options specified in spec. The
2268 supported TCP options are:
2270 mss (maximum segment size), window (tcp window
2271 advertisement), sack (selective ack), ts (rfc1323
2272 timestamp) and cc (rfc1644 t/tcp connection
2273 count). The absence of a particular option may
2274 be denoted with a '!'.
2276 established
2277 TCP packets only. Match packets that have the RST
2278 or ACK bits set.
2280 setup TCP packets only. Match packets that have the SYN
2281 bit set but no ACK bit.
2283 tcpflags spec
2284 TCP packets only. Match if the TCP header
2285 contains the comma separated list of flags
2286 specified in spec. The supported TCP flags are:
2288 fin, syn, rst, psh, ack and urg. The absence of a
2289 particular flag may be denoted with a '!'. A rule
2290 that contains a tcpflags specification can never
2291 match a fragmented packet that has a non-zero
2292 offset. See the frag option for details on
2293 matching fragmented packets.
2295 icmptypes types
2296 ICMP packets only. Match if the ICMP type is in
2297 the list types. The list may be specified as any
2298 combination of ranges or individual types
2299 separated by commas. Both the numeric values and
2300 the symbolic values listed below can be used. The
2301 supported ICMP types are:
2303 echo reply (0), destination unreachable (3),
2304 source quench (4), redirect (5), echo request
2305 (8), router advertisement (9), router
2306 solicitation (10), time-to-live exceeded (11), IP
2307 header bad (12), timestamp request (13),
2308 timestamp reply (14), information request (15),
2309 information reply (16), address mask request (17)
2310 and address mask reply (18).
2312 There is one kind of packet that the access device MUST always
2313 discard, that is an IP fragment with a fragment offset of one.
2314 This is a valid packet, but it only has one use, to try to
2315 circumvent firewalls.
2317 An access device that is unable to interpret or apply a deny rule
2318 MUST terminate the session. An access device that is unable to
2319 interpret or apply a permit rule MAY apply a more restrictive
2320 rule. An access device MAY apply deny rules of its own before the
2321 supplied rules, for example to protect the access device owner's
2322 infrastructure.
2324 4.4. Grouped AVP Values
2326 The Diameter protocol allows AVP values of type 'Grouped'. This
2327 implies that the Data field is actually a sequence of AVPs. It is
2328 possible to include an AVP with a Grouped type within a Grouped type,
2329 that is, to nest them. AVPs within an AVP of type Grouped have the
2330 same padding requirements as non-Grouped AVPs, as defined in
2331 Section 4.4.
2333 The AVP Code numbering space of all AVPs included in a Grouped AVP is
2334 the same as for non-grouped AVPs. Receivers of a Grouped AVP that
2335 does not have the 'M' (mandatory) bit set and one or more of the
2336 encapsulated AVPs within the group has the 'M' (mandatory) bit set
2337 MAY simply be ignored if the Grouped AVP itself is unrecognized. The
2338 rule applies even if the encapsulated AVP with its 'M' (mandatory)
2339 bit set is further encapsulated within other sub-groups; i.e. other
2340 Grouped AVPs embedded within the Grouped AVP.
2342 Every Grouped AVP defined MUST include a corresponding grammar, using
2343 CCF [RFC5234] (with modifications), as defined below.
2345 grouped-avp-def = "<" name ">" "::=" avp
2347 name-fmt = ALPHA *(ALPHA / DIGIT / "-")
2349 name = name-fmt
2350 ; The name has to be the name of an AVP,
2351 ; defined in the base or extended Diameter
2352 ; specifications.
2354 avp = header *fixed *required *optional
2356 header = "<" "AVP-Header:" avpcode [vendor] ">"
2358 avpcode = 1*DIGIT
2359 ; The AVP Code assigned to the Grouped AVP
2361 vendor = 1*DIGIT
2362 ; The Vendor-ID assigned to the Grouped AVP.
2363 ; If absent, the default value of zero is
2364 ; used.
2366 4.4.1. Example AVP with a Grouped Data type
2368 The Example-AVP (AVP Code 999999) is of type Grouped and is used to
2369 clarify how Grouped AVP values work. The Grouped Data field has the
2370 following CCF grammar:
2372 Example-AVP ::= < AVP Header: 999999 >
2373 { Origin-Host }
2374 1*{ Session-Id }
2375 *[ AVP ]
2377 An Example-AVP with Grouped Data follows.
2379 The Origin-Host AVP (Section 6.3) is required. In this case:
2381 Origin-Host = "example.com".
2383 One or more Session-Ids must follow. Here there are two:
2385 Session-Id =
2386 "grump.example.com:33041;23432;893;0AF3B81"
2388 Session-Id =
2389 "grump.example.com:33054;23561;2358;0AF3B82"
2391 optional AVPs included are
2393 Recovery-Policy =
2394 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2395 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
2396 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
2397 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
2398 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
2399 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
2400 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
2402 Futuristic-Acct-Record =
2403 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
2404 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
2405 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
2406 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
2407 d3427475e49968f841
2409 The data for the optional AVPs is represented in hex since the format
2410 of these AVPs is neither known at the time of definition of the
2411 Example-AVP group, nor (likely) at the time when the example instance
2412 of this AVP is interpreted - except by Diameter implementations which
2413 support the same set of AVPs. The encoding example illustrates how
2414 padding is used and how length fields are calculated. Also note that
2415 AVPs may be present in the Grouped AVP value which the receiver
2416 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record
2417 AVPs). The length of the Example-AVP is the sum of all the length of
2418 the member AVPs including their padding plus the Example-AVP header
2419 size.
2421 This AVP would be encoded as follows:
2423 0 1 2 3 4 5 6 7
2424 +-------+-------+-------+-------+-------+-------+-------+-------+
2425 0 | Example AVP Header (AVP Code = 999999), Length = 496 |
2426 +-------+-------+-------+-------+-------+-------+-------+-------+
2427 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
2428 +-------+-------+-------+-------+-------+-------+-------+-------+
2429 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
2430 +-------+-------+-------+-------+-------+-------+-------+-------+
2431 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
2432 +-------+-------+-------+-------+-------+-------+-------+-------+
2433 32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
2434 +-------+-------+-------+-------+-------+-------+-------+-------+
2435 . . .
2436 +-------+-------+-------+-------+-------+-------+-------+-------+
2437 72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
2438 +-------+-------+-------+-------+-------+-------+-------+-------+
2439 80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
2440 +-------+-------+-------+-------+-------+-------+-------+-------+
2441 88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
2442 +-------+-------+-------+-------+-------+-------+-------+-------+
2443 . . .
2444 +-------+-------+-------+-------+-------+-------+-------+-------+
2445 120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
2446 +-------+-------+-------+-------+-------+-------+-------+-------+
2447 128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
2448 +-------+-------+-------+-------+-------+-------+-------+-------+
2449 136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
2450 +-------+-------+-------+-------+-------+-------+-------+-------+
2451 144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
2452 +-------+-------+-------+-------+-------+-------+-------+-------+
2453 . . .
2454 +-------+-------+-------+-------+-------+-------+-------+-------+
2455 352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
2456 +-------+-------+-------+-------+-------+-------+-------+-------+
2457 328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
2458 +-------+-------+-------+-------+-------+-------+-------+-------+
2459 336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
2460 +-------+-------+-------+-------+-------+-------+-------+-------+
2461 . . .
2462 +-------+-------+-------+-------+-------+-------+-------+-------+
2463 488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
2464 +-------+-------+-------+-------+-------+-------+-------+-------+
2466 4.5. Diameter Base Protocol AVPs
2468 The following table describes the Diameter AVPs defined in the base
2469 protocol, their AVP Code values, types, possible flag values.
2471 Due to space constraints, the short form DiamIdent is used to
2472 represent DiameterIdentity.
2474 +----------+
2475 | AVP Flag |
2476 | rules |
2477 |----+-----|
2478 AVP Section | |MUST |
2479 Attribute Name Code Defined Data Type |MUST| NOT |
2480 -----------------------------------------|----+-----|
2481 Acct- 85 9.8.2 Unsigned32 | M | V |
2482 Interim-Interval | | |
2483 Accounting- 483 9.8.7 Enumerated | M | V |
2484 Realtime-Required | | |
2485 Acct- 50 9.8.5 UTF8String | M | V |
2486 Multi-Session-Id | | |
2487 Accounting- 485 9.8.3 Unsigned32 | M | V |
2488 Record-Number | | |
2489 Accounting- 480 9.8.1 Enumerated | M | V |
2490 Record-Type | | |
2491 Accounting- 44 9.8.4 OctetString| M | V |
2492 Session-Id | | |
2493 Accounting- 287 9.8.6 Unsigned64 | M | V |
2494 Sub-Session-Id | | |
2495 Acct- 259 6.9 Unsigned32 | M | V |
2496 Application-Id | | |
2497 Auth- 258 6.8 Unsigned32 | M | V |
2498 Application-Id | | |
2499 Auth-Request- 274 8.7 Enumerated | M | V |
2500 Type | | |
2501 Authorization- 291 8.9 Unsigned32 | M | V |
2502 Lifetime | | |
2503 Auth-Grace- 276 8.10 Unsigned32 | M | V |
2504 Period | | |
2505 Auth-Session- 277 8.11 Enumerated | M | V |
2506 State | | |
2507 Re-Auth-Request- 285 8.12 Enumerated | M | V |
2508 Type | | |
2509 Class 25 8.20 OctetString| M | V |
2510 Destination-Host 293 6.5 DiamIdent | M | V |
2511 Destination- 283 6.6 DiamIdent | M | V |
2512 Realm | | |
2513 Disconnect-Cause 273 5.4.3 Enumerated | M | V |
2514 Error-Message 281 7.3 UTF8String | | V,M |
2515 Error-Reporting- 294 7.4 DiamIdent | | V,M |
2516 Host | | |
2517 Event-Timestamp 55 8.21 Time | M | V |
2518 Experimental- 297 7.6 Grouped | M | V |
2519 Result | | |
2520 -----------------------------------------|----+-----|
2521 +----------+
2522 | AVP Flag |
2523 | rules |
2524 |----+-----|
2525 AVP Section | |MUST |
2526 Attribute Name Code Defined Data Type |MUST| NOT |
2527 -----------------------------------------|----+-----|
2528 Experimental- 298 7.7 Unsigned32 | M | V |
2529 Result-Code | | |
2530 Failed-AVP 279 7.5 Grouped | M | V |
2531 Firmware- 267 5.3.4 Unsigned32 | | V,M |
2532 Revision | | |
2533 Host-IP-Address 257 5.3.5 Address | M | V |
2534 Inband-Security | M | V |
2535 -Id 299 6.10 Unsigned32 | | |
2536 Multi-Round- 272 8.19 Unsigned32 | M | V |
2537 Time-Out | | |
2538 Origin-Host 264 6.3 DiamIdent | M | V |
2539 Origin-Realm 296 6.4 DiamIdent | M | V |
2540 Origin-State-Id 278 8.16 Unsigned32 | M | V |
2541 Product-Name 269 5.3.7 UTF8String | | V,M |
2542 Proxy-Host 280 6.7.3 DiamIdent | M | V |
2543 Proxy-Info 284 6.7.2 Grouped | M | V |
2544 Proxy-State 33 6.7.4 OctetString| M | V |
2545 Redirect-Host 292 6.12 DiamURI | M | V |
2546 Redirect-Host- 261 6.13 Enumerated | M | V |
2547 Usage | | |
2548 Redirect-Max- 262 6.14 Unsigned32 | M | V |
2549 Cache-Time | | |
2550 Result-Code 268 7.1 Unsigned32 | M | V |
2551 Route-Record 282 6.7.1 DiamIdent | M | V |
2552 Session-Id 263 8.8 UTF8String | M | V |
2553 Session-Timeout 27 8.13 Unsigned32 | M | V |
2554 Session-Binding 270 8.17 Unsigned32 | M | V |
2555 Session-Server- 271 8.18 Enumerated | M | V |
2556 Failover | | |
2557 Supported- 265 5.3.6 Unsigned32 | M | V |
2558 Vendor-Id | | |
2559 Termination- 295 8.15 Enumerated | M | V |
2560 Cause | | |
2561 User-Name 1 8.14 UTF8String | M | V |
2562 Vendor-Id 266 5.3.3 Unsigned32 | M | V |
2563 Vendor-Specific- 260 6.11 Grouped | M | V |
2564 Application-Id | | |
2565 -----------------------------------------|----+-----|
2567 5. Diameter Peers
2569 This section describes how Diameter nodes establish connections and
2570 communicate with peers.
2572 5.1. Peer Connections
2574 Connections between diameter peers are established using their valid
2575 DiameterIdentity. A Diameter node initiating a connection to a peer
2576 MUST know the peers DiameterIdentity. Methods for discovering a
2577 Diameter peer can be found in Section 5.2.
2579 Although a Diameter node may have many possible peers that it is able
2580 to communicate with, it may not be economical to have an established
2581 connection to all of them. At a minimum, a Diameter node SHOULD have
2582 an established connection with two peers per realm, known as the
2583 primary and secondary peers. Of course, a node MAY have additional
2584 connections, if it is deemed necessary. Typically, all messages for
2585 a realm are sent to the primary peer, but in the event that failover
2586 procedures are invoked, any pending requests are sent to the
2587 secondary peer. However, implementations are free to load balance
2588 requests between a set of peers.
2590 Note that a given peer MAY act as a primary for a given realm, while
2591 acting as a secondary for another realm.
2593 When a peer is deemed suspect, which could occur for various reasons,
2594 including not receiving a DWA within an allotted timeframe, no new
2595 requests should be forwarded to the peer, but failover procedures are
2596 invoked. When an active peer is moved to this mode, additional
2597 connections SHOULD be established to ensure that the necessary number
2598 of active connections exists.
2600 There are two ways that a peer is removed from the suspect peer list:
2602 1. The peer is no longer reachable, causing the transport connection
2603 to be shutdown. The peer is moved to the closed state.
2605 2. Three watchdog messages are exchanged with accepted round trip
2606 times, and the connection to the peer is considered stabilized.
2608 In the event the peer being removed is either the primary or
2609 secondary, an alternate peer SHOULD replace the deleted peer, and
2610 assume the role of either primary or secondary.
2612 5.2. Diameter Peer Discovery
2614 Allowing for dynamic Diameter agent discovery will make it possible
2615 for simpler and more robust deployment of Diameter services. In
2616 order to promote interoperable implementations of Diameter peer
2617 discovery, the following mechanisms are described. These are based
2618 on existing IETF standards. The first option (manual configuration)
2619 MUST be supported by all Diameter nodes, while the latter option
2620 (DNS) MAY be supported.
2622 There are two cases where Diameter peer discovery may be performed.
2623 The first is when a Diameter client needs to discover a first-hop
2624 Diameter agent. The second case is when a Diameter agent needs to
2625 discover another agent - for further handling of a Diameter
2626 operation. In both cases, the following 'search order' is
2627 recommended:
2629 1. The Diameter implementation consults its list of static
2630 (manually) configured Diameter agent locations. These will be
2631 used if they exist and respond.
2633 2. The Diameter implementation performs a NAPTR query for a server
2634 in a particular realm. The Diameter implementation has to know
2635 in advance which realm to look for a Diameter agent. This could
2636 be deduced, for example, from the 'realm' in a NAI that a
2637 Diameter implementation needed to perform a Diameter operation
2638 on.
2640 The NAPTR usage in Diameter follows the S-NAPTR DDDS application
2641 [RFC3958] in which the SERVICE field includes tags for the
2642 desired application and supported application protocol. The
2643 application service tag for a Diameter application is 'aaa' and
2644 the supported application protocol tags are 'diameter.tcp',
2645 'diameter.sctp', 'diameter.dtls' or 'diameter.tls.tcp' [RFC6408].
2647 The client can follow the resolution process defined by the
2648 S-NAPTR DDDS [RFC3958] application to find a matching SRV, A or
2649 AAAA record of a suitable peer. The domain suffixes in the NAPTR
2650 replacement field SHOULD match the domain of the original query.
2651 An example can be found in Appendix B.
2653 3. If no NAPTR records are found, the requester directly queries for
2654 one of the following SRV records: for Diameter over TCP, use
2655 "_diameter._tcp.realm"; for Diameter over TLS, use
2656 "_diameters._tcp.realm"; for Diameter over SCTP, use
2657 "_diameter._sctp.realm"; for Diameter over DTLS, use
2658 "_diameters._sctp.realm". If SRV records are found then the
2659 requester can perform address record query (A RR's and/or AAAA
2660 RR's) for the target hostname specified in the SRV records
2661 following the rules given in Gulbrandsen, et al. [RFC2782]. If
2662 no SRV records are found, the requester gives up.
2664 If the server is using a site certificate, the domain name in the
2665 NAPTR query and the domain name in the replacement field MUST both be
2666 valid based on the site certificate handed out by the server in the
2667 TLS/TCP and DTLS/SCTP or IKE exchange. Similarly, the domain name in
2668 the SRV query and the domain name in the target in the SRV record
2669 MUST both be valid based on the same site certificate. Otherwise, an
2670 attacker could modify the DNS records to contain replacement values
2671 in a different domain, and the client could not validate that this
2672 was the desired behavior, or the result of an attack.
2674 Also, the Diameter Peer MUST check to make sure that the discovered
2675 peers are authorized to act in its role. Authentication via IKE or
2676 TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not
2677 sufficient to conclude this. For example, a web server may have
2678 obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs
2679 may be included in the DNS, but this does not imply that it is
2680 authorized to act as a Diameter Server.
2682 Authorization can be achieved for example, by configuration of a
2683 Diameter Server Certification Authority (CA). The Server CA issues a
2684 certificate to the Diameter Server, which includes an Object
2685 Identifier (OID) to indicate the subject is a Diameter Server in the
2686 Extended Key Usage extension [RFC5280]. This certificate is then
2687 used during TLS/TCP, DTLS/SCTP, or IKE security negotiation. Note,
2688 however, that at the time of writing no Diameter Server Certification
2689 Authorities exist.
2691 A dynamically discovered peer causes an entry in the Peer Table (see
2692 Section 2.6) to be created. Note that entries created via DNS MUST
2693 expire (or be refreshed) within the DNS TTL. If a peer is discovered
2694 outside of the local realm, a routing table entry (see Section 2.7)
2695 for the peer's realm is created. The routing table entry's
2696 expiration MUST match the peer's expiration value.
2698 5.3. Capabilities Exchange
2700 When two Diameter peers establish a transport connection, they MUST
2701 exchange the Capabilities Exchange messages, as specified in the peer
2702 state machine (see Section 5.6). This message allows the discovery
2703 of a peer's identity and its capabilities (protocol version number,
2704 the identifiers of supported Diameter applications, security
2705 mechanisms, etc.)
2706 The receiver only issues commands to its peers that have advertised
2707 support for the Diameter application that defines the command. A
2708 Diameter node MUST cache the supported Application Ids in order to
2709 ensure that unrecognized commands and/or AVPs are not unnecessarily
2710 sent to a peer.
2712 A receiver of a Capabilities-Exchange-Req (CER) message that does not
2713 have any applications in common with the sender MUST return a
2714 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
2715 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
2716 layer connection. Note that receiving a CER or CEA from a peer
2717 advertising itself as a Relay (see Section 2.4) MUST be interpreted
2718 as having common applications with the peer.
2720 The receiver of the Capabilities-Exchange-Request (CER) MUST
2721 determine common applications by computing the intersection of its
2722 own set of supported Application Id against all of the application
2723 identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-
2724 Specific-Application-Id) present in the CER. The value of the
2725 Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
2726 during computation. The sender of the Capabilities-Exchange-Answer
2727 (CEA) SHOULD include all of its supported applications as a hint to
2728 the receiver regarding all of its application capabilities.
2730 Diameter implementations SHOULD first attempt to establish a TLS/TCP
2731 and DTLS/SCTP connection prior to the CER/CEA exchange. This
2732 protects the capabilities information of both peers. To support
2733 older Diameter implementations that do not fully conform to this
2734 document, the transport security MAY still be negotiated via Inband-
2735 Security AVP. In this case, the receiver of a Capabilities-Exchange-
2736 Req (CER) message that does not have any security mechanisms in
2737 common with the sender MUST return a Capabilities-Exchange-Answer
2738 (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY,
2739 and SHOULD disconnect the transport layer connection.
2741 CERs received from unknown peers MAY be silently discarded, or a CEA
2742 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
2743 In both cases, the transport connection is closed. If the local
2744 policy permits receiving CERs from unknown hosts, a successful CEA
2745 MAY be returned. If a CER from an unknown peer is answered with a
2746 successful CEA, the lifetime of the peer entry is equal to the
2747 lifetime of the transport connection. In case of a transport
2748 failure, all the pending transactions destined to the unknown peer
2749 can be discarded.
2751 The CER and CEA messages MUST NOT be proxied, redirected or relayed.
2753 Since the CER/CEA messages cannot be proxied, it is still possible
2754 that an upstream agent receives a message for which it has no
2755 available peers to handle the application that corresponds to the
2756 Command-Code. In such instances, the 'E' bit is set in the answer
2757 message (Section 7) with the Result-Code AVP set to
2758 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action
2759 (e.g., re-routing request to an alternate peer).
2761 With the exception of the Capabilities-Exchange-Request message, a
2762 message of type Request that includes the Auth-Application-Id or
2763 Acct-Application-Id AVPs, or a message with an application-specific
2764 command code, MAY only be forwarded to a host that has explicitly
2765 advertised support for the application (or has advertised the Relay
2766 Application Id).
2768 5.3.1. Capabilities-Exchange-Request
2770 The Capabilities-Exchange-Request (CER), indicated by the Command-
2771 Code set to 257 and the Command Flags' 'R' bit set, is sent to
2772 exchange local capabilities. Upon detection of a transport failure,
2773 this message MUST NOT be sent to an alternate peer.
2775 When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
2776 which allow for connections to span multiple interfaces and multiple
2777 IP addresses, the Capabilities-Exchange-Request message MUST contain
2778 one Host-IP-Address AVP for each potential IP address that MAY be
2779 locally used when transmitting Diameter messages.
2781 Message Format
2783 ::= < Diameter Header: 257, REQ >
2784 { Origin-Host }
2785 { Origin-Realm }
2786 1* { Host-IP-Address }
2787 { Vendor-Id }
2788 { Product-Name }
2789 [ Origin-State-Id ]
2790 * [ Supported-Vendor-Id ]
2791 * [ Auth-Application-Id ]
2792 * [ Inband-Security-Id ]
2793 * [ Acct-Application-Id ]
2794 * [ Vendor-Specific-Application-Id ]
2795 [ Firmware-Revision ]
2796 * [ AVP ]
2798 5.3.2. Capabilities-Exchange-Answer
2800 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code
2801 set to 257 and the Command Flags' 'R' bit cleared, is sent in
2802 response to a CER message.
2804 When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
2805 which allow connections to span multiple interfaces, hence, multiple
2806 IP addresses, the Capabilities-Exchange-Answer message MUST contain
2807 one Host-IP-Address AVP for each potential IP address that MAY be
2808 locally used when transmitting Diameter messages.
2810 Message Format
2812 ::= < Diameter Header: 257 >
2813 { Result-Code }
2814 { Origin-Host }
2815 { Origin-Realm }
2816 1* { Host-IP-Address }
2817 { Vendor-Id }
2818 { Product-Name }
2819 [ Origin-State-Id ]
2820 [ Error-Message ]
2821 [ Failed-AVP ]
2822 * [ Supported-Vendor-Id ]
2823 * [ Auth-Application-Id ]
2824 * [ Inband-Security-Id ]
2825 * [ Acct-Application-Id ]
2826 * [ Vendor-Specific-Application-Id ]
2827 [ Firmware-Revision ]
2828 * [ AVP ]
2830 5.3.3. Vendor-Id AVP
2832 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
2833 the IANA "SMI Network Management Private Enterprise Codes"
2834 [ENTERPRISE] value assigned to the Diameter Software vendor. It is
2835 envisioned that the combination of the Vendor-Id, Product-Name
2836 (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs may
2837 provide useful debugging information.
2839 A Vendor-Id value of zero in the CER or CEA messages is reserved and
2840 indicates that this field is ignored.
2842 5.3.4. Firmware-Revision AVP
2844 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
2845 used to inform a Diameter peer of the firmware revision of the
2846 issuing device.
2848 For devices that do not have a firmware revision (general purpose
2849 computers running Diameter software modules, for instance), the
2850 revision of the Diameter software module may be reported instead.
2852 5.3.5. Host-IP-Address AVP
2854 The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
2855 to inform a Diameter peer of the sender's IP address. All source
2856 addresses that a Diameter node expects to use with SCTP [RFC4960] or
2857 DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
2858 including a Host-IP-Address AVP for each address.
2860 5.3.6. Supported-Vendor-Id AVP
2862 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
2863 contains the IANA "SMI Network Management Private Enterprise Codes"
2864 [ENTERPRISE] value assigned to a vendor other than the device vendor
2865 but including the application vendor. This is used in the CER and
2866 CEA messages in order to inform the peer that the sender supports (a
2867 subset of) the vendor-specific AVPs defined by the vendor identified
2868 in this AVP. The value of this AVP MUST NOT be set to zero.
2869 Multiple instances of this AVP containing the same value SHOULD NOT
2870 be sent.
2872 5.3.7. Product-Name AVP
2874 The Product-Name AVP (AVP Code 269) is of type UTF8String, and
2875 contains the vendor assigned name for the product. The Product-Name
2876 AVP SHOULD remain constant across firmware revisions for the same
2877 product.
2879 5.4. Disconnecting Peer connections
2881 When a Diameter node disconnects one of its transport connections,
2882 its peer cannot know the reason for the disconnect, and will most
2883 likely assume that a connectivity problem occurred, or that the peer
2884 has rebooted. In these cases, the peer may periodically attempt to
2885 reconnect, as stated in Section 2.1. In the event that the
2886 disconnect was a result of either a shortage of internal resources,
2887 or simply that the node in question has no intentions of forwarding
2888 any Diameter messages to the peer in the foreseeable future, a
2889 periodic connection request would not be welcomed. The
2890 Disconnection-Reason AVP contains the reason the Diameter node issued
2891 the Disconnect-Peer-Request message.
2893 The Disconnect-Peer-Request message is used by a Diameter node to
2894 inform its peer of its intent to disconnect the transport layer, and
2895 that the peer shouldn't reconnect unless it has a valid reason to do
2896 so (e.g., message to be forwarded). Upon receipt of the message, the
2897 Disconnect-Peer-Answer is returned, which SHOULD contain an error if
2898 messages have recently been forwarded, and are likely in flight,
2899 which would otherwise cause a race condition.
2901 The receiver of the Disconnect-Peer-Answer initiates the transport
2902 disconnect. The sender of the Disconnect-Peer-Answer should be able
2903 to detect the transport closure and cleanup the connection.
2905 5.4.1. Disconnect-Peer-Request
2907 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set
2908 to 282 and the Command Flags' 'R' bit set, is sent to a peer to
2909 inform its intentions to shutdown the transport connection. Upon
2910 detection of a transport failure, this message MUST NOT be sent to an
2911 alternate peer.
2913 Message Format
2915 ::= < Diameter Header: 282, REQ >
2916 { Origin-Host }
2917 { Origin-Realm }
2918 { Disconnect-Cause }
2919 * [ AVP ]
2921 5.4.2. Disconnect-Peer-Answer
2923 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set
2924 to 282 and the Command Flags' 'R' bit cleared, is sent as a response
2925 to the Disconnect-Peer-Request message. Upon receipt of this
2926 message, the transport connection is shutdown.
2928 Message Format
2930 ::= < Diameter Header: 282 >
2931 { Result-Code }
2932 { Origin-Host }
2933 { Origin-Realm }
2934 [ Error-Message ]
2935 [ Failed-AVP ]
2936 * [ AVP ]
2938 5.4.3. Disconnect-Cause AVP
2940 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
2941 Diameter node MUST include this AVP in the Disconnect-Peer-Request
2942 message to inform the peer of the reason for its intention to
2943 shutdown the transport connection. The following values are
2944 supported:
2946 REBOOTING 0
2947 A scheduled reboot is imminent. Receiver of DPR with above
2948 result code MAY attempt reconnection.
2950 BUSY 1
2951 The peer's internal resources are constrained, and it has
2952 determined that the transport connection needs to be closed.
2953 Receiver of DPR with above result code SHOULD NOT attempt
2954 reconnection.
2956 DO_NOT_WANT_TO_TALK_TO_YOU 2
2957 The peer has determined that it does not see a need for the
2958 transport connection to exist, since it does not expect any
2959 messages to be exchanged in the near future. Receiver of DPR
2960 with above result code SHOULD NOT attempt reconnection.
2962 5.5. Transport Failure Detection
2964 Given the nature of the Diameter protocol, it is recommended that
2965 transport failures be detected as soon as possible. Detecting such
2966 failures will minimize the occurrence of messages sent to unavailable
2967 agents, resulting in unnecessary delays, and will provide better
2968 failover performance. The Device-Watchdog-Request and Device-
2969 Watchdog-Answer messages, defined in this section, are used to pro-
2970 actively detect transport failures.
2972 5.5.1. Device-Watchdog-Request
2974 The Device-Watchdog-Request (DWR), indicated by the Command-Code set
2975 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
2976 traffic has been exchanged between two peers (see Section 5.5.3).
2977 Upon detection of a transport failure, this message MUST NOT be sent
2978 to an alternate peer.
2980 Message Format
2982 ::= < Diameter Header: 280, REQ >
2983 { Origin-Host }
2984 { Origin-Realm }
2985 [ Origin-State-Id ]
2987 * [ AVP ]
2989 5.5.2. Device-Watchdog-Answer
2991 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
2992 to 280 and the Command Flags' 'R' bit cleared, is sent as a response
2993 to the Device-Watchdog-Request message.
2995 Message Format
2997 ::= < Diameter Header: 280 >
2998 { Result-Code }
2999 { Origin-Host }
3000 { Origin-Realm }
3001 [ Error-Message ]
3002 [ Failed-AVP ]
3003 [ Origin-State-Id ]
3004 * [ AVP ]
3006 5.5.3. Transport Failure Algorithm
3008 The transport failure algorithm is defined in [RFC3539]. All
3009 Diameter implementations MUST support the algorithm defined in the
3010 specification in order to be compliant to the Diameter base protocol.
3012 5.5.4. Failover and Failback Procedures
3014 In the event that a transport failure is detected with a peer, it is
3015 necessary for all pending request messages to be forwarded to an
3016 alternate agent, if possible. This is commonly referred to as
3017 failover.
3019 In order for a Diameter node to perform failover procedures, it is
3020 necessary for the node to maintain a pending message queue for a
3021 given peer. When an answer message is received, the corresponding
3022 request is removed from the queue. The Hop-by-Hop Identifier field
3023 is used to match the answer with the queued request.
3025 When a transport failure is detected, if possible all messages in the
3026 queue are sent to an alternate agent with the T flag set. On booting
3027 a Diameter client or agent, the T flag is also set on any records
3028 still remaining to be transmitted in non-volatile storage. An
3029 example of a case where it is not possible to forward the message to
3030 an alternate server is when the message has a fixed destination, and
3031 the unavailable peer is the message's final destination (see
3032 Destination-Host AVP). Such an error requires that the agent return
3033 an answer message with the 'E' bit set and the Result-Code AVP set to
3034 DIAMETER_UNABLE_TO_DELIVER.
3036 It is important to note that multiple identical requests or answers
3037 MAY be received as a result of a failover. The End-to-End Identifier
3038 field in the Diameter header along with the Origin-Host AVP MUST be
3039 used to identify duplicate messages.
3041 As described in Section 2.1, a connection request should be
3042 periodically attempted with the failed peer in order to re-establish
3043 the transport connection. Once a connection has been successfully
3044 established, messages can once again be forwarded to the peer. This
3045 is commonly referred to as failback.
3047 5.6. Peer State Machine
3049 This section contains a finite state machine that MUST be observed by
3050 all Diameter implementations. Each Diameter node MUST follow the
3051 state machine described below when communicating with each peer.
3052 Multiple actions are separated by commas, and may continue on
3053 succeeding lines, as space requires. Similarly, state and next state
3054 may also span multiple lines, as space requires.
3056 This state machine is closely coupled with the state machine
3057 described in [RFC3539], which is used to open, close, failover,
3058 probe, and reopen transport connections. Note in particular that
3059 [RFC3539] requires the use of watchdog messages to probe connections.
3060 For Diameter, DWR and DWA messages are to be used.
3062 I- is used to represent the initiator (connecting) connection, while
3063 the R- is used to represent the responder (listening) connection.
3064 The lack of a prefix indicates that the event or action is the same
3065 regardless of the connection on which the event occurred.
3067 The stable states that a state machine may be in are Closed, I-Open
3068 and R-Open; all other states are intermediate. Note that I-Open and
3069 R-Open are equivalent except for whether the initiator or responder
3070 transport connection is used for communication.
3072 A CER message is always sent on the initiating connection immediately
3073 after the connection request is successfully completed. In the case
3074 of an election, one of the two connections will shut down. The
3075 responder connection will survive if the Origin-Host of the local
3076 Diameter entity is higher than that of the peer; the initiator
3077 connection will survive if the peer's Origin-Host is higher. All
3078 subsequent messages are sent on the surviving connection. Note that
3079 the results of an election on one peer are guaranteed to be the
3080 inverse of the results on the other.
3082 For TLS/TCP and DTLS/SCTP usage, TLS/TCP and DTLS/SCTP handshake
3083 SHOULD begin when both ends are in the closed state prior to any
3084 Diameter message exchanges. The TLS/TCP and DTLS/SCTP connection
3085 SHOULD be established before sending any CER or CEA message to secure
3086 and protect the capabilities information of both peers. The TLS/TCP
3087 and DTLS/SCTP connection SHOULD be disconnected when the state
3088 machine moves to the closed state. When connecting to responders
3089 that do not conform to this document (i.e. older Diameter
3090 implementations that are not prepared to received TLS/TCP and DTLS/
3091 SCTP connections in the closed state), the initial TLS/TCP and DTLS/
3092 SCTP connection attempt will fail. The initiator MAY then attempt to
3093 connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP
3094 handshake when both ends are in the open state. If the handshake is
3095 successful, all further messages will be sent via TLS/TCP and DTLS/
3096 SCTP. If the handshake fails, both ends move to the closed state.
3098 The state machine constrains only the behavior of a Diameter
3099 implementation as seen by Diameter peers through events on the wire.
3101 Any implementation that produces equivalent results is considered
3102 compliant.
3104 state event action next state
3105 -----------------------------------------------------------------
3106 Closed Start I-Snd-Conn-Req Wait-Conn-Ack
3107 R-Conn-CER R-Accept, R-Open
3108 Process-CER,
3109 R-Snd-CEA
3111 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA
3112 I-Rcv-Conn-Nack Cleanup Closed
3113 R-Conn-CER R-Accept, Wait-Conn-Ack/
3114 Process-CER Elect
3115 Timeout Error Closed
3117 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
3118 R-Conn-CER R-Accept, Wait-Returns
3119 Process-CER,
3120 Elect
3121 I-Peer-Disc I-Disc Closed
3122 I-Rcv-Non-CEA Error Closed
3123 Timeout Error Closed
3125 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns
3126 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open
3127 R-Peer-Disc R-Disc Wait-Conn-Ack
3128 R-Conn-CER R-Reject Wait-Conn-Ack/
3129 Elect
3130 Timeout Error Closed
3132 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
3133 I-Peer-Disc I-Disc, R-Open
3134 R-Snd-CEA
3135 I-Rcv-CEA R-Disc I-Open
3136 R-Peer-Disc R-Disc Wait-I-CEA
3137 R-Conn-CER R-Reject Wait-Returns
3138 Timeout Error Closed
3140 R-Open Send-Message R-Snd-Message R-Open
3141 R-Rcv-Message Process R-Open
3142 R-Rcv-DWR Process-DWR, R-Open
3143 R-Snd-DWA
3144 R-Rcv-DWA Process-DWA R-Open
3145 R-Conn-CER R-Reject R-Open
3146 Stop R-Snd-DPR Closing
3147 R-Rcv-DPR R-Snd-DPA, Closed
3148 R-Disc
3149 R-Peer-Disc R-Disc Closed
3151 I-Open Send-Message I-Snd-Message I-Open
3152 I-Rcv-Message Process I-Open
3153 I-Rcv-DWR Process-DWR, I-Open
3154 I-Snd-DWA
3155 I-Rcv-DWA Process-DWA I-Open
3156 R-Conn-CER R-Reject I-Open
3157 Stop I-Snd-DPR Closing
3158 I-Rcv-DPR I-Snd-DPA, Closed
3159 I-Disc
3160 I-Peer-Disc I-Disc Closed
3162 Closing I-Rcv-DPA I-Disc Closed
3163 R-Rcv-DPA R-Disc Closed
3164 Timeout Error Closed
3165 I-Peer-Disc I-Disc Closed
3166 R-Peer-Disc R-Disc Closed
3168 5.6.1. Incoming connections
3170 When a connection request is received from a Diameter peer, it is
3171 not, in the general case, possible to know the identity of that peer
3172 until a CER is received from it. This is because host and port
3173 determine the identity of a Diameter peer; and the source port of an
3174 incoming connection is arbitrary. Upon receipt of CER, the identity
3175 of the connecting peer can be uniquely determined from Origin-Host.
3177 For this reason, a Diameter peer must employ logic separate from the
3178 state machine to receive connection requests, accept them, and await
3179 CER. Once CER arrives on a new connection, the Origin-Host that
3180 identifies the peer is used to locate the state machine associated
3181 with that peer, and the new connection and CER are passed to the
3182 state machine as an R-Conn-CER event.
3184 The logic that handles incoming connections SHOULD close and discard
3185 the connection if any message other than CER arrives, or if an
3186 implementation-defined timeout occurs prior to receipt of CER.
3188 Because handling of incoming connections up to and including receipt
3189 of CER requires logic, separate from that of any individual state
3190 machine associated with a particular peer, it is described separately
3191 in this section rather than in the state machine above.
3193 5.6.2. Events
3195 Transitions and actions in the automaton are caused by events. In
3196 this section, we will ignore the -I and -R prefix, since the actual
3197 event would be identical, but would occur on one of two possible
3198 connections.
3200 Start The Diameter application has signaled that a
3201 connection should be initiated with the peer.
3203 R-Conn-CER An acknowledgement is received stating that the
3204 transport connection has been established, and the
3205 associated CER has arrived.
3207 Rcv-Conn-Ack A positive acknowledgement is received confirming that
3208 the transport connection is established.
3210 Rcv-Conn-Nack A negative acknowledgement was received stating that
3211 the transport connection was not established.
3213 Timeout An application-defined timer has expired while waiting
3214 for some event.
3216 Rcv-CER A CER message from the peer was received.
3218 Rcv-CEA A CEA message from the peer was received.
3220 Rcv-Non-CEA A message other than CEA from the peer was received.
3222 Peer-Disc A disconnection indication from the peer was received.
3224 Rcv-DPR A DPR message from the peer was received.
3226 Rcv-DPA A DPA message from the peer was received.
3228 Win-Election An election was held, and the local node was the
3229 winner.
3231 Send-Message A message is to be sent.
3233 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR or DWA
3234 was received.
3236 Stop The Diameter application has signaled that a
3237 connection should be terminated (e.g., on system
3238 shutdown).
3240 5.6.3. Actions
3242 Actions in the automaton are caused by events and typically indicate
3243 the transmission of packets and/or an action to be taken on the
3244 connection. In this section we will ignore the I- and R-prefix,
3245 since the actual action would be identical, but would occur on one of
3246 two possible connections.
3248 Snd-Conn-Req A transport connection is initiated with the peer.
3250 Accept The incoming connection associated with the R-Conn-CER
3251 is accepted as the responder connection.
3253 Reject The incoming connection associated with the R-Conn-CER
3254 is disconnected.
3256 Process-CER The CER associated with the R-Conn-CER is processed.
3257 Snd-CER A CER message is sent to the peer.
3259 Snd-CEA A CEA message is sent to the peer.
3261 Cleanup If necessary, the connection is shutdown, and any
3262 local resources are freed.
3264 Error The transport layer connection is disconnected,
3265 either politely or abortively, in response to
3266 an error condition. Local resources are freed.
3268 Process-CEA A received CEA is processed.
3270 Snd-DPR A DPR message is sent to the peer.
3272 Snd-DPA A DPA message is sent to the peer.
3274 Disc The transport layer connection is disconnected,
3275 and local resources are freed.
3277 Elect An election occurs (see Section 5.6.4 for more
3278 information).
3280 Snd-Message A message is sent.
3282 Snd-DWR A DWR message is sent.
3284 Snd-DWA A DWA message is sent.
3286 Process-DWR The DWR message is serviced.
3288 Process-DWA The DWA message is serviced.
3290 Process A message is serviced.
3292 5.6.4. The Election Process
3294 The election is performed on the responder. The responder compares
3295 the Origin-Host received in the CER with its own Origin-Host as two
3296 streams of octets. If the local Origin-Host lexicographically
3297 succeeds the received Origin-Host a Win-Election event is issued
3298 locally. Diameter identities are in ASCII form therefore the lexical
3299 comparison is consistent with DNS case insensitivity where octets
3300 that fall in the ASCII range 'a' through 'z' MUST compare equally to
3301 their upper-case counterparts between 'A' and 'Z'. See Appendix D
3302 for interactions between the Diameter protocol and Internationalized
3303 Domain Name (IDNs).
3305 The winner of the election MUST close the connection it initiated.
3306 Historically, maintaining the responder side of a connection was more
3307 efficient than maintaining the initiator side. However, current
3308 practices makes this distinction irrelevant.
3310 6. Diameter Message Processing
3312 This section describes how Diameter requests and answers are created
3313 and processed.
3315 6.1. Diameter Request Routing Overview
3317 A request is sent towards its final destination using a combination
3318 of the Destination-Realm and Destination-Host AVPs, in one of these
3319 three combinations:
3321 o a request that is not able to be proxied (such as CER) MUST NOT
3322 contain either Destination-Realm or Destination-Host AVPs.
3324 o a request that needs to be sent to a home server serving a
3325 specific realm, but not to a specific server (such as the first
3326 request of a series of round-trips), MUST contain a Destination-
3327 Realm AVP, but MUST NOT contain a Destination-Host AVP. For
3328 Diameter clients, the value of the Destination-Realm AVP MAY be
3329 extracted from the User-Name AVP, or other methods.
3331 o otherwise, a request that needs to be sent to a specific home
3332 server among those serving a given realm, MUST contain both the
3333 Destination-Realm and Destination-Host AVPs.
3335 The Destination-Host AVP is used as described above when the
3336 destination of the request is fixed, which includes:
3338 o Authentication requests that span multiple round trips
3340 o A Diameter message that uses a security mechanism that makes use
3341 of a pre-established session key shared between the source and the
3342 final destination of the message.
3344 o Server initiated messages that MUST be received by a specific
3345 Diameter client (e.g., access device), such as the Abort-Session-
3346 Request message, which is used to request that a particular user's
3347 session be terminated.
3349 Note that an agent can forward a request to a host described in the
3350 Destination-Host AVP only if the host in question is included in its
3351 peer table (see Section 2.6). Otherwise, the request is routed based
3352 on the Destination-Realm only (see Section 6.1.6).
3354 When a message is received, the message is processed in the following
3355 order:
3357 o If the message is destined for the local host, the procedures
3358 listed in Section 6.1.4 are followed.
3360 o If the message is intended for a Diameter peer with whom the local
3361 host is able to directly communicate, the procedures listed in
3362 Section 6.1.5 are followed. This is known as Request Forwarding.
3364 o The procedures listed in Section 6.1.6 are followed, which is
3365 known as Request Routing.
3367 o If none of the above is successful, an answer is returned with the
3368 Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the 'E' bit
3369 set.
3371 For routing of Diameter messages to work within an administrative
3372 domain, all Diameter nodes within the realm MUST be peers.
3374 The overview contained in this section (6.1) is intended to provide
3375 general guidelines to Diameter developers. Implementations are free
3376 to use different methods than the ones described here as long as they
3377 conform to the requirements specified in Sections 6.1.1 through
3378 6.1.9. See Section 7 for more detail on error handling.
3380 6.1.1. Originating a Request
3382 When creating a request, in addition to any other procedures
3383 described in the application definition for that specific request,
3384 the following procedures MUST be followed:
3386 o the Command-Code is set to the appropriate value
3388 o the 'R' bit is set
3390 o the End-to-End Identifier is set to a locally unique value
3392 o the Origin-Host and Origin-Realm AVPs MUST be set to the
3393 appropriate values, used to identify the source of the message
3395 o the Destination-Host and Destination-Realm AVPs MUST be set to the
3396 appropriate values as described in Section 6.1.
3398 6.1.2. Sending a Request
3400 When sending a request, originated either locally, or as the result
3401 of a forwarding or routing operation, the following procedures SHOULD
3402 be followed:
3404 o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
3406 o The message SHOULD be saved in the list of pending requests.
3408 Other actions to perform on the message based on the particular role
3409 the agent is playing are described in the following sections.
3411 6.1.3. Receiving Requests
3413 A relay or proxy agent MUST check for forwarding loops when receiving
3414 requests. A loop is detected if the server finds its own identity in
3415 a Route-Record AVP. When such an event occurs, the agent MUST answer
3416 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
3418 6.1.4. Processing Local Requests
3420 A request is known to be for local consumption when one of the
3421 following conditions occur:
3423 o The Destination-Host AVP contains the local host's identity,
3425 o The Destination-Host AVP is not present, the Destination-Realm AVP
3426 contains a realm the server is configured to process locally, and
3427 the Diameter application is locally supported, or
3429 o Both the Destination-Host and the Destination-Realm are not
3430 present.
3432 When a request is locally processed, the rules in Section 6.2 should
3433 be used to generate the corresponding answer.
3435 6.1.5. Request Forwarding
3437 Request forwarding is done using the Diameter Peer Table. The
3438 Diameter peer table contains all of the peers that the local node is
3439 able to directly communicate with.
3441 When a request is received, and the host encoded in the Destination-
3442 Host AVP is one that is present in the peer table, the message SHOULD
3443 be forwarded to the peer.
3445 6.1.6. Request Routing
3447 Diameter request message routing is done via realms and application
3448 identifiers. A Diameter message that may be forwarded by Diameter
3449 agents (proxies, redirect or relay agents) MUST include the target
3450 realm in the Destination-Realm AVP. Request routing SHOULD rely on
3451 the Destination-Realm AVP and the Application Id present in the
3452 request message header to aid in the routing decision. The realm MAY
3453 be retrieved from the User-Name AVP, which is in the form of a
3454 Network Access Identifier (NAI). The realm portion of the NAI is
3455 inserted in the Destination-Realm AVP.
3457 Diameter agents MAY have a list of locally supported realms and
3458 applications, and MAY have a list of externally supported realms and
3459 applications. When a request is received that includes a realm
3460 and/or application that is not locally supported, the message is
3461 routed to the peer configured in the Routing Table (see Section 2.7).
3463 Realm names and Application Ids are the minimum supported routing
3464 criteria, additional information may be needed to support redirect
3465 semantics.
3467 6.1.7. Predictive Loop Avoidance
3469 Before forwarding or routing a request Diameter agents, in addition
3470 to performing the processing described in Section 6.1.3, SHOULD check
3471 for the presence of candidate route's peer identity in any of the
3472 Route-Record AVPs. In an event of the agent detecting the presence
3473 of a candidate route's peer identity in a Route-Record AVP, the agent
3474 MUST ignore such route for the Diameter request message and attempt
3475 alternate routes if any. In case all the candidate routes are
3476 eliminated by the above criteria, the agent SHOULD return
3477 DIAMETER_UNABLE_TO_DELIVER message.
3479 6.1.8. Redirecting Requests
3481 When a redirect agent receives a request whose routing entry is set
3482 to REDIRECT, it MUST reply with an answer message with the 'E' bit
3483 set, while maintaining the Hop-by-Hop Identifier in the header, and
3484 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of
3485 the servers associated with the routing entry are added in separate
3486 Redirect-Host AVP.
3488 +------------------+
3489 | Diameter |
3490 | Redirect Agent |
3491 +------------------+
3492 ^ | 2. command + 'E' bit
3493 1. Request | | Result-Code =
3494 joe@example.com | | DIAMETER_REDIRECT_INDICATION +
3495 | | Redirect-Host AVP(s)
3496 | v
3497 +-------------+ 3. Request +-------------+
3498 | example.com |------------->| example.net |
3499 | Relay | | Diameter |
3500 | Agent |<-------------| Server |
3501 +-------------+ 4. Answer +-------------+
3503 Figure 5: Diameter Redirect Agent
3505 The receiver of an answer message with the 'E' bit set and the
3506 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the Hop-by-
3507 Hop Identifier in the Diameter header to identify the request in the
3508 pending message queue (see Section 5.5.4) that is to be redirected.
3509 If no transport connection exists with the new agent, one is created,
3510 and the request is sent directly to it.
3512 Multiple Redirect-Host AVPs are allowed. The receiver of the answer
3513 message with the 'E' bit set selects exactly one of these hosts as
3514 the destination of the redirected message.
3516 When the Redirect-Host-Usage AVP included in the answer message has a
3517 non-zero value, a route entry for the redirect indications is created
3518 and cached by the receiver. The redirect usage for such route entry
3519 is set by the value of Redirect-Host-Usage AVP and the lifetime of
3520 the cached route entry is set by Redirect-Max-Cache-Time AVP value.
3522 It is possible that multiple redirect indications can create multiple
3523 cached route entries differing only in their redirect usage and the
3524 peer to forward messages to. As an example, two(2) route entries
3525 that are created by two(2) redirect indications results in two(2)
3526 cached routes for the same realm and Application Id. However, one
3527 has a redirect usage of ALL_SESSION where matching request will be
3528 forwarded to one peer and the other has a redirect usage of ALL_REALM
3529 where request are forwarded to another peer. Therefore, an incoming
3530 request that matches the realm and Application Id of both routes will
3531 need additional resolution. In such a case, a routing precedence
3532 rule MUST be used against the redirect usage value to resolve the
3533 contention. The precedence rule can be found in Section 6.13.
3535 6.1.9. Relaying and Proxying Requests
3537 A relay or proxy agent MUST append a Route-Record AVP to all requests
3538 forwarded. The AVP contains the identity of the peer the request was
3539 received from.
3541 The Hop-by-Hop identifier in the request is saved, and replaced with
3542 a locally unique value. The source of the request is also saved,
3543 which includes the IP address, port and protocol.
3545 A relay or proxy agent MAY include the Proxy-Info AVP in requests if
3546 it requires access to any local state information when the
3547 corresponding response is received. The Proxy-Info AVP has security
3548 implications as state information is distributed to other entities.
3549 As such, it is RECOMMENDED that the content of the Proxy-Info AVP be
3550 protected with cryptographic mechanisms, for example by using a keyed
3551 message digest such as HMAC-SHA1 [RFC2104]. Such a mechanism,
3552 however, requires the management of keys, although only locally at
3553 the Diameter server. Still, a full description of the management of
3554 the keys used to protect the Proxy-Info AVP is beyond the scope of
3555 this document. Below is a list of common recommendations:
3557 o The keys should be generated securely following the randomness
3558 recommendations in [RFC4086].
3560 o The keys and cryptographic protection algorithms should be at
3561 least 128 bits in strength.
3563 o The keys should not be used for any other purpose than generating
3564 and verifying tickets.
3566 o The keys should be changed regularly.
3568 o The keys should be changed if the ticket format or cryptographic
3569 protection algorithms change.
3571 The message is then forwarded to the next hop, as identified in the
3572 Routing Table.
3574 Figure 6 provides an example of message routing using the procedures
3575 listed in these sections.
3577 (Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
3578 (Origin-Realm=example.net) (Origin-Realm=example.net)
3579 (Destination-Realm=example.com) (Destination-
3580 Realm=example.com)
3581 (Route-Record=nas.example.net)
3582 +------+ ------> +------+ ------> +------+
3583 | | (Request) | | (Request) | |
3584 | NAS +-------------------+ DRL +-------------------+ HMS |
3585 | | | | | |
3586 +------+ <------ +------+ <------ +------+
3587 example.net (Answer) example.net (Answer) example.com
3588 (Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
3589 (Origin-Realm=example.com) (Origin-Realm=example.com)
3591 Figure 6: Routing of Diameter messages
3593 Relay and proxy agents are not required to perform full inspection of
3594 incoming messages. At a minimum, validation of the message header
3595 and relevant routing AVPs has to be done when relaying messages.
3596 Proxy agents may optionally perform more in-depth message validation
3597 for applications it is interested in.
3599 6.2. Diameter Answer Processing
3601 When a request is locally processed, the following procedures MUST be
3602 applied to create the associated answer, in addition to any
3603 additional procedures that MAY be discussed in the Diameter
3604 application defining the command:
3606 o The same Hop-by-Hop identifier in the request is used in the
3607 answer.
3609 o The local host's identity is encoded in the Origin-Host AVP.
3611 o The Destination-Host and Destination-Realm AVPs MUST NOT be
3612 present in the answer message.
3614 o The Result-Code AVP is added with its value indicating success or
3615 failure.
3617 o If the Session-Id is present in the request, it MUST be included
3618 in the answer.
3620 o Any Proxy-Info AVPs in the request MUST be added to the answer
3621 message, in the same order they were present in the request.
3623 o The 'P' bit is set to the same value as the one in the request.
3625 o The same End-to-End identifier in the request is used in the
3626 answer.
3628 Note that the error messages (see Section 7) are also subjected to
3629 the above processing rules.
3631 6.2.1. Processing Received Answers
3633 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
3634 answer received against the list of pending requests. The
3635 corresponding message should be removed from the list of pending
3636 requests. It SHOULD ignore answers received that do not match a
3637 known Hop-by-Hop Identifier.
3639 6.2.2. Relaying and Proxying Answers
3641 If the answer is for a request which was proxied or relayed, the
3642 agent MUST restore the original value of the Diameter header's Hop-
3643 by-Hop Identifier field.
3645 If the last Proxy-Info AVP in the message is targeted to the local
3646 Diameter server, the AVP MUST be removed before the answer is
3647 forwarded.
3649 If a relay or proxy agent receives an answer with a Result-Code AVP
3650 indicating a failure, it MUST NOT modify the contents of the AVP.
3651 Any additional local errors detected SHOULD be logged, but not
3652 reflected in the Result-Code AVP. If the agent receives an answer
3653 message with a Result-Code AVP indicating success, and it wishes to
3654 modify the AVP to indicate an error, it MUST modify the Result-Code
3655 AVP to contain the appropriate error in the message destined towards
3656 the access device as well as include the Error-Reporting-Host AVP and
3657 it MUST issue an STR on behalf of the access device towards the
3658 Diameter server.
3660 The agent MUST then send the answer to the host that it received the
3661 original request from.
3663 6.3. Origin-Host AVP
3665 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
3666 MUST be present in all Diameter messages. This AVP identifies the
3667 endpoint that originated the Diameter message. Relay agents MUST NOT
3668 modify this AVP.
3670 The value of the Origin-Host AVP is guaranteed to be unique within a
3671 single host.
3673 Note that the Origin-Host AVP may resolve to more than one address as
3674 the Diameter peer may support more than one address.
3676 This AVP SHOULD be placed as close to the Diameter header as
3677 possible.
3679 6.4. Origin-Realm AVP
3681 The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.
3682 This AVP contains the Realm of the originator of any Diameter message
3683 and MUST be present in all messages.
3685 This AVP SHOULD be placed as close to the Diameter header as
3686 possible.
3688 6.5. Destination-Host AVP
3690 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
3691 This AVP MUST be present in all unsolicited agent initiated messages,
3692 MAY be present in request messages, and MUST NOT be present in Answer
3693 messages.
3695 The absence of the Destination-Host AVP will cause a message to be
3696 sent to any Diameter server supporting the application within the
3697 realm specified in Destination-Realm AVP.
3699 This AVP SHOULD be placed as close to the Diameter header as
3700 possible.
3702 6.6. Destination-Realm AVP
3704 The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity,
3705 and contains the realm the message is to be routed to. The
3706 Destination-Realm AVP MUST NOT be present in Answer messages.
3707 Diameter Clients insert the realm portion of the User-Name AVP.
3708 Diameter servers initiating a request message use the value of the
3709 Origin-Realm AVP from a previous message received from the intended
3710 target host (unless it is known a priori). When present, the
3711 Destination-Realm AVP is used to perform message routing decisions.
3713 The CCF for a request message that includes the Destination-Realm AVP
3714 SHOULD list the Destination-Realm AVP as a required AVP (an AVP
3715 indicated as {AVP}) otherwise the message is inherently a non-
3716 routable message.
3718 This AVP SHOULD be placed as close to the Diameter header as
3719 possible.
3721 6.7. Routing AVPs
3723 The AVPs defined in this section are Diameter AVPs used for routing
3724 purposes. These AVPs change as Diameter messages are processed by
3725 agents.
3727 6.7.1. Route-Record AVP
3729 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
3730 identity added in this AVP MUST be the same as the one received in
3731 the Origin-Host of the Capabilities Exchange message.
3733 6.7.2. Proxy-Info AVP
3735 The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
3736 contains the identity and local state information of the Diameter
3737 node that creates and adds it to a message. The Grouped Data field
3738 has the following CCF grammar:
3740 Proxy-Info ::= < AVP Header: 284 >
3741 { Proxy-Host }
3742 { Proxy-State }
3743 * [ AVP ]
3745 6.7.3. Proxy-Host AVP
3747 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This
3748 AVP contains the identity of the host that added the Proxy-Info AVP.
3750 6.7.4. Proxy-State AVP
3752 The Proxy-State AVP (AVP Code 33) is of type OctetString. It
3753 contains state information that would otherwise be stored at the
3754 Diameter entity that created it. As such, this AVP MUST be treated
3755 as opaque data by other Diameter entities.
3757 6.8. Auth-Application-Id AVP
3759 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
3760 is used in order to advertise support of the Authentication and
3761 Authorization portion of an application (see Section 2.4). If
3762 present in a message other than CER and CEA, the value of the Auth-
3763 Application-Id AVP MUST match the Application Id present in the
3764 Diameter message header.
3766 6.9. Acct-Application-Id AVP
3768 The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
3769 is used in order to advertise support of the Accounting portion of an
3770 application (see Section 2.4). If present in a message other than
3771 CER and CEA, the value of the Acct-Application-Id AVP MUST match the
3772 Application Id present in the Diameter message header.
3774 6.10. Inband-Security-Id AVP
3776 The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
3777 is used in order to advertise support of the security portion of the
3778 application. The use of this AVP in CER and CEA messages is NOT
3779 RECCOMENDED. Instead, discovery of a Diameter entities security
3780 capabilities can be done either through static configuration or via
3781 Diameter Peer Discovery as described in Section 5.2.
3783 The following values are supported:
3785 NO_INBAND_SECURITY 0
3787 This peer does not support TLS/TCP and DTLS/SCTP. This is the
3788 default value, if the AVP is omitted.
3790 TLS 1
3792 This node supports TLS/TCP [RFC5246] and DTLS/SCTP [RFC6083]
3793 security.
3795 6.11. Vendor-Specific-Application-Id AVP
3797 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
3798 Grouped and is used to advertise support of a vendor-specific
3799 Diameter Application. Exactly one instance of either Auth-
3800 Application-Id or Acct-Application-Id AVP MUST be present. The
3801 Application Id carried by either Auth-Application-Id or Acct-
3802 Application-Id AVP MUST comply with vendor specific Application Id
3803 assignment described in Sec 11.3. It MUST also match the Application
3804 Id present in the Diameter header except when used in a CER or CEA
3805 message.
3807 The Vendor-Id AVP is an informational AVP pertaining to the vendor
3808 who may have authorship of the vendor-specific Diameter application.
3809 It MUST NOT be used as a means of defining a completely separate
3810 vendor-specific Application Id space.
3812 The Vendor-Specific-Application-Id AVP SHOULD be placed as close to
3813 the Diameter header as possible.
3815 AVP Format
3817 ::= < AVP Header: 260 >
3818 { Vendor-Id }
3819 [ Auth-Application-Id ]
3820 [ Acct-Application-Id ]
3822 A Vendor-Specific-Application-Id AVP MUST contain exactly one of
3823 either Auth-Application-Id or Acct-Application-Id. If a Vendor-
3824 Specific-Application-Id is received without any of these two AVPs,
3825 then the recipient SHOULD issue an answer with a Result-Code set to
3826 DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP
3827 which MUST contain an example of an Auth-Application-Id AVP and an
3828 Acct-Application-Id AVP.
3830 If a Vendor-Specific-Application-Id is received that contains both
3831 Auth-Application-Id and Acct-Application-Id, then the recipient MUST
3832 issue an answer with Result-Code set to
3833 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a
3834 Failed-AVP which MUST contain the received Auth-Application-Id AVP
3835 and Acct-Application-Id AVP.
3837 6.12. Redirect-Host AVP
3839 The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. One or
3840 more of instances of this AVP MUST be present if the answer message's
3841 'E' bit is set and the Result-Code AVP is set to
3842 DIAMETER_REDIRECT_INDICATION.
3844 Upon receiving the above, the receiving Diameter node SHOULD forward
3845 the request directly to one of the hosts identified in these AVPs.
3846 The server contained in the selected Redirect-Host AVP SHOULD be used
3847 for all messages matching the criteria set by the Redirect-Host-Usage
3848 AVP.
3850 6.13. Redirect-Host-Usage AVP
3852 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
3853 This AVP MAY be present in answer messages whose 'E' bit is set and
3854 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
3856 When present, this AVP provides a hints about how the routing entry
3857 resulting from the Redirect-Host is to be used. The following values
3858 are supported:
3860 DONT_CACHE 0
3862 The host specified in the Redirect-Host AVP SHOULD NOT be cached.
3863 This is the default value.
3865 ALL_SESSION 1
3867 All messages within the same session, as defined by the same value
3868 of the Session-ID AVP SHOULD be sent to the host specified in the
3869 Redirect-Host AVP.
3871 ALL_REALM 2
3873 All messages destined for the realm requested SHOULD be sent to
3874 the host specified in the Redirect-Host AVP.
3876 REALM_AND_APPLICATION 3
3878 All messages for the application requested to the realm specified
3879 SHOULD be sent to the host specified in the Redirect-Host AVP.
3881 ALL_APPLICATION 4
3883 All messages for the application requested SHOULD be sent to the
3884 host specified in the Redirect-Host AVP.
3886 ALL_HOST 5
3888 All messages that would be sent to the host that generated the
3889 Redirect-Host SHOULD be sent to the host specified in the
3890 Redirect-Host AVP.
3892 ALL_USER 6
3894 All messages for the user requested SHOULD be sent to the host
3895 specified in the Redirect-Host AVP.
3897 When multiple cached routes are created by redirect indications and
3898 they differ only in redirect usage and peers to forward requests to
3899 (see Section 6.1.8, a precedence rule MUST be applied to the redirect
3900 usage values of the cached routes during normal routing to resolve
3901 contentions that may occur. The precedence rule is the order that
3902 dictate which redirect usage should be considered before any other as
3903 they appear. The order is as follows:
3905 1. ALL_SESSION
3907 2. ALL_USER
3909 3. REALM_AND_APPLICATION
3911 4. ALL_REALM
3913 5. ALL_APPLICATION
3915 6. ALL_HOST
3917 6.14. Redirect-Max-Cache-Time AVP
3919 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
3920 This AVP MUST be present in answer messages whose 'E' bit is set, the
3921 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the
3922 Redirect-Host-Usage AVP set to a non-zero value.
3924 This AVP contains the maximum number of seconds the peer and route
3925 table entries, created as a result of the Redirect-Host, SHOULD be
3926 cached. Note that once a host is no longer reachable, any associated
3927 cache, peer and routing table entries MUST be deleted.
3929 7. Error Handling
3931 There are two different types of errors in Diameter; protocol and
3932 application errors. A protocol error is one that occurs at the base
3933 protocol level, and MAY require per hop attention (e.g., message
3934 routing error). Application errors, on the other hand, generally
3935 occur due to a problem with a function specified in a Diameter
3936 application (e.g., user authentication, missing AVP).
3938 Result-Code AVP values that are used to report protocol errors MUST
3939 only be present in answer messages whose 'E' bit is set. When a
3940 request message is received that causes a protocol error, an answer
3941 message is returned with the 'E' bit set, and the Result-Code AVP is
3942 set to the appropriate protocol error value. As the answer is sent
3943 back towards the originator of the request, each proxy or relay agent
3944 MAY take action on the message.
3946 1. Request +---------+ Link Broken
3947 +-------------------------->|Diameter |----///----+
3948 | +---------------------| | v
3949 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+
3950 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
3951 | | | Home |
3952 | Relay 1 |--+ +---------+ | Server |
3953 +---------+ | 3. Request |Diameter | +--------+
3954 +-------------------->| | ^
3955 | Relay 3 |-----------+
3956 +---------+
3958 Figure 7: Example of Protocol Error causing answer message
3960 Figure 7 provides an example of a message forwarded upstream by a
3961 Diameter relay. When the message is received by Relay 2, and it
3962 detects that it cannot forward the request to the home server, an
3963 answer message is returned with the 'E' bit set and the Result-Code
3964 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls
3965 within the protocol error category, Relay 1 would take special
3966 action, and given the error, attempt to route the message through its
3967 alternate Relay 3.
3969 +---------+ 1. Request +---------+ 2. Request +---------+
3970 | Access |------------>|Diameter |------------>|Diameter |
3971 | | | | | Home |
3972 | Device |<------------| Relay |<------------| Server |
3973 +---------+ 4. Answer +---------+ 3. Answer +---------+
3974 (Missing AVP) (Missing AVP)
3976 Figure 8: Example of Application Error Answer message
3978 Figure 8 provides an example of a Diameter message that caused an
3979 application error. When application errors occur, the Diameter
3980 entity reporting the error clears the 'R' bit in the Command Flags,
3981 and adds the Result-Code AVP with the proper value. Application
3982 errors do not require any proxy or relay agent involvement, and
3983 therefore the message would be forwarded back to the originator of
3984 the request.
3986 In the case where the answer message itself contains errors, any
3987 related session SHOULD be terminated by sending an STR or ASR
3988 message. The Termination-Cause AVP in the STR MAY be filled with the
3989 appropriate value to indicate the cause of the error. An application
3990 MAY also send an application-specific request instead of STR or ASR
3991 to signal the error in the case where no state is maintained or to
3992 allow for some form of error recovery with the corresponding Diameter
3993 entity.
3995 There are certain Result-Code AVP application errors that require
3996 additional AVPs to be present in the answer. In these cases, the
3997 Diameter node that sets the Result-Code AVP to indicate the error
3998 MUST add the AVPs. Examples are:
4000 o A request with an unrecognized AVP is received with the 'M' bit
4001 (Mandatory bit) set, causes an answer to be sent with the Result-
4002 Code AVP set to DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP
4003 containing the offending AVP.
4005 o A request with an AVP that is received with an unrecognized value
4006 causes an answer to be returned with the Result-Code AVP set to
4007 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the
4008 AVP causing the error.
4010 o A received command which is missing AVP(s) that are defined as
4011 required in the commands CCF; examples are AVPs indicated as
4012 {AVP}. The receiver issues an answer with the Result-Code set to
4013 DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and
4014 other fields set as expected in the missing AVP. The created AVP
4015 is then added to the Failed-AVP AVP.
4017 The Result-Code AVP describes the error that the Diameter node
4018 encountered in its processing. In case there are multiple errors,
4019 the Diameter node MUST report only the first error it encountered
4020 (detected possibly in some implementation dependent order). The
4021 specific errors that can be described by this AVP are described in
4022 the following section.
4024 7.1. Result-Code AVP
4026 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
4027 indicates whether a particular request was completed successfully or
4028 whether an error occurred. All Diameter answer messages in IETF
4029 defined Diameter application specification MUST include one Result-
4030 Code AVP. A non-successful Result-Code AVP (one containing a non
4031 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the
4032 Error-Reporting-Host AVP if the host setting the Result-Code AVP is
4033 different from the identity encoded in the Origin-Host AVP.
4035 The Result-Code data field contains an IANA-managed 32-bit address
4036 space representing errors (see Section 11.3.2). Diameter provides
4037 the following classes of errors, all identified by the thousands
4038 digit in the decimal notation:
4040 o 1xxx (Informational)
4042 o 2xxx (Success)
4044 o 3xxx (Protocol Errors)
4046 o 4xxx (Transient Failures)
4048 o 5xxx (Permanent Failure)
4050 A non-recognized class (one whose first digit is not defined in this
4051 section) MUST be handled as a permanent failure.
4053 7.1.1. Informational
4055 Errors that fall within this category are used to inform the
4056 requester that a request could not be satisfied, and additional
4057 action is required on its part before access is granted.
4059 DIAMETER_MULTI_ROUND_AUTH 1001
4061 This informational error is returned by a Diameter server to
4062 inform the access device that the authentication mechanism being
4063 used requires multiple round trips, and a subsequent request needs
4064 to be issued in order for access to be granted.
4066 7.1.2. Success
4068 Errors that fall within the Success category are used to inform a
4069 peer that a request has been successfully completed.
4071 DIAMETER_SUCCESS 2001
4073 The request was successfully completed.
4075 DIAMETER_LIMITED_SUCCESS 2002
4077 When returned, the request was successfully completed, but
4078 additional processing is required by the application in order to
4079 provide service to the user.
4081 7.1.3. Protocol Errors
4083 Errors that fall within the Protocol Error category SHOULD be treated
4084 on a per-hop basis, and Diameter proxies MAY attempt to correct the
4085 error, if it is possible. Note that these errors MUST only be used
4086 in answer messages whose 'E' bit is set.
4088 DIAMETER_COMMAND_UNSUPPORTED 3001
4090 This error code is used when a Diameter entity receives a message
4091 with a Command Code that it does not support.
4093 DIAMETER_UNABLE_TO_DELIVER 3002
4095 This error is given when Diameter can not deliver the message to
4096 the destination, either because no host within the realm
4097 supporting the required application was available to process the
4098 request, or because Destination-Host AVP was given without the
4099 associated Destination-Realm AVP.
4101 DIAMETER_REALM_NOT_SERVED 3003
4103 The intended realm of the request is not recognized.
4105 DIAMETER_TOO_BUSY 3004
4107 When returned, a Diameter node SHOULD attempt to send the message
4108 to an alternate peer. This error MUST only be used when a
4109 specific server is requested, and it cannot provide the requested
4110 service.
4112 DIAMETER_LOOP_DETECTED 3005
4114 An agent detected a loop while trying to get the message to the
4115 intended recipient. The message MAY be sent to an alternate peer,
4116 if one is available, but the peer reporting the error has
4117 identified a configuration problem.
4119 DIAMETER_REDIRECT_INDICATION 3006
4121 A redirect agent has determined that the request could not be
4122 satisfied locally and the initiator of the request SHOULD direct
4123 the request directly to the server, whose contact information has
4124 been added to the response. When set, the Redirect-Host AVP MUST
4125 be present.
4127 DIAMETER_APPLICATION_UNSUPPORTED 3007
4129 A request was sent for an application that is not supported.
4131 DIAMETER_INVALID_HDR_BITS 3008
4133 A request was received whose bits in the Diameter header were
4134 either set to an invalid combination, or to a value that is
4135 inconsistent with the command code's definition.
4137 DIAMETER_INVALID_AVP_BITS 3009
4139 A request was received that included an AVP whose flag bits are
4140 set to an unrecognized value, or that is inconsistent with the
4141 AVP's definition.
4143 DIAMETER_UNKNOWN_PEER 3010
4145 A CER was received from an unknown peer.
4147 7.1.4. Transient Failures
4149 Errors that fall within the transient failures category are used to
4150 inform a peer that the request could not be satisfied at the time it
4151 was received, but MAY be able to satisfy the request in the future.
4152 Note that these errors MUST be used in answer messages whose 'E' bit
4153 is not set.
4155 DIAMETER_AUTHENTICATION_REJECTED 4001
4157 The authentication process for the user failed, most likely due to
4158 an invalid password used by the user. Further attempts MUST only
4159 be tried after prompting the user for a new password.
4161 DIAMETER_OUT_OF_SPACE 4002
4163 A Diameter node received the accounting request but was unable to
4164 commit it to stable storage due to a temporary lack of space.
4166 ELECTION_LOST 4003
4168 The peer has determined that it has lost the election process and
4169 has therefore disconnected the transport connection.
4171 7.1.5. Permanent Failures
4173 Errors that fall within the permanent failures category are used to
4174 inform the peer that the request failed, and should not be attempted
4175 again. Note that these errors SHOULD be used in answer messages
4176 whose 'E' bit is not set. In error conditions where it is not
4177 possible or efficient to compose application-specific answer grammar
4178 then answer messages with E-bit set and complying to the grammar
4179 described in 7.2 MAY also be used for permanent errors.
4181 DIAMETER_AVP_UNSUPPORTED 5001
4183 The peer received a message that contained an AVP that is not
4184 recognized or supported and was marked with the Mandatory bit. A
4185 Diameter message with this error MUST contain one or more Failed-
4186 AVP AVP containing the AVPs that caused the failure.
4188 DIAMETER_UNKNOWN_SESSION_ID 5002
4190 The request contained an unknown Session-Id.
4192 DIAMETER_AUTHORIZATION_REJECTED 5003
4194 A request was received for which the user could not be authorized.
4195 This error could occur if the service requested is not permitted
4196 to the user.
4198 DIAMETER_INVALID_AVP_VALUE 5004
4200 The request contained an AVP with an invalid value in its data
4201 portion. A Diameter message indicating this error MUST include
4202 the offending AVPs within a Failed-AVP AVP.
4204 DIAMETER_MISSING_AVP 5005
4206 The request did not contain an AVP that is required by the Command
4207 Code definition. If this value is sent in the Result-Code AVP, a
4208 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP
4209 AVP MUST contain an example of the missing AVP complete with the
4210 Vendor-Id if applicable. The value field of the missing AVP
4211 should be of correct minimum length and contain zeroes.
4213 DIAMETER_RESOURCES_EXCEEDED 5006
4215 A request was received that cannot be authorized because the user
4216 has already expended allowed resources. An example of this error
4217 condition is a user that is restricted to one dial-up PPP port,
4218 attempts to establish a second PPP connection.
4220 DIAMETER_CONTRADICTING_AVPS 5007
4222 The Home Diameter server has detected AVPs in the request that
4223 contradicted each other, and is not willing to provide service to
4224 the user. The Failed-AVP AVPs MUST be present which contains the
4225 AVPs that contradicted each other.
4227 DIAMETER_AVP_NOT_ALLOWED 5008
4229 A message was received with an AVP that MUST NOT be present. The
4230 Failed-AVP AVP MUST be included and contain a copy of the
4231 offending AVP.
4233 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
4235 A message was received that included an AVP that appeared more
4236 often than permitted in the message definition. The Failed-AVP
4237 AVP MUST be included and contain a copy of the first instance of
4238 the offending AVP that exceeded the maximum number of occurrences
4240 DIAMETER_NO_COMMON_APPLICATION 5010
4242 This error is returned by a Diameter node that receives a CER
4243 whereby no applications are common between the CER sending peer
4244 and the CER receiving peer.
4246 DIAMETER_UNSUPPORTED_VERSION 5011
4248 This error is returned when a request was received, whose version
4249 number is unsupported.
4251 DIAMETER_UNABLE_TO_COMPLY 5012
4253 This error is returned when a request is rejected for unspecified
4254 reasons.
4256 DIAMETER_INVALID_BIT_IN_HEADER 5013
4258 This error is returned when a reserved bit in the Diameter header
4259 is set to one (1) or the bits in the Diameter header are set
4260 incorrectly.
4262 DIAMETER_INVALID_AVP_LENGTH 5014
4264 The request contained an AVP with an invalid length. A Diameter
4265 message indicating this error MUST include the offending AVPs
4266 within a Failed-AVP AVP. In cases where the erroneous AVP length
4267 value exceeds the message length or is less than the minimum AVP
4268 header length, it is sufficient to include the offending AVP
4269 header and a zero filled payload of the minimum required length
4270 for the payloads data type. If the AVP is a grouped AVP, the
4271 grouped AVP header with an empty payload would be sufficient to
4272 indicate the offending AVP. In the case where the offending AVP
4273 header cannot be fully decoded when the AVP length is less than
4274 the minimum AVP header length, it is sufficient to include an
4275 offending AVP header that is formulated by padding the incomplete
4276 AVP header with zero up to the minimum AVP header length.
4278 DIAMETER_INVALID_MESSAGE_LENGTH 5015
4280 This error is returned when a request is received with an invalid
4281 message length.
4283 DIAMETER_INVALID_AVP_BIT_COMBO 5016
4285 The request contained an AVP with which is not allowed to have the
4286 given value in the AVP Flags field. A Diameter message indicating
4287 this error MUST include the offending AVPs within a Failed-AVP
4288 AVP.
4290 DIAMETER_NO_COMMON_SECURITY 5017
4292 This error is returned when a CER message is received, and there
4293 are no common security mechanisms supported between the peers. A
4294 Capabilities-Exchange-Answer (CEA) MUST be returned with the
4295 Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
4297 7.2. Error Bit
4299 The 'E' (Error Bit) in the Diameter header is set when the request
4300 caused a protocol-related error (see Section 7.1.3). A message with
4301 the 'E' bit MUST NOT be sent as a response to an answer message.
4302 Note that a message with the 'E' bit set is still subjected to the
4303 processing rules defined in Section 6.2. When set, the answer
4304 message will not conform to the CCF specification for the command,
4305 and will instead conform to the following CCF:
4307 Message Format
4309 ::= < Diameter Header: code, ERR [, PXY] >
4310 0*1< Session-Id >
4311 { Origin-Host }
4312 { Origin-Realm }
4313 { Result-Code }
4314 [ Origin-State-Id ]
4315 [ Error-Message ]
4316 [ Error-Reporting-Host ]
4317 [ Failed-AVP ]
4318 [ Experimental-Result ]
4319 * [ Proxy-Info ]
4320 * [ AVP ]
4322 Note that the code used in the header is the same than the one found
4323 in the request message, but with the 'R' bit cleared and the 'E' bit
4324 set. The 'P' bit in the header is set to the same value as the one
4325 found in the request message.
4327 7.3. Error-Message AVP
4329 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY
4330 accompany a Result-Code AVP as a human readable error message. The
4331 Error-Message AVP is not intended to be useful in an environment
4332 where error messages are processed automatically. It SHOULD NOT be
4333 expected that the content of this AVP is parsed by network entities.
4335 7.4. Error-Reporting-Host AVP
4337 The Error-Reporting-Host AVP (AVP Code 294) is of type
4338 DiameterIdentity. This AVP contains the identity of the Diameter
4339 host that sent the Result-Code AVP to a value other than 2001
4340 (Success), only if the host setting the Result-Code is different from
4341 the one encoded in the Origin-Host AVP. This AVP is intended to be
4342 used for troubleshooting purposes, and MUST be set when the Result-
4343 Code AVP indicates a failure.
4345 7.5. Failed-AVP AVP
4347 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
4348 debugging information in cases where a request is rejected or not
4349 fully processed due to erroneous information in a specific AVP. The
4350 value of the Result-Code AVP will provide information on the reason
4351 for the Failed-AVP AVP. A Diameter answer message SHOULD contain
4352 only one Failed-AVP that corresponds to the error indicated by the
4353 Result-Code AVP. For practical purposes, this Failed-AVP would
4354 typically refer to the first AVP processing error that a Diameter
4355 node encounters.
4357 The possible reasons for this AVP are the presence of an improperly
4358 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
4359 value, the omission of a required AVP, the presence of an explicitly
4360 excluded AVP (see tables in Section 10) or the presence of two or
4361 more occurrences of an AVP which is restricted to 0, 1, or 0-1
4362 occurrences.
4364 A Diameter message SHOULD contain one Failed-AVP AVP, containing the
4365 entire AVP that could not be processed successfully. If the failure
4366 reason is omission of a required AVP, an AVP with the missing AVP
4367 code, the missing vendor id, and a zero filled payload of the minimum
4368 required length for the omitted AVP will be added. If the failure
4369 reason is an invalid AVP length where the reported length is less
4370 than the minimum AVP header length or greater than the reported
4371 message length, a copy of the offending AVP header and a zero filled
4372 payload of the minimum required length SHOULD be added.
4374 In the case where the offending AVP is embedded within a grouped AVP,
4375 the Failed-AVP MAY contain the grouped AVP which in turn contains the
4376 single offending AVP. The same method MAY be employed if the grouped
4377 AVP itself is embedded in yet another grouped AVP and so on. In this
4378 case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the
4379 single offending AVP. This enables the recipient to detect the
4380 location of the offending AVP when embedded in a group.
4382 AVP Format
4384 ::= < AVP Header: 279 >
4385 1* {AVP}
4387 7.6. Experimental-Result AVP
4389 The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
4390 indicates whether a particular vendor-specific request was completed
4391 successfully or whether an error occurred. This AVP has the
4392 following structure:
4394 AVP Format
4396 Experimental-Result ::= < AVP Header: 297 >
4397 { Vendor-Id }
4398 { Experimental-Result-Code }
4400 The Vendor-Id AVP (see Section 5.3.3 in this grouped AVP identifies
4401 the vendor responsible for the assignment of the result code which
4402 follows. All Diameter answer messages defined in vendor-specific
4403 applications MUST include either one Result-Code AVP or one
4404 Experimental-Result AVP.
4406 7.7. Experimental-Result-Code AVP
4408 The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32
4409 and contains a vendor-assigned value representing the result of
4410 processing the request.
4412 It is recommended that vendor-specific result codes follow the same
4413 conventions given for the Result-Code AVP regarding the different
4414 types of result codes and the handling of errors (for non 2xxx
4415 values).
4417 8. Diameter User Sessions
4419 In general, Diameter can provide two different types of services to
4420 applications. The first involves authentication and authorization,
4421 and can optionally make use of accounting. The second only makes use
4422 of accounting.
4424 When a service makes use of the authentication and/or authorization
4425 portion of an application, and a user requests access to the network,
4426 the Diameter client issues an auth request to its local server. The
4427 auth request is defined in a service-specific Diameter application
4428 (e.g., NASREQ). The request contains a Session-Id AVP, which is used
4429 in subsequent messages (e.g., subsequent authorization, accounting,
4430 etc) relating to the user's session. The Session-Id AVP is a means
4431 for the client and servers to correlate a Diameter message with a
4432 user session.
4434 When a Diameter server authorizes a user to use network resources for
4435 a finite amount of time, and it is willing to extend the
4436 authorization via a future request, it MUST add the Authorization-
4437 Lifetime AVP to the answer message. The Authorization-Lifetime AVP
4438 defines the maximum number of seconds a user MAY make use of the
4439 resources before another authorization request is expected by the
4440 server. The Auth-Grace-Period AVP contains the number of seconds
4441 following the expiration of the Authorization-Lifetime, after which
4442 the server will release all state information related to the user's
4443 session. Note that if payment for services is expected by the
4444 serving realm from the user's home realm, the Authorization-Lifetime
4445 AVP, combined with the Auth-Grace-Period AVP, implies the maximum
4446 length of the session the home realm is willing to be fiscally
4447 responsible for. Services provided past the expiration of the
4448 Authorization-Lifetime and Auth-Grace-Period AVPs are the
4449 responsibility of the access device. Of course, the actual cost of
4450 services rendered is clearly outside the scope of the protocol.
4452 An access device that does not expect to send a re-authorization or a
4453 session termination request to the server MAY include the Auth-
4454 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
4455 to the server. If the server accepts the hint, it agrees that since
4456 no session termination message will be received once service to the
4457 user is terminated, it cannot maintain state for the session. If the
4458 answer message from the server contains a different value in the
4459 Auth-Session-State AVP (or the default value if the AVP is absent),
4460 the access device MUST follow the server's directives. Note that the
4461 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-
4462 authorization requests and answers.
4464 The base protocol does not include any authorization request
4465 messages, since these are largely application-specific and are
4466 defined in a Diameter application document. However, the base
4467 protocol does define a set of messages that are used to terminate
4468 user sessions. These are used to allow servers that maintain state
4469 information to free resources.
4471 When a service only makes use of the Accounting portion of the
4472 Diameter protocol, even in combination with an application, the
4473 Session-Id is still used to identify user sessions. However, the
4474 session termination messages are not used, since a session is
4475 signaled as being terminated by issuing an accounting stop message.
4477 Diameter may also be used for services that cannot be easily
4478 categorized as authentication, authorization or accounting (e.g.,
4479 certain 3GPP IMS interfaces). In such cases, the finite state
4480 machine defined in subsequent sections may not be applicable.
4481 Therefore, the applications itself MAY need to define its own finite
4482 state machine. However, such application-specific state machines
4483 SHOULD follow the general state machine framework outlined in this
4484 document such as the use of Session-Id AVPs and the use of STR/STA,
4485 ASR/ASA messages for stateful sessions.
4487 8.1. Authorization Session State Machine
4489 This section contains a set of finite state machines, representing
4490 the life cycle of Diameter sessions, and which MUST be observed by
4491 all Diameter implementations that make use of the authentication
4492 and/or authorization portion of a Diameter application. The term
4493 Service-Specific below refers to a message defined in a Diameter
4494 application (e.g., Mobile IPv4, NASREQ).
4496 There are four different authorization session state machines
4497 supported in the Diameter base protocol. The first two describe a
4498 session in which the server is maintaining session state, indicated
4499 by the value of the Auth-Session-State AVP (or its absence). One
4500 describes the session from a client perspective, the other from a
4501 server perspective. The second two state machines are used when the
4502 server does not maintain session state. Here again, one describes
4503 the session from a client perspective, the other from a server
4504 perspective.
4506 When a session is moved to the Idle state, any resources that were
4507 allocated for the particular session must be released. Any event not
4508 listed in the state machines MUST be considered as an error
4509 condition, and an answer, if applicable, MUST be returned to the
4510 originator of the message.
4512 In the case that an application does not support re-auth, the state
4513 transitions related to server-initiated re-auth when both client and
4514 server session maintains state (e.g., Send RAR, Pending, Receive RAA)
4515 MAY be ignored.
4517 In the state table, the event 'Failure to send X' means that the
4518 Diameter agent is unable to send command X to the desired
4519 destination. This could be due to the peer being down, or due to the
4520 peer sending back a transient failure or temporary protocol error
4521 notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the
4522 Result-Code AVP of the corresponding Answer command. The event 'X
4523 successfully sent' is the complement of 'Failure to send X'.
4525 The following state machine is observed by a client when state is
4526 maintained on the server:
4528 CLIENT, STATEFUL
4529 State Event Action New State
4530 ---------------------------------------------------------------
4531 Idle Client or Device Requests Send Pending
4532 access service
4533 specific
4534 auth req
4536 Idle ASR Received Send ASA Idle
4537 for unknown session with
4538 Result-Code =
4539 UNKNOWN_
4540 SESSION_ID
4542 Idle RAR Received Send RAA Idle
4543 for unknown session with
4544 Result-Code =
4545 UNKNOWN_
4546 SESSION_ID
4548 Pending Successful Service-specific Grant Open
4549 authorization answer Access
4550 received with default
4551 Auth-Session-State value
4553 Pending Successful Service-specific Sent STR Discon
4554 authorization answer received
4555 but service not provided
4557 Pending Error processing successful Sent STR Discon
4558 Service-specific authorization
4559 answer
4561 Pending Failed Service-specific Cleanup Idle
4562 authorization answer received
4564 Open User or client device Send Open
4565 requests access to service service
4566 specific
4567 auth req
4569 Open Successful Service-specific Provide Open
4570 authorization answer received Service
4572 Open Failed Service-specific Discon. Idle
4573 authorization answer user/device
4574 received.
4576 Open RAR received and client will Send RAA Open
4577 perform subsequent re-auth with
4578 Result-Code =
4579 SUCCESS
4581 Open RAR received and client will Send RAA Idle
4582 not perform subsequent with
4583 re-auth Result-Code !=
4584 SUCCESS,
4585 Discon.
4586 user/device
4588 Open Session-Timeout Expires on Send STR Discon
4589 Access Device
4591 Open ASR Received, Send ASA Discon
4592 client will comply with
4593 with request to end the Result-Code =
4594 session = SUCCESS,
4595 Send STR.
4597 Open ASR Received, Send ASA Open
4598 client will not comply with
4599 with request to end the Result-Code !=
4600 session != SUCCESS
4602 Open Authorization-Lifetime + Send STR Discon
4603 Auth-Grace-Period expires on
4604 access device
4606 Discon ASR Received Send ASA Discon
4608 Discon STA Received Discon. Idle
4609 user/device
4611 The following state machine is observed by a server when it is
4612 maintaining state for the session:
4614 SERVER, STATEFUL
4615 State Event Action New State
4616 ---------------------------------------------------------------
4617 Idle Service-specific authorization Send Open
4618 request received, and successful
4619 user is authorized serv.
4620 specific
4621 answer
4623 Idle Service-specific authorization Send Idle
4624 request received, and failed serv.
4625 user is not authorized specific
4626 answer
4628 Open Service-specific authorization Send Open
4629 request received, and user successful
4630 is authorized serv. specific
4631 answer
4633 Open Service-specific authorization Send Idle
4634 request received, and user failed serv.
4635 is not authorized specific
4636 answer,
4637 Cleanup
4639 Open Home server wants to confirm Send RAR Pending
4640 authentication and/or
4641 authorization of the user
4643 Pending Received RAA with a failed Cleanup Idle
4644 Result-Code
4646 Pending Received RAA with Result-Code Update Open
4647 = SUCCESS session
4649 Open Home server wants to Send ASR Discon
4650 terminate the service
4652 Open Authorization-Lifetime (and Cleanup Idle
4653 Auth-Grace-Period) expires
4654 on home server.
4656 Open Session-Timeout expires on Cleanup Idle
4657 home server
4659 Discon Failure to send ASR Wait, Discon
4660 resend ASR
4662 Discon ASR successfully sent and Cleanup Idle
4663 ASA Received with Result-Code
4665 Not ASA Received None No Change.
4666 Discon
4668 Any STR Received Send STA, Idle
4669 Cleanup.
4671 The following state machine is observed by a client when state is not
4672 maintained on the server:
4674 CLIENT, STATELESS
4675 State Event Action New State
4676 ---------------------------------------------------------------
4677 Idle Client or Device Requests Send Pending
4678 access service
4679 specific
4680 auth req
4682 Pending Successful Service-specific Grant Open
4683 authorization answer Access
4684 received with Auth-Session-
4685 State set to
4686 NO_STATE_MAINTAINED
4688 Pending Failed Service-specific Cleanup Idle
4689 authorization answer
4690 received
4692 Open Session-Timeout Expires on Discon. Idle
4693 Access Device user/device
4695 Open Service to user is terminated Discon. Idle
4696 user/device
4698 The following state machine is observed by a server when it is not
4699 maintaining state for the session:
4701 SERVER, STATELESS
4702 State Event Action New State
4703 ---------------------------------------------------------------
4704 Idle Service-specific authorization Send serv. Idle
4705 request received, and specific
4706 successfully processed answer
4708 8.2. Accounting Session State Machine
4710 The following state machines MUST be supported for applications that
4711 have an accounting portion or that require only accounting services.
4712 The first state machine is to be observed by clients.
4714 See Section 9.7 for Accounting Command Codes and Section 9.8 for
4715 Accounting AVPs.
4717 The server side in the accounting state machine depends in some cases
4718 on the particular application. The Diameter base protocol defines a
4719 default state machine that MUST be followed by all applications that
4720 have not specified other state machines. This is the second state
4721 machine in this section described below.
4723 The default server side state machine requires the reception of
4724 accounting records in any order and at any time, and does not place
4725 any standards requirement on the processing of these records.
4726 Implementations of Diameter may perform checking, ordering,
4727 correlation, fraud detection, and other tasks based on these records.
4728 AVPs may need to be inspected as a part of these tasks. The tasks
4729 can happen either immediately after record reception or in a post-
4730 processing phase. However, as these tasks are typically application
4731 or even policy dependent, they are not standardized by the Diameter
4732 specifications. Applications MAY define requirements on when to
4733 accept accounting records based on the used value of Accounting-
4734 Realtime-Required AVP, credit limits checks, and so on.
4736 However, the Diameter base protocol defines one optional server side
4737 state machine that MAY be followed by applications that require
4738 keeping track of the session state at the accounting server. Note
4739 that such tracking is incompatible with the ability to sustain long
4740 duration connectivity problems. Therefore, the use of this state
4741 machine is recommended only in applications where the value of the
4742 Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence
4743 accounting connectivity problems are required to cause the serviced
4744 user to be disconnected. Otherwise, records produced by the client
4745 may be lost by the server which no longer accepts them after the
4746 connectivity is re-established. This state machine is the third
4747 state machine in this section. The state machine is supervised by a
4748 supervision session timer Ts, which the value should be reasonably
4749 higher than the Acct_Interim_Interval value. Ts MAY be set to two
4750 times the value of the Acct_Interim_Interval so as to avoid the
4751 accounting session in the Diameter server to change to Idle state in
4752 case of short transient network failure.
4754 Any event not listed in the state machines MUST be considered as an
4755 error condition, and a corresponding answer, if applicable, MUST be
4756 returned to the originator of the message.
4758 In the state table, the event 'Failure to send' means that the
4759 Diameter client is unable to communicate with the desired
4760 destination. This could be due to the peer being down, or due to the
4761 peer sending back a transient failure or temporary protocol error
4762 notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
4763 DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
4764 Answer command.
4766 The event 'Failed answer' means that the Diameter client received a
4767 non-transient failure notification in the Accounting Answer command.
4769 Note that the action 'Disconnect user/dev' MUST have an effect also
4770 to the authorization session state table, e.g., cause the STR message
4771 to be sent, if the given application has both authentication/
4772 authorization and accounting portions.
4774 The states PendingS, PendingI, PendingL, PendingE and PendingB stand
4775 for pending states to wait for an answer to an accounting request
4776 related to a Start, Interim, Stop, Event or buffered record,
4777 respectively.
4779 CLIENT, ACCOUNTING
4780 State Event Action New State
4781 ---------------------------------------------------------------
4782 Idle Client or device requests Send PendingS
4783 access accounting
4784 start req.
4786 Idle Client or device requests Send PendingE
4787 a one-time service accounting
4788 event req
4790 Idle Records in storage Send PendingB
4791 record
4793 PendingS Successful accounting Open
4794 start answer received
4796 PendingS Failure to send and buffer Store Open
4797 space available and realtime Start
4798 not equal to DELIVER_AND_GRANT Record
4800 PendingS Failure to send and no buffer Open
4801 space available and realtime
4802 equal to GRANT_AND_LOSE
4804 PendingS Failure to send and no Disconnect Idle
4805 buffer space available and user/dev
4806 realtime not equal to
4807 GRANT_AND_LOSE
4809 PendingS Failed accounting start answer Open
4810 received and realtime equal
4811 to GRANT_AND_LOSE
4813 PendingS Failed accounting start answer Disconnect Idle
4814 received and realtime not user/dev
4815 equal to GRANT_AND_LOSE
4817 PendingS User service terminated Store PendingS
4818 stop
4819 record
4821 Open Interim interval elapses Send PendingI
4822 accounting
4823 interim
4824 record
4825 Open User service terminated Send PendingL
4826 accounting
4827 stop req.
4829 PendingI Successful accounting interim Open
4830 answer received
4832 PendingI Failure to send and (buffer Store Open
4833 space available or old interim
4834 record can be overwritten) record
4835 and realtime not equal to
4836 DELIVER_AND_GRANT
4838 PendingI Failure to send and no buffer Open
4839 space available and realtime
4840 equal to GRANT_AND_LOSE
4842 PendingI Failure to send and no Disconnect Idle
4843 buffer space available and user/dev
4844 realtime not equal to
4845 GRANT_AND_LOSE
4847 PendingI Failed accounting interim Open
4848 answer received and realtime
4849 equal to GRANT_AND_LOSE
4851 PendingI Failed accounting interim Disconnect Idle
4852 answer received and user/dev
4853 realtime not equal to
4854 GRANT_AND_LOSE
4856 PendingI User service terminated Store PendingI
4857 stop
4858 record
4859 PendingE Successful accounting Idle
4860 event answer received
4862 PendingE Failure to send and buffer Store Idle
4863 space available event
4864 record
4866 PendingE Failure to send and no buffer Idle
4867 space available
4869 PendingE Failed accounting event answer Idle
4870 received
4872 PendingB Successful accounting answer Delete Idle
4873 received record
4875 PendingB Failure to send Idle
4877 PendingB Failed accounting answer Delete Idle
4878 received record
4880 PendingL Successful accounting Idle
4881 stop answer received
4883 PendingL Failure to send and buffer Store Idle
4884 space available stop
4885 record
4887 PendingL Failure to send and no buffer Idle
4888 space available
4890 PendingL Failed accounting stop answer Idle
4891 received
4893 SERVER, STATELESS ACCOUNTING
4894 State Event Action New State
4895 ---------------------------------------------------------------
4897 Idle Accounting start request Send Idle
4898 received, and successfully accounting
4899 processed. start
4900 answer
4902 Idle Accounting event request Send Idle
4903 received, and successfully accounting
4904 processed. event
4905 answer
4907 Idle Interim record received, Send Idle
4908 and successfully processed. accounting
4909 interim
4910 answer
4912 Idle Accounting stop request Send Idle
4913 received, and successfully accounting
4914 processed stop answer
4916 Idle Accounting request received, Send Idle
4917 no space left to store accounting
4918 records answer,
4919 Result-Code =
4920 OUT_OF_
4921 SPACE
4923 SERVER, STATEFUL ACCOUNTING
4924 State Event Action New State
4925 ---------------------------------------------------------------
4927 Idle Accounting start request Send Open
4928 received, and successfully accounting
4929 processed. start
4930 answer,
4931 Start Ts
4933 Idle Accounting event request Send Idle
4934 received, and successfully accounting
4935 processed. event
4936 answer
4938 Idle Accounting request received, Send Idle
4939 no space left to store accounting
4940 records answer,
4941 Result-Code =
4942 OUT_OF_
4943 SPACE
4945 Open Interim record received, Send Open
4946 and successfully processed. accounting
4947 interim
4948 answer,
4949 Restart Ts
4951 Open Accounting stop request Send Idle
4952 received, and successfully accounting
4953 processed stop answer,
4954 Stop Ts
4956 Open Accounting request received, Send Idle
4957 no space left to store accounting
4958 records answer,
4959 Result-Code =
4960 OUT_OF_
4961 SPACE,
4962 Stop Ts
4964 Open Session supervision timer Ts Stop Ts Idle
4965 expired
4967 8.3. Server-Initiated Re-Auth
4969 A Diameter server may initiate a re-authentication and/or re-
4970 authorization service for a particular session by issuing a Re-Auth-
4971 Request (RAR).
4973 For example, for pre-paid services, the Diameter server that
4974 originally authorized a session may need some confirmation that the
4975 user is still using the services.
4977 An access device that receives a RAR message with Session-Id equal to
4978 a currently active session MUST initiate a re-auth towards the user,
4979 if the service supports this particular feature. Each Diameter
4980 application MUST state whether server-initiated re-auth is supported,
4981 since some applications do not allow access devices to prompt the
4982 user for re-auth.
4984 8.3.1. Re-Auth-Request
4986 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258
4987 and the message flags' 'R' bit set, may be sent by any server to the
4988 access device that is providing session service, to request that the
4989 user be re-authenticated and/or re-authorized.
4991 Message Format
4993 ::= < Diameter Header: 258, REQ, PXY >
4994 < Session-Id >
4995 { Origin-Host }
4996 { Origin-Realm }
4997 { Destination-Realm }
4998 { Destination-Host }
4999 { Auth-Application-Id }
5000 { Re-Auth-Request-Type }
5001 [ User-Name ]
5002 [ Origin-State-Id ]
5003 * [ Proxy-Info ]
5004 * [ Route-Record ]
5005 * [ AVP ]
5007 8.3.2. Re-Auth-Answer
5009 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258
5010 and the message flags' 'R' bit clear, is sent in response to the RAR.
5011 The Result-Code AVP MUST be present, and indicates the disposition of
5012 the request.
5014 A successful RAA message MUST be followed by an application-specific
5015 authentication and/or authorization message.
5017 Message Format
5019 ::= < Diameter Header: 258, PXY >
5020 < Session-Id >
5021 { Result-Code }
5022 { Origin-Host }
5023 { Origin-Realm }
5024 [ User-Name ]
5025 [ Origin-State-Id ]
5026 [ Error-Message ]
5027 [ Error-Reporting-Host ]
5028 [ Failed-AVP ]
5029 * [ Redirect-Host ]
5030 [ Redirect-Host-Usage ]
5031 [ Redirect-Max-Cache-Time ]
5032 * [ Proxy-Info ]
5033 * [ AVP ]
5035 8.4. Session Termination
5037 It is necessary for a Diameter server that authorized a session, for
5038 which it is maintaining state, to be notified when that session is no
5039 longer active, both for tracking purposes as well as to allow
5040 stateful agents to release any resources that they may have provided
5041 for the user's session. For sessions whose state is not being
5042 maintained, this section is not used.
5044 When a user session that required Diameter authorization terminates,
5045 the access device that provided the service MUST issue a Session-
5046 Termination-Request (STR) message to the Diameter server that
5047 authorized the service, to notify it that the session is no longer
5048 active. An STR MUST be issued when a user session terminates for any
5049 reason, including user logoff, expiration of Session-Timeout,
5050 administrative action, termination upon receipt of an Abort-Session-
5051 Request (see below), orderly shutdown of the access device, etc.
5053 The access device also MUST issue an STR for a session that was
5054 authorized but never actually started. This could occur, for
5055 example, due to a sudden resource shortage in the access device, or
5056 because the access device is unwilling to provide the type of service
5057 requested in the authorization, or because the access device does not
5058 support a mandatory AVP returned in the authorization, etc.
5060 It is also possible that a session that was authorized is never
5061 actually started due to action of a proxy. For example, a proxy may
5062 modify an authorization answer, converting the result from success to
5063 failure, prior to forwarding the message to the access device. If
5064 the answer did not contain an Auth-Session-State AVP with the value
5065 NO_STATE_MAINTAINED, a proxy that causes an authorized session not to
5066 be started MUST issue an STR to the Diameter server that authorized
5067 the session, since the access device has no way of knowing that the
5068 session had been authorized.
5070 A Diameter server that receives an STR message MUST clean up
5071 resources (e.g., session state) associated with the Session-Id
5072 specified in the STR, and return a Session-Termination-Answer.
5074 A Diameter server also MUST clean up resources when the Session-
5075 Timeout expires, or when the Authorization-Lifetime and the Auth-
5076 Grace-Period AVPs expires without receipt of a re-authorization
5077 request, regardless of whether an STR for that session is received.
5078 The access device is not expected to provide service beyond the
5079 expiration of these timers; thus, expiration of either of these
5080 timers implies that the access device may have unexpectedly shut
5081 down.
5083 8.4.1. Session-Termination-Request
5085 The Session-Termination-Request (STR), indicated by the Command-Code
5086 set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter
5087 client or by a Diameter proxy to inform the Diameter Server that an
5088 authenticated and/or authorized session is being terminated.
5090 Message Format
5092 ::= < Diameter Header: 275, REQ, PXY >
5093 < Session-Id >
5094 { Origin-Host }
5095 { Origin-Realm }
5096 { Destination-Realm }
5097 { Auth-Application-Id }
5098 { Termination-Cause }
5099 [ User-Name ]
5100 [ Destination-Host ]
5101 * [ Class ]
5102 [ Origin-State-Id ]
5103 * [ Proxy-Info ]
5104 * [ Route-Record ]
5105 * [ AVP ]
5107 8.4.2. Session-Termination-Answer
5109 The Session-Termination-Answer (STA), indicated by the Command-Code
5110 set to 275 and the message flags' 'R' bit clear, is sent by the
5111 Diameter Server to acknowledge the notification that the session has
5112 been terminated. The Result-Code AVP MUST be present, and MAY
5113 contain an indication that an error occurred while servicing the STR.
5115 Upon sending or receipt of the STA, the Diameter Server MUST release
5116 all resources for the session indicated by the Session-Id AVP. Any
5117 intermediate server in the Proxy-Chain MAY also release any
5118 resources, if necessary.
5120 Message Format
5122 ::= < Diameter Header: 275, PXY >
5123 < Session-Id >
5124 { Result-Code }
5125 { Origin-Host }
5126 { Origin-Realm }
5127 [ User-Name ]
5128 * [ Class ]
5129 [ Error-Message ]
5130 [ Error-Reporting-Host ]
5131 [ Failed-AVP ]
5132 [ Origin-State-Id ]
5133 * [ Redirect-Host ]
5134 [ Redirect-Host-Usage ]
5135 [ Redirect-Max-Cache-Time ]
5136 * [ Proxy-Info ]
5137 * [ AVP ]
5139 8.5. Aborting a Session
5141 A Diameter server may request that the access device stop providing
5142 service for a particular session by issuing an Abort-Session-Request
5143 (ASR).
5145 For example, the Diameter server that originally authorized the
5146 session may be required to cause that session to be stopped for lack
5147 of credit or other reasons that were not anticipated when the session
5148 was first authorized.
5150 An access device that receives an ASR with Session-ID equal to a
5151 currently active session MAY stop the session. Whether the access
5152 device stops the session or not is implementation- and/or
5153 configuration-dependent. For example, an access device may honor
5154 ASRs from certain agents only. In any case, the access device MUST
5155 respond with an Abort-Session-Answer, including a Result-Code AVP to
5156 indicate what action it took.
5158 8.5.1. Abort-Session-Request
5160 The Abort-Session-Request (ASR), indicated by the Command-Code set to
5161 274 and the message flags' 'R' bit set, may be sent by any Diameter
5162 server or any Diameter proxy to the access device that is providing
5163 session service, to request that the session identified by the
5164 Session-Id be stopped.
5166 Message Format
5168 ::= < Diameter Header: 274, REQ, PXY >
5169 < Session-Id >
5170 { Origin-Host }
5171 { Origin-Realm }
5172 { Destination-Realm }
5173 { Destination-Host }
5174 { Auth-Application-Id }
5175 [ User-Name ]
5176 [ Origin-State-Id ]
5177 * [ Proxy-Info ]
5178 * [ Route-Record ]
5179 * [ AVP ]
5181 8.5.2. Abort-Session-Answer
5183 The Abort-Session-Answer (ASA), indicated by the Command-Code set to
5184 274 and the message flags' 'R' bit clear, is sent in response to the
5185 ASR. The Result-Code AVP MUST be present, and indicates the
5186 disposition of the request.
5188 If the session identified by Session-Id in the ASR was successfully
5189 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
5190 is not currently active, Result-Code is set to
5191 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
5192 session for any other reason, Result-Code is set to
5193 DIAMETER_UNABLE_TO_COMPLY.
5195 Message Format
5197 ::= < Diameter Header: 274, PXY >
5198 < Session-Id >
5199 { Result-Code }
5200 { Origin-Host }
5201 { Origin-Realm }
5202 [ User-Name ]
5203 [ Origin-State-Id ]
5204 [ Error-Message ]
5205 [ Error-Reporting-Host ]
5206 [ Failed-AVP ]
5207 * [ Redirect-Host ]
5208 [ Redirect-Host-Usage ]
5209 [ Redirect-Max-Cache-Time ]
5210 * [ Proxy-Info ]
5211 * [ AVP ]
5213 8.6. Inferring Session Termination from Origin-State-Id
5215 The Origin-State-Id is used to allow detection of terminated sessions
5216 for which no STR would have been issued, due to unanticipated
5217 shutdown of an access device.
5219 A Diameter client or access device increments the value of the
5220 Origin-State-Id every time it is started or powered-up. The new
5221 Origin-State-Id is then sent in the CER/CEA message immediately upon
5222 connection to the server. The Diameter server receiving the new
5223 Origin-State-Id can determine whether the sending Diameter client had
5224 abruptly shutdown by comparing the old value of the Origin-State-Id
5225 it has kept for that specific client is less than the new value and
5226 whether it has un-terminated sessions originating from that client.
5228 An access device can also include the Origin-State-Id in request
5229 messages other than CER if there are relays or proxies in between the
5230 access device and the server. In this case, however, the server
5231 cannot discover that the access device has been restarted unless and
5232 until it receives a new request from it. Therefore this mechanism is
5233 more opportunistic across proxies and relays.
5235 The Diameter server may assume that all sessions that were active
5236 prior to detection of a client restart have been terminated. The
5237 Diameter server MAY clean up all session state associated with such
5238 lost sessions, and MAY also issues STRs for all such lost sessions
5239 that were authorized on upstream servers, to allow session state to
5240 be cleaned up globally.
5242 8.7. Auth-Request-Type AVP
5244 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
5245 included in application-specific auth requests to inform the peers
5246 whether a user is to be authenticated only, authorized only or both.
5247 Note any value other than both MAY cause RADIUS interoperability
5248 issues. The following values are defined:
5250 AUTHENTICATE_ONLY 1
5252 The request being sent is for authentication only, and MUST
5253 contain the relevant application specific authentication AVPs that
5254 are needed by the Diameter server to authenticate the user.
5256 AUTHORIZE_ONLY 2
5258 The request being sent is for authorization only, and MUST contain
5259 the application-specific authorization AVPs that are necessary to
5260 identify the service being requested/offered.
5262 AUTHORIZE_AUTHENTICATE 3
5264 The request contains a request for both authentication and
5265 authorization. The request MUST include both the relevant
5266 application-specific authentication information, and authorization
5267 information necessary to identify the service being requested/
5268 offered.
5270 8.8. Session-Id AVP
5272 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
5273 to identify a specific session (see Section 8). All messages
5274 pertaining to a specific session MUST include only one Session-Id AVP
5275 and the same value MUST be used throughout the life of a session.
5276 When present, the Session-Id SHOULD appear immediately following the
5277 Diameter Header (see Section 3).
5279 The Session-Id MUST be globally and eternally unique, as it is meant
5280 to uniquely identify a user session without reference to any other
5281 information, and may be needed to correlate historical authentication
5282 information with accounting information. The Session-Id includes a
5283 mandatory portion and an implementation-defined portion; a
5284 recommended format for the implementation-defined portion is outlined
5285 below.
5287 The Session-Id MUST begin with the sender's identity encoded in the
5288 DiameterIdentity type (see Section 4.3.1). The remainder of the
5289 Session-Id is delimited by a ";" character, and MAY be any sequence
5290 that the client can guarantee to be eternally unique; however, the
5291 following format is recommended, (square brackets [] indicate an
5292 optional element):
5294 ;;[;]
5296 and are decimal representations of the
5297 high and low 32 bits of a monotonically increasing 64-bit value. The
5298 64-bit value is rendered in two part to simplify formatting by 32-bit
5299 processors. At startup, the high 32 bits of the 64-bit value MAY be
5300 initialized to the time in NTP format [RFC5905], and the low 32 bits
5301 MAY be initialized to zero. This will for practical purposes
5302 eliminate the possibility of overlapping Session-Ids after a reboot,
5303 assuming the reboot process takes longer than a second.
5304 Alternatively, an implementation MAY keep track of the increasing
5305 value in non-volatile memory.
5307 is implementation specific but may include a modem's
5308 device Id, a layer 2 address, timestamp, etc.
5310 Example, in which there is no optional value:
5312 accesspoint7.example.com;1876543210;523
5314 Example, in which there is an optional value:
5316 accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
5318 The Session-Id is created by the Diameter application initiating the
5319 session, which in most cases is done by the client. Note that a
5320 Session-Id MAY be used for both the authentication, authorization and
5321 accounting commands of a given application.
5323 8.9. Authorization-Lifetime AVP
5325 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
5326 and contains the maximum number of seconds of service to be provided
5327 to the user before the user is to be re-authenticated and/or re-
5328 authorized. Care should be taken when the Authorization-Lifetime
5329 value is determined, since a low, non-zero, value could create
5330 significant Diameter traffic, which could congest both the network
5331 and the agents.
5333 A value of zero (0) means that immediate re-auth is necessary by the
5334 access device. The absence of this AVP, or a value of all ones
5335 (meaning all bits in the 32 bit field are set to one) means no re-
5336 auth is expected.
5338 If both this AVP and the Session-Timeout AVP are present in a
5339 message, the value of the latter MUST NOT be smaller than the
5340 Authorization-Lifetime AVP.
5342 An Authorization-Lifetime AVP MAY be present in re-authorization
5343 messages, and contains the number of seconds the user is authorized
5344 to receive service from the time the re-auth answer message is
5345 received by the access device.
5347 This AVP MAY be provided by the client as a hint of the maximum
5348 lifetime that it is willing to accept. The server MUST return a
5349 value that is equal to, or smaller, than the one provided by the
5350 client.
5352 8.10. Auth-Grace-Period AVP
5354 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
5355 contains the number of seconds the Diameter server will wait
5356 following the expiration of the Authorization-Lifetime AVP before
5357 cleaning up resources for the session.
5359 8.11. Auth-Session-State AVP
5361 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
5362 specifies whether state is maintained for a particular session. The
5363 client MAY include this AVP in requests as a hint to the server, but
5364 the value in the server's answer message is binding. The following
5365 values are supported:
5367 STATE_MAINTAINED 0
5369 This value is used to specify that session state is being
5370 maintained, and the access device MUST issue a session termination
5371 message when service to the user is terminated. This is the
5372 default value.
5374 NO_STATE_MAINTAINED 1
5376 This value is used to specify that no session termination messages
5377 will be sent by the access device upon expiration of the
5378 Authorization-Lifetime.
5380 8.12. Re-Auth-Request-Type AVP
5382 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
5383 is included in application-specific auth answers to inform the client
5384 of the action expected upon expiration of the Authorization-Lifetime.
5385 If the answer message contains an Authorization-Lifetime AVP with a
5386 positive value, the Re-Auth-Request-Type AVP MUST be present in an
5387 answer message. The following values are defined:
5389 AUTHORIZE_ONLY 0
5391 An authorization only re-auth is expected upon expiration of the
5392 Authorization-Lifetime. This is the default value if the AVP is
5393 not present in answer messages that include the Authorization-
5394 Lifetime.
5396 AUTHORIZE_AUTHENTICATE 1
5398 An authentication and authorization re-auth is expected upon
5399 expiration of the Authorization-Lifetime.
5401 8.13. Session-Timeout AVP
5403 The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32
5404 and contains the maximum number of seconds of service to be provided
5405 to the user before termination of the session. When both the
5406 Session-Timeout and the Authorization-Lifetime AVPs are present in an
5407 answer message, the former MUST be equal to or greater than the value
5408 of the latter.
5410 A session that terminates on an access device due to the expiration
5411 of the Session-Timeout MUST cause an STR to be issued, unless both
5412 the access device and the home server had previously agreed that no
5413 session termination messages would be sent (see Section 8).
5415 A Session-Timeout AVP MAY be present in a re-authorization answer
5416 message, and contains the remaining number of seconds from the
5417 beginning of the re-auth.
5419 A value of zero, or the absence of this AVP, means that this session
5420 has an unlimited number of seconds before termination.
5422 This AVP MAY be provided by the client as a hint of the maximum
5423 timeout that it is willing to accept. However, the server MAY return
5424 a value that is equal to, or smaller, than the one provided by the
5425 client.
5427 8.14. User-Name AVP
5429 The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which
5430 contains the User-Name, in a format consistent with the NAI
5431 specification [RFC4282].
5433 8.15. Termination-Cause AVP
5435 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
5436 is used to indicate the reason why a session was terminated on the
5437 access device. The following values are defined:
5439 DIAMETER_LOGOUT 1
5441 The user initiated a disconnect
5443 DIAMETER_SERVICE_NOT_PROVIDED 2
5445 This value is used when the user disconnected prior to the receipt
5446 of the authorization answer message.
5448 DIAMETER_BAD_ANSWER 3
5450 This value indicates that the authorization answer received by the
5451 access device was not processed successfully.
5453 DIAMETER_ADMINISTRATIVE 4
5455 The user was not granted access, or was disconnected, due to
5456 administrative reasons, such as the receipt of a Abort-Session-
5457 Request message.
5459 DIAMETER_LINK_BROKEN 5
5461 The communication to the user was abruptly disconnected.
5463 DIAMETER_AUTH_EXPIRED 6
5465 The user's access was terminated since its authorized session time
5466 has expired.
5468 DIAMETER_USER_MOVED 7
5470 The user is receiving services from another access device.
5472 DIAMETER_SESSION_TIMEOUT 8
5474 The user's session has timed out, and service has been terminated.
5476 8.16. Origin-State-Id AVP
5478 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a
5479 monotonically increasing value that is advanced whenever a Diameter
5480 entity restarts with loss of previous state, for example upon reboot.
5481 Origin-State-Id MAY be included in any Diameter message, including
5482 CER.
5484 A Diameter entity issuing this AVP MUST create a higher value for
5485 this AVP each time its state is reset. A Diameter entity MAY set
5486 Origin-State-Id to the time of startup, or it MAY use an incrementing
5487 counter retained in non-volatile memory across restarts.
5489 The Origin-State-Id, if present, MUST reflect the state of the entity
5490 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST
5491 either remove Origin-State-Id or modify it appropriately as well.
5492 Typically, Origin-State-Id is used by an access device that always
5493 starts up with no active sessions; that is, any session active prior
5494 to restart will have been lost. By including Origin-State-Id in a
5495 message, it allows other Diameter entities to infer that sessions
5496 associated with a lower Origin-State-Id are no longer active. If an
5497 access device does not intend for such inferences to be made, it MUST
5498 either not include Origin-State-Id in any message, or set its value
5499 to 0.
5501 8.17. Session-Binding AVP
5503 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
5504 be present in application-specific authorization answer messages. If
5505 present, this AVP MAY inform the Diameter client that all future
5506 application-specific re-auth and Session-Termination-Request messages
5507 for this session MUST be sent to the same authorization server.
5509 This field is a bit mask, and the following bits have been defined:
5511 RE_AUTH 1
5513 When set, future re-auth messages for this session MUST NOT
5514 include the Destination-Host AVP. When cleared, the default
5515 value, the Destination-Host AVP MUST be present in all re-auth
5516 messages for this session.
5518 STR 2
5520 When set, the STR message for this session MUST NOT include the
5521 Destination-Host AVP. When cleared, the default value, the
5522 Destination-Host AVP MUST be present in the STR message for this
5523 session.
5525 ACCOUNTING 4
5527 When set, all accounting messages for this session MUST NOT
5528 include the Destination-Host AVP. When cleared, the default
5529 value, the Destination-Host AVP, if known, MUST be present in all
5530 accounting messages for this session.
5532 8.18. Session-Server-Failover AVP
5534 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated,
5535 and MAY be present in application-specific authorization answer
5536 messages that either do not include the Session-Binding AVP or
5537 include the Session-Binding AVP with any of the bits set to a zero
5538 value. If present, this AVP MAY inform the Diameter client that if a
5539 re-auth or STR message fails due to a delivery problem, the Diameter
5540 client SHOULD issue a subsequent message without the Destination-Host
5541 AVP. When absent, the default value is REFUSE_SERVICE.
5543 The following values are supported:
5545 REFUSE_SERVICE 0
5547 If either the re-auth or the STR message delivery fails, terminate
5548 service with the user, and do not attempt any subsequent attempts.
5550 TRY_AGAIN 1
5552 If either the re-auth or the STR message delivery fails, resend
5553 the failed message without the Destination-Host AVP present.
5555 ALLOW_SERVICE 2
5557 If re-auth message delivery fails, assume that re-authorization
5558 succeeded. If STR message delivery fails, terminate the session.
5560 TRY_AGAIN_ALLOW_SERVICE 3
5562 If either the re-auth or the STR message delivery fails, resend
5563 the failed message without the Destination-Host AVP present. If
5564 the second delivery fails for re-auth, assume re-authorization
5565 succeeded. If the second delivery fails for STR, terminate the
5566 session.
5568 8.19. Multi-Round-Time-Out AVP
5570 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32,
5571 and SHOULD be present in application-specific authorization answer
5572 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
5573 This AVP contains the maximum number of seconds that the access
5574 device MUST provide the user in responding to an authentication
5575 request.
5577 8.20. Class AVP
5579 The Class AVP (AVP Code 25) is of type OctetString and is used by
5580 Diameter servers to return state information to the access device.
5581 When one or more Class AVPs are present in application-specific
5582 authorization answer messages, they MUST be present in subsequent re-
5583 authorization, session termination and accounting messages. Class
5584 AVPs found in a re-authorization answer message override the ones
5585 found in any previous authorization answer message. Diameter server
5586 implementations SHOULD NOT return Class AVPs that require more than
5587 4096 bytes of storage on the Diameter client. A Diameter client that
5588 receives Class AVPs whose size exceeds local available storage MUST
5589 terminate the session.
5591 8.21. Event-Timestamp AVP
5593 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be
5594 included in an Accounting-Request and Accounting-Answer messages to
5595 record the time that the reported event occurred, in seconds since
5596 January 1, 1900 00:00 UTC.
5598 9. Accounting
5600 This accounting protocol is based on a server directed model with
5601 capabilities for real-time delivery of accounting information.
5602 Several fault resilience methods [RFC2975] have been built in to the
5603 protocol in order minimize loss of accounting data in various fault
5604 situations and under different assumptions about the capabilities of
5605 the used devices.
5607 9.1. Server Directed Model
5609 The server directed model means that the device generating the
5610 accounting data gets information from either the authorization server
5611 (if contacted) or the accounting server regarding the way accounting
5612 data shall be forwarded. This information includes accounting record
5613 timeliness requirements.
5615 As discussed in [RFC2975], real-time transfer of accounting records
5616 is a requirement, such as the need to perform credit limit checks and
5617 fraud detection. Note that batch accounting is not a requirement,
5618 and is therefore not supported by Diameter. Should batched
5619 accounting be required in the future, a new Diameter application will
5620 need to be created, or it could be handled using another protocol.
5621 Note, however, that even if at the Diameter layer accounting requests
5622 are processed one by one, transport protocols used under Diameter
5623 typically batch several requests in the same packet under heavy
5624 traffic conditions. This may be sufficient for many applications.
5626 The authorization server (chain) directs the selection of proper
5627 transfer strategy, based on its knowledge of the user and
5628 relationships of roaming partnerships. The server (or agents) uses
5629 the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
5630 control the operation of the Diameter peer operating as a client.
5631 The Acct-Interim-Interval AVP, when present, instructs the Diameter
5632 node acting as a client to produce accounting records continuously
5633 even during a session. Accounting-Realtime-Required AVP is used to
5634 control the behavior of the client when the transfer of accounting
5635 records from the Diameter client is delayed or unsuccessful.
5637 The Diameter accounting server MAY override the interim interval or
5638 the realtime requirements by including the Acct-Interim-Interval or
5639 Accounting-Realtime-Required AVP in the Accounting-Answer message.
5640 When one of these AVPs is present, the latest value received SHOULD
5641 be used in further accounting activities for the same session.
5643 9.2. Protocol Messages
5645 A Diameter node that receives a successful authentication and/or
5646 authorization messages from the Diameter server SHOULD collect
5647 accounting information for the session. The Accounting-Request
5648 message is used to transmit the accounting information to the
5649 Diameter server, which MUST reply with the Accounting-Answer message
5650 to confirm reception. The Accounting-Answer message includes the
5651 Result-Code AVP, which MAY indicate that an error was present in the
5652 accounting message. The value of the Accounting-Realtime-Required
5653 AVP received earlier for the session in question may indicate that
5654 the user's session has to be terminated when a rejected Accounting-
5655 Request message was received.
5657 9.3. Accounting Application Extension and Requirements
5659 Each Diameter application (e.g., NASREQ, MobileIP), SHOULD define
5660 their Service-Specific AVPs that MUST be present in the Accounting-
5661 Request message in a section entitled "Accounting AVPs". The
5662 application MUST assume that the AVPs described in this document will
5663 be present in all Accounting messages, so only their respective
5664 service-specific AVPs need to be defined in that section.
5666 Applications have the option of using one or both of the following
5667 accounting application extension models:
5669 Split Accounting Service
5671 The accounting message will carry the Application Id of the
5672 Diameter base accounting application (see Section 2.4).
5673 Accounting messages may be routed to Diameter nodes other than the
5674 corresponding Diameter application. These nodes might be
5675 centralized accounting servers that provide accounting service for
5676 multiple different Diameter applications. These nodes MUST
5677 advertise the Diameter base accounting Application Id during
5678 capabilities exchange.
5680 Coupled Accounting Service
5682 The accounting messages will carry the Application Id of the
5683 application that is using it. The application itself will process
5684 the received accounting records or forward them to an accounting
5685 server. There is no accounting application advertisement required
5686 during capabilities exchange and the accounting messages will be
5687 routed the same as any of the other application messages.
5689 In cases where an application does not define its own accounting
5690 service, it is preferred that the split accounting model be used.
5692 9.4. Fault Resilience
5694 Diameter Base protocol mechanisms are used to overcome small message
5695 loss and network faults of temporary nature.
5697 Diameter peers acting as clients MUST implement the use of failover
5698 to guard against server failures and certain network failures.
5699 Diameter peers acting as agents or related off-line processing
5700 systems MUST detect duplicate accounting records caused by the
5701 sending of the same record to several servers and duplication of
5702 messages in transit. This detection MUST be based on the inspection
5703 of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C
5704 discusses duplicate detection needs and implementation issues.
5706 Diameter clients MAY have non-volatile memory for the safe storage of
5707 accounting records over reboots or extended network failures, network
5708 partitions, and server failures. If such memory is available, the
5709 client SHOULD store new accounting records there as soon as the
5710 records are created and until a positive acknowledgement of their
5711 reception from the Diameter Server has been received. Upon a reboot,
5712 the client MUST starting sending the records in the non-volatile
5713 memory to the accounting server with appropriate modifications in
5714 termination cause, session length, and other relevant information in
5715 the records.
5717 A further application of this protocol may include AVPs to control
5718 how many accounting records may at most be stored in the Diameter
5719 client without committing them to the non-volatile memory or
5720 transferring them to the Diameter server.
5722 The client SHOULD NOT remove the accounting data from any of its
5723 memory areas before the correct Accounting-Answer has been received.
5724 The client MAY remove oldest, undelivered or yet unacknowledged
5725 accounting data if it runs out of resources such as memory. It is an
5726 implementation dependent matter for the client to accept new sessions
5727 under this condition.
5729 9.5. Accounting Records
5731 In all accounting records, the Session-Id AVP MUST be present; the
5732 User-Name AVP MUST be present if it is available to the Diameter
5733 client.
5735 Different types of accounting records are sent depending on the
5736 actual type of accounted service and the authorization server's
5737 directions for interim accounting. If the accounted service is a
5738 one-time event, meaning that the start and stop of the event are
5739 simultaneous, then the Accounting-Record-Type AVP MUST be present and
5740 set to the value EVENT_RECORD.
5742 If the accounted service is of a measurable length, then the AVP MUST
5743 use the values START_RECORD, STOP_RECORD, and possibly,
5744 INTERIM_RECORD. If the authorization server has not directed interim
5745 accounting to be enabled for the session, two accounting records MUST
5746 be generated for each service of type session. When the initial
5747 Accounting-Request for a given session is sent, the Accounting-
5748 Record-Type AVP MUST be set to the value START_RECORD. When the last
5749 Accounting-Request is sent, the value MUST be STOP_RECORD.
5751 If the authorization server has directed interim accounting to be
5752 enabled, the Diameter client MUST produce additional records between
5753 the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
5754 production of these records is directed by Acct-Interim-Interval as
5755 well as any re-authentication or re-authorization of the session.
5756 The Diameter client MUST overwrite any previous interim accounting
5757 records that are locally stored for delivery, if a new record is
5758 being generated for the same session. This ensures that only one
5759 pending interim record can exist on an access device for any given
5760 session.
5762 A particular value of Accounting-Sub-Session-Id MUST appear only in
5763 one sequence of accounting records from a Diameter client, except for
5764 the purposes of retransmission. The one sequence that is sent MUST
5765 be either one record with Accounting-Record-Type AVP set to the value
5766 EVENT_RECORD, or several records starting with one having the value
5767 START_RECORD, followed by zero or more INTERIM_RECORD and a single
5768 STOP_RECORD. A particular Diameter application specification MUST
5769 define the type of sequences that MUST be used.
5771 9.6. Correlation of Accounting Records
5773 If an application uses accounting messages, it can correlate
5774 accounting records with a specific application session by using the
5775 Session-Id of the particular application session in the accounting
5776 messages. Accounting messages MAY also use a different Session-Id
5777 from that of the application sessions in which case other session
5778 related information is needed to perform correlation.
5780 In cases where an application requires multiple accounting sub-
5781 session, an Accounting-Sub-Session-Id AVP is used to differentiate
5782 each sub-session. The Session-Id would remain constant for all sub-
5783 sessions and is be used to correlate all the sub-sessions to a
5784 particular application session. Note that receiving a STOP_RECORD
5785 with no Accounting-Sub-Session-Id AVP when sub-sessions were
5786 originally used in the START_RECORD messages implies that all sub-
5787 sessions are terminated.
5789 There are also cases where an application needs to correlate multiple
5790 application sessions into a single accounting record; the accounting
5791 record may span multiple different Diameter applications and sessions
5792 used by the same user at a given time. In such cases, the Acct-
5793 Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD
5794 be signaled by the server to the access device (typically during
5795 authorization) when it determines that a request belongs to an
5796 existing session. The access device MUST then include the Acct-
5797 Multi-Session-Id AVP in all subsequent accounting messages.
5799 The Acct-Multi-Session-Id AVP MAY include the value of the original
5800 Session-Id. It's contents are implementation specific, but MUST be
5801 globally unique across other Acct-Multi-Session-Id, and MUST NOT
5802 change during the life of a session.
5804 A Diameter application document MUST define the exact concept of a
5805 session that is being accounted, and MAY define the concept of a
5806 multi-session. For instance, the NASREQ DIAMETER application treats
5807 a single PPP connection to a Network Access Server as one session,
5808 and a set of Multilink PPP sessions as one multi-session.
5810 9.7. Accounting Command-Codes
5812 This section defines Command-Code values that MUST be supported by
5813 all Diameter implementations that provide Accounting services.
5815 9.7.1. Accounting-Request
5817 The Accounting-Request (ACR) command, indicated by the Command-Code
5818 field set to 271 and the Command Flags' 'R' bit set, is sent by a
5819 Diameter node, acting as a client, in order to exchange accounting
5820 information with a peer.
5822 In addition to the AVPs listed below, Accounting-Request messages
5823 SHOULD include service-specific accounting AVPs.
5825 Message Format
5827 ::= < Diameter Header: 271, REQ, PXY >
5828 < Session-Id >
5829 { Origin-Host }
5830 { Origin-Realm }
5831 { Destination-Realm }
5832 { Accounting-Record-Type }
5833 { Accounting-Record-Number }
5834 [ Acct-Application-Id ]
5835 [ Vendor-Specific-Application-Id ]
5836 [ User-Name ]
5837 [ Destination-Host ]
5838 [ Accounting-Sub-Session-Id ]
5839 [ Acct-Session-Id ]
5840 [ Acct-Multi-Session-Id ]
5841 [ Acct-Interim-Interval ]
5842 [ Accounting-Realtime-Required ]
5843 [ Origin-State-Id ]
5844 [ Event-Timestamp ]
5845 * [ Proxy-Info ]
5846 * [ Route-Record ]
5847 * [ AVP ]
5849 9.7.2. Accounting-Answer
5851 The Accounting-Answer (ACA) command, indicated by the Command-Code
5852 field set to 271 and the Command Flags' 'R' bit cleared, is used to
5853 acknowledge an Accounting-Request command. The Accounting-Answer
5854 command contains the same Session-Id as the corresponding request.
5856 Only the target Diameter Server, known as the home Diameter Server,
5857 SHOULD respond with the Accounting-Answer command.
5859 In addition to the AVPs listed below, Accounting-Answer messages
5860 SHOULD include service-specific accounting AVPs.
5862 Message Format
5864 ::= < Diameter Header: 271, PXY >
5865 < Session-Id >
5866 { Result-Code }
5867 { Origin-Host }
5868 { Origin-Realm }
5869 { Accounting-Record-Type }
5870 { Accounting-Record-Number }
5871 [ Acct-Application-Id ]
5872 [ Vendor-Specific-Application-Id ]
5873 [ User-Name ]
5874 [ Accounting-Sub-Session-Id ]
5875 [ Acct-Session-Id ]
5876 [ Acct-Multi-Session-Id ]
5877 [ Error-Message ]
5878 [ Error-Reporting-Host ]
5879 [ Failed-AVP ]
5880 [ Acct-Interim-Interval ]
5881 [ Accounting-Realtime-Required ]
5882 [ Origin-State-Id ]
5883 [ Event-Timestamp ]
5884 * [ Proxy-Info ]
5885 * [ AVP ]
5887 9.8. Accounting AVPs
5889 This section contains AVPs that describe accounting usage information
5890 related to a specific session.
5892 9.8.1. Accounting-Record-Type AVP
5894 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
5895 and contains the type of accounting record being sent. The following
5896 values are currently defined for the Accounting-Record-Type AVP:
5898 EVENT_RECORD 1
5900 An Accounting Event Record is used to indicate that a one-time
5901 event has occurred (meaning that the start and end of the event
5902 are simultaneous). This record contains all information relevant
5903 to the service, and is the only record of the service.
5905 START_RECORD 2
5907 An Accounting Start, Interim, and Stop Records are used to
5908 indicate that a service of a measurable length has been given. An
5909 Accounting Start Record is used to initiate an accounting session,
5910 and contains accounting information that is relevant to the
5911 initiation of the session.
5913 INTERIM_RECORD 3
5915 An Interim Accounting Record contains cumulative accounting
5916 information for an existing accounting session. Interim
5917 Accounting Records SHOULD be sent every time a re-authentication
5918 or re-authorization occurs. Further, additional interim record
5919 triggers MAY be defined by application-specific Diameter
5920 applications. The selection of whether to use INTERIM_RECORD
5921 records is done by the Acct-Interim-Interval AVP.
5923 STOP_RECORD 4
5925 An Accounting Stop Record is sent to terminate an accounting
5926 session and contains cumulative accounting information relevant to
5927 the existing session.
5929 9.8.2. Acct-Interim-Interval AVP
5931 The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
5932 is sent from the Diameter home authorization server to the Diameter
5933 client. The client uses information in this AVP to decide how and
5934 when to produce accounting records. With different values in this
5935 AVP, service sessions can result in one, two, or two+N accounting
5936 records, based on the needs of the home-organization. The following
5937 accounting record production behavior is directed by the inclusion of
5938 this AVP:
5940 1. The omission of the Acct-Interim-Interval AVP or its inclusion
5941 with Value field set to 0 means that EVENT_RECORD, START_RECORD,
5942 and STOP_RECORD are produced, as appropriate for the service.
5944 2. The inclusion of the AVP with Value field set to a non-zero value
5945 means that INTERIM_RECORD records MUST be produced between the
5946 START_RECORD and STOP_RECORD records. The Value field of this
5947 AVP is the nominal interval between these records in seconds.
5949 The Diameter node that originates the accounting information,
5950 known as the client, MUST produce the first INTERIM_RECORD record
5951 roughly at the time when this nominal interval has elapsed from
5952 the START_RECORD, the next one again as the interval has elapsed
5953 once more, and so on until the session ends and a STOP_RECORD
5954 record is produced.
5956 The client MUST ensure that the interim record production times
5957 are randomized so that large accounting message storms are not
5958 created either among records or around a common service start
5959 time.
5961 9.8.3. Accounting-Record-Number AVP
5963 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
5964 and identifies this record within one session. As Session-Id AVPs
5965 are globally unique, the combination of Session-Id and Accounting-
5966 Record-Number AVPs is also globally unique, and can be used in
5967 matching accounting records with confirmations. An easy way to
5968 produce unique numbers is to set the value to 0 for records of type
5969 EVENT_RECORD and START_RECORD, and set the value to 1 for the first
5970 INTERIM_RECORD, 2 for the second, and so on until the value for
5971 STOP_RECORD is one more than for the last INTERIM_RECORD.
5973 9.8.4. Acct-Session-Id AVP
5975 The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only
5976 used when RADIUS/Diameter translation occurs. This AVP contains the
5977 contents of the RADIUS Acct-Session-Id attribute.
5979 9.8.5. Acct-Multi-Session-Id AVP
5981 The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
5982 following the format specified in Section 8.8. The Acct-Multi-
5983 Session-Id AVP is used to link together multiple related accounting
5984 sessions, where each session would have a unique Session-Id, but the
5985 same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the
5986 Diameter server in an authorization answer, and MUST be used in all
5987 accounting messages for the given session.
5989 9.8.6. Accounting-Sub-Session-Id AVP
5991 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
5992 Unsigned64 and contains the accounting sub-session identifier. The
5993 combination of the Session-Id and this AVP MUST be unique per sub-
5994 session, and the value of this AVP MUST be monotonically increased by
5995 one for all new sub-sessions. The absence of this AVP implies no
5996 sub-sessions are in use, with the exception of an Accounting-Request
5997 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
5998 message with no Accounting-Sub-Session-Id AVP present will signal the
5999 termination of all sub-sessions for a given Session-Id.
6001 9.8.7. Accounting-Realtime-Required AVP
6003 The Accounting-Realtime-Required AVP (AVP Code 483) is of type
6004 Enumerated and is sent from the Diameter home authorization server to
6005 the Diameter client or in the Accounting-Answer from the accounting
6006 server. The client uses information in this AVP to decide what to do
6007 if the sending of accounting records to the accounting server has
6008 been temporarily prevented due to, for instance, a network problem.
6010 DELIVER_AND_GRANT 1
6012 The AVP with Value field set to DELIVER_AND_GRANT means that the
6013 service MUST only be granted as long as there is a connection to
6014 an accounting server. Note that the set of alternative accounting
6015 servers are treated as one server in this sense. Having to move
6016 the accounting record stream to a backup server is not a reason to
6017 discontinue the service to the user.
6019 GRANT_AND_STORE 2
6021 The AVP with Value field set to GRANT_AND_STORE means that service
6022 SHOULD be granted if there is a connection, or as long as records
6023 can still be stored as described in Section 9.4.
6025 This is the default behavior if the AVP isn't included in the
6026 reply from the authorization server.
6028 GRANT_AND_LOSE 3
6030 The AVP with Value field set to GRANT_AND_LOSE means that service
6031 SHOULD be granted even if the records cannot be delivered or
6032 stored.
6034 10. AVP Occurrence Tables
6036 The following tables presents the AVPs defined in this document, and
6037 specifies in which Diameter messages they MAY be present or not.
6038 AVPs that occur only inside a Grouped AVP are not shown in this
6039 table.
6041 The table uses the following symbols:
6043 0 The AVP MUST NOT be present in the message.
6045 0+ Zero or more instances of the AVP MAY be present in the
6046 message.
6048 0-1 Zero or one instance of the AVP MAY be present in the message.
6049 It is considered an error if there are more than one instance of
6050 the AVP.
6052 1 One instance of the AVP MUST be present in the message.
6054 1+ At least one instance of the AVP MUST be present in the
6055 message.
6057 10.1. Base Protocol Command AVP Table
6059 The table in this section is limited to the non-accounting Command
6060 Codes defined in this specification.
6062 +-----------------------------------------------+
6063 | Command-Code |
6064 +---+---+---+---+---+---+---+---+---+---+---+---+
6065 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
6066 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
6067 Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
6068 Interval | | | | | | | | | | | | |
6069 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
6070 Required | | | | | | | | | | | | |
6071 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6072 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
6073 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6074 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6075 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6076 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6077 Lifetime | | | | | | | | | | | | |
6078 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
6079 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
6080 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
6081 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6082 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
6083 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6084 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |
6085 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6086 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6087 Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6088 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6089 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
6090 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
6091 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|
6092 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6093 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
6094 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
6095 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6096 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6097 Time | | | | | | | | | | | | |
6098 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
6099 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
6100 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
6101 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6102 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
6103 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6104 Failover | | | | | | | | | | | | |
6105 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6106 Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6107 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
6108 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
6109 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6110 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6111 Application-Id | | | | | | | | | | | | |
6112 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
6114 10.2. Accounting AVP Table
6116 The table in this section is used to represent which AVPs defined in
6117 this document are to be present in the Accounting messages. These
6118 AVP occurrence requirements are guidelines, which may be expanded,
6119 and/or overridden by application-specific requirements in the
6120 Diameter applications documents.
6122 +-----------+
6123 | Command |
6124 | Code |
6125 +-----+-----+
6126 Attribute Name | ACR | ACA |
6127 ------------------------------+-----+-----+
6128 Acct-Interim-Interval | 0-1 | 0-1 |
6129 Acct-Multi-Session-Id | 0-1 | 0-1 |
6130 Accounting-Record-Number | 1 | 1 |
6131 Accounting-Record-Type | 1 | 1 |
6132 Acct-Session-Id | 0-1 | 0-1 |
6133 Accounting-Sub-Session-Id | 0-1 | 0-1 |
6134 Accounting-Realtime-Required | 0-1 | 0-1 |
6135 Acct-Application-Id | 0-1 | 0-1 |
6136 Auth-Application-Id | 0 | 0 |
6137 Class | 0+ | 0+ |
6138 Destination-Host | 0-1 | 0 |
6139 Destination-Realm | 1 | 0 |
6140 Error-Reporting-Host | 0 | 0+ |
6141 Event-Timestamp | 0-1 | 0-1 |
6142 Origin-Host | 1 | 1 |
6143 Origin-Realm | 1 | 1 |
6144 Proxy-Info | 0+ | 0+ |
6145 Route-Record | 0+ | 0 |
6146 Result-Code | 0 | 1 |
6147 Session-Id | 1 | 1 |
6148 Termination-Cause | 0 | 0 |
6149 User-Name | 0-1 | 0-1 |
6150 Vendor-Specific-Application-Id| 0-1 | 0-1 |
6151 ------------------------------+-----+-----+
6153 11. IANA Considerations
6155 This section provides guidance to the Internet Assigned Numbers
6156 Authority (IANA) regarding registration of values related to the
6157 Diameter protocol, in accordance with [RFC5226]. Existing IANA
6158 registries and assignments put in place by [RFC3588] remain the same
6159 unless explicitly updated or deprecated in this section.
6161 11.1. AVP Header
6163 As defined in Section 4, the AVP header contains three fields that
6164 requires IANA namespace management; the AVP Code, Vendor-ID and Flags
6165 field.
6167 11.1.1. AVP Codes
6169 There are multiple namespaces. Vendors can have their own AVP Codes
6170 namespace which will be identified by their Vendor-ID (also known as
6171 Enterprise-Number) and they control the assignments of their vendor-
6172 specific AVP codes within their own namespace. The absence of a
6173 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
6174 controlled AVP Codes namespace. The AVP Codes and sometimes also
6175 possible values in an AVP are controlled and maintained by IANA. AVP
6176 Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS
6177 Attribute Types. Where a Vendor-Specific AVP is implemented by more
6178 than one vendor, allocation of global AVPs should be encouraged
6179 instead.
6181 AVPs may be allocated following Expert Review (or Designated Expert)
6182 with Specification Required [RFC5226]. A block allocation (release
6183 of more than 3 AVPs at a time for a given purpose) requires IETF
6184 Review.
6186 11.1.2. AVP Flags
6188 Section 4.1 describes the existing AVP Flags. The remaining bits can
6189 only be assigned via a Standards Action [RFC5226].
6191 11.2. Diameter Header
6193 11.2.1. Command Codes
6195 For the Diameter Header, the command code namespace allocation has
6196 changed. The new allocation rules are as follows:
6198 The command code values 256 - 8,388,607 (0x100 to 0x7fffff) are
6199 for permanent, standard commands, allocated by IETF Review
6200 [RFC5226].
6202 The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are
6203 reserved for vendor-specific command codes, to be allocated on a
6204 First Come, First Served basis by IANA [RFC5226]. The request to
6205 IANA for a Vendor-Specific Command Code SHOULD include a reference
6206 to a publicly available specification which documents the command
6207 in sufficient detail to aid in interoperability between
6208 independent implementations. If the specification cannot be made
6209 publicly available, the request for a vendor-specific command code
6210 MUST include the contact information of persons and/or entities
6211 responsible for authoring and maintaining the command.
6213 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe
6214 - 0xffffff) are reserved for experimental commands. As these
6215 codes are only for experimental and testing purposes, no guarantee
6216 is made for interoperability between Diameter peers using
6217 experimental commands.
6219 11.2.2. Command Flags
6221 Section 3 describes the existing Command Flag field. The remaining
6222 bits can only be assigned via a Standards Action [RFC5226].
6224 11.3. AVP Values
6226 For AVP values, the Experimental-Result-Code AVP value allocation has
6227 been added, see Section 11.3.1. The old AVP value allocation rule
6228 IETF Consensus has been updated to IETF Review as per [RFC5226] and
6229 affected AVPs are listed as reminders.
6231 11.3.1. Experimental-Result-Code AVP
6233 Values for this AVP are purely local to the indicated vendor, and no
6234 IANA registry is maintained for them.
6236 11.3.2. Result-Code AVP Values
6238 New values are available for assignment via IETF Review [RFC5226].
6240 11.3.3. Accounting-Record-Type AVP Values
6242 New values are available for assignment via IETF Review [RFC5226].
6244 11.3.4. Termination-Cause AVP Values
6246 New values are available for assignment via IETF Review [RFC5226].
6248 11.3.5. Redirect-Host-Usage AVP Values
6250 New values are available for assignment via IETF Review [RFC5226].
6252 11.3.6. Session-Server-Failover AVP Values
6254 New values are available for assignment via IETF Review [RFC5226].
6256 11.3.7. Session-Binding AVP Values
6258 New values are available for assignment via IETF Review [RFC5226].
6260 11.3.8. Disconnect-Cause AVP Values
6262 New values are available for assignment via IETF Review [RFC5226].
6264 11.3.9. Auth-Request-Type AVP Values
6266 New values are available for assignment via IETF Review [RFC5226].
6268 11.3.10. Auth-Session-State AVP Values
6270 New values are available for assignment via IETF Review [RFC5226].
6272 11.3.11. Re-Auth-Request-Type AVP Values
6274 New values are available for assignment via IETF Review [RFC5226].
6276 11.3.12. Accounting-Realtime-Required AVP Values
6278 New values are available for assignment via IETF Review [RFC5226].
6280 11.3.13. Inband-Security-Id AVP (code 299)
6282 The use of this AVP has been deprecated.
6284 11.4. _diameter Service Name and Port Number Registration
6286 This section requests the IANA to register the "_diameter" service
6287 name and assign port numbers for TLS/TCP and DTLS/SCTP according to
6288 the guidelines given in Cotton, et al. [RFC6335].
6290 Service Name: _diameter
6292 Transport Protocols: TCP, SCTP
6294 Assignee: IESG
6296 Contact: IETF Chair
6298 Description: Diameter over TLS/TCP and DTLS/SCTP
6300 Reference: draft-ietf-dime-rfc3588bis
6302 Port Number: TBD, from the User Range
6304 11.5. SCTP Payload Protocol Identifiers
6306 Two SCTP payload protocol identifiers are registered in SCTP Payload
6307 Protocol Identifier registry:
6309 Value | SCTP Payload Protocol Identifier
6310 --------|-----------------------------------
6311 TBD2 | Diameter in a SCTP DATA chunk
6312 TBD3 | Diameter in a DTLS/SCTP DATA chunk
6314 11.6. S-NAPTR Parameters
6316 This document also registers the following S-NAPTR Application
6317 Protocol Tags registry:
6319 Tag | Protocol
6320 -------------------|---------
6321 diameter.dtls.sctp | DTLS/SCTP
6323 12. Diameter Protocol-related Configurable Parameters
6325 This section contains the configurable parameters that are found
6326 throughout this document:
6328 Diameter Peer
6330 A Diameter entity MAY communicate with peers that are statically
6331 configured. A statically configured Diameter peer would require
6332 that either the IP address or the fully qualified domain name
6333 (FQDN) be supplied, which would then be used to resolve through
6334 DNS.
6336 Routing Table
6338 A Diameter proxy server routes messages based on the realm portion
6339 of a Network Access Identifier (NAI). The server MUST have a
6340 table of Realm Names, and the address of the peer to which the
6341 message must be forwarded to. The routing table MAY also include
6342 a "default route", which is typically used for all messages that
6343 cannot be locally processed.
6345 Tc timer
6347 The Tc timer controls the frequency that transport connection
6348 attempts are done to a peer with whom no active transport
6349 connection exists. The recommended value is 30 seconds.
6351 13. Security Considerations
6353 The Diameter base protocol messages SHOULD be secured by using TLS
6354 [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms
6355 such as IPsec [RFC4301] MAY also be deployed to secure connections
6356 between peers. However, all Diameter base protocol implementations
6357 MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter
6358 protocol MUST NOT be used without one of TLS, DTLS or IPsec.
6360 If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP
6361 or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior
6362 to any Diameter message exchange. All security parameters for TLS/
6363 TCP and DTLS/SCTP or IPsec are configured independent of the Diameter
6364 protocol. All Diameter messages will be sent through the TLS/TCP and
6365 DTLS/SCTP or IPsec connection after a successful setup.
6367 For TLS/TCP and DTLS/SCTP connections to be established in the open
6368 state, the CER/CEA exchange MUST include an Inband-Security-ID AVP
6369 with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP
6370 handshake will begin when both ends successfully reached the open
6371 state, after completion of the CER/CEA exchange. If the TLS/TCP and
6372 DTLS/SCTP handshake is successful, all further messages will be sent
6373 via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST
6374 move to the closed state. See Section 13.1 for more details.
6376 13.1. TLS/TCP and DTLS/SCTP Usage
6378 Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually
6379 authenticate as part of TLS/TCP and DTLS/SCTP session establishment.
6380 In order to ensure mutual authentication, the Diameter node acting as
6381 the TLS/TCP and DTLS/SCTP server MUST request a certificate from the
6382 Diameter node acting as TLS/TCP and DTLS/SCTP client, and the
6383 Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be
6384 prepared to supply a certificate on request.
6386 Diameter nodes MUST be able to negotiate the following TLS/TCP and
6387 DTLS/SCTP cipher suites:
6389 TLS_RSA_WITH_RC4_128_MD5
6390 TLS_RSA_WITH_RC4_128_SHA
6391 TLS_RSA_WITH_3DES_EDE_CBC_SHA
6393 Diameter nodes SHOULD be able to negotiate the following TLS/TCP and
6394 DTLS/SCTP cipher suite:
6396 TLS_RSA_WITH_AES_128_CBC_SHA
6398 Note that that it is quite possible that support for the
6399 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite will be REQUIRED at some
6400 future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/
6401 SCTP cipher suites.
6403 13.2. Peer-to-Peer Considerations
6405 As with any peer-to-peer protocol, proper configuration of the trust
6406 model within a Diameter peer is essential to security. When
6407 certificates are used, it is necessary to configure the root
6408 certificate authorities trusted by the Diameter peer. These root CAs
6409 are likely to be unique to Diameter usage and distinct from the root
6410 CAs that might be trusted for other purposes such as Web browsing.
6411 In general, it is expected that those root CAs will be configured so
6412 as to reflect the business relationships between the organization
6413 hosting the Diameter peer and other organizations. As a result, a
6414 Diameter peer will typically not be configured to allow connectivity
6415 with any arbitrary peer. With certificate authentication, Diameter
6416 peers may not be known beforehand and therefore peer discovery may be
6417 required.
6419 13.3. AVP Considerations
6421 Diameter AVPs often contain security-sensitive data; for example,
6422 user passwords and location data, network addresses and cryptographic
6423 keys. The Diameter messages containing such AVPs MUST only be sent
6424 protected via mutually authenticated TLS or IPsec. In addition,
6425 those messages SHOULD NOT be sent via intermediate nodes that would
6426 expose the sensitive data at those nodes except in cases where an
6427 intermediary is known to be operated as part of the same
6428 administrative domain as the endpoints so that an ability to
6429 successfully compromise the intermediary would imply a high
6430 probability of being able to compromise the endpoints as well.
6432 14. References
6434 14.1. Normative References
6436 [FLOATPOINT]
6437 Institute of Electrical and Electronics Engineers, "IEEE
6438 Standard for Binary Floating-Point Arithmetic, ANSI/IEEE
6439 Standard 754-1985", August 1985.
6441 [IANAADFAM]
6442 IANA,, "Address Family Numbers",
6443 http://www.iana.org/assignments/address-family-numbers.
6445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6446 Requirement Levels", BCP 14, RFC 2119, March 1997.
6448 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
6449 for Internationalized Domain Names in Applications
6450 (IDNA)", RFC 3492, March 2003.
6452 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
6453 Accounting (AAA) Transport Profile", RFC 3539, June 2003.
6455 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
6456 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
6458 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
6459 10646", STD 63, RFC 3629, November 2003.
6461 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
6462 Service Location Using SRV RRs and the Dynamic Delegation
6463 Discovery Service (DDDS)", RFC 3958, January 2005.
6465 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6466 Resource Identifier (URI): Generic Syntax", STD 66,
6467 RFC 3986, January 2005.
6469 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
6470 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
6471 August 2005.
6473 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
6474 "Diameter Network Access Server Application", RFC 4005,
6475 August 2005.
6477 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
6478 Loughney, "Diameter Credit-Control Application", RFC 4006,
6479 August 2005.
6481 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
6482 Requirements for Security", BCP 106, RFC 4086, June 2005.
6484 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
6485 Network Access Identifier", RFC 4282, December 2005.
6487 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
6488 Architecture", RFC 4291, February 2006.
6490 [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
6491 RFC 4960, September 2007.
6493 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
6494 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
6495 May 2008.
6497 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
6498 Specifications: ABNF", STD 68, RFC 5234, January 2008.
6500 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
6501 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
6503 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
6504 Housley, R., and W. Polk, "Internet X.509 Public Key
6505 Infrastructure Certificate and Certificate Revocation List
6506 (CRL) Profile", RFC 5280, May 2008.
6508 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou,
6509 "Clarifications on the Routing of Diameter Requests Based
6510 on the Username and the Realm", RFC 5729, December 2009.
6512 [RFC5890] Klensin, J., "Internationalized Domain Names for
6513 Applications (IDNA): Definitions and Document Framework",
6514 RFC 5890, August 2010.
6516 [RFC5891] Klensin, J., "Internationalized Domain Names in
6517 Applications (IDNA): Protocol", RFC 5891, August 2010.
6519 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
6520 Transport Layer Security (DTLS) for Stream Control
6521 Transmission Protocol (SCTP)", RFC 6083, January 2011.
6523 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
6524 Security Version 1.2", RFC 6347, January 2012.
6526 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter
6527 Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
6528 RFC 6408, November 2011.
6530 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
6532 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
6533 January 1981.
6535 14.2. Informational References
6537 [ENTERPRISE]
6538 IANA, "SMI Network Management Private Enterprise Codes",
6539 http://www.iana.org/assignments/enterprise-numbers.
6541 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
6542 TACACS", RFC 1492, July 1993.
6544 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
6545 RFC 1661, July 1994.
6547 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
6548 Hashing for Message Authentication", RFC 2104,
6549 February 1997.
6551 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
6552 specifying the location of services (DNS SRV)", RFC 2782,
6553 February 2000.
6555 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
6556 "Remote Authentication Dial In User Service (RADIUS)",
6557 RFC 2865, June 2000.
6559 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
6561 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
6562 Extensions", RFC 2869, June 2000.
6564 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
6565 Accounting Management", RFC 2975, October 2000.
6567 [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
6568 Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C.,
6569 Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X.,
6570 Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim,
6571 B., Hirschman, B., Hsu, R., Koo, H., Lipford, M.,
6572 Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria
6573 for Evaluating AAA Protocols for Network Access",
6574 RFC 2989, November 2000.
6576 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
6577 RFC 3162, August 2001.
6579 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
6580 Levkowetz, "Extensible Authentication Protocol (EAP)",
6581 RFC 3748, June 2004.
6583 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
6584 Internet Protocol", RFC 4301, December 2005.
6586 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
6587 Recommendations for Internationalized Domain Names
6588 (IDNs)", RFC 4690, September 2006.
6590 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
6591 Aboba, "Dynamic Authorization Extensions to Remote
6592 Authentication Dial In User Service (RADIUS)", RFC 5176,
6593 January 2008.
6595 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
6596 February 2009.
6598 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
6599 Time Protocol Version 4: Protocol and Algorithms
6600 Specification", RFC 5905, June 2010.
6602 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
6604 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
6605 Cheshire, "Internet Assigned Numbers Authority (IANA)
6606 Procedures for the Management of the Service Name and
6607 Transport Protocol Port Number Registry", BCP 165,
6608 RFC 6335, August 2011.
6610 Appendix A. Acknowledgements
6612 A.1. RFC3588bis
6614 The authors would like to thank the following people that have
6615 provided proposals and contributions to this document:
6617 To Vishnu Ram and Satendra Gera for their contributions on
6618 Capabilities Updates, and Predictive Loop Avoidance as well as many
6619 other technical proposals. To Tolga Asveren for his insights and
6620 contributions on almost all of the proposed solutions incorporated
6621 into this document. To Timothy Smith for helping on the Capabilities
6622 Update and other topics. To Tony Zhang for providing fixes to loop
6623 holes on composing Failed-AVPs as well as many other issues and
6624 topics. To Jan Nordqvist for clearly stating the usage of
6625 Application Ids. To Anders Kristensen for providing needed technical
6626 opinions. To David Frascone for providing invaluable review of the
6627 document. To Mark Jones for providing clarifying text on vendor
6628 command codes and other vendor specific indicators. To Jouni
6629 Korhonen for taking over the editing task and resolving last bits
6630 from -27 through -29.
6632 Special thanks to the Diameter extensibility design team which helped
6633 resolve the tricky question of mandatory AVPs and ABNF semantics.
6634 The members of this team are as follows:
6636 Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga
6637 Asveren Jouni Korhonen, Glenn McGregor.
6639 Special thanks also to people who have provided invaluable comments
6640 and inputs especially in resolving controversial issues:
6642 Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick,
6643 Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry
6644 Leiba and Pasi Eronen.
6646 Finally, we would like to thank the original authors of this
6647 document:
6649 Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman and Glen Zorn.
6651 Their invaluable knowledge and experience has given us a robust and
6652 flexible AAA protocol that many people have seen great value in
6653 adopting. We greatly appreciate their support and stewardship for
6654 the continued improvements of Diameter as a protocol. We would also
6655 like to extend our gratitude to folks aside from the authors who have
6656 assisted and contributed to the original version of this document.
6657 Their efforts significantly contributed to the success of Diameter.
6659 A.2. RFC3588
6661 The authors would like to thank Nenad Trifunovic, Tony Johansson and
6662 Pankaj Patel for their participation in the pre-IETF Document Reading
6663 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided
6664 invaluable assistance in working out transport issues, and similarly
6665 with Steven Bellovin in the security area.
6667 Paul Funk and David Mitton were instrumental in getting the Peer
6668 State Machine correct, and our deep thanks go to them for their time.
6670 Text in this document was also provided by Paul Funk, Mark Eklund,
6671 Mark Jones and Dave Spence. Jacques Caron provided many great
6672 comments as a result of a thorough review of the spec.
6674 The authors would also like to acknowledge the following people for
6675 their contribution in the development of the Diameter protocol:
6677 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell,
6678 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy
6679 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien,
6680 Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin,
6681 Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and
6682 Jeff Weisberg.
6684 Finally, Pat Calhoun would like to thank Sun Microsystems since most
6685 of the effort put into this document was done while he was in their
6686 employ.
6688 Appendix B. S-NAPTR Example
6690 As an example, consider a client that wishes to resolve aaa:
6691 ex1.example.com. The client performs a NAPTR query for that domain,
6692 and the following NAPTR records are returned:
6694 ;; order pref flags service regexp replacement
6695 IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" ""
6696 _diameter._tls.ex1.example.com
6697 IN NAPTR 100 50 "s" "aaa:diameter.tcp" ""
6698 _aaa._tcp.ex1.example.com
6699 IN NAPTR 150 50 "s" "aaa:diameter.sctp" ""
6700 _diameter._sctp.ex1.example.com
6702 This indicates that the server supports TLS, TCP and SCTP in that
6703 order. If the client supports TLS, TLS will be used, targeted to a
6704 host determined by an SRV lookup of _diameter._tls.ex1.example.com.
6705 That lookup would return:
6707 ;; Priority Weight Port Target
6708 IN SRV 0 1 5060 server1.ex1.example.com
6709 IN SRV 0 2 5060 server2.ex1.example.com
6711 As an alternative example, a client that wishes to resolve aaa:
6712 ex2.example.com. The client performs a NAPTR query for that domain,
6713 and the following NAPTR records are returned:
6715 ;; order pref flags service regexp replacement
6716 IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
6717 server1.ex2.example.com
6718 IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
6719 server2.ex2.example.com
6721 This indicates that the server supports TCP available at the returned
6722 host names.
6724 Appendix C. Duplicate Detection
6726 As described in Section 9.4, accounting record duplicate detection is
6727 based on session identifiers. Duplicates can appear for various
6728 reasons:
6730 o Failover to an alternate server. Where close to real-time
6731 performance is required, failover thresholds need to be kept low
6732 and this may lead to an increased likelihood of duplicates.
6733 Failover can occur at the client or within Diameter agents.
6735 o Failure of a client or agent after sending of a record from non-
6736 volatile memory, but prior to receipt of an application layer ACK
6737 and deletion of the record. record to be sent. This will result
6738 in retransmission of the record soon after the client or agent has
6739 rebooted.
6741 o Duplicates received from RADIUS gateways. Since the
6742 retransmission behavior of RADIUS is not defined within [RFC2865],
6743 the likelihood of duplication will vary according to the
6744 implementation.
6746 o Implementation problems and misconfiguration.
6748 The T flag is used as an indication of an application layer
6749 retransmission event, e.g., due to failover to an alternate server.
6750 It is defined only for request messages sent by Diameter clients or
6751 agents. For instance, after a reboot, a client may not know whether
6752 it has already tried to send the accounting records in its non-
6753 volatile memory before the reboot occurred. Diameter servers MAY use
6754 the T flag as an aid when processing requests and detecting duplicate
6755 messages. However, servers that do this MUST ensure that duplicates
6756 are found even when the first transmitted request arrives at the
6757 server after the retransmitted request. It can be used only in cases
6758 where no answer has been received from the Server for a request and
6759 the request is sent again, (e.g., due to a failover to an alternate
6760 peer, due to a recovered primary peer or due to a client re-sending a
6761 stored record from non-volatile memory such as after reboot of a
6762 client or agent).
6764 In some cases the Diameter accounting server can delay the duplicate
6765 detection and accounting record processing until a post-processing
6766 phase takes place. At that time records are likely to be sorted
6767 according to the included User-Name and duplicate elimination is easy
6768 in this case. In other situations it may be necessary to perform
6769 real-time duplicate detection, such as when credit limits are imposed
6770 or real-time fraud detection is desired.
6772 In general, only generation of duplicates due to failover or re-
6773 sending of records in non-volatile storage can be reliably detected
6774 by Diameter clients or agents. In such cases the Diameter client or
6775 agents can mark the message as possible duplicate by setting the T
6776 flag. Since the Diameter server is responsible for duplicate
6777 detection, it can choose to make use of the T flag or not, in order
6778 to optimize duplicate detection. Since the T flag does not affect
6779 interoperability, and may not be needed by some servers, generation
6780 of the T flag is REQUIRED for Diameter clients and agents, but MAY be
6781 implemented by Diameter servers.
6783 As an example, it can be usually be assumed that duplicates appear
6784 within a time window of longest recorded network partition or device
6785 fault, perhaps a day. So only records within this time window need
6786 to be looked at in the backward direction. Secondly, hashing
6787 techniques or other schemes, such as the use of the T flag in the
6788 received messages, may be used to eliminate the need to do a full
6789 search even in this set except for rare cases.
6791 The following is an example of how the T flag may be used by the
6792 server to detect duplicate requests.
6794 A Diameter server MAY check the T flag of the received message to
6795 determine if the record is a possible duplicate. If the T flag is
6796 set in the request message, the server searches for a duplicate
6797 within a configurable duplication time window backward and
6798 forward. This limits database searching to those records where
6799 the T flag is set. In a well run network, network partitions and
6800 device faults will presumably be rare events, so this approach
6801 represents a substantial optimization of the duplicate detection
6802 process. During failover, it is possible for the original record
6803 to be received after the T flag marked record, due to differences
6804 in network delays experienced along the path by the original and
6805 duplicate transmissions. The likelihood of this occurring
6806 increases as the failover interval is decreased. In order to be
6807 able to detect out of order duplicates, the Diameter server should
6808 use backward and forward time windows when performing duplicate
6809 checking for the T flag marked request. For example, in order to
6810 allow time for the original record to exit the network and be
6811 recorded by the accounting server, the Diameter server can delay
6812 processing records with the T flag set until a time period
6813 TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing
6814 of the original transport connection. After this time period has
6815 expired, then it may check the T flag marked records against the
6816 database with relative assurance that the original records, if
6817 sent, have been received and recorded.
6819 Appendix D. Internationalized Domain Names
6821 To be compatible with the existing DNS infrastructure and simplify
6822 host and domain name comparison, Diameter identities (FQDNs) are
6823 represented in ASCII form. This allows the Diameter protocol to fall
6824 in-line with the DNS strategy of being transparent from the effects
6825 of Internationalized Domain Names (IDNs) by following the
6826 recommendations in [RFC4690] and [RFC5890]. Applications that
6827 provide support for IDNs outside of the Diameter protocol but
6828 interacting with it SHOULD use the representation and conversion
6829 framework described in [RFC5890], [RFC5891] and [RFC3492].
6831 Authors' Addresses
6833 Victor Fajardo (editor)
6834 Telcordia Technologies
6835 One Telcordia Drive, 1S-222
6836 Piscataway, NJ 08854
6837 USA
6839 Phone: +1-908-421-1845
6840 Email: vf0213@gmail.com
6842 Jari Arkko
6843 Ericsson Research
6844 02420 Jorvas
6845 Finland
6847 Phone: +358 40 5079256
6848 Email: jari.arkko@ericsson.com
6850 John Loughney
6851 Nokia Research Center
6852 955 Page Mill Road
6853 Palo Alto, CA 94304
6854 US
6856 Phone: +1-650-283-8068
6857 Email: john.loughney@nokia.com
6859 Glen Zorn (editor)
6860 Network Zen
6861 227/358 Thanon Sanphawut
6862 Bang Na, Bangkok 10260
6863 Thailand
6865 Phone: +66 (0) 87-0404617
6866 Email: glenzorn@gmail.com