idnits 2.17.1
draft-ietf-dime-rfc3588bis-30.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 mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 1783 has weird spacing: '...equired rules...'
== Line 6667 has weird spacing: '...service rege...'
== Line 6688 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 8, 2012) is 4423 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 6284, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'FLOATPOINT'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM'
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155)
** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506)
** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
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 9, 2012 Nokia Research Center
8 G. Zorn, Ed.
9 Network Zen
10 March 8, 2012
12 Diameter Base Protocol
13 draft-ietf-dime-rfc3588bis-30.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 must be supported by all new Diameter
24 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 9, 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 ABNF 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 Table . . . . . . . . . . . . . . . . . . . . 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 TCP, SCTP, TLS/TCP and DTLS/SCTP Port Numbers . 141
251 11.5. SCTP Payload Protocol Identifiers . . . . . . . . . . . . 141
252 11.6. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . 141
253 12. Diameter Protocol-related Configurable Parameters . . . . . . 142
254 13. Security Considerations . . . . . . . . . . . . . . . . . . . 142
255 13.1. TLS/TCP and DTLS/SCTP Usage . . . . . . . . . . . . . . . 143
256 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 143
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 . . . . . . . . . . . . . . . . . . 147
262 A.1. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . . 147
263 A.2. RFC3588 . . . . . . . . . . . . . . . . . . . . . . . . . 148
264 Appendix B. S-NAPTR Example . . . . . . . . . . . . . . . . . . 149
265 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 150
266 Appendix D. Internationalized Domain Names . . . . . . . . . . . 152
267 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 152
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 Augmented Backus-Naur Form (ABNF,
401 [RFC5234]) Command Code syntax specificationSection 3.2 is satisfied.
402 AVPs are used by the base Diameter protocol to support the following
403 required features:
405 o Transporting of user authentication information, for the purposes
406 of enabling the Diameter server to authenticate the user.
408 o Transporting of service-specific authorization information,
409 between client and servers, allowing the peers to decide whether a
410 user's access request should be granted.
412 o Exchanging resource usage information, which may be used for
413 accounting purposes, capacity planning, etc.
415 o Routing, relaying, proxying and redirecting of Diameter messages
416 through a server hierarchy.
418 The Diameter base protocol satisfies the minimum requirements for an
419 AAA protocol, as specified by [RFC2989]. The base protocol may be
420 used by itself for accounting purposes only, or it may be used with a
421 Diameter application, such as Mobile IPv4 [RFC4004], or network
422 access [RFC4005]. It is also possible for the base protocol to be
423 extended for use in new applications, via the addition of new
424 commands or AVPs. The initial focus of Diameter was network access
425 and accounting applications. A truly generic AAA protocol used by
426 many applications might provide functionality not provided by
427 Diameter. Therefore, it is imperative that the designers of new
428 applications understand their requirements before using Diameter.
429 See Section 1.3.4 for more information on Diameter applications.
431 Any node can initiate a request. In that sense, Diameter is a peer-
432 to-peer protocol. In this document, a Diameter Client is a device at
433 the edge of the network that performs access control, such as a
434 Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
435 client generates Diameter messages to request authentication,
436 authorization, and accounting services for the user. A Diameter
437 agent is a node that does not provide local user authentication or
438 authorization services; agents include proxies, redirects and relay
439 agents. A Diameter server performs authentication and/or
440 authorization of the user. A Diameter node may act as an agent for
441 certain requests while acting as a server for others.
443 The Diameter protocol also supports server-initiated messages, such
444 as a request to abort service to a particular user.
446 1.1.1. Description of the Document Set
448 The Diameter specification consists of an updated version of the base
449 protocol specification (this document) and the Transport Profile
450 [RFC3539]. This document obsoletes RFC 3588. A summary of the base
451 protocol updates included in this document can be found in
452 Section 1.1.3.
454 This document defines the base protocol specification for AAA, which
455 includes support for accounting. There are also a myriad of
456 applications documents describing applications that use this base
457 specification for Authentication, Authorization and Accounting.
458 These application documents specify how to use the Diameter protocol
459 within the context of their application.
461 The Transport Profile document [RFC3539] discusses transport layer
462 issues that arise with AAA protocols and recommendations on how to
463 overcome these issues. This document also defines the Diameter
464 failover algorithm and state machine.
466 Clarifications on the Routing of Diameter Request based on Username
467 and the Realm [RFC5729] defines specific behavior on how to route
468 requests based on the content of the User-Name AVP (Attribute Value
469 Pair).
471 1.1.2. Conventions Used in This Document
473 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
474 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
475 document are to be interpreted as described in [RFC2119].
477 1.1.3. Changes from RFC3588
479 This document obsoletes RFC 3588 but is fully backward compatible
480 with that document. The changes introduced in this document focus on
481 fixing issues that have surfaced during implementation of [RFC3588].
482 An overview of some the major changes are given below.
484 o Deprecated the use of Inband-Security AVP for negotiating
485 transport layer security. It has been generally considered that
486 bootstrapping of TLS via Inband-Security AVP creates certain
487 security risk because it does not completely protect the
488 information carried in the CER (Capabilities Exchange Request)/CEA
489 (Capabilities Exchange Answer). This version of Diameter adopted
490 a common approach of defining a well-known secured port that peers
491 should use when communicating via TLS/TCP and DTLS/SCTP. This new
492 approach augments the existing Inband-Security negotiation but
493 does not completely replace it. The old method is kept for
494 backwards compatibility reasons.
496 o Deprecated the exchange of CER/CEA messages in the open state.
497 This feature was implied in the peer state machine table of
498 [RFC3588] but it was not clearly defined anywhere else in that
499 document. As work on this document progressed, it became clear
500 that the multiplicity of meaning and use of Application Id AVPs in
501 the CER/CEA messages (and the messages themselves) is seen as an
502 abuse of the Diameter extensibility rules and thus required
503 simplification. It is assumed that the capabilities exchange in
504 the open state will be re-introduced in a separate specification
505 which clearly defines new commands for this feature.
507 o Simplified Security Requirements. The use of a secured transport
508 for exchanging Diameter messages remains mandatory. However, TLS/
509 TCP and DTLS/SCTP has become the primary method of securing
510 Diameter and IPsec is a secondary alternative. See Section 13 for
511 details. The support for the End-to-End security framework (E2E-
512 Sequence AVP and 'P'-bit in the AVP header) has also been
513 deprecated.
515 o Diameter Extensibility Changes. This includes fixes to the
516 Diameter extensibility description (Section 1.3 and others) to
517 better aid Diameter application designers; in addition, the new
518 specification relaxes the policy with respect to the allocation of
519 command codes for vendor-specific uses.
521 o Application Id Usage. Clarify the proper use of Application Id
522 information which can be found in multiple places within a
523 Diameter message. This includes correlating Application Ids found
524 in the message headers and AVPs. These changes also clearly
525 specify the proper Application Id value to use for specific base
526 protocol messages (ASR/ASA, STR/STA) as well as clarifying the
527 content and use of Vendor-Specific-Application-Id.
529 o Routing Fixes. This document more clearly specifies what
530 information (AVPs and Application Id) can be used for making
531 general routing decisions. A rule for the prioritization of
532 redirect routing criteria when multiple route entries are found
533 via redirects has also been added (see Section 6.13.
535 o Simplification of Diameter Peer Discovery. The Diameter discovery
536 process now supports only widely used discovery schemes; the rest
537 have been deprecated (see Section 5.2 for details).
539 There are many other many miscellaneous fixes that have been
540 introduced in this document that may not be considered significant
541 but they are important nonetheless. Examples are removal of obsolete
542 types, fixes to command ABNFs, fixes to the state machine,
543 clarification of the election process, message validation, fixes to
544 Failed-AVP and Result-Code AVP values, etc. All of the errata
545 previously filed against RFC 3588 have been fixed. A comprehensive
546 list of changes is not shown here for practical reasons.
548 1.2. Terminology
550 AAA
552 Authentication, Authorization and Accounting.
554 ABNF
556 Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own
557 formal syntax and rules. It is based on the Backus-Naur Form and
558 is used to define message exchanges in a bi-directional
559 communications protocol.
561 Accounting
563 The act of collecting information on resource usage for the
564 purpose of capacity planning, auditing, billing or cost
565 allocation.
567 Accounting Record
569 An accounting record represents a summary of the resource
570 consumption of a user over the entire session. Accounting servers
571 creating the accounting record may do so by processing interim
572 accounting events or accounting events from several devices
573 serving the same user.
575 Authentication
577 The act of verifying the identity of an entity (subject).
579 Authorization
581 The act of determining whether a requesting entity (subject) will
582 be allowed access to a resource (object).
584 AVP
586 The Diameter protocol consists of a header followed by one or more
587 Attribute-Value-Pairs (AVPs). An AVP includes a header and is
588 used to encapsulate protocol-specific data (e.g., routing
589 information) as well as authentication, authorization or
590 accounting information.
592 Diameter Agent
594 A Diameter Agent is a Diameter Node that provides either relay,
595 proxy, redirect or translation services.
597 Diameter Client
599 A Diameter Client is a Diameter Node that supports Diameter client
600 applications as well as the base protocol. Diameter Clients are
601 often implemented in devices situated at the edge of a network and
602 provide access control services for that network. Typical
603 examples of Diameter Clients include the Network Access Server
604 (NAS) and the Mobile IP Foreign Agent (FA).
606 Diameter Node
608 A Diameter Node is a host process that implements the Diameter
609 protocol, and acts either as a Client, Agent or Server.
611 Diameter Peer
613 Two Diameter Nodes sharing a direct TCP or SCTP transport
614 connection are called Diameter Peers.
616 Diameter Server
618 A Diameter Server is a Diameter Node that handles authentication,
619 authorization and accounting requests for a particular realm. By
620 its very nature, a Diameter Server must support Diameter server
621 applications in addition to the base protocol.
623 Downstream
625 Downstream is used to identify the direction of a particular
626 Diameter message from the Home Server towards the Diameter Client.
628 Home Realm
630 A Home Realm is the administrative domain with which the user
631 maintains an account relationship.
633 Home Server
635 A Diameter Server which serves the Home Realm.
637 Interim accounting
639 An interim accounting message provides a snapshot of usage during
640 a user's session. It is typically implemented in order to provide
641 for partial accounting of a user's session in the case a device
642 reboot or other network problem prevents the delivery of a session
643 summary message or session record.
645 Local Realm
647 A local realm is the administrative domain providing services to a
648 user. An administrative domain may act as a local realm for
649 certain users, while being a home realm for others.
651 Multi-session
653 A multi-session represents a logical linking of several sessions.
654 Multi-sessions are tracked by using the Acct-Multi-Session-Id. An
655 example of a multi-session would be a Multi-link PPP bundle. Each
656 leg of the bundle would be a session while the entire bundle would
657 be a multi-session.
659 Network Access Identifier
661 The Network Access Identifier, or NAI [RFC4282], is used in the
662 Diameter protocol to extract a user's identity and realm. The
663 identity is used to identify the user during authentication and/or
664 authorization, while the realm is used for message routing
665 purposes.
667 Proxy Agent or Proxy
669 In addition to forwarding requests and responses, proxies make
670 policy decisions relating to resource usage and provisioning.
671 This is typically accomplished by tracking the state of NAS
672 devices. While proxies typically do not respond to client
673 Requests prior to receiving a Response from the server, they may
674 originate Reject messages in cases where policies are violated.
675 As a result, proxies need to understand the semantics of the
676 messages passing through them, and may not support all Diameter
677 applications.
679 Realm
681 The string in the NAI that immediately follows the '@' character.
682 NAI realm names are required to be unique, and are piggybacked on
683 the administration of the DNS namespace. Diameter makes use of
684 the realm, also loosely referred to as domain, to determine
685 whether messages can be satisfied locally, or whether they must be
686 routed or redirected. In RADIUS, realm names are not necessarily
687 piggybacked on the DNS namespace but may be independent of it.
689 Real-time Accounting
691 Real-time accounting involves the processing of information on
692 resource usage within a defined time window. Time constraints are
693 typically imposed in order to limit financial risk. The Diameter
694 Credit Control Application [RFC4006] is an example of an
695 application that defines real-time accounting functionality.
697 Relay Agent or Relay
699 Relays forward requests and responses based on routing-related
700 AVPs and routing table entries. Since relays do not make policy
701 decisions, they do not examine or alter non-routing AVPs. As a
702 result, relays never originate messages, do not need to understand
703 the semantics of messages or non-routing AVPs, and are capable of
704 handling any Diameter application or message type. Since relays
705 make decisions based on information in routing AVPs and realm
706 forwarding tables they do not keep state on NAS resource usage or
707 sessions in progress.
709 Redirect Agent
711 Rather than forwarding requests and responses between clients and
712 servers, redirect agents refer clients to servers and allow them
713 to communicate directly. Since redirect agents do not sit in the
714 forwarding path, they do not alter any AVPs transiting between
715 client and server. Redirect agents do not originate messages and
716 are capable of handling any message type, although they may be
717 configured only to redirect messages of certain types, while
718 acting as relay or proxy agents for other types. As with relay
719 agents, redirect agents do not keep state with respect to sessions
720 or NAS resources.
722 Session
724 A session is a related progression of events devoted to a
725 particular activity. Diameter application documents provide
726 guidelines as to when a session begins and ends. All Diameter
727 packets with the same Session-Id are considered to be part of the
728 same session.
730 Stateful Agent
732 A stateful agent is one that maintains session state information,
733 by keeping track of all authorized active sessions. Each
734 authorized session is bound to a particular service, and its state
735 is considered active either until it is notified otherwise, or by
736 expiration.
738 Sub-session
740 A sub-session represents a distinct service (e.g., QoS or data
741 characteristics) provided to a given session. These services may
742 happen concurrently (e.g., simultaneous voice and data transfer
743 during the same session) or serially. These changes in sessions
744 are tracked with the Accounting-Sub-Session-Id.
746 Transaction state
748 The Diameter protocol requires that agents maintain transaction
749 state, which is used for failover purposes. Transaction state
750 implies that upon forwarding a request, the Hop-by-Hop identifier
751 is saved; the field is replaced with a locally unique identifier,
752 which is restored to its original value when the corresponding
753 answer is received. The request's state is released upon receipt
754 of the answer. A stateless agent is one that only maintains
755 transaction state.
757 Translation Agent
759 A translation agent is a stateful Diameter node that performs
760 protocol translation between Diameter and another AAA protocol,
761 such as RADIUS.
763 Upstream
765 Upstream is used to identify the direction of a particular
766 Diameter message from the Diameter Client towards the Home Server.
768 User
770 The entity or device requesting or using some resource, in support
771 of which a Diameter client has generated a request.
773 1.3. Approach to Extensibility
775 The Diameter protocol is designed to be extensible, using several
776 mechanisms, including:
778 o Defining new AVP values
780 o Creating new AVPs
782 o Creating new commands
784 o Creating new applications
786 From the point of view of extensibility Diameter authentication,
787 authorization and accounting applications are treated in the same
788 way.
790 Note: Protocol designers should try to re-use existing functionality,
791 namely AVP values, AVPs, commands, and Diameter applications. Reuse
792 simplifies standardization and implementation. To avoid potential
793 interoperability issues it is important to ensure that the semantics
794 of the re-used features are well understood. Given that Diameter can
795 also carry RADIUS attributes as Diameter AVPs, such re-use
796 considerations apply also to existing RADIUS attributes that may be
797 useful in a Diameter application.
799 1.3.1. Defining New AVP Values
801 In order to allocate a new AVP value for AVPs defined in the Diameter
802 Base protocol, the IETF needs to approve a new RFC that describes the
803 AVP value. IANA considerations for these AVP values are discussed in
804 Section 11.3.
806 The allocation of AVP values for other AVPs is guided by the IANA
807 considerations of the document that defines those AVPs. Typically,
808 allocation of new values for an AVP defined in an IETF RFC should
809 require IETF Review [RFC5226], whereas values for vendor-specific
810 AVPs can be allocated by the vendor.
812 1.3.2. Creating New AVPs
814 A new AVP being defined MUST use one of the data types listed in
815 Section 4.2 or Section 4.3. If an appropriate derived data type is
816 already defined, it SHOULD be used instead of a base data type to
817 encourage reusability and good design practice.
819 In the event that a logical grouping of AVPs is necessary, and
820 multiple "groups" are possible in a given command, it is recommended
821 that a Grouped AVP be used (see Section 4.4).
823 The creation of new AVPs can happen in various ways. The recommended
824 approach is to define a new general-purpose AVP in a standards track
825 RFC approved by the IETF. However, as described in Section 11.1.1
826 there are also other mechanisms.
828 1.3.3. Creating New Commands
830 A new Command Code MUST be allocated when required AVPs (those
831 indicated as {AVP} in the ABNF definition) are added to, deleted from
832 or redefined in (for example, by changing a required AVP into an
833 optional one) an existing command.
835 Furthermore, if the transport characteristics of a command are
836 changed (for example, with respect to the number of round trips
837 required) a new Command Code MUST be registered.
839 A change to the ABNF of a command, such as described above, MUST
840 result in the definition of a new Command Code. This subsequently
841 leads to the need to define a new Diameter Application for any
842 application that will use that new Command.
844 The IANA considerations for command codes are discussed in
845 Section 3.1.
847 1.3.4. Creating New Diameter Applications
849 Every Diameter application specification MUST have an IANA assigned
850 Application Id (see Section 2.4). The managed Application Id space
851 is flat and there is no relationship between different Diameter
852 applications with respect to their Application Ids. As such, there is
853 no versioning support provided by these application Ids itself; every
854 Diameter application is a standalone application. If the application
855 has a relationship with other Diameter applications, such a
856 relationship is not known to Diameter.
858 Before describing the rules for creating new Diameter applications it
859 is important to discuss the semantics of the AVP occurrences as
860 stated in the ABNF and the M-bit flag (Section 4.1) for an AVP.
861 There is no relationship imposed between the two; they are set
862 independently.
864 o The ABNF indicates what AVPs are placed into a Diameter Command by
865 the sender of that Command. Often, since there are multiple modes
866 of protocol interactions many of the AVPs are indicated as
867 optional.
869 o The M-bit allows the sender to indicate to the receiver whether or
870 not understanding the semantics of an AVP and its content is
871 mandatory. If the M-bit is set by the sender and the receiver
872 does not understand the AVP or the values carried within that AVP
873 then a failure is generated (see Section 7).
875 It is the decision of the protocol designer when to develop a new
876 Diameter application rather than extending Diameter in other ways.
877 However, a new Diameter application MUST be created when one or more
878 of the following criteria are met:
880 M-bit Setting
882 An AVP with the M-bit in the MUST column of the AVP flag table is
883 added to an existing Command/Application.
885 An AVP with the M-bit in the MAY column of the AVP flag table is
886 added to an existing Command/Application.
888 Note: The M-bit setting for a given AVP is relevant to an
889 Application and each command within that application which
890 includes the AVP. That is, if an AVP appears in two commands for
891 application Foo and the M-bit settings are different in each
892 command, then there should be two AVP flag tables describing when
893 to set the M-bit.
895 Commands
897 A new command is used within the existing application either
898 because an additional command is added, an existing command has
899 been modified so that a new Command Code had to be registered, or
900 a command has been deleted.
902 AVP Flag bits
904 An existing application changes the meaning/semantics of their AVP
905 Flags or adds new flag bits then a new Diameter application MUST
906 be created.
908 If the ABNF definition of a command allows it, an implementation may
909 add arbitrary optional AVPs with the M-bit cleared (including vendor-
910 specific AVPs) to that command without needing to define a new
911 application. Please refer to Section 11.1.1 for details.
913 2. Protocol Overview
915 The base Diameter protocol concerns itself with establishing
916 connections to peers, capabilities negotiation, how messages are sent
917 and routed through peers, and how the connections are eventually torn
918 down. The base protocol also defines certain rules that apply to all
919 message exchanges between Diameter nodes.
921 Communication between Diameter peers begins with one peer sending a
922 message to another Diameter peer. The set of AVPs included in the
923 message is determined by a particular Diameter application. One AVP
924 that is included to reference a user's session is the Session-Id.
926 The initial request for authentication and/or authorization of a user
927 would include the Session-Id AVP. The Session-Id is then used in all
928 subsequent messages to identify the user's session (see Section 8 for
929 more information). The communicating party may accept the request,
930 or reject it by returning an answer message with the Result-Code AVP
931 set to indicate an error occurred. The specific behavior of the
932 Diameter server or client receiving a request depends on the Diameter
933 application employed.
935 Session state (associated with a Session-Id) MUST be freed upon
936 receipt of the Session-Termination-Request, Session-Termination-
937 Answer, expiration of authorized service time in the Session-Timeout
938 AVP, and according to rules established in a particular Diameter
939 application.
941 The base Diameter protocol may be used by itself for accounting
942 applications. For authentication and authorization, it is always
943 extended for a particular application.
945 Diameter Clients MUST support the base protocol, which includes
946 accounting. In addition, they MUST fully support each Diameter
947 application that is needed to implement the client's service, e.g.,
948 NASREQ and/or Mobile IPv4. A Diameter Client MUST be referred to as
949 "Diameter X Client" where X is the application which it supports, and
950 not a "Diameter Client".
952 Diameter Servers MUST support the base protocol, which includes
953 accounting. In addition, they MUST fully support each Diameter
954 application that is needed to implement the intended service, e.g.,
955 NASREQ and/or Mobile IPv4. A Diameter Server MUST be referred to as
956 "Diameter X Server" where X is the application which it supports, and
957 not a "Diameter Server".
959 Diameter Relays and redirect agents are transparent to the Diameter
960 applications but they MUST support the Diameter base protocol, which
961 includes accounting, and all Diameter applications.
963 Diameter proxies MUST support the base protocol, which includes
964 accounting. In addition, they MUST fully support each Diameter
965 application that is needed to implement proxied services, e.g.,
966 NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as
967 "Diameter X Proxy" where X is the application which it supports, and
968 not a "Diameter Proxy".
970 2.1. Transport
972 The Diameter Transport profile is defined in [RFC3539].
974 The base Diameter protocol is run on port 3868 for both TCP [RFC793]
975 and SCTP [RFC4960]. For TLS [RFC5246] and DTLS [RFC6347], a Diameter
976 node that initiate a connection prior to any message exchanges MUST
977 run on port [TBD]. It is assumed that TLS is run on top of TCP when
978 it is used and DTLS is run on top of SCTP when it is used.
980 If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
981 connections on port [TBD], i.e. the peer complies only with
982 [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
983 port 3868. Note that this scheme is kept for the purpose of
984 backwards compatibility only and that there are inherent security
985 vulnerabilities when the initial CER/CEA messages are sent un-
986 protected (see Section 5.6).
988 Diameter clients MUST support either TCP or SCTP, while agents and
989 servers SHOULD support both.
991 A Diameter node MAY initiate connections from a source port other
992 than the one that it declares it accepts incoming connections on, and
993 MUST be prepared to receive connections on port 3868 for TCP or SCTP
994 and port [TBD] for TLS/TCP and DTLS/SCTP connections. A given
995 Diameter instance of the peer state machine MUST NOT use more than
996 one transport connection to communicate with a given peer, unless
997 multiple instances exist on the peer in which case a separate
998 connection per process is allowed.
1000 When no transport connection exists with a peer, an attempt to
1001 connect SHOULD be periodically made. This behavior is handled via
1002 the Tc timer (see Section 12 for details), whose recommended value is
1003 30 seconds. There are certain exceptions to this rule, such as when
1004 a peer has terminated the transport connection stating that it does
1005 not wish to communicate.
1007 When connecting to a peer and either zero or more transports are
1008 specified, TLS SHOULD be tried first, followed by DTLS, then by TCP
1009 and finally by SCTP. See Section 5.2 for more information on peer
1010 discovery.
1012 Diameter implementations SHOULD be able to interpret ICMP protocol
1013 port unreachable messages as explicit indications that the server is
1014 not reachable, subject to security policy on trusting such messages.
1015 Further guidance regarding the treatment of ICMP errors can be found
1016 in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be
1017 able to interpret a reset from the transport and timed-out connection
1018 attempts. If Diameter receives data from the lower layer that cannot
1019 be parsed or identified as a Diameter error made by the peer, the
1020 stream is compromised and cannot be recovered. The transport
1021 connection MUST be closed using a RESET call (send a TCP RST bit) or
1022 an SCTP ABORT message (graceful closure is compromised).
1024 2.1.1. SCTP Guidelines
1026 Diameter messages SHOULD be mapped into SCTP streams in a way that
1027 avoids head-of-the-line (HOL) blocking. Among different ways of
1028 performing the mapping that fulfill this requirement it is
1029 RECOMMENDED that a Diameter node sends every Diameter message
1030 (request or response) over the stream zero with the unordered flag
1031 set. However, Diameter nodes MAY select and implement other design
1032 alternatives for avoiding HOL blocking such as using multiple streams
1033 with the unordered flag cleared (as originally instructed in
1034 RFC3588). On the receiving side, a Diameter entity MUST be ready to
1035 receive Diameter messages over any stream and it is free to return
1036 responses over a different stream. This way, both sides manage the
1037 available streams in the sending direction, independently of the
1038 streams chosen by the other side to send a particular Diameter
1039 message. These messages can be out-of-order and belong to different
1040 Diameter sessions.
1042 Out-of-order delivery has special concerns during a connection
1043 establishment and termination. When a connection is established, the
1044 responder side sends a CEA message and moves to R-Open state as
1045 specified in Section 5.6. If an application message is sent shortly
1046 after the CEA and delivered out-of-order, the initiator side, still
1047 in Wait-I-CEA state, will discard the application message and close
1048 the connection. In order to avoid this race condition, the receiver
1049 side SHOULD NOT use out-of-order delivery methods until the first
1050 message has been received from the initiator, proving that it has
1051 moved to I-Open state. To trigger such message, the receiver side
1052 could send a DWR immediatly after sending CEA. Upon reception of the
1053 corresponding DWA, the receiver side should start using out-of-order
1054 delivery methods to counter the HOL blocking.
1056 Another race condition may occur when DPR and DPA messages are used.
1057 Both DPR and DPA are small in size, thus they may be delivered faster
1058 to the peer than application messages when out-of-order delivery
1059 mechanism is used. Therefore, it is possible that a DPR/DPA exchange
1060 completes while application messages are still in transit, resulting
1061 to a loss of these messages. An implementation could mitigate this
1062 race condition, for example, using timers and wait for a short period
1063 of time for pending application level messages to arrive before
1064 proceeding to disconnect the transport connection. Eventually, lost
1065 messages are handled by the retransmission mechanism described in
1066 Section 5.5.4.
1068 A Diameter agent SHOULD use dedicated payload protocol identifiers
1069 (PPID) for clear text and encrypted SCTP DATA chunks instead of only
1070 using the unspecified payload protocol identifier (value 0). For
1071 this purpose two PPID values are allocated. The PPID value TBD2 is
1072 for Diameter messages in clear text SCTP DATA chunks and the PPID
1073 value TBD3 is for Diameter messages in protected DTLS/SCTP DATA
1074 chunks.
1076 2.2. Securing Diameter Messages
1078 Connections between Diameter peers SHOULD be protected by TLS/TCP and
1079 DTLS/SCTP. All Diameter base protocol implementations MUST support
1080 the use of TLS/TCP and DTLS/SCTP. If desired, alternative security
1081 mechanisms that are independent of Diameter, such as IPsec [RFC4301],
1082 can be deployed to secure connections between peers. The Diameter
1083 protocol MUST NOT be used without any security mechanism.
1085 2.3. Diameter Application Compliance
1087 Application Ids are advertised during the capabilities exchange phase
1088 (see Section 5.3). Advertising support of an application implies
1089 that the sender supports the functionality specified in the
1090 respective Diameter application specification.
1092 Implementations MAY add arbitrary optional AVPs with the M-bit
1093 cleared (including vendor-specific AVPs) to a command defined in an
1094 application, but only if the command's ABNF syntax specification
1095 allows for it. Please refer to Section 11.1.1 for details.
1097 2.4. Application Identifiers
1099 Each Diameter application MUST have an IANA assigned Application Id.
1100 The base protocol does not require an Application Id since its
1101 support is mandatory. During the capabilities exchange, Diameter
1102 nodes inform their peers of locally supported applications.
1103 Furthermore, all Diameter messages contain an Application Id, which
1104 is used in the message forwarding process.
1106 The following Application Id values are defined:
1108 Diameter Common Messages 0
1109 Diameter Base Accounting 3
1110 Relay 0xffffffff
1112 Relay and redirect agents MUST advertise the Relay Application
1113 Identifier, while all other Diameter nodes MUST advertise locally
1114 supported applications. The receiver of a Capabilities Exchange
1115 message advertising Relay service MUST assume that the sender
1116 supports all current and future applications.
1118 Diameter relay and proxy agents are responsible for finding an
1119 upstream server that supports the application of a particular
1120 message. If none can be found, an error message is returned with the
1121 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1123 2.5. Connections vs. Sessions
1125 This section attempts to provide the reader with an understanding of
1126 the difference between connection and session, which are terms used
1127 extensively throughout this document.
1129 A connection refers to a transport level connection between two peers
1130 that is used to send and receive Diameter messages. A session is a
1131 logical concept at the application layer existing between the
1132 Diameter client and the Diameter server; it is identified via the
1133 Session-Id AVP.
1135 +--------+ +-------+ +--------+
1136 | Client | | Relay | | Server |
1137 +--------+ +-------+ +--------+
1138 <----------> <---------->
1139 peer connection A peer connection B
1141 <----------------------------->
1142 User session x
1144 Figure 1: Diameter connections and sessions
1146 In the example provided in Figure 1, peer connection A is established
1147 between the Client and the Relay. Peer connection B is established
1148 between the Relay and the Server. User session X spans from the
1149 Client via the Relay to the Server. Each "user" of a service causes
1150 an auth request to be sent, with a unique session identifier. Once
1151 accepted by the server, both the client and the server are aware of
1152 the session.
1154 It is important to note that there is no relationship between a
1155 connection and a session, and that Diameter messages for multiple
1156 sessions are all multiplexed through a single connection. Also note
1157 that Diameter messages pertaining to the session, both application
1158 specific and those that are defined in this document such as ASR/ASA,
1159 RAR/RAA and STR/STA MUST carry the Application Id of the application.
1160 Diameter messages pertaining to peer connection establishment and
1161 maintenance such as CER/CEA, DWR/DWA and DPR/DPA MUST carry an
1162 Application Id of zero (0).
1164 2.6. Peer Table
1166 The Diameter Peer Table is used in message forwarding, and referenced
1167 by the Routing Table. A Peer Table entry contains the following
1168 fields:
1170 Host identity
1172 Following the conventions described for the DiameterIdentity
1173 derived AVP data format in Section 4.3.1, this field contains the
1174 contents of the Origin-Host (Section 6.3) AVP found in the CER or
1175 CEA message.
1177 StatusT
1179 This is the state of the peer entry, and MUST match one of the
1180 values listed in Section 5.6.
1182 Static or Dynamic
1184 Specifies whether a peer entry was statically configured or
1185 dynamically discovered.
1187 Expiration time
1189 Specifies the time at which dynamically discovered peer table
1190 entries are to be either refreshed, or expired.
1192 TLS/TCP and DTLS/SCTP Enabled
1194 Specifies whether TLS/TCP and DTLS/SCTP is to be used when
1195 communicating with the peer.
1197 Additional security information, when needed (e.g., keys,
1198 certificates).
1200 2.7. Routing Table
1202 All Realm-Based routing lookups are performed against what is
1203 commonly known as the Routing Table (see Section 12). Each Routing
1204 Table entry contains the following fields:
1206 Realm Name
1208 This is the field that MUST be used as a primary key in the
1209 routing table lookups. Note that some implementations perform
1210 their lookups based on longest-match-from-the-right on the realm
1211 rather than requiring an exact match.
1213 Application Identifier
1215 An application is identified by an Application Id. A route entry
1216 can have a different destination based on the Application Id in
1217 the message header. This field MUST be used as a secondary key
1218 field in routing table lookups.
1220 Local Action
1222 The Local Action field is used to identify how a message should be
1223 treated. The following actions are supported:
1225 1. LOCAL - Diameter messages that can be satisfied locally, and
1226 do not need to be routed to another Diameter entity.
1228 2. RELAY - All Diameter messages that fall within this category
1229 MUST be routed to a next hop Diameter entity that is indicated
1230 by the identifier described below. Routing is done without
1231 modifying any non-routing AVPs. See Section 6.1.9 for
1232 relaying guidelines.
1234 3. PROXY - All Diameter messages that fall within this category
1235 MUST be routed to a next Diameter entity that is indicated by
1236 the identifier described below. The local server MAY apply
1237 its local policies to the message by including new AVPs to the
1238 message prior to routing. See Section 6.1.9 for proxying
1239 guidelines.
1241 4. REDIRECT - Diameter messages that fall within this category
1242 MUST have the identity of the home Diameter server(s)
1243 appended, and returned to the sender of the message. See
1244 Section 6.1.8 for redirection guidelines.
1246 Server Identifier
1248 The identity of one or more servers to which the message is to be
1249 routed. This identity MUST also be present in the Host Identity
1250 field of the Peer Table (Section 2.6). When the Local Action is
1251 set to RELAY or PROXY, this field contains the identity of the
1252 server(s) to which the message MUST be routed. When the Local
1253 Action field is set to REDIRECT, this field contains the identity
1254 of one or more servers to which the message MUST be redirected.
1256 Static or Dynamic
1258 Specifies whether a route entry was statically configured or
1259 dynamically discovered.
1261 Expiration time
1263 Specifies the time at which a dynamically discovered route table
1264 entry expires.
1266 It is important to note that Diameter agents MUST support at least
1267 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
1268 Agents do not need to support all modes of operation in order to
1269 conform with the protocol specification, but MUST follow the protocol
1270 compliance guidelines in Section 2. Relay agents and proxies MUST
1271 NOT reorder AVPs.
1273 The routing table MAY include a default entry that MUST be used for
1274 any requests not matching any of the other entries. The routing
1275 table MAY consist of only such an entry.
1277 When a request is routed, the target server MUST have advertised the
1278 Application Id (see Section 2.4) for the given message, or have
1279 advertised itself as a relay or proxy agent. Otherwise, an error is
1280 returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1282 2.8. Role of Diameter Agents
1284 In addition to clients and servers, the Diameter protocol introduces
1285 relay, proxy, redirect, and translation agents, each of which is
1286 defined in Section 1.2. Diameter agents are useful for several
1287 reasons:
1289 o They can distribute administration of systems to a configurable
1290 grouping, including the maintenance of security associations.
1292 o They can be used for concentration of requests from an number of
1293 co-located or distributed NAS equipment sets to a set of like user
1294 groups.
1296 o They can do value-added processing to the requests or responses.
1298 o They can be used for load balancing.
1300 o A complex network will have multiple authentication sources, they
1301 can sort requests and forward towards the correct target.
1303 The Diameter protocol requires that agents maintain transaction
1304 state, which is used for failover purposes. Transaction state
1305 implies that upon forwarding a request, its Hop-by-Hop identifier is
1306 saved; the field is replaced with a locally unique identifier, which
1307 is restored to its original value when the corresponding answer is
1308 received. The request's state is released upon receipt of the
1309 answer. A stateless agent is one that only maintains transaction
1310 state.
1312 The Proxy-Info AVP allows stateless agents to add local state to a
1313 Diameter request, with the guarantee that the same state will be
1314 present in the answer. However, the protocol's failover procedures
1315 require that agents maintain a copy of pending requests.
1317 A stateful agent is one that maintains session state information by
1318 keeping track of all authorized active sessions. Each authorized
1319 session is bound to a particular service, and its state is considered
1320 active either until the agent is notified otherwise, or the session
1321 expires. Each authorized session has an expiration, which is
1322 communicated by Diameter servers via the Session-Timeout AVP.
1324 Maintaining session state may be useful in certain applications, such
1325 as:
1327 o Protocol translation (e.g., RADIUS <-> Diameter)
1329 o Limiting resources authorized to a particular user
1331 o Per user or transaction auditing
1333 A Diameter agent MAY act in a stateful manner for some requests and
1334 be stateless for others. A Diameter implementation MAY act as one
1335 type of agent for some requests, and as another type of agent for
1336 others.
1338 2.8.1. Relay Agents
1340 Relay Agents are Diameter agents that accept requests and route
1341 messages to other Diameter nodes based on information found in the
1342 messages (e.g., Destination-Realm). This routing decision is
1343 performed using a list of supported realms, and known peers. This is
1344 known as the Routing Table, as is defined further in Section 2.7.
1346 Relays may, for example, be used to aggregate requests from multiple
1347 Network Access Servers (NASes) within a common geographical area
1348 (POP). The use of Relays is advantageous since it eliminates the
1349 need for NASes to be configured with the necessary security
1350 information they would otherwise require to communicate with Diameter
1351 servers in other realms. Likewise, this reduces the configuration
1352 load on Diameter servers that would otherwise be necessary when NASes
1353 are added, changed or deleted.
1355 Relays modify Diameter messages by inserting and removing routing
1356 information, but do not modify any other portion of a message.
1357 Relays SHOULD NOT maintain session state but MUST maintain
1358 transaction state.
1360 +------+ ---------> +------+ ---------> +------+
1361 | | 1. Request | | 2. Request | |
1362 | NAS | | DRL | | HMS |
1363 | | 4. Answer | | 3. Answer | |
1364 +------+ <--------- +------+ <--------- +------+
1365 example.net example.net example.com
1367 Figure 2: Relaying of Diameter messages
1369 The example provided in Figure 2 depicts a request issued from NAS,
1370 which is an access device, for the user bob@example.com. Prior to
1371 issuing the request, NAS performs a Diameter route lookup, using
1372 "example.com" as the key, and determines that the message is to be
1373 relayed to DRL, which is a Diameter Relay. DRL performs the same
1374 route lookup as NAS, and relays the message to HMS, which is
1375 example.com's Home Diameter Server. HMS identifies that the request
1376 can be locally supported (via the realm), processes the
1377 authentication and/or authorization request, and replies with an
1378 answer, which is routed back to NAS using saved transaction state.
1380 Since Relays do not perform any application level processing, they
1381 provide relaying services for all Diameter applications, and
1382 therefore MUST advertise the Relay Application Id.
1384 2.8.2. Proxy Agents
1386 Similarly to relays, proxy agents route Diameter messages using the
1387 Diameter Routing Table. However, they differ since they modify
1388 messages to implement policy enforcement. This requires that proxies
1389 maintain the state of their downstream peers (e.g., access devices)
1390 to enforce resource usage, provide admission control, and
1391 provisioning.
1393 Proxies may, for example, be used in call control centers or access
1394 ISPs that provide outsourced connections, they can monitor the number
1395 and types of ports in use, and make allocation and admission
1396 decisions according to their configuration.
1398 Since enforcing policies requires an understanding of the service
1399 being provided, Proxies MUST only advertise the Diameter applications
1400 they support.
1402 2.8.3. Redirect Agents
1404 Redirect agents are useful in scenarios where the Diameter routing
1405 configuration needs to be centralized. An example is a redirect
1406 agent that provides services to all members of a consortium, but does
1407 not wish to be burdened with relaying all messages between realms.
1409 This scenario is advantageous since it does not require that the
1410 consortium provide routing updates to its members when changes are
1411 made to a member's infrastructure.
1413 Since redirect agents do not relay messages, and only return an
1414 answer with the information necessary for Diameter agents to
1415 communicate directly, they do not modify messages. Since redirect
1416 agents do not receive answer messages, they cannot maintain session
1417 state.
1419 The example provided in Figure 3 depicts a request issued from the
1420 access device, NAS, for the user bob@example.com. The message is
1421 forwarded by the NAS to its relay, DRL, which does not have a routing
1422 entry in its Diameter Routing Table for example.com. DRL has a
1423 default route configured to DRD, which is a redirect agent that
1424 returns a redirect notification to DRL, as well as HMS' contact
1425 information. Upon receipt of the redirect notification, DRL
1426 establishes a transport connection with HMS, if one doesn't already
1427 exist, and forwards the request to it.
1429 +------+
1430 | |
1431 | DRD |
1432 | |
1433 +------+
1434 ^ |
1435 2. Request | | 3. Redirection
1436 | | Notification
1437 | v
1438 +------+ ---------> +------+ ---------> +------+
1439 | | 1. Request | | 4. Request | |
1440 | NAS | | DRL | | HMS |
1441 | | 6. Answer | | 5. Answer | |
1442 +------+ <--------- +------+ <--------- +------+
1443 example.net example.net example.com
1445 Figure 3: Redirecting a Diameter Message
1447 Since redirect agents do not perform any application level
1448 processing, they provide relaying services for all Diameter
1449 applications, and therefore MUST advertise the Relay Application
1450 Identifier.
1452 2.8.4. Translation Agents
1454 A translation agent is a device that provides translation between two
1455 protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation
1456 agents are likely to be used as aggregation servers to communicate
1457 with a Diameter infrastructure, while allowing for the embedded
1458 systems to be migrated at a slower pace.
1460 Given that the Diameter protocol introduces the concept of long-lived
1461 authorized sessions, translation agents MUST be session stateful and
1462 MUST maintain transaction state.
1464 Translation of messages can only occur if the agent recognizes the
1465 application of a particular request, and therefore translation agents
1466 MUST only advertise their locally supported applications.
1468 +------+ ---------> +------+ ---------> +------+
1469 | | RADIUS Request | | Diameter Request | |
1470 | NAS | | TLA | | HMS |
1471 | | RADIUS Answer | | Diameter Answer | |
1472 +------+ <--------- +------+ <--------- +------+
1473 example.net example.net example.com
1475 Figure 4: Translation of RADIUS to Diameter
1477 2.9. Diameter Path Authorization
1479 As noted in Section 2.2, Diameter provides transmission level
1480 security for each connection using TLS/TCP and DTLS/SCTP. Therefore,
1481 each connection can be authenticated, replay and integrity protected.
1483 In addition to authenticating each connection, each connection as
1484 well as the entire session MUST also be authorized. Before
1485 initiating a connection, a Diameter Peer MUST check that its peers
1486 are authorized to act in their roles. For example, a Diameter peer
1487 may be authentic, but that does not mean that it is authorized to act
1488 as a Diameter Server advertising a set of Diameter applications.
1490 Prior to bringing up a connection, authorization checks are performed
1491 at each connection along the path. Diameter capabilities negotiation
1492 (CER/CEA) also MUST be carried out, in order to determine what
1493 Diameter applications are supported by each peer. Diameter sessions
1494 MUST be routed only through authorized nodes that have advertised
1495 support for the Diameter application required by the session.
1497 As noted in Section 6.1.9, a relay or proxy agent MUST append a
1498 Route-Record AVP to all requests forwarded. The AVP contains the
1499 identity of the peer the request was received from.
1501 The home Diameter server, prior to authorizing a session, MUST check
1502 the Route-Record AVPs to make sure that the route traversed by the
1503 request is acceptable. For example, administrators within the home
1504 realm may not wish to honor requests that have been routed through an
1505 untrusted realm. By authorizing a request, the home Diameter server
1506 is implicitly indicating its willingness to engage in the business
1507 transaction as specified by the contractual relationship between the
1508 server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
1509 message (see Section 7.1.5) is sent if the route traversed by the
1510 request is unacceptable.
1512 A home realm may also wish to check that each accounting request
1513 message corresponds to a Diameter response authorizing the session.
1514 Accounting requests without corresponding authorization responses
1515 SHOULD be subjected to further scrutiny, as should accounting
1516 requests indicating a difference between the requested and provided
1517 service.
1519 Forwarding of an authorization response is considered evidence of a
1520 willingness to take on financial risk relative to the session. A
1521 local realm may wish to limit this exposure, for example, by
1522 establishing credit limits for intermediate realms and refusing to
1523 accept responses which would violate those limits. By issuing an
1524 accounting request corresponding to the authorization response, the
1525 local realm implicitly indicates its agreement to provide the service
1526 indicated in the authorization response. If the service cannot be
1527 provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
1528 message MUST be sent within the accounting request; a Diameter client
1529 receiving an authorization response for a service that it cannot
1530 perform MUST NOT substitute an alternate service, and then send
1531 accounting requests for the alternate service instead.
1533 3. Diameter Header
1535 A summary of the Diameter header format is shown below. The fields
1536 are transmitted in network byte order.
1538 0 1 2 3
1539 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
1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1541 | Version | Message Length |
1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1543 | command flags | Command-Code |
1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545 | Application-ID |
1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1547 | Hop-by-Hop Identifier |
1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1549 | End-to-End Identifier |
1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1551 | AVPs ...
1553 +-+-+-+-+-+-+-+-+-+-+-+-+-
1555 Version
1557 This Version field MUST be set to 1 to indicate Diameter Version
1558 1.
1560 Message Length
1562 The Message Length field is three octets and indicates the length
1563 of the Diameter message including the header fields and the padded
1564 AVPs. Thus the message length field is always a multiple of 4.
1566 Command Flags
1568 The Command Flags field is eight bits. The following bits are
1569 assigned:
1571 0 1 2 3 4 5 6 7
1572 +-+-+-+-+-+-+-+-+
1573 |R P E T r r r r|
1574 +-+-+-+-+-+-+-+-+
1576 R(equest)
1578 If set, the message is a request. If cleared, the message is
1579 an answer.
1581 P(roxiable)
1583 If set, the message MAY be proxied, relayed or redirected. If
1584 cleared, the message MUST be locally processed.
1586 E(rror)
1588 If set, the message contains a protocol error, and the message
1589 will not conform to the ABNF described for this command.
1590 Messages with the 'E' bit set are commonly referred to as error
1591 messages. This bit MUST NOT be set in request messages (see
1592 Section 7.2).
1594 T(Potentially re-transmitted message)
1596 This flag is set after a link failover procedure, to aid the
1597 removal of duplicate requests. It is set when resending
1598 requests not yet acknowledged, as an indication of a possible
1599 duplicate due to a link failure. This bit MUST be cleared when
1600 sending a request for the first time, otherwise the sender MUST
1601 set this flag. Diameter agents only need to be concerned about
1602 the number of requests they send based on a single received
1603 request; retransmissions by other entities need not be tracked.
1604 Diameter agents that receive a request with the T flag set,
1605 MUST keep the T flag set in the forwarded request. This flag
1606 MUST NOT be set if an error answer message (e.g., a protocol
1607 error) has been received for the earlier message. It can be
1608 set only in cases where no answer has been received from the
1609 server for a request and the request is sent again. This flag
1610 MUST NOT be set in answer messages.
1612 r(eserved)
1614 These flag bits are reserved for future use, and MUST be set to
1615 zero, and ignored by the receiver.
1617 Command-Code
1619 The Command-Code field is three octets, and is used in order to
1620 communicate the command associated with the message. The 24-bit
1621 address space is managed by IANA (see Section 3.1).
1623 Command-Code values 16,777,214 and 16,777,215 (hexadecimal values
1624 FFFFFE -FFFFFF) are reserved for experimental use (See Section
1625 11.3).
1627 Application-ID
1629 Application-ID is four octets and is used to identify to which
1630 application the message is applicable for. The application can be
1631 an authentication application, an accounting application or a
1632 vendor specific application. See Section 11.3 for the possible
1633 values that the application-id may use.
1635 The value of the application-id field in the header MUST be the
1636 same as any relevant application-id AVPs contained in the message.
1638 Hop-by-Hop Identifier
1640 The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
1641 network byte order) and aids in matching requests and replies.
1642 The sender MUST ensure that the Hop-by-Hop identifier in a request
1643 is unique on a given connection at any given time, and MAY attempt
1644 to ensure that the number is unique across reboots. The sender of
1645 an Answer message MUST ensure that the Hop-by-Hop Identifier field
1646 contains the same value that was found in the corresponding
1647 request. The Hop-by-Hop identifier is normally a monotonically
1648 increasing number, whose start value was randomly generated. An
1649 answer message that is received with an unknown Hop-by-Hop
1650 Identifier MUST be discarded.
1652 End-to-End Identifier
1654 The End-to-End Identifier is an unsigned 32-bit integer field (in
1655 network byte order) and is used to detect duplicate messages.
1656 Upon reboot implementations MAY set the high order 12 bits to
1657 contain the low order 12 bits of current time, and the low order
1658 20 bits to a random value. Senders of request messages MUST
1659 insert a unique identifier on each message. The identifier MUST
1660 remain locally unique for a period of at least 4 minutes, even
1661 across reboots. The originator of an Answer message MUST ensure
1662 that the End-to-End Identifier field contains the same value that
1663 was found in the corresponding request. The End-to-End Identifier
1664 MUST NOT be modified by Diameter agents of any kind. The
1665 combination of the Origin-Host (see Section 6.3) and this field is
1666 used to detect duplicates. Duplicate requests SHOULD cause the
1667 same answer to be transmitted (modulo the hop-by-hop Identifier
1668 field and any routing AVPs that may be present), and MUST NOT
1669 affect any state that was set when the original request was
1670 processed. Duplicate answer messages that are to be locally
1671 consumed (see Section 6.2) SHOULD be silently discarded.
1673 AVPs
1675 AVPs are a method of encapsulating information relevant to the
1676 Diameter message. See Section 4 for more information on AVPs.
1678 3.1. Command Codes
1680 Each command Request/Answer pair is assigned a command code, and the
1681 sub-type (i.e., request or answer) is identified via the 'R' bit in
1682 the Command Flags field of the Diameter header.
1684 Every Diameter message MUST contain a command code in its header's
1685 Command-Code field, which is used to determine the action that is to
1686 be taken for a particular message. The following Command Codes are
1687 defined in the Diameter base protocol:
1689 Command-Name Abbrev. Code Reference
1690 --------------------------------------------------------
1691 Abort-Session-Request ASR 274 8.5.1
1692 Abort-Session-Answer ASA 274 8.5.2
1693 Accounting-Request ACR 271 9.7.1
1694 Accounting-Answer ACA 271 9.7.2
1695 Capabilities-Exchange- CER 257 5.3.1
1696 Request
1697 Capabilities-Exchange- CEA 257 5.3.2
1698 Answer
1699 Device-Watchdog-Request DWR 280 5.5.1
1700 Device-Watchdog-Answer DWA 280 5.5.2
1701 Disconnect-Peer-Request DPR 282 5.4.1
1702 Disconnect-Peer-Answer DPA 282 5.4.2
1703 Re-Auth-Request RAR 258 8.3.1
1704 Re-Auth-Answer RAA 258 8.3.2
1705 Session-Termination- STR 275 8.4.1
1706 Request
1707 Session-Termination- STA 275 8.4.2
1708 Answer
1710 3.2. Command Code ABNF specification
1712 Every Command Code defined MUST include a corresponding ABNF
1713 specification, which is used to define the AVPs that MUST or MAY be
1714 present when sending the message. The following format is used in
1715 the definition:
1717 command-def = "<" command-name ">" "::=" diameter-message
1719 command-name = diameter-name
1721 diameter-name = ALPHA *(ALPHA / DIGIT / "-")
1723 diameter-message = header *fixed *required *optional
1725 header = "<" "Diameter Header:" command-id
1726 [r-bit] [p-bit] [e-bit] [application-id] ">"
1728 application-id = 1*DIGIT
1730 command-id = 1*DIGIT
1731 ; The Command Code assigned to the command
1733 r-bit = ", REQ"
1734 ; If present, the 'R' bit in the Command
1735 ; Flags is set, indicating that the message
1736 ; is a request, as opposed to an answer.
1738 p-bit = ", PXY"
1739 ; If present, the 'P' bit in the Command
1740 ; Flags is set, indicating that the message
1741 ; is proxiable.
1743 e-bit = ", ERR"
1744 ; If present, the 'E' bit in the Command
1745 ; Flags is set, indicating that the answer
1746 ; message contains a Result-Code AVP in
1747 ; the "protocol error" class.
1749 fixed = [qual] "<" avp-spec ">"
1750 ; Defines the fixed position of an AVP
1752 required = [qual] "{" avp-spec "}"
1753 ; The AVP MUST be present and can appear
1754 ; anywhere in the message.
1756 optional = [qual] "[" avp-name "]"
1757 ; The avp-name in the 'optional' rule cannot
1758 ; evaluate to any AVP Name which is included
1759 ; in a fixed or required rule. The AVP can
1760 ; appear anywhere in the message.
1761 ;
1762 ; NOTE: "[" and "]" have a slightly different
1763 ; meaning than in ABNF (RFC 5234]). These braces
1764 ; cannot be used to express optional fixed rules
1765 ; (such as an optional ICV at the end). To do
1766 ; this, the convention is '0*1fixed'.
1768 qual = [min] "*" [max]
1769 ; See ABNF conventions, RFC 5234 Section 4.
1770 ; The absence of any qualifiers depends on
1771 ; whether it precedes a fixed, required, or
1772 ; optional rule. If a fixed or required rule has
1773 ; no qualifier, then exactly one such AVP MUST
1774 ; be present. If an optional rule has no
1775 ; qualifier, then 0 or 1 such AVP may be
1776 ; present. If an optional rule has a qualifier,
1777 ; then the value of min MUST be 0 if present.
1779 min = 1*DIGIT
1780 ; The minimum number of times the element may
1781 ; be present. If absent, the default value is zero
1782 ; for fixed and optional rules and one for
1783 ; required rules. The value MUST be at least one
1784 ; for required rules.
1786 max = 1*DIGIT
1787 ; The maximum number of times the element may
1788 ; be present. If absent, the default value is
1789 ; infinity. A value of zero implies the AVP MUST
1790 ; NOT be present.
1792 avp-spec = diameter-name
1793 ; The avp-spec has to be an AVP Name, defined
1794 ; in the base or extended Diameter
1795 ; specifications.
1797 avp-name = avp-spec / "AVP"
1798 ; The string "AVP" stands for *any* arbitrary AVP
1799 ; Name, not otherwise listed in that command code
1800 ; definition. Addition this AVP is recommended for
1801 ; all command ABNFs to allow for extensibility.
1803 The following is a definition of a fictitious command code:
1805 Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
1806 { User-Name }
1807 *1 { Origin-Host }
1808 * [ AVP ]
1810 3.3. Diameter Command Naming Conventions
1812 Diameter command names typically includes one or more English words
1813 followed by the verb Request or Answer. Each English word is
1814 delimited by a hyphen. A three-letter acronym for both the request
1815 and answer is also normally provided.
1817 An example is a message set used to terminate a session. The command
1818 name is Session-Terminate-Request and Session-Terminate-Answer, while
1819 the acronyms are STR and STA, respectively.
1821 Both the request and the answer for a given command share the same
1822 command code. The request is identified by the R(equest) bit in the
1823 Diameter header set to one (1), to ask that a particular action be
1824 performed, such as authorizing a user or terminating a session. Once
1825 the receiver has completed the request it issues the corresponding
1826 answer, which includes a result code that communicates one of the
1827 following:
1829 o The request was successful
1830 o The request failed
1832 o An additional request has to be sent to provide information the
1833 peer requires prior to returning a successful or failed answer.
1835 o The receiver could not process the request, but provides
1836 information about a Diameter peer that is able to satisfy the
1837 request, known as redirect.
1839 Additional information, encoded within AVPs, may also be included in
1840 answer messages.
1842 4. Diameter AVPs
1844 Diameter AVPs carry specific authentication, accounting,
1845 authorization and routing information as well as configuration
1846 details for the request and reply.
1848 Each AVP of type OctetString MUST be padded to align on a 32-bit
1849 boundary, while other AVP types align naturally. A number of zero-
1850 valued bytes are added to the end of the AVP Data field till a word
1851 boundary is reached. The length of the padding is not reflected in
1852 the AVP Length field.
1854 4.1. AVP Header
1856 The fields in the AVP header MUST be sent in network byte order. The
1857 format of the header is:
1859 0 1 2 3
1860 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
1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1862 | AVP Code |
1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1864 |V M P r r r r r| AVP Length |
1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1866 | Vendor-ID (opt) |
1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1868 | Data ...
1869 +-+-+-+-+-+-+-+-+
1871 AVP Code
1873 The AVP Code, combined with the Vendor-Id field, identifies the
1874 attribute uniquely. AVP numbers 1 through 255 are reserved for
1875 re-use of RADIUS attributes, without setting the Vendor-Id field.
1877 AVP numbers 256 and above are used for Diameter, which are
1878 allocated by IANA (see Section 11.1).
1880 AVP Flags
1882 The AVP Flags field informs the receiver how each attribute must
1883 be handled. New Diameter applications SHOULD NOT define
1884 additional AVP Flag bits. Note however, that new Diameter
1885 applications MAY define additional bits within the AVP Header, and
1886 an unrecognized bit SHOULD be considered an error. The sender of
1887 the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD
1888 ignore all 'r' (reserved) bits. The 'P' bit has been reserved for
1889 future usage of end-to-end security. At the time of writing there
1890 are no end-to-end security mechanisms specified therefore the 'P'
1891 bit SHOULD be set to 0.
1893 The 'M' Bit, known as the Mandatory bit, indicates whether the
1894 receiver of the AVP MUST parse and understand the semantic of the
1895 AVP including its content. The receiving entity MUST return an
1896 appropriate error message if it receives an AVP that has the M-bit
1897 set but does not understand it. An exception applies when the AVP
1898 is embedded within a Grouped AVP. See Section 4.4 for details.
1899 Diameter Relay and redirect agents MUST NOT reject messages with
1900 unrecognized AVPs.
1902 The 'M' bit MUST be set according to the rules defined in the
1903 application specification which introduces or re-uses this AVP.
1904 Within a given application, the M-bit setting for an AVP is either
1905 defined for all command types or for each command type.
1907 AVPs with the 'M' bit cleared are informational only and a
1908 receiver that receives a message with such an AVP that is not
1909 supported, or whose value is not supported, MAY simply ignore the
1910 AVP.
1912 The 'V' bit, known as the Vendor-Specific bit, indicates whether
1913 the optional Vendor-ID field is present in the AVP header. When
1914 set the AVP Code belongs to the specific vendor code address
1915 space.
1917 AVP Length
1919 The AVP Length field is three octets, and indicates the number of
1920 octets in this AVP including the AVP Code, AVP Length, AVP Flags,
1921 Vendor-ID field (if present) and the AVP data. If a message is
1922 received with an invalid attribute length, the message MUST be
1923 rejected.
1925 4.1.1. Optional Header Elements
1927 The AVP Header contains one optional field. This field is only
1928 present if the respective bit-flag is enabled.
1930 Vendor-ID
1932 The Vendor-ID field is present if the 'V' bit is set in the AVP
1933 Flags field. The optional four-octet Vendor-ID field contains the
1934 IANA assigned "SMI Network Management Private Enterprise Codes"
1935 [ENTERPRISE] value, encoded in network byte order. Any vendor or
1936 standardization organization that are also treated like vendors in
1937 the IANA managed "SMI Network Management Private Enterprise Codes"
1938 space wishing to implement a vendor-specific Diameter AVP MUST use
1939 their own Vendor-ID along with their privately managed AVP address
1940 space, guaranteeing that they will not collide with any other
1941 vendor's vendor-specific AVP(s), nor with future IETF AVPs.
1943 A vendor ID value of zero (0) corresponds to the IETF adopted AVP
1944 values, as managed by the IANA. Since the absence of the vendor
1945 ID field implies that the AVP in question is not vendor specific,
1946 implementations MUST NOT use the zero (0) vendor ID.
1948 4.2. Basic AVP Data Formats
1950 The Data field is zero or more octets and contains information
1951 specific to the Attribute. The format and length of the Data field
1952 is determined by the AVP Code and AVP Length fields. The format of
1953 the Data field MUST be one of the following base data types or a data
1954 type derived from the base data types. In the event that a new Basic
1955 AVP Data Format is needed, a new version of this RFC MUST be created.
1957 OctetString
1959 The data contains arbitrary data of variable length. Unless
1960 otherwise noted, the AVP Length field MUST be set to at least 8
1961 (12 if the 'V' bit is enabled). AVP Values of this type that are
1962 not a multiple of four-octets in length is followed by the
1963 necessary padding so that the next AVP (if any) will start on a
1964 32-bit boundary.
1966 Integer32
1968 32 bit signed value, in network byte order. The AVP Length field
1969 MUST be set to 12 (16 if the 'V' bit is enabled).
1971 Integer64
1973 64 bit signed value, in network byte order. The AVP Length field
1974 MUST be set to 16 (20 if the 'V' bit is enabled).
1976 Unsigned32
1978 32 bit unsigned value, in network byte order. The AVP Length
1979 field MUST be set to 12 (16 if the 'V' bit is enabled).
1981 Unsigned64
1983 64 bit unsigned value, in network byte order. The AVP Length
1984 field MUST be set to 16 (20 if the 'V' bit is enabled).
1986 Float32
1988 This represents floating point values of single precision as
1989 described by [FLOATPOINT]. The 32-bit value is transmitted in
1990 network byte order. The AVP Length field MUST be set to 12 (16 if
1991 the 'V' bit is enabled).
1993 Float64
1995 This represents floating point values of double precision as
1996 described by [FLOATPOINT]. The 64-bit value is transmitted in
1997 network byte order. The AVP Length field MUST be set to 16 (20 if
1998 the 'V' bit is enabled).
2000 Grouped
2002 The Data field is specified as a sequence of AVPs. Each of these
2003 AVPs follows - in the order in which they are specified -
2004 including their headers and padding. The AVP Length field is set
2005 to 8 (12 if the 'V' bit is enabled) plus the total length of all
2006 included AVPs, including their headers and padding. Thus the AVP
2007 length field of an AVP of type Grouped is always a multiple of 4.
2009 4.3. Derived AVP Data Formats
2011 In addition to using the Basic AVP Data Formats, applications may
2012 define data formats derived from the Basic AVP Data Formats. An
2013 application that defines new Derived AVP Data Formats MUST include
2014 them in a section entitled "Derived AVP Data Formats", using the same
2015 format as the definitions below. Each new definition MUST be either
2016 defined or listed with a reference to the RFC that defines the
2017 format.
2019 4.3.1. Common Derived AVP Data Formats
2021 The following are commonly used Derived AVP Data Formats.
2023 Address
2025 The Address format is derived from the OctetString AVP Base
2026 Format. It is a discriminated union, representing, for example a
2027 32-bit (IPv4) [RFC791] or 128-bit (IPv6) [RFC4291] address, most
2028 significant octet first. The first two octets of the Address AVP
2029 represents the AddressType, which contains an Address Family
2030 defined in [IANAADFAM]. The AddressType is used to discriminate
2031 the content and format of the remaining octets.
2033 Time
2035 The Time format is derived from the OctetString AVP Base Format.
2036 The string MUST contain four octets, in the same format as the
2037 first four bytes are in the NTP timestamp format. The NTP
2038 Timestamp format is defined in Chapter 3 of [RFC5905].
2040 This represents the number of seconds since 0h on 1 January 1900
2041 with respect to the Coordinated Universal Time (UTC).
2043 On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
2044 SNTP [RFC5905] describes a procedure to extend the time to 2104.
2045 This procedure MUST be supported by all Diameter nodes.
2047 UTF8String
2049 The UTF8String format is derived from the OctetString AVP Base
2050 Format. This is a human readable string represented using the
2051 ISO/IEC IS 10646-1 character set, encoded as an OctetString using
2052 the UTF-8 transformation format [RFC3629].
2054 Since additional code points are added by amendments to the 10646
2055 standard from time to time, implementations MUST be prepared to
2056 encounter any code point from 0x00000001 to 0x7fffffff. Byte
2057 sequences that do not correspond to the valid encoding of a code
2058 point into UTF-8 charset or are outside this range are prohibited.
2060 The use of control codes SHOULD be avoided. When it is necessary
2061 to represent a new line, the control code sequence CR LF SHOULD be
2062 used.
2064 The use of leading or trailing white space SHOULD be avoided.
2066 For code points not directly supported by user interface hardware
2067 or software, an alternative means of entry and display, such as
2068 hexadecimal, MAY be provided.
2070 For information encoded in 7-bit US-ASCII, the UTF-8 charset is
2071 identical to the US-ASCII charset.
2073 UTF-8 may require multiple bytes to represent a single character /
2074 code point; thus the length of an UTF8String in octets may be
2075 different from the number of characters encoded.
2077 Note that the AVP Length field of an UTF8String is measured in
2078 octets, not characters.
2080 DiameterIdentity
2082 The DiameterIdentity format is derived from the OctetString AVP
2083 Base Format.
2085 DiameterIdentity = FQDN/Realm
2087 DiameterIdentity value is used to uniquely identify either:
2089 * A Diameter node for purposes of duplicate connection and
2090 routing loop detection.
2092 * A Realm to determine whether messages can be satisfied locally,
2093 or whether they must be routed or redirected.
2095 When a DiameterIdentity is used to identify a Diameter node the
2096 contents of the string MUST be the FQDN of the Diameter node. If
2097 multiple Diameter nodes run on the same host, each Diameter node
2098 MUST be assigned a unique DiameterIdentity. If a Diameter node
2099 can be identified by several FQDNs, a single FQDN should be picked
2100 at startup, and used as the only DiameterIdentity for that node,
2101 whatever the connection it is sent on. Note that in this
2102 document, DiameterIdentity is in ASCII form in order to be
2103 compatible with existing DNS infrastructure. See Appendix D for
2104 interactions between the Diameter protocol and Internationalized
2105 Domain Name (IDNs).
2107 DiameterURI
2109 The DiameterURI MUST follow the Uniform Resource Identifiers
2110 (RFC3986) syntax [RFC3986] rules specified below:
2112 "aaa://" FQDN [ port ] [ transport ] [ protocol ]
2114 ; No transport security
2116 "aaas://" FQDN [ port ] [ transport ] [ protocol ]
2118 ; Transport security used
2120 FQDN = < Fully Qualified Domain Name >
2122 port = ":" 1*DIGIT
2124 ; One of the ports used to listen for
2125 ; incoming connections.
2126 ; If absent, the default Diameter port
2127 ; (3868) is assumed if no transport
2128 ; security is used and port (TBD) when
2129 ; transport security (TLS/TCP and DTLS/SCTP)
2130 ; is used.
2132 transport = ";transport=" transport-protocol
2134 ; One of the transports used to listen
2135 ; for incoming connections. If absent,
2136 ; the default protocol is assumed to be TCP.
2137 ; UDP MUST NOT be used when the aaa-protocol
2138 ; field is set to diameter.
2140 transport-protocol = ( "tcp" / "sctp" / "udp" )
2142 protocol = ";protocol=" aaa-protocol
2144 ; If absent, the default AAA protocol
2145 ; is Diameter.
2147 aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
2149 The following are examples of valid Diameter host identities:
2151 aaa://host.example.com;transport=tcp
2152 aaa://host.example.com:6666;transport=tcp
2153 aaa://host.example.com;protocol=diameter
2154 aaa://host.example.com:6666;protocol=diameter
2155 aaa://host.example.com:6666;transport=tcp;protocol=diameter
2156 aaa://host.example.com:1813;transport=udp;protocol=radius
2158 Enumerated
2160 Enumerated is derived from the Integer32 AVP Base Format. The
2161 definition contains a list of valid values and their
2162 interpretation and is described in the Diameter application
2163 introducing the AVP.
2165 IPFilterRule
2167 The IPFilterRule format is derived from the OctetString AVP Base
2168 Format and uses the ASCII charset. The rule syntax is a modified
2169 subset of ipfw(8) from FreeBSD. Packets may be filtered based on
2170 the following information that is associated with it:
2172 Direction (in or out)
2173 Source and destination IP address (possibly masked)
2174 Protocol
2175 Source and destination port (lists or ranges)
2176 TCP flags
2177 IP fragment flag
2178 IP options
2179 ICMP types
2181 Rules for the appropriate direction are evaluated in order, with
2182 the first matched rule terminating the evaluation. Each packet is
2183 evaluated once. If no rule matches, the packet is dropped if the
2184 last rule evaluated was a permit, and passed if the last rule was
2185 a deny.
2187 IPFilterRule filters MUST follow the format:
2189 action dir proto from src to dst [options]
2191 action permit - Allow packets that match the rule.
2192 deny - Drop packets that match the rule.
2194 dir "in" is from the terminal, "out" is to the
2195 terminal.
2197 proto An IP protocol specified by number. The "ip"
2198 keyword means any protocol will match.
2200 src and dst
[ports]
2202 The may be specified as:
2203 ipno An IPv4 or IPv6 number in dotted-
2204 quad or canonical IPv6 form. Only
2205 this exact IP number will match the
2206 rule.
2207 ipno/bits An IP number as above with a mask
2208 width of the form 192.0.2.10/24. In
2209 this case, all IP numbers from
2210 192.0.2.0 to 192.0.2.255 will match.
2211 The bit width MUST be valid for the
2212 IP version and the IP number MUST
2213 NOT have bits set beyond the mask.
2214 For a match to occur, the same IP
2215 version must be present in the
2216 packet that was used in describing
2217 the IP address. To test for a
2218 particular IP version, the bits part
2219 can be set to zero. The keyword
2220 "any" is 0.0.0.0/0 or the IPv6
2221 equivalent. The keyword "assigned"
2222 is the address or set of addresses
2223 assigned to the terminal. For IPv4,
2224 a typical first rule is often "deny
2225 in ip! assigned"
2227 The sense of the match can be inverted by
2228 preceding an address with the not modifier (!),
2229 causing all other addresses to be matched
2230 instead. This does not affect the selection of
2231 port numbers.
2233 With the TCP, UDP and SCTP protocols, optional
2234 ports may be specified as:
2236 {port/port-port}[,ports[,...]]
2238 The '-' notation specifies a range of ports
2239 (including boundaries).
2241 Fragmented packets that have a non-zero offset
2242 (i.e., not the first fragment) will never match
2243 a rule that has one or more port
2244 specifications. See the frag option for
2245 details on matching fragmented packets.
2247 options:
2248 frag Match if the packet is a fragment and this is not
2249 the first fragment of the datagram. frag may not
2250 be used in conjunction with either tcpflags or
2251 TCP/UDP port specifications.
2253 ipoptions spec
2254 Match if the IP header contains the comma
2255 separated list of options specified in spec. The
2256 supported IP options are:
2258 ssrr (strict source route), lsrr (loose source
2259 route), rr (record packet route) and ts
2260 (timestamp). The absence of a particular option
2261 may be denoted with a '!'.
2263 tcpoptions spec
2264 Match if the TCP header contains the comma
2265 separated list of options specified in spec. The
2266 supported TCP options are:
2268 mss (maximum segment size), window (tcp window
2269 advertisement), sack (selective ack), ts (rfc1323
2270 timestamp) and cc (rfc1644 t/tcp connection
2271 count). The absence of a particular option may
2272 be denoted with a '!'.
2274 established
2275 TCP packets only. Match packets that have the RST
2276 or ACK bits set.
2278 setup TCP packets only. Match packets that have the SYN
2279 bit set but no ACK bit.
2281 tcpflags spec
2282 TCP packets only. Match if the TCP header
2283 contains the comma separated list of flags
2284 specified in spec. The supported TCP flags are:
2286 fin, syn, rst, psh, ack and urg. The absence of a
2287 particular flag may be denoted with a '!'. A rule
2288 that contains a tcpflags specification can never
2289 match a fragmented packet that has a non-zero
2290 offset. See the frag option for details on
2291 matching fragmented packets.
2293 icmptypes types
2294 ICMP packets only. Match if the ICMP type is in
2295 the list types. The list may be specified as any
2296 combination of ranges or individual types
2297 separated by commas. Both the numeric values and
2298 the symbolic values listed below can be used. The
2299 supported ICMP types are:
2301 echo reply (0), destination unreachable (3),
2302 source quench (4), redirect (5), echo request
2303 (8), router advertisement (9), router
2304 solicitation (10), time-to-live exceeded (11), IP
2305 header bad (12), timestamp request (13),
2306 timestamp reply (14), information request (15),
2307 information reply (16), address mask request (17)
2308 and address mask reply (18).
2310 There is one kind of packet that the access device MUST always
2311 discard, that is an IP fragment with a fragment offset of one.
2312 This is a valid packet, but it only has one use, to try to
2313 circumvent firewalls.
2315 An access device that is unable to interpret or apply a deny rule
2316 MUST terminate the session. An access device that is unable to
2317 interpret or apply a permit rule MAY apply a more restrictive
2318 rule. An access device MAY apply deny rules of its own before the
2319 supplied rules, for example to protect the access device owner's
2320 infrastructure.
2322 4.4. Grouped AVP Values
2324 The Diameter protocol allows AVP values of type 'Grouped'. This
2325 implies that the Data field is actually a sequence of AVPs. It is
2326 possible to include an AVP with a Grouped type within a Grouped type,
2327 that is, to nest them. AVPs within an AVP of type Grouped have the
2328 same padding requirements as non-Grouped AVPs, as defined in Section
2329 4.
2331 The AVP Code numbering space of all AVPs included in a Grouped AVP is
2332 the same as for non-grouped AVPs. Receivers of a Grouped AVP that
2333 does not have the 'M' (mandatory) bit set and one or more of the
2334 encapsulated AVPs within the group has the 'M' (mandatory) bit set
2335 MAY simply be ignored if the Grouped AVP itself is unrecognized. The
2336 rule applies even if the encapsulated AVP with its 'M' (mandatory)
2337 bit set is further encapsulated within other sub-groups; i.e. other
2338 Grouped AVPs embedded within the Grouped AVP.
2340 Every Grouped AVP defined MUST include a corresponding grammar, using
2341 ABNF [RFC5234] (with modifications), as defined below.
2343 grouped-avp-def = "::=" avp
2345 name-fmt = ALPHA *(ALPHA / DIGIT / "-")
2347 name = name-fmt
2348 ; The name has to be the name of an AVP,
2349 ; defined in the base or extended Diameter
2350 ; specifications.
2352 avp = header [ *fixed] [ *required] [ *optional]
2354 header = "<" "AVP-Header:" avpcode [vendor] ">"
2356 avpcode = 1*DIGIT
2357 ; The AVP Code assigned to the Grouped AVP
2359 vendor = 1*DIGIT
2360 ; The Vendor-ID assigned to the Grouped AVP.
2361 ; If absent, the default value of zero is
2362 ; used.
2364 4.4.1. Example AVP with a Grouped Data type
2366 The Example-AVP (AVP Code 999999) is of type Grouped and is used to
2367 clarify how Grouped AVP values work. The Grouped Data field has the
2368 following ABNF grammar:
2370 Example-AVP ::= < AVP Header: 999999 >
2371 { Origin-Host }
2372 1*{ Session-Id }
2373 *[ AVP ]
2375 An Example-AVP with Grouped Data follows.
2377 The Origin-Host AVP is required (Section 6.3). In this case:
2379 Origin-Host = "example.com".
2381 One or more Session-Ids must follow. Here there are two:
2383 Session-Id =
2384 "grump.example.com:33041;23432;893;0AF3B81"
2386 Session-Id =
2387 "grump.example.com:33054;23561;2358;0AF3B82"
2389 optional AVPs included are
2391 Recovery-Policy =
2392 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2393 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
2394 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
2395 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
2396 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
2397 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
2398 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
2400 Futuristic-Acct-Record =
2401 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
2402 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
2403 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
2404 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
2405 d3427475e49968f841
2407 The data for the optional AVPs is represented in hex since the format
2408 of these AVPs is neither known at the time of definition of the
2409 Example-AVP group, nor (likely) at the time when the example instance
2410 of this AVP is interpreted - except by Diameter implementations which
2411 support the same set of AVPs. The encoding example illustrates how
2412 padding is used and how length fields are calculated. Also note that
2413 AVPs may be present in the Grouped AVP value which the receiver
2414 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record
2415 AVPs). The length of the Example-AVP is the sum of all the length of
2416 the member AVPs including their padding plus the Example-AVP header
2417 size.
2419 This AVP would be encoded as follows:
2421 0 1 2 3 4 5 6 7
2422 +-------+-------+-------+-------+-------+-------+-------+-------+
2423 0 | Example AVP Header (AVP Code = 999999), Length = 496 |
2424 +-------+-------+-------+-------+-------+-------+-------+-------+
2425 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
2426 +-------+-------+-------+-------+-------+-------+-------+-------+
2427 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
2428 +-------+-------+-------+-------+-------+-------+-------+-------+
2429 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
2430 +-------+-------+-------+-------+-------+-------+-------+-------+
2431 32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
2432 +-------+-------+-------+-------+-------+-------+-------+-------+
2433 . . .
2434 +-------+-------+-------+-------+-------+-------+-------+-------+
2435 72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
2436 +-------+-------+-------+-------+-------+-------+-------+-------+
2437 80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
2438 +-------+-------+-------+-------+-------+-------+-------+-------+
2439 88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
2440 +-------+-------+-------+-------+-------+-------+-------+-------+
2441 . . .
2442 +-------+-------+-------+-------+-------+-------+-------+-------+
2443 120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
2444 +-------+-------+-------+-------+-------+-------+-------+-------+
2445 128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
2446 +-------+-------+-------+-------+-------+-------+-------+-------+
2447 136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
2448 +-------+-------+-------+-------+-------+-------+-------+-------+
2449 144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
2450 +-------+-------+-------+-------+-------+-------+-------+-------+
2451 . . .
2452 +-------+-------+-------+-------+-------+-------+-------+-------+
2453 352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
2454 +-------+-------+-------+-------+-------+-------+-------+-------+
2455 328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
2456 +-------+-------+-------+-------+-------+-------+-------+-------+
2457 336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
2458 +-------+-------+-------+-------+-------+-------+-------+-------+
2459 . . .
2460 +-------+-------+-------+-------+-------+-------+-------+-------+
2461 488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
2462 +-------+-------+-------+-------+-------+-------+-------+-------+
2464 4.5. Diameter Base Protocol AVPs
2466 The following table describes the Diameter AVPs defined in the base
2467 protocol, their AVP Code values, types, possible flag values.
2469 Due to space constraints, the short form DiamIdent is used to
2470 represent DiameterIdentity.
2472 +----------+
2473 | AVP Flag |
2474 | rules |
2475 |----+-----|
2476 AVP Section | |MUST |
2477 Attribute Name Code Defined Data Type |MUST| NOT |
2478 -----------------------------------------|----+-----|
2479 Acct- 85 9.8.2 Unsigned32 | M | V |
2480 Interim-Interval | | |
2481 Accounting- 483 9.8.7 Enumerated | M | V |
2482 Realtime-Required | | |
2483 Acct- 50 9.8.5 UTF8String | M | V |
2484 Multi-Session-Id | | |
2485 Accounting- 485 9.8.3 Unsigned32 | M | V |
2486 Record-Number | | |
2487 Accounting- 480 9.8.1 Enumerated | M | V |
2488 Record-Type | | |
2489 Accounting- 44 9.8.4 OctetString| M | V |
2490 Session-Id | | |
2491 Accounting- 287 9.8.6 Unsigned64 | M | V |
2492 Sub-Session-Id | | |
2493 Acct- 259 6.9 Unsigned32 | M | V |
2494 Application-Id | | |
2495 Auth- 258 6.8 Unsigned32 | M | V |
2496 Application-Id | | |
2497 Auth-Request- 274 8.7 Enumerated | M | V |
2498 Type | | |
2499 Authorization- 291 8.9 Unsigned32 | M | V |
2500 Lifetime | | |
2501 Auth-Grace- 276 8.10 Unsigned32 | M | V |
2502 Period | | |
2503 Auth-Session- 277 8.11 Enumerated | M | V |
2504 State | | |
2505 Re-Auth-Request- 285 8.12 Enumerated | M | V |
2506 Type | | |
2507 Class 25 8.20 OctetString| M | V |
2508 Destination-Host 293 6.5 DiamIdent | M | V |
2509 Destination- 283 6.6 DiamIdent | M | V |
2510 Realm | | |
2511 Disconnect-Cause 273 5.4.3 Enumerated | M | V |
2512 Error-Message 281 7.3 UTF8String | | V,M |
2513 Error-Reporting- 294 7.4 DiamIdent | | V,M |
2514 Host | | |
2515 Event-Timestamp 55 8.21 Time | M | V |
2516 Experimental- 297 7.6 Grouped | M | V |
2517 Result | | |
2518 -----------------------------------------|----+-----|
2519 +----------+
2520 | AVP Flag |
2521 | rules |
2522 |----+-----|
2523 AVP Section | |MUST |
2524 Attribute Name Code Defined Data Type |MUST| NOT |
2525 -----------------------------------------|----+-----|
2526 Experimental- 298 7.7 Unsigned32 | M | V |
2527 Result-Code | | |
2528 Failed-AVP 279 7.5 Grouped | M | V |
2529 Firmware- 267 5.3.4 Unsigned32 | | V,M |
2530 Revision | | |
2531 Host-IP-Address 257 5.3.5 Address | M | V |
2532 Inband-Security | M | V |
2533 -Id 299 6.10 Unsigned32 | | |
2534 Multi-Round- 272 8.19 Unsigned32 | M | V |
2535 Time-Out | | |
2536 Origin-Host 264 6.3 DiamIdent | M | V |
2537 Origin-Realm 296 6.4 DiamIdent | M | V |
2538 Origin-State-Id 278 8.16 Unsigned32 | M | V |
2539 Product-Name 269 5.3.7 UTF8String | | V,M |
2540 Proxy-Host 280 6.7.3 DiamIdent | M | V |
2541 Proxy-Info 284 6.7.2 Grouped | M | V |
2542 Proxy-State 33 6.7.4 OctetString| M | V |
2543 Redirect-Host 292 6.12 DiamURI | M | V |
2544 Redirect-Host- 261 6.13 Enumerated | M | V |
2545 Usage | | |
2546 Redirect-Max- 262 6.14 Unsigned32 | M | V |
2547 Cache-Time | | |
2548 Result-Code 268 7.1 Unsigned32 | M | V |
2549 Route-Record 282 6.7.1 DiamIdent | M | V |
2550 Session-Id 263 8.8 UTF8String | M | V |
2551 Session-Timeout 27 8.13 Unsigned32 | M | V |
2552 Session-Binding 270 8.17 Unsigned32 | M | V |
2553 Session-Server- 271 8.18 Enumerated | M | V |
2554 Failover | | |
2555 Supported- 265 5.3.6 Unsigned32 | M | V |
2556 Vendor-Id | | |
2557 Termination- 295 8.15 Enumerated | M | V |
2558 Cause | | |
2559 User-Name 1 8.14 UTF8String | M | V |
2560 Vendor-Id 266 5.3.3 Unsigned32 | M | V |
2561 Vendor-Specific- 260 6.11 Grouped | M | V |
2562 Application-Id | | |
2563 -----------------------------------------|----+-----|
2565 5. Diameter Peers
2567 This section describes how Diameter nodes establish connections and
2568 communicate with peers.
2570 5.1. Peer Connections
2572 Connections between diameter peers are established using their valid
2573 DiameterIdentity. A Diameter node initiating a connection to a peer
2574 MUST know the peers DiameterIdentity. Methods for discovering a
2575 Diameter peer can be found in Section 5.2.
2577 Although a Diameter node may have many possible peers that it is able
2578 to communicate with, it may not be economical to have an established
2579 connection to all of them. At a minimum, a Diameter node SHOULD have
2580 an established connection with two peers per realm, known as the
2581 primary and secondary peers. Of course, a node MAY have additional
2582 connections, if it is deemed necessary. Typically, all messages for
2583 a realm are sent to the primary peer, but in the event that failover
2584 procedures are invoked, any pending requests are sent to the
2585 secondary peer. However, implementations are free to load balance
2586 requests between a set of peers.
2588 Note that a given peer MAY act as a primary for a given realm, while
2589 acting as a secondary for another realm.
2591 When a peer is deemed suspect, which could occur for various reasons,
2592 including not receiving a DWA within an allotted timeframe, no new
2593 requests should be forwarded to the peer, but failover procedures are
2594 invoked. When an active peer is moved to this mode, additional
2595 connections SHOULD be established to ensure that the necessary number
2596 of active connections exists.
2598 There are two ways that a peer is removed from the suspect peer list:
2600 1. The peer is no longer reachable, causing the transport connection
2601 to be shutdown. The peer is moved to the closed state.
2603 2. Three watchdog messages are exchanged with accepted round trip
2604 times, and the connection to the peer is considered stabilized.
2606 In the event the peer being removed is either the primary or
2607 secondary, an alternate peer SHOULD replace the deleted peer, and
2608 assume the role of either primary or secondary.
2610 5.2. Diameter Peer Discovery
2612 Allowing for dynamic Diameter agent discovery will make it possible
2613 for simpler and more robust deployment of Diameter services. In
2614 order to promote interoperable implementations of Diameter peer
2615 discovery, the following mechanisms are described. These are based
2616 on existing IETF standards. The first option (manual configuration)
2617 MUST be supported by all Diameter nodes, while the latter option
2618 (DNS) MAY be supported.
2620 There are two cases where Diameter peer discovery may be performed.
2621 The first is when a Diameter client needs to discover a first-hop
2622 Diameter agent. The second case is when a Diameter agent needs to
2623 discover another agent - for further handling of a Diameter
2624 operation. In both cases, the following 'search order' is
2625 recommended:
2627 1. The Diameter implementation consults its list of static
2628 (manually) configured Diameter agent locations. These will be
2629 used if they exist and respond.
2631 2. The Diameter implementation performs a NAPTR query for a server
2632 in a particular realm. The Diameter implementation has to know
2633 in advance which realm to look for a Diameter agent. This could
2634 be deduced, for example, from the 'realm' in a NAI that a
2635 Diameter implementation needed to perform a Diameter operation
2636 on.
2638 The NAPTR usage in Diameter follows the S-NAPTR DDDS application
2639 [RFC3958] in which the SERVICE field includes tags for the
2640 desired application and supported application protocol. The
2641 application service tag for a Diameter application is 'aaa' and
2642 the supported application protocol tags are 'diameter.tcp',
2643 'diameter.sctp', 'diameter.dtls' or 'diameter.tls.tcp' [RFC6408].
2645 The client can follow the resolution process defined by the
2646 S-NAPTR DDDS [RFC3958] application to find a matching SRV, A or
2647 AAAA record of a suitable peer. The domain suffixes in the NAPTR
2648 replacement field SHOULD match the domain of the original query.
2649 An example can be found in Appendix B.
2651 3. If no NAPTR records are found, the requester directly queries for
2652 one of the following SRV records: for Diameter over TCP, use
2653 "_diameter._tcp.realm"; for Diameter over TLS, use
2654 "_diameters._tcp.realm"; for Diameter over SCTP, use
2655 "_diameter._sctp.realm"; for Diameter over DTLS, use
2656 "_diameters._sctp.realm". If SRV records are found then the
2657 requester can perform address record query (A RR's and/or AAAA
2658 RR's) for the target hostname specified in the SRV records
2659 following the rules given in Gulbrandsen, et al. [RFC2782]. If
2660 no SRV records are found, the requester gives up.
2662 If the server is using a site certificate, the domain name in the
2663 NAPTR query and the domain name in the replacement field MUST both be
2664 valid based on the site certificate handed out by the server in the
2665 TLS/TCP and DTLS/SCTP or IKE exchange. Similarly, the domain name in
2666 the SRV query and the domain name in the target in the SRV record
2667 MUST both be valid based on the same site certificate. Otherwise, an
2668 attacker could modify the DNS records to contain replacement values
2669 in a different domain, and the client could not validate that this
2670 was the desired behavior, or the result of an attack.
2672 Also, the Diameter Peer MUST check to make sure that the discovered
2673 peers are authorized to act in its role. Authentication via IKE or
2674 TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not
2675 sufficient to conclude this. For example, a web server may have
2676 obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs
2677 may be included in the DNS, but this does not imply that it is
2678 authorized to act as a Diameter Server.
2680 Authorization can be achieved for example, by configuration of a
2681 Diameter Server Certification Authority (CA). The Server CA issues a
2682 certificate to the Diameter Server, which includes an Object
2683 Identifier (OID) to indicate the subject is a Diameter Server in the
2684 Extended Key Usage extension [RFC5280]. This certificate is then
2685 used during TLS/TCP, DTLS/SCTP, or IKE security negotiation. Note,
2686 however, that at the time of writing no Diameter Server Certification
2687 Authorities exist.
2689 A dynamically discovered peer causes an entry in the Peer Table (see
2690 Section 2.6) to be created. Note that entries created via DNS MUST
2691 expire (or be refreshed) within the DNS TTL. If a peer is discovered
2692 outside of the local realm, a routing table entry (see Section 2.7)
2693 for the peer's realm is created. The routing table entry's
2694 expiration MUST match the peer's expiration value.
2696 5.3. Capabilities Exchange
2698 When two Diameter peers establish a transport connection, they MUST
2699 exchange the Capabilities Exchange messages, as specified in the peer
2700 state machine (see Section 5.6). This message allows the discovery
2701 of a peer's identity and its capabilities (protocol version number,
2702 the identifiers of supported Diameter applications, security
2703 mechanisms, etc.)
2704 The receiver only issues commands to its peers that have advertised
2705 support for the Diameter application that defines the command. A
2706 Diameter node MUST cache the supported Application Ids in order to
2707 ensure that unrecognized commands and/or AVPs are not unnecessarily
2708 sent to a peer.
2710 A receiver of a Capabilities-Exchange-Req (CER) message that does not
2711 have any applications in common with the sender MUST return a
2712 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
2713 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
2714 layer connection. Note that receiving a CER or CEA from a peer
2715 advertising itself as a Relay (see Section 2.4) MUST be interpreted
2716 as having common applications with the peer.
2718 The receiver of the Capabilities-Exchange-Request (CER) MUST
2719 determine common applications by computing the intersection of its
2720 own set of supported Application Id against all of the application
2721 identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-
2722 Specific-Application-Id) present in the CER. The value of the
2723 Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
2724 during computation. The sender of the Capabilities-Exchange-Answer
2725 (CEA) SHOULD include all of its supported applications as a hint to
2726 the receiver regarding all of its application capabilities.
2728 Diameter implementations SHOULD first attempt to establish a TLS/TCP
2729 and DTLS/SCTP connection prior to the CER/CEA exchange. This
2730 protects the capabilities information of both peers. To support
2731 older Diameter implementations that do not fully conform to this
2732 document, the transport security MAY still be negotiated via Inband-
2733 Security AVP. In this case, the receiver of a Capabilities-Exchange-
2734 Req (CER) message that does not have any security mechanisms in
2735 common with the sender MUST return a Capabilities-Exchange-Answer
2736 (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY,
2737 and SHOULD disconnect the transport layer connection.
2739 CERs received from unknown peers MAY be silently discarded, or a CEA
2740 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
2741 In both cases, the transport connection is closed. If the local
2742 policy permits receiving CERs from unknown hosts, a successful CEA
2743 MAY be returned. If a CER from an unknown peer is answered with a
2744 successful CEA, the lifetime of the peer entry is equal to the
2745 lifetime of the transport connection. In case of a transport
2746 failure, all the pending transactions destined to the unknown peer
2747 can be discarded.
2749 The CER and CEA messages MUST NOT be proxied, redirected or relayed.
2751 Since the CER/CEA messages cannot be proxied, it is still possible
2752 that an upstream agent receives a message for which it has no
2753 available peers to handle the application that corresponds to the
2754 Command-Code. In such instances, the 'E' bit is set in the answer
2755 message (Section 7) with the Result-Code AVP set to
2756 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action
2757 (e.g., re-routing request to an alternate peer).
2759 With the exception of the Capabilities-Exchange-Request message, a
2760 message of type Request that includes the Auth-Application-Id or
2761 Acct-Application-Id AVPs, or a message with an application-specific
2762 command code, MAY only be forwarded to a host that has explicitly
2763 advertised support for the application (or has advertised the Relay
2764 Application Id).
2766 5.3.1. Capabilities-Exchange-Request
2768 The Capabilities-Exchange-Request (CER), indicated by the Command-
2769 Code set to 257 and the Command Flags' 'R' bit set, is sent to
2770 exchange local capabilities. Upon detection of a transport failure,
2771 this message MUST NOT be sent to an alternate peer.
2773 When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
2774 which allow for connections to span multiple interfaces and multiple
2775 IP addresses, the Capabilities-Exchange-Request message MUST contain
2776 one Host-IP-Address AVP for each potential IP address that MAY be
2777 locally used when transmitting Diameter messages.
2779 Message Format
2781 ::= < Diameter Header: 257, REQ >
2782 { Origin-Host }
2783 { Origin-Realm }
2784 1* { Host-IP-Address }
2785 { Vendor-Id }
2786 { Product-Name }
2787 [ Origin-State-Id ]
2788 * [ Supported-Vendor-Id ]
2789 * [ Auth-Application-Id ]
2790 * [ Inband-Security-Id ]
2791 * [ Acct-Application-Id ]
2792 * [ Vendor-Specific-Application-Id ]
2793 [ Firmware-Revision ]
2794 * [ AVP ]
2796 5.3.2. Capabilities-Exchange-Answer
2798 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code
2799 set to 257 and the Command Flags' 'R' bit cleared, is sent in
2800 response to a CER message.
2802 When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
2803 which allow connections to span multiple interfaces, hence, multiple
2804 IP addresses, the Capabilities-Exchange-Answer message MUST contain
2805 one Host-IP-Address AVP for each potential IP address that MAY be
2806 locally used when transmitting Diameter messages.
2808 Message Format
2810 ::= < Diameter Header: 257 >
2811 { Result-Code }
2812 { Origin-Host }
2813 { Origin-Realm }
2814 1* { Host-IP-Address }
2815 { Vendor-Id }
2816 { Product-Name }
2817 [ Origin-State-Id ]
2818 [ Error-Message ]
2819 [ Failed-AVP ]
2820 * [ Supported-Vendor-Id ]
2821 * [ Auth-Application-Id ]
2822 * [ Inband-Security-Id ]
2823 * [ Acct-Application-Id ]
2824 * [ Vendor-Specific-Application-Id ]
2825 [ Firmware-Revision ]
2826 * [ AVP ]
2828 5.3.3. Vendor-Id AVP
2830 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
2831 the IANA "SMI Network Management Private Enterprise Codes"
2832 [ENTERPRISE] value assigned to the Diameter Software vendor. It is
2833 envisioned that the combination of the Vendor-Id, Product-Name
2834 (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs may
2835 provide useful debugging information.
2837 A Vendor-Id value of zero in the CER or CEA messages is reserved and
2838 indicates that this field is ignored.
2840 5.3.4. Firmware-Revision AVP
2842 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
2843 used to inform a Diameter peer of the firmware revision of the
2844 issuing device.
2846 For devices that do not have a firmware revision (general purpose
2847 computers running Diameter software modules, for instance), the
2848 revision of the Diameter software module may be reported instead.
2850 5.3.5. Host-IP-Address AVP
2852 The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
2853 to inform a Diameter peer of the sender's IP address. All source
2854 addresses that a Diameter node expects to use with SCTP [RFC4960] or
2855 DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
2856 including a Host-IP-Address AVP for each address.
2858 5.3.6. Supported-Vendor-Id AVP
2860 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
2861 contains the IANA "SMI Network Management Private Enterprise Codes"
2862 [ENTERPRISE] value assigned to a vendor other than the device vendor
2863 but including the application vendor. This is used in the CER and
2864 CEA messages in order to inform the peer that the sender supports (a
2865 subset of) the vendor-specific AVPs defined by the vendor identified
2866 in this AVP. The value of this AVP MUST NOT be set to zero.
2867 Multiple instances of this AVP containing the same value SHOULD NOT
2868 be sent.
2870 5.3.7. Product-Name AVP
2872 The Product-Name AVP (AVP Code 269) is of type UTF8String, and
2873 contains the vendor assigned name for the product. The Product-Name
2874 AVP SHOULD remain constant across firmware revisions for the same
2875 product.
2877 5.4. Disconnecting Peer connections
2879 When a Diameter node disconnects one of its transport connections,
2880 its peer cannot know the reason for the disconnect, and will most
2881 likely assume that a connectivity problem occurred, or that the peer
2882 has rebooted. In these cases, the peer may periodically attempt to
2883 reconnect, as stated in Section 2.1. In the event that the
2884 disconnect was a result of either a shortage of internal resources,
2885 or simply that the node in question has no intentions of forwarding
2886 any Diameter messages to the peer in the foreseeable future, a
2887 periodic connection request would not be welcomed. The
2888 Disconnection-Reason AVP contains the reason the Diameter node issued
2889 the Disconnect-Peer-Request message.
2891 The Disconnect-Peer-Request message is used by a Diameter node to
2892 inform its peer of its intent to disconnect the transport layer, and
2893 that the peer shouldn't reconnect unless it has a valid reason to do
2894 so (e.g., message to be forwarded). Upon receipt of the message, the
2895 Disconnect-Peer-Answer is returned, which SHOULD contain an error if
2896 messages have recently been forwarded, and are likely in flight,
2897 which would otherwise cause a race condition.
2899 The receiver of the Disconnect-Peer-Answer initiates the transport
2900 disconnect. The sender of the Disconnect-Peer-Answer should be able
2901 to detect the transport closure and cleanup the connection.
2903 5.4.1. Disconnect-Peer-Request
2905 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set
2906 to 282 and the Command Flags' 'R' bit set, is sent to a peer to
2907 inform its intentions to shutdown the transport connection. Upon
2908 detection of a transport failure, this message MUST NOT be sent to an
2909 alternate peer.
2911 Message Format
2913 ::= < Diameter Header: 282, REQ >
2914 { Origin-Host }
2915 { Origin-Realm }
2916 { Disconnect-Cause }
2917 * [ AVP ]
2919 5.4.2. Disconnect-Peer-Answer
2921 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set
2922 to 282 and the Command Flags' 'R' bit cleared, is sent as a response
2923 to the Disconnect-Peer-Request message. Upon receipt of this
2924 message, the transport connection is shutdown.
2926 Message Format
2928 ::= < Diameter Header: 282 >
2929 { Result-Code }
2930 { Origin-Host }
2931 { Origin-Realm }
2932 [ Error-Message ]
2933 [ Failed-AVP ]
2934 * [ AVP ]
2936 5.4.3. Disconnect-Cause AVP
2938 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
2939 Diameter node MUST include this AVP in the Disconnect-Peer-Request
2940 message to inform the peer of the reason for its intention to
2941 shutdown the transport connection. The following values are
2942 supported:
2944 REBOOTING 0
2945 A scheduled reboot is imminent. Receiver of DPR with above
2946 result code MAY attempt reconnection.
2948 BUSY 1
2949 The peer's internal resources are constrained, and it has
2950 determined that the transport connection needs to be closed.
2951 Receiver of DPR with above result code SHOULD NOT attempt
2952 reconnection.
2954 DO_NOT_WANT_TO_TALK_TO_YOU 2
2955 The peer has determined that it does not see a need for the
2956 transport connection to exist, since it does not expect any
2957 messages to be exchanged in the near future. Receiver of DPR
2958 with above result code SHOULD NOT attempt reconnection.
2960 5.5. Transport Failure Detection
2962 Given the nature of the Diameter protocol, it is recommended that
2963 transport failures be detected as soon as possible. Detecting such
2964 failures will minimize the occurrence of messages sent to unavailable
2965 agents, resulting in unnecessary delays, and will provide better
2966 failover performance. The Device-Watchdog-Request and Device-
2967 Watchdog-Answer messages, defined in this section, are used to pro-
2968 actively detect transport failures.
2970 5.5.1. Device-Watchdog-Request
2972 The Device-Watchdog-Request (DWR), indicated by the Command-Code set
2973 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
2974 traffic has been exchanged between two peers (see Section 5.5.3).
2975 Upon detection of a transport failure, this message MUST NOT be sent
2976 to an alternate peer.
2978 Message Format
2980 ::= < Diameter Header: 280, REQ >
2981 { Origin-Host }
2982 { Origin-Realm }
2983 [ Origin-State-Id ]
2985 * [ AVP ]
2987 5.5.2. Device-Watchdog-Answer
2989 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
2990 to 280 and the Command Flags' 'R' bit cleared, is sent as a response
2991 to the Device-Watchdog-Request message.
2993 Message Format
2995 ::= < Diameter Header: 280 >
2996 { Result-Code }
2997 { Origin-Host }
2998 { Origin-Realm }
2999 [ Error-Message ]
3000 [ Failed-AVP ]
3001 [ Origin-State-Id ]
3002 * [ AVP ]
3004 5.5.3. Transport Failure Algorithm
3006 The transport failure algorithm is defined in [RFC3539]. All
3007 Diameter implementations MUST support the algorithm defined in the
3008 specification in order to be compliant to the Diameter base protocol.
3010 5.5.4. Failover and Failback Procedures
3012 In the event that a transport failure is detected with a peer, it is
3013 necessary for all pending request messages to be forwarded to an
3014 alternate agent, if possible. This is commonly referred to as
3015 failover.
3017 In order for a Diameter node to perform failover procedures, it is
3018 necessary for the node to maintain a pending message queue for a
3019 given peer. When an answer message is received, the corresponding
3020 request is removed from the queue. The Hop-by-Hop Identifier field
3021 is used to match the answer with the queued request.
3023 When a transport failure is detected, if possible all messages in the
3024 queue are sent to an alternate agent with the T flag set. On booting
3025 a Diameter client or agent, the T flag is also set on any records
3026 still remaining to be transmitted in non-volatile storage. An
3027 example of a case where it is not possible to forward the message to
3028 an alternate server is when the message has a fixed destination, and
3029 the unavailable peer is the message's final destination (see
3030 Destination-Host AVP). Such an error requires that the agent return
3031 an answer message with the 'E' bit set and the Result-Code AVP set to
3032 DIAMETER_UNABLE_TO_DELIVER.
3034 It is important to note that multiple identical requests or answers
3035 MAY be received as a result of a failover. The End-to-End Identifier
3036 field in the Diameter header along with the Origin-Host AVP MUST be
3037 used to identify duplicate messages.
3039 As described in Section 2.1, a connection request should be
3040 periodically attempted with the failed peer in order to re-establish
3041 the transport connection. Once a connection has been successfully
3042 established, messages can once again be forwarded to the peer. This
3043 is commonly referred to as failback.
3045 5.6. Peer State Machine
3047 This section contains a finite state machine that MUST be observed by
3048 all Diameter implementations. Each Diameter node MUST follow the
3049 state machine described below when communicating with each peer.
3050 Multiple actions are separated by commas, and may continue on
3051 succeeding lines, as space requires. Similarly, state and next state
3052 may also span multiple lines, as space requires.
3054 This state machine is closely coupled with the state machine
3055 described in [RFC3539], which is used to open, close, failover,
3056 probe, and reopen transport connections. Note in particular that
3057 [RFC3539] requires the use of watchdog messages to probe connections.
3058 For Diameter, DWR and DWA messages are to be used.
3060 I- is used to represent the initiator (connecting) connection, while
3061 the R- is used to represent the responder (listening) connection.
3062 The lack of a prefix indicates that the event or action is the same
3063 regardless of the connection on which the event occurred.
3065 The stable states that a state machine may be in are Closed, I-Open
3066 and R-Open; all other states are intermediate. Note that I-Open and
3067 R-Open are equivalent except for whether the initiator or responder
3068 transport connection is used for communication.
3070 A CER message is always sent on the initiating connection immediately
3071 after the connection request is successfully completed. In the case
3072 of an election, one of the two connections will shut down. The
3073 responder connection will survive if the Origin-Host of the local
3074 Diameter entity is higher than that of the peer; the initiator
3075 connection will survive if the peer's Origin-Host is higher. All
3076 subsequent messages are sent on the surviving connection. Note that
3077 the results of an election on one peer are guaranteed to be the
3078 inverse of the results on the other.
3080 For TLS/TCP and DTLS/SCTP usage, TLS/TCP and DTLS/SCTP handshake
3081 SHOULD begin when both ends are in the closed state prior to any
3082 Diameter message exchanges. The TLS/TCP and DTLS/SCTP connection
3083 SHOULD be established before sending any CER or CEA message to secure
3084 and protect the capabilities information of both peers. The TLS/TCP
3085 and DTLS/SCTP connection SHOULD be disconnected when the state
3086 machine moves to the closed state. When connecting to responders
3087 that do not conform to this document (i.e. older Diameter
3088 implementations that are not prepared to received TLS/TCP and DTLS/
3089 SCTP connections in the closed state), the initial TLS/TCP and DTLS/
3090 SCTP connection attempt will fail. The initiator MAY then attempt to
3091 connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP
3092 handshake when both ends are in the open state. If the handshake is
3093 successful, all further messages will be sent via TLS/TCP and DTLS/
3094 SCTP. If the handshake fails, both ends move to the closed state.
3096 The state machine constrains only the behavior of a Diameter
3097 implementation as seen by Diameter peers through events on the wire.
3099 Any implementation that produces equivalent results is considered
3100 compliant.
3102 state event action next state
3103 -----------------------------------------------------------------
3104 Closed Start I-Snd-Conn-Req Wait-Conn-Ack
3105 R-Conn-CER R-Accept, R-Open
3106 Process-CER,
3107 R-Snd-CEA
3109 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA
3110 I-Rcv-Conn-Nack Cleanup Closed
3111 R-Conn-CER R-Accept, Wait-Conn-Ack/
3112 Process-CER Elect
3113 Timeout Error Closed
3115 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
3116 R-Conn-CER R-Accept, Wait-Returns
3117 Process-CER,
3118 Elect
3119 I-Peer-Disc I-Disc Closed
3120 I-Rcv-Non-CEA Error Closed
3121 Timeout Error Closed
3123 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns
3124 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open
3125 R-Peer-Disc R-Disc Wait-Conn-Ack
3126 R-Conn-CER R-Reject Wait-Conn-Ack/
3127 Elect
3128 Timeout Error Closed
3130 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
3131 I-Peer-Disc I-Disc, R-Open
3132 R-Snd-CEA
3133 I-Rcv-CEA R-Disc I-Open
3134 R-Peer-Disc R-Disc Wait-I-CEA
3135 R-Conn-CER R-Reject Wait-Returns
3136 Timeout Error Closed
3138 R-Open Send-Message R-Snd-Message R-Open
3139 R-Rcv-Message Process R-Open
3140 R-Rcv-DWR Process-DWR, R-Open
3141 R-Snd-DWA
3142 R-Rcv-DWA Process-DWA R-Open
3143 R-Conn-CER R-Reject R-Open
3144 Stop R-Snd-DPR Closing
3145 R-Rcv-DPR R-Snd-DPA, Closed
3146 R-Disc
3147 R-Peer-Disc R-Disc Closed
3149 I-Open Send-Message I-Snd-Message I-Open
3150 I-Rcv-Message Process I-Open
3151 I-Rcv-DWR Process-DWR, I-Open
3152 I-Snd-DWA
3153 I-Rcv-DWA Process-DWA I-Open
3154 R-Conn-CER R-Reject I-Open
3155 Stop I-Snd-DPR Closing
3156 I-Rcv-DPR I-Snd-DPA, Closed
3157 I-Disc
3158 I-Peer-Disc I-Disc Closed
3160 Closing I-Rcv-DPA I-Disc Closed
3161 R-Rcv-DPA R-Disc Closed
3162 Timeout Error Closed
3163 I-Peer-Disc I-Disc Closed
3164 R-Peer-Disc R-Disc Closed
3166 5.6.1. Incoming connections
3168 When a connection request is received from a Diameter peer, it is
3169 not, in the general case, possible to know the identity of that peer
3170 until a CER is received from it. This is because host and port
3171 determine the identity of a Diameter peer; and the source port of an
3172 incoming connection is arbitrary. Upon receipt of CER, the identity
3173 of the connecting peer can be uniquely determined from Origin-Host.
3175 For this reason, a Diameter peer must employ logic separate from the
3176 state machine to receive connection requests, accept them, and await
3177 CER. Once CER arrives on a new connection, the Origin-Host that
3178 identifies the peer is used to locate the state machine associated
3179 with that peer, and the new connection and CER are passed to the
3180 state machine as an R-Conn-CER event.
3182 The logic that handles incoming connections SHOULD close and discard
3183 the connection if any message other than CER arrives, or if an
3184 implementation-defined timeout occurs prior to receipt of CER.
3186 Because handling of incoming connections up to and including receipt
3187 of CER requires logic, separate from that of any individual state
3188 machine associated with a particular peer, it is described separately
3189 in this section rather than in the state machine above.
3191 5.6.2. Events
3193 Transitions and actions in the automaton are caused by events. In
3194 this section, we will ignore the -I and -R prefix, since the actual
3195 event would be identical, but would occur on one of two possible
3196 connections.
3198 Start The Diameter application has signaled that a
3199 connection should be initiated with the peer.
3201 R-Conn-CER An acknowledgement is received stating that the
3202 transport connection has been established, and the
3203 associated CER has arrived.
3205 Rcv-Conn-Ack A positive acknowledgement is received confirming that
3206 the transport connection is established.
3208 Rcv-Conn-Nack A negative acknowledgement was received stating that
3209 the transport connection was not established.
3211 Timeout An application-defined timer has expired while waiting
3212 for some event.
3214 Rcv-CER A CER message from the peer was received.
3216 Rcv-CEA A CEA message from the peer was received.
3218 Rcv-Non-CEA A message other than CEA from the peer was received.
3220 Peer-Disc A disconnection indication from the peer was received.
3222 Rcv-DPR A DPR message from the peer was received.
3224 Rcv-DPA A DPA message from the peer was received.
3226 Win-Election An election was held, and the local node was the
3227 winner.
3229 Send-Message A message is to be sent.
3231 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR or DWA
3232 was received.
3234 Stop The Diameter application has signaled that a
3235 connection should be terminated (e.g., on system
3236 shutdown).
3238 5.6.3. Actions
3240 Actions in the automaton are caused by events and typically indicate
3241 the transmission of packets and/or an action to be taken on the
3242 connection. In this section we will ignore the I- and R-prefix,
3243 since the actual action would be identical, but would occur on one of
3244 two possible connections.
3246 Snd-Conn-Req A transport connection is initiated with the peer.
3248 Accept The incoming connection associated with the R-Conn-CER
3249 is accepted as the responder connection.
3251 Reject The incoming connection associated with the R-Conn-CER
3252 is disconnected.
3254 Process-CER The CER associated with the R-Conn-CER is processed.
3255 Snd-CER A CER message is sent to the peer.
3257 Snd-CEA A CEA message is sent to the peer.
3259 Cleanup If necessary, the connection is shutdown, and any
3260 local resources are freed.
3262 Error The transport layer connection is disconnected,
3263 either politely or abortively, in response to
3264 an error condition. Local resources are freed.
3266 Process-CEA A received CEA is processed.
3268 Snd-DPR A DPR message is sent to the peer.
3270 Snd-DPA A DPA message is sent to the peer.
3272 Disc The transport layer connection is disconnected,
3273 and local resources are freed.
3275 Elect An election occurs (see Section 5.6.4 for more
3276 information).
3278 Snd-Message A message is sent.
3280 Snd-DWR A DWR message is sent.
3282 Snd-DWA A DWA message is sent.
3284 Process-DWR The DWR message is serviced.
3286 Process-DWA The DWA message is serviced.
3288 Process A message is serviced.
3290 5.6.4. The Election Process
3292 The election is performed on the responder. The responder compares
3293 the Origin-Host received in the CER with its own Origin-Host as two
3294 streams of octets. If the local Origin-Host lexicographically
3295 succeeds the received Origin-Host a Win-Election event is issued
3296 locally. Diameter identities are in ASCII form therefore the lexical
3297 comparison is consistent with DNS case insensitivity where octets
3298 that fall in the ASCII range 'a' through 'z' MUST compare equally to
3299 their upper-case counterparts between 'A' and 'Z'. See Appendix D
3300 for interactions between the Diameter protocol and Internationalized
3301 Domain Name (IDNs).
3303 The winner of the election MUST close the connection it initiated.
3304 Historically, maintaining the responder side of a connection was more
3305 efficient than maintaining the initiator side. However, current
3306 practices makes this distinction irrelevant.
3308 6. Diameter Message Processing
3310 This section describes how Diameter requests and answers are created
3311 and processed.
3313 6.1. Diameter Request Routing Overview
3315 A request is sent towards its final destination using a combination
3316 of the Destination-Realm and Destination-Host AVPs, in one of these
3317 three combinations:
3319 o a request that is not able to be proxied (such as CER) MUST NOT
3320 contain either Destination-Realm or Destination-Host AVPs.
3322 o a request that needs to be sent to a home server serving a
3323 specific realm, but not to a specific server (such as the first
3324 request of a series of round-trips), MUST contain a Destination-
3325 Realm AVP, but MUST NOT contain a Destination-Host AVP. For
3326 Diameter clients, the value of the Destination-Realm AVP MAY be
3327 extracted from the User-Name AVP, or other methods.
3329 o otherwise, a request that needs to be sent to a specific home
3330 server among those serving a given realm, MUST contain both the
3331 Destination-Realm and Destination-Host AVPs.
3333 The Destination-Host AVP is used as described above when the
3334 destination of the request is fixed, which includes:
3336 o Authentication requests that span multiple round trips
3338 o A Diameter message that uses a security mechanism that makes use
3339 of a pre-established session key shared between the source and the
3340 final destination of the message.
3342 o Server initiated messages that MUST be received by a specific
3343 Diameter client (e.g., access device), such as the Abort-Session-
3344 Request message, which is used to request that a particular user's
3345 session be terminated.
3347 Note that an agent can forward a request to a host described in the
3348 Destination-Host AVP only if the host in question is included in its
3349 peer table (see Section 2.7). Otherwise, the request is routed based
3350 on the Destination-Realm only (see Sections 6.1.6).
3352 When a message is received, the message is processed in the following
3353 order:
3355 o If the message is destined for the local host, the procedures
3356 listed in Section 6.1.4 are followed.
3358 o If the message is intended for a Diameter peer with whom the local
3359 host is able to directly communicate, the procedures listed in
3360 Section 6.1.5 are followed. This is known as Request Forwarding.
3362 o The procedures listed in Section 6.1.6 are followed, which is
3363 known as Request Routing.
3365 o If none of the above is successful, an answer is returned with the
3366 Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.
3368 For routing of Diameter messages to work within an administrative
3369 domain, all Diameter nodes within the realm MUST be peers.
3371 Note the processing rules contained in this section are intended to
3372 be used as general guidelines to Diameter developers. Certain
3373 implementations MAY use different methods than the ones described
3374 here, and still comply with the protocol specification. See Section
3375 7 for more detail on error handling.
3377 6.1.1. Originating a Request
3379 When creating a request, in addition to any other procedures
3380 described in the application definition for that specific request,
3381 the following procedures MUST be followed:
3383 o the Command-Code is set to the appropriate value
3385 o the 'R' bit is set
3387 o the End-to-End Identifier is set to a locally unique value
3389 o the Origin-Host and Origin-Realm AVPs MUST be set to the
3390 appropriate values, used to identify the source of the message
3392 o the Destination-Host and Destination-Realm AVPs MUST be set to the
3393 appropriate values as described in Section 6.1.
3395 6.1.2. Sending a Request
3397 When sending a request, originated either locally, or as the result
3398 of a forwarding or routing operation, the following procedures SHOULD
3399 be followed:
3401 o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
3403 o The message SHOULD be saved in the list of pending requests.
3405 Other actions to perform on the message based on the particular role
3406 the agent is playing are described in the following sections.
3408 6.1.3. Receiving Requests
3410 A relay or proxy agent MUST check for forwarding loops when receiving
3411 requests. A loop is detected if the server finds its own identity in
3412 a Route-Record AVP. When such an event occurs, the agent MUST answer
3413 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
3415 6.1.4. Processing Local Requests
3417 A request is known to be for local consumption when one of the
3418 following conditions occur:
3420 o The Destination-Host AVP contains the local host's identity,
3422 o The Destination-Host AVP is not present, the Destination-Realm AVP
3423 contains a realm the server is configured to process locally, and
3424 the Diameter application is locally supported, or
3426 o Both the Destination-Host and the Destination-Realm are not
3427 present.
3429 When a request is locally processed, the rules in Section 6.2 should
3430 be used to generate the corresponding answer.
3432 6.1.5. Request Forwarding
3434 Request forwarding is done using the Diameter Peer Table. The
3435 Diameter peer table contains all of the peers that the local node is
3436 able to directly communicate with.
3438 When a request is received, and the host encoded in the Destination-
3439 Host AVP is one that is present in the peer table, the message SHOULD
3440 be forwarded to the peer.
3442 6.1.6. Request Routing
3444 Diameter request message routing is done via realms and application
3445 identifiers. A Diameter message that may be forwarded by Diameter
3446 agents (proxies, redirect or relay agents) MUST include the target
3447 realm in the Destination-Realm AVP. Request routing SHOULD rely on
3448 the Destination-Realm AVP and the Application Id present in the
3449 request message header to aid in the routing decision. The realm MAY
3450 be retrieved from the User-Name AVP, which is in the form of a
3451 Network Access Identifier (NAI). The realm portion of the NAI is
3452 inserted in the Destination-Realm AVP.
3454 Diameter agents MAY have a list of locally supported realms and
3455 applications, and MAY have a list of externally supported realms and
3456 applications. When a request is received that includes a realm
3457 and/or application that is not locally supported, the message is
3458 routed to the peer configured in the Routing Table (see Section 2.7).
3460 Realm names and Application Ids are the minimum supported routing
3461 criteria, additional information may be needed to support redirect
3462 semantics.
3464 6.1.7. Predictive Loop Avoidance
3466 Before forwarding or routing a request, Diameter agents, in addition
3467 to processing done in Section 6.1.3, SHOULD check for the presence of
3468 candidate route's peer identity in any of the Route-Record AVPs. In
3469 an event of the agent detecting the presence of a candidate route's
3470 peer identity in a Route-Record AVP, the agent MUST ignore such route
3471 for the Diameter request message and attempt alternate routes if any.
3472 In case all the candidate routes are eliminated by the above
3473 criteria, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message.
3475 6.1.8. Redirecting Requests
3477 When a redirect agent receives a request whose routing entry is set
3478 to REDIRECT, it MUST reply with an answer message with the 'E' bit
3479 set, while maintaining the Hop-by-Hop Identifier in the header, and
3480 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of
3481 the servers associated with the routing entry are added in separate
3482 Redirect-Host AVP.
3484 +------------------+
3485 | Diameter |
3486 | Redirect Agent |
3487 +------------------+
3488 ^ | 2. command + 'E' bit
3489 1. Request | | Result-Code =
3490 joe@example.com | | DIAMETER_REDIRECT_INDICATION +
3491 | | Redirect-Host AVP(s)
3492 | v
3493 +-------------+ 3. Request +-------------+
3494 | example.com |------------->| example.net |
3495 | Relay | | Diameter |
3496 | Agent |<-------------| Server |
3497 +-------------+ 4. Answer +-------------+
3499 Figure 5: Diameter Redirect Agent
3501 The receiver of the answer message with the 'E' bit set, and the
3502 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-
3503 hop field in the Diameter header to identify the request in the
3504 pending message queue (see Section 5.3) that is to be redirected. If
3505 no transport connection exists with the new agent, one is created,
3506 and the request is sent directly to it.
3508 Multiple Redirect-Host AVPs are allowed. The receiver of the answer
3509 message with the 'E' bit set selects exactly one of these hosts as
3510 the destination of the redirected message.
3512 When the Redirect-Host-Usage AVP included in the answer message has a
3513 non-zero value, a route entry for the redirect indications is created
3514 and cached by the receiver. The redirect usage for such route entry
3515 is set by the value of Redirect-Host-Usage AVP and the lifetime of
3516 the cached route entry is set by Redirect-Max-Cache-Time AVP value.
3518 It is possible that multiple redirect indications can create multiple
3519 cached route entries differing only in their redirect usage and the
3520 peer to forward messages to. As an example, two(2) route entries
3521 that are created by two(2) redirect indications results in two(2)
3522 cached routes for the same realm and Application Id. However, one
3523 has a redirect usage of ALL_SESSION where matching request will be
3524 forwarded to one peer and the other has a redirect usage of ALL_REALM
3525 where request are forwarded to another peer. Therefore, an incoming
3526 request that matches the realm and Application Id of both routes will
3527 need additional resolution. In such a case, a routing precedence
3528 rule MUST be used against the redirect usage value to resolve the
3529 contention. The precedence rule can be found in Section 6.13.
3531 6.1.9. Relaying and Proxying Requests
3533 A relay or proxy agent MUST append a Route-Record AVP to all requests
3534 forwarded. The AVP contains the identity of the peer the request was
3535 received from.
3537 The Hop-by-Hop identifier in the request is saved, and replaced with
3538 a locally unique value. The source of the request is also saved,
3539 which includes the IP address, port and protocol.
3541 A relay or proxy agent MAY include the Proxy-Info AVP in requests if
3542 it requires access to any local state information when the
3543 corresponding response is received. The Proxy-Info AVP has security
3544 implications as state information is distributed to other entities.
3545 As such, it is RECOMMENDED that the content of the Proxy-Info AVP be
3546 protected with cryptographic mechanisms, for example by using a keyed
3547 message digest such as HMAC-SHA1 [RFC2104]. Such a mechanism,
3548 however, requires the management of keys, although only locally at
3549 the Diameter server. Still, a full description of the management of
3550 the keys used to protect the Proxy-Info AVP is beyond the scope of
3551 this document. Below is a list of common recommendations:
3553 o The keys should be generated securely following the randomness
3554 recommendations in [RFC4086].
3556 o The keys and cryptographic protection algorithms should be at
3557 least 128 bits in strength.
3559 o The keys should not be used for any other purpose than generating
3560 and verifying tickets.
3562 o The keys should be changed regularly.
3564 o The keys should be changed if the ticket format or cryptographic
3565 protection algorithms change.
3567 The message is then forwarded to the next hop, as identified in the
3568 Routing Table.
3570 Figure 6 provides an example of message routing using the procedures
3571 listed in these sections.
3573 (Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
3574 (Origin-Realm=example.net) (Origin-Realm=example.net)
3575 (Destination-Realm=example.com) (Destination-
3576 Realm=example.com)
3577 (Route-Record=nas.example.net)
3578 +------+ ------> +------+ ------> +------+
3579 | | (Request) | | (Request) | |
3580 | NAS +-------------------+ DRL +-------------------+ HMS |
3581 | | | | | |
3582 +------+ <------ +------+ <------ +------+
3583 example.net (Answer) example.net (Answer) example.com
3584 (Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
3585 (Origin-Realm=example.com) (Origin-Realm=example.com)
3587 Figure 6: Routing of Diameter messages
3589 Relay and proxy agents are not required to perform full inspection of
3590 incoming messages. At a minimum, validation of the message header
3591 and relevant routing AVPs has to be done when relaying messages.
3592 Proxy agents may optionally perform more in-depth message validation
3593 for applications it is interested in.
3595 6.2. Diameter Answer Processing
3597 When a request is locally processed, the following procedures MUST be
3598 applied to create the associated answer, in addition to any
3599 additional procedures that MAY be discussed in the Diameter
3600 application defining the command:
3602 o The same Hop-by-Hop identifier in the request is used in the
3603 answer.
3605 o The local host's identity is encoded in the Origin-Host AVP.
3607 o The Destination-Host and Destination-Realm AVPs MUST NOT be
3608 present in the answer message.
3610 o The Result-Code AVP is added with its value indicating success or
3611 failure.
3613 o If the Session-Id is present in the request, it MUST be included
3614 in the answer.
3616 o Any Proxy-Info AVPs in the request MUST be added to the answer
3617 message, in the same order they were present in the request.
3619 o The 'P' bit is set to the same value as the one in the request.
3621 o The same End-to-End identifier in the request is used in the
3622 answer.
3624 Note that the error messages (see Section 7.3) are also subjected to
3625 the above processing rules.
3627 6.2.1. Processing Received Answers
3629 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
3630 answer received against the list of pending requests. The
3631 corresponding message should be removed from the list of pending
3632 requests. It SHOULD ignore answers received that do not match a
3633 known Hop-by-Hop Identifier.
3635 6.2.2. Relaying and Proxying Answers
3637 If the answer is for a request which was proxied or relayed, the
3638 agent MUST restore the original value of the Diameter header's Hop-
3639 by-Hop Identifier field.
3641 If the last Proxy-Info AVP in the message is targeted to the local
3642 Diameter server, the AVP MUST be removed before the answer is
3643 forwarded.
3645 If a relay or proxy agent receives an answer with a Result-Code AVP
3646 indicating a failure, it MUST NOT modify the contents of the AVP.
3647 Any additional local errors detected SHOULD be logged, but not
3648 reflected in the Result-Code AVP. If the agent receives an answer
3649 message with a Result-Code AVP indicating success, and it wishes to
3650 modify the AVP to indicate an error, it MUST modify the Result-Code
3651 AVP to contain the appropriate error in the message destined towards
3652 the access device as well as include the Error-Reporting-Host AVP and
3653 it MUST issue an STR on behalf of the access device towards the
3654 Diameter server.
3656 The agent MUST then send the answer to the host that it received the
3657 original request from.
3659 6.3. Origin-Host AVP
3661 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
3662 MUST be present in all Diameter messages. This AVP identifies the
3663 endpoint that originated the Diameter message. Relay agents MUST NOT
3664 modify this AVP.
3666 The value of the Origin-Host AVP is guaranteed to be unique within a
3667 single host.
3669 Note that the Origin-Host AVP may resolve to more than one address as
3670 the Diameter peer may support more than one address.
3672 This AVP SHOULD be placed as close to the Diameter header as
3673 possible.
3675 6.4. Origin-Realm AVP
3677 The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.
3678 This AVP contains the Realm of the originator of any Diameter message
3679 and MUST be present in all messages.
3681 This AVP SHOULD be placed as close to the Diameter header as
3682 possible.
3684 6.5. Destination-Host AVP
3686 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
3687 This AVP MUST be present in all unsolicited agent initiated messages,
3688 MAY be present in request messages, and MUST NOT be present in Answer
3689 messages.
3691 The absence of the Destination-Host AVP will cause a message to be
3692 sent to any Diameter server supporting the application within the
3693 realm specified in Destination-Realm AVP.
3695 This AVP SHOULD be placed as close to the Diameter header as
3696 possible.
3698 6.6. Destination-Realm AVP
3700 The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity,
3701 and contains the realm the message is to be routed to. The
3702 Destination-Realm AVP MUST NOT be present in Answer messages.
3703 Diameter Clients insert the realm portion of the User-Name AVP.
3704 Diameter servers initiating a request message use the value of the
3705 Origin-Realm AVP from a previous message received from the intended
3706 target host (unless it is known a priori). When present, the
3707 Destination-Realm AVP is used to perform message routing decisions.
3709 An ABNF for a request message that includes the Destination-Realm AVP
3710 SHOULD list the Destination-Realm AVP as a required AVP (an AVP
3711 indicated as {AVP}) otherwise the message is inherently a non-
3712 routable message.
3714 This AVP SHOULD be placed as close to the Diameter header as
3715 possible.
3717 6.7. Routing AVPs
3719 The AVPs defined in this section are Diameter AVPs used for routing
3720 purposes. These AVPs change as Diameter messages are processed by
3721 agents.
3723 6.7.1. Route-Record AVP
3725 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
3726 identity added in this AVP MUST be the same as the one received in
3727 the Origin-Host of the Capabilities Exchange message.
3729 6.7.2. Proxy-Info AVP
3731 The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
3732 contains the identity and local state information of the Diameter
3733 node that creates and adds it to a message. The Grouped Data field
3734 has the following ABNF grammar:
3736 Proxy-Info ::= < AVP Header: 284 >
3737 { Proxy-Host }
3738 { Proxy-State }
3739 * [ AVP ]
3741 6.7.3. Proxy-Host AVP
3743 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This
3744 AVP contains the identity of the host that added the Proxy-Info AVP.
3746 6.7.4. Proxy-State AVP
3748 The Proxy-State AVP (AVP Code 33) is of type OctetString. It
3749 contains state information that would otherwise be stored at the
3750 Diameter entity that created it. As such, this AVP MUST be treated
3751 as opaque data by other Diameter entities.
3753 6.8. Auth-Application-Id AVP
3755 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
3756 is used in order to advertise support of the Authentication and
3757 Authorization portion of an application (see Section 2.4). If
3758 present in a message other than CER and CEA, the value of the Auth-
3759 Application-Id AVP MUST match the Application Id present in the
3760 Diameter message header.
3762 6.9. Acct-Application-Id AVP
3764 The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
3765 is used in order to advertise support of the Accounting portion of an
3766 application (see Section 2.4). If present in a message other than
3767 CER and CEA, the value of the Acct-Application-Id AVP MUST match the
3768 Application Id present in the Diameter message header.
3770 6.10. Inband-Security-Id AVP
3772 The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
3773 is used in order to advertise support of the security portion of the
3774 application. The use of this AVP in CER and CEA messages is NOT
3775 RECCOMENDED. Instead, discovery of a Diameter entities security
3776 capabilities can be done either through static configuration or via
3777 Diameter Peer Discovery described in Section 5.2.
3779 The following values are supported:
3781 NO_INBAND_SECURITY 0
3783 This peer does not support TLS/TCP and DTLS/SCTP. This is the
3784 default value, if the AVP is omitted.
3786 TLS 1
3788 This node supports TLS/TCP [RFC5246] and DTLS/SCTP [RFC6083]
3789 security.
3791 6.11. Vendor-Specific-Application-Id AVP
3793 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
3794 Grouped and is used to advertise support of a vendor-specific
3795 Diameter Application. Exactly one instance of either Auth-
3796 Application-Id or Acct-Application-Id AVP MUST be present. The
3797 Application Id carried by either Auth-Application-Id or Acct-
3798 Application-Id AVP MUST comply with vendor specific Application Id
3799 assignment described in Sec 11.3. It MUST also match the Application
3800 Id present in the Diameter header except when used in a CER or CEA
3801 message.
3803 The Vendor-Id AVP is an informational AVP pertaining to the vendor
3804 who may have authorship of the vendor-specific Diameter application.
3805 It MUST NOT be used as a means of defining a completely separate
3806 vendor-specific Application Id space.
3808 The Vendor-Specific-Application-Id AVP SHOULD be placed as close to
3809 the Diameter header as possible.
3811 AVP Format
3813 ::= < AVP Header: 260 >
3814 { Vendor-Id }
3815 [ Auth-Application-Id ]
3816 [ Acct-Application-Id ]
3818 A Vendor-Specific-Application-Id AVP MUST contain exactly one of
3819 either Auth-Application-Id or Acct-Application-Id. If a Vendor-
3820 Specific-Application-Id is received without any of these two AVPs,
3821 then the recipient SHOULD issue an answer with a Result-Code set to
3822 DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP
3823 which MUST contain an example of an Auth-Application-Id AVP and an
3824 Acct-Application-Id AVP.
3826 If a Vendor-Specific-Application-Id is received that contains both
3827 Auth-Application-Id and Acct-Application-Id, then the recipient MUST
3828 issue an answer with Result-Code set to
3829 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a
3830 Failed-AVP which MUST contain the received Auth-Application-Id AVP
3831 and Acct-Application-Id AVP.
3833 6.12. Redirect-Host AVP
3835 The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. One or
3836 more of instances of this AVP MUST be present if the answer message's
3837 'E' bit is set and the Result-Code AVP is set to
3838 DIAMETER_REDIRECT_INDICATION.
3840 Upon receiving the above, the receiving Diameter node SHOULD forward
3841 the request directly to one of the hosts identified in these AVPs.
3842 The server contained in the selected Redirect-Host AVP SHOULD be used
3843 for all messages matching the criteria set by the Redirect-Host-Usage
3844 AVP.
3846 6.13. Redirect-Host-Usage AVP
3848 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
3849 This AVP MAY be present in answer messages whose 'E' bit is set and
3850 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
3852 When present, this AVP provides a hints about how the routing entry
3853 resulting from the Redirect-Host is to be used. The following values
3854 are supported:
3856 DONT_CACHE 0
3858 The host specified in the Redirect-Host AVP SHOULD NOT be cached.
3859 This is the default value.
3861 ALL_SESSION 1
3863 All messages within the same session, as defined by the same value
3864 of the Session-ID AVP SHOULD be sent to the host specified in the
3865 Redirect-Host AVP.
3867 ALL_REALM 2
3869 All messages destined for the realm requested SHOULD be sent to
3870 the host specified in the Redirect-Host AVP.
3872 REALM_AND_APPLICATION 3
3874 All messages for the application requested to the realm specified
3875 SHOULD be sent to the host specified in the Redirect-Host AVP.
3877 ALL_APPLICATION 4
3879 All messages for the application requested SHOULD be sent to the
3880 host specified in the Redirect-Host AVP.
3882 ALL_HOST 5
3884 All messages that would be sent to the host that generated the
3885 Redirect-Host SHOULD be sent to the host specified in the
3886 Redirect- Host AVP.
3888 ALL_USER 6
3890 All messages for the user requested SHOULD be sent to the host
3891 specified in the Redirect-Host AVP.
3893 When multiple cached routes are created by redirect indications and
3894 they differ only in redirect usage and peers to forward requests to
3895 (see Section 6.1.8), a precedence rule MUST be applied to the
3896 redirect usage values of the cached routes during normal routing to
3897 resolve contentions that may occur. The precedence rule is the order
3898 that dictate which redirect usage should be considered before any
3899 other as they appear. The order is as follows:
3901 1. ALL_SESSION
3903 2. ALL_USER
3905 3. REALM_AND_APPLICATION
3907 4. ALL_REALM
3909 5. ALL_APPLICATION
3911 6. ALL_HOST
3913 6.14. Redirect-Max-Cache-Time AVP
3915 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
3916 This AVP MUST be present in answer messages whose 'E' bit is set, the
3917 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the
3918 Redirect-Host-Usage AVP set to a non-zero value.
3920 This AVP contains the maximum number of seconds the peer and route
3921 table entries, created as a result of the Redirect-Host, SHOULD be
3922 cached. Note that once a host is no longer reachable, any associated
3923 cache, peer and routing table entries MUST be deleted.
3925 7. Error Handling
3927 There are two different types of errors in Diameter; protocol and
3928 application errors. A protocol error is one that occurs at the base
3929 protocol level, and MAY require per hop attention (e.g., message
3930 routing error). Application errors, on the other hand, generally
3931 occur due to a problem with a function specified in a Diameter
3932 application (e.g., user authentication, missing AVP).
3934 Result-Code AVP values that are used to report protocol errors MUST
3935 only be present in answer messages whose 'E' bit is set. When a
3936 request message is received that causes a protocol error, an answer
3937 message is returned with the 'E' bit set, and the Result-Code AVP is
3938 set to the appropriate protocol error value. As the answer is sent
3939 back towards the originator of the request, each proxy or relay agent
3940 MAY take action on the message.
3942 1. Request +---------+ Link Broken
3943 +-------------------------->|Diameter |----///----+
3944 | +---------------------| | v
3945 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+
3946 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
3947 | | | Home |
3948 | Relay 1 |--+ +---------+ | Server |
3949 +---------+ | 3. Request |Diameter | +--------+
3950 +-------------------->| | ^
3951 | Relay 3 |-----------+
3952 +---------+
3954 Figure 7: Example of Protocol Error causing answer message
3956 Figure 7 provides an example of a message forwarded upstream by a
3957 Diameter relay. When the message is received by Relay 2, and it
3958 detects that it cannot forward the request to the home server, an
3959 answer message is returned with the 'E' bit set and the Result-Code
3960 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls
3961 within the protocol error category, Relay 1 would take special
3962 action, and given the error, attempt to route the message through its
3963 alternate Relay 3.
3965 +---------+ 1. Request +---------+ 2. Request +---------+
3966 | Access |------------>|Diameter |------------>|Diameter |
3967 | | | | | Home |
3968 | Device |<------------| Relay |<------------| Server |
3969 +---------+ 4. Answer +---------+ 3. Answer +---------+
3970 (Missing AVP) (Missing AVP)
3972 Figure 8: Example of Application Error Answer message
3974 Figure 8 provides an example of a Diameter message that caused an
3975 application error. When application errors occur, the Diameter
3976 entity reporting the error clears the 'R' bit in the Command Flags,
3977 and adds the Result-Code AVP with the proper value. Application
3978 errors do not require any proxy or relay agent involvement, and
3979 therefore the message would be forwarded back to the originator of
3980 the request.
3982 In the case where the answer message itself contains errors, any
3983 related session SHOULD be terminated by sending an STR or ASR
3984 message. The Termination-Cause AVP in the STR MAY be filled with the
3985 appropriate value to indicate the cause of the error. An application
3986 MAY also send an application-specific request instead of STR or ASR
3987 to signal the error in the case where no state is maintained or to
3988 allow for some form of error recovery with the corresponding Diameter
3989 entity.
3991 There are certain Result-Code AVP application errors that require
3992 additional AVPs to be present in the answer. In these cases, the
3993 Diameter node that sets the Result-Code AVP to indicate the error
3994 MUST add the AVPs. Examples are:
3996 o A request with an unrecognized AVP is received with the 'M' bit
3997 (Mandatory bit) set, causes an answer to be sent with the Result-
3998 Code AVP set to DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP
3999 containing the offending AVP.
4001 o A request with an AVP that is received with an unrecognized value
4002 causes an answer to be returned with the Result-Code AVP set to
4003 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the
4004 AVP causing the error.
4006 o A received command which is missing AVP(s) that are defined as
4007 required in the commands ABNF; examples are AVPs indicated as
4008 {AVP}. The receiver issues an answer with the Result-Code set to
4009 DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and
4010 other fields set as expected in the missing AVP. The created AVP
4011 is then added to the Failed- AVP AVP.
4013 The Result-Code AVP describes the error that the Diameter node
4014 encountered in its processing. In case there are multiple errors,
4015 the Diameter node MUST report only the first error it encountered
4016 (detected possibly in some implementation dependent order). The
4017 specific errors that can be described by this AVP are described in
4018 the following section.
4020 7.1. Result-Code AVP
4022 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
4023 indicates whether a particular request was completed successfully or
4024 whether an error occurred. All Diameter answer messages in IETF
4025 defined Diameter application specification MUST include one Result-
4026 Code AVP. A non-successful Result-Code AVP (one containing a non
4027 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the
4028 Error-Reporting-Host AVP if the host setting the Result-Code AVP is
4029 different from the identity encoded in the Origin-Host AVP.
4031 The Result-Code data field contains an IANA-managed 32-bit address
4032 space representing errors (see Section 11.4). Diameter provides the
4033 following classes of errors, all identified by the thousands digit in
4034 the decimal notation:
4036 o 1xxx (Informational)
4038 o 2xxx (Success)
4040 o 3xxx (Protocol Errors)
4042 o 4xxx (Transient Failures)
4044 o 5xxx (Permanent Failure)
4046 A non-recognized class (one whose first digit is not defined in this
4047 section) MUST be handled as a permanent failure.
4049 7.1.1. Informational
4051 Errors that fall within this category are used to inform the
4052 requester that a request could not be satisfied, and additional
4053 action is required on its part before access is granted.
4055 DIAMETER_MULTI_ROUND_AUTH 1001
4057 This informational error is returned by a Diameter server to
4058 inform the access device that the authentication mechanism being
4059 used requires multiple round trips, and a subsequent request needs
4060 to be issued in order for access to be granted.
4062 7.1.2. Success
4064 Errors that fall within the Success category are used to inform a
4065 peer that a request has been successfully completed.
4067 DIAMETER_SUCCESS 2001
4069 The request was successfully completed.
4071 DIAMETER_LIMITED_SUCCESS 2002
4073 When returned, the request was successfully completed, but
4074 additional processing is required by the application in order to
4075 provide service to the user.
4077 7.1.3. Protocol Errors
4079 Errors that fall within the Protocol Error category SHOULD be treated
4080 on a per-hop basis, and Diameter proxies MAY attempt to correct the
4081 error, if it is possible. Note that these errors MUST only be used
4082 in answer messages whose 'E' bit is set.
4084 DIAMETER_COMMAND_UNSUPPORTED 3001
4086 This error code is used when a Diameter entity receives a message
4087 with a Command Code that it does not support.
4089 DIAMETER_UNABLE_TO_DELIVER 3002
4091 This error is given when Diameter can not deliver the message to
4092 the destination, either because no host within the realm
4093 supporting the required application was available to process the
4094 request, or because Destination-Host AVP was given without the
4095 associated Destination-Realm AVP.
4097 DIAMETER_REALM_NOT_SERVED 3003
4099 The intended realm of the request is not recognized.
4101 DIAMETER_TOO_BUSY 3004
4103 When returned, a Diameter node SHOULD attempt to send the message
4104 to an alternate peer. This error MUST only be used when a
4105 specific server is requested, and it cannot provide the requested
4106 service.
4108 DIAMETER_LOOP_DETECTED 3005
4110 An agent detected a loop while trying to get the message to the
4111 intended recipient. The message MAY be sent to an alternate peer,
4112 if one is available, but the peer reporting the error has
4113 identified a configuration problem.
4115 DIAMETER_REDIRECT_INDICATION 3006
4117 A redirect agent has determined that the request could not be
4118 satisfied locally and the initiator of the request SHOULD direct
4119 the request directly to the server, whose contact information has
4120 been added to the response. When set, the Redirect-Host AVP MUST
4121 be present.
4123 DIAMETER_APPLICATION_UNSUPPORTED 3007
4125 A request was sent for an application that is not supported.
4127 DIAMETER_INVALID_HDR_BITS 3008
4129 A request was received whose bits in the Diameter header were
4130 either set to an invalid combination, or to a value that is
4131 inconsistent with the command code's definition.
4133 DIAMETER_INVALID_AVP_BITS 3009
4135 A request was received that included an AVP whose flag bits are
4136 set to an unrecognized value, or that is inconsistent with the
4137 AVP's definition.
4139 DIAMETER_UNKNOWN_PEER 3010
4141 A CER was received from an unknown peer.
4143 7.1.4. Transient Failures
4145 Errors that fall within the transient failures category are used to
4146 inform a peer that the request could not be satisfied at the time it
4147 was received, but MAY be able to satisfy the request in the future.
4148 Note that these errors MUST be used in answer messages whose 'E' bit
4149 is not set.
4151 DIAMETER_AUTHENTICATION_REJECTED 4001
4153 The authentication process for the user failed, most likely due to
4154 an invalid password used by the user. Further attempts MUST only
4155 be tried after prompting the user for a new password.
4157 DIAMETER_OUT_OF_SPACE 4002
4159 A Diameter node received the accounting request but was unable to
4160 commit it to stable storage due to a temporary lack of space.
4162 ELECTION_LOST 4003
4164 The peer has determined that it has lost the election process and
4165 has therefore disconnected the transport connection.
4167 7.1.5. Permanent Failures
4169 Errors that fall within the permanent failures category are used to
4170 inform the peer that the request failed, and should not be attempted
4171 again. Note that these errors SHOULD be used in answer messages
4172 whose 'E' bit is not set. In error conditions where it is not
4173 possible or efficient to compose application-specific answer grammar
4174 then answer messages with E-bit set and complying to the grammar
4175 described in 7.2 MAY also be used for permanent errors.
4177 DIAMETER_AVP_UNSUPPORTED 5001
4179 The peer received a message that contained an AVP that is not
4180 recognized or supported and was marked with the Mandatory bit. A
4181 Diameter message with this error MUST contain one or more Failed-
4182 AVP AVP containing the AVPs that caused the failure.
4184 DIAMETER_UNKNOWN_SESSION_ID 5002
4186 The request contained an unknown Session-Id.
4188 DIAMETER_AUTHORIZATION_REJECTED 5003
4190 A request was received for which the user could not be authorized.
4191 This error could occur if the service requested is not permitted
4192 to the user.
4194 DIAMETER_INVALID_AVP_VALUE 5004
4196 The request contained an AVP with an invalid value in its data
4197 portion. A Diameter message indicating this error MUST include
4198 the offending AVPs within a Failed-AVP AVP.
4200 DIAMETER_MISSING_AVP 5005
4202 The request did not contain an AVP that is required by the Command
4203 Code definition. If this value is sent in the Result-Code AVP, a
4204 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP
4205 AVP MUST contain an example of the missing AVP complete with the
4206 Vendor-Id if applicable. The value field of the missing AVP
4207 should be of correct minimum length and contain zeroes.
4209 DIAMETER_RESOURCES_EXCEEDED 5006
4211 A request was received that cannot be authorized because the user
4212 has already expended allowed resources. An example of this error
4213 condition is a user that is restricted to one dial-up PPP port,
4214 attempts to establish a second PPP connection.
4216 DIAMETER_CONTRADICTING_AVPS 5007
4218 The Home Diameter server has detected AVPs in the request that
4219 contradicted each other, and is not willing to provide service to
4220 the user. The Failed-AVP AVPs MUST be present which contains the
4221 AVPs that contradicted each other.
4223 DIAMETER_AVP_NOT_ALLOWED 5008
4225 A message was received with an AVP that MUST NOT be present. The
4226 Failed-AVP AVP MUST be included and contain a copy of the
4227 offending AVP.
4229 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
4231 A message was received that included an AVP that appeared more
4232 often than permitted in the message definition. The Failed-AVP
4233 AVP MUST be included and contain a copy of the first instance of
4234 the offending AVP that exceeded the maximum number of occurrences
4236 DIAMETER_NO_COMMON_APPLICATION 5010
4238 This error is returned by a Diameter node that receives a CER
4239 whereby no applications are common between the CER sending peer
4240 and the CER receiving peer.
4242 DIAMETER_UNSUPPORTED_VERSION 5011
4244 This error is returned when a request was received, whose version
4245 number is unsupported.
4247 DIAMETER_UNABLE_TO_COMPLY 5012
4249 This error is returned when a request is rejected for unspecified
4250 reasons.
4252 DIAMETER_INVALID_BIT_IN_HEADER 5013
4254 This error is returned when a reserved bit in the Diameter header
4255 is set to one (1) or the bits in the Diameter header defined in
4256 Section 3 are set incorrectly.
4258 DIAMETER_INVALID_AVP_LENGTH 5014
4260 The request contained an AVP with an invalid length. A Diameter
4261 message indicating this error MUST include the offending AVPs
4262 within a Failed-AVP AVP. In cases where the erroneous AVP length
4263 value exceeds the message length or is less than the minimum AVP
4264 header length, it is sufficient to include the offending AVP
4265 header and a zero filled payload of the minimum required length
4266 for the payloads data type. If the AVP is a grouped AVP, the
4267 grouped AVP header with an empty payload would be sufficient to
4268 indicate the offending AVP. In the case where the offending AVP
4269 header cannot be fully decoded when the AVP length is less than
4270 the minimum AVP header length, it is sufficient to include an
4271 offending AVP header that is formulated by padding the incomplete
4272 AVP header with zero up to the minimum AVP header length.
4274 DIAMETER_INVALID_MESSAGE_LENGTH 5015
4276 This error is returned when a request is received with an invalid
4277 message length.
4279 DIAMETER_INVALID_AVP_BIT_COMBO 5016
4281 The request contained an AVP with which is not allowed to have the
4282 given value in the AVP Flags field. A Diameter message indicating
4283 this error MUST include the offending AVPs within a Failed-AVP
4284 AVP.
4286 DIAMETER_NO_COMMON_SECURITY 5017
4288 This error is returned when a CER message is received, and there
4289 are no common security mechanisms supported between the peers. A
4290 Capabilities-Exchange-Answer (CEA) MUST be returned with the
4291 Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
4293 7.2. Error Bit
4295 The 'E' (Error Bit) in the Diameter header is set when the request
4296 caused a protocol-related error (see Section 7.1.3). A message with
4297 the 'E' bit MUST NOT be sent as a response to an answer message.
4298 Note that a message with the 'E' bit set is still subjected to the
4299 processing rules defined in Section 6.2. When set, the answer
4300 message will not conform to the ABNF specification for the command,
4301 and will instead conform to the following ABNF:
4303 Message Format
4305 ::= < Diameter Header: code, ERR [, PXY] >
4306 0*1< Session-Id >
4307 { Origin-Host }
4308 { Origin-Realm }
4309 { Result-Code }
4310 [ Origin-State-Id ]
4311 [ Error-Message ]
4312 [ Error-Reporting-Host ]
4313 [ Failed-AVP ]
4314 [ Experimental-Result ]
4315 * [ Proxy-Info ]
4316 * [ AVP ]
4318 Note that the code used in the header is the same than the one found
4319 in the request message, but with the 'R' bit cleared and the 'E' bit
4320 set. The 'P' bit in the header is set to the same value as the one
4321 found in the request message.
4323 7.3. Error-Message AVP
4325 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY
4326 accompany a Result-Code AVP as a human readable error message. The
4327 Error-Message AVP is not intended to be useful in an environment
4328 where error messages are processed automatically. It SHOULD NOT be
4329 expected that the content of this AVP is parsed by network entities.
4331 7.4. Error-Reporting-Host AVP
4333 The Error-Reporting-Host AVP (AVP Code 294) is of type
4334 DiameterIdentity. This AVP contains the identity of the Diameter
4335 host that sent the Result-Code AVP to a value other than 2001
4336 (Success), only if the host setting the Result-Code is different from
4337 the one encoded in the Origin-Host AVP. This AVP is intended to be
4338 used for troubleshooting purposes, and MUST be set when the Result-
4339 Code AVP indicates a failure.
4341 7.5. Failed-AVP AVP
4343 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
4344 debugging information in cases where a request is rejected or not
4345 fully processed due to erroneous information in a specific AVP. The
4346 value of the Result-Code AVP will provide information on the reason
4347 for the Failed-AVP AVP. A Diameter answer message SHOULD contain
4348 only one Failed-AVP that corresponds to the error indicated by the
4349 Result-Code AVP. For practical purposes, this Failed-AVP would
4350 typically refer to the first AVP processing error that a Diameter
4351 node encounters.
4353 The possible reasons for this AVP are the presence of an improperly
4354 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
4355 value, the omission of a required AVP, the presence of an explicitly
4356 excluded AVP (see tables in Section 10), or the presence of two or
4357 more occurrences of an AVP which is restricted to 0, 1, or 0-1
4358 occurrences.
4360 A Diameter message SHOULD contain one Failed-AVP AVP, containing the
4361 entire AVP that could not be processed successfully. If the failure
4362 reason is omission of a required AVP, an AVP with the missing AVP
4363 code, the missing vendor id, and a zero filled payload of the minimum
4364 required length for the omitted AVP will be added. If the failure
4365 reason is an invalid AVP length where the reported length is less
4366 than the minimum AVP header length or greater than the reported
4367 message length, a copy of the offending AVP header and a zero filled
4368 payload of the minimum required length SHOULD be added.
4370 In the case where the offending AVP is embedded within a grouped AVP,
4371 the Failed-AVP MAY contain the grouped AVP which in turn contains the
4372 single offending AVP. The same method MAY be employed if the grouped
4373 AVP itself is embedded in yet another grouped AVP and so on. In this
4374 case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the
4375 single offending AVP. This enables the recipient to detect the
4376 location of the offending AVP when embedded in a group.
4378 AVP Format
4380 ::= < AVP Header: 279 >
4381 1* {AVP}
4383 7.6. Experimental-Result AVP
4385 The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
4386 indicates whether a particular vendor-specific request was completed
4387 successfully or whether an error occurred. This AVP has the
4388 following structure:
4390 AVP Format
4392 Experimental-Result ::= < AVP Header: 297 >
4393 { Vendor-Id }
4394 { Experimental-Result-Code }
4396 The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies
4397 the vendor responsible for the assignment of the result code which
4398 follows. All Diameter answer messages defined in vendor-specific
4399 applications MUST include either one Result-Code AVP or one
4400 Experimental-Result AVP.
4402 7.7. Experimental-Result-Code AVP
4404 The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32
4405 and contains a vendor-assigned value representing the result of
4406 processing the request.
4408 It is recommended that vendor-specific result codes follow the same
4409 conventions given for the Result-Code AVP regarding the different
4410 types of result codes and the handling of errors (for non 2xxx
4411 values).
4413 8. Diameter User Sessions
4415 In general, Diameter can provide two different types of services to
4416 applications. The first involves authentication and authorization,
4417 and can optionally make use of accounting. The second only makes use
4418 of accounting.
4420 When a service makes use of the authentication and/or authorization
4421 portion of an application, and a user requests access to the network,
4422 the Diameter client issues an auth request to its local server. The
4423 auth request is defined in a service-specific Diameter application
4424 (e.g., NASREQ). The request contains a Session-Id AVP, which is used
4425 in subsequent messages (e.g., subsequent authorization, accounting,
4426 etc) relating to the user's session. The Session-Id AVP is a means
4427 for the client and servers to correlate a Diameter message with a
4428 user session.
4430 When a Diameter server authorizes a user to use network resources for
4431 a finite amount of time, and it is willing to extend the
4432 authorization via a future request, it MUST add the Authorization-
4433 Lifetime AVP to the answer message. The Authorization-Lifetime AVP
4434 defines the maximum number of seconds a user MAY make use of the
4435 resources before another authorization request is expected by the
4436 server. The Auth-Grace-Period AVP contains the number of seconds
4437 following the expiration of the Authorization-Lifetime, after which
4438 the server will release all state information related to the user's
4439 session. Note that if payment for services is expected by the
4440 serving realm from the user's home realm, the Authorization-Lifetime
4441 AVP, combined with the Auth-Grace-Period AVP, implies the maximum
4442 length of the session the home realm is willing to be fiscally
4443 responsible for. Services provided past the expiration of the
4444 Authorization-Lifetime and Auth-Grace-Period AVPs are the
4445 responsibility of the access device. Of course, the actual cost of
4446 services rendered is clearly outside the scope of the protocol.
4448 An access device that does not expect to send a re-authorization or a
4449 session termination request to the server MAY include the Auth-
4450 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
4451 to the server. If the server accepts the hint, it agrees that since
4452 no session termination message will be received once service to the
4453 user is terminated, it cannot maintain state for the session. If the
4454 answer message from the server contains a different value in the
4455 Auth-Session-State AVP (or the default value if the AVP is absent),
4456 the access device MUST follow the server's directives. Note that the
4457 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-
4458 authorization requests and answers.
4460 The base protocol does not include any authorization request
4461 messages, since these are largely application-specific and are
4462 defined in a Diameter application document. However, the base
4463 protocol does define a set of messages that are used to terminate
4464 user sessions. These are used to allow servers that maintain state
4465 information to free resources.
4467 When a service only makes use of the Accounting portion of the
4468 Diameter protocol, even in combination with an application, the
4469 Session-Id is still used to identify user sessions. However, the
4470 session termination messages are not used, since a session is
4471 signaled as being terminated by issuing an accounting stop message.
4473 Diameter may also be used for services that cannot be easily
4474 categorized as authentication, authorization or accounting (e.g.,
4475 certain 3GPP IMS interfaces). In such cases, the finite state
4476 machine defined in subsequent sections may not be applicable.
4477 Therefore, the applications itself MAY need to define its own finite
4478 state machine. However, such application-specific state machines
4479 SHOULD follow the general state machine framework outlined in this
4480 document such as the use of Session-Id AVPs and the use of STR/STA,
4481 ASR/ASA messages for stateful sessions.
4483 8.1. Authorization Session State Machine
4485 This section contains a set of finite state machines, representing
4486 the life cycle of Diameter sessions, and which MUST be observed by
4487 all Diameter implementations that make use of the authentication
4488 and/or authorization portion of a Diameter application. The term
4489 Service-Specific below refers to a message defined in a Diameter
4490 application (e.g., Mobile IPv4, NASREQ).
4492 There are four different authorization session state machines
4493 supported in the Diameter base protocol. The first two describe a
4494 session in which the server is maintaining session state, indicated
4495 by the value of the Auth-Session-State AVP (or its absence). One
4496 describes the session from a client perspective, the other from a
4497 server perspective. The second two state machines are used when the
4498 server does not maintain session state. Here again, one describes
4499 the session from a client perspective, the other from a server
4500 perspective.
4502 When a session is moved to the Idle state, any resources that were
4503 allocated for the particular session must be released. Any event not
4504 listed in the state machines MUST be considered as an error
4505 condition, and an answer, if applicable, MUST be returned to the
4506 originator of the message.
4508 In the case that an application does not support re-auth, the state
4509 transitions related to server-initiated re-auth when both client and
4510 server session maintains state (e.g., Send RAR, Pending, Receive RAA)
4511 MAY be ignored.
4513 In the state table, the event 'Failure to send X' means that the
4514 Diameter agent is unable to send command X to the desired
4515 destination. This could be due to the peer being down, or due to the
4516 peer sending back a transient failure or temporary protocol error
4517 notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the
4518 Result-Code AVP of the corresponding Answer command. The event 'X
4519 successfully sent' is the complement of 'Failure to send X'.
4521 The following state machine is observed by a client when state is
4522 maintained on the server:
4524 CLIENT, STATEFUL
4525 State Event Action New State
4526 ---------------------------------------------------------------
4527 Idle Client or Device Requests Send Pending
4528 access service
4529 specific
4530 auth req
4532 Idle ASR Received Send ASA Idle
4533 for unknown session with
4534 Result-Code =
4535 UNKNOWN_
4536 SESSION_ID
4538 Idle RAR Received Send RAA Idle
4539 for unknown session with
4540 Result-Code =
4541 UNKNOWN_
4542 SESSION_ID
4544 Pending Successful Service-specific Grant Open
4545 authorization answer Access
4546 received with default
4547 Auth-Session-State value
4549 Pending Successful Service-specific Sent STR Discon
4550 authorization answer received
4551 but service not provided
4553 Pending Error processing successful Sent STR Discon
4554 Service-specific authorization
4555 answer
4557 Pending Failed Service-specific Cleanup Idle
4558 authorization answer received
4560 Open User or client device Send Open
4561 requests access to service service
4562 specific
4563 auth req
4565 Open Successful Service-specific Provide Open
4566 authorization answer received Service
4568 Open Failed Service-specific Discon. Idle
4569 authorization answer user/device
4570 received.
4572 Open RAR received and client will Send RAA Open
4573 perform subsequent re-auth with
4574 Result-Code =
4575 SUCCESS
4577 Open RAR received and client will Send RAA Idle
4578 not perform subsequent with
4579 re-auth Result-Code !=
4580 SUCCESS,
4581 Discon.
4582 user/device
4584 Open Session-Timeout Expires on Send STR Discon
4585 Access Device
4587 Open ASR Received, Send ASA Discon
4588 client will comply with
4589 with request to end the Result-Code =
4590 session = SUCCESS,
4591 Send STR.
4593 Open ASR Received, Send ASA Open
4594 client will not comply with
4595 with request to end the Result-Code !=
4596 session != SUCCESS
4598 Open Authorization-Lifetime + Send STR Discon
4599 Auth-Grace-Period expires on
4600 access device
4602 Discon ASR Received Send ASA Discon
4604 Discon STA Received Discon. Idle
4605 user/device
4607 The following state machine is observed by a server when it is
4608 maintaining state for the session:
4610 SERVER, STATEFUL
4611 State Event Action New State
4612 ---------------------------------------------------------------
4613 Idle Service-specific authorization Send Open
4614 request received, and successful
4615 user is authorized serv.
4616 specific
4617 answer
4619 Idle Service-specific authorization Send Idle
4620 request received, and failed serv.
4621 user is not authorized specific
4622 answer
4624 Open Service-specific authorization Send Open
4625 request received, and user successful
4626 is authorized serv. specific
4627 answer
4629 Open Service-specific authorization Send Idle
4630 request received, and user failed serv.
4631 is not authorized specific
4632 answer,
4633 Cleanup
4635 Open Home server wants to confirm Send RAR Pending
4636 authentication and/or
4637 authorization of the user
4639 Pending Received RAA with a failed Cleanup Idle
4640 Result-Code
4642 Pending Received RAA with Result-Code Update Open
4643 = SUCCESS session
4645 Open Home server wants to Send ASR Discon
4646 terminate the service
4648 Open Authorization-Lifetime (and Cleanup Idle
4649 Auth-Grace-Period) expires
4650 on home server.
4652 Open Session-Timeout expires on Cleanup Idle
4653 home server
4655 Discon Failure to send ASR Wait, Discon
4656 resend ASR
4658 Discon ASR successfully sent and Cleanup Idle
4659 ASA Received with Result-Code
4661 Not ASA Received None No Change.
4662 Discon
4664 Any STR Received Send STA, Idle
4665 Cleanup.
4667 The following state machine is observed by a client when state is not
4668 maintained on the server:
4670 CLIENT, STATELESS
4671 State Event Action New State
4672 ---------------------------------------------------------------
4673 Idle Client or Device Requests Send Pending
4674 access service
4675 specific
4676 auth req
4678 Pending Successful Service-specific Grant Open
4679 authorization answer Access
4680 received with Auth-Session-
4681 State set to
4682 NO_STATE_MAINTAINED
4684 Pending Failed Service-specific Cleanup Idle
4685 authorization answer
4686 received
4688 Open Session-Timeout Expires on Discon. Idle
4689 Access Device user/device
4691 Open Service to user is terminated Discon. Idle
4692 user/device
4694 The following state machine is observed by a server when it is not
4695 maintaining state for the session:
4697 SERVER, STATELESS
4698 State Event Action New State
4699 ---------------------------------------------------------------
4700 Idle Service-specific authorization Send serv. Idle
4701 request received, and specific
4702 successfully processed answer
4704 8.2. Accounting Session State Machine
4706 The following state machines MUST be supported for applications that
4707 have an accounting portion or that require only accounting services.
4708 The first state machine is to be observed by clients.
4710 See Section 9.7 for Accounting Command Codes and Section 9.8 for
4711 Accounting AVPs.
4713 The server side in the accounting state machine depends in some cases
4714 on the particular application. The Diameter base protocol defines a
4715 default state machine that MUST be followed by all applications that
4716 have not specified other state machines. This is the second state
4717 machine in this section described below.
4719 The default server side state machine requires the reception of
4720 accounting records in any order and at any time, and does not place
4721 any standards requirement on the processing of these records.
4722 Implementations of Diameter may perform checking, ordering,
4723 correlation, fraud detection, and other tasks based on these records.
4724 AVPs may need to be inspected as a part of these tasks. The tasks
4725 can happen either immediately after record reception or in a post-
4726 processing phase. However, as these tasks are typically application
4727 or even policy dependent, they are not standardized by the Diameter
4728 specifications. Applications MAY define requirements on when to
4729 accept accounting records based on the used value of Accounting-
4730 Realtime-Required AVP, credit limits checks, and so on.
4732 However, the Diameter base protocol defines one optional server side
4733 state machine that MAY be followed by applications that require
4734 keeping track of the session state at the accounting server. Note
4735 that such tracking is incompatible with the ability to sustain long
4736 duration connectivity problems. Therefore, the use of this state
4737 machine is recommended only in applications where the value of the
4738 Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence
4739 accounting connectivity problems are required to cause the serviced
4740 user to be disconnected. Otherwise, records produced by the client
4741 may be lost by the server which no longer accepts them after the
4742 connectivity is re-established. This state machine is the third
4743 state machine in this section. The state machine is supervised by a
4744 supervision session timer Ts, which the value should be reasonably
4745 higher than the Acct_Interim_Interval value. Ts MAY be set to two
4746 times the value of the Acct_Interim_Interval so as to avoid the
4747 accounting session in the Diameter server to change to Idle state in
4748 case of short transient network failure.
4750 Any event not listed in the state machines MUST be considered as an
4751 error condition, and a corresponding answer, if applicable, MUST be
4752 returned to the originator of the message.
4754 In the state table, the event 'Failure to send' means that the
4755 Diameter client is unable to communicate with the desired
4756 destination. This could be due to the peer being down, or due to the
4757 peer sending back a transient failure or temporary protocol error
4758 notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
4759 DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
4760 Answer command.
4762 The event 'Failed answer' means that the Diameter client received a
4763 non-transient failure notification in the Accounting Answer command.
4765 Note that the action 'Disconnect user/dev' MUST have an effect also
4766 to the authorization session state table, e.g., cause the STR message
4767 to be sent, if the given application has both authentication/
4768 authorization and accounting portions.
4770 The states PendingS, PendingI, PendingL, PendingE and PendingB stand
4771 for pending states to wait for an answer to an accounting request
4772 related to a Start, Interim, Stop, Event or buffered record,
4773 respectively.
4775 CLIENT, ACCOUNTING
4776 State Event Action New State
4777 ---------------------------------------------------------------
4778 Idle Client or device requests Send PendingS
4779 access accounting
4780 start req.
4782 Idle Client or device requests Send PendingE
4783 a one-time service accounting
4784 event req
4786 Idle Records in storage Send PendingB
4787 record
4789 PendingS Successful accounting Open
4790 start answer received
4792 PendingS Failure to send and buffer Store Open
4793 space available and realtime Start
4794 not equal to DELIVER_AND_GRANT Record
4796 PendingS Failure to send and no buffer Open
4797 space available and realtime
4798 equal to GRANT_AND_LOSE
4800 PendingS Failure to send and no Disconnect Idle
4801 buffer space available and user/dev
4802 realtime not equal to
4803 GRANT_AND_LOSE
4805 PendingS Failed accounting start answer Open
4806 received and realtime equal
4807 to GRANT_AND_LOSE
4809 PendingS Failed accounting start answer Disconnect Idle
4810 received and realtime not user/dev
4811 equal to GRANT_AND_LOSE
4813 PendingS User service terminated Store PendingS
4814 stop
4815 record
4817 Open Interim interval elapses Send PendingI
4818 accounting
4819 interim
4820 record
4821 Open User service terminated Send PendingL
4822 accounting
4823 stop req.
4825 PendingI Successful accounting interim Open
4826 answer received
4828 PendingI Failure to send and (buffer Store Open
4829 space available or old interim
4830 record can be overwritten) record
4831 and realtime not equal to
4832 DELIVER_AND_GRANT
4834 PendingI Failure to send and no buffer Open
4835 space available and realtime
4836 equal to GRANT_AND_LOSE
4838 PendingI Failure to send and no Disconnect Idle
4839 buffer space available and user/dev
4840 realtime not equal to
4841 GRANT_AND_LOSE
4843 PendingI Failed accounting interim Open
4844 answer received and realtime
4845 equal to GRANT_AND_LOSE
4847 PendingI Failed accounting interim Disconnect Idle
4848 answer received and user/dev
4849 realtime not equal to
4850 GRANT_AND_LOSE
4852 PendingI User service terminated Store PendingI
4853 stop
4854 record
4855 PendingE Successful accounting Idle
4856 event answer received
4858 PendingE Failure to send and buffer Store Idle
4859 space available event
4860 record
4862 PendingE Failure to send and no buffer Idle
4863 space available
4865 PendingE Failed accounting event answer Idle
4866 received
4868 PendingB Successful accounting answer Delete Idle
4869 received record
4871 PendingB Failure to send Idle
4873 PendingB Failed accounting answer Delete Idle
4874 received record
4876 PendingL Successful accounting Idle
4877 stop answer received
4879 PendingL Failure to send and buffer Store Idle
4880 space available stop
4881 record
4883 PendingL Failure to send and no buffer Idle
4884 space available
4886 PendingL Failed accounting stop answer Idle
4887 received
4889 SERVER, STATELESS ACCOUNTING
4890 State Event Action New State
4891 ---------------------------------------------------------------
4893 Idle Accounting start request Send Idle
4894 received, and successfully accounting
4895 processed. start
4896 answer
4898 Idle Accounting event request Send Idle
4899 received, and successfully accounting
4900 processed. event
4901 answer
4903 Idle Interim record received, Send Idle
4904 and successfully processed. accounting
4905 interim
4906 answer
4908 Idle Accounting stop request Send Idle
4909 received, and successfully accounting
4910 processed stop answer
4912 Idle Accounting request received, Send Idle
4913 no space left to store accounting
4914 records answer,
4915 Result-Code =
4916 OUT_OF_
4917 SPACE
4919 SERVER, STATEFUL ACCOUNTING
4920 State Event Action New State
4921 ---------------------------------------------------------------
4923 Idle Accounting start request Send Open
4924 received, and successfully accounting
4925 processed. start
4926 answer,
4927 Start Ts
4929 Idle Accounting event request Send Idle
4930 received, and successfully accounting
4931 processed. event
4932 answer
4934 Idle Accounting request received, Send Idle
4935 no space left to store accounting
4936 records answer,
4937 Result-Code =
4938 OUT_OF_
4939 SPACE
4941 Open Interim record received, Send Open
4942 and successfully processed. accounting
4943 interim
4944 answer,
4945 Restart Ts
4947 Open Accounting stop request Send Idle
4948 received, and successfully accounting
4949 processed stop answer,
4950 Stop Ts
4952 Open Accounting request received, Send Idle
4953 no space left to store accounting
4954 records answer,
4955 Result-Code =
4956 OUT_OF_
4957 SPACE,
4958 Stop Ts
4960 Open Session supervision timer Ts Stop Ts Idle
4961 expired
4963 8.3. Server-Initiated Re-Auth
4965 A Diameter server may initiate a re-authentication and/or re-
4966 authorization service for a particular session by issuing a Re-Auth-
4967 Request (RAR).
4969 For example, for pre-paid services, the Diameter server that
4970 originally authorized a session may need some confirmation that the
4971 user is still using the services.
4973 An access device that receives a RAR message with Session-Id equal to
4974 a currently active session MUST initiate a re-auth towards the user,
4975 if the service supports this particular feature. Each Diameter
4976 application MUST state whether server-initiated re-auth is supported,
4977 since some applications do not allow access devices to prompt the
4978 user for re-auth.
4980 8.3.1. Re-Auth-Request
4982 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258
4983 and the message flags' 'R' bit set, may be sent by any server to the
4984 access device that is providing session service, to request that the
4985 user be re-authenticated and/or re-authorized.
4987 Message Format
4989 ::= < Diameter Header: 258, REQ, PXY >
4990 < Session-Id >
4991 { Origin-Host }
4992 { Origin-Realm }
4993 { Destination-Realm }
4994 { Destination-Host }
4995 { Auth-Application-Id }
4996 { Re-Auth-Request-Type }
4997 [ User-Name ]
4998 [ Origin-State-Id ]
4999 * [ Proxy-Info ]
5000 * [ Route-Record ]
5001 * [ AVP ]
5003 8.3.2. Re-Auth-Answer
5005 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258
5006 and the message flags' 'R' bit clear, is sent in response to the RAR.
5007 The Result-Code AVP MUST be present, and indicates the disposition of
5008 the request.
5010 A successful RAA message MUST be followed by an application-specific
5011 authentication and/or authorization message.
5013 Message Format
5015 ::= < Diameter Header: 258, PXY >
5016 < Session-Id >
5017 { Result-Code }
5018 { Origin-Host }
5019 { Origin-Realm }
5020 [ User-Name ]
5021 [ Origin-State-Id ]
5022 [ Error-Message ]
5023 [ Error-Reporting-Host ]
5024 [ Failed-AVP ]
5025 * [ Redirect-Host ]
5026 [ Redirect-Host-Usage ]
5027 [ Redirect-Max-Cache-Time ]
5028 * [ Proxy-Info ]
5029 * [ AVP ]
5031 8.4. Session Termination
5033 It is necessary for a Diameter server that authorized a session, for
5034 which it is maintaining state, to be notified when that session is no
5035 longer active, both for tracking purposes as well as to allow
5036 stateful agents to release any resources that they may have provided
5037 for the user's session. For sessions whose state is not being
5038 maintained, this section is not used.
5040 When a user session that required Diameter authorization terminates,
5041 the access device that provided the service MUST issue a Session-
5042 Termination-Request (STR) message to the Diameter server that
5043 authorized the service, to notify it that the session is no longer
5044 active. An STR MUST be issued when a user session terminates for any
5045 reason, including user logoff, expiration of Session-Timeout,
5046 administrative action, termination upon receipt of an Abort-Session-
5047 Request (see below), orderly shutdown of the access device, etc.
5049 The access device also MUST issue an STR for a session that was
5050 authorized but never actually started. This could occur, for
5051 example, due to a sudden resource shortage in the access device, or
5052 because the access device is unwilling to provide the type of service
5053 requested in the authorization, or because the access device does not
5054 support a mandatory AVP returned in the authorization, etc.
5056 It is also possible that a session that was authorized is never
5057 actually started due to action of a proxy. For example, a proxy may
5058 modify an authorization answer, converting the result from success to
5059 failure, prior to forwarding the message to the access device. If
5060 the answer did not contain an Auth-Session-State AVP with the value
5061 NO_STATE_MAINTAINED, a proxy that causes an authorized session not to
5062 be started MUST issue an STR to the Diameter server that authorized
5063 the session, since the access device has no way of knowing that the
5064 session had been authorized.
5066 A Diameter server that receives an STR message MUST clean up
5067 resources (e.g., session state) associated with the Session-Id
5068 specified in the STR, and return a Session-Termination-Answer.
5070 A Diameter server also MUST clean up resources when the Session-
5071 Timeout expires, or when the Authorization-Lifetime and the Auth-
5072 Grace-Period AVPs expires without receipt of a re-authorization
5073 request, regardless of whether an STR for that session is received.
5074 The access device is not expected to provide service beyond the
5075 expiration of these timers; thus, expiration of either of these
5076 timers implies that the access device may have unexpectedly shut
5077 down.
5079 8.4.1. Session-Termination-Request
5081 The Session-Termination-Request (STR), indicated by the Command-Code
5082 set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter
5083 client or by a Diameter proxy to inform the Diameter Server that an
5084 authenticated and/or authorized session is being terminated.
5086 Message Format
5088 ::= < Diameter Header: 275, REQ, PXY >
5089 < Session-Id >
5090 { Origin-Host }
5091 { Origin-Realm }
5092 { Destination-Realm }
5093 { Auth-Application-Id }
5094 { Termination-Cause }
5095 [ User-Name ]
5096 [ Destination-Host ]
5097 * [ Class ]
5098 [ Origin-State-Id ]
5099 * [ Proxy-Info ]
5100 * [ Route-Record ]
5101 * [ AVP ]
5103 8.4.2. Session-Termination-Answer
5105 The Session-Termination-Answer (STA), indicated by the Command-Code
5106 set to 275 and the message flags' 'R' bit clear, is sent by the
5107 Diameter Server to acknowledge the notification that the session has
5108 been terminated. The Result-Code AVP MUST be present, and MAY
5109 contain an indication that an error occurred while servicing the STR.
5111 Upon sending or receipt of the STA, the Diameter Server MUST release
5112 all resources for the session indicated by the Session-Id AVP. Any
5113 intermediate server in the Proxy-Chain MAY also release any
5114 resources, if necessary.
5116 Message Format
5118 ::= < Diameter Header: 275, PXY >
5119 < Session-Id >
5120 { Result-Code }
5121 { Origin-Host }
5122 { Origin-Realm }
5123 [ User-Name ]
5124 * [ Class ]
5125 [ Error-Message ]
5126 [ Error-Reporting-Host ]
5127 [ Failed-AVP ]
5128 [ Origin-State-Id ]
5129 * [ Redirect-Host ]
5130 [ Redirect-Host-Usage ]
5131 [ Redirect-Max-Cache-Time ]
5132 * [ Proxy-Info ]
5133 * [ AVP ]
5135 8.5. Aborting a Session
5137 A Diameter server may request that the access device stop providing
5138 service for a particular session by issuing an Abort-Session-Request
5139 (ASR).
5141 For example, the Diameter server that originally authorized the
5142 session may be required to cause that session to be stopped for lack
5143 of credit or other reasons that were not anticipated when the session
5144 was first authorized.
5146 An access device that receives an ASR with Session-ID equal to a
5147 currently active session MAY stop the session. Whether the access
5148 device stops the session or not is implementation- and/or
5149 configuration-dependent. For example, an access device may honor
5150 ASRs from certain agents only. In any case, the access device MUST
5151 respond with an Abort-Session-Answer, including a Result-Code AVP to
5152 indicate what action it took.
5154 8.5.1. Abort-Session-Request
5156 The Abort-Session-Request (ASR), indicated by the Command-Code set to
5157 274 and the message flags' 'R' bit set, may be sent by any Diameter
5158 server or any Diameter proxy to the access device that is providing
5159 session service, to request that the session identified by the
5160 Session-Id be stopped.
5162 Message Format
5164 ::= < Diameter Header: 274, REQ, PXY >
5165 < Session-Id >
5166 { Origin-Host }
5167 { Origin-Realm }
5168 { Destination-Realm }
5169 { Destination-Host }
5170 { Auth-Application-Id }
5171 [ User-Name ]
5172 [ Origin-State-Id ]
5173 * [ Proxy-Info ]
5174 * [ Route-Record ]
5175 * [ AVP ]
5177 8.5.2. Abort-Session-Answer
5179 The Abort-Session-Answer (ASA), indicated by the Command-Code set to
5180 274 and the message flags' 'R' bit clear, is sent in response to the
5181 ASR. The Result-Code AVP MUST be present, and indicates the
5182 disposition of the request.
5184 If the session identified by Session-Id in the ASR was successfully
5185 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
5186 is not currently active, Result-Code is set to
5187 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
5188 session for any other reason, Result-Code is set to
5189 DIAMETER_UNABLE_TO_COMPLY.
5191 Message Format
5193 ::= < Diameter Header: 274, PXY >
5194 < Session-Id >
5195 { Result-Code }
5196 { Origin-Host }
5197 { Origin-Realm }
5198 [ User-Name ]
5199 [ Origin-State-Id ]
5200 [ Error-Message ]
5201 [ Error-Reporting-Host ]
5202 [ Failed-AVP ]
5203 * [ Redirect-Host ]
5204 [ Redirect-Host-Usage ]
5205 [ Redirect-Max-Cache-Time ]
5206 * [ Proxy-Info ]
5207 * [ AVP ]
5209 8.6. Inferring Session Termination from Origin-State-Id
5211 The Origin-State-Id is used to allow detection of terminated sessions
5212 for which no STR would have been issued, due to unanticipated
5213 shutdown of an access device.
5215 A Diameter client or access device increments the value of the
5216 Origin-State-Id every time it is started or powered-up. The new
5217 Origin-State-Id is then sent in the CER/CEA message immediately upon
5218 connection to the server. The Diameter server receiving the new
5219 Origin-State-Id can determine whether the sending Diameter client had
5220 abruptly shutdown by comparing the old value of the Origin-State-Id
5221 it has kept for that specific client is less than the new value and
5222 whether it has un-terminated sessions originating from that client.
5224 An access device can also include the Origin-State-Id in request
5225 messages other than CER if there are relays or proxies in between the
5226 access device and the server. In this case, however, the server
5227 cannot discover that the access device has been restarted unless and
5228 until it receives a new request from it. Therefore this mechanism is
5229 more opportunistic across proxies and relays.
5231 The Diameter server may assume that all sessions that were active
5232 prior to detection of a client restart have been terminated. The
5233 Diameter server MAY clean up all session state associated with such
5234 lost sessions, and MAY also issues STRs for all such lost sessions
5235 that were authorized on upstream servers, to allow session state to
5236 be cleaned up globally.
5238 8.7. Auth-Request-Type AVP
5240 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
5241 included in application-specific auth requests to inform the peers
5242 whether a user is to be authenticated only, authorized only or both.
5243 Note any value other than both MAY cause RADIUS interoperability
5244 issues. The following values are defined:
5246 AUTHENTICATE_ONLY 1
5248 The request being sent is for authentication only, and MUST
5249 contain the relevant application specific authentication AVPs that
5250 are needed by the Diameter server to authenticate the user.
5252 AUTHORIZE_ONLY 2
5254 The request being sent is for authorization only, and MUST contain
5255 the application-specific authorization AVPs that are necessary to
5256 identify the service being requested/offered.
5258 AUTHORIZE_AUTHENTICATE 3
5260 The request contains a request for both authentication and
5261 authorization. The request MUST include both the relevant
5262 application-specific authentication information, and authorization
5263 information necessary to identify the service being requested/
5264 offered.
5266 8.8. Session-Id AVP
5268 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
5269 to identify a specific session (see Section 8). All messages
5270 pertaining to a specific session MUST include only one Session-Id AVP
5271 and the same value MUST be used throughout the life of a session.
5272 When present, the Session-Id SHOULD appear immediately following the
5273 Diameter Header (see Section 3).
5275 The Session-Id MUST be globally and eternally unique, as it is meant
5276 to uniquely identify a user session without reference to any other
5277 information, and may be needed to correlate historical authentication
5278 information with accounting information. The Session-Id includes a
5279 mandatory portion and an implementation-defined portion; a
5280 recommended format for the implementation-defined portion is outlined
5281 below.
5283 The Session-Id MUST begin with the sender's identity encoded in the
5284 DiameterIdentity type (see Section 4.4). The remainder of the
5285 Session-Id is delimited by a ";" character, and MAY be any sequence
5286 that the client can guarantee to be eternally unique; however, the
5287 following format is recommended, (square brackets [] indicate an
5288 optional element):
5290 ;;[;]
5292 and are decimal representations of the
5293 high and low 32 bits of a monotonically increasing 64-bit value. The
5294 64-bit value is rendered in two part to simplify formatting by 32-bit
5295 processors. At startup, the high 32 bits of the 64-bit value MAY be
5296 initialized to the time in NTP format [RFC5905], and the low 32 bits
5297 MAY be initialized to zero. This will for practical purposes
5298 eliminate the possibility of overlapping Session-Ids after a reboot,
5299 assuming the reboot process takes longer than a second.
5300 Alternatively, an implementation MAY keep track of the increasing
5301 value in non-volatile memory.
5303 is implementation specific but may include a modem's
5304 device Id, a layer 2 address, timestamp, etc.
5306 Example, in which there is no optional value:
5308 accesspoint7.example.com;1876543210;523
5310 Example, in which there is an optional value:
5312 accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
5314 The Session-Id is created by the Diameter application initiating the
5315 session, which in most cases is done by the client. Note that a
5316 Session-Id MAY be used for both the authentication, authorization and
5317 accounting commands of a given application.
5319 8.9. Authorization-Lifetime AVP
5321 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
5322 and contains the maximum number of seconds of service to be provided
5323 to the user before the user is to be re-authenticated and/or re-
5324 authorized. Care should be taken when the Authorization-Lifetime
5325 value is determined, since a low, non-zero, value could create
5326 significant Diameter traffic, which could congest both the network
5327 and the agents.
5329 A value of zero (0) means that immediate re-auth is necessary by the
5330 access device. The absence of this AVP, or a value of all ones
5331 (meaning all bits in the 32 bit field are set to one) means no re-
5332 auth is expected.
5334 If both this AVP and the Session-Timeout AVP are present in a
5335 message, the value of the latter MUST NOT be smaller than the
5336 Authorization-Lifetime AVP.
5338 An Authorization-Lifetime AVP MAY be present in re-authorization
5339 messages, and contains the number of seconds the user is authorized
5340 to receive service from the time the re-auth answer message is
5341 received by the access device.
5343 This AVP MAY be provided by the client as a hint of the maximum
5344 lifetime that it is willing to accept. The server MUST return a
5345 value that is equal to, or smaller, than the one provided by the
5346 client.
5348 8.10. Auth-Grace-Period AVP
5350 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
5351 contains the number of seconds the Diameter server will wait
5352 following the expiration of the Authorization-Lifetime AVP before
5353 cleaning up resources for the session.
5355 8.11. Auth-Session-State AVP
5357 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
5358 specifies whether state is maintained for a particular session. The
5359 client MAY include this AVP in requests as a hint to the server, but
5360 the value in the server's answer message is binding. The following
5361 values are supported:
5363 STATE_MAINTAINED 0
5365 This value is used to specify that session state is being
5366 maintained, and the access device MUST issue a session termination
5367 message when service to the user is terminated. This is the
5368 default value.
5370 NO_STATE_MAINTAINED 1
5372 This value is used to specify that no session termination messages
5373 will be sent by the access device upon expiration of the
5374 Authorization-Lifetime.
5376 8.12. Re-Auth-Request-Type AVP
5378 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
5379 is included in application-specific auth answers to inform the client
5380 of the action expected upon expiration of the Authorization-Lifetime.
5381 If the answer message contains an Authorization-Lifetime AVP with a
5382 positive value, the Re-Auth-Request-Type AVP MUST be present in an
5383 answer message. The following values are defined:
5385 AUTHORIZE_ONLY 0
5387 An authorization only re-auth is expected upon expiration of the
5388 Authorization-Lifetime. This is the default value if the AVP is
5389 not present in answer messages that include the Authorization-
5390 Lifetime.
5392 AUTHORIZE_AUTHENTICATE 1
5394 An authentication and authorization re-auth is expected upon
5395 expiration of the Authorization-Lifetime.
5397 8.13. Session-Timeout AVP
5399 The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32
5400 and contains the maximum number of seconds of service to be provided
5401 to the user before termination of the session. When both the
5402 Session-Timeout and the Authorization-Lifetime AVPs are present in an
5403 answer message, the former MUST be equal to or greater than the value
5404 of the latter.
5406 A session that terminates on an access device due to the expiration
5407 of the Session-Timeout MUST cause an STR to be issued, unless both
5408 the access device and the home server had previously agreed that no
5409 session termination messages would be sent (see Section 8.11).
5411 A Session-Timeout AVP MAY be present in a re-authorization answer
5412 message, and contains the remaining number of seconds from the
5413 beginning of the re-auth.
5415 A value of zero, or the absence of this AVP, means that this session
5416 has an unlimited number of seconds before termination.
5418 This AVP MAY be provided by the client as a hint of the maximum
5419 timeout that it is willing to accept. However, the server MAY return
5420 a value that is equal to, or smaller, than the one provided by the
5421 client.
5423 8.14. User-Name AVP
5425 The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which
5426 contains the User-Name, in a format consistent with the NAI
5427 specification [RFC4282].
5429 8.15. Termination-Cause AVP
5431 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
5432 is used to indicate the reason why a session was terminated on the
5433 access device. The following values are defined:
5435 DIAMETER_LOGOUT 1
5437 The user initiated a disconnect
5439 DIAMETER_SERVICE_NOT_PROVIDED 2
5441 This value is used when the user disconnected prior to the receipt
5442 of the authorization answer message.
5444 DIAMETER_BAD_ANSWER 3
5446 This value indicates that the authorization answer received by the
5447 access device was not processed successfully.
5449 DIAMETER_ADMINISTRATIVE 4
5451 The user was not granted access, or was disconnected, due to
5452 administrative reasons, such as the receipt of a Abort-Session-
5453 Request message.
5455 DIAMETER_LINK_BROKEN 5
5457 The communication to the user was abruptly disconnected.
5459 DIAMETER_AUTH_EXPIRED 6
5461 The user's access was terminated since its authorized session time
5462 has expired.
5464 DIAMETER_USER_MOVED 7
5466 The user is receiving services from another access device.
5468 DIAMETER_SESSION_TIMEOUT 8
5470 The user's session has timed out, and service has been terminated.
5472 8.16. Origin-State-Id AVP
5474 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a
5475 monotonically increasing value that is advanced whenever a Diameter
5476 entity restarts with loss of previous state, for example upon reboot.
5477 Origin-State-Id MAY be included in any Diameter message, including
5478 CER.
5480 A Diameter entity issuing this AVP MUST create a higher value for
5481 this AVP each time its state is reset. A Diameter entity MAY set
5482 Origin-State-Id to the time of startup, or it MAY use an incrementing
5483 counter retained in non-volatile memory across restarts.
5485 The Origin-State-Id, if present, MUST reflect the state of the entity
5486 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST
5487 either remove Origin-State-Id or modify it appropriately as well.
5488 Typically, Origin-State-Id is used by an access device that always
5489 starts up with no active sessions; that is, any session active prior
5490 to restart will have been lost. By including Origin-State-Id in a
5491 message, it allows other Diameter entities to infer that sessions
5492 associated with a lower Origin-State-Id are no longer active. If an
5493 access device does not intend for such inferences to be made, it MUST
5494 either not include Origin-State-Id in any message, or set its value
5495 to 0.
5497 8.17. Session-Binding AVP
5499 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
5500 be present in application-specific authorization answer messages. If
5501 present, this AVP MAY inform the Diameter client that all future
5502 application-specific re-auth and Session-Termination-Request messages
5503 for this session MUST be sent to the same authorization server.
5505 This field is a bit mask, and the following bits have been defined:
5507 RE_AUTH 1
5509 When set, future re-auth messages for this session MUST NOT
5510 include the Destination-Host AVP. When cleared, the default
5511 value, the Destination-Host AVP MUST be present in all re-auth
5512 messages for this session.
5514 STR 2
5516 When set, the STR message for this session MUST NOT include the
5517 Destination-Host AVP. When cleared, the default value, the
5518 Destination-Host AVP MUST be present in the STR message for this
5519 session.
5521 ACCOUNTING 4
5523 When set, all accounting messages for this session MUST NOT
5524 include the Destination-Host AVP. When cleared, the default
5525 value, the Destination-Host AVP, if known, MUST be present in all
5526 accounting messages for this session.
5528 8.18. Session-Server-Failover AVP
5530 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated,
5531 and MAY be present in application-specific authorization answer
5532 messages that either do not include the Session-Binding AVP or
5533 include the Session-Binding AVP with any of the bits set to a zero
5534 value. If present, this AVP MAY inform the Diameter client that if a
5535 re-auth or STR message fails due to a delivery problem, the Diameter
5536 client SHOULD issue a subsequent message without the Destination-Host
5537 AVP. When absent, the default value is REFUSE_SERVICE.
5539 The following values are supported:
5541 REFUSE_SERVICE 0
5543 If either the re-auth or the STR message delivery fails, terminate
5544 service with the user, and do not attempt any subsequent attempts.
5546 TRY_AGAIN 1
5548 If either the re-auth or the STR message delivery fails, resend
5549 the failed message without the Destination-Host AVP present.
5551 ALLOW_SERVICE 2
5553 If re-auth message delivery fails, assume that re-authorization
5554 succeeded. If STR message delivery fails, terminate the session.
5556 TRY_AGAIN_ALLOW_SERVICE 3
5558 If either the re-auth or the STR message delivery fails, resend
5559 the failed message without the Destination-Host AVP present. If
5560 the second delivery fails for re-auth, assume re-authorization
5561 succeeded. If the second delivery fails for STR, terminate the
5562 session.
5564 8.19. Multi-Round-Time-Out AVP
5566 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32,
5567 and SHOULD be present in application-specific authorization answer
5568 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
5569 This AVP contains the maximum number of seconds that the access
5570 device MUST provide the user in responding to an authentication
5571 request.
5573 8.20. Class AVP
5575 The Class AVP (AVP Code 25) is of type OctetString and is used by
5576 Diameter servers to return state information to the access device.
5577 When one or more Class AVPs are present in application-specific
5578 authorization answer messages, they MUST be present in subsequent re-
5579 authorization, session termination and accounting messages. Class
5580 AVPs found in a re-authorization answer message override the ones
5581 found in any previous authorization answer message. Diameter server
5582 implementations SHOULD NOT return Class AVPs that require more than
5583 4096 bytes of storage on the Diameter client. A Diameter client that
5584 receives Class AVPs whose size exceeds local available storage MUST
5585 terminate the session.
5587 8.21. Event-Timestamp AVP
5589 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be
5590 included in an Accounting-Request and Accounting-Answer messages to
5591 record the time that the reported event occurred, in seconds since
5592 January 1, 1900 00:00 UTC.
5594 9. Accounting
5596 This accounting protocol is based on a server directed model with
5597 capabilities for real-time delivery of accounting information.
5598 Several fault resilience methods [RFC2975] have been built in to the
5599 protocol in order minimize loss of accounting data in various fault
5600 situations and under different assumptions about the capabilities of
5601 the used devices.
5603 9.1. Server Directed Model
5605 The server directed model means that the device generating the
5606 accounting data gets information from either the authorization server
5607 (if contacted) or the accounting server regarding the way accounting
5608 data shall be forwarded. This information includes accounting record
5609 timeliness requirements.
5611 As discussed in [RFC2975], real-time transfer of accounting records
5612 is a requirement, such as the need to perform credit limit checks and
5613 fraud detection. Note that batch accounting is not a requirement,
5614 and is therefore not supported by Diameter. Should batched
5615 accounting be required in the future, a new Diameter application will
5616 need to be created, or it could be handled using another protocol.
5617 Note, however, that even if at the Diameter layer accounting requests
5618 are processed one by one, transport protocols used under Diameter
5619 typically batch several requests in the same packet under heavy
5620 traffic conditions. This may be sufficient for many applications.
5622 The authorization server (chain) directs the selection of proper
5623 transfer strategy, based on its knowledge of the user and
5624 relationships of roaming partnerships. The server (or agents) uses
5625 the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
5626 control the operation of the Diameter peer operating as a client.
5627 The Acct-Interim-Interval AVP, when present, instructs the Diameter
5628 node acting as a client to produce accounting records continuously
5629 even during a session. Accounting-Realtime-Required AVP is used to
5630 control the behavior of the client when the transfer of accounting
5631 records from the Diameter client is delayed or unsuccessful.
5633 The Diameter accounting server MAY override the interim interval or
5634 the realtime requirements by including the Acct-Interim-Interval or
5635 Accounting-Realtime-Required AVP in the Accounting-Answer message.
5636 When one of these AVPs is present, the latest value received SHOULD
5637 be used in further accounting activities for the same session.
5639 9.2. Protocol Messages
5641 A Diameter node that receives a successful authentication and/or
5642 authorization messages from the Diameter server SHOULD collect
5643 accounting information for the session. The Accounting-Request
5644 message is used to transmit the accounting information to the
5645 Diameter server, which MUST reply with the Accounting-Answer message
5646 to confirm reception. The Accounting-Answer message includes the
5647 Result-Code AVP, which MAY indicate that an error was present in the
5648 accounting message. The value of the Accounting-Realtime-Required
5649 AVP received earlier for the session in question may indicate that
5650 the user's session has to be terminated when a rejected Accounting-
5651 Request message was received.
5653 9.3. Accounting Application Extension and Requirements
5655 Each Diameter application (e.g., NASREQ, MobileIP), SHOULD define
5656 their Service-Specific AVPs that MUST be present in the Accounting-
5657 Request message in a section entitled "Accounting AVPs". The
5658 application MUST assume that the AVPs described in this document will
5659 be present in all Accounting messages, so only their respective
5660 service-specific AVPs need to be defined in that section.
5662 Applications have the option of using one or both of the following
5663 accounting application extension models:
5665 Split Accounting Service
5667 The accounting message will carry the Application Id of the
5668 Diameter base accounting application (see Section 2.4).
5669 Accounting messages may be routed to Diameter nodes other than the
5670 corresponding Diameter application. These nodes might be
5671 centralized accounting servers that provide accounting service for
5672 multiple different Diameter applications. These nodes MUST
5673 advertise the Diameter base accounting Application Id during
5674 capabilities exchange.
5676 Coupled Accounting Service
5678 The accounting messages will carry the Application Id of the
5679 application that is using it. The application itself will process
5680 the received accounting records or forward them to an accounting
5681 server. There is no accounting application advertisement required
5682 during capabilities exchange and the accounting messages will be
5683 routed the same as any of the other application messages.
5685 In cases where an application does not define its own accounting
5686 service, it is preferred that the split accounting model be used.
5688 9.4. Fault Resilience
5690 Diameter Base protocol mechanisms are used to overcome small message
5691 loss and network faults of temporary nature.
5693 Diameter peers acting as clients MUST implement the use of failover
5694 to guard against server failures and certain network failures.
5695 Diameter peers acting as agents or related off-line processing
5696 systems MUST detect duplicate accounting records caused by the
5697 sending of same record to several servers and duplication of messages
5698 in transit. This detection MUST be based on the inspection of the
5699 Session-Id and Accounting-Record-Number AVP pairs. Appendix C
5700 discusses duplicate detection needs and implementation issues.
5702 Diameter clients MAY have non-volatile memory for the safe storage of
5703 accounting records over reboots or extended network failures, network
5704 partitions, and server failures. If such memory is available, the
5705 client SHOULD store new accounting records there as soon as the
5706 records are created and until a positive acknowledgement of their
5707 reception from the Diameter Server has been received. Upon a reboot,
5708 the client MUST starting sending the records in the non-volatile
5709 memory to the accounting server with appropriate modifications in
5710 termination cause, session length, and other relevant information in
5711 the records.
5713 A further application of this protocol may include AVPs to control
5714 how many accounting records may at most be stored in the Diameter
5715 client without committing them to the non-volatile memory or
5716 transferring them to the Diameter server.
5718 The client SHOULD NOT remove the accounting data from any of its
5719 memory areas before the correct Accounting-Answer has been received.
5720 The client MAY remove oldest, undelivered or yet unacknowledged
5721 accounting data if it runs out of resources such as memory. It is an
5722 implementation dependent matter for the client to accept new sessions
5723 under this condition.
5725 9.5. Accounting Records
5727 In all accounting records, the Session-Id AVP MUST be present; the
5728 User-Name AVP MUST be present if it is available to the Diameter
5729 client.
5731 Different types of accounting records are sent depending on the
5732 actual type of accounted service and the authorization server's
5733 directions for interim accounting. If the accounted service is a
5734 one-time event, meaning that the start and stop of the event are
5735 simultaneous, then the Accounting-Record-Type AVP MUST be present and
5736 set to the value EVENT_RECORD.
5738 If the accounted service is of a measurable length, then the AVP MUST
5739 use the values START_RECORD, STOP_RECORD, and possibly,
5740 INTERIM_RECORD. If the authorization server has not directed interim
5741 accounting to be enabled for the session, two accounting records MUST
5742 be generated for each service of type session. When the initial
5743 Accounting-Request for a given session is sent, the Accounting-
5744 Record-Type AVP MUST be set to the value START_RECORD. When the last
5745 Accounting-Request is sent, the value MUST be STOP_RECORD.
5747 If the authorization server has directed interim accounting to be
5748 enabled, the Diameter client MUST produce additional records between
5749 the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
5750 production of these records is directed by Acct-Interim-Interval as
5751 well as any re-authentication or re-authorization of the session.
5752 The Diameter client MUST overwrite any previous interim accounting
5753 records that are locally stored for delivery, if a new record is
5754 being generated for the same session. This ensures that only one
5755 pending interim record can exist on an access device for any given
5756 session.
5758 A particular value of Accounting-Sub-Session-Id MUST appear only in
5759 one sequence of accounting records from a Diameter client, except for
5760 the purposes of retransmission. The one sequence that is sent MUST
5761 be either one record with Accounting-Record-Type AVP set to the value
5762 EVENT_RECORD, or several records starting with one having the value
5763 START_RECORD, followed by zero or more INTERIM_RECORD and a single
5764 STOP_RECORD. A particular Diameter application specification MUST
5765 define the type of sequences that MUST be used.
5767 9.6. Correlation of Accounting Records
5769 If an application uses accounting messages, it can correlate
5770 accounting records with a specific application session by using the
5771 Session-Id of the particular application session in the accounting
5772 messages. Accounting messages MAY also use a different Session-Id
5773 from that of the application sessions in which case other session
5774 related information is needed to perform correlation.
5776 In cases where an application requires multiple accounting sub-
5777 session, an Accounting-Sub-Session-Id AVP is used to differentiate
5778 each sub-session. The Session-Id would remain constant for all sub-
5779 sessions and is be used to correlate all the sub-sessions to a
5780 particular application session. Note that receiving a STOP_RECORD
5781 with no Accounting-Sub-Session-Id AVP when sub-sessions were
5782 originally used in the START_RECORD messages implies that all sub-
5783 sessions are terminated.
5785 There are also cases where an application needs to correlate multiple
5786 application sessions into a single accounting record; the accounting
5787 record may span multiple different Diameter applications and sessions
5788 used by the same user at a given time. In such cases, the Acct-
5789 Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD
5790 be signaled by the server to the access device (typically during
5791 authorization) when it determines that a request belongs to an
5792 existing session. The access device MUST then include the Acct-
5793 Multi-Session-Id AVP in all subsequent accounting messages.
5795 The Acct-Multi-Session-Id AVP MAY include the value of the original
5796 Session-Id. It's contents are implementation specific, but MUST be
5797 globally unique across other Acct-Multi-Session-Id, and MUST NOT
5798 change during the life of a session.
5800 A Diameter application document MUST define the exact concept of a
5801 session that is being accounted, and MAY define the concept of a
5802 multi-session. For instance, the NASREQ DIAMETER application treats
5803 a single PPP connection to a Network Access Server as one session,
5804 and a set of Multilink PPP sessions as one multi-session.
5806 9.7. Accounting Command-Codes
5808 This section defines Command-Code values that MUST be supported by
5809 all Diameter implementations that provide Accounting services.
5811 9.7.1. Accounting-Request
5813 The Accounting-Request (ACR) command, indicated by the Command-Code
5814 field set to 271 and the Command Flags' 'R' bit set, is sent by a
5815 Diameter node, acting as a client, in order to exchange accounting
5816 information with a peer.
5818 The AVP listed below SHOULD include service-specific accounting AVPs,
5819 as described in Section 9.3.
5821 Message Format
5823 ::= < Diameter Header: 271, REQ, PXY >
5824 < Session-Id >
5825 { Origin-Host }
5826 { Origin-Realm }
5827 { Destination-Realm }
5828 { Accounting-Record-Type }
5829 { Accounting-Record-Number }
5830 [ Acct-Application-Id ]
5831 [ Vendor-Specific-Application-Id ]
5832 [ User-Name ]
5833 [ Destination-Host ]
5834 [ Accounting-Sub-Session-Id ]
5835 [ Acct-Session-Id ]
5836 [ Acct-Multi-Session-Id ]
5837 [ Acct-Interim-Interval ]
5838 [ Accounting-Realtime-Required ]
5839 [ Origin-State-Id ]
5840 [ Event-Timestamp ]
5841 * [ Proxy-Info ]
5842 * [ Route-Record ]
5843 * [ AVP ]
5845 9.7.2. Accounting-Answer
5847 The Accounting-Answer (ACA) command, indicated by the Command-Code
5848 field set to 271 and the Command Flags' 'R' bit cleared, is used to
5849 acknowledge an Accounting-Request command. The Accounting-Answer
5850 command contains the same Session-Id as the corresponding request.
5852 Only the target Diameter Server, known as the home Diameter Server,
5853 SHOULD respond with the Accounting-Answer command.
5855 The AVP listed below SHOULD include service-specific accounting AVPs,
5856 as described in Section 9.3.
5858 Message Format
5860 ::= < Diameter Header: 271, PXY >
5861 < Session-Id >
5862 { Result-Code }
5863 { Origin-Host }
5864 { Origin-Realm }
5865 { Accounting-Record-Type }
5866 { Accounting-Record-Number }
5867 [ Acct-Application-Id ]
5868 [ Vendor-Specific-Application-Id ]
5869 [ User-Name ]
5870 [ Accounting-Sub-Session-Id ]
5871 [ Acct-Session-Id ]
5872 [ Acct-Multi-Session-Id ]
5873 [ Error-Message ]
5874 [ Error-Reporting-Host ]
5875 [ Failed-AVP ]
5876 [ Acct-Interim-Interval ]
5877 [ Accounting-Realtime-Required ]
5878 [ Origin-State-Id ]
5879 [ Event-Timestamp ]
5880 * [ Proxy-Info ]
5881 * [ AVP ]
5883 9.8. Accounting AVPs
5885 This section contains AVPs that describe accounting usage information
5886 related to a specific session.
5888 9.8.1. Accounting-Record-Type AVP
5890 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
5891 and contains the type of accounting record being sent. The following
5892 values are currently defined for the Accounting-Record-Type AVP:
5894 EVENT_RECORD 1
5896 An Accounting Event Record is used to indicate that a one-time
5897 event has occurred (meaning that the start and end of the event
5898 are simultaneous). This record contains all information relevant
5899 to the service, and is the only record of the service.
5901 START_RECORD 2
5903 An Accounting Start, Interim, and Stop Records are used to
5904 indicate that a service of a measurable length has been given. An
5905 Accounting Start Record is used to initiate an accounting session,
5906 and contains accounting information that is relevant to the
5907 initiation of the session.
5909 INTERIM_RECORD 3
5911 An Interim Accounting Record contains cumulative accounting
5912 information for an existing accounting session. Interim
5913 Accounting Records SHOULD be sent every time a re-authentication
5914 or re-authorization occurs. Further, additional interim record
5915 triggers MAY be defined by application-specific Diameter
5916 applications. The selection of whether to use INTERIM_RECORD
5917 records is done by the Acct-Interim-Interval AVP.
5919 STOP_RECORD 4
5921 An Accounting Stop Record is sent to terminate an accounting
5922 session and contains cumulative accounting information relevant to
5923 the existing session.
5925 9.8.2. Acct-Interim-Interval AVP
5927 The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
5928 is sent from the Diameter home authorization server to the Diameter
5929 client. The client uses information in this AVP to decide how and
5930 when to produce accounting records. With different values in this
5931 AVP, service sessions can result in one, two, or two+N accounting
5932 records, based on the needs of the home-organization. The following
5933 accounting record production behavior is directed by the inclusion of
5934 this AVP:
5936 1. The omission of the Acct-Interim-Interval AVP or its inclusion
5937 with Value field set to 0 means that EVENT_RECORD, START_RECORD,
5938 and STOP_RECORD are produced, as appropriate for the service.
5940 2. The inclusion of the AVP with Value field set to a non-zero value
5941 means that INTERIM_RECORD records MUST be produced between the
5942 START_RECORD and STOP_RECORD records. The Value field of this
5943 AVP is the nominal interval between these records in seconds.
5945 The Diameter node that originates the accounting information,
5946 known as the client, MUST produce the first INTERIM_RECORD record
5947 roughly at the time when this nominal interval has elapsed from
5948 the START_RECORD, the next one again as the interval has elapsed
5949 once more, and so on until the session ends and a STOP_RECORD
5950 record is produced.
5952 The client MUST ensure that the interim record production times
5953 are randomized so that large accounting message storms are not
5954 created either among records or around a common service start
5955 time.
5957 9.8.3. Accounting-Record-Number AVP
5959 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
5960 and identifies this record within one session. As Session-Id AVPs
5961 are globally unique, the combination of Session-Id and Accounting-
5962 Record-Number AVPs is also globally unique, and can be used in
5963 matching accounting records with confirmations. An easy way to
5964 produce unique numbers is to set the value to 0 for records of type
5965 EVENT_RECORD and START_RECORD, and set the value to 1 for the first
5966 INTERIM_RECORD, 2 for the second, and so on until the value for
5967 STOP_RECORD is one more than for the last INTERIM_RECORD.
5969 9.8.4. Acct-Session-Id AVP
5971 The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only
5972 used when RADIUS/Diameter translation occurs. This AVP contains the
5973 contents of the RADIUS Acct-Session-Id attribute.
5975 9.8.5. Acct-Multi-Session-Id AVP
5977 The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
5978 following the format specified in Section 8.8. The Acct-Multi-
5979 Session-Id AVP is used to link together multiple related accounting
5980 sessions, where each session would have a unique Session-Id, but the
5981 same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the
5982 Diameter server in an authorization answer, and MUST be used in all
5983 accounting messages for the given session.
5985 9.8.6. Accounting-Sub-Session-Id AVP
5987 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
5988 Unsigned64 and contains the accounting sub-session identifier. The
5989 combination of the Session-Id and this AVP MUST be unique per sub-
5990 session, and the value of this AVP MUST be monotonically increased by
5991 one for all new sub-sessions. The absence of this AVP implies no
5992 sub-sessions are in use, with the exception of an Accounting-Request
5993 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
5994 message with no Accounting-Sub-Session-Id AVP present will signal the
5995 termination of all sub-sessions for a given Session-Id.
5997 9.8.7. Accounting-Realtime-Required AVP
5999 The Accounting-Realtime-Required AVP (AVP Code 483) is of type
6000 Enumerated and is sent from the Diameter home authorization server to
6001 the Diameter client or in the Accounting-Answer from the accounting
6002 server. The client uses information in this AVP to decide what to do
6003 if the sending of accounting records to the accounting server has
6004 been temporarily prevented due to, for instance, a network problem.
6006 DELIVER_AND_GRANT 1
6008 The AVP with Value field set to DELIVER_AND_GRANT means that the
6009 service MUST only be granted as long as there is a connection to
6010 an accounting server. Note that the set of alternative accounting
6011 servers are treated as one server in this sense. Having to move
6012 the accounting record stream to a backup server is not a reason to
6013 discontinue the service to the user.
6015 GRANT_AND_STORE 2
6017 The AVP with Value field set to GRANT_AND_STORE means that service
6018 SHOULD be granted if there is a connection, or as long as records
6019 can still be stored as described in Section 9.4.
6021 This is the default behavior if the AVP isn't included in the
6022 reply from the authorization server.
6024 GRANT_AND_LOSE 3
6026 The AVP with Value field set to GRANT_AND_LOSE means that service
6027 SHOULD be granted even if the records cannot be delivered or
6028 stored.
6030 10. AVP Occurrence Table
6032 The following tables presents the AVPs defined in this document, and
6033 specifies in which Diameter messages they MAY be present or not.
6034 AVPs that occur only inside a Grouped AVP are not shown in this
6035 table.
6037 The table uses the following symbols:
6039 0 The AVP MUST NOT be present in the message.
6041 0+ Zero or more instances of the AVP MAY be present in the
6042 message.
6044 0-1 Zero or one instance of the AVP MAY be present in the message.
6045 It is considered an error if there are more than one instance of
6046 the AVP.
6048 1 One instance of the AVP MUST be present in the message.
6050 1+ At least one instance of the AVP MUST be present in the
6051 message.
6053 10.1. Base Protocol Command AVP Table
6055 The table in this section is limited to the non-accounting Command
6056 Codes defined in this specification.
6058 +-----------------------------------------------+
6059 | Command-Code |
6060 +---+---+---+---+---+---+---+---+---+---+---+---+
6061 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
6062 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
6063 Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
6064 Interval | | | | | | | | | | | | |
6065 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
6066 Required | | | | | | | | | | | | |
6067 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6068 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
6069 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6070 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6071 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6072 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6073 Lifetime | | | | | | | | | | | | |
6074 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
6075 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
6076 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
6077 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6078 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
6079 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6080 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |
6081 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6082 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6083 Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6084 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6085 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
6086 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
6087 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|
6088 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6089 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
6090 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
6091 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6092 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
6093 Time | | | | | | | | | | | | |
6094 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
6095 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
6096 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
6097 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6098 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
6099 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6100 Failover | | | | | | | | | | | | |
6101 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6102 Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6103 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
6104 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
6105 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6106 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6107 Application-Id | | | | | | | | | | | | |
6108 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
6110 10.2. Accounting AVP Table
6112 The table in this section is used to represent which AVPs defined in
6113 this document are to be present in the Accounting messages. These
6114 AVP occurrence requirements are guidelines, which may be expanded,
6115 and/or overridden by application-specific requirements in the
6116 Diameter applications documents.
6118 +-----------+
6119 | Command |
6120 | Code |
6121 +-----+-----+
6122 Attribute Name | ACR | ACA |
6123 ------------------------------+-----+-----+
6124 Acct-Interim-Interval | 0-1 | 0-1 |
6125 Acct-Multi-Session-Id | 0-1 | 0-1 |
6126 Accounting-Record-Number | 1 | 1 |
6127 Accounting-Record-Type | 1 | 1 |
6128 Acct-Session-Id | 0-1 | 0-1 |
6129 Accounting-Sub-Session-Id | 0-1 | 0-1 |
6130 Accounting-Realtime-Required | 0-1 | 0-1 |
6131 Acct-Application-Id | 0-1 | 0-1 |
6132 Auth-Application-Id | 0 | 0 |
6133 Class | 0+ | 0+ |
6134 Destination-Host | 0-1 | 0 |
6135 Destination-Realm | 1 | 0 |
6136 Error-Reporting-Host | 0 | 0+ |
6137 Event-Timestamp | 0-1 | 0-1 |
6138 Origin-Host | 1 | 1 |
6139 Origin-Realm | 1 | 1 |
6140 Proxy-Info | 0+ | 0+ |
6141 Route-Record | 0+ | 0 |
6142 Result-Code | 0 | 1 |
6143 Session-Id | 1 | 1 |
6144 Termination-Cause | 0 | 0 |
6145 User-Name | 0-1 | 0-1 |
6146 Vendor-Specific-Application-Id| 0-1 | 0-1 |
6147 ------------------------------+-----+-----+
6149 11. IANA Considerations
6151 This section provides guidance to the Internet Assigned Numbers
6152 Authority (IANA) regarding registration of values related to the
6153 Diameter protocol, in accordance with [RFC5226]. Existing IANA
6154 registries and assignments put in place by [RFC3588] remain the same
6155 unless explicitly updated or deprecated in this section.
6157 11.1. AVP Header
6159 As defined in Section 4, the AVP header contains three fields that
6160 requires IANA namespace management; the AVP Code, Vendor-ID and Flags
6161 field.
6163 11.1.1. AVP Codes
6165 There are multiple namespaces. Vendors can have their own AVP Codes
6166 namespace which will be identified by their Vendor-ID (also known as
6167 Enterprise-Number) and they control the assignments of their vendor-
6168 specific AVP codes within their own namespace. The absence of a
6169 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
6170 controlled AVP Codes namespace. The AVP Codes and sometimes also
6171 possible values in an AVP are controlled and maintained by IANA. AVP
6172 Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS
6173 Attribute Types. Where a Vendor-Specific AVP is implemented by more
6174 than one vendor, allocation of global AVPs should be encouraged
6175 instead.
6177 AVPs may be allocated following Expert Review (or Designated Expert)
6178 with Specification Required [RFC5226]. A block allocation (release
6179 of more than 3 AVPs at a time for a given purpose) requires IETF
6180 Review.
6182 11.1.2. AVP Flags
6184 Section 4.1 describes the existing AVP Flags. The remaining bits can
6185 only be assigned via a Standards Action [RFC5226].
6187 11.2. Diameter Header
6189 11.2.1. Command Codes
6191 For the Diameter Header, the command code namespace allocation has
6192 changed. The new allocation rules are as follows:
6194 The command code values 256 - 8,388,607 (0x100 to 0x7fffff) are
6195 for permanent, standard commands, allocated by IETF Review
6196 [RFC5226].
6198 The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are
6199 reserved for vendor-specific command codes, to be allocated on a
6200 First Come, First Served basis by IANA [RFC5226]. The request to
6201 IANA for a Vendor-Specific Command Code SHOULD include a reference
6202 to a publicly available specification which documents the command
6203 in sufficient detail to aid in interoperability between
6204 independent implementations. If the specification cannot be made
6205 publicly available, the request for a vendor-specific command code
6206 MUST include the contact information of persons and/or entities
6207 responsible for authoring and maintaining the command.
6209 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe
6210 - 0xffffff) are reserved for experimental commands. As these
6211 codes are only for experimental and testing purposes, no guarantee
6212 is made for interoperability between Diameter peers using
6213 experimental commands.
6215 11.2.2. Command Flags
6217 Section 3 describes the existing Command Flag field. The remaining
6218 bits can only be assigned via a Standards Action [RFC5226].
6220 11.3. AVP Values
6222 For AVP values, the Experimental-Result-Code AVP value allocation has
6223 been added, see Section 11.3.1. The old AVP value allocation rule
6224 IETF Consensus has been updated to IETF Review as per [RFC5226] and
6225 affected AVPs are listed as reminders.
6227 11.3.1. Experimental-Result-Code AVP
6229 Values for this AVP are purely local to the indicated vendor, and no
6230 IANA registry is maintained for them.
6232 11.3.2. Result-Code AVP Values
6234 New values are available for assignment via IETF Review [RFC5226].
6236 11.3.3. Accounting-Record-Type AVP Values
6238 New values are available for assignment via IETF Review [RFC5226].
6240 11.3.4. Termination-Cause AVP Values
6242 New values are available for assignment via IETF Review [RFC5226].
6244 11.3.5. Redirect-Host-Usage AVP Values
6246 New values are available for assignment via IETF Review [RFC5226].
6248 11.3.6. Session-Server-Failover AVP Values
6250 New values are available for assignment via IETF Review [RFC5226].
6252 11.3.7. Session-Binding AVP Values
6254 New values are available for assignment via IETF Review [RFC5226].
6256 11.3.8. Disconnect-Cause AVP Values
6258 New values are available for assignment via IETF Review [RFC5226].
6260 11.3.9. Auth-Request-Type AVP Values
6262 New values are available for assignment via IETF Review [RFC5226].
6264 11.3.10. Auth-Session-State AVP Values
6266 New values are available for assignment via IETF Review [RFC5226].
6268 11.3.11. Re-Auth-Request-Type AVP Values
6270 New values are available for assignment via IETF Review [RFC5226].
6272 11.3.12. Accounting-Realtime-Required AVP Values
6274 New values are available for assignment via IETF Review [RFC5226].
6276 11.3.13. Inband-Security-Id AVP (code 299)
6278 The use of this AVP has been deprecated.
6280 11.4. Diameter TCP, SCTP, TLS/TCP and DTLS/SCTP Port Numbers
6282 Updated port number assignments are described in this section. The
6283 IANA has assigned port number 3868 for TCP and SCTP. The port number
6284 [TBD] has been assigned for TLS/TCP and DTLS/SCTP.
6286 11.5. SCTP Payload Protocol Identifiers
6288 Two SCTP payload protocol identifiers are registered in SCTP Payload
6289 Protocol Identifier registry:
6291 Value | SCTP Payload Protocol Identifier
6292 --------|-----------------------------------
6293 TBD2 | Diameter in a SCTP DATA chunk
6294 TBD3 | Diameter in a DTLS/SCTP DATA chunk
6296 11.6. S-NAPTR Parameters
6298 This document also registers the following S-NAPTR Application
6299 Protocol Tags registry:
6301 Tag | Protocol
6302 -------------------|---------
6303 diameter.dtls.sctp | DTLS/SCTP
6305 12. Diameter Protocol-related Configurable Parameters
6307 This section contains the configurable parameters that are found
6308 throughout this document:
6310 Diameter Peer
6312 A Diameter entity MAY communicate with peers that are statically
6313 configured. A statically configured Diameter peer would require
6314 that either the IP address or the fully qualified domain name
6315 (FQDN) be supplied, which would then be used to resolve through
6316 DNS.
6318 Routing Table
6320 A Diameter proxy server routes messages based on the realm portion
6321 of a Network Access Identifier (NAI). The server MUST have a
6322 table of Realm Names, and the address of the peer to which the
6323 message must be forwarded to. The routing table MAY also include
6324 a "default route", which is typically used for all messages that
6325 cannot be locally processed.
6327 Tc timer
6329 The Tc timer controls the frequency that transport connection
6330 attempts are done to a peer with whom no active transport
6331 connection exists. The recommended value is 30 seconds.
6333 13. Security Considerations
6335 The Diameter base protocol messages SHOULD be secured by using TLS
6336 [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms
6337 such as IPsec [RFC4301] MAY also be deployed to secure connections
6338 between peers. However, all Diameter base protocol implementations
6339 MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter
6340 protocol MUST NOT be used without any security mechanism.
6342 If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP
6343 or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior
6344 to any Diameter message exchange. All security parameters for TLS/
6345 TCP and DTLS/SCTP or IPsec are configured independent of the Diameter
6346 protocol. All Diameter message will be sent through the TLS/TCP and
6347 DTLS/SCTP or IPsec connection after a successful setup.
6349 For TLS/TCP and DTLS/SCTP connections to be established in the open
6350 state, the CER/CEA exchange MUST include an Inband-Security-ID AVP
6351 with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP
6352 handshake will begin when both ends successfully reached the open
6353 state, after completion of the CER/CEA exchange. If the TLS/TCP and
6354 DTLS/SCTP handshake is successful, all further messages will be sent
6355 via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends move to
6356 the closed state. See Sections Section 13.1 for more details.
6358 13.1. TLS/TCP and DTLS/SCTP Usage
6360 Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually
6361 authenticate as part of TLS/TCP and DTLS/SCTP session establishment.
6362 In order to ensure mutual authentication, the Diameter node acting as
6363 TLS/TCP and DTLS/SCTP server MUST request a certificate from the
6364 Diameter node acting as TLS/TCP and DTLS/SCTP client, and the
6365 Diameter node acting as TLS/TCP and DTLS/SCTP client MUST be prepared
6366 to supply a certificate on request.
6368 Diameter nodes MUST be able to negotiate the following TLS/TCP and
6369 DTLS/SCTP cipher suites:
6371 TLS_RSA_WITH_RC4_128_MD5
6372 TLS_RSA_WITH_RC4_128_SHA
6373 TLS_RSA_WITH_3DES_EDE_CBC_SHA
6375 Diameter nodes SHOULD be able to negotiate the following TLS/TCP and
6376 DTLS/SCTP cipher suite:
6378 TLS_RSA_WITH_AES_128_CBC_SHA
6380 Diameter nodes MAY negotiate other TLS/TCP and DTLS/SCTP cipher
6381 suites.
6383 13.2. Peer-to-Peer Considerations
6385 As with any peer-to-peer protocol, proper configuration of the trust
6386 model within a Diameter peer is essential to security. When
6387 certificates are used, it is necessary to configure the root
6388 certificate authorities trusted by the Diameter peer. These root CAs
6389 are likely to be unique to Diameter usage and distinct from the root
6390 CAs that might be trusted for other purposes such as Web browsing.
6391 In general, it is expected that those root CAs will be configured so
6392 as to reflect the business relationships between the organization
6393 hosting the Diameter peer and other organizations. As a result, a
6394 Diameter peer will typically not be configured to allow connectivity
6395 with any arbitrary peer. With certificate authentication, Diameter
6396 peers may not be known beforehand and therefore peer discovery may be
6397 required.
6399 13.3. AVP Considerations
6401 Diameter AVPs often contain security-sensitive data; for example,
6402 user passwords and location data, network addresses and cryptographic
6403 keys. The Diameter messages containing such AVPs MUST only be sent
6404 protected via mutually authenticated TLS or IPsec. In addition,
6405 those messages SHOULD NOT be sent via intermediate nodes that would
6406 expose the sensitive data at those nodes except in cases where an
6407 intermediary is known to be operated as part of the same
6408 administrative domain as the endpoints so that an ability to
6409 successfully compromise the intermediary would imply a high
6410 probability of being able to compromise the endpoints as well.
6412 14. References
6414 14.1. Normative References
6416 [FLOATPOINT]
6417 Institute of Electrical and Electronics Engineers, "IEEE
6418 Standard for Binary Floating-Point Arithmetic, ANSI/IEEE
6419 Standard 754-1985", August 1985.
6421 [IANAADFAM]
6422 IANA,, "Address Family Numbers",
6423 http://www.iana.org/assignments/address-family-numbers.
6425 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
6427 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
6428 January 1981.
6430 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter
6431 Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
6432 RFC 6408, November 2011.
6434 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
6435 Accounting (AAA) Transport Profile", RFC 3539, June 2003.
6437 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
6438 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
6439 August 2005.
6441 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
6442 "Diameter Network Access Server Application", RFC 4005,
6443 August 2005.
6445 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
6447 Loughney, "Diameter Credit-Control Application", RFC 4006,
6448 August 2005.
6450 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
6451 Specifications: ABNF", STD 68, RFC 5234, January 2008.
6453 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
6454 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
6456 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
6457 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
6458 May 2008.
6460 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
6461 Architecture", RFC 4291, February 2006.
6463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6464 Requirement Levels", BCP 14, RFC 2119, March 1997.
6466 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
6467 Network Access Identifier", RFC 4282, December 2005.
6469 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
6470 Requirements for Security", BCP 106, RFC 4086, June 2005.
6472 [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
6473 RFC 4960, September 2007.
6475 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
6476 Service Location Using SRV RRs and the Dynamic Delegation
6477 Discovery Service (DDDS)", RFC 3958, January 2005.
6479 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
6480 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
6482 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6483 Resource Identifier (URI): Generic Syntax", STD 66,
6484 RFC 3986, January 2005.
6486 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
6487 10646", STD 63, RFC 3629, November 2003.
6489 [RFC5890] Klensin, J., "Internationalized Domain Names for
6490 Applications (IDNA): Definitions and Document Framework",
6491 RFC 5890, August 2010.
6493 [RFC5891] Klensin, J., "Internationalized Domain Names in
6494 Applications (IDNA): Protocol", RFC 5891, August 2010.
6496 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
6497 for Internationalized Domain Names in Applications
6498 (IDNA)", RFC 3492, March 2003.
6500 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou,
6501 "Clarifications on the Routing of Diameter Requests Based
6502 on the Username and the Realm", RFC 5729, December 2009.
6504 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
6505 Security Version 1.2", RFC 6347, January 2012.
6507 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
6508 Transport Layer Security (DTLS) for Stream Control
6509 Transmission Protocol (SCTP)", RFC 6083, January 2011.
6511 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
6512 Housley, R., and W. Polk, "Internet X.509 Public Key
6513 Infrastructure Certificate and Certificate Revocation List
6514 (CRL) Profile", RFC 5280, May 2008.
6516 14.2. Informational References
6518 [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
6519 Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C.,
6520 Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X.,
6521 Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim,
6522 B., Hirschman, B., Hsu, R., Koo, H., Lipford, M.,
6523 Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria
6524 for Evaluating AAA Protocols for Network Access",
6525 RFC 2989, November 2000.
6527 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
6528 Accounting Management", RFC 2975, October 2000.
6530 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
6531 Aboba, "Dynamic Authorization Extensions to Remote
6532 Authentication Dial In User Service (RADIUS)", RFC 5176,
6533 January 2008.
6535 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
6536 RFC 1661, July 1994.
6538 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
6540 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
6541 Extensions", RFC 2869, June 2000.
6543 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
6544 "Remote Authentication Dial In User Service (RADIUS)",
6545 RFC 2865, June 2000.
6547 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
6548 RFC 3162, August 2001.
6550 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
6551 Internet Protocol", RFC 4301, December 2005.
6553 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
6554 Time Protocol Version 4: Protocol and Algorithms
6555 Specification", RFC 5905, June 2010.
6557 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
6558 TACACS", RFC 1492, July 1993.
6560 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
6561 Recommendations for Internationalized Domain Names
6562 (IDNs)", RFC 4690, September 2006.
6564 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
6565 February 2009.
6567 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
6569 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
6570 Levkowetz, "Extensible Authentication Protocol (EAP)",
6571 RFC 3748, June 2004.
6573 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
6574 specifying the location of services (DNS SRV)", RFC 2782,
6575 February 2000.
6577 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
6578 Hashing for Message Authentication", RFC 2104,
6579 February 1997.
6581 [ENTERPRISE]
6582 IANA, "SMI Network Management Private Enterprise Codes",
6583 http://www.iana.org/assignments/enterprise-numbers.
6585 Appendix A. Acknowledgements
6587 A.1. RFC3588bis
6589 The authors would like to thank the following people that have
6590 provided proposals and contributions to this document:
6592 To Vishnu Ram and Satendra Gera for their contributions on
6593 Capabilities Updates, Predictive Loop Avoidance as well as many other
6594 technical proposals. To Tolga Asveren for his insights and
6595 contributions on almost all of the proposed solutions incorporated
6596 into this document. To Timothy Smith for helping on the Capabilities
6597 Updates and other topics. To Tony Zhang for providing fixes to loop
6598 holes on composing Failed-AVPs as well as many other issues and
6599 topics. To Jan Nordqvist for clearly stating the usage of
6600 Application Ids. To Anders Kristensen for providing needed technical
6601 opinions. To David Frascone for providing invaluable review of the
6602 document. To Mark Jones for providing clarifying text on vendor
6603 command codes and other vendor specific indicators. To Jouni
6604 Korhonen for taking over the editing task and resolving last bits
6605 from -27 version onwards.
6607 Special thanks to the Diameter extensibility design team which helped
6608 resolve the tricky question of mandatory AVPs and ABNF semantics.
6609 The members of this team are as follows:
6611 Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga
6612 Asveren Jouni Korhonen, Glenn McGregor.
6614 Special thanks also to people who have provided invaluable comments
6615 and inputs especially in resolving controversial issues:
6617 Glen Zorn, Yoshihiro Ohba, Marco Stura, and Pasi Eronen.
6619 Finally, we would like to thank the original authors of this
6620 document:
6622 Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman and Glen Zorn.
6624 Their invaluable knowledge and experience has given us a robust and
6625 flexible AAA protocol that many people have seen great value in
6626 adopting. We greatly appreciate their support and stewardship for
6627 the continued improvements of Diameter as a protocol. We would also
6628 like to extend our gratitude to folks aside from the authors who have
6629 assisted and contributed to the original version of this document.
6630 Their efforts significantly contributed to the success of Diameter.
6632 A.2. RFC3588
6634 The authors would like to thank Nenad Trifunovic, Tony Johansson and
6635 Pankaj Patel for their participation in the pre-IETF Document Reading
6636 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided
6637 invaluable assistance in working out transport issues, and similarly
6638 with Steven Bellovin in the security area.
6640 Paul Funk and David Mitton were instrumental in getting the Peer
6641 State Machine correct, and our deep thanks go to them for their time.
6643 Text in this document was also provided by Paul Funk, Mark Eklund,
6644 Mark Jones and Dave Spence. Jacques Caron provided many great
6645 comments as a result of a thorough review of the spec.
6647 The authors would also like to acknowledge the following people for
6648 their contribution in the development of the Diameter protocol:
6650 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell,
6651 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy
6652 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien,
6653 Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin,
6654 Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and
6655 Jeff Weisberg.
6657 Finally, Pat Calhoun would like to thank Sun Microsystems since most
6658 of the effort put into this document was done while he was in their
6659 employ.
6661 Appendix B. S-NAPTR Example
6663 As an example, consider a client that wishes to resolve aaa:
6664 ex1.example.com. The client performs a NAPTR query for that domain,
6665 and the following NAPTR records are returned:
6667 ;; order pref flags service regexp replacement
6668 IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" ""
6669 _diameter._tls.ex1.example.com
6670 IN NAPTR 100 50 "s" "aaa:diameter.tcp" ""
6671 _aaa._tcp.ex1.example.com
6672 IN NAPTR 150 50 "s" "aaa:diameter.sctp" ""
6673 _diameter._sctp.ex1.example.com
6675 This indicates that the server supports TLS, TCP and SCTP in that
6676 order. If the client supports TLS, TLS will be used, targeted to a
6677 host determined by an SRV lookup of _diameter._tls.ex1.example.com.
6678 That lookup would return:
6680 ;; Priority Weight Port Target
6681 IN SRV 0 1 5060 server1.ex1.example.com
6682 IN SRV 0 2 5060 server2.ex1.example.com
6684 As an alternative example, a client that wishes to resolve aaa:
6685 ex2.example.com. The client performs a NAPTR query for that domain,
6686 and the following NAPTR records are returned:
6688 ;; order pref flags service regexp replacement
6689 IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
6690 server1.ex2.example.com
6691 IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
6692 server2.ex2.example.com
6694 This indicates that the server supports TCP available at the returned
6695 host names.
6697 Appendix C. Duplicate Detection
6699 As described in Section 9.4, accounting record duplicate detection is
6700 based on session identifiers. Duplicates can appear for various
6701 reasons:
6703 o Failover to an alternate server. Where close to real-time
6704 performance is required, failover thresholds need to be kept low
6705 and this may lead to an increased likelihood of duplicates.
6706 Failover can occur at the client or within Diameter agents.
6708 o Failure of a client or agent after sending of a record from non-
6709 volatile memory, but prior to receipt of an application layer ACK
6710 and deletion of the record. record to be sent. This will result
6711 in retransmission of the record soon after the client or agent has
6712 rebooted.
6714 o Duplicates received from RADIUS gateways. Since the
6715 retransmission behavior of RADIUS is not defined within [RFC2865],
6716 the likelihood of duplication will vary according to the
6717 implementation.
6719 o Implementation problems and misconfiguration.
6721 The T flag is used as an indication of an application layer
6722 retransmission event, e.g., due to failover to an alternate server.
6723 It is defined only for request messages sent by Diameter clients or
6724 agents. For instance, after a reboot, a client may not know whether
6725 it has already tried to send the accounting records in its non-
6726 volatile memory before the reboot occurred. Diameter servers MAY use
6727 the T flag as an aid when processing requests and detecting duplicate
6728 messages. However, servers that do this MUST ensure that duplicates
6729 are found even when the first transmitted request arrives at the
6730 server after the retransmitted request. It can be used only in cases
6731 where no answer has been received from the Server for a request and
6732 the request is sent again, (e.g., due to a failover to an alternate
6733 peer, due to a recovered primary peer or due to a client re-sending a
6734 stored record from non-volatile memory such as after reboot of a
6735 client or agent).
6737 In some cases the Diameter accounting server can delay the duplicate
6738 detection and accounting record processing until a post-processing
6739 phase takes place. At that time records are likely to be sorted
6740 according to the included User-Name and duplicate elimination is easy
6741 in this case. In other situations it may be necessary to perform
6742 real-time duplicate detection, such as when credit limits are imposed
6743 or real-time fraud detection is desired.
6745 In general, only generation of duplicates due to failover or re-
6746 sending of records in non-volatile storage can be reliably detected
6747 by Diameter clients or agents. In such cases the Diameter client or
6748 agents can mark the message as possible duplicate by setting the T
6749 flag. Since the Diameter server is responsible for duplicate
6750 detection, it can choose to make use of the T flag or not, in order
6751 to optimize duplicate detection. Since the T flag does not affect
6752 interoperability, and may not be needed by some servers, generation
6753 of the T flag is REQUIRED for Diameter clients and agents, but MAY be
6754 implemented by Diameter servers.
6756 As an example, it can be usually be assumed that duplicates appear
6757 within a time window of longest recorded network partition or device
6758 fault, perhaps a day. So only records within this time window need
6759 to be looked at in the backward direction. Secondly, hashing
6760 techniques or other schemes, such as the use of the T flag in the
6761 received messages, may be used to eliminate the need to do a full
6762 search even in this set except for rare cases.
6764 The following is an example of how the T flag may be used by the
6765 server to detect duplicate requests.
6767 A Diameter server MAY check the T flag of the received message to
6768 determine if the record is a possible duplicate. If the T flag is
6769 set in the request message, the server searches for a duplicate
6770 within a configurable duplication time window backward and
6771 forward. This limits database searching to those records where
6772 the T flag is set. In a well run network, network partitions and
6773 device faults will presumably be rare events, so this approach
6774 represents a substantial optimization of the duplicate detection
6775 process. During failover, it is possible for the original record
6776 to be received after the T flag marked record, due to differences
6777 in network delays experienced along the path by the original and
6778 duplicate transmissions. The likelihood of this occurring
6779 increases as the failover interval is decreased. In order to be
6780 able to detect out of order duplicates, the Diameter server should
6781 use backward and forward time windows when performing duplicate
6782 checking for the T flag marked request. For example, in order to
6783 allow time for the original record to exit the network and be
6784 recorded by the accounting server, the Diameter server can delay
6785 processing records with the T flag set until a time period
6786 TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing
6787 of the original transport connection. After this time period has
6788 expired, then it may check the T flag marked records against the
6789 database with relative assurance that the original records, if
6790 sent, have been received and recorded.
6792 Appendix D. Internationalized Domain Names
6794 To be compatible with the existing DNS infrastructure and simplify
6795 host and domain name comparison, Diameter identities (FQDNs) are
6796 represented in ASCII form. This allows the Diameter protocol to fall
6797 in-line with the DNS strategy of being transparent from the effects
6798 of Internationalized Domain Names (IDNs) by following the
6799 recommendations in [RFC4690] and [RFC5890]. Applications that
6800 provide support for IDNs outside of the Diameter protocol but
6801 interacting with it SHOULD use the representation and conversion
6802 framework described in [RFC5890], [RFC5891] and [RFC3492].
6804 Authors' Addresses
6806 Victor Fajardo (editor)
6807 Telcordia Technologies
6808 One Telcordia Drive, 1S-222
6809 Piscataway, NJ 08854
6810 USA
6812 Phone: +1-908-421-1845
6813 Email: vf0213@gmail.com
6815 Jari Arkko
6816 Ericsson Research
6817 02420 Jorvas
6818 Finland
6820 Phone: +358 40 5079256
6821 Email: jari.arkko@ericsson.com
6822 John Loughney
6823 Nokia Research Center
6824 955 Page Mill Road
6825 Palo Alto, CA 94304
6826 US
6828 Phone: +1-650-283-8068
6829 Email: john.loughney@nokia.com
6831 Glen Zorn (editor)
6832 Network Zen
6833 227/358 Thanon Sanphawut
6834 Bang Na, Bangkok 10260
6835 Thailand
6837 Phone: +66 (0) 87-0404617
6838 Email: glenzorn@gmail.com