idnits 2.17.1
draft-ietf-dime-rfc3588bis-15.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 20.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 6789.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6800.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6807.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6813.
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 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
-- The draft header indicates that this document obsoletes RFC3588, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Line 4494 has weird spacing: '...ly with wit...'
== Line 4701 has weird spacing: '...ealtime user...'
== Line 4729 has weird spacing: '... record inter...'
== Line 4739 has weird spacing: '...ealtime user...'
== Line 4747 has weird spacing: '...ealtime user...'
== (1 more instance...)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 11, 2008) is 5606 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 975, but not defined
== Missing Reference: 'PXY' is mentioned on line 4207, but not defined
== Unused Reference: 'RFC3280' is defined on line 6462, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'FLOATPOINT'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM'
-- Possible downref: Non-RFC (?) normative reference: ref. 'RADTYPE'
** 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 4234 (Obsoleted by RFC 5234)
** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733)
** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960)
** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280)
** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891)
-- Obsolete informational reference (is this intentional?): RFC 3576
(Obsoleted by RFC 5176)
-- Obsolete informational reference (is this intentional?): RFC 4330
(Obsoleted by RFC 5905)
Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DIME V. Fajardo, Ed.
3 Internet-Draft Toshiba America Research
4 Obsoletes: 3588 (if approved) J. Arkko
5 Intended status: Standards Track Ericsson Research
6 Expires: June 14, 2009 J. Loughney
7 Nokia Research Center
8 G. Zorn
9 NetCube
10 December 11, 2008
12 Diameter Base Protocol
13 draft-ietf-dime-rfc3588bis-15.txt
15 Status of this Memo
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on June 14, 2009.
40 Abstract
42 The Diameter base protocol is intended to provide an Authentication,
43 Authorization and Accounting (AAA) framework for applications such as
44 network access or IP mobility. Diameter is also intended to work in
45 both local Authentication, Authorization & Accounting and roaming
46 situations. This document specifies the message format, transport,
47 error reporting, accounting and security services to be used by all
48 Diameter applications. The Diameter base application needs to be
49 supported by all Diameter implementations.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
54 1.1. Diameter Protocol . . . . . . . . . . . . . . . . . . . . 9
55 1.1.1. Description of the Document Set . . . . . . . . . . 11
56 1.1.2. Conventions Used in This Document . . . . . . . . . 12
57 1.1.3. Changes from RFC3588 . . . . . . . . . . . . . . . . 12
58 1.2. Approach to Extensibility . . . . . . . . . . . . . . . . 13
59 1.2.1. Defining New AVP Values . . . . . . . . . . . . . . 13
60 1.2.2. Creating New AVPs . . . . . . . . . . . . . . . . . 14
61 1.2.3. Creating New Commands . . . . . . . . . . . . . . . 14
62 1.2.4. Creating New Diameter Applications . . . . . . . . . 14
63 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 16
64 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22
65 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23
66 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 24
67 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 24
68 2.3. Diameter Application Compliance . . . . . . . . . . . . . 24
69 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 24
70 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 25
71 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 26
72 2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 27
73 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 28
74 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 30
75 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 31
76 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 31
77 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 32
78 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33
79 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
80 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38
81 3.2. Command Code ABNF specification . . . . . . . . . . . . . 38
82 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 41
83 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42
84 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42
85 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 43
86 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
87 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 45
88 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 52
89 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 53
90 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56
91 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 59
92 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 59
93 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 59
94 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62
95 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 63
96 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 63
97 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 64
98 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 64
99 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 65
100 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 65
101 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 65
102 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 65
103 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 66
104 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 66
105 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 66
106 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 67
107 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 67
108 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 67
109 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 68
110 5.5.4. Failover and Failback Procedures . . . . . . . . . . 68
111 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 69
112 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 71
113 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 72
114 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 73
115 5.6.4. The Election Process . . . . . . . . . . . . . . . . 75
116 6. Diameter message processing . . . . . . . . . . . . . . . . . 76
117 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76
118 6.1.1. Originating a Request . . . . . . . . . . . . . . . 77
119 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 77
120 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78
121 6.1.4. Processing Local Requests . . . . . . . . . . . . . 78
122 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 78
123 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 78
124 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 79
125 6.1.8. Redirecting Requests . . . . . . . . . . . . . . . . 79
126 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 80
127 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 82
128 6.2.1. Processing received Answers . . . . . . . . . . . . 82
129 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 82
130 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 83
131 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 83
132 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 83
133 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 84
134 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 84
135 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 84
136 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 84
137 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 85
138 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 85
139 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 85
140 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 85
141 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 85
142 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 86
143 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 87
144 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87
145 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88
146 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90
147 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 92
148 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92
149 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 93
150 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 93
151 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94
152 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95
153 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98
154 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 98
155 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 99
156 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 99
157 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 100
158 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100
159 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 101
160 8.1. Authorization Session State Machine . . . . . . . . . . . 102
161 8.2. Accounting Session State Machine . . . . . . . . . . . . 107
162 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112
163 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112
164 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113
165 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 114
166 8.4.1. Session-Termination-Request . . . . . . . . . . . . 115
167 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 115
168 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 116
169 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 116
170 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 117
171 8.6. Inferring Session Termination from Origin-State-Id . . . 118
172 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 118
173 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 119
174 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 120
175 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 121
176 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 121
177 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 121
178 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 122
179 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 122
180 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 122
181 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 124
182 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 124
183 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 125
184 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 126
185 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 126
186 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 126
187 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 127
188 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 127
189 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 128
190 9.3. Accounting Application Extension and Requirements . . . . 128
191 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 129
192 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 129
193 9.6. Correlation of Accounting Records . . . . . . . . . . . . 130
194 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 131
195 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 131
196 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 132
197 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 133
198 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 133
199 9.8.2. Acct-Interim-Interval AVP . . . . . . . . . . . . . 134
200 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 135
201 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 135
202 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 135
203 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 135
204 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 136
205 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 137
206 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 137
207 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 138
208 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
209 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 140
210 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 140
211 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 141
212 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 141
213 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 141
214 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 142
215 11.3. Application Identifiers . . . . . . . . . . . . . . . . . 142
216 11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 142
217 11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 143
218 11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 143
219 11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 143
220 11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 143
221 11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 143
222 11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 143
223 11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 143
224 11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 143
225 11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 144
226 11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144
227 11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 144
228 11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 144
229 11.5. Diameter TCP/SCTP and TLS Port Numbers . . . . . . . . . 144
230 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144
232 12. Diameter protocol related configurable parameters . . . . . . 146
233 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147
234 13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147
235 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 147
236 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
237 14.1. Normative References . . . . . . . . . . . . . . . . . . 149
238 14.2. Informational References . . . . . . . . . . . . . . . . 151
239 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153
240 A.1. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . . 153
241 A.2. RFC3588 . . . . . . . . . . . . . . . . . . . . . . . . . 154
242 Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 155
243 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 156
244 Appendix D. Internationalized Domain Names . . . . . . . . . . . 158
245 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159
246 Intellectual Property and Copyright Statements . . . . . . . . . 160
248 1. Introduction
250 Authentication, Authorization and Accounting (AAA) protocols such as
251 TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
252 provide dial-up PPP [RFC1661] and terminal server access. Over time,
253 with the growth of the Internet and the introduction of new access
254 technologies (including wireless, DSL, Mobile IP and Ethernet), both
255 the amount and complexity of processing performed by routers and
256 network access servers (NAS) have increased, putting new demands on
257 AAA protocols.
259 Network access requirements for AAA protocols are summarized in
260 [RFC2989]. These include:
262 Failover
264 [RFC2865] does not define failover mechanisms, and as a result,
265 failover behavior differs between implementations. In order to
266 provide well defined failover behavior, Diameter supports
267 application-layer acknowledgements, and defines failover
268 algorithms and the associated state machine. This is described in
269 Section 5.5 and [RFC3539].
271 Transmission-level security
273 [RFC2865] defines an application-layer authentication and
274 integrity scheme that is required only for use with Response
275 packets. While [RFC2869] defines an additional authentication and
276 integrity mechanism, use is only required during Extensible
277 Authentication Protocol (EAP) sessions. While attribute-hiding is
278 supported, [RFC2865] does not provide support for per-packet
279 confidentiality. In accounting, [RFC2866] assumes that replay
280 protection is provided by the backend billing server, rather than
281 within the protocol itself.
283 While [RFC3162] defines the use of IPsec with RADIUS, support for
284 IPsec is not required. Since within [RFC4306] authentication
285 occurs only within Phase 1 prior to the establishment of IPsec SAs
286 in Phase 2, it is typically not possible to define separate trust
287 or authorization schemes for each application. This limits the
288 usefulness of IPsec in inter-domain AAA applications (such as
289 roaming) where it may be desirable to define a distinct
290 certificate hierarchy for use in a AAA deployment. In order to
291 provide universal support for transmission-level security, and
292 enable both intra- and inter-domain AAA deployments, Diameter
293 provides support for TLS. Security is discussed in Section 13.
295 Reliable transport
297 RADIUS runs over UDP, and does not define retransmission behavior;
298 as a result, reliability varies between implementations. As
299 described in [RFC2975], this is a major issue in accounting, where
300 packet loss may translate directly into revenue loss. In order to
301 provide well defined transport behavior, Diameter runs over
302 reliable transport mechanisms (TCP, SCTP) as defined in [RFC3539].
304 Agent support
306 [RFC2865] does not provide for explicit support for agents,
307 including Proxies, Redirects and Relays. Since the expected
308 behavior is not defined, it varies between implementations.
309 Diameter defines agent behavior explicitly; this is described in
310 Section 2.8.
312 Server-initiated messages
314 While RADIUS server-initiated messages are defined in [RFC3576],
315 support is optional. This makes it difficult to implement
316 features such as unsolicited disconnect or reauthentication/
317 reauthorization on demand across a heterogeneous deployment.
318 Support for server-initiated messages is mandatory in Diameter,
319 and is described in Section 8.
321 Transition support
323 While Diameter does not share a common protocol data unit (PDU)
324 with RADIUS, considerable effort has been expended in enabling
325 backward compatibility with RADIUS, so that the two protocols may
326 be deployed in the same network. Initially, it is expected that
327 Diameter will be deployed within new network devices, as well as
328 within gateways enabling communication between legacy RADIUS
329 devices and Diameter agents. This capability, described in
330 [RFC4005], enables Diameter support to be added to legacy
331 networks, by addition of a gateway or server speaking both RADIUS
332 and Diameter.
334 In addition to addressing the above requirements, Diameter also
335 provides support for the following:
337 Capability negotiation
339 RADIUS does not support error messages, capability negotiation, or
340 a mandatory/non-mandatory flag for attributes. Since RADIUS
341 clients and servers are not aware of each other's capabilities,
342 they may not be able to successfully negotiate a mutually
343 acceptable service, or in some cases, even be aware of what
344 service has been implemented. Diameter includes support for error
345 handling (Section 7), capability negotiation (Section 5.3), and
346 mandatory/non-mandatory attribute-value pairs (AVPs) (Section
347 4.1).
349 Peer discovery and configuration
351 RADIUS implementations typically require that the name or address
352 of servers or clients be manually configured, along with the
353 corresponding shared secrets. This results in a large
354 administrative burden, and creates the temptation to reuse the
355 RADIUS shared secret, which can result in major security
356 vulnerabilities if the Request Authenticator is not globally and
357 temporally unique as required in [RFC2865]. Through DNS, Diameter
358 enables dynamic discovery of peers. Derivation of dynamic session
359 keys is enabled via transmission-level security.
361 Over time, the capabilities of Network Access Server (NAS) devices
362 have increased substantially. As a result, while Diameter is a
363 considerably more sophisticated protocol than RADIUS, it remains
364 feasible to implement within embedded devices, given improvements in
365 processor speeds and the widespread availability of embedded TLS
366 implementations.
368 1.1. Diameter Protocol
370 The Diameter base protocol provides the following facilities:
372 o Delivery of AVPs (attribute value pairs)
374 o Capabilities negotiation
376 o Error notification
378 o Extensibility, through addition of new applications, commands and
379 AVPs (required in [RFC2989]).
381 o Basic services necessary for applications, such as handling of
382 user sessions or accounting
384 All data delivered by the protocol is in the form of an AVP. Some of
385 these AVP values are used by the Diameter protocol itself, while
386 others deliver data associated with particular applications that
387 employ Diameter. AVPs may be added arbitrarily to Diameter messages,
388 so long as the requirements of a message's ABNF are met. AVPs are
389 used by the base Diameter protocol to support the following required
390 features:
392 o Transporting of user authentication information, for the purposes
393 of enabling the Diameter server to authenticate the user.
395 o Transporting of service specific authorization information,
396 between client and servers, allowing the peers to decide whether a
397 user's access request should be granted.
399 o Exchanging resource usage information, which may be used for
400 accounting purposes, capacity planning, etc.
402 o Relaying, proxying and redirecting of Diameter messages through a
403 server hierarchy.
405 The Diameter base protocol provides the minimum requirements needed
406 for a AAA protocol, as required by [RFC2989]. The base protocol may
407 be used by itself for accounting purposes only, or it may be used
408 with a Diameter application, such as Mobile IPv4 [RFC4004], or
409 network access [RFC4005]. It is also possible for the base protocol
410 to be extended for use in new applications, via the addition of new
411 commands or AVPs. At this time the focus of Diameter is network
412 access and accounting applications. A truly generic AAA protocol
413 used by many applications might provide functionality not provided by
414 Diameter. Therefore, it is imperative that the designers of new
415 applications understand their requirements before using Diameter.
416 See Section 2.4 for more information on Diameter applications.
418 Any node can initiate a request. In that sense, Diameter is a peer-
419 to-peer protocol. In this document, a Diameter Client is a device at
420 the edge of the network that performs access control, such as a
421 Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
422 client generates Diameter messages to request authentication,
423 authorization, and accounting services for the user. A Diameter
424 agent is a node that does not provide local user authentication or
425 authorization services; agents include proxies, redirects and relay
426 agents. A Diameter server performs authentication and/or
427 authorization of the user. A Diameter node may act as an agent for
428 certain requests while acting as a server for others.
430 The Diameter protocol also supports server-initiated messages, such
431 as a request to abort service to a particular user.
433 1.1.1. Description of the Document Set
435 Currently, the Diameter specification consists of an updated version
436 of the base protocol specification (this document), Transport Profile
437 [RFC3539] and applications: Mobile IPv4 [RFC4004], NASREQ [RFC4005],
438 Credit Control [RFC4006], EAP [RFC4072] and SIP [RFC4740]. Note that
439 this document obsoletes [RFC3588]. A summary of the base protocol
440 updates included in this document can be found in Section 1.1.3.
442 The Transport Profile document [RFC3539] discusses transport layer
443 issues that arise with AAA protocols and recommendations on how to
444 overcome these issues. This document also defines the Diameter
445 failover algorithm and state machine.
447 The Mobile IPv4 [RFC4004] application defines a Diameter application
448 that allows a Diameter server to perform AAA functions for Mobile
449 IPv4 services to a mobile node.
451 The NASREQ [RFC4005] application defines a Diameter Application that
452 allows a Diameter server to be used in a PPP/SLIP Dial-Up and
453 Terminal Server Access environment. Consideration was given for
454 servers that need to perform protocol conversion between Diameter and
455 RADIUS.
457 The Credit Control [RFC4006] application defines a Diameter
458 Application that can be used to implement real-time credit-control
459 for a variety of end user services such as network access, SIP
460 services, messaging services, and download services. It provides a
461 general solution to real-time cost and credit-control.
463 The EAP [RFC4072] application defines a Diameter Application that can
464 be used to carry EAP packets between the Network Access Server (NAS)
465 working as an EAP authenticator and a back-end authentication server.
466 The Diameter EAP application is based on NASREQ and intended for a
467 similar environment.
469 The SIP [RFC4740] application defines a Diameter Application that
470 allows a Diameter client to request authentication and authorization
471 information to a Diameter server for SIP-based IP multimedia services
472 (see SIP [RFC3261]).
474 In summary, this document defines the base protocol specification for
475 AAA, which includes support for accounting. The applications
476 documents describe applications that use this base specification for
477 Authentication, Authorization and Accounting.
479 1.1.2. Conventions Used in This Document
481 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
482 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
483 document are to be interpreted as described in [RFC2119].
485 1.1.3. Changes from RFC3588
487 This document deprecates [RFC3588] but is fully backward compatible
488 with that document. The changes introduced in this document focuses
489 on fixing issues that have surfaced during implementation of
490 [RFC3588]. An overview of some the major changes are shown below.
492 o Simplified Security Requirements. The use of a secured transport
493 for exchanging Diameter messages remains mandatory. However, TLS
494 has become the primary method of securing Diameter and IPsec is a
495 secondary alternative. Also, the start of the TLS handshake is no
496 longer embedded in peer state machine but is now started before
497 any Diameter messages are exchanged. See Section 13 for details.
498 Along with this, the support for the End-to-End security framework
499 (E2ESequence AVP and 'P'-bit in the AVP header) has also been
500 deprecated.
502 o Diameter Extensibility Changes. This includes fixes to the
503 Diameter extensibility description (Section 1.2 and others) to
504 better aid Diameter application designers. It also includes
505 allocation of vendor specific command code space. The new
506 specification relaxes the allocation of command codes for vendor
507 specific uses. See Section 11.2.1 for details.
509 o Application Id Usage. Clarify the proper use of Application Id
510 information which can be found in multiple places within a
511 Diameter message. This includes co-relating Application Ids found
512 in the message headers and AVPs. These changes also clearly
513 specifies the proper Application Id value to use for specific base
514 protocol messages (ASR/ASA, STR/STA) as well as clarifying the
515 content and use of Vendor-Specific-Application-Id.
517 o Routing Fixes. For general routing, specifies much more clearly
518 what information (AVPs and Application Id) can be used for making
519 routing decisions. Prioritization of redirect routing criterias
520 when multiple route entries are found via redirects has also been
521 added (See Section 6.13 for details).
523 o Simplification of Diameter Peer Discovery. The Diameter discovery
524 process now supports only well known discovery schemes. The rest
525 has been deprecated. (See Section 5.2 for details).
527 There are many other many miscellaneous fixes that has been
528 introduced in this document that may not be considered significant
529 but they are important nonetheless. Examples are removal of obsolete
530 types, fixes to command ABNFs, fixes to the state machine,
531 clarification on election process, message validation, fixes to
532 Failed-AVP and Result-Code AVP values etc. A comprehensive list of
533 changes is not shown here for practical reasons. Though, that can be
534 generated via a diff comparison between this document and [RFC3588].
536 1.2. Approach to Extensibility
538 The Diameter protocol is designed to be extensible, using several
539 mechanisms, including:
541 o Defining new AVP values
543 o Creating new AVPs
545 o Creating new commands
547 o Creating new applications
549 From the point of extensibility Diameter authentication,
550 authorization and accounting applications are treated in the same
551 way.
553 Note: Protocol designer should try to re-use existing functionality,
554 namely AVP values, AVPs, commands, and Diameter applications. Reuse
555 simplifies standardization and implementation. To avoid potential
556 interoperability issues it is important to ensure that the semantics
557 of the re-used features are well understood.
559 1.2.1. Defining New AVP Values
561 In order to allocate a new AVP value for AVPs defined in the Diameter
562 Base protocol, the IETF needs to approve a new RFC that describes the
563 AVP value. IANA considerations for these AVP values are discussed in
564 Section 11.4.
566 The allocation of AVP values for other AVPs is guided by the IANA
567 considerations of the documents that defines those AVPs. Typically,
568 allocation of new values for an AVP defined in an IETF RFC should
569 require IETF Review [RFC2434], where as values for vendor-specific
570 AVPs can be allocated by the vendor.
572 1.2.2. Creating New AVPs
574 A new AVP being defined MUST use one of the data types listed in
575 Section 4.2 or 4.3. If an appropriate derived data type is already
576 defined, it SHOULD be used instead of the base data type to encourage
577 reusability and good design practice.
579 In the event that a logical grouping of AVPs is necessary, and
580 multiple "groups" are possible in a given command, it is recommended
581 that a Grouped AVP be used (see Section 4.4).
583 The creation of new AVPs can happen in various ways. The recommended
584 approach is to define a new general-purpose AVP in a standards track
585 RFC approved by the IETF. However, as described in Section 11.1.1
586 there are also other mechanisms.
588 1.2.3. Creating New Commands
590 A new Command Code MUST be allocated when new required AVPs (those
591 indicated as {AVP}) are added, deleted or are redefined (for example
592 by changing a required AVP into an optional one).
594 Furthermore, when a command is modified with respect to the number of
595 round trips then a new Command Code has to be registered.
597 A change to the ABNF of a command, such as described above, MUST
598 result in the definition of a new Command Code. This subsequently
599 leads to the need to define a new Diameter Application for any
600 application that will use that new Command.
602 The IANA considerations for commands are discussed in Section 11.2.1.
604 1.2.4. Creating New Diameter Applications
606 Every Diameter application specification MUST have an IANA assigned
607 Application Id (see Section 2.4 and Section 11.3). The managed
608 Application ID space is flat and there is no relationship between
609 different Diameter applications with respect to their application
610 IDs. As such, there is no versioning supported provided by these
611 application IDs itself; every Diameter application is a standalone
612 application that may or may not have a semantical relationship with
613 one or more Diameter applications being defined elsewhere.
615 Before describing the rules for creating new Diameter applications it
616 is important to discuss the semantics of the AVPs occurrences as
617 stated in the ABNF and the M-bit flag for an AVP. There is no
618 relationship imposed between the two; they are set independently.
620 o The ABNF indicates what AVPs are placed into a Diameter Command by
621 the sender of that Command. Often, since there are multiple modes
622 of protocol interactions many of the AVPs are indicated as
623 optional.
625 o The M-bit allows the sender to indicate to the receiver whether
626 the semantics of an AVP and it's content has to be understood
627 mandatorily or not. If the M-bit is set by the sender and the
628 receiver does not understand the AVP or the values carried within
629 that AVP then a failure is generated (see Section 7).
631 It is the decision of the protocol designer when to develop a new
632 Diameter application rather than extending Diameter in other ways.
633 However, a new Diameter application MUST be created when one or more
634 of the following criteria are met:
636 M-bit Setting
638 Adding an AVP with the M-bit in the MUST column of the AVP flag
639 table to an existing Command/Application requires a new Diameter
640 Application Id to be assigned to that Application.
642 Adding an AVP with the M-bit in the MAY column of the AVP flag
643 table to an existing Command/Application requires a new Diameter
644 Application Id to be assigned to that Application.
646 Note: The M-bit setting for a given AVP is relevant to an
647 Application and each command within that application which
648 includes the AVP. That is, if an AVP appears in two commands for
649 application Foo and the M-bit settings are different in each
650 command, then there should be two AVP flag tables describing when
651 to set the M-bit.
653 Commands
655 A new command is used within the existing application either
656 because an additional command is added, an existing command has
657 been modified so that a new Command Code had to be registered, or
658 a command has been deleted.
660 An implementation MAY add arbitrary optional AVPs with the M-bit
661 cleared to a command defined in an application, including vendor-
662 specific AVPs without needing to define a new application. This can
663 be done if the commands ABNF allows for it. Please refer to Section
664 11.1.1 for details.
666 1.3. Terminology
668 AAA
670 Authentication, Authorization and Accounting.
672 Accounting
674 The act of collecting information on resource usage for the
675 purpose of capacity planning, auditing, billing or cost
676 allocation.
678 Accounting Record
680 An accounting record represents a summary of the resource
681 consumption of a user over the entire session. Accounting servers
682 creating the accounting record may do so by processing interim
683 accounting events or accounting events from several devices
684 serving the same user.
686 Authentication
688 The act of verifying the identity of an entity (subject).
690 Authorization
692 The act of determining whether a requesting entity (subject) will
693 be allowed access to a resource (object).
695 AVP
697 The Diameter protocol consists of a header followed by one or more
698 Attribute-Value-Pairs (AVPs). An AVP includes a header and is
699 used to encapsulate protocol-specific data (e.g., routing
700 information) as well as authentication, authorization or
701 accounting information.
703 Broker
705 A broker is a business term commonly used in AAA infrastructures.
706 A broker is either a relay, proxy or redirect agent, and may be
707 operated by roaming consortiums. Depending on the business model,
708 a broker may either choose to deploy relay agents or proxy agents.
710 Diameter Agent
712 A Diameter Agent is a Diameter node that provides either relay,
713 proxy, redirect or translation services.
715 Diameter Client
717 A Diameter Client is a device at the edge of the network that
718 performs access control. An example of a Diameter client is a
719 Network Access Server (NAS) or a Foreign Agent (FA). By its very
720 nature, a Diameter Client must support Diameter client
721 applications in addition to the base protocol.
723 Diameter Node
725 A Diameter node is a host process that implements the Diameter
726 protocol, and acts either as a Client, Agent or Server.
728 Diameter Peer
730 A Diameter Peer is a Diameter Node to which a given Diameter Node
731 has a direct transport connection.
733 Diameter Server
735 A Diameter Server is one that handles authentication,
736 authorization and accounting requests for a particular realm. By
737 its very nature, a Diameter Server must support Diameter server
738 applications in addition to the base protocol.
740 Downstream
742 Downstream is used to identify the direction of a particular
743 Diameter message from the home server towards the access device.
745 Home Realm
747 A Home Realm is the administrative domain with which the user
748 maintains an account relationship.
750 Home Server
752 A Diameter Server which serves the Home Realm.
754 Interim accounting
756 An interim accounting message provides a snapshot of usage during
757 a user's session. It is typically implemented in order to provide
758 for partial accounting of a user's session in the case of a device
759 reboot or other network problem prevents the reception of a
760 session summary message or session record.
762 Local Realm
764 A local realm is the administrative domain providing services to a
765 user. An administrative domain may act as a local realm for
766 certain users, while being a home realm for others.
768 Multi-session
770 A multi-session represents a logical linking of several sessions.
771 Multi-sessions are tracked by using the Acct-Multi-Session-Id. An
772 example of a multi-session would be a Multi-link PPP bundle. Each
773 leg of the bundle would be a session while the entire bundle would
774 be a multi-session.
776 Network Access Identifier
778 The Network Access Identifier, or NAI [RFC4282], is used in the
779 Diameter protocol to extract a user's identity and realm. The
780 identity is used to identify the user during authentication and/or
781 authorization, while the realm is used for message routing
782 purposes.
784 Proxy Agent or Proxy
786 In addition to forwarding requests and responses, proxies make
787 policy decisions relating to resource usage and provisioning.
788 This is typically accomplished by tracking the state of NAS
789 devices. While proxies typically do not respond to client
790 Requests prior to receiving a Response from the server, they may
791 originate Reject messages in cases where policies are violated.
792 As a result, proxies need to understand the semantics of the
793 messages passing through them, and may not support all Diameter
794 applications.
796 Realm
798 The string in the NAI that immediately follows the '@' character.
799 NAI realm names are required to be unique, and are piggybacked on
800 the administration of the DNS namespace. Diameter makes use of
801 the realm, also loosely referred to as domain, to determine
802 whether messages can be satisfied locally, or whether they must be
803 routed or redirected. In RADIUS, realm names are not necessarily
804 piggybacked on the DNS namespace but may be independent of it.
806 Real-time Accounting
808 Real-time accounting involves the processing of information on
809 resource usage within a defined time window. Time constraints are
810 typically imposed in order to limit financial risk. The Diameter
811 Credit Control Application [RFC4006] is the application that
812 defines real-time accounting functionality.
814 Relay Agent or Relay
816 Relays forward requests and responses based on routing-related
817 AVPs and routing table entries. Since relays do not make policy
818 decisions, they do not examine or alter non-routing AVPs. As a
819 result, relays never originate messages, do not need to understand
820 the semantics of messages or non-routing AVPs, and are capable of
821 handling any Diameter application or message type. Since relays
822 make decisions based on information in routing AVPs and realm
823 forwarding tables they do not keep state on NAS resource usage or
824 sessions in progress.
826 Redirect Agent
828 Rather than forwarding requests and responses between clients and
829 servers, redirect agents refer clients to servers and allow them
830 to communicate directly. Since redirect agents do not sit in the
831 forwarding path, they do not alter any AVPs transiting between
832 client and server. Redirect agents do not originate messages and
833 are capable of handling any message type, although they may be
834 configured only to redirect messages of certain types, while
835 acting as relay or proxy agents for other types. As with proxy
836 agents, redirect agents do not keep state with respect to sessions
837 or NAS resources.
839 Roaming Relationships
841 Roaming relationships include relationships between companies and
842 ISPs, relationships among peer ISPs within a roaming consortium,
843 and relationships between an ISP and a roaming consortium.
845 Session
847 A session is a related progression of events devoted to a
848 particular activity. Diameter application documents provide
849 guidelines as to when a session begins and ends. All Diameter
850 packets with the same Session-Id are considered to be part of the
851 same session.
853 Session state
855 A stateful agent is one that maintains session state information,
856 by keeping track of all authorized active sessions. Each
857 authorized session is bound to a particular service, and its state
858 is considered active either until it is notified otherwise, or by
859 expiration.
861 Sub-session
863 A sub-session represents a distinct service (e.g., QoS or data
864 characteristics) provided to a given session. These services may
865 happen concurrently (e.g., simultaneous voice and data transfer
866 during the same session) or serially. These changes in sessions
867 are tracked with the Accounting-Sub-Session-Id.
869 Transaction state
871 The Diameter protocol requires that agents maintain transaction
872 state, which is used for failover purposes. Transaction state
873 implies that upon forwarding a request, the Hop-by-Hop identifier
874 is saved; the field is replaced with a locally unique identifier,
875 which is restored to its original value when the corresponding
876 answer is received. The request's state is released upon receipt
877 of the answer. A stateless agent is one that only maintains
878 transaction state.
880 Translation Agent
882 A translation agent is a stateful Diameter node that performs
883 protocol translation between Diameter and another AAA protocol,
884 such as RADIUS.
886 Transport Connection
888 A transport connection is a TCP or SCTP connection existing
889 directly between two Diameter peers, otherwise known as a Peer-to-
890 Peer Connection.
892 Upstream
894 Upstream is used to identify the direction of a particular
895 Diameter message from the access device towards the home server.
897 User
899 The entity or client device requesting or using some resource, in
900 support of which a Diameter client has generated a request.
902 2. Protocol Overview
904 The base Diameter protocol concerns itself with capabilities
905 negotiation, how messages are sent and how peers may eventually be
906 abandoned. The base protocol also defines certain rules that apply
907 to all exchanges of messages between Diameter nodes.
909 Communication between Diameter peers begins with one peer sending a
910 message to another Diameter peer. The set of AVPs included in the
911 message is determined by a particular Diameter application. One AVP
912 that is included to reference a user's session is the Session-Id.
914 The initial request for authentication and/or authorization of a user
915 would include the Session-Id. The Session-Id is then used in all
916 subsequent messages to identify the user's session (see Section 8 for
917 more information). The communicating party may accept the request,
918 or reject it by returning an answer message with the Result-Code AVP
919 set to indicate an error occurred. The specific behavior of the
920 Diameter server or client receiving a request depends on the Diameter
921 application employed.
923 Session state (associated with a Session-Id) MUST be freed upon
924 receipt of the Session-Termination-Request, Session-Termination-
925 Answer, expiration of authorized service time in the Session-Timeout
926 AVP, and according to rules established in a particular Diameter
927 application.
929 The base Diameter protocol may be used by itself for accounting
930 applications. For authentication and authorization, it is always
931 extended for a particular application.
933 Diameter Clients MUST support the base protocol, which includes
934 accounting. In addition, they MUST fully support each Diameter
935 application that is needed to implement the client's service, e.g.,
936 NASREQ and/or Mobile IPv4. A Diameter Client that does not support
937 both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
938 Client" where X is the application which it supports, and not a
939 "Diameter Client".
941 Diameter Servers MUST support the base protocol, which includes
942 accounting. In addition, they MUST fully support each Diameter
943 application that is needed to implement the intended service, e.g.,
944 NASREQ and/or Mobile IPv4. A Diameter Server that does not support
945 both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
946 Server" where X is the application which it supports, and not a
947 "Diameter Server".
949 Diameter Relays and redirect agents are, by definition, protocol
950 transparent, and MUST transparently support the Diameter base
951 protocol, which includes accounting, and all Diameter applications.
953 Diameter proxies MUST support the base protocol, which includes
954 accounting. In addition, they MUST fully support each Diameter
955 application that is needed to implement proxied services, e.g.,
956 NASREQ and/or Mobile IPv4. A Diameter proxy which does not support
957 both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
958 Proxy" where X is the application which it supports, and not a
959 "Diameter Proxy".
961 2.1. Transport
963 The Diameter Transport profile is defined in [RFC3539].
965 The base Diameter protocol is run on port 3868 for both TCP [RFC793]
966 and SCTP [RFC2960]. It is run on port [TBD] when TLS [RFC4346] is
967 used.
969 Diameter clients MUST support either TCP or SCTP, while agents and
970 servers SHOULD support both.
972 A Diameter node MAY initiate connections from a source port other
973 than the one that it declares it accepts incoming connections on, and
974 MUST be prepared to receive connections on port 3868 for TCP or SCTP
975 and port [TBD] for TLS connections. A given Diameter instance of the
976 peer state machine MUST NOT use more than one transport connection to
977 communicate with a given peer, unless multiple instances exist on the
978 peer in which case a separate connection per process is allowed.
980 When no transport connection exists with a peer, an attempt to
981 connect SHOULD be periodically made. This behavior is handled via
982 the Tc timer, whose recommended value is 30 seconds. There are
983 certain exceptions to this rule, such as when a peer has terminated
984 the transport connection stating that it does not wish to
985 communicate.
987 When connecting to a peer and either zero or more transports are
988 specified, TCP SHOULD be tried first, followed by SCTP. See Section
989 5.2 for more information on peer discovery.
991 Diameter implementations SHOULD be able to interpret ICMP protocol
992 port unreachable messages as explicit indications that the server is
993 not reachable, subject to security policy on trusting such messages.
994 Diameter implementations SHOULD also be able to interpret a reset
995 from the transport and timed-out connection attempts. If Diameter
996 receives data up from TCP that cannot be parsed or identified as a
997 Diameter error made by the peer, the stream is compromised and cannot
998 be recovered. The transport connection MUST be closed using a RESET
999 call (send a TCP RST bit) or an SCTP ABORT message (graceful closure
1000 is compromised).
1002 2.1.1. SCTP Guidelines
1004 The following are guidelines for Diameter implementations that
1005 support SCTP:
1007 1. For interoperability: All Diameter nodes MUST be prepared to
1008 receive Diameter messages on any SCTP stream in the association.
1010 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
1011 streams available to the association to prevent head-of-the-line
1012 blocking.
1014 2.2. Securing Diameter Messages
1016 Connections between Diameter peers SHOULD be protected by TLS. All
1017 Diameter base protocol implementations MUST support the use of TLS.
1018 If desired, alternative security mechanisms that are independent of
1019 Diameter, such as IPsec [RFC4301], can be deployed to secure
1020 connections between peers. The Diameter protocol MUST NOT be used
1021 without any security mechanism.
1023 2.3. Diameter Application Compliance
1025 Application Ids are advertised during the capabilities exchange phase
1026 (see Section 5.3). For a given application, advertising support of
1027 an application implies that the sender supports the functionality
1028 specified in the respective Diameter application specification.
1030 An implementation MAY add arbitrary optional AVPs with the M-bit
1031 cleared to a command defined in an application, including vendor-
1032 specific AVPs only if the commands ABNF allows for it. Please refer
1033 to Section 11.1.1 for details.
1035 2.4. Application Identifiers
1037 Each Diameter application MUST have an IANA assigned Application Id
1038 (see Section 11.3). The base protocol does not require an
1039 Application Id since its support is mandatory. During the
1040 capabilities exchange, Diameter nodes inform their peers of locally
1041 supported applications. Furthermore, all Diameter messages contain
1042 an Application Id, which is used in the message forwarding process.
1044 The following Application Id values are defined:
1046 Diameter Common Messages 0
1047 Diameter Base Accounting 3
1048 Relay 0xffffffff
1050 Relay and redirect agents MUST advertise the Relay Application
1051 Identifier, while all other Diameter nodes MUST advertise locally
1052 supported applications. The receiver of a Capabilities Exchange
1053 message advertising Relay service MUST assume that the sender
1054 supports all current and future applications.
1056 Diameter relay and proxy agents are responsible for finding an
1057 upstream server that supports the application of a particular
1058 message. If none can be found, an error message is returned with the
1059 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1061 2.5. Connections vs. Sessions
1063 This section attempts to provide the reader with an understanding of
1064 the difference between connection and session, which are terms used
1065 extensively throughout this document.
1067 A connection refers to a transport level connection between two peers
1068 that is used to send and receive Diameter messages. A session is a
1069 logical concept at the application layer, it spawns from the Diameter
1070 client to the Diameter server and is identified via the Session-Id
1071 AVP.
1073 +--------+ +-------+ +--------+
1074 | Client | | Relay | | Server |
1075 +--------+ +-------+ +--------+
1076 <----------> <---------->
1077 peer connection A peer connection B
1079 <----------------------------->
1080 User session x
1082 Figure 1: Diameter connections and sessions
1084 In the example provided in Figure 1, peer connection A is established
1085 between the Client and the Relay. Peer connection B is established
1086 between the Relay and the Server. User session X spans from the
1087 Client via the Relay to the Server. Each "user" of a service causes
1088 an auth request to be sent, with a unique session identifier. Once
1089 accepted by the server, both the client and the server are aware of
1090 the session.
1092 It is important to note that there is no relationship between a
1093 connection and a session, and that Diameter messages for multiple
1094 sessions are all multiplexed through a single connection. Also note
1095 that Diameter messages pertaining to the session, both application
1096 specific and those that are defined in this document such as ASR/ASA,
1097 RAR/RAA and STR/STA MUST carry the Application Id of the application.
1098 Diameter messages pertaining to peer connection establishment and
1099 maintenance such as CER/CEA, DWR/DWA and DPR/DPA MUST carry an
1100 Application Id of zero (0).
1102 2.6. Peer Table
1104 The Diameter Peer Table is used in message forwarding, and referenced
1105 by the Routing Table. A Peer Table entry contains the following
1106 fields:
1108 Host identity
1110 Following the conventions described for the DiameterIdentity
1111 derived AVP data format in Section 4.4. This field contains the
1112 contents of the Origin-Host (Section 6.3) AVP found in the CER or
1113 CEA message.
1115 StatusT
1117 This is the state of the peer entry, and MUST match one of the
1118 values listed in Section 5.6.
1120 Static or Dynamic
1122 Specifies whether a peer entry was statically configured, or
1123 dynamically discovered.
1125 Expiration time
1127 Specifies the time at which dynamically discovered peer table
1128 entries are to be either refreshed, or expired.
1130 TLS Enabled
1132 Specifies whether TLS is to be used when communicating with the
1133 peer.
1135 Additional security information, when needed (e.g., keys,
1136 certificates)
1138 2.7. Routing Table
1140 All Realm-Based routing lookups are performed against what is
1141 commonly known as the Routing Table (see Section 12). A Routing
1142 Table Entry contains the following fields:
1144 Realm Name
1146 This is the field that is MUST be used as a primary key in the
1147 routing table lookups. Note that some implementations perform
1148 their lookups based on longest-match-from-the-right on the realm
1149 rather than requiring an exact match.
1151 Application Identifier
1153 An application is identified by an Application Id. A route entry
1154 can have a different destination based on the Application Id in
1155 the message header. This field MUST be used as a secondary key
1156 field in routing table lookups.
1158 Local Action
1160 The Local Action field is used to identify how a message should be
1161 treated. The following actions are supported:
1163 1. LOCAL - Diameter messages that can be satisfied locally, and
1164 do not need to be routed to another Diameter entity.
1166 2. RELAY - All Diameter messages that fall within this category
1167 MUST be routed to a next hop Diameter entity that is indicated
1168 by the identifier described below. Routing is done without
1169 modifying any non-routing AVPs. See Section 6.1.9 for
1170 relaying guidelines
1172 3. PROXY - All Diameter messages that fall within this category
1173 MUST be routed to a next Diameter entity that is indicated by
1174 the identifier described below. The local server MAY apply
1175 its local policies to the message by including new AVPs to the
1176 message prior to routing. See Section 6.1.9 for proxying
1177 guidelines.
1179 4. REDIRECT - Diameter messages that fall within this category
1180 MUST have the identity of the home Diameter server(s)
1181 appended, and returned to the sender of the message. See
1182 Section 6.1.9 for redirect guidelines.
1184 Server Identifier
1186 One or more servers the message is to be routed to. These servers
1187 MUST also be present in the Peer table. When the Local Action is
1188 set to RELAY or PROXY, this field contains the identity of the
1189 server(s) the message MUST be routed to. When the Local Action
1190 field is set to REDIRECT, this field contains the identity of one
1191 or more servers the message MUST be redirected to.
1193 Static or Dynamic
1195 Specifies whether a route entry was statically configured, or
1196 dynamically discovered.
1198 Expiration time
1200 Specifies the time which a dynamically discovered route table
1201 entry expires.
1203 It is important to note that Diameter agents MUST support at least
1204 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
1205 Agents do not need to support all modes of operation in order to
1206 conform with the protocol specification, but MUST follow the protocol
1207 compliance guidelines in Section 2. Relay agents and proxies MUST
1208 NOT reorder AVPs.
1210 The routing table MAY include a default entry that MUST be used for
1211 any requests not matching any of the other entries. The routing
1212 table MAY consist of only such an entry.
1214 When a request is routed, the target server MUST have advertised the
1215 Application Id (see Section 2.4) for the given message, or have
1216 advertised itself as a relay or proxy agent. Otherwise, an error is
1217 returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
1219 2.8. Role of Diameter Agents
1221 In addition to client and servers, the Diameter protocol introduces
1222 relay, proxy, redirect, and translation agents, each of which is
1223 defined in Section 1.3. These Diameter agents are useful for several
1224 reasons:
1226 o They can distribute administration of systems to a configurable
1227 grouping, including the maintenance of security associations.
1229 o They can be used for concentration of requests from an number of
1230 co-located or distributed NAS equipment sets to a set of like user
1231 groups.
1233 o They can do value-added processing to the requests or responses.
1235 o They can be used for load balancing.
1237 o A complex network will have multiple authentication sources, they
1238 can sort requests and forward towards the correct target.
1240 The Diameter protocol requires that agents maintain transaction
1241 state, which is used for failover purposes. Transaction state
1242 implies that upon forwarding a request, its Hop-by-Hop identifier is
1243 saved; the field is replaced with a locally unique identifier, which
1244 is restored to its original value when the corresponding answer is
1245 received. The request's state is released upon receipt of the
1246 answer. A stateless agent is one that only maintains transaction
1247 state.
1249 The Proxy-Info AVP allows stateless agents to add local state to a
1250 Diameter request, with the guarantee that the same state will be
1251 present in the answer. However, the protocol's failover procedures
1252 require that agents maintain a copy of pending requests.
1254 A stateful agent is one that maintains session state information; by
1255 keeping track of all authorized active sessions. Each authorized
1256 session is bound to a particular service, and its state is considered
1257 active either until it is notified otherwise, or by expiration. Each
1258 authorized session has an expiration, which is communicated by
1259 Diameter servers via the Session-Timeout AVP.
1261 Maintaining session state may be useful in certain applications, such
1262 as:
1264 o Protocol translation (e.g., RADIUS <-> Diameter)
1266 o Limiting resources authorized to a particular user
1268 o Per user or transaction auditing
1270 A Diameter agent MAY act in a stateful manner for some requests and
1271 be stateless for others. A Diameter implementation MAY act as one
1272 type of agent for some requests, and as another type of agent for
1273 others.
1275 2.8.1. Relay Agents
1277 Relay Agents are Diameter agents that accept requests and route
1278 messages to other Diameter nodes based on information found in the
1279 messages (e.g., Destination-Realm). This routing decision is
1280 performed using a list of supported realms, and known peers. This is
1281 known as the Routing Table, as is defined further in Section 2.7.
1283 Relays may, for example, be used to aggregate requests from multiple
1284 Network Access Servers (NASes) within a common geographical area
1285 (POP). The use of Relays is advantageous since it eliminates the
1286 need for NASes to be configured with the necessary security
1287 information they would otherwise require to communicate with Diameter
1288 servers in other realms. Likewise, this reduces the configuration
1289 load on Diameter servers that would otherwise be necessary when NASes
1290 are added, changed or deleted.
1292 Relays modify Diameter messages by inserting and removing routing
1293 information, but do not modify any other portion of a message.
1294 Relays SHOULD NOT maintain session state but MUST maintain
1295 transaction state.
1297 +------+ ---------> +------+ ---------> +------+
1298 | | 1. Request | | 2. Request | |
1299 | NAS | | DRL | | HMS |
1300 | | 4. Answer | | 3. Answer | |
1301 +------+ <--------- +------+ <--------- +------+
1302 example.net example.net example.com
1304 Figure 2: Relaying of Diameter messages
1306 The example provided in Figure 2 depicts a request issued from NAS,
1307 which is an access device, for the user bob@example.com. Prior to
1308 issuing the request, NAS performs a Diameter route lookup, using
1309 "example.com" as the key, and determines that the message is to be
1310 relayed to DRL, which is a Diameter Relay. DRL performs the same
1311 route lookup as NAS, and relays the message to HMS, which is
1312 example.com's Home Diameter Server. HMS identifies that the request
1313 can be locally supported (via the realm), processes the
1314 authentication and/or authorization request, and replies with an
1315 answer, which is routed back to NAS using saved transaction state.
1317 Since Relays do not perform any application level processing, they
1318 provide relaying services for all Diameter applications, and
1319 therefore MUST advertise the Relay Application Id.
1321 2.8.2. Proxy Agents
1323 Similarly to relays, proxy agents route Diameter messages using the
1324 Diameter Routing Table. However, they differ since they modify
1325 messages to implement policy enforcement. This requires that proxies
1326 maintain the state of their downstream peers (e.g., access devices)
1327 to enforce resource usage, provide admission control, and
1328 provisioning.
1330 Proxies may, for example, be used in call control centers or access
1331 ISPs that provide outsourced connections, they can monitor the number
1332 and types of ports in use, and make allocation and admission
1333 decisions according to their configuration.
1335 Since enforcing policies requires an understanding of the service
1336 being provided, Proxies MUST only advertise the Diameter applications
1337 they support.
1339 2.8.3. Redirect Agents
1341 Redirect agents are useful in scenarios where the Diameter routing
1342 configuration needs to be centralized. An example is a redirect
1343 agent that provides services to all members of a consortium, but does
1344 not wish to be burdened with relaying all messages between realms.
1345 This scenario is advantageous since it does not require that the
1346 consortium provide routing updates to its members when changes are
1347 made to a member's infrastructure.
1349 Since redirect agents do not relay messages, and only return an
1350 answer with the information necessary for Diameter agents to
1351 communicate directly, they do not modify messages. Since redirect
1352 agents do not receive answer messages, they cannot maintain session
1353 state.
1355 The example provided in Figure 3 depicts a request issued from the
1356 access device, NAS, for the user bob@example.com. The message is
1357 forwarded by the NAS to its relay, DRL, which does not have a routing
1358 entry in its Diameter Routing Table for example.com. DRL has a
1359 default route configured to DRD, which is a redirect agent that
1360 returns a redirect notification to DRL, as well as HMS' contact
1361 information. Upon receipt of the redirect notification, DRL
1362 establishes a transport connection with HMS, if one doesn't already
1363 exist, and forwards the request to it.
1365 +------+
1366 | |
1367 | DRD |
1368 | |
1369 +------+
1370 ^ |
1371 2. Request | | 3. Redirection
1372 | | Notification
1373 | v
1374 +------+ ---------> +------+ ---------> +------+
1375 | | 1. Request | | 4. Request | |
1376 | NAS | | DRL | | HMS |
1377 | | 6. Answer | | 5. Answer | |
1378 +------+ <--------- +------+ <--------- +------+
1379 example.net example.net example.com
1381 Figure 3: Redirecting a Diameter Message
1383 Since redirect agents do not perform any application level
1384 processing, they provide relaying services for all Diameter
1385 applications, and therefore MUST advertise the Relay Application
1386 Identifier.
1388 2.8.4. Translation Agents
1390 A translation agent is a device that provides translation between two
1391 protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation
1392 agents are likely to be used as aggregation servers to communicate
1393 with a Diameter infrastructure, while allowing for the embedded
1394 systems to be migrated at a slower pace.
1396 Given that the Diameter protocol introduces the concept of long-lived
1397 authorized sessions, translation agents MUST be session stateful and
1398 MUST maintain transaction state.
1400 Translation of messages can only occur if the agent recognizes the
1401 application of a particular request, and therefore translation agents
1402 MUST only advertise their locally supported applications.
1404 +------+ ---------> +------+ ---------> +------+
1405 | | RADIUS Request | | Diameter Request | |
1406 | NAS | | TLA | | HMS |
1407 | | RADIUS Answer | | Diameter Answer | |
1408 +------+ <--------- +------+ <--------- +------+
1409 example.net example.net example.com
1411 Figure 4: Translation of RADIUS to Diameter
1413 2.9. Diameter Path Authorization
1415 As noted in Section 2.2, Diameter provides transmission level
1416 security for each connection using TLS. Therefore, each connection
1417 can be authenticated, replay and integrity protected.
1419 In addition to authenticating each connection, each connection as
1420 well as the entire session MUST also be authorized. Before
1421 initiating a connection, a Diameter Peer MUST check that its peers
1422 are authorized to act in their roles. For example, a Diameter peer
1423 may be authentic, but that does not mean that it is authorized to act
1424 as a Diameter Server advertising a set of Diameter applications.
1426 Prior to bringing up a connection, authorization checks are performed
1427 at each connection along the path. Diameter capabilities negotiation
1428 (CER/CEA) also MUST be carried out, in order to determine what
1429 Diameter applications are supported by each peer. Diameter sessions
1430 MUST be routed only through authorized nodes that have advertised
1431 support for the Diameter application required by the session.
1433 As noted in Section 6.1.9, a relay or proxy agent MUST append a
1434 Route-Record AVP to all requests forwarded. The AVP contains the
1435 identity of the peer the request was received from.
1437 The home Diameter server, prior to authorizing a session, MUST check
1438 the Route-Record AVPs to make sure that the route traversed by the
1439 request is acceptable. For example, administrators within the home
1440 realm may not wish to honor requests that have been routed through an
1441 untrusted realm. By authorizing a request, the home Diameter server
1442 is implicitly indicating its willingness to engage in the business
1443 transaction as specified by the contractual relationship between the
1444 server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
1445 message (see Section 7.1.5) is sent if the route traversed by the
1446 request is unacceptable.
1448 A home realm may also wish to check that each accounting request
1449 message corresponds to a Diameter response authorizing the session.
1450 Accounting requests without corresponding authorization responses
1451 SHOULD be subjected to further scrutiny, as should accounting
1452 requests indicating a difference between the requested and provided
1453 service.
1455 Forwarding of an authorization response is considered evidence of a
1456 willingness to take on financial risk relative to the session. A
1457 local realm may wish to limit this exposure, for example, by
1458 establishing credit limits for intermediate realms and refusing to
1459 accept responses which would violate those limits. By issuing an
1460 accounting request corresponding to the authorization response, the
1461 local realm implicitly indicates its agreement to provide the service
1462 indicated in the authorization response. If the service cannot be
1463 provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
1464 message MUST be sent within the accounting request; a Diameter client
1465 receiving an authorization response for a service that it cannot
1466 perform MUST NOT substitute an alternate service, and then send
1467 accounting requests for the alternate service instead.
1469 3. Diameter Header
1471 A summary of the Diameter header format is shown below. The fields
1472 are transmitted in network byte order.
1474 0 1 2 3
1475 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
1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1477 | Version | Message Length |
1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1479 | command flags | Command-Code |
1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1481 | Application-ID |
1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1483 | Hop-by-Hop Identifier |
1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1485 | End-to-End Identifier |
1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1487 | AVPs ...
1488 +-+-+-+-+-+-+-+-+-+-+-+-+-
1490 Version
1492 This Version field MUST be set to 1 to indicate Diameter Version
1493 1.
1495 Message Length
1497 The Message Length field is three octets and indicates the length
1498 of the Diameter message including the header fields.
1500 Command Flags
1502 The Command Flags field is eight bits. The following bits are
1503 assigned:
1505 0 1 2 3 4 5 6 7
1506 +-+-+-+-+-+-+-+-+
1507 |R P E T r r r r|
1508 +-+-+-+-+-+-+-+-+
1510 R(equest)
1512 If set, the message is a request. If cleared, the message is
1513 an answer.
1515 P(roxiable)
1517 If set, the message MAY be proxied, relayed or redirected. If
1518 cleared, the message MUST be locally processed.
1520 E(rror)
1522 If set, the message contains a protocol error, and the message
1523 will not conform to the ABNF described for this command.
1524 Messages with the 'E' bit set are commonly referred to as error
1525 messages. This bit MUST NOT be set in request messages. See
1526 Section 7.2.
1528 T(Potentially re-transmitted message)
1530 This flag is set after a link failover procedure, to aid the
1531 removal of duplicate requests. It is set when resending
1532 requests not yet acknowledged, as an indication of a possible
1533 duplicate due to a link failure. This bit MUST be cleared when
1534 sending a request for the first time, otherwise the sender MUST
1535 set this flag. Diameter agents only need to be concerned about
1536 the number of requests they send based on a single received
1537 request; retransmissions by other entities need not be tracked.
1538 Diameter agents that receive a request with the T flag set,
1539 MUST keep the T flag set in the forwarded request. This flag
1540 MUST NOT be set if an error answer message (e.g., a protocol
1541 error) has been received for the earlier message. It can be
1542 set only in cases where no answer has been received from the
1543 server for a request and the request is sent again. This flag
1544 MUST NOT be set in answer messages.
1546 r(eserved)
1548 These flag bits are reserved for future use, and MUST be set to
1549 zero, and ignored by the receiver.
1551 Command-Code
1553 The Command-Code field is three octets, and is used in order to
1554 communicate the command associated with the message. The 24-bit
1555 address space is managed by IANA (see Section 11.2.1).
1557 Command-Code values 16,777,214 and 16,777,215 (hexadecimal values
1558 FFFFFE -FFFFFF) are reserved for experimental use (See Section
1559 11.3).
1561 Application-ID
1563 Application-ID is four octets and is used to identify to which
1564 application the message is applicable for. The application can be
1565 an authentication application, an accounting application or a
1566 vendor specific application. See Section 11.3 for the possible
1567 values that the application-id may use.
1569 The value of the application-id field in the header MUST be the
1570 same as any relevant application-id AVPs contained in the message.
1572 Hop-by-Hop Identifier
1574 The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
1575 network byte order) and aids in matching requests and replies.
1576 The sender MUST ensure that the Hop-by-Hop identifier in a request
1577 is unique on a given connection at any given time, and MAY attempt
1578 to ensure that the number is unique across reboots. The sender of
1579 an Answer message MUST ensure that the Hop-by-Hop Identifier field
1580 contains the same value that was found in the corresponding
1581 request. The Hop-by-Hop identifier is normally a monotonically
1582 increasing number, whose start value was randomly generated. An
1583 answer message that is received with an unknown Hop-by-Hop
1584 Identifier MUST be discarded.
1586 End-to-End Identifier
1588 The End-to-End Identifier is an unsigned 32-bit integer field (in
1589 network byte order) and is used to detect duplicate messages.
1590 Upon reboot implementations MAY set the high order 12 bits to
1591 contain the low order 12 bits of current time, and the low order
1592 20 bits to a random value. Senders of request messages MUST
1593 insert a unique identifier on each message. The identifier MUST
1594 remain locally unique for a period of at least 4 minutes, even
1595 across reboots. The originator of an Answer message MUST ensure
1596 that the End-to-End Identifier field contains the same value that
1597 was found in the corresponding request. The End-to-End Identifier
1598 MUST NOT be modified by Diameter agents of any kind. The
1599 combination of the Origin-Host (see Section 6.3) and this field is
1600 used to detect duplicates. Duplicate requests SHOULD cause the
1601 same answer to be transmitted (modulo the hop-by-hop Identifier
1602 field and any routing AVPs that may be present), and MUST NOT
1603 affect any state that was set when the original request was
1604 processed. Duplicate answer messages that are to be locally
1605 consumed (see Section 6.2) SHOULD be silently discarded.
1607 AVPs
1609 AVPs are a method of encapsulating information relevant to the
1610 Diameter message. See Section 4 for more information on AVPs.
1612 3.1. Command Codes
1614 Each command Request/Answer pair is assigned a command code, and the
1615 sub-type (i.e., request or answer) is identified via the 'R' bit in
1616 the Command Flags field of the Diameter header.
1618 Every Diameter message MUST contain a command code in its header's
1619 Command-Code field, which is used to determine the action that is to
1620 be taken for a particular message. The following Command Codes are
1621 defined in the Diameter base protocol:
1623 Command-Name Abbrev. Code Reference
1624 --------------------------------------------------------
1625 Abort-Session-Request ASR 274 8.5.1
1626 Abort-Session-Answer ASA 274 8.5.2
1627 Accounting-Request ACR 271 9.7.1
1628 Accounting-Answer ACA 271 9.7.2
1629 Capabilities-Exchange- CER 257 5.3.1
1630 Request
1631 Capabilities-Exchange- CEA 257 5.3.2
1632 Answer
1633 Device-Watchdog-Request DWR 280 5.5.1
1634 Device-Watchdog-Answer DWA 280 5.5.2
1635 Disconnect-Peer-Request DPR 282 5.4.1
1636 Disconnect-Peer-Answer DPA 282 5.4.2
1637 Re-Auth-Request RAR 258 8.3.1
1638 Re-Auth-Answer RAA 258 8.3.2
1639 Session-Termination- STR 275 8.4.1
1640 Request
1641 Session-Termination- STA 275 8.4.2
1642 Answer
1644 3.2. Command Code ABNF specification
1646 Every Command Code defined MUST include a corresponding ABNF
1647 specification, which is used to define the AVPs that MUST or MAY be
1648 present when sending the message. The following format is used in
1649 the definition:
1651 command-def = command-name "::=" diameter-message
1653 command-name = diameter-name
1654 diameter-name = ALPHA *(ALPHA / DIGIT / "-")
1656 diameter-message = header [ *fixed] [ *required] [ *optional]
1658 header = "<" "Diameter Header:" command-id
1659 [r-bit] [p-bit] [e-bit] [application-id] ">"
1661 application-id = 1*DIGIT
1663 command-id = 1*DIGIT
1664 ; The Command Code assigned to the command
1666 r-bit = ", REQ"
1667 ; If present, the 'R' bit in the Command
1668 ; Flags is set, indicating that the message
1669 ; is a request, as opposed to an answer.
1671 p-bit = ", PXY"
1672 ; If present, the 'P' bit in the Command
1673 ; Flags is set, indicating that the message
1674 ; is proxiable.
1676 e-bit = ", ERR"
1677 ; If present, the 'E' bit in the Command
1678 ; Flags is set, indicating that the answer
1679 ; message contains a Result-Code AVP in
1680 ; the "protocol error" class.
1682 fixed = [qual] "<" avp-spec ">"
1683 ; Defines the fixed position of an AVP
1685 required = [qual] "{" avp-spec "}"
1686 ; The AVP MUST be present and can appear
1687 ; anywhere in the message.
1689 optional = [qual] "[" avp-name "]"
1690 ; The avp-name in the 'optional' rule cannot
1691 ; evaluate to any AVP Name which is included
1692 ; in a fixed or required rule. The AVP can
1693 ; appear anywhere in the message.
1695 qual = [min] "*" [max]
1696 ; See ABNF conventions, RFC 4234 Section 6.6.
1697 ; The absence of any qualifiers depends on
1698 ; whether it precedes a fixed, required, or
1699 ; optional rule. If a fixed or required rule has
1700 ; no qualifier, then exactly one such AVP MUST
1701 ; be present. If an optional rule has no
1702 ; qualifier, then 0 or 1 such AVP may be
1703 ; present. If an optional rule has a qualifier,
1704 ; then the value of min MUST be 0 if present.
1705 ;
1706 ; NOTE: "[" and "]" have a different meaning
1707 ; than in ABNF (see the optional rule, above).
1708 ; These braces cannot be used to express
1709 ; optional fixed rules (such as an optional
1710 ; ICV at the end). To do this, the convention
1711 ; is '0*1fixed'.
1713 min = 1*DIGIT
1714 ; The minimum number of times the element may
1715 ; be present. The default value is zero for
1716 ; fixed and optional rules. The default value
1717 ; is one for required rules. The value of zero
1718 ; is not allowed for required rules.
1720 max = 1*DIGIT
1721 ; The maximum number of times the element may
1722 ; be present. The default value is infinity. A
1723 ; value of zero implies the AVP MUST NOT be
1724 ; present.
1726 avp-spec = diameter-name
1727 ; The avp-spec has to be an AVP Name, defined
1728 ; in the base or extended Diameter
1729 ; specifications.
1731 avp-name = avp-spec / "AVP"
1732 ; The string "AVP" stands for *any* arbitrary AVP
1733 ; Name, not otherwise listed in that command code
1734 ; definition. Addition this AVP is recommended for
1735 ; all command ABNFs to allow for extensibility.
1737 The following is a definition of a fictitious command code:
1739 Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
1740 { User-Name }
1741 * { Origin-Host }
1742 * [ AVP ]
1744 3.3. Diameter Command Naming Conventions
1746 Diameter command names typically includes one or more English words
1747 followed by the verb Request or Answer. Each English word is
1748 delimited by a hyphen. A three-letter acronym for both the request
1749 and answer is also normally provided.
1751 An example is a message set used to terminate a session. The command
1752 name is Session-Terminate-Request and Session-Terminate-Answer, while
1753 the acronyms are STR and STA, respectively.
1755 Both the request and the answer for a given command share the same
1756 command code. The request is identified by the R(equest) bit in the
1757 Diameter header set to one (1), to ask that a particular action be
1758 performed, such as authorizing a user or terminating a session. Once
1759 the receiver has completed the request it issues the corresponding
1760 answer, which includes a result code that communicates one of the
1761 following:
1763 o The request was successful
1765 o The request failed
1767 o An additional request has to be sent to provide information the
1768 peer requires prior to returning a successful or failed answer.
1770 o The receiver could not process the request, but provides
1771 information about a Diameter peer that is able to satisfy the
1772 request, known as redirect.
1774 Additional information, encoded within AVPs, may also be included in
1775 answer messages.
1777 4. Diameter AVPs
1779 Diameter AVPs carry specific authentication, accounting,
1780 authorization and routing information as well as configuration
1781 details for the request and reply.
1783 Each AVP of type OctetString MUST be padded to align on a 32-bit
1784 boundary, while other AVP types align naturally. A number of zero-
1785 valued bytes are added to the end of the AVP Data field till a word
1786 boundary is reached. The length of the padding is not reflected in
1787 the AVP Length field.
1789 4.1. AVP Header
1791 The fields in the AVP header MUST be sent in network byte order. The
1792 format of the header is:
1794 0 1 2 3
1795 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
1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1797 | AVP Code |
1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1799 |V M P r r r r r| AVP Length |
1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1801 | Vendor-ID (opt) |
1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1803 | Data ...
1804 +-+-+-+-+-+-+-+-+
1806 AVP Code
1808 The AVP Code, combined with the Vendor-Id field, identifies the
1809 attribute uniquely. AVP numbers 1 through 255 are reserved for
1810 backward compatibility with RADIUS, without setting the Vendor-Id
1811 field. AVP numbers 256 and above are used for Diameter, which are
1812 allocated by IANA (see Section 11.1).
1814 AVP Flags
1816 The AVP Flags field informs the receiver how each attribute must
1817 be handled. The 'r' (reserved) bits are unused and SHOULD be set
1818 to 0. Note that subsequent Diameter applications MAY define
1819 additional bits within the AVP Header, and an unrecognized bit
1820 SHOULD be considered an error. The 'P' bit has been reserved for
1821 future usage of end-to-end security. At the time of writing there
1822 are no end-to-end security mechanisms specified therefore the 'P'
1823 bit SHOULD be set to 0.
1825 The 'M' Bit, known as the Mandatory bit, indicates whether the
1826 receiver of the AVP MUST parse and understand the semantic of the
1827 AVP including its content. The receiving entity MUST return an
1828 appropriate error message if it receives an AVP that has the M-bit
1829 set but does not understand it. An exception applies when the AVP
1830 is embedded within a Grouped AVP. See Section 4.4 for details.
1831 Diameter Relay and redirect agents MUST NOT reject messages with
1832 unrecognized AVPs.
1834 The 'M' bit MUST be set according to the rules defined in the
1835 application specification which introduces or re-uses this AVP.
1836 Within a given application, the M-bit setting for an AVP is either
1837 defined for all command types or for each command type.
1839 AVPs with the 'M' bit cleared are informational only and a
1840 receiver that receives a message with such an AVP that is not
1841 supported, or whose value is not supported, MAY simply ignore the
1842 AVP.
1844 The 'V' bit, known as the Vendor-Specific bit, indicates whether
1845 the optional Vendor-ID field is present in the AVP header. When
1846 set the AVP Code belongs to the specific vendor code address
1847 space.
1849 AVP Length
1851 The AVP Length field is three octets, and indicates the number of
1852 octets in this AVP including the AVP Code, AVP Length, AVP Flags,
1853 Vendor-ID field (if present) and the AVP data. If a message is
1854 received with an invalid attribute length, the message MUST be
1855 rejected.
1857 4.1.1. Optional Header Elements
1859 The AVP Header contains one optional field. This field is only
1860 present if the respective bit-flag is enabled.
1862 Vendor-ID
1864 The Vendor-ID field is present if the 'V' bit is set in the AVP
1865 Flags field. The optional four-octet Vendor-ID field contains the
1866 IANA assigned "SMI Network Management Private Enterprise Codes"
1867 [RFC3232] value, encoded in network byte order. Any vendor or
1868 standardization organization that are also treated like vendors in
1869 the IANA managed"SMI Network Management Private Enterprise Codes"
1870 space wishing to implement a vendor-specific Diameter AVP MUST use
1871 their own Vendor-ID along with their privately managed AVP address
1872 space, guaranteeing that they will not collide with any other
1873 vendor's vendor-specific AVP(s), nor with future IETF AVPs.
1875 A vendor ID value of zero (0) corresponds to the IETF adopted AVP
1876 values, as managed by the IANA. Since the absence of the vendor
1877 ID field implies that the AVP in question is not vendor specific,
1878 implementations MUST NOT use the zero (0) vendor ID.
1880 4.2. Basic AVP Data Formats
1882 The Data field is zero or more octets and contains information
1883 specific to the Attribute. The format and length of the Data field
1884 is determined by the AVP Code and AVP Length fields. The format of
1885 the Data field MUST be one of the following base data types or a data
1886 type derived from the base data types. In the event that a new Basic
1887 AVP Data Format is needed, a new version of this RFC MUST be created.
1889 OctetString
1891 The data contains arbitrary data of variable length. Unless
1892 otherwise noted, the AVP Length field MUST be set to at least 8
1893 (12 if the 'V' bit is enabled). AVP Values of this type that are
1894 not a multiple of four-octets in length is followed by the
1895 necessary padding so that the next AVP (if any) will start on a
1896 32-bit boundary.
1898 Integer32
1900 32 bit signed value, in network byte order. The AVP Length field
1901 MUST be set to 12 (16 if the 'V' bit is enabled).
1903 Integer64
1905 64 bit signed value, in network byte order. The AVP Length field
1906 MUST be set to 16 (20 if the 'V' bit is enabled).
1908 Unsigned32
1910 32 bit unsigned value, in network byte order. The AVP Length
1911 field MUST be set to 12 (16 if the 'V' bit is enabled).
1913 Unsigned64
1915 64 bit unsigned value, in network byte order. The AVP Length
1916 field MUST be set to 16 (20 if the 'V' bit is enabled).
1918 Float32
1920 This represents floating point values of single precision as
1921 described by [FLOATPOINT]. The 32-bit value is transmitted in
1922 network byte order. The AVP Length field MUST be set to 12 (16 if
1923 the 'V' bit is enabled).
1925 Float64
1927 This represents floating point values of double precision as
1928 described by [FLOATPOINT]. The 64-bit value is transmitted in
1929 network byte order. The AVP Length field MUST be set to 16 (20 if
1930 the 'V' bit is enabled).
1932 Grouped
1934 The Data field is specified as a sequence of AVPs. Each of these
1935 AVPs follows - in the order in which they are specified -
1936 including their headers and padding. The AVP Length field is set
1937 to 8 (12 if the 'V' bit is enabled) plus the total length of all
1938 included AVPs, including their headers and padding. Thus the AVP
1939 length field of an AVP of type Grouped is always a multiple of 4.
1941 4.3. Derived AVP Data Formats
1943 In addition to using the Basic AVP Data Formats, applications may
1944 define data formats derived from the Basic AVP Data Formats. An
1945 application that defines new AVP Derived Data Formats MUST include
1946 them in a section entitled "AVP Derived Data Formats", using the same
1947 format as the definitions below. Each new definition MUST be either
1948 defined or listed with a reference to the RFC that defines the
1949 format.
1951 The below AVP Derived Data Formats are commonly used by applications.
1953 Address
1955 The Address format is derived from the OctetString AVP Base
1956 Format. It is a discriminated union, representing, for example a
1957 32-bit (IPv4) [RFC791] or 128-bit (IPv6) [RFC4291] address, most
1958 significant octet first. The first two octets of the Address AVP
1959 represents the AddressType, which contains an Address Family
1960 defined in [IANAADFAM]. The AddressType is used to discriminate
1961 the content and format of the remaining octets.
1963 Time
1965 The Time format is derived from the OctetString AVP Base Format.
1966 The string MUST contain four octets, in the same format as the
1967 first four bytes are in the NTP timestamp format. The NTP
1968 Timestamp format is defined in Chapter 3 of [RFC4330].
1970 This represents the number of seconds since 0h on 1 January 1900
1971 with respect to the Coordinated Universal Time (UTC).
1973 On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
1974 SNTP [RFC4330] describes a procedure to extend the time to 2104.
1975 This procedure MUST be supported by all Diameter nodes.
1977 UTF8String
1979 The UTF8String format is derived from the OctetString AVP Base
1980 Format. This is a human readable string represented using the
1981 ISO/IEC IS 10646-1 character set, encoded as an OctetString using
1982 the UTF-8 [RFC3629] transformation format described in RFC 3629.
1984 Since additional code points are added by amendments to the 10646
1985 standard from time to time, implementations MUST be prepared to
1986 encounter any code point from 0x00000001 to 0x7fffffff. Byte
1987 sequences that do not correspond to the valid encoding of a code
1988 point into UTF-8 charset or are outside this range are prohibited.
1990 The use of control codes SHOULD be avoided. When it is necessary
1991 to represent a new line, the control code sequence CR LF SHOULD be
1992 used.
1994 The use of leading or trailing white space SHOULD be avoided.
1996 For code points not directly supported by user interface hardware
1997 or software, an alternative means of entry and display, such as
1998 hexadecimal, MAY be provided.
2000 For information encoded in 7-bit US-ASCII, the UTF-8 charset is
2001 identical to the US-ASCII charset.
2003 UTF-8 may require multiple bytes to represent a single character /
2004 code point; thus the length of an UTF8String in octets may be
2005 different from the number of characters encoded.
2007 Note that the AVP Length field of an UTF8String is measured in
2008 octets, not characters.
2010 DiameterIdentity
2012 The DiameterIdentity format is derived from the OctetString AVP
2013 Base Format.
2015 DiameterIdentity = FQDN
2017 DiameterIdentity value is used to uniquely identify a Diameter
2018 node for purposes of duplicate connection and routing loop
2019 detection.
2021 The contents of the string MUST be the FQDN of the Diameter node.
2022 If multiple Diameter nodes run on the same host, each Diameter
2023 node MUST be assigned a unique DiameterIdentity. If a Diameter
2024 node can be identified by several FQDNs, a single FQDN should be
2025 picked at startup, and used as the only DiameterIdentity for that
2026 node, whatever the connection it is sent on. Note that in this
2027 document, DiameterIdentity is in ASCII form in order to be
2028 compatible with existing DNS infrastructure. See Appendix D for
2029 interactions between the Diameter protocol and Internationalized
2030 Domain Name (IDNs).
2032 DiameterURI
2034 The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
2035 syntax [RFC3986] rules specified below:
2037 "aaa://" FQDN [ port ] [ transport ] [ protocol ]
2039 ; No transport security
2041 "aaas://" FQDN [ port ] [ transport ] [ protocol ]
2043 ; Transport security used
2045 FQDN = Fully Qualified Host Name
2047 port = ":" 1*DIGIT
2049 ; One of the ports used to listen for
2050 ; incoming connections.
2051 ; If absent, the default Diameter port
2052 ; (3868) is assumed if no transport
2053 ; security is used and port (TBD) when
2054 ; transport security is used.
2056 transport = ";transport=" transport-protocol
2058 ; One of the transports used to listen
2059 ; for incoming connections. If absent,
2060 ; the default protocol is assumed to be TCP.
2061 ; UDP MUST NOT be used when the aaa-protocol
2062 ; field is set to diameter.
2064 transport-protocol = ( "tcp" / "sctp" / "udp" )
2066 protocol = ";protocol=" aaa-protocol
2068 ; If absent, the default AAA protocol
2069 ; is Diameter.
2071 aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
2073 The following are examples of valid Diameter host identities:
2075 aaa://host.example.com;transport=tcp
2076 aaa://host.example.com:6666;transport=tcp
2077 aaa://host.example.com;protocol=diameter
2078 aaa://host.example.com:6666;protocol=diameter
2079 aaa://host.example.com:6666;transport=tcp;protocol=diameter
2080 aaa://host.example.com:1813;transport=udp;protocol=radius
2082 Enumerated
2084 Enumerated is derived from the Integer32 AVP Base Format. The
2085 definition contains a list of valid values and their
2086 interpretation and is described in the Diameter application
2087 introducing the AVP.
2089 IPFilterRule
2091 The IPFilterRule format is derived from the OctetString AVP Base
2092 Format and uses the ASCII charset. The rule syntax is a modified
2093 subset of ipfw(8) from FreeBSD. Packets may be filtered based on
2094 the following information that is associated with it:
2096 Direction (in or out)
2097 Source and destination IP address (possibly masked)
2098 Protocol
2099 Source and destination port (lists or ranges)
2100 TCP flags
2101 IP fragment flag
2102 IP options
2103 ICMP types
2105 Rules for the appropriate direction are evaluated in order, with
2106 the first matched rule terminating the evaluation. Each packet is
2107 evaluated once. If no rule matches, the packet is dropped if the
2108 last rule evaluated was a permit, and passed if the last rule was
2109 a deny.
2111 IPFilterRule filters MUST follow the format:
2113 action dir proto from src to dst [options]
2115 action permit - Allow packets that match the rule.
2116 deny - Drop packets that match the rule.
2118 dir "in" is from the terminal, "out" is to the
2119 terminal.
2121 proto An IP protocol specified by number. The "ip"
2122 keyword means any protocol will match.
2124 src and dst
[ports]
2126 The may be specified as:
2127 ipno An IPv4 or IPv6 number in dotted-
2128 quad or canonical IPv6 form. Only
2129 this exact IP number will match the
2130 rule.
2131 ipno/bits An IP number as above with a mask
2132 width of the form 1.2.3.4/24. In
2133 this case, all IP numbers from
2134 1.2.3.0 to 1.2.3.255 will match.
2135 The bit width MUST be valid for the
2136 IP version and the IP number MUST
2137 NOT have bits set beyond the mask.
2138 For a match to occur, the same IP
2139 version must be present in the
2140 packet that was used in describing
2141 the IP address. To test for a
2142 particular IP version, the bits part
2143 can be set to zero. The keyword
2144 "any" is 0.0.0.0/0 or the IPv6
2145 equivalent. The keyword "assigned"
2146 is the address or set of addresses
2147 assigned to the terminal. For IPv4,
2148 a typical first rule is often "deny
2149 in ip! assigned"
2151 The sense of the match can be inverted by
2152 preceding an address with the not modifier (!),
2153 causing all other addresses to be matched
2154 instead. This does not affect the selection of
2155 port numbers.
2157 With the TCP, UDP and SCTP protocols, optional
2158 ports may be specified as:
2160 {port/port-port}[,ports[,...]]
2162 The '-' notation specifies a range of ports
2163 (including boundaries).
2165 Fragmented packets that have a non-zero offset
2166 (i.e., not the first fragment) will never match
2167 a rule that has one or more port
2168 specifications. See the frag option for
2169 details on matching fragmented packets.
2171 options:
2172 frag Match if the packet is a fragment and this is not
2173 the first fragment of the datagram. frag may not
2174 be used in conjunction with either tcpflags or
2175 TCP/UDP port specifications.
2177 ipoptions spec
2178 Match if the IP header contains the comma
2179 separated list of options specified in spec. The
2180 supported IP options are:
2182 ssrr (strict source route), lsrr (loose source
2183 route), rr (record packet route) and ts
2184 (timestamp). The absence of a particular option
2185 may be denoted with a '!'.
2187 tcpoptions spec
2188 Match if the TCP header contains the comma
2189 separated list of options specified in spec. The
2190 supported TCP options are:
2192 mss (maximum segment size), window (tcp window
2193 advertisement), sack (selective ack), ts (rfc1323
2194 timestamp) and cc (rfc1644 t/tcp connection
2195 count). The absence of a particular option may
2196 be denoted with a '!'.
2198 established
2199 TCP packets only. Match packets that have the RST
2200 or ACK bits set.
2202 setup TCP packets only. Match packets that have the SYN
2203 bit set but no ACK bit.
2205 tcpflags spec
2206 TCP packets only. Match if the TCP header
2207 contains the comma separated list of flags
2208 specified in spec. The supported TCP flags are:
2210 fin, syn, rst, psh, ack and urg. The absence of a
2211 particular flag may be denoted with a '!'. A rule
2212 that contains a tcpflags specification can never
2213 match a fragmented packet that has a non-zero
2214 offset. See the frag option for details on
2215 matching fragmented packets.
2217 icmptypes types
2218 ICMP packets only. Match if the ICMP type is in
2219 the list types. The list may be specified as any
2220 combination of ranges or individual types
2221 separated by commas. Both the numeric values and
2222 the symbolic values listed below can be used. The
2223 supported ICMP types are:
2225 echo reply (0), destination unreachable (3),
2226 source quench (4), redirect (5), echo request
2227 (8), router advertisement (9), router
2228 solicitation (10), time-to-live exceeded (11), IP
2229 header bad (12), timestamp request (13),
2230 timestamp reply (14), information request (15),
2231 information reply (16), address mask request (17)
2232 and address mask reply (18).
2234 There is one kind of packet that the access device MUST always
2235 discard, that is an IP fragment with a fragment offset of one.
2236 This is a valid packet, but it only has one use, to try to
2237 circumvent firewalls.
2239 An access device that is unable to interpret or apply a deny rule
2240 MUST terminate the session. An access device that is unable to
2241 interpret or apply a permit rule MAY apply a more restrictive
2242 rule. An access device MAY apply deny rules of its own before the
2243 supplied rules, for example to protect the access device owner's
2244 infrastructure.
2246 4.4. Grouped AVP Values
2248 The Diameter protocol allows AVP values of type 'Grouped'. This
2249 implies that the Data field is actually a sequence of AVPs. It is
2250 possible to include an AVP with a Grouped type within a Grouped type,
2251 that is, to nest them. AVPs within an AVP of type Grouped have the
2252 same padding requirements as non-Grouped AVPs, as defined in Section
2253 4.
2255 The AVP Code numbering space of all AVPs included in a Grouped AVP is
2256 the same as for non-grouped AVPs. Receivers of a Grouped AVP that
2257 does not have the 'M' (mandatory) bit set and one or more of the
2258 encapsulated AVPs within the group has the 'M' (mandatory) bit set
2259 MAY simply be ignored if the Grouped AVP itself is unrecognized. The
2260 rule applies even if the encapsulated AVP with its 'M' (mandatory)
2261 bit set is further encapsulated within other sub-groups; i.e. other
2262 Grouped AVPs embedded within the Grouped AVP.
2264 Every Grouped AVP defined MUST include a corresponding grammar, using
2265 ABNF [RFC4234] (with modifications), as defined below.
2267 grouped-avp-def = name "::=" avp
2269 name-fmt = ALPHA *(ALPHA / DIGIT / "-")
2271 name = name-fmt
2272 ; The name has to be the name of an AVP,
2273 ; defined in the base or extended Diameter
2274 ; specifications.
2276 avp = header [ *fixed] [ *required] [ *optional]
2278 header = "<" "AVP-Header:" avpcode [vendor] ">"
2280 avpcode = 1*DIGIT
2281 ; The AVP Code assigned to the Grouped AVP
2283 vendor = 1*DIGIT
2284 ; The Vendor-ID assigned to the Grouped AVP.
2285 ; If absent, the default value of zero is
2286 ; used.
2288 4.4.1. Example AVP with a Grouped Data type
2290 The Example-AVP (AVP Code 999999) is of type Grouped and is used to
2291 clarify how Grouped AVP values work. The Grouped Data field has the
2292 following ABNF grammar:
2294 Example-AVP ::= < AVP Header: 999999 >
2295 { Origin-Host }
2296 1*{ Session-Id }
2297 *[ AVP ]
2299 An Example-AVP with Grouped Data follows.
2301 The Origin-Host AVP is required (Section 6.3). In this case:
2303 Origin-Host = "example.com".
2305 One or more Session-Ids must follow. Here there are two:
2307 Session-Id =
2308 "grump.example.com:33041;23432;893;0AF3B81"
2310 Session-Id =
2311 "grump.example.com:33054;23561;2358;0AF3B82"
2313 optional AVPs included are
2315 Recovery-Policy =
2316 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2317 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
2318 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
2319 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
2320 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
2321 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
2322 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
2324 Futuristic-Acct-Record =
2325 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
2326 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
2327 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
2328 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
2329 d3427475e49968f841
2331 The data for the optional AVPs is represented in hex since the format
2332 of these AVPs is neither known at the time of definition of the
2333 Example-AVP group, nor (likely) at the time when the example instance
2334 of this AVP is interpreted - except by Diameter implementations which
2335 support the same set of AVPs. The encoding example illustrates how
2336 padding is used and how length fields are calculated. Also note that
2337 AVPs may be present in the Grouped AVP value which the receiver
2338 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record
2339 AVPs). The length of the Example-AVP is the sum of all the length of
2340 the member AVPs including their padding plus the Example-AVP header
2341 size.
2343 This AVP would be encoded as follows:
2345 0 1 2 3 4 5 6 7
2346 +-------+-------+-------+-------+-------+-------+-------+-------+
2347 0 | Example AVP Header (AVP Code = 999999), Length = 496 |
2348 +-------+-------+-------+-------+-------+-------+-------+-------+
2349 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
2350 +-------+-------+-------+-------+-------+-------+-------+-------+
2351 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
2352 +-------+-------+-------+-------+-------+-------+-------+-------+
2353 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
2354 +-------+-------+-------+-------+-------+-------+-------+-------+
2355 32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
2356 +-------+-------+-------+-------+-------+-------+-------+-------+
2357 . . .
2358 +-------+-------+-------+-------+-------+-------+-------+-------+
2359 72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
2360 +-------+-------+-------+-------+-------+-------+-------+-------+
2361 80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
2362 +-------+-------+-------+-------+-------+-------+-------+-------+
2363 88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
2364 +-------+-------+-------+-------+-------+-------+-------+-------+
2365 . . .
2366 +-------+-------+-------+-------+-------+-------+-------+-------+
2367 120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
2368 +-------+-------+-------+-------+-------+-------+-------+-------+
2369 128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
2370 +-------+-------+-------+-------+-------+-------+-------+-------+
2371 136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
2372 +-------+-------+-------+-------+-------+-------+-------+-------+
2373 144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
2374 +-------+-------+-------+-------+-------+-------+-------+-------+
2375 . . .
2376 +-------+-------+-------+-------+-------+-------+-------+-------+
2377 352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
2378 +-------+-------+-------+-------+-------+-------+-------+-------+
2379 328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
2380 +-------+-------+-------+-------+-------+-------+-------+-------+
2381 336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
2382 +-------+-------+-------+-------+-------+-------+-------+-------+
2383 . . .
2384 +-------+-------+-------+-------+-------+-------+-------+-------+
2385 488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
2386 +-------+-------+-------+-------+-------+-------+-------+-------+
2388 4.5. Diameter Base Protocol AVPs
2390 The following table describes the Diameter AVPs defined in the base
2391 protocol, their AVP Code values, types, possible flag values.
2393 Due to space constraints, the short form DiamIdent is used to
2394 represent DiameterIdentity.
2396 +----------+
2397 | AVP Flag |
2398 | rules |
2399 |----+-----|
2400 AVP Section | |MUST |
2401 Attribute Name Code Defined Data Type |MUST| NOT |
2402 -----------------------------------------|----+-----|
2403 Acct- 85 9.8.2 Unsigned32 | M | V |
2404 Interim-Interval | | |
2405 Accounting- 483 9.8.7 Enumerated | M | V |
2406 Realtime-Required | | |
2407 Acct- 50 9.8.5 UTF8String | M | V |
2408 Multi-Session-Id | | |
2409 Accounting- 485 9.8.3 Unsigned32 | M | V |
2410 Record-Number | | |
2411 Accounting- 480 9.8.1 Enumerated | M | V |
2412 Record-Type | | |
2413 Accounting- 44 9.8.4 OctetString| M | V |
2414 Session-Id | | |
2415 Accounting- 287 9.8.6 Unsigned64 | M | V |
2416 Sub-Session-Id | | |
2417 Acct- 259 6.9 Unsigned32 | M | V |
2418 Application-Id | | |
2419 Auth- 258 6.8 Unsigned32 | M | V |
2420 Application-Id | | |
2421 Auth-Request- 274 8.7 Enumerated | M | V |
2422 Type | | |
2423 Authorization- 291 8.9 Unsigned32 | M | V |
2424 Lifetime | | |
2425 Auth-Grace- 276 8.10 Unsigned32 | M | V |
2426 Period | | |
2427 Auth-Session- 277 8.11 Enumerated | M | V |
2428 State | | |
2429 Re-Auth-Request- 285 8.12 Enumerated | M | V |
2430 Type | | |
2431 Class 25 8.20 OctetString| M | V |
2432 Destination-Host 293 6.5 DiamIdent | M | V |
2433 Destination- 283 6.6 DiamIdent | M | V |
2434 Realm | | |
2435 Disconnect-Cause 273 5.4.3 Enumerated | M | V |
2436 Error-Message 281 7.3 UTF8String | | V,M |
2437 Error-Reporting- 294 7.4 DiamIdent | | V,M |
2438 Host | | |
2439 Event-Timestamp 55 8.21 Time | M | V |
2440 Experimental- 297 7.6 Grouped | M | V |
2441 Result | | |
2442 -----------------------------------------|----+-----|
2443 +----------+
2444 | AVP Flag |
2445 | rules |
2446 |----+-----|
2447 AVP Section | |MUST |
2448 Attribute Name Code Defined Data Type |MUST| NOT |
2449 -----------------------------------------|----+-----|
2450 Experimental- 298 7.7 Unsigned32 | M | V |
2451 Result-Code | | |
2452 Failed-AVP 279 7.5 Grouped | M | V |
2453 Firmware- 267 5.3.4 Unsigned32 | | V,M |
2454 Revision | | |
2455 Host-IP-Address 257 5.3.5 Address | M | V |
2456 Inband-Security | M | V |
2457 -Id 299 6.10 Unsigned32 | | |
2458 Multi-Round- 272 8.19 Unsigned32 | M | V |
2459 Time-Out | | |
2460 Origin-Host 264 6.3 DiamIdent | M | V |
2461 Origin-Realm 296 6.4 DiamIdent | M | V |
2462 Origin-State-Id 278 8.16 Unsigned32 | M | V |
2463 Product-Name 269 5.3.7 UTF8String | | V,M |
2464 Proxy-Host 280 6.7.3 DiamIdent | M | V |
2465 Proxy-Info 284 6.7.2 Grouped | M | V |
2466 Proxy-State 33 6.7.4 OctetString| M | V |
2467 Redirect-Host 292 6.12 DiamURI | M | V |
2468 Redirect-Host- 261 6.13 Enumerated | M | V |
2469 Usage | | |
2470 Redirect-Max- 262 6.14 Unsigned32 | M | V |
2471 Cache-Time | | |
2472 Result-Code 268 7.1 Unsigned32 | M | V |
2473 Route-Record 282 6.7.1 DiamIdent | M | V |
2474 Session-Id 263 8.8 UTF8String | M | V |
2475 Session-Timeout 27 8.13 Unsigned32 | M | V |
2476 Session-Binding 270 8.17 Unsigned32 | M | V |
2477 Session-Server- 271 8.18 Enumerated | M | V |
2478 Failover | | |
2479 Supported- 265 5.3.6 Unsigned32 | M | V |
2480 Vendor-Id | | |
2481 Termination- 295 8.15 Enumerated | M | V |
2482 Cause | | |
2483 User-Name 1 8.14 UTF8String | M | V |
2484 Vendor-Id 266 5.3.3 Unsigned32 | M | V |
2485 Vendor-Specific- 260 6.11 Grouped | M | V |
2486 Application-Id | | |
2487 -----------------------------------------|----+-----|
2489 5. Diameter Peers
2491 This section describes how Diameter nodes establish connections and
2492 communicate with peers.
2494 5.1. Peer Connections
2496 Although a Diameter node may have many possible peers that it is able
2497 to communicate with, it may not be economical to have an established
2498 connection to all of them. At a minimum, a Diameter node SHOULD have
2499 an established connection with two peers per realm, known as the
2500 primary and secondary peers. Of course, a node MAY have additional
2501 connections, if it is deemed necessary. Typically, all messages for
2502 a realm are sent to the primary peer, but in the event that failover
2503 procedures are invoked, any pending requests are sent to the
2504 secondary peer. However, implementations are free to load balance
2505 requests between a set of peers.
2507 Note that a given peer MAY act as a primary for a given realm, while
2508 acting as a secondary for another realm.
2510 When a peer is deemed suspect, which could occur for various reasons,
2511 including not receiving a DWA within an allotted timeframe, no new
2512 requests should be forwarded to the peer, but failover procedures are
2513 invoked. When an active peer is moved to this mode, additional
2514 connections SHOULD be established to ensure that the necessary number
2515 of active connections exists.
2517 There are two ways that a peer is removed from the suspect peer list:
2519 1. The peer is no longer reachable, causing the transport connection
2520 to be shutdown. The peer is moved to the closed state.
2522 2. Three watchdog messages are exchanged with accepted round trip
2523 times, and the connection to the peer is considered stabilized.
2525 In the event the peer being removed is either the primary or
2526 secondary, an alternate peer SHOULD replace the deleted peer, and
2527 assume the role of either primary or secondary.
2529 5.2. Diameter Peer Discovery
2531 Allowing for dynamic Diameter agent discovery will make it possible
2532 for simpler and more robust deployment of Diameter services. In
2533 order to promote interoperable implementations of Diameter peer
2534 discovery, the following mechanisms are described. These are based
2535 on existing IETF standards. The first option (manual configuration)
2536 MUST be supported by all Diameter nodes, while the latter option
2537 (DNS) MAY be supported.
2539 There are two cases where Diameter peer discovery may be performed.
2540 The first is when a Diameter client needs to discover a first-hop
2541 Diameter agent. The second case is when a Diameter agent needs to
2542 discover another agent - for further handling of a Diameter
2543 operation. In both cases, the following 'search order' is
2544 recommended:
2546 1. The Diameter implementation consults its list of static
2547 (manually) configured Diameter agent locations. These will be
2548 used if they exist and respond.
2550 2. The Diameter implementation performs a NAPTR query for a server
2551 in a particular realm. The Diameter implementation has to know
2552 in advance which realm to look for a Diameter agent in. This
2553 could be deduced, for example, from the 'realm' in a NAI that a
2554 Diameter implementation needed to perform a Diameter operation
2555 on.
2557 * The services relevant for the task of transport protocol
2558 selection are those with NAPTR service fields with values
2559 "AAA+D2x", where x is a letter that corresponds to a transport
2560 protocol supported by the domain. This specification defines
2561 D2T for TCP, D2S for SCTP and D2L for TLS. An IANA registry
2562 for NAPTR service name to transport protocol mappings is
2563 defined in Section 11.6.
2565 These NAPTR records provide a mapping from a domain, to the
2566 SRV record for contacting a server with the specific transport
2567 protocol in the NAPTR services field. The resource record
2568 will contain an empty regular expression and the replacement
2569 value will contain the SRV record for that particular
2570 transport protocol. If the server supports multiple transport
2571 protocols, there will be multiple NAPTR records, each with a
2572 different service value. As per [RFC3403], the client
2573 discards any records whose services fields are not applicable.
2574 For the purposes of this specification, several rules are
2575 defined.
2577 * A client MUST discard any service fields that identify a
2578 resolution service whose value is not "D2X", for values of X
2579 that indicate transport protocols supported by the client.
2580 The NAPTR processing as described in [RFC3403] will result in
2581 discovery of the most preferred transport protocol of the
2582 server that is supported by the client, as well as an SRV
2583 record for the server.
2585 The domain suffixes in the NAPTR replacement field SHOULD
2586 match the domain of the original query.
2588 3. If no NAPTR records are found, the requester directly queries for
2589 SRV records '_diameter._sctp'.realm, '_diameter._tcp'.realm and
2590 '_diameter._tls'.realm depending on the requesters network
2591 protocol capabilities. If SRV records are found then the
2592 requester can perform address record query (A RR's and/or AAAA
2593 RR's) for the target hostname specified in the SRV records. If
2594 no SRV records are found, the requester gives up.
2596 If the server is using a site certificate, the domain name in the
2597 NAPTR query and the domain name in the replacement field MUST both be
2598 valid based on the site certificate handed out by the server in the
2599 TLS or IKE exchange. Similarly, the domain name in the SRV query and
2600 the domain name in the target in the SRV record MUST both be valid
2601 based on the same site certificate. Otherwise, an attacker could
2602 modify the DNS records to contain replacement values in a different
2603 domain, and the client could not validate that this was the desired
2604 behavior, or the result of an attack.
2606 Also, the Diameter Peer MUST check to make sure that the discovered
2607 peers are authorized to act in its role. Authentication via IKE or
2608 TLS, or validation of DNS RRs via DNSSEC is not sufficient to
2609 conclude this. For example, a web server may have obtained a valid
2610 TLS certificate, and secured RRs may be included in the DNS, but this
2611 does not imply that it is authorized to act as a Diameter Server.
2613 Authorization can be achieved for example, by configuration of a
2614 Diameter Server CA. Alternatively this can be achieved by definition
2615 of OIDs within TLS or IKE certificates so as to signify Diameter
2616 Server authorization.
2618 A dynamically discovered peer causes an entry in the Peer Table (see
2619 Section 2.6) to be created. Note that entries created via DNS MUST
2620 expire (or be refreshed) within the DNS TTL. If a peer is discovered
2621 outside of the local realm, a routing table entry (see Section 2.7)
2622 for the peer's realm is created. The routing table entry's
2623 expiration MUST match the peer's expiration value.
2625 5.3. Capabilities Exchange
2627 When two Diameter peers establish a transport connection, they MUST
2628 exchange the Capabilities Exchange messages, as specified in the peer
2629 state machine (see Section 5.6). This message allows the discovery
2630 of a peer's identity and its capabilities (protocol version number,
2631 supported Diameter applications, security mechanisms, etc.)
2633 The receiver only issues commands to its peers that have advertised
2634 support for the Diameter application that defines the command. A
2635 Diameter node MUST cache the supported applications in order to
2636 ensure that unrecognized commands and/or AVPs are not unnecessarily
2637 sent to a peer.
2639 A receiver of a Capabilities-Exchange-Req (CER) message that does not
2640 have any applications in common with the sender MUST return a
2641 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
2642 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
2643 layer connection. Note that receiving a CER or CEA from a peer
2644 advertising itself as a Relay (see Section 2.4) MUST be interpreted
2645 as having common applications with the peer.
2647 The receiver of the Capabilities-Exchange-Request (CER) MUST
2648 determine common applications by computing the intersection of its
2649 own set of supported Application Id against all of the application
2650 identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-
2651 Specific-Application-Id) present in the CER. The value of the
2652 Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
2653 during computation. The sender of the Capabilities-Exchange-Answer
2654 (CEA) SHOULD include all of its supported applications as a hint to
2655 the receiver regarding all of its application capabilities.
2657 CERs received from unknown peers MAY be silently discarded, or a CEA
2658 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
2659 In both cases, the transport connection is closed. If the local
2660 policy permits receiving CERs from unknown hosts, a successful CEA
2661 MAY be returned. If a CER from an unknown peer is answered with a
2662 successful CEA, the lifetime of the peer entry is equal to the
2663 lifetime of the transport connection. In case of a transport
2664 failure, all the pending transactions destined to the unknown peer
2665 can be discarded.
2667 The CER and CEA messages MUST NOT be proxied, redirected or relayed.
2669 Since the CER/CEA messages cannot be proxied, it is still possible
2670 that an upstream agent receives a message for which it has no
2671 available peers to handle the application that corresponds to the
2672 Command-Code. In such instances, the 'E' bit is set in the answer
2673 message (see Section 7.) with the Result-Code AVP set to
2674 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action
2675 (e.g., re-routing request to an alternate peer).
2677 With the exception of the Capabilities-Exchange-Request message, a
2678 message of type Request that includes the Auth-Application-Id or
2679 Acct-Application-Id AVPs, or a message with an application-specific
2680 command code, MAY only be forwarded to a host that has explicitly
2681 advertised support for the application (or has advertised the Relay
2682 Application Id).
2684 5.3.1. Capabilities-Exchange-Request
2686 The Capabilities-Exchange-Request (CER), indicated by the Command-
2687 Code set to 257 and the Command Flags' 'R' bit set, is sent to
2688 exchange local capabilities. Upon detection of a transport failure,
2689 this message MUST NOT be sent to an alternate peer.
2691 When Diameter is run over SCTP [RFC2960], which allows for
2692 connections to span multiple interfaces and multiple IP addresses,
2693 the Capabilities-Exchange-Request message MUST contain one Host-IP-
2694 Address AVP for each potential IP address that MAY be locally used
2695 when transmitting Diameter messages.
2697 Message Format
2699 ::= < Diameter Header: 257, REQ >
2700 { Origin-Host }
2701 { Origin-Realm }
2702 1* { Host-IP-Address }
2703 { Vendor-Id }
2704 { Product-Name }
2705 [ Origin-State-Id ]
2706 * [ Supported-Vendor-Id ]
2707 * [ Auth-Application-Id ]
2708 * [ Acct-Application-Id ]
2709 * [ Vendor-Specific-Application-Id ]
2710 [ Firmware-Revision ]
2711 * [ AVP ]
2713 5.3.2. Capabilities-Exchange-Answer
2715 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code
2716 set to 257 and the Command Flags' 'R' bit cleared, is sent in
2717 response to a CER message.
2719 When Diameter is run over SCTP [RFC2960], which allows connections to
2720 span multiple interfaces, hence, multiple IP addresses, the
2721 Capabilities-Exchange-Answer message MUST contain one Host-IP-Address
2722 AVP for each potential IP address that MAY be locally used when
2723 transmitting Diameter messages.
2725 Message Format
2727 ::= < Diameter Header: 257 >
2728 { Result-Code }
2729 { Origin-Host }
2730 { Origin-Realm }
2731 1* { Host-IP-Address }
2732 { Vendor-Id }
2733 { Product-Name }
2734 [ Origin-State-Id ]
2735 [ Error-Message ]
2736 [ Failed-AVP ]
2737 * [ Supported-Vendor-Id ]
2738 * [ Auth-Application-Id ]
2739 * [ Acct-Application-Id ]
2740 * [ Vendor-Specific-Application-Id ]
2741 [ Firmware-Revision ]
2742 * [ AVP ]
2744 5.3.3. Vendor-Id AVP
2746 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
2747 the IANA "SMI Network Management Private Enterprise Codes" [RFC3232]
2748 value assigned to the vendor of the Diameter device. It is
2749 envisioned that the combination of the Vendor-Id, Product-Name
2750 (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs may
2751 provide useful debugging information.
2753 A Vendor-Id value of zero in the CER or CEA messages is reserved and
2754 indicates that this field is ignored.
2756 5.3.4. Firmware-Revision AVP
2758 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
2759 used to inform a Diameter peer of the firmware revision of the
2760 issuing device.
2762 For devices that do not have a firmware revision (general purpose
2763 computers running Diameter software modules, for instance), the
2764 revision of the Diameter software module may be reported instead.
2766 5.3.5. Host-IP-Address AVP
2768 The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
2769 to inform a Diameter peer of the sender's IP address. All source
2770 addresses that a Diameter node expects to use with SCTP [RFC2960]
2771 MUST be advertised in the CER and CEA messages by including a Host-
2772 IP-Address AVP for each address.
2774 5.3.6. Supported-Vendor-Id AVP
2776 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
2777 contains the IANA "SMI Network Management Private Enterprise Codes"
2778 [RFC3232] value assigned to a vendor other than the device vendor but
2779 including the application vendor. This is used in the CER and CEA
2780 messages in order to inform the peer that the sender supports (a
2781 subset of) the vendor-specific AVPs defined by the vendor identified
2782 in this AVP. The value of this AVP MUST NOT be set to zero.
2783 Multiple instances of this AVP containing the same value SHOULD NOT
2784 be sent.
2786 5.3.7. Product-Name AVP
2788 The Product-Name AVP (AVP Code 269) is of type UTF8String, and
2789 contains the vendor assigned name for the product. The Product-Name
2790 AVP SHOULD remain constant across firmware revisions for the same
2791 product.
2793 5.4. Disconnecting Peer connections
2795 When a Diameter node disconnects one of its transport connections,
2796 its peer cannot know the reason for the disconnect, and will most
2797 likely assume that a connectivity problem occurred, or that the peer
2798 has rebooted. In these cases, the peer may periodically attempt to
2799 reconnect, as stated in Section 2.1. In the event that the
2800 disconnect was a result of either a shortage of internal resources,
2801 or simply that the node in question has no intentions of forwarding
2802 any Diameter messages to the peer in the foreseeable future, a
2803 periodic connection request would not be welcomed. The
2804 Disconnection-Reason AVP contains the reason the Diameter node issued
2805 the Disconnect-Peer-Request message.
2807 The Disconnect-Peer-Request message is used by a Diameter node to
2808 inform its peer of its intent to disconnect the transport layer, and
2809 that the peer shouldn't reconnect unless it has a valid reason to do
2810 so (e.g., message to be forwarded). Upon receipt of the message, the
2811 Disconnect-Peer-Answer is returned, which SHOULD contain an error if
2812 messages have recently been forwarded, and are likely in flight,
2813 which would otherwise cause a race condition.
2815 The receiver of the Disconnect-Peer-Answer initiates the transport
2816 disconnect. The sender of the Disconnect-Peer-Answer should be able
2817 to detect the transport closure and cleanup the connection.
2819 5.4.1. Disconnect-Peer-Request
2821 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set
2822 to 282 and the Command Flags' 'R' bit set, is sent to a peer to
2823 inform its intentions to shutdown the transport connection. Upon
2824 detection of a transport failure, this message MUST NOT be sent to an
2825 alternate peer.
2827 Message Format
2829 ::= < Diameter Header: 282, REQ >
2830 { Origin-Host }
2831 { Origin-Realm }
2832 { Disconnect-Cause }
2833 * [ AVP ]
2835 5.4.2. Disconnect-Peer-Answer
2837 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set
2838 to 282 and the Command Flags' 'R' bit cleared, is sent as a response
2839 to the Disconnect-Peer-Request message. Upon receipt of this
2840 message, the transport connection is shutdown.
2842 Message Format
2844 ::= < Diameter Header: 282 >
2845 { Result-Code }
2846 { Origin-Host }
2847 { Origin-Realm }
2848 [ Error-Message ]
2849 [ Failed-AVP ]
2850 * [ AVP ]
2852 5.4.3. Disconnect-Cause AVP
2854 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
2855 Diameter node MUST include this AVP in the Disconnect-Peer-Request
2856 message to inform the peer of the reason for its intention to
2857 shutdown the transport connection. The following values are
2858 supported:
2860 REBOOTING 0
2861 A scheduled reboot is imminent. Receiver of DPR with above result
2862 code MAY attempt reconnection.
2864 BUSY 1
2865 The peer's internal resources are constrained, and it has
2866 determined that the transport connection needs to be closed.
2867 Receiver of DPR with above result code SHOULD NOT attempt
2868 reconnection.
2870 DO_NOT_WANT_TO_TALK_TO_YOU 2
2871 The peer has determined that it does not see a need for the
2872 transport connection to exist, since it does not expect any
2873 messages to be exchanged in the near future. Receiver of DPR
2874 with above result code SHOULD NOT attempt reconnection.
2876 5.5. Transport Failure Detection
2878 Given the nature of the Diameter protocol, it is recommended that
2879 transport failures be detected as soon as possible. Detecting such
2880 failures will minimize the occurrence of messages sent to unavailable
2881 agents, resulting in unnecessary delays, and will provide better
2882 failover performance. The Device-Watchdog-Request and Device-
2883 Watchdog-Answer messages, defined in this section, are used to pro-
2884 actively detect transport failures.
2886 5.5.1. Device-Watchdog-Request
2888 The Device-Watchdog-Request (DWR), indicated by the Command-Code set
2889 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
2890 traffic has been exchanged between two peers (see Section 5.5.3).
2891 Upon detection of a transport failure, this message MUST NOT be sent
2892 to an alternate peer.
2894 Message Format
2896 ::= < Diameter Header: 280, REQ >
2897 { Origin-Host }
2898 { Origin-Realm }
2899 [ Origin-State-Id ]
2900 * [ AVP ]
2902 5.5.2. Device-Watchdog-Answer
2904 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
2905 to 280 and the Command Flags' 'R' bit cleared, is sent as a response
2906 to the Device-Watchdog-Request message.
2908 Message Format
2910 ::= < Diameter Header: 280 >
2911 { Result-Code }
2912 { Origin-Host }
2913 { Origin-Realm }
2914 [ Error-Message ]
2915 [ Failed-AVP ]
2916 [ Origin-State-Id ]
2917 * [ AVP ]
2919 5.5.3. Transport Failure Algorithm
2921 The transport failure algorithm is defined in [RFC3539]. All
2922 Diameter implementations MUST support the algorithm defined in the
2923 specification in order to be compliant to the Diameter base protocol.
2925 5.5.4. Failover and Failback Procedures
2927 In the event that a transport failure is detected with a peer, it is
2928 necessary for all pending request messages to be forwarded to an
2929 alternate agent, if possible. This is commonly referred to as
2930 failover.
2932 In order for a Diameter node to perform failover procedures, it is
2933 necessary for the node to maintain a pending message queue for a
2934 given peer. When an answer message is received, the corresponding
2935 request is removed from the queue. The Hop-by-Hop Identifier field
2936 is used to match the answer with the queued request.
2938 When a transport failure is detected, if possible all messages in the
2939 queue are sent to an alternate agent with the T flag set. On booting
2940 a Diameter client or agent, the T flag is also set on any records
2941 still remaining to be transmitted in non-volatile storage. An
2942 example of a case where it is not possible to forward the message to
2943 an alternate server is when the message has a fixed destination, and
2944 the unavailable peer is the message's final destination (see
2945 Destination-Host AVP). Such an error requires that the agent return
2946 an answer message with the 'E' bit set and the Result-Code AVP set to
2947 DIAMETER_UNABLE_TO_DELIVER.
2949 It is important to note that multiple identical requests or answers
2950 MAY be received as a result of a failover. The End-to-End Identifier
2951 field in the Diameter header along with the Origin-Host AVP MUST be
2952 used to identify duplicate messages.
2954 As described in Section 2.1, a connection request should be
2955 periodically attempted with the failed peer in order to re-establish
2956 the transport connection. Once a connection has been successfully
2957 established, messages can once again be forwarded to the peer. This
2958 is commonly referred to as failback.
2960 5.6. Peer State Machine
2962 This section contains a finite state machine that MUST be observed by
2963 all Diameter implementations. Each Diameter node MUST follow the
2964 state machine described below when communicating with each peer.
2965 Multiple actions are separated by commas, and may continue on
2966 succeeding lines, as space requires. Similarly, state and next state
2967 may also span multiple lines, as space requires.
2969 This state machine is closely coupled with the state machine
2970 described in [RFC3539], which is used to open, close, failover,
2971 probe, and reopen transport connections. Note in particular that
2972 [RFC3539] requires the use of watchdog messages to probe connections.
2973 For Diameter, DWR and DWA messages are to be used.
2975 I- is used to represent the initiator (connecting) connection, while
2976 the R- is used to represent the responder (listening) connection.
2977 The lack of a prefix indicates that the event or action is the same
2978 regardless of the connection on which the event occurred.
2980 The stable states that a state machine may be in are Closed, I-Open
2981 and R-Open; all other states are intermediate. Note that I-Open and
2982 R-Open are equivalent except for whether the initiator or responder
2983 transport connection is used for communication.
2985 A CER message is always sent on the initiating connection immediately
2986 after the connection request is successfully completed. In the case
2987 of an election, one of the two connections will shut down. The
2988 responder connection will survive if the Origin-Host of the local
2989 Diameter entity is higher than that of the peer; the initiator
2990 connection will survive if the peer's Origin-Host is higher. All
2991 subsequent messages are sent on the surviving connection. Note that
2992 the results of an election on one peer are guaranteed to be the
2993 inverse of the results on the other.
2995 For TLS usage, TLS handshake will begin when both ends are in the
2996 closed state prior to any Diameter message exchanges. The TLS
2997 connection MUST be established before sending any CER or CEA message
2998 to secure and protect the capabilities information of both peers.
2999 Establishment of the TLS connection is independent of the state
3000 machine described here and MUST be treated as a lower layer transport
3001 for all Diameter message. The TLS connection SHOULD be disconnected
3002 when the state machine goes back to the closed state to save on
3003 system resources.
3005 The state machine constrains only the behavior of a Diameter
3006 implementation as seen by Diameter peers through events on the wire.
3008 Any implementation that produces equivalent results is considered
3009 compliant.
3011 state event action next state
3012 -----------------------------------------------------------------
3013 Closed Start I-Snd-Conn-Req Wait-Conn-Ack
3014 R-Conn-CER R-Accept, R-Open
3015 Process-CER,
3016 R-Snd-CEA
3018 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA
3019 I-Rcv-Conn-Nack Cleanup Closed
3020 R-Conn-CER R-Accept, Wait-Conn-Ack/
3021 Process-CER Elect
3022 Timeout Error Closed
3024 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
3025 R-Conn-CER R-Accept, Wait-Returns
3026 Process-CER,
3027 Elect
3028 I-Peer-Disc I-Disc Closed
3029 I-Rcv-Non-CEA Error Closed
3030 Timeout Error Closed
3032 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns
3033 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open
3034 R-Peer-Disc R-Disc Wait-Conn-Ack
3035 R-Conn-CER R-Reject Wait-Conn-Ack/
3036 Elect
3037 Timeout Error Closed
3039 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
3040 I-Peer-Disc I-Disc, R-Open
3041 R-Snd-CEA
3042 I-Rcv-CEA R-Disc I-Open
3043 R-Peer-Disc R-Disc Wait-I-CEA
3044 R-Conn-CER R-Reject Wait-Returns
3045 Timeout Error Closed
3047 R-Open Send-Message R-Snd-Message R-Open
3048 R-Rcv-Message Process R-Open
3049 R-Rcv-DWR Process-DWR, R-Open
3050 R-Snd-DWA
3051 R-Rcv-DWA Process-DWA R-Open
3052 R-Conn-CER R-Reject R-Open
3053 Stop R-Snd-DPR Closing
3054 R-Rcv-DPR R-Snd-DPA, Closed
3055 R-Disc
3056 R-Peer-Disc R-Disc Closed
3058 I-Open Send-Message I-Snd-Message I-Open
3059 I-Rcv-Message Process I-Open
3060 I-Rcv-DWR Process-DWR, I-Open
3061 I-Snd-DWA
3062 I-Rcv-DWA Process-DWA I-Open
3063 R-Conn-CER R-Reject I-Open
3064 Stop I-Snd-DPR Closing
3065 I-Rcv-DPR I-Snd-DPA, Closed
3066 I-Disc
3067 I-Peer-Disc I-Disc Closed
3069 Closing I-Rcv-DPA I-Disc Closed
3070 R-Rcv-DPA R-Disc Closed
3071 Timeout Error Closed
3072 I-Peer-Disc I-Disc Closed
3073 R-Peer-Disc R-Disc Closed
3075 5.6.1. Incoming connections
3077 When a connection request is received from a Diameter peer, it is
3078 not, in the general case, possible to know the identity of that peer
3079 until a CER is received from it. This is because host and port
3080 determine the identity of a Diameter peer; and the source port of an
3081 incoming connection is arbitrary. Upon receipt of CER, the identity
3082 of the connecting peer can be uniquely determined from Origin-Host.
3084 For this reason, a Diameter peer must employ logic separate from the
3085 state machine to receive connection requests, accept them, and await
3086 CER. Once CER arrives on a new connection, the Origin-Host that
3087 identifies the peer is used to locate the state machine associated
3088 with that peer, and the new connection and CER are passed to the
3089 state machine as an R-Conn-CER event.
3091 The logic that handles incoming connections SHOULD close and discard
3092 the connection if any message other than CER arrives, or if an
3093 implementation-defined timeout occurs prior to receipt of CER.
3095 Because handling of incoming connections up to and including receipt
3096 of CER requires logic, separate from that of any individual state
3097 machine associated with a particular peer, it is described separately
3098 in this section rather than in the state machine above.
3100 5.6.2. Events
3102 Transitions and actions in the automaton are caused by events. In
3103 this section, we will ignore the -I and -R prefix, since the actual
3104 event would be identical, but would occur on one of two possible
3105 connections.
3107 Start The Diameter application has signaled that a
3108 connection should be initiated with the peer.
3110 R-Conn-CER An acknowledgement is received stating that the
3111 transport connection has been established, and the
3112 associated CER has arrived.
3114 Rcv-Conn-Ack A positive acknowledgement is received confirming that
3115 the transport connection is established.
3117 Rcv-Conn-Nack A negative acknowledgement was received stating that
3118 the transport connection was not established.
3120 Timeout An application-defined timer has expired while waiting
3121 for some event.
3123 Rcv-CER A CER message from the peer was received.
3125 Rcv-CEA A CEA message from the peer was received.
3127 Rcv-Non-CEA A message other than CEA from the peer was received.
3129 Peer-Disc A disconnection indication from the peer was received.
3131 Rcv-DPR A DPR message from the peer was received.
3133 Rcv-DPA A DPA message from the peer was received.
3135 Win-Election An election was held, and the local node was the
3136 winner.
3138 Send-Message A message is to be sent.
3140 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR or DWA
3141 was received.
3143 Stop The Diameter application has signaled that a
3144 connection should be terminated (e.g., on system
3145 shutdown).
3147 5.6.3. Actions
3149 Actions in the automaton are caused by events and typically indicate
3150 the transmission of packets and/or an action to be taken on the
3151 connection. In this section we will ignore the I- and R-prefix,
3152 since the actual action would be identical, but would occur on one of
3153 two possible connections.
3155 Snd-Conn-Req A transport connection is initiated with the peer.
3157 Accept The incoming connection associated with the R-Conn-CER
3158 is accepted as the responder connection.
3160 Reject The incoming connection associated with the R-Conn-CER
3161 is disconnected.
3163 Process-CER The CER associated with the R-Conn-CER is processed.
3164 Snd-CER A CER message is sent to the peer.
3166 Snd-CEA A CEA message is sent to the peer.
3168 Cleanup If necessary, the connection is shutdown, and any
3169 local resources are freed.
3171 Error The transport layer connection is disconnected,
3172 either politely or abortively, in response to
3173 an error condition. Local resources are freed.
3175 Process-CEA A received CEA is processed.
3177 Snd-DPR A DPR message is sent to the peer.
3179 Snd-DPA A DPA message is sent to the peer.
3181 Disc The transport layer connection is disconnected,
3182 and local resources are freed.
3184 Elect An election occurs (see Section 5.6.4 for more
3185 information).
3187 Snd-Message A message is sent.
3189 Snd-DWR A DWR message is sent.
3191 Snd-DWA A DWA message is sent.
3193 Process-DWR The DWR message is serviced.
3195 Process-DWA The DWA message is serviced.
3197 Process A message is serviced.
3199 5.6.4. The Election Process
3201 The election is performed on the responder. The responder compares
3202 the Origin-Host received in the CER with its own Origin-Host as two
3203 streams of octets. If the local Origin-Host lexicographically
3204 succeeds the received Origin-Host a Win-Election event is issued
3205 locally. Diameter identities are in ASCII form therefore the lexical
3206 comparison is consistent with DNS case insensitivity where octets
3207 that fall in the ASCII range 'a' through 'z' MUST compare equally to
3208 their upper-case counterparts between 'A' and 'Z'. See Appendix D
3209 for interactions between the Diameter protocol and Internationalized
3210 Domain Name (IDNs).
3212 The winner of the election MUST close the connection it initiated.
3213 Historically, maintaining the responder side of a connection was more
3214 efficient than maintaining the initiator side. However, current
3215 practices makes this distinction irrelevant.
3217 6. Diameter message processing
3219 This section describes how Diameter requests and answers are created
3220 and processed.
3222 6.1. Diameter Request Routing Overview
3224 A request is sent towards its final destination using a combination
3225 of the Destination-Realm and Destination-Host AVPs, in one of these
3226 three combinations:
3228 o a request that is not able to be proxied (such as CER) MUST NOT
3229 contain either Destination-Realm or Destination-Host AVPs.
3231 o a request that needs to be sent to a home server serving a
3232 specific realm, but not to a specific server (such as the first
3233 request of a series of round-trips), MUST contain a Destination-
3234 Realm AVP, but MUST NOT contain a Destination-Host AVP. For
3235 Diameter clients, the value of the Destination-Realm AVP MAY be
3236 extracted from the User-Name AVP, or other methods.
3238 o otherwise, a request that needs to be sent to a specific home
3239 server among those serving a given realm, MUST contain both the
3240 Destination-Realm and Destination-Host AVPs.
3242 The Destination-Host AVP is used as described above when the
3243 destination of the request is fixed, which includes:
3245 o Authentication requests that span multiple round trips
3247 o A Diameter message that uses a security mechanism that makes use
3248 of a pre-established session key shared between the source and the
3249 final destination of the message.
3251 o Server initiated messages that MUST be received by a specific
3252 Diameter client (e.g., access device), such as the Abort-Session-
3253 Request message, which is used to request that a particular user's
3254 session be terminated.
3256 Note that an agent can forward a request to a host described in the
3257 Destination-Host AVP only if the host in question is included in its
3258 peer table (see Section 2.7). Otherwise, the request is routed based
3259 on the Destination-Realm only (see Sections 6.1.6).
3261 When a message is received, the message is processed in the following
3262 order:
3264 o If the message is destined for the local host, the procedures
3265 listed in Section 6.1.4 are followed.
3267 o If the message is intended for a Diameter peer with whom the local
3268 host is able to directly communicate, the procedures listed in
3269 Section 6.1.5 are followed. This is known as Request Forwarding.
3271 o The procedures listed in Section 6.1.6 are followed, which is
3272 known as Request Routing.
3274 o If none of the above is successful, an answer is returned with the
3275 Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.
3277 For routing of Diameter messages to work within an administrative
3278 domain, all Diameter nodes within the realm MUST be peers.
3280 Note the processing rules contained in this section are intended to
3281 be used as general guidelines to Diameter developers. Certain
3282 implementations MAY use different methods than the ones described
3283 here, and still comply with the protocol specification. See Section
3284 7 for more detail on error handling.
3286 6.1.1. Originating a Request
3288 When creating a request, in addition to any other procedures
3289 described in the application definition for that specific request,
3290 the following procedures MUST be followed:
3292 o the Command-Code is set to the appropriate value
3294 o the 'R' bit is set
3296 o the End-to-End Identifier is set to a locally unique value
3298 o the Origin-Host and Origin-Realm AVPs MUST be set to the
3299 appropriate values, used to identify the source of the message
3301 o the Destination-Host and Destination-Realm AVPs MUST be set to the
3302 appropriate values as described in Section 6.1.
3304 6.1.2. Sending a Request
3306 When sending a request, originated either locally, or as the result
3307 of a forwarding or routing operation, the following procedures SHOULD
3308 be followed:
3310 o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
3312 o The message SHOULD be saved in the list of pending requests.
3314 Other actions to perform on the message based on the particular role
3315 the agent is playing are described in the following sections.
3317 6.1.3. Receiving Requests
3319 A relay or proxy agent MUST check for forwarding loops when receiving
3320 requests. A loop is detected if the server finds its own identity in
3321 a Route-Record AVP. When such an event occurs, the agent MUST answer
3322 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
3324 6.1.4. Processing Local Requests
3326 A request is known to be for local consumption when one of the
3327 following conditions occur:
3329 o The Destination-Host AVP contains the local host's identity,
3331 o The Destination-Host AVP is not present, the Destination-Realm AVP
3332 contains a realm the server is configured to process locally, and
3333 the Diameter application is locally supported, or
3335 o Both the Destination-Host and the Destination-Realm are not
3336 present.
3338 When a request is locally processed, the rules in Section 6.2 should
3339 be used to generate the corresponding answer.
3341 6.1.5. Request Forwarding
3343 Request forwarding is done using the Diameter Peer Table. The
3344 Diameter peer table contains all of the peers that the local node is
3345 able to directly communicate with.
3347 When a request is received, and the host encoded in the Destination-
3348 Host AVP is one that is present in the peer table, the message SHOULD
3349 be forwarded to the peer.
3351 6.1.6. Request Routing
3353 Diameter request message routing is done via realms and application
3354 identifiers. A Diameter message that may be forwarded by Diameter
3355 agents (proxies, redirect or relay agents) MUST include the target
3356 realm in the Destination-Realm AVP. Request routing SHOULD rely on
3357 the Destination-Realm AVP and the Application Id present in the
3358 request message header to aid in the routing decision. The realm MAY
3359 be retrieved from the User-Name AVP, which is in the form of a
3360 Network Access Identifier (NAI). The realm portion of the NAI is
3361 inserted in the Destination-Realm AVP.
3363 Diameter agents MAY have a list of locally supported realms and
3364 applications, and MAY have a list of externally supported realms and
3365 applications. When a request is received that includes a realm
3366 and/or application that is not locally supported, the message is
3367 routed to the peer configured in the Routing Table (see Section 2.7).
3369 Realm names and Application Ids are the minimum supported routing
3370 criteria, additional information maybe needed to support redirect
3371 semantics.
3373 6.1.7. Predictive Loop Avoidance
3375 Before forwarding or routing a request, Diameter agents, in addition
3376 to processing done in Section 6.1.3, SHOULD check for the presence of
3377 candidate route's peer identity in any of the Route-Record AVPs. In
3378 an event of the agent detecting the presence of a candidate route's
3379 peer identity in a Route-Record AVP, the agent MUST ignore such route
3380 for the Diameter request message and attempt alternate routes if any.
3381 In case all the candidate routes are eliminated by the above
3382 criteria, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message.
3384 6.1.8. Redirecting Requests
3386 When a redirect agent receives a request whose routing entry is set
3387 to REDIRECT, it MUST reply with an answer message with the 'E' bit
3388 set, while maintaining the Hop-by-Hop Identifier in the header, and
3389 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of
3390 the servers associated with the routing entry are added in separate
3391 Redirect-Host AVP.
3393 +------------------+
3394 | Diameter |
3395 | Redirect Agent |
3396 +------------------+
3397 ^ | 2. command + 'E' bit
3398 1. Request | | Result-Code =
3399 joe@example.com | | DIAMETER_REDIRECT_INDICATION +
3400 | | Redirect-Host AVP(s)
3401 | v
3402 +-------------+ 3. Request +-------------+
3403 | example.com |------------->| example.net |
3404 | Relay | | Diameter |
3405 | Agent |<-------------| Server |
3406 +-------------+ 4. Answer +-------------+
3407 Figure 5: Diameter Redirect Agent
3409 The receiver of the answer message with the 'E' bit set, and the
3410 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-
3411 hop field in the Diameter header to identify the request in the
3412 pending message queue (see Section 5.3) that is to be redirected. If
3413 no transport connection exists with the new agent, one is created,
3414 and the request is sent directly to it.
3416 Multiple Redirect-Host AVPs are allowed. The receiver of the answer
3417 message with the 'E' bit set selects exactly one of these hosts as
3418 the destination of the redirected message.
3420 When the Redirect-Host-Usage AVP included in the answer message has a
3421 non-zero value, a route entry for the redirect indications is created
3422 and cached by the receiver. The redirect usage for such route entry
3423 is set by the value of Redirect-Host-Usage AVP and the lifetime of
3424 the cached route entry is set by Redirect-Max-Cache-Time AVP value.
3426 It is possible that multiple redirect indications can create multiple
3427 cached route entries differing only in their redirect usage and the
3428 peer to forward messages to. As an example, two(2) route entries
3429 that are created by two(2) redirect indications results in two(2)
3430 cached routes for the same realm and Application Id. However, one
3431 has a redirect usage of ALL_SESSION where matching request will be
3432 forwarded to one peer and the other has a redirect usage of ALL_REALM
3433 where request are forwarded to another peer. Therefore, an incoming
3434 request that matches the realm and Application Id of both routes will
3435 need additional resolution. In such a case, a routing precedence
3436 rule MUST be used againts the redirect usage value to resolve the
3437 contention. The precedence rule can be found in Section 6.13.
3439 6.1.9. Relaying and Proxying Requests
3441 A relay or proxy agent MUST append a Route-Record AVP to all requests
3442 forwarded. The AVP contains the identity of the peer the request was
3443 received from.
3445 The Hop-by-Hop identifier in the request is saved, and replaced with
3446 a locally unique value. The source of the request is also saved,
3447 which includes the IP address, port and protocol.
3449 A relay or proxy agent MAY include the Proxy-Info AVP in requests if
3450 it requires access to any local state information when the
3451 corresponding response is received. The Proxy-Info AVP has security
3452 implications as state information is distribute to other entities.
3453 As such, it is RECOMMMENDED to protect the content of the Proxy-Info
3454 AVP with cryptographic mechanisms, for example by using a keyed
3455 message digest. Such a mechanism, however, requires the management
3456 of keys, although only locally at the Diameter server. Still, a full
3457 description of the management of the keys used to protect the Proxy-
3458 Info AVP is beyond the scope of this document. Below is a list of
3459 commonly recommended:
3461 o The keys should be generated securely following the randomness
3462 recommendations in [RFC4086].
3464 o The keys and cryptographic protection algorithms should be at
3465 least 128 bits in strength.
3467 o The keys should not be used for any other purpose than generating
3468 and verifying tickets.
3470 o The keys should be changed regularly.
3472 o The keys should be changed if the ticket format or cryptographic
3473 protection algorithms change.
3475 The message is then forwarded to the next hop, as identified in the
3476 Routing Table.
3478 Figure 6 provides an example of message routing using the procedures
3479 listed in these sections.
3481 (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net)
3482 (Origin-Realm=mno.net) (Origin-Realm=mno.net)
3483 (Destination-Realm=example.com) (Destination-
3484 Realm=example.com)
3485 (Route-Record=nas.example.net)
3486 +------+ ------> +------+ ------> +------+
3487 | | (Request) | | (Request) | |
3488 | NAS +-------------------+ DRL +-------------------+ HMS |
3489 | | | | | |
3490 +------+ <------ +------+ <------ +------+
3491 example.net (Answer) example.net (Answer) example.com
3492 (Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
3493 (Origin-Realm=example.com) (Origin-Realm=example.com)
3495 Figure 6: Routing of Diameter messages
3497 Relay and proxy agents are not required to perform full inspection of
3498 incoming messages. At a minimum, validation of the message header
3499 and relevant routing AVPs has to be done when relaying messages.
3500 Proxy agents may optionally perform more in-depth message validation
3501 for applications it is interested in.
3503 6.2. Diameter Answer Processing
3505 When a request is locally processed, the following procedures MUST be
3506 applied to create the associated answer, in addition to any
3507 additional procedures that MAY be discussed in the Diameter
3508 application defining the command:
3510 o The same Hop-by-Hop identifier in the request is used in the
3511 answer.
3513 o The local host's identity is encoded in the Origin-Host AVP.
3515 o The Destination-Host and Destination-Realm AVPs MUST NOT be
3516 present in the answer message.
3518 o The Result-Code AVP is added with its value indicating success or
3519 failure.
3521 o If the Session-Id is present in the request, it MUST be included
3522 in the answer.
3524 o Any Proxy-Info AVPs in the request MUST be added to the answer
3525 message, in the same order they were present in the request.
3527 o The 'P' bit is set to the same value as the one in the request.
3529 o The same End-to-End identifier in the request is used in the
3530 answer.
3532 Note that the error messages (see Section 7.3) are also subjected to
3533 the above processing rules.
3535 6.2.1. Processing received Answers
3537 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
3538 answer received against the list of pending requests. The
3539 corresponding message should be removed from the list of pending
3540 requests. It SHOULD ignore answers received that do not match a
3541 known Hop-by-Hop Identifier.
3543 6.2.2. Relaying and Proxying Answers
3545 If the answer is for a request which was proxied or relayed, the
3546 agent MUST restore the original value of the Diameter header's Hop-
3547 by-Hop Identifier field.
3549 If the last Proxy-Info AVP in the message is targeted to the local
3550 Diameter server, the AVP MUST be removed before the answer is
3551 forwarded.
3553 If a relay or proxy agent receives an answer with a Result-Code AVP
3554 indicating a failure, it MUST NOT modify the contents of the AVP.
3555 Any additional local errors detected SHOULD be logged, but not
3556 reflected in the Result-Code AVP. If the agent receives an answer
3557 message with a Result-Code AVP indicating success, and it wishes to
3558 modify the AVP to indicate an error, it MUST modify the Result-Code
3559 AVP to contain the appropriate error in the message destined towards
3560 the access device as well as include the Error-Reporting-Host AVP and
3561 it MUST issue an STR on behalf of the access device towards the
3562 Diameter server.
3564 The agent MUST then send the answer to the host that it received the
3565 original request from.
3567 6.3. Origin-Host AVP
3569 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
3570 MUST be present in all Diameter messages. This AVP identifies the
3571 endpoint that originated the Diameter message. Relay agents MUST NOT
3572 modify this AVP.
3574 The value of the Origin-Host AVP is guaranteed to be unique within a
3575 single host.
3577 Note that the Origin-Host AVP may resolve to more than one address as
3578 the Diameter peer may support more than one address.
3580 This AVP SHOULD be placed as close to the Diameter header as
3581 possible.
3583 6.4. Origin-Realm AVP
3585 The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.
3586 This AVP contains the Realm of the originator of any Diameter message
3587 and MUST be present in all messages.
3589 This AVP SHOULD be placed as close to the Diameter header as
3590 possible.
3592 6.5. Destination-Host AVP
3594 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
3595 This AVP MUST be present in all unsolicited agent initiated messages,
3596 MAY be present in request messages, and MUST NOT be present in Answer
3597 messages.
3599 The absence of the Destination-Host AVP will cause a message to be
3600 sent to any Diameter server supporting the application within the
3601 realm specified in Destination-Realm AVP.
3603 This AVP SHOULD be placed as close to the Diameter header as
3604 possible.
3606 6.6. Destination-Realm AVP
3608 The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity,
3609 and contains the realm the message is to be routed to. The
3610 Destination-Realm AVP MUST NOT be present in Answer messages.
3611 Diameter Clients insert the realm portion of the User-Name AVP.
3612 Diameter servers initiating a request message use the value of the
3613 Origin-Realm AVP from a previous message received from the intended
3614 target host (unless it is known a priori). When present, the
3615 Destination-Realm AVP is used to perform message routing decisions.
3617 An ABNF for a request message that includes the Destination-Realm AVP
3618 SHOULD list the Destination-Realm AVP as a required AVP (an AVP
3619 indicated as {AVP}) otherwise the message is inherently a non-
3620 routable messages.
3622 This AVP SHOULD be placed as close to the Diameter header as
3623 possible.
3625 6.7. Routing AVPs
3627 The AVPs defined in this section are Diameter AVPs used for routing
3628 purposes. These AVPs change as Diameter messages are processed by
3629 agents.
3631 6.7.1. Route-Record AVP
3633 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
3634 identity added in this AVP MUST be the same as the one received in
3635 the Origin-Host of the Capabilities Exchange message.
3637 6.7.2. Proxy-Info AVP
3639 The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
3640 contains the identity and local state information of Diameter node
3641 that creates and adds it to a message. The Grouped Data field has
3642 the following ABNF grammar:
3644 Proxy-Info ::= < AVP Header: 284 >
3645 { Proxy-Host }
3646 { Proxy-State }
3648 * [ AVP ]
3650 6.7.3. Proxy-Host AVP
3652 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This
3653 AVP contains the identity of the host that added the Proxy-Info AVP.
3655 6.7.4. Proxy-State AVP
3657 The Proxy-State AVP (AVP Code 33) is of type OctetString. It
3658 contains state information that would otherwise be stored at the
3659 Diameter entity that created it. As such, this AVP MUST be treated
3660 as opaque data by entities other Diameter entities.
3662 6.8. Auth-Application-Id AVP
3664 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
3665 is used in order to advertise support of the Authentication and
3666 Authorization portion of an application (see Section 2.4). If
3667 present in a message other than CER and CEA, the value of the Auth-
3668 Application-Id AVP MUST match the Application Id present in the
3669 Diameter message header.
3671 6.9. Acct-Application-Id AVP
3673 The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
3674 is used in order to advertise support of the Accounting portion of an
3675 application (see Section 2.4). If present in a message other than
3676 CER and CEA, the value of the Acct-Application-Id AVP MUST match the
3677 Application Id present in the Diameter message header.
3679 6.10. Inband-Security-Id AVP
3681 The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
3682 is used in order to advertise support of the security portion of the
3683 application. The use of this AVP in CER and CEA messages has been
3684 deprecated. Instead, discovery of a Diameter entities security
3685 capabilities can be done either through static configuration or via
3686 Diameter Peer Discovery described in Section 5.2.
3688 The following values are supported:
3690 NO_INBAND_SECURITY 0
3692 This peer does not support TLS. This is the default value, if the
3693 AVP is omitted.
3695 TLS 1
3697 This node supports TLS security, as defined by [RFC4346].
3699 6.11. Vendor-Specific-Application-Id AVP
3701 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
3702 Grouped and is used to advertise support of a vendor-specific
3703 Diameter Application. Exactly one instance of either Auth-
3704 Application-Id or Acct-Application-Id AVP MUST be present. The
3705 Application Id carried by either Auth-Application-Id or Acct-
3706 Application-Id AVP MUST comply with vendor specific Application Id
3707 assignment described in Sec 11.3. It MUST also match the Application
3708 Id present in the Diameter header except when used in a CER or CEA
3709 messages.
3711 The Vendor-Id AVP is an informational AVP pertaining to the vendor
3712 who may have authorship of the vendor-specific Diameter application.
3713 It MUST NOT be used as a means of defining a completely separate
3714 vendor-specific Application Id space.
3716 The Vendor-Specific-Application-Id AVP SHOULD be placed as close to
3717 the Diameter header as possible.
3719 AVP Format
3721 ::= < AVP Header: 260 >
3722 { Vendor-Id }
3723 [ Auth-Application-Id ]
3724 [ Acct-Application-Id ]
3726 A Vendor-Specific-Application-Id AVP MUST contain exactly one of
3727 either Auth-Application-Id or Acct-Application-Id. If a Vendor-
3728 Specific-Application-Id is received without any of these two AVPs,
3729 then the recipient SHOULD issue an answer with a Result-Code set to
3730 DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP
3731 which MUST contain an example of an Auth-Application-Id AVP and an
3732 Acct-Application-Id AVP.
3734 If a Vendor-Specific-Application-Id is received that contains both
3735 Auth-Application-Id and Acct-Application-Id, then the recipient MUST
3736 issue an answer with Result-Code set to
3737 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a
3738 Failed-AVP which MUST contain the received Auth-Application-Id AVP
3739 and Acct-Application-Id AVP.
3741 6.12. Redirect-Host AVP
3743 One or more of instances of this AVP MUST be present if the answer
3744 message's 'E' bit is set and the Result-Code AVP is set to
3745 DIAMETER_REDIRECT_INDICATION.
3747 Upon receiving the above, the receiving Diameter node SHOULD forward
3748 the request directly to one of the hosts identified in these AVPs.
3749 The server contained in the selected Redirect-Host AVP SHOULD be used
3750 for all messages matching the criteria set by the Redirect-Host-Usage
3751 AVP.
3753 6.13. Redirect-Host-Usage AVP
3755 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
3756 This AVP MAY be present in answer messages whose 'E' bit is set and
3757 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
3759 When present, this AVP provides a hints about how the routing entry
3760 resulting from the Redirect-Host is to be used. The following values
3761 are supported:
3763 DONT_CACHE 0
3765 The host specified in the Redirect-Host AVP SHOULD NOT be cached.
3766 This is the default value.
3768 ALL_SESSION 1
3770 All messages within the same session, as defined by the same value
3771 of the Session-ID AVP SHOULD be sent to the host specified in the
3772 Redirect-Host AVP.
3774 ALL_REALM 2
3776 All messages destined for the realm requested SHOULD be sent to
3777 the host specified in the Redirect-Host AVP.
3779 REALM_AND_APPLICATION 3
3781 All messages for the application requested to the realm specified
3782 SHOULD be sent to the host specified in the Redirect-Host AVP.
3784 ALL_APPLICATION 4
3786 All messages for the application requested SHOULD be sent to the
3787 host specified in the Redirect-Host AVP.
3789 ALL_HOST 5
3791 All messages that would be sent to the host that generated the
3792 Redirect-Host SHOULD be sent to the host specified in the
3793 Redirect- Host AVP.
3795 ALL_USER 6
3797 All messages for the user requested SHOULD be sent to the host
3798 specified in the Redirect-Host AVP.
3800 When multiple cached routes are created by redirect indications and
3801 they differ only in redirect usage and peers to forward requests to
3802 (see Section 6.1.8), a precedence rule MUST be applied to the
3803 redirect usage values of the cached routes during normal routing to
3804 resolve contentions that may occur. The precedence rule is the order
3805 that dictate which redirect usage should be considered before any
3806 other as they appear. The order is as follows:
3808 1. ALL_SESSION
3810 2. ALL_USER
3812 3. REALM_AND_APPLICATION
3814 4. ALL_REALM
3816 5. ALL_APPLICATION
3818 6. ALL_HOST
3820 6.14. Redirect-Max-Cache-Time AVP
3822 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
3823 This AVP MUST be present in answer messages whose 'E' bit is set, the
3824 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the
3825 Redirect-Host-Usage AVP set to a non-zero value.
3827 This AVP contains the maximum number of seconds the peer and route
3828 table entries, created as a result of the Redirect-Host, SHOULD be
3829 cached. Note that once a host is no longer reachable, any associated
3830 cache, peer and routing table entries MUST be deleted.
3832 7. Error Handling
3834 There are two different types of errors in Diameter; protocol and
3835 application errors. A protocol error is one that occurs at the base
3836 protocol level, and MAY require per hop attention (e.g., message
3837 routing error). Application errors, on the other hand, generally
3838 occur due to a problem with a function specified in a Diameter
3839 application (e.g., user authentication, missing AVP).
3841 Result-Code AVP values that are used to report protocol errors MUST
3842 only be present in answer messages whose 'E' bit is set. When a
3843 request message is received that causes a protocol error, an answer
3844 message is returned with the 'E' bit set, and the Result-Code AVP is
3845 set to the appropriate protocol error value. As the answer is sent
3846 back towards the originator of the request, each proxy or relay agent
3847 MAY take action on the message.
3849 1. Request +---------+ Link Broken
3850 +-------------------------->|Diameter |----///----+
3851 | +---------------------| | v
3852 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+
3853 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
3854 | | | Home |
3855 | Relay 1 |--+ +---------+ | Server |
3856 +---------+ | 3. Request |Diameter | +--------+
3857 +-------------------->| | ^
3858 | Relay 3 |-----------+
3859 +---------+
3861 Figure 7: Example of Protocol Error causing answer message
3863 Figure 7 provides an example of a message forwarded upstream by a
3864 Diameter relay. When the message is received by Relay 2, and it
3865 detects that it cannot forward the request to the home server, an
3866 answer message is returned with the 'E' bit set and the Result-Code
3867 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls
3868 within the protocol error category, Relay 1 would take special
3869 action, and given the error, attempt to route the message through its
3870 alternate Relay 3.
3872 +---------+ 1. Request +---------+ 2. Request +---------+
3873 | Access |------------>|Diameter |------------>|Diameter |
3874 | | | | | Home |
3875 | Device |<------------| Relay |<------------| Server |
3876 +---------+ 4. Answer +---------+ 3. Answer +---------+
3877 (Missing AVP) (Missing AVP)
3879 Figure 8: Example of Application Error Answer message
3881 Figure 8 provides an example of a Diameter message that caused an
3882 application error. When application errors occur, the Diameter
3883 entity reporting the error clears the 'R' bit in the Command Flags,
3884 and adds the Result-Code AVP with the proper value. Application
3885 errors do not require any proxy or relay agent involvement, and
3886 therefore the message would be forwarded back to the originator of
3887 the request.
3889 In the case where the answer message itself contain an error(s), any
3890 related session SHOULD be terminated by sending an STR or ASR
3891 message. The Termination-Cause AVP in the STR MAY be filled with the
3892 appropriate value to inidcate the cause of the error. An application
3893 MAY also send an application specific request instead of STR or ASR
3894 to signal the error in the case where no state is maintained or to
3895 allow for some form of error recovery with the corresponding Diameter
3896 entity.
3898 There are certain Result-Code AVP application errors that require
3899 additional AVPs to be present in the answer. In these cases, the
3900 Diameter node that sets the Result-Code AVP to indicate the error
3901 MUST add the AVPs. Examples are:
3903 o A request with an unrecognized AVP is received with the 'M' bit
3904 (Mandatory bit) set, causes an answer to be sent with the Result-
3905 Code AVP set to DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP
3906 containing the offending AVP.
3908 o A request with an AVP that is received with an unrecognized value
3909 causes an answer to be returned with the Result-Code AVP set to
3910 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the
3911 AVP causing the error.
3913 o A command is received that is missing AVP(s) that are defined as
3914 required in the commands ABNF; examples are AVPs indicated as
3915 {AVP}. The receiver issues an answer with the Result-Code set to
3916 DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and
3917 other fields set as expected in the missing AVP. The created AVP
3918 is then added to the Failed- AVP AVP.
3920 The Result-Code AVP describes the error that the Diameter node
3921 encountered in its processing. In case there are multiple errors,
3922 the Diameter node MUST report only the first error it encountered
3923 (detected possibly in some implementation dependent order). The
3924 specific errors that can be described by this AVP are described in
3925 the following section.
3927 7.1. Result-Code AVP
3929 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
3930 indicates whether a particular request was completed successfully or
3931 whether an error occurred. All Diameter answer messages in IETF
3932 defined Diameter application specification MUST include one Result-
3933 Code AVP. A non-successful Result-Code AVP (one containing a non
3934 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the
3935 Error-Reporting-Host AVP if the host setting the Result-Code AVP is
3936 different from the identity encoded in the Origin-Host AVP.
3938 The Result-Code data field contains an IANA-managed 32-bit address
3939 space representing errors (see Section 11.4). Diameter provides the
3940 following classes of errors, all identified by the thousands digit in
3941 the decimal notation:
3943 o 1xxx (Informational)
3945 o 2xxx (Success)
3947 o 3xxx (Protocol Errors)
3949 o 4xxx (Transient Failures)
3951 o 5xxx (Permanent Failure)
3953 A non-recognized class (one whose first digit is not defined in this
3954 section) MUST be handled as a permanent failure.
3956 7.1.1. Informational
3958 Errors that fall within this category are used to inform the
3959 requester that a request could not be satisfied, and additional
3960 action is required on its part before access is granted.
3962 DIAMETER_MULTI_ROUND_AUTH 1001
3964 This informational error is returned by a Diameter server to
3965 inform the access device that the authentication mechanism being
3966 used requires multiple round trips, and a subsequent request needs
3967 to be issued in order for access to be granted.
3969 7.1.2. Success
3971 Errors that fall within the Success category are used to inform a
3972 peer that a request has been successfully completed.
3974 DIAMETER_SUCCESS 2001
3976 The request was successfully completed.
3978 DIAMETER_LIMITED_SUCCESS 2002
3980 When returned, the request was successfully completed, but
3981 additional processing is required by the application in order to
3982 provide service to the user.
3984 7.1.3. Protocol Errors
3986 Errors that fall within the Protocol Error category SHOULD be treated
3987 on a per-hop basis, and Diameter proxies MAY attempt to correct the
3988 error, if it is possible. Note that these errors MUST only be used
3989 in answer messages whose 'E' bit is set. This document omits some
3990 error codes defined in [RFC3588]. To provide backward compatibility
3991 with [RFC3588] implementations these error code values are not re-
3992 used and hence the error codes values enumerated below are non-
3993 sequential.
3995 DIAMETER_UNABLE_TO_DELIVER 3002
3997 This error is given when Diameter can not deliver the message to
3998 the destination, either because no host within the realm
3999 supporting the required application was available to process the
4000 request, or because Destination-Host AVP was given without the
4001 associated Destination-Realm AVP.
4003 DIAMETER_REALM_NOT_SERVED 3003
4005 The intended realm of the request is not recognized.
4007 DIAMETER_TOO_BUSY 3004
4009 When returned, a Diameter node SHOULD attempt to send the message
4010 to an alternate peer. This error MUST only be used when a
4011 specific server is requested, and it cannot provide the requested
4012 service.
4014 DIAMETER_LOOP_DETECTED 3005
4016 An agent detected a loop while trying to get the message to the
4017 intended recipient. The message MAY be sent to an alternate peer,
4018 if one is available, but the peer reporting the error has
4019 identified a configuration problem.
4021 DIAMETER_REDIRECT_INDICATION 3006
4023 A redirect agent has determined that the request could not be
4024 satisfied locally and the initiator of the request SHOULD direct
4025 the request directly to the server, whose contact information has
4026 been added to the response. When set, the Redirect-Host AVP MUST
4027 be present.
4029 DIAMETER_APPLICATION_UNSUPPORTED 3007
4031 A request was sent for an application that is not supported.
4033 DIAMETER_INVALID_BIT_IN_HEADER 3011
4035 This error is returned when a reserved bit in the Diameter header
4036 is set to one (1) or the bits in the Diameter header defined in
4037 Section 3 are set incorrectly.
4039 DIAMETER_INVALID_MESSAGE_LENGTH 3012
4041 This error is returned when a request is received with an invalid
4042 message length.
4044 7.1.4. Transient Failures
4046 Errors that fall within the transient failures category are used to
4047 inform a peer that the request could not be satisfied at the time it
4048 was received, but MAY be able to satisfy the request in the future.
4049 Note that these errors MUST be used in answer messages whose 'E' bit
4050 is not set.
4052 DIAMETER_AUTHENTICATION_REJECTED 4001
4054 The authentication process for the user failed, most likely due to
4055 an invalid password used by the user. Further attempts MUST only
4056 be tried after prompting the user for a new password.
4058 DIAMETER_OUT_OF_SPACE 4002
4060 A Diameter node received the accounting request but was unable to
4061 commit it to stable storage due to a temporary lack of space.
4063 ELECTION_LOST 4003
4065 The peer has determined that it has lost the election process and
4066 has therefore disconnected the transport connection.
4068 7.1.5. Permanent Failures
4070 Errors that fall within the permanent failures category are used to
4071 inform the peer that the request failed, and should not be attempted
4072 again. Note that these errors SHOULD be used in answer messages
4073 whose 'E' bit is not set. In error conditions where it is not
4074 possible or efficient to compose application specific answer grammar
4075 then answer messages with E-bit set and complying to the grammar
4076 described in 7.2 MAY also be used for permanent errors.
4078 To provide backward compatibility with existing implementations that
4079 follow [RFC3588], some of the error values that have previously been
4080 used in this category by [RFC3588] will not be re-used. Therefore
4081 the error values enumerated here maybe non-sequential.
4083 DIAMETER_AVP_UNSUPPORTED 5001
4085 The peer received a message that contained an AVP that is not
4086 recognized or supported and was marked with the Mandatory bit. A
4087 Diameter message with this error MUST contain one or more Failed-
4088 AVP AVP containing the AVPs that caused the failure.
4090 DIAMETER_UNKNOWN_SESSION_ID 5002
4092 The request contained an unknown Session-Id.
4094 DIAMETER_AUTHORIZATION_REJECTED 5003
4096 A request was received for which the user could not be authorized.
4097 This error could occur if the service requested is not permitted
4098 to the user.
4100 DIAMETER_INVALID_AVP_VALUE 5004
4102 The request contained an AVP with an invalid value in its data
4103 portion. A Diameter message indicating this error MUST include
4104 the offending AVPs within a Failed-AVP AVP.
4106 DIAMETER_MISSING_AVP 5005
4108 The request did not contain an AVP that is required by the Command
4109 Code definition. If this value is sent in the Result-Code AVP, a
4110 Failed-AVP AVP SHOULD be included in the message. The Failed-AVP
4111 AVP MUST contain an example of the missing AVP complete with the
4112 Vendor-Id if applicable. The value field of the missing AVP
4113 should be of correct minimum length and contain zeroes.
4115 DIAMETER_RESOURCES_EXCEEDED 5006
4117 A request was received that cannot be authorized because the user
4118 has already expended allowed resources. An example of this error
4119 condition is a user that is restricted to one dial-up PPP port,
4120 attempts to establish a second PPP connection.
4122 DIAMETER_CONTRADICTING_AVPS 5007
4124 The Home Diameter server has detected AVPs in the request that
4125 contradicted each other, and is not willing to provide service to
4126 the user. The Failed-AVP AVPs MUST be present which contains the
4127 AVPs that contradicted each other.
4129 DIAMETER_AVP_NOT_ALLOWED 5008
4131 A message was received with an AVP that MUST NOT be present. The
4132 Failed-AVP AVP MUST be included and contain a copy of the
4133 offending AVP.
4135 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
4137 A message was received that included an AVP that appeared more
4138 often than permitted in the message definition. The Failed-AVP
4139 AVP MUST be included and contain a copy of the first instance of
4140 the offending AVP that exceeded the maximum number of occurrences
4142 DIAMETER_NO_COMMON_APPLICATION 5010
4144 This error is returned by a Diameter node that receives a CER
4145 whereby no applications are common between the CER sending peer
4146 and the CER receiving peer.
4148 DIAMETER_UNSUPPORTED_VERSION 5011
4150 This error is returned when a request was received, whose version
4151 number is unsupported.
4153 DIAMETER_UNABLE_TO_COMPLY 5012
4155 This error is returned when a request is rejected for unspecified
4156 reasons.
4158 DIAMETER_INVALID_AVP_LENGTH 5014
4160 The request contained an AVP with an invalid length. A Diameter
4161 message indicating this error MUST include the offending AVPs
4162 within a Failed-AVP AVP. In cases where the erroneous avp length
4163 value exceeds the message length or is less than the minimum AVP
4164 header length, it is sufficient to include the offending AVP
4165 header and a zero filled payload of the minimum required length
4166 for the payloads data type. If the AVP is a grouped AVP, the
4167 grouped AVP header with an empty payload would be sufficient to
4168 indicate the offending AVP. In the case where the offending AVP
4169 header cannot be fully decoded when the AVP length is less than
4170 the minimum AVP header length, it is sufficient to include an
4171 offending AVP header that is formulated by padding the incomplete
4172 AVP header with zero up to the minimum AVP header length.
4174 DIAMETER_UNKNOWN_PEER 5018
4176 A CER was received from an unknown peer.
4178 DIAMETER_COMMAND_UNSUPPORTED 5019
4180 This error code is used when a Diameter entity receives a message
4181 with a Command Code that it does not support.
4183 DIAMETER_INVALID_HDR_BITS 5020
4185 A request was received whose bits in the Diameter header were
4186 either set to an invalid combination, or to a value that is
4187 inconsistent with the command code's definition.
4189 DIAMETER_INVALID_AVP_BITS 5021
4191 A request was received that included an AVP whose flag bits are
4192 set to an unrecognized value, or that is inconsistent with the
4193 AVP's definition.
4195 7.2. Error Bit
4197 The 'E' (Error Bit) in the Diameter header is set when the request
4198 caused a protocol-related error (see Section 7.1.3). A message with
4199 the 'E' bit MUST NOT be sent as a response to an answer message.
4200 Note that a message with the 'E' bit set is still subjected to the
4201 processing rules defined in Section 6.2. When set, the answer
4202 message will not conform to the ABNF specification for the command,
4203 and will instead conform to the following ABNF:
4205 Message Format
4207 ::= < Diameter Header: code, ERR [PXY] >
4208 0*1< Session-Id >
4209 { Origin-Host }
4210 { Origin-Realm }
4211 { Result-Code }
4212 [ Origin-State-Id ]
4213 [ Error-Message ]
4214 [ Error-Reporting-Host ]
4215 [ Failed-AVP ]
4216 * [ Proxy-Info ]
4217 * [ AVP ]
4219 Note that the code used in the header is the same than the one found
4220 in the request message, but with the 'R' bit cleared and the 'E' bit
4221 set. The 'P' bit in the header is set to the same value as the one
4222 found in the request message.
4224 7.3. Error-Message AVP
4226 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY
4227 accompany a Result-Code AVP as a human readable error message. The
4228 Error-Message AVP is not intended to be useful in an environment
4229 where error messages are processed automatically. It SHOULD NOT be
4230 expected that the content of this AVP is parsed by network entities.
4232 7.4. Error-Reporting-Host AVP
4234 The Error-Reporting-Host AVP (AVP Code 294) is of type
4235 DiameterIdentity. This AVP contains the identity of the Diameter
4236 host that sent the Result-Code AVP to a value other than 2001
4237 (Success), only if the host setting the Result-Code is different from
4238 the one encoded in the Origin-Host AVP. This AVP is intended to be
4239 used for troubleshooting purposes, and MUST be set when the Result-
4240 Code AVP indicates a failure.
4242 7.5. Failed-AVP AVP
4244 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
4245 debugging information in cases where a request is rejected or not
4246 fully processed due to erroneous information in a specific AVP. The
4247 value of the Result-Code AVP will provide information on the reason
4248 for the Failed-AVP AVP. A Diameter message SHOULD contain only one
4249 Failed-AVP that corresponds to the error indicated by the Result-Code
4250 AVP. For practical purposes, this Failed-AVP would typically refer
4251 to the first AVP processing error that a Diameter node encounters.
4253 The possible reasons for this AVP are the presence of an improperly
4254 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
4255 value, the omission of a required AVP, the presence of an explicitly
4256 excluded AVP (see tables in Section 10), or the presence of two or
4257 more occurrences of an AVP which is restricted to 0, 1, or 0-1
4258 occurrences.
4260 A Diameter message SHOULD contain one Failed-AVP AVP, containing the
4261 entire AVP that could not be processed successfully. If the failure
4262 reason is omission of a required AVP, an AVP with the missing AVP
4263 code, the missing vendor id, and a zero filled payload of the minimum
4264 required length for the omitted AVP will be added. If the failure
4265 reason is an invalid AVP length where the reported length is less
4266 than the minimum AVP header length or greater than the reported
4267 message length, a copy of the offending AVP header and a zero filled
4268 payload of the minimum required length SHOULD be added.
4270 In the case where the offending AVP is embedded within a grouped AVP,
4271 the Failed-AVP MAY contain the grouped AVP which in turn contains the
4272 single offending AVP. The same method MAY be employed if the grouped
4273 AVP itself is embedded in yet another grouped AVP and so on. In this
4274 case, the Failed-AVP MAY contain the grouped AVP heirarchy up to the
4275 single offending AVP. This enables the recipient to detect the
4276 location of the offending AVP when embedded in a group.
4278 AVP Format
4280 ::= < AVP Header: 279 >
4281 1* {AVP}
4283 7.6. Experimental-Result AVP
4285 The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
4286 indicates whether a particular vendor-specific request was completed
4287 successfully or whether an error occurred. This AVP has the
4288 following structure:
4290 AVP Format
4292 Experimental-Result ::= < AVP Header: 297 >
4293 { Vendor-Id }
4294 { Experimental-Result-Code }
4296 The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies
4297 the vendor responsible for the assignment of the result code which
4298 follows. All Diameter answer messages defined in vendor-specific
4299 applications MUST include either one Result-Code AVP or one
4300 Experimental-Result AVP.
4302 7.7. Experimental-Result-Code AVP
4304 The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32
4305 and contains a vendor-assigned value representing the result of
4306 processing the request.
4308 It is recommended that vendor-specific result codes follow the same
4309 conventions given for the Result-Code AVP regarding the different
4310 types of result codes and the handling of errors (for non 2xxx
4311 values).
4313 8. Diameter User Sessions
4315 In general, Diameter can provide two different types of services to
4316 applications. The first involves authentication and authorization,
4317 and can optionally make use of accounting. The second only makes use
4318 of accounting.
4320 When a service makes use of the authentication and/or authorization
4321 portion of an application, and a user requests access to the network,
4322 the Diameter client issues an auth request to its local server. The
4323 auth request is defined in a service specific Diameter application
4324 (e.g., NASREQ). The request contains a Session-Id AVP, which is used
4325 in subsequent messages (e.g., subsequent authorization, accounting,
4326 etc) relating to the user's session. The Session-Id AVP is a means
4327 for the client and servers to correlate a Diameter message with a
4328 user session.
4330 When a Diameter server authorizes a user to use network resources for
4331 a finite amount of time, and it is willing to extend the
4332 authorization via a future request, it MUST add the Authorization-
4333 Lifetime AVP to the answer message. The Authorization-Lifetime AVP
4334 defines the maximum number of seconds a user MAY make use of the
4335 resources before another authorization request is expected by the
4336 server. The Auth-Grace-Period AVP contains the number of seconds
4337 following the expiration of the Authorization-Lifetime, after which
4338 the server will release all state information related to the user's
4339 session. Note that if payment for services is expected by the
4340 serving realm from the user's home realm, the Authorization-Lifetime
4341 AVP, combined with the Auth-Grace-Period AVP, implies the maximum
4342 length of the session the home realm is willing to be fiscally
4343 responsible for. Services provided past the expiration of the
4344 Authorization-Lifetime and Auth-Grace-Period AVPs are the
4345 responsibility of the access device. Of course, the actual cost of
4346 services rendered is clearly outside the scope of the protocol.
4348 An access device that does not expect to send a re-authorization or a
4349 session termination request to the server MAY include the Auth-
4350 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
4351 to the server. If the server accepts the hint, it agrees that since
4352 no session termination message will be received once service to the
4353 user is terminated, it cannot maintain state for the session. If the
4354 answer message from the server contains a different value in the
4355 Auth-Session-State AVP (or the default value if the AVP is absent),
4356 the access device MUST follow the server's directives. Note that the
4357 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-
4358 authorization requests and answers.
4360 The base protocol does not include any authorization request
4361 messages, since these are largely application-specific and are
4362 defined in a Diameter application document. However, the base
4363 protocol does define a set of messages that are used to terminate
4364 user sessions. These are used to allow servers that maintain state
4365 information to free resources.
4367 When a service only makes use of the Accounting portion of the
4368 Diameter protocol, even in combination with an application, the
4369 Session-Id is still used to identify user sessions. However, the
4370 session termination messages are not used, since a session is
4371 signaled as being terminated by issuing an accounting stop message.
4373 Diameter may also be used for services that cannot be easily
4374 categorized as authentication, authorization or accounting (e.g.,
4375 certain 3GPP IMS interfaces). In such cases, the finite state
4376 machine defined in subsequent sections may not be applicable.
4377 Therefore, the applications itself MAY need to define its own finite
4378 state machine. However, such application specific state machines
4379 SHOULD follow the general state machine framework outlined in this
4380 document such as the use of Session-Id AVPs and the use of STR/STA,
4381 ASR/ASA messages for stateful sessions.
4383 8.1. Authorization Session State Machine
4385 This section contains a set of finite state machines, representing
4386 the life cycle of Diameter sessions, and which MUST be observed by
4387 all Diameter implementations that make use of the authentication
4388 and/or authorization portion of a Diameter application. The term
4389 Service-Specific below refers to a message defined in a Diameter
4390 application (e.g., Mobile IPv4, NASREQ).
4392 There are four different authorization session state machines
4393 supported in the Diameter base protocol. The first two describe a
4394 session in which the server is maintaining session state, indicated
4395 by the value of the Auth-Session-State AVP (or its absence). One
4396 describes the session from a client perspective, the other from a
4397 server perspective. The second two state machines are used when the
4398 server does not maintain session state. Here again, one describes
4399 the session from a client perspective, the other from a server
4400 perspective.
4402 When a session is moved to the Idle state, any resources that were
4403 allocated for the particular session must be released. Any event not
4404 listed in the state machines MUST be considered as an error
4405 condition, and an answer, if applicable, MUST be returned to the
4406 originator of the message.
4408 In the case that an application does not support re-auth, the state
4409 transitions related to server-initiated re-auth when both client and
4410 server sessions maintains state (e.g., Send RAR, Pending, Receive
4411 RAA) MAY be ignored.
4413 In the state table, the event 'Failure to send X' means that the
4414 Diameter agent is unable to send command X to the desired
4415 destination. This could be due to the peer being down, or due to the
4416 peer sending back a transient failure or temporary protocol error
4417 notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the
4418 Result-Code AVP of the corresponding Answer command. The event 'X
4419 successfully sent' is the complement of 'Failure to send X'.
4421 The following state machine is observed by a client when state is
4422 maintained on the server:
4424 CLIENT, STATEFUL
4425 State Event Action New State
4426 -------------------------------------------------------------
4427 Idle Client or Device Requests Send Pending
4428 access service
4429 specific
4430 auth req
4432 Idle ASR Received Send ASA Idle
4433 for unknown session with
4434 Result-Code
4435 = UNKNOWN_
4436 SESSION_ID
4438 Idle RAR Received Send RAA Idle
4439 for unknown session with
4440 Result-Code
4441 = UNKNOWN_
4442 SESSION_ID
4444 Pending Successful Service-specific Grant Open
4445 authorization answer Access
4446 received with default
4447 Auth-Session-State value
4449 Pending Successful Service-specific Sent STR Discon
4450 authorization answer received
4451 but service not provided
4453 Pending Error processing successful Sent STR Discon
4454 Service-specific authorization
4455 answer
4457 Pending Failed Service-specific Cleanup Idle
4458 authorization answer received
4460 Open User or client device Send Open
4461 requests access to service service
4462 specific
4463 auth req
4465 Open Successful Service-specific Provide Open
4466 authorization answer received Service
4468 Open Failed Service-specific Discon. Idle
4469 authorization answer user/device
4470 received.
4472 Open RAR received and client will Send RAA Open
4473 perform subsequent re-auth with
4474 Result-Code
4475 = SUCCESS
4477 Open RAR received and client will Send RAA Idle
4478 not perform subsequent with
4479 re-auth Result-Code
4480 != SUCCESS,
4481 Discon.
4482 user/device
4484 Open Session-Timeout Expires on Send STR Discon
4485 Access Device
4487 Open ASR Received, Send ASA Discon
4488 client will comply with with
4489 request to end the session Result-Code
4490 = SUCCESS,
4491 Send STR.
4493 Open ASR Received, Send ASA Open
4494 client will not comply with with
4495 request to end the session Result-Code
4496 != SUCCESS
4498 Open Authorization-Lifetime + Send STR Discon
4499 Auth-Grace-Period expires on
4500 access device
4502 Discon ASR Received Send ASA Discon
4504 Discon STA Received Discon. Idle
4505 user/device
4507 The following state machine is observed by a server when it is
4508 maintaining state for the session:
4510 SERVER, STATEFUL
4511 State Event Action New State
4512 -------------------------------------------------------------
4513 Idle Service-specific authorization Send Open
4514 request received, and successful
4515 user is authorized serv.
4516 specific
4517 answer
4519 Idle Service-specific authorization Send Idle
4520 request received, and failed serv.
4521 user is not authorized specific
4522 answer
4524 Open Service-specific authorization Send Open
4525 request received, and user successful
4526 is authorized serv. specific
4527 answer
4529 Open Service-specific authorization Send Idle
4530 request received, and user failed serv.
4531 is not authorized specific
4532 answer,
4533 Cleanup
4535 Open Home server wants to confirm Send RAR Pending
4536 authentication and/or
4537 authorization of the user
4539 Pending Received RAA with a failed Cleanup Idle
4540 Result-Code
4542 Pending Received RAA with Result-Code Update Open
4543 = SUCCESS session
4545 Open Home server wants to Send ASR Discon
4546 terminate the service
4548 Open Authorization-Lifetime (and Cleanup Idle
4549 Auth-Grace-Period) expires
4550 on home server.
4552 Open Session-Timeout expires on Cleanup Idle
4553 home server
4555 Discon Failure to send ASR Wait, Discon
4556 resend ASR
4558 Discon ASR successfully sent and Cleanup Idle
4559 ASA Received with Result-Code
4561 Not ASA Received None No Change.
4562 Discon
4564 Any STR Received Send STA, Idle
4565 Cleanup.
4567 The following state machine is observed by a client when state is not
4568 maintained on the server:
4570 CLIENT, STATELESS
4571 State Event Action New State
4572 -------------------------------------------------------------
4573 Idle Client or Device Requests Send Pending
4574 access service
4575 specific
4576 auth req
4578 Pending Successful Service-specific Grant Open
4579 authorization answer Access
4580 received with Auth-Session-
4581 State set to
4582 NO_STATE_MAINTAINED
4584 Pending Failed Service-specific Cleanup Idle
4585 authorization answer
4586 received
4588 Open Session-Timeout Expires on Discon. Idle
4589 Access Device user/device
4591 Open Service to user is terminated Discon. Idle
4592 user/device
4594 The following state machine is observed by a server when it is not
4595 maintaining state for the session:
4597 SERVER, STATELESS
4598 State Event Action New State
4599 -------------------------------------------------------------
4600 Idle Service-specific authorization Send serv. Idle
4601 request received, and specific
4602 successfully processed answer
4604 8.2. Accounting Session State Machine
4606 The following state machines MUST be supported for applications that
4607 have an accounting portion or that require only accounting services.
4608 The first state machine is to be observed by clients.
4610 See Section 9.7 for Accounting Command Codes and Section 9.8 for
4611 Accounting AVPs.
4613 The server side in the accounting state machine depends in some cases
4614 on the particular application. The Diameter base protocol defines a
4615 default state machine that MUST be followed by all applications that
4616 have not specified other state machines. This is the second state
4617 machine in this section described below.
4619 The default server side state machine requires the reception of
4620 accounting records in any order and at any time, and does not place
4621 any standards requirement on the processing of these records.
4622 Implementations of Diameter may perform checking, ordering,
4623 correlation, fraud detection, and other tasks based on these records.
4624 AVPs may need to be inspected as a part of these tasks. The tasks
4625 can happen either immediately after record reception or in a post-
4626 processing phase. However, as these tasks are typically application
4627 or even policy dependent, they are not standardized by the Diameter
4628 specifications. Applications MAY define requirements on when to
4629 accept accounting records based on the used value of Accounting-
4630 Realtime-Required AVP, credit limits checks, and so on.
4632 However, the Diameter base protocol defines one optional server side
4633 state machine that MAY be followed by applications that require
4634 keeping track of the session state at the accounting server. Note
4635 that such tracking is incompatible with the ability to sustain long
4636 duration connectivity problems. Therefore, the use of this state
4637 machine is recommended only in applications where the value of the
4638 Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence
4639 accounting connectivity problems are required to cause the serviced
4640 user to be disconnected. Otherwise, records produced by the client
4641 may be lost by the server which no longer accepts them after the
4642 connectivity is re-established. This state machine is the third
4643 state machine in this section. The state machine is supervised by a
4644 supervision session timer Ts, which the value should be reasonably
4645 higher than the Acct_Interim_Interval value. Ts MAY be set to two
4646 times the value of the Acct_Interim_Interval so as to avoid the
4647 accounting session in the Diameter server to change to Idle state in
4648 case of short transient network failure.
4650 Any event not listed in the state machines MUST be considered as an
4651 error condition, and a corresponding answer, if applicable, MUST be
4652 returned to the originator of the message.
4654 In the state table, the event 'Failure to send' means that the
4655 Diameter client is unable to communicate with the desired
4656 destination. This could be due to the peer being down, or due to the
4657 peer sending back a transient failure or temporary protocol error
4658 notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
4659 DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
4660 Answer command.
4662 The event 'Failed answer' means that the Diameter client received a
4663 non-transient failure notification in the Accounting Answer command.
4665 Note that the action 'Disconnect user/dev' MUST have an effect also
4666 to the authorization session state table, e.g., cause the STR message
4667 to be sent, if the given application has both authentication/
4668 authorization and accounting portions.
4670 The states PendingS, PendingI, PendingL, PendingE and PendingB stand
4671 for pending states to wait for an answer to an accounting request
4672 related to a Start, Interim, Stop, Event or buffered record,
4673 respectively.
4675 CLIENT, ACCOUNTING
4676 State Event Action New State
4677 -------------------------------------------------------------
4678 Idle Client or device requests Send PendingS
4679 access accounting
4680 start req.
4682 Idle Client or device requests Send PendingE
4683 a one-time service accounting
4684 event req
4686 Idle Records in storage Send PendingB
4687 record
4689 PendingS Successful accounting Open
4690 start answer received
4692 PendingS Failure to send and buffer Store Open
4693 space available and realtime Start
4694 not equal to DELIVER_AND_GRANT Record
4696 PendingS Failure to send and no buffer Open
4697 space available and realtime
4698 equal to GRANT_AND_LOSE
4700 PendingS Failure to send and no buffer Disconnect Idle
4701 space available and realtime user/dev
4702 not equal to
4703 GRANT_AND_LOSE
4705 PendingS Failed accounting start answer Open
4706 received and realtime equal
4707 to GRANT_AND_LOSE
4709 PendingS Failed accounting start answer Disconnect Idle
4710 received and realtime not user/dev
4711 equal to GRANT_AND_LOSE
4713 PendingS User service terminated Store PendingS
4714 stop
4715 record
4717 Open Interim interval elapses Send PendingI
4718 accounting
4719 interim
4720 record
4721 Open User service terminated Send PendingL
4722 accounting
4723 stop req.
4725 PendingI Successful accounting interim Open
4726 answer received
4728 PendingI Failure to send and (buffer Store Open
4729 space available or old record interim
4730 can be overwritten) and record
4731 realtime not equal to
4732 DELIVER_AND_GRANT
4734 PendingI Failure to send and no buffer Open
4735 space available and realtime
4736 equal to GRANT_AND_LOSE
4738 PendingI Failure to send and no buffer Disconnect Idle
4739 space available and realtime user/dev
4740 not equal to GRANT_AND_LOSE
4742 PendingI Failed accounting interim Open
4743 answer received and realtime
4744 equal to GRANT_AND_LOSE
4746 PendingI Failed accounting interim Disconnect Idle
4747 answer received and realtime user/dev
4748 not equal to GRANT_AND_LOSE
4750 PendingI User service terminated Store PendingI
4751 stop
4752 record
4753 PendingE Successful accounting Idle
4754 event answer received
4756 PendingE Failure to send and buffer Store Idle
4757 space available event
4758 record
4760 PendingE Failure to send and no buffer Idle
4761 space available
4763 PendingE Failed accounting event answer Idle
4764 received
4766 PendingB Successful accounting answer Delete Idle
4767 received record
4769 PendingB Failure to send Idle
4771 PendingB Failed accounting answer Delete Idle
4772 received record
4774 PendingL Successful accounting Idle
4775 stop answer received
4777 PendingL Failure to send and buffer Store Idle
4778 space available stop
4779 record
4781 PendingL Failure to send and no buffer Idle
4782 space available
4784 PendingL Failed accounting stop answer Idle
4785 received
4786 SERVER, STATELESS ACCOUNTING
4787 State Event Action New State
4788 -------------------------------------------------------------
4790 Idle Accounting start request Send Idle
4791 received, and successfully accounting
4792 processed. start
4793 answer
4795 Idle Accounting event request Send Idle
4796 received, and successfully accounting
4797 processed. event
4798 answer
4800 Idle Interim record received, Send Idle
4801 and successfully processed. accounting
4802 interim
4803 answer
4805 Idle Accounting stop request Send Idle
4806 received, and successfully accounting
4807 processed stop answer
4809 Idle Accounting request received, Send Idle
4810 no space left to store accounting
4811 records answer,
4812 Result-Code
4813 = OUT_OF_
4814 SPACE
4816 SERVER, STATEFUL ACCOUNTING
4817 State Event Action New State
4818 -------------------------------------------------------------
4820 Idle Accounting start request Send Open
4821 received, and successfully accounting
4822 processed. start
4823 answer,
4824 Start Ts
4826 Idle Accounting event request Send Idle
4827 received, and successfully accounting
4828 processed. event
4829 answer
4831 Idle Accounting request received, Send Idle
4832 no space left to store accounting
4833 records answer,
4834 Result-Code
4835 = OUT_OF_
4836 SPACE
4838 Open Interim record received, Send Open
4839 and successfully processed. accounting
4840 interim
4841 answer,
4842 Restart Ts
4844 Open Accounting stop request Send Idle
4845 received, and successfully accounting
4846 processed stop answer,
4847 Stop Ts
4849 Open Accounting request received, Send Idle
4850 no space left to store accounting
4851 records answer,
4852 Result-Code
4853 = OUT_OF_
4854 SPACE,
4855 Stop Ts
4857 Open Session supervision timer Ts Stop Ts Idle
4858 expired
4860 8.3. Server-Initiated Re-Auth
4862 A Diameter server may initiate a re-authentication and/or re-
4863 authorization service for a particular session by issuing a Re-Auth-
4864 Request (RAR).
4866 For example, for pre-paid services, the Diameter server that
4867 originally authorized a session may need some confirmation that the
4868 user is still using the services.
4870 An access device that receives a RAR message with Session-Id equal to
4871 a currently active session MUST initiate a re-auth towards the user,
4872 if the service supports this particular feature. Each Diameter
4873 application MUST state whether service-initiated re-auth is
4874 supported, since some applications do not allow access devices to
4875 prompt the user for re-auth.
4877 8.3.1. Re-Auth-Request
4879 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258
4880 and the message flags' 'R' bit set, may be sent by any server to the
4881 access device that is providing session service, to request that the
4882 user be re-authenticated and/or re-authorized.
4884 Message Format
4886 ::= < Diameter Header: 258, REQ, PXY >
4887 < Session-Id >
4888 { Origin-Host }
4889 { Origin-Realm }
4890 { Destination-Realm }
4891 { Destination-Host }
4892 { Auth-Application-Id }
4893 { Re-Auth-Request-Type }
4894 [ User-Name ]
4895 [ Origin-State-Id ]
4896 * [ Proxy-Info ]
4897 * [ Route-Record ]
4898 * [ AVP ]
4900 8.3.2. Re-Auth-Answer
4902 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258
4903 and the message flags' 'R' bit clear, is sent in response to the RAR.
4904 The Result-Code AVP MUST be present, and indicates the disposition of
4905 the request.
4907 A successful RAA message MUST be followed by an application-specific
4908 authentication and/or authorization message.
4910 Message Format
4912 ::= < Diameter Header: 258, PXY >
4913 < Session-Id >
4914 { Result-Code }
4915 { Origin-Host }
4916 { Origin-Realm }
4917 [ User-Name ]
4918 [ Origin-State-Id ]
4919 [ Error-Message ]
4920 [ Error-Reporting-Host ]
4921 [ Failed-AVP ]
4922 * [ Redirect-Host ]
4923 [ Redirect-Host-Usage ]
4924 [ Redirect-Max-Cache-Time ]
4925 * [ Proxy-Info ]
4926 * [ AVP ]
4928 8.4. Session Termination
4930 It is necessary for a Diameter server that authorized a session, for
4931 which it is maintaining state, to be notified when that session is no
4932 longer active, both for tracking purposes as well as to allow
4933 stateful agents to release any resources that they may have provided
4934 for the user's session. For sessions whose state is not being
4935 maintained, this section is not used.
4937 When a user session that required Diameter authorization terminates,
4938 the access device that provided the service MUST issue a Session-
4939 Termination-Request (STR) message to the Diameter server that
4940 authorized the service, to notify it that the session is no longer
4941 active. An STR MUST be issued when a user session terminates for any
4942 reason, including user logoff, expiration of Session-Timeout,
4943 administrative action, termination upon receipt of an Abort-Session-
4944 Request (see below), orderly shutdown of the access device, etc.
4946 The access device also MUST issue an STR for a session that was
4947 authorized but never actually started. This could occur, for
4948 example, due to a sudden resource shortage in the access device, or
4949 because the access device is unwilling to provide the type of service
4950 requested in the authorization, or because the access device does not
4951 support a mandatory AVP returned in the authorization, etc.
4953 It is also possible that a session that was authorized is never
4954 actually started due to action of a proxy. For example, a proxy may
4955 modify an authorization answer, converting the result from success to
4956 failure, prior to forwarding the message to the access device. If
4957 the answer did not contain an Auth-Session-State AVP with the value
4958 NO_STATE_MAINTAINED, a proxy that causes an authorized session not to
4959 be started MUST issue an STR to the Diameter server that authorized
4960 the session, since the access device has no way of knowing that the
4961 session had been authorized.
4963 A Diameter server that receives an STR message MUST clean up
4964 resources (e.g., session state) associated with the Session-Id
4965 specified in the STR, and return a Session-Termination-Answer.
4967 A Diameter server also MUST clean up resources when the Session-
4968 Timeout expires, or when the Authorization-Lifetime and the Auth-
4969 Grace-Period AVPs expires without receipt of a re-authorization
4970 request, regardless of whether an STR for that session is received.
4971 The access device is not expected to provide service beyond the
4972 expiration of these timers; thus, expiration of either of these
4973 timers implies that the access device may have unexpectedly shut
4974 down.
4976 8.4.1. Session-Termination-Request
4978 The Session-Termination-Request (STR), indicated by the Command-Code
4979 set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter
4980 client or by a Diameter proxy to inform the Diameter Server that an
4981 authenticated and/or authorized session is being terminated.
4983 Message Format
4985 ::= < Diameter Header: 275, REQ, PXY >
4986 < Session-Id >
4987 { Origin-Host }
4988 { Origin-Realm }
4989 { Destination-Realm }
4990 { Auth-Application-Id }
4991 { Termination-Cause }
4992 [ User-Name ]
4993 [ Destination-Host ]
4994 * [ Class ]
4995 [ Origin-State-Id ]
4996 * [ Proxy-Info ]
4997 * [ Route-Record ]
4998 * [ AVP ]
5000 8.4.2. Session-Termination-Answer
5002 The Session-Termination-Answer (STA), indicated by the Command-Code
5003 set to 275 and the message flags' 'R' bit clear, is sent by the
5004 Diameter Server to acknowledge the notification that the session has
5005 been terminated. The Result-Code AVP MUST be present, and MAY
5006 contain an indication that an error occurred while servicing the STR.
5008 Upon sending or receipt of the STA, the Diameter Server MUST release
5009 all resources for the session indicated by the Session-Id AVP. Any
5010 intermediate server in the Proxy-Chain MAY also release any
5011 resources, if necessary.
5013 Message Format
5015 ::= < Diameter Header: 275, PXY >
5016 < Session-Id >
5017 { Result-Code }
5018 { Origin-Host }
5019 { Origin-Realm }
5020 [ User-Name ]
5021 * [ Class ]
5022 [ Error-Message ]
5023 [ Error-Reporting-Host ]
5024 [ Failed-AVP ]
5025 [ Origin-State-Id ]
5026 * [ Redirect-Host ]
5027 [ Redirect-Host-Usage ]
5028 [ Redirect-Max-Cache-Time ]
5029 * [ Proxy-Info ]
5030 * [ AVP ]
5032 8.5. Aborting a Session
5034 A Diameter server may request that the access device stop providing
5035 service for a particular session by issuing an Abort-Session-Request
5036 (ASR).
5038 For example, the Diameter server that originally authorized the
5039 session may be required to cause that session to be stopped for lack
5040 of credit or other reasons that were not anticipated when the session
5041 was first authorized.
5043 An access device that receives an ASR with Session-ID equal to a
5044 currently active session MAY stop the session. Whether the access
5045 device stops the session or not is implementation- and/or
5046 configuration-dependent. For example, an access device may honor
5047 ASRs from certain agents only. In any case, the access device MUST
5048 respond with an Abort-Session-Answer, including a Result-Code AVP to
5049 indicate what action it took.
5051 8.5.1. Abort-Session-Request
5053 The Abort-Session-Request (ASR), indicated by the Command-Code set to
5054 274 and the message flags' 'R' bit set, may be sent by any Diameter
5055 server or any Diameter proxy to the access device that is providing
5056 session service, to request that the session identified by the
5057 Session-Id be stopped.
5059 Message Format
5061 ::= < Diameter Header: 274, REQ, PXY >
5062 < Session-Id >
5063 { Origin-Host }
5064 { Origin-Realm }
5065 { Destination-Realm }
5066 { Destination-Host }
5067 { Auth-Application-Id }
5068 [ User-Name ]
5069 [ Origin-State-Id ]
5070 * [ Proxy-Info ]
5071 * [ Route-Record ]
5072 * [ AVP ]
5074 8.5.2. Abort-Session-Answer
5076 The Abort-Session-Answer (ASA), indicated by the Command-Code set to
5077 274 and the message flags' 'R' bit clear, is sent in response to the
5078 ASR. The Result-Code AVP MUST be present, and indicates the
5079 disposition of the request.
5081 If the session identified by Session-Id in the ASR was successfully
5082 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
5083 is not currently active, Result-Code is set to
5084 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
5085 session for any other reason, Result-Code is set to
5086 DIAMETER_UNABLE_TO_COMPLY.
5088 Message Format
5090 ::= < Diameter Header: 274, PXY >
5091 < Session-Id >
5092 { Result-Code }
5093 { Origin-Host }
5094 { Origin-Realm }
5095 [ User-Name ]
5096 [ Origin-State-Id ]
5097 [ Error-Message ]
5098 [ Error-Reporting-Host ]
5099 [ Failed-AVP ]
5100 * [ Redirect-Host ]
5101 [ Redirect-Host-Usage ]
5102 [ Redirect-Max-Cache-Time ]
5103 * [ Proxy-Info ]
5104 * [ AVP ]
5106 8.6. Inferring Session Termination from Origin-State-Id
5108 The Origin-State-Id is used to allow detection of terminated sessions
5109 for which no STR would have been issued, due to unanticipated
5110 shutdown of an access device.
5112 A Diameter client or access device increments the value of the
5113 Origin-State-Id every time it is started or powered-up. The new
5114 Origin-State-Id is then sent in the CER/CEA message immediately upon
5115 connection to the server. The Diameter server receiving the new
5116 Origin-State-Id can determine whether the sending Diameter client had
5117 abrubtly shutdown by comparing the old value of the Origin-State-Id
5118 it has kept for that specific client is less than the new value and
5119 whether it has un-terminated sessions originating from that client.
5121 An access device can also include the Origin-State-Id in request
5122 messages other than CER if there are relays or proxies in between the
5123 access device and the server. In this case, however, the server
5124 cannot discover that the access device has been restarted unless and
5125 until it receives a new request from it. Therefore this mechanism is
5126 more opportunistic across proxies and relays.
5128 The Diameter server may assume that all sessions that were active
5129 prior to detection of a client restart have been terminated. The
5130 Diameter server MAY clean up all session state associated with such
5131 lost sessions, and MAY also issues STRs for all such lost sessions
5132 that were authorized on upstream servers, to allow session state to
5133 be cleaned up globally.
5135 8.7. Auth-Request-Type AVP
5137 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
5138 included in application-specific auth requests to inform the peers
5139 whether a user is to be authenticated only, authorized only or both.
5140 Note any value other than both MAY cause RADIUS interoperability
5141 issues. The following values are defined:
5143 AUTHENTICATE_ONLY 1
5145 The request being sent is for authentication only, and MUST
5146 contain the relevant application specific authentication AVPs that
5147 are needed by the Diameter server to authenticate the user.
5149 AUTHORIZE_ONLY 2
5151 The request being sent is for authorization only, and MUST contain
5152 the application specific authorization AVPs that are necessary to
5153 identify the service being requested/offered.
5155 AUTHORIZE_AUTHENTICATE 3
5157 The request contains a request for both authentication and
5158 authorization. The request MUST include both the relevant
5159 application specific authentication information, and authorization
5160 information necessary to identify the service being requested/
5161 offered.
5163 8.8. Session-Id AVP
5165 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
5166 to identify a specific session (see Section 8). All messages
5167 pertaining to a specific session MUST include only one Session-Id AVP
5168 and the same value MUST be used throughout the life of a session.
5169 When present, the Session-Id SHOULD appear immediately following the
5170 Diameter Header (see Section 3).
5172 The Session-Id MUST be globally and eternally unique, as it is meant
5173 to uniquely identify a user session without reference to any other
5174 information, and may be needed to correlate historical authentication
5175 information with accounting information. The Session-Id includes a
5176 mandatory portion and an implementation-defined portion; a
5177 recommended format for the implementation-defined portion is outlined
5178 below.
5180 The Session-Id MUST begin with the sender's identity encoded in the
5181 DiameterIdentity type (see Section 4.4). The remainder of the
5182 Session-Id is delimited by a ";" character, and MAY be any sequence
5183 that the client can guarantee to be eternally unique; however, the
5184 following format is recommended, (square brackets [] indicate an
5185 optional element):
5187 ;;[;]
5189 and are decimal representations of the
5190 high and low 32 bits of a monotonically increasing 64-bit value. The
5191 64-bit value is rendered in two part to simplify formatting by 32-bit
5192 processors. At startup, the high 32 bits of the 64-bit value MAY be
5193 initialized to the time in NTP format [RFC4330], and the low 32 bits
5194 MAY be initialized to zero. This will for practical purposes
5195 eliminate the possibility of overlapping Session-Ids after a reboot,
5196 assuming the reboot process takes longer than a second.
5197 Alternatively, an implementation MAY keep track of the increasing
5198 value in non-volatile memory.
5200 is implementation specific but may include a modem's
5201 device Id, a layer 2 address, timestamp, etc.
5203 Example, in which there is no optional value:
5205 accesspoint7.example.com;1876543210;523
5207 Example, in which there is an optional value:
5209 accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
5211 The Session-Id is created by the Diameter application initiating the
5212 session, which in most cases is done by the client. Note that a
5213 Session-Id MAY be used for both the authentication, authorization and
5214 accounting commands of a given application.
5216 8.9. Authorization-Lifetime AVP
5218 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
5219 and contains the maximum number of seconds of service to be provided
5220 to the user before the user is to be re-authenticated and/or re-
5221 authorized. Care should be taken when the Authorization- Lifetime
5222 value is determined, since a low, non-zero, value could create
5223 significant Diameter traffic, which could congest both the network
5224 and the agents.
5226 A value of zero (0) means that immediate re-auth is necessary by the
5227 access device. The absence of this AVP, or a value of all ones
5228 (meaning all bits in the 32 bit field are set to one) means no re-
5229 auth is expected.
5231 If both this AVP and the Session-Timeout AVP are present in a
5232 message, the value of the latter MUST NOT be smaller than the
5233 Authorization-Lifetime AVP.
5235 An Authorization-Lifetime AVP MAY be present in re-authorization
5236 messages, and contains the number of seconds the user is authorized
5237 to receive service from the time the re-auth answer message is
5238 received by the access device.
5240 This AVP MAY be provided by the client as a hint of the maximum
5241 lifetime that it is willing to accept. The server MUST return a
5242 value that is equal to, or smaller, than the one provided by the
5243 client.
5245 8.10. Auth-Grace-Period AVP
5247 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
5248 contains the number of seconds the Diameter server will wait
5249 following the expiration of the Authorization-Lifetime AVP before
5250 cleaning up resources for the session.
5252 8.11. Auth-Session-State AVP
5254 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
5255 specifies whether state is maintained for a particular session. The
5256 client MAY include this AVP in requests as a hint to the server, but
5257 the value in the server's answer message is binding. The following
5258 values are supported:
5260 STATE_MAINTAINED 0
5262 This value is used to specify that session state is being
5263 maintained, and the access device MUST issue a session termination
5264 message when service to the user is terminated. This is the
5265 default value.
5267 NO_STATE_MAINTAINED 1
5269 This value is used to specify that no session termination messages
5270 will be sent by the access device upon expiration of the
5271 Authorization-Lifetime.
5273 8.12. Re-Auth-Request-Type AVP
5275 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
5276 is included in application-specific auth answers to inform the client
5277 of the action expected upon expiration of the Authorization-Lifetime.
5278 If the answer message contains an Authorization-Lifetime AVP with a
5279 positive value, the Re-Auth-Request-Type AVP MUST be present in an
5280 answer message. The following values are defined:
5282 AUTHORIZE_ONLY 0
5284 An authorization only re-auth is expected upon expiration of the
5285 Authorization-Lifetime. This is the default value if the AVP is
5286 not present in answer messages that include the Authorization-
5287 Lifetime.
5289 AUTHORIZE_AUTHENTICATE 1
5291 An authentication and authorization re-auth is expected upon
5292 expiration of the Authorization-Lifetime.
5294 8.13. Session-Timeout AVP
5296 The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32
5297 and contains the maximum number of seconds of service to be provided
5298 to the user before termination of the session. When both the
5299 Session-Timeout and the Authorization-Lifetime AVPs are present in an
5300 answer message, the former MUST be equal to or greater than the value
5301 of the latter.
5303 A session that terminates on an access device due to the expiration
5304 of the Session-Timeout MUST cause an STR to be issued, unless both
5305 the access device and the home server had previously agreed that no
5306 session termination messages would be sent (see Section 8.11).
5308 A Session-Timeout AVP MAY be present in a re-authorization answer
5309 message, and contains the remaining number of seconds from the
5310 beginning of the re-auth.
5312 A value of zero, or the absence of this AVP, means that this session
5313 has an unlimited number of seconds before termination.
5315 This AVP MAY be provided by the client as a hint of the maximum
5316 timeout that it is willing to accept. However, the server MAY return
5317 a value that is equal to, or smaller, than the one provided by the
5318 client.
5320 8.14. User-Name AVP
5322 The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which
5323 contains the User-Name, in a format consistent with the NAI
5324 specification [RFC4282].
5326 8.15. Termination-Cause AVP
5328 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
5329 is used to indicate the reason why a session was terminated on the
5330 access device. The following values are defined:
5332 DIAMETER_LOGOUT 1
5334 The user initiated a disconnect
5336 DIAMETER_SERVICE_NOT_PROVIDED 2
5338 This value is used when the user disconnected prior to the receipt
5339 of the authorization answer message.
5341 DIAMETER_BAD_ANSWER 3
5343 This value indicates that the authorization answer received by the
5344 access device was not processed successfully.
5346 DIAMETER_ADMINISTRATIVE 4
5348 The user was not granted access, or was disconnected, due to
5349 administrative reasons, such as the receipt of a Abort-Session-
5350 Request message.
5352 DIAMETER_LINK_BROKEN 5
5354 The communication to the user was abruptly disconnected.
5356 DIAMETER_AUTH_EXPIRED 6
5358 The user's access was terminated since its authorized session time
5359 has expired.
5361 DIAMETER_USER_MOVED 7
5363 The user is receiving services from another access device.
5365 DIAMETER_SESSION_TIMEOUT 8
5367 The user's session has timed out, and service has been terminated.
5369 8.16. Origin-State-Id AVP
5371 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a
5372 monotonically increasing value that is advanced whenever a Diameter
5373 entity restarts with loss of previous state, for example upon reboot.
5374 Origin-State-Id MAY be included in any Diameter message, including
5375 CER.
5377 A Diameter entity issuing this AVP MUST create a higher value for
5378 this AVP each time its state is reset. A Diameter entity MAY set
5379 Origin-State-Id to the time of startup, or it MAY use an incrementing
5380 counter retained in non-volatile memory across restarts.
5382 The Origin-State-Id, if present, MUST reflect the state of the entity
5383 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST
5384 either remove Origin-State-Id or modify it appropriately as well.
5385 Typically, Origin-State-Id is used by an access device that always
5386 starts up with no active sessions; that is, any session active prior
5387 to restart will have been lost. By including Origin-State-Id in a
5388 message, it allows other Diameter entities to infer that sessions
5389 associated with a lower Origin-State-Id are no longer active. If an
5390 access device does not intend for such inferences to be made, it MUST
5391 either not include Origin-State-Id in any message, or set its value
5392 to 0.
5394 8.17. Session-Binding AVP
5396 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
5397 be present in application-specific authorization answer messages. If
5398 present, this AVP MAY inform the Diameter client that all future
5399 application-specific re-auth and Session-Termination-Request messages
5400 for this session MUST be sent to the same authorization server.
5402 This field is a bit mask, and the following bits have been defined:
5404 RE_AUTH 1
5406 When set, future re-auth messages for this session MUST NOT
5407 include the Destination-Host AVP. When cleared, the default
5408 value, the Destination-Host AVP MUST be present in all re-auth
5409 messages for this session.
5411 STR 2
5413 When set, the STR message for this session MUST NOT include the
5414 Destination-Host AVP. When cleared, the default value, the
5415 Destination-Host AVP MUST be present in the STR message for this
5416 session.
5418 ACCOUNTING 4
5420 When set, all accounting messages for this session MUST NOT
5421 include the Destination-Host AVP. When cleared, the default
5422 value, the Destination-Host AVP, if known, MUST be present in all
5423 accounting messages for this session.
5425 8.18. Session-Server-Failover AVP
5427 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated,
5428 and MAY be present in application-specific authorization answer
5429 messages that either do not include the Session-Binding AVP or
5430 include the Session-Binding AVP with any of the bits set to a zero
5431 value. If present, this AVP MAY inform the Diameter client that if a
5432 re-auth or STR message fails due to a delivery problem, the Diameter
5433 client SHOULD issue a subsequent message without the Destination-Host
5434 AVP. When absent, the default value is REFUSE_SERVICE.
5436 The following values are supported:
5438 REFUSE_SERVICE 0
5440 If either the re-auth or the STR message delivery fails, terminate
5441 service with the user, and do not attempt any subsequent attempts.
5443 TRY_AGAIN 1
5445 If either the re-auth or the STR message delivery fails, resend
5446 the failed message without the Destination-Host AVP present.
5448 ALLOW_SERVICE 2
5450 If re-auth message delivery fails, assume that re-authorization
5451 succeeded. If STR message delivery fails, terminate the session.
5453 TRY_AGAIN_ALLOW_SERVICE 3
5455 If either the re-auth or the STR message delivery fails, resend
5456 the failed message without the Destination-Host AVP present. If
5457 the second delivery fails for re-auth, assume re-authorization
5458 succeeded. If the second delivery fails for STR, terminate the
5459 session.
5461 8.19. Multi-Round-Time-Out AVP
5463 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32,
5464 and SHOULD be present in application-specific authorization answer
5465 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
5466 This AVP contains the maximum number of seconds that the access
5467 device MUST provide the user in responding to an authentication
5468 request.
5470 8.20. Class AVP
5472 The Class AVP (AVP Code 25) is of type OctetString and is used by
5473 Diameter servers to return state information to the access device.
5474 When one or more Class AVPs are present in application-specific
5475 authorization answer messages, they MUST be present in subsequent re-
5476 authorization, session termination and accounting messages. Class
5477 AVPs found in a re-authorization answer message override the ones
5478 found in any previous authorization answer message. Diameter server
5479 implementations SHOULD NOT return Class AVPs that require more than
5480 4096 bytes of storage on the Diameter client. A Diameter client that
5481 receives Class AVPs whose size exceeds local available storage MUST
5482 terminate the session.
5484 8.21. Event-Timestamp AVP
5486 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be
5487 included in an Accounting-Request and Accounting-Answer messages to
5488 record the time that the reported event occurred, in seconds since
5489 January 1, 1900 00:00 UTC.
5491 9. Accounting
5493 This accounting protocol is based on a server directed model with
5494 capabilities for real-time delivery of accounting information.
5495 Several fault resilience methods [RFC2975] have been built in to the
5496 protocol in order minimize loss of accounting data in various fault
5497 situations and under different assumptions about the capabilities of
5498 the used devices.
5500 9.1. Server Directed Model
5502 The server directed model means that the device generating the
5503 accounting data gets information from either the authorization server
5504 (if contacted) or the accounting server regarding the way accounting
5505 data shall be forwarded. This information includes accounting record
5506 timeliness requirements.
5508 As discussed in [RFC2975], real-time transfer of accounting records
5509 is a requirement, such as the need to perform credit limit checks and
5510 fraud detection. Note that batch accounting is not a requirement,
5511 and is therefore not supported by Diameter. Should batched
5512 accounting be required in the future, a new Diameter application will
5513 need to be created, or it could be handled using another protocol.
5514 Note, however, that even if at the Diameter layer accounting requests
5515 are processed one by one, transport protocols used under Diameter
5516 typically batch several requests in the same packet under heavy
5517 traffic conditions. This may be sufficient for many applications.
5519 The authorization server (chain) directs the selection of proper
5520 transfer strategy, based on its knowledge of the user and
5521 relationships of roaming partnerships. The server (or agents) uses
5522 the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
5523 control the operation of the Diameter peer operating as a client.
5524 The Acct-Interim-Interval AVP, when present, instructs the Diameter
5525 node acting as a client to produce accounting records continuously
5526 even during a session. Accounting-Realtime-Required AVP is used to
5527 control the behavior of the client when the transfer of accounting
5528 records from the Diameter client is delayed or unsuccessful.
5530 The Diameter accounting server MAY override the interim interval or
5531 the realtime requirements by including the Acct-Interim-Interval or
5532 Accounting-Realtime-Required AVP in the Accounting-Answer message.
5533 When one of these AVPs is present, the latest value received SHOULD
5534 be used in further accounting activities for the same session.
5536 9.2. Protocol Messages
5538 A Diameter node that receives a successful authentication and/or
5539 authorization messages from the Diameter server SHOULD collect
5540 accounting information for the session. The Accounting-Request
5541 message is used to transmit the accounting information to the
5542 Diameter server, which MUST reply with the Accounting-Answer message
5543 to confirm reception. The Accounting-Answer message includes the
5544 Result-Code AVP, which MAY indicate that an error was present in the
5545 accounting message. The value of the Accounting-Realtime-Required
5546 AVP received earlier for the session in question may indicate that
5547 the user's session has to be terminated when a rejected Accounting-
5548 Request message was received.
5550 9.3. Accounting Application Extension and Requirements
5552 Each Diameter application (e.g., NASREQ, MobileIP), SHOULD define
5553 their Service-Specific AVPs that MUST be present in the Accounting-
5554 Request message in a section entitled "Accounting AVPs". The
5555 application MUST assume that the AVPs described in this document will
5556 be present in all Accounting messages, so only their respective
5557 service-specific AVPs need to be defined in that section.
5559 Applications have the option of using one or both of the following
5560 accounting application extension models:
5562 Split Accounting Service
5564 The accounting message will carry the Application Id of the
5565 Diameter base accounting application (see Section 2.4).
5566 Accounting messages maybe routed to Diameter nodes other than the
5567 corresponding Diameter application. These nodes might be
5568 centralized accounting servers that provide accounting service for
5569 multiple different Diameter applications. These nodes MUST
5570 advertise the Diameter base accounting Application Id during
5571 capabilities exchange.
5573 Coupled Accounting Service
5575 The accounting messages will carry the Application Id of the
5576 application that is using it. The application itself will process
5577 the received accounting records or forward them to an accounting
5578 server. There is no accounting application advertisement required
5579 during capabilities exchange and the accounting messages will be
5580 routed the same as any of the other application messages.
5582 In cases where an application does not define its own accounting
5583 service, it is preferred that the split accounting model be used.
5585 9.4. Fault Resilience
5587 Diameter Base protocol mechanisms are used to overcome small message
5588 loss and network faults of temporary nature.
5590 Diameter peers acting as clients MUST implement the use of failover
5591 to guard against server failures and certain network failures.
5592 Diameter peers acting as agents or related off-line processing
5593 systems MUST detect duplicate accounting records caused by the
5594 sending of same record to several servers and duplication of messages
5595 in transit. This detection MUST be based on the inspection of the
5596 Session-Id and Accounting-Record-Number AVP pairs. Appendix C
5597 discusses duplicate detection needs and implementation issues.
5599 Diameter clients MAY have non-volatile memory for the safe storage of
5600 accounting records over reboots or extended network failures, network
5601 partitions, and server failures. If such memory is available, the
5602 client SHOULD store new accounting records there as soon as the
5603 records are created and until a positive acknowledgement of their
5604 reception from the Diameter Server has been received. Upon a reboot,
5605 the client MUST starting sending the records in the non-volatile
5606 memory to the accounting server with appropriate modifications in
5607 termination cause, session length, and other relevant information in
5608 the records.
5610 A further application of this protocol may include AVPs to control
5611 how many accounting records may at most be stored in the Diameter
5612 client without committing them to the non-volatile memory or
5613 transferring them to the Diameter server.
5615 The client SHOULD NOT remove the accounting data from any of its
5616 memory areas before the correct Accounting-Answer has been received.
5617 The client MAY remove oldest, undelivered or yet unacknowledged
5618 accounting data if it runs out of resources such as memory. It is an
5619 implementation dependent matter for the client to accept new sessions
5620 under this condition.
5622 9.5. Accounting Records
5624 In all accounting records, the Session-Id AVP MUST be present; the
5625 User-Name AVP MUST be present if it is available to the Diameter
5626 client.
5628 Different types of accounting records are sent depending on the
5629 actual type of accounted service and the authorization server's
5630 directions for interim accounting. If the accounted service is a
5631 one-time event, meaning that the start and stop of the event are
5632 simultaneous, then the Accounting-Record-Type AVP MUST be present and
5633 set to the value EVENT_RECORD.
5635 If the accounted service is of a measurable length, then the AVP MUST
5636 use the values START_RECORD, STOP_RECORD, and possibly,
5637 INTERIM_RECORD. If the authorization server has not directed interim
5638 accounting to be enabled for the session, two accounting records MUST
5639 be generated for each service of type session. When the initial
5640 Accounting-Request for a given session is sent, the Accounting-
5641 Record-Type AVP MUST be set to the value START_RECORD. When the last
5642 Accounting-Request is sent, the value MUST be STOP_RECORD.
5644 If the authorization server has directed interim accounting to be
5645 enabled, the Diameter client MUST produce additional records between
5646 the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
5647 production of these records is directed by Acct-Interim-Interval as
5648 well as any re-authentication or re-authorization of the session.
5649 The Diameter client MUST overwrite any previous interim accounting
5650 records that are locally stored for delivery, if a new record is
5651 being generated for the same session. This ensures that only one
5652 pending interim record can exist on an access device for any given
5653 session.
5655 A particular value of Accounting-Sub-Session-Id MUST appear only in
5656 one sequence of accounting records from a DIAMETER client, except for
5657 the purposes of retransmission. The one sequence that is sent MUST
5658 be either one record with Accounting-Record-Type AVP set to the value
5659 EVENT_RECORD, or several records starting with one having the value
5660 START_RECORD, followed by zero or more INTERIM_RECORD and a single
5661 STOP_RECORD. A particular Diameter application specification MUST
5662 define the type of sequences that MUST be used.
5664 9.6. Correlation of Accounting Records
5666 If an application uses accounting messages, it can correlate
5667 accounting records with a specific application session by using the
5668 Session-Id of the particular application session in the accounting
5669 messages. Accounting messages MAY also use a different Session-Id
5670 from that of the application sessions in which case other session
5671 related information is needed to perform correlation.
5673 In cases where an application requires multiple accounting sub-
5674 session, an Accounting-Sub-Session-Id AVP is used to differentiate
5675 each sub-session. The Session-Id would remain constant for all sub-
5676 sessions and is be used to correlate all the sub-sessions to a
5677 particular application session. Note that receiving a STOP_RECORD
5678 with no Accounting-Sub-Session-Id AVP when sub-sessions were
5679 originally used in the START_RECORD messages implies that all sub-
5680 sessions are terminated.
5682 There are also cases where an application needs to correlate multiple
5683 application sessions into a single accounting record; the accounting
5684 record may span multiple different Diameter applications and sessions
5685 used by the same user at a given time. In such cases, the Acct-
5686 Multi-Session- Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD
5687 be signalled by the server to the access device (typically during
5688 authorization) when it determines that a request belongs to an
5689 existing session. The access device MUST then include the Acct-
5690 Multi-Session-Id AVP in all subsequent accounting messages.
5692 The Acct-Multi-Session-Id AVP MAY include the value of the original
5693 Session-Id. It's contents are implementation specific, but MUST be
5694 globally unique across other Acct-Multi-Session-Id, and MUST NOT
5695 change during the life of a session.
5697 A Diameter application document MUST define the exact concept of a
5698 session that is being accounted, and MAY define the concept of a
5699 multi-session. For instance, the NASREQ DIAMETER application treats
5700 a single PPP connection to a Network Access Server as one session,
5701 and a set of Multilink PPP sessions as one multi-session.
5703 9.7. Accounting Command-Codes
5705 This section defines Command-Code values that MUST be supported by
5706 all Diameter implementations that provide Accounting services.
5708 9.7.1. Accounting-Request
5710 The Accounting-Request (ACR) command, indicated by the Command-Code
5711 field set to 271 and the Command Flags' 'R' bit set, is sent by a
5712 Diameter node, acting as a client, in order to exchange accounting
5713 information with a peer.
5715 The AVP listed below SHOULD include service specific accounting AVPs,
5716 as described in Section 9.3.
5718 Message Format
5720 ::= < Diameter Header: 271, REQ, PXY >
5721 < Session-Id >
5722 { Origin-Host }
5723 { Origin-Realm }
5724 { Destination-Realm }
5725 { Accounting-Record-Type }
5726 { Accounting-Record-Number }
5727 [ Acct-Application-Id ]
5728 [ Vendor-Specific-Application-Id ]
5729 [ User-Name ]
5730 [ Destination-Host ]
5731 [ Accounting-Sub-Session-Id ]
5732 [ Acct-Session-Id ]
5733 [ Acct-Multi-Session-Id ]
5734 [ Acct-Interim-Interval ]
5735 [ Accounting-Realtime-Required ]
5736 [ Origin-State-Id ]
5737 [ Event-Timestamp ]
5738 * [ Proxy-Info ]
5739 * [ Route-Record ]
5740 * [ AVP ]
5742 9.7.2. Accounting-Answer
5744 The Accounting-Answer (ACA) command, indicated by the Command-Code
5745 field set to 271 and the Command Flags' 'R' bit cleared, is used to
5746 acknowledge an Accounting-Request command. The Accounting-Answer
5747 command contains the same Session-Id as the corresponding request.
5749 Only the target Diameter Server, known as the home Diameter Server,
5750 SHOULD respond with the Accounting-Answer command.
5752 The AVP listed below SHOULD include service specific accounting AVPs,
5753 as described in Section 9.3.
5755 Message Format
5757 ::= < Diameter Header: 271, PXY >
5758 < Session-Id >
5759 { Result-Code }
5760 { Origin-Host }
5761 { Origin-Realm }
5762 { Accounting-Record-Type }
5763 { Accounting-Record-Number }
5764 [ Acct-Application-Id ]
5765 [ Vendor-Specific-Application-Id ]
5766 [ User-Name ]
5767 [ Accounting-Sub-Session-Id ]
5768 [ Acct-Session-Id ]
5769 [ Acct-Multi-Session-Id ]
5770 [ Error-Message ]
5771 [ Error-Reporting-Host ]
5772 [ Failed-AVP ]
5773 [ Acct-Interim-Interval ]
5774 [ Accounting-Realtime-Required ]
5775 [ Origin-State-Id ]
5776 [ Event-Timestamp ]
5777 * [ Proxy-Info ]
5778 * [ AVP ]
5780 9.8. Accounting AVPs
5782 This section contains AVPs that describe accounting usage information
5783 related to a specific session.
5785 9.8.1. Accounting-Record-Type AVP
5787 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
5788 and contains the type of accounting record being sent. The following
5789 values are currently defined for the Accounting-Record-Type AVP:
5791 EVENT_RECORD 1
5793 An Accounting Event Record is used to indicate that a one-time
5794 event has occurred (meaning that the start and end of the event
5795 are simultaneous). This record contains all information relevant
5796 to the service, and is the only record of the service.
5798 START_RECORD 2
5800 An Accounting Start, Interim, and Stop Records are used to
5801 indicate that a service of a measurable length has been given. An
5802 Accounting Start Record is used to initiate an accounting session,
5803 and contains accounting information that is relevant to the
5804 initiation of the session.
5806 INTERIM_RECORD 3
5808 An Interim Accounting Record contains cumulative accounting
5809 information for an existing accounting session. Interim
5810 Accounting Records SHOULD be sent every time a re-authentication
5811 or re-authorization occurs. Further, additional interim record
5812 triggers MAY be defined by application-specific Diameter
5813 applications. The selection of whether to use INTERIM_RECORD
5814 records is done by the Acct-Interim-Interval AVP.
5816 STOP_RECORD 4
5818 An Accounting Stop Record is sent to terminate an accounting
5819 session and contains cumulative accounting information relevant to
5820 the existing session.
5822 9.8.2. Acct-Interim-Interval AVP
5824 The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
5825 is sent from the Diameter home authorization server to the Diameter
5826 client. The client uses information in this AVP to decide how and
5827 when to produce accounting records. With different values in this
5828 AVP, service sessions can result in one, two, or two+N accounting
5829 records, based on the needs of the home-organization. The following
5830 accounting record production behavior is directed by the inclusion of
5831 this AVP:
5833 1. The omission of the Acct-Interim-Interval AVP or its inclusion
5834 with Value field set to 0 means that EVENT_RECORD, START_RECORD,
5835 and STOP_RECORD are produced, as appropriate for the service.
5837 2. The inclusion of the AVP with Value field set to a non-zero value
5838 means that INTERIM_RECORD records MUST be produced between the
5839 START_RECORD and STOP_RECORD records. The Value field of this
5840 AVP is the nominal interval between these records in seconds.
5842 The Diameter node that originates the accounting information,
5843 known as the client, MUST produce the first INTERIM_RECORD record
5844 roughly at the time when this nominal interval has elapsed from
5845 the START_RECORD, the next one again as the interval has elapsed
5846 once more, and so on until the session ends and a STOP_RECORD
5847 record is produced.
5849 The client MUST ensure that the interim record production times
5850 are randomized so that large accounting message storms are not
5851 created either among records or around a common service start
5852 time.
5854 9.8.3. Accounting-Record-Number AVP
5856 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
5857 and identifies this record within one session. As Session-Id AVPs
5858 are globally unique, the combination of Session-Id and Accounting-
5859 Record-Number AVPs is also globally unique, and can be used in
5860 matching accounting records with confirmations. An easy way to
5861 produce unique numbers is to set the value to 0 for records of type
5862 EVENT_RECORD and START_RECORD, and set the value to 1 for the first
5863 INTERIM_RECORD, 2 for the second, and so on until the value for
5864 STOP_RECORD is one more than for the last INTERIM_RECORD.
5866 9.8.4. Acct-Session-Id AVP
5868 The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only
5869 used when RADIUS/Diameter translation occurs. This AVP contains the
5870 contents of the RADIUS Acct-Session-Id attribute.
5872 9.8.5. Acct-Multi-Session-Id AVP
5874 The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
5875 following the format specified in Section 8.8. The Acct-Multi-
5876 Session-Id AVP is used to link together multiple related accounting
5877 sessions, where each session would have a unique Session-Id, but the
5878 same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the
5879 Diameter server in an authorization answer, and MUST be used in all
5880 accounting messages for the given session.
5882 9.8.6. Accounting-Sub-Session-Id AVP
5884 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
5885 Unsigned64 and contains the accounting sub-session identifier. The
5886 combination of the Session-Id and this AVP MUST be unique per sub-
5887 session, and the value of this AVP MUST be monotonically increased by
5888 one for all new sub-sessions. The absence of this AVP implies no
5889 sub-sessions are in use, with the exception of an Accounting-Request
5890 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
5891 message with no Accounting-Sub-Session-Id AVP present will signal the
5892 termination of all sub-sessions for a given Session-Id.
5894 9.8.7. Accounting-Realtime-Required AVP
5896 The Accounting-Realtime-Required AVP (AVP Code 483) is of type
5897 Enumerated and is sent from the Diameter home authorization server to
5898 the Diameter client or in the Accounting-Answer from the accounting
5899 server. The client uses information in this AVP to decide what to do
5900 if the sending of accounting records to the accounting server has
5901 been temporarily prevented due to, for instance, a network problem.
5903 DELIVER_AND_GRANT 1
5905 The AVP with Value field set to DELIVER_AND_GRANT means that the
5906 service MUST only be granted as long as there is a connection to
5907 an accounting server. Note that the set of alternative accounting
5908 servers are treated as one server in this sense. Having to move
5909 the accounting record stream to a backup server is not a reason to
5910 discontinue the service to the user.
5912 GRANT_AND_STORE 2
5914 The AVP with Value field set to GRANT_AND_STORE means that service
5915 SHOULD be granted if there is a connection, or as long as records
5916 can still be stored as described in Section 9.4.
5918 This is the default behavior if the AVP isn't included in the
5919 reply from the authorization server.
5921 GRANT_AND_LOSE 3
5923 The AVP with Value field set to GRANT_AND_LOSE means that service
5924 SHOULD be granted even if the records can not be delivered or
5925 stored.
5927 10. AVP Occurrence Table
5929 The following tables presents the AVPs defined in this document, and
5930 specifies in which Diameter messages they MAY be present or not.
5931 AVPs that occur only inside a Grouped AVP are not shown in this
5932 table.
5934 The table uses the following symbols:
5936 0 The AVP MUST NOT be present in the message.
5938 0+ Zero or more instances of the AVP MAY be present in the
5939 message.
5941 0-1 Zero or one instance of the AVP MAY be present in the message.
5942 It is considered an error if there are more than one instance of
5943 the AVP.
5945 1 One instance of the AVP MUST be present in the message.
5947 1+ At least one instance of the AVP MUST be present in the
5948 message.
5950 10.1. Base Protocol Command AVP Table
5952 The table in this section is limited to the non-accounting Command
5953 Codes defined in this specification.
5955 +-----------------------------------------------+
5956 | Command-Code |
5957 +---+---+---+---+---+---+---+---+---+---+---+---+
5958 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
5959 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
5960 Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
5961 Interval | | | | | | | | | | | | |
5962 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
5963 Required | | | | | | | | | | | | |
5964 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5965 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
5966 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5967 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5968 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5969 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5970 Lifetime | | | | | | | | | | | | |
5971 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
5972 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
5973 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
5974 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5975 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
5976 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
5977 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |
5978 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5979 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5980 Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5981 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5982 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
5983 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
5984 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|
5985 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5986 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
5987 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
5988 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
5989 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
5990 Time | | | | | | | | | | | | |
5991 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
5992 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
5993 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
5994 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5995 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
5996 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5997 Failover | | | | | | | | | | | | |
5998 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
5999 Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6000 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
6001 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
6002 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6003 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
6004 Application-Id | | | | | | | | | | | | |
6005 --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
6007 10.2. Accounting AVP Table
6009 The table in this section is used to represent which AVPs defined in
6010 this document are to be present in the Accounting messages. These
6011 AVP occurrence requirements are guidelines, which may be expanded,
6012 and/or overridden by application-specific requirements in the
6013 Diameter applications documents.
6015 +-----------+
6016 | Command |
6017 | Code |
6018 +-----+-----+
6019 Attribute Name | ACR | ACA |
6020 ------------------------------+-----+-----+
6021 Acct-Interim-Interval | 0-1 | 0-1 |
6022 Acct-Multi-Session-Id | 0-1 | 0-1 |
6023 Accounting-Record-Number | 1 | 1 |
6024 Accounting-Record-Type | 1 | 1 |
6025 Acct-Session-Id | 0-1 | 0-1 |
6026 Accounting-Sub-Session-Id | 0-1 | 0-1 |
6027 Accounting-Realtime-Required | 0-1 | 0-1 |
6028 Acct-Application-Id | 0-1 | 0-1 |
6029 Auth-Application-Id | 0 | 0 |
6030 Class | 0+ | 0+ |
6031 Destination-Host | 0-1 | 0 |
6032 Destination-Realm | 1 | 0 |
6033 Error-Reporting-Host | 0 | 0+ |
6034 Event-Timestamp | 0-1 | 0-1 |
6035 Origin-Host | 1 | 1 |
6036 Origin-Realm | 1 | 1 |
6037 Proxy-Info | 0+ | 0+ |
6038 Route-Record | 0+ | 0 |
6039 Result-Code | 0 | 1 |
6040 Session-Id | 1 | 1 |
6041 Termination-Cause | 0 | 0 |
6042 User-Name | 0-1 | 0-1 |
6043 Vendor-Specific-Application-Id| 0-1 | 0-1 |
6044 ------------------------------+-----+-----+
6046 11. IANA Considerations
6048 This section provides guidance to the Internet Assigned Numbers
6049 Authority (IANA) regarding registration of values related to the
6050 Diameter protocol, in accordance with BCP 26 [RFC2434]. The
6051 following policies are used here with the meanings defined in BCP 26:
6052 "Private Use", "First Come First Served", "Expert Review",
6053 "Specification Required", "IETF Review", "Standards Action".
6055 This section explains the criteria to be used by the IANA for
6056 assignment of numbers within namespaces defined within this document.
6058 For registration requests where a Designated Expert should be
6059 consulted, the responsible IESG area director should appoint the
6060 Designated Expert. For Designated Expert with Specification
6061 Required, the request is posted to the DIME WG mailing list (or, if
6062 it has been disbanded, a successor designated by the Area Director)
6063 for comment and review, and MUST include a pointer to a public
6064 specification. Before a period of 30 days has passed, the Designated
6065 Expert will either approve or deny the registration request and
6066 publish a notice of the decision to the DIME WG mailing list or its
6067 successor. A denial notice MUST be justified by an explanation and,
6068 in the cases where it is possible, concrete suggestions on how the
6069 request can be modified so as to become acceptable.
6071 11.1. AVP Header
6073 As defined in Section 4, the AVP header contains three fields that
6074 requires IANA namespace management; the AVP Code, Vendor-ID and Flags
6075 field.
6077 11.1.1. AVP Codes
6079 The AVP Code namespace is used to identify attributes. There are
6080 multiple namespaces. Vendors can have their own AVP Codes namespace
6081 which will be identified by their Vendor-ID (also known as
6082 Enterprise-Number) and they control the assignments of their vendor-
6083 specific AVP codes within their own namespace. The absence of a
6084 Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
6085 controlled AVP Codes namespace. The AVP Codes and sometimes also
6086 possible values in an AVP are controlled and maintained by IANA.
6088 AVP Code 0 is not used. AVP Codes 1-255 are managed separately as
6089 RADIUS Attribute Types [RADTYPE]. This document defines the AVP
6090 Codes 257-274, 276-285, 287, 291-300, 480, 483 and 485-486. See
6091 Section 4.5 for the assignment of the namespace in this
6092 specification.
6094 AVPs may be allocated following Designated Expert with Specification
6095 Required [RFC2434]. Release of blocks of AVPs (more than 3 at a time
6096 for a given purpose) should require IETF Review.
6098 Note that Diameter defines a mechanism for Vendor-Specific AVPs,
6099 where the Vendor-Id field in the AVP header is set to a non-zero
6100 value. Vendor-Specific AVPs codes are for Private Use and should be
6101 encouraged instead of allocation of global attribute types, for
6102 functions specific only to one vendor's implementation of Diameter,
6103 where no interoperability is deemed useful. Where a Vendor-Specific
6104 AVP is implemented by more than one vendor, allocation of global AVPs
6105 should be encouraged instead.
6107 11.1.2. AVP Flags
6109 There are 8 bits in the AVP Flags field of the AVP header, defined in
6110 Section 4. This document assigns bit 0 ('V'endor Specific), bit 1
6111 ('M'andatory) and bit 2 ('P'rotected). The remaining bits should
6112 only be assigned via a Standards Action [RFC2434].
6114 11.2. Diameter Header
6116 As defined in Section 3, the Diameter header contains two fields that
6117 require IANA namespace management; Command Code and Command Flags.
6119 11.2.1. Command Codes
6121 The Command Code namespace is used to identify Diameter commands.
6122 The values 0-255 (0x00-0xff) are reserved for RADIUS backward
6123 compatibility, and are defined as "RADIUS Packet Type Codes" in
6124 [RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for
6125 permanent, standard commands, allocated by IETF Review [RFC2434].
6126 This document defines the Command Codes 257, 258, 271, 274-275, 280
6127 and 282. See Section 3.1 for the assignment of the namespace in this
6128 specification.
6130 The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved
6131 for vendor-specific command codes, to be allocated on a First Come,
6132 First Served basis by IANA [RFC2434]. The request to IANA for a
6133 Vendor-Specific Command Code SHOULD include a reference to a publicly
6134 available specification which documents the command in sufficient
6135 detail to aid in interoperability between independent
6136 implementations. If the specification cannot be made publicly
6137 available, the request for a vendor-specific command code MUST
6138 include the contact information of persons and/or entities
6139 responsible for authoring and maintaining the command.
6141 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
6142 0xffffff) are reserved for experimental commands. As these codes are
6143 only for experimental and testing purposes, no guarantee is made for
6144 interoperability between Diameter peers using experimental commands,
6145 as outlined in [IANA-EXP].
6147 11.2.2. Command Flags
6149 There are eight bits in the Command Flags field of the Diameter
6150 header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy),
6151 bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be
6152 assigned via a Standards Action [RFC2434].
6154 11.3. Application Identifiers
6156 As defined in Section 2.4, the Application Id is used to identify a
6157 specific Diameter Application. There are standards-track Application
6158 Ids and vendor specific Application Ids.
6160 IANA [RFC2434] has assigned the range 0x00000001 to 0x00ffffff for
6161 standards-track applications; and 0x01000000 - 0xfffffffe for vendor
6162 specific applications, on a first-come, first-served basis. The
6163 following values are allocated.
6165 Diameter Common Messages 0
6166 Diameter Base Accounting 3
6167 Relay 0xffffffff
6169 Assignment of standards-track Application Ids are by Designated
6170 Expert with Specification Required [RFC2434].
6172 Both Auth-Application-Id and Acct-Application-Id AVPs use the same
6173 Application Id space. A Diameter node advertising itself as a relay
6174 agent MUST set either Application-Id or Acct-Application-Id to
6175 0xffffffff.
6177 Vendor-Specific Application Ids, are for Private Use. Vendor-Specific
6178 Application Ids are assigned on a First Come, First Served basis by
6179 IANA.
6181 11.4. AVP Values
6183 Certain AVPs in Diameter define a list of values with various
6184 meanings. For attributes other than those specified in this section,
6185 adding additional values to the list can be done on a First Come,
6186 First Served basis by IANA.
6188 11.4.1. Result-Code AVP Values
6190 As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
6191 the values 1001, 2001-2002, 3001-3012, 4001-4003 and 5001-5021.
6193 All remaining values are available for assignment via IETF Review
6194 [RFC2434].
6196 11.4.2. Accounting-Record-Type AVP Values
6198 As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code
6199 480) defines the values 1-4. All remaining values are available for
6200 assignment via IETF Review [RFC2434].
6202 11.4.3. Termination-Cause AVP Values
6204 As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295)
6205 defines the values 1-8. All remaining values are available for
6206 assignment via IETF Review [RFC2434].
6208 11.4.4. Redirect-Host-Usage AVP Values
6210 As defined in Section 6.13, the Redirect-Host-Usage AVP (AVP Code
6211 261) defines the values 0-5. All remaining values are available for
6212 assignment via IETF Review [RFC2434].
6214 11.4.5. Session-Server-Failover AVP Values
6216 As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code
6217 271) defines the values 0-3. All remaining values are available for
6218 assignment via IETF Review [RFC2434].
6220 11.4.6. Session-Binding AVP Values
6222 As defined in Section 8.17, the Session-Binding AVP (AVP Code 270)
6223 defines the bits 1-4. All remaining bits are available for
6224 assignment via IETF Review [RFC2434].
6226 11.4.7. Disconnect-Cause AVP Values
6228 As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273)
6229 defines the values 0-2. All remaining values are available for
6230 assignment via IETF Review [RFC2434].
6232 11.4.8. Auth-Request-Type AVP Values
6234 As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274)
6235 defines the values 1-3. All remaining values are available for
6236 assignment via IETF Review [RFC2434].
6238 11.4.9. Auth-Session-State AVP Values
6240 As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277)
6241 defines the values 0-1. All remaining values are available for
6242 assignment via IETF Review [RFC2434].
6244 11.4.10. Re-Auth-Request-Type AVP Values
6246 As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code
6247 285) defines the values 0-1. All remaining values are available for
6248 assignment via IETF Review [RFC2434].
6250 11.4.11. Accounting-Realtime-Required AVP Values
6252 As defined in Section 9.8.7, the Accounting-Realtime-Required AVP
6253 (AVP Code 483) defines the values 1-3. All remaining values are
6254 available for assignment via IETF Review [RFC2434].
6256 11.4.12. Inband-Security-Id AVP (code 299)
6258 As defined in Section 6.10, the Inband-Security-Id AVP (AVP Code 299)
6259 defines the values 0-1. All remaining values are available for
6260 assignment via IETF Review. [RFC2434].
6262 11.5. Diameter TCP/SCTP and TLS Port Numbers
6264 The IANA has assigned port number 3868 for TCP/SCTP. The IANA is
6265 requested to allocated a port number for TLS.
6267 11.6. NAPTR Service Fields
6269 The registration in the RFC MUST include the following information:
6271 Service Field: The service field being registered. An example for a
6272 new fictitious transport protocol called NCTP might be "AAA+D2N".
6274 Protocol: The specific transport protocol associated with that
6275 service field. This MUST include the name and acronym for the
6276 protocol, along with reference to a document that describes the
6277 transport protocol. For example - "New Connectionless Transport
6278 Protocol (NCTP), RFC XYZ".
6280 Name and Contact Information: The name, address, email address and
6281 telephone number for the person performing the registration.
6283 The following values have been placed into the registry:
6285 Services Field Protocol
6287 AAA+D2T TCP
6288 AAA+D2S SCTP
6289 AAA+D2L TLS
6291 12. Diameter protocol related configurable parameters
6293 This section contains the configurable parameters that are found
6294 throughout this document:
6296 Diameter Peer
6298 A Diameter entity MAY communicate with peers that are statically
6299 configured. A statically configured Diameter peer would require
6300 that either the IP address or the fully qualified domain name
6301 (FQDN) be supplied, which would then be used to resolve through
6302 DNS.
6304 Routing Table
6306 A Diameter proxy server routes messages based on the realm portion
6307 of a Network Access Identifier (NAI). The server MUST have a
6308 table of Realm Names, and the address of the peer to which the
6309 message must be forwarded to. The routing table MAY also include
6310 a "default route", which is typically used for all messages that
6311 cannot be locally processed.
6313 Tc timer
6315 The Tc timer controls the frequency that transport connection
6316 attempts are done to a peer with whom no active transport
6317 connection exists. The recommended value is 30 seconds.
6319 13. Security Considerations
6321 The Diameter base protocol messages SHOULD be secured by using TLS
6322 [RFC4346]. Additional security mechanisms such as IPsec [RFC4301]
6323 MAY also be deployed to secure connections between peers. However,
6324 all Diameter base protocol implementations MUST support the use of
6325 TLS and the Diameter protocol MUST NOT be used without any security
6326 mechanism.
6328 If a Diameter connection is to be protected via TLS or IPsec, then
6329 TLS or IPsec handshake will begin prior to any Diameter message
6330 exchange. All security parameters for TLS or IPsec are configured
6331 independent of the Diameter protocol. All Diameter message will be
6332 sent through the TLS or IPsec connection after a successful setup.
6334 13.1. TLS Usage
6336 Diameter nodes using TLS for security MUST mutually authenticate as
6337 part of TLS session establishment. In order to ensure mutual
6338 authentication, the Diameter node acting as TLS server MUST request a
6339 certificate from the Diameter node acting as TLS client, and the
6340 Diameter node acting as TLS client MUST be prepared to supply a
6341 certificate on request.
6343 Diameter nodes MUST be able to negotiate the following TLS cipher
6344 suites:
6346 TLS_RSA_WITH_RC4_128_MD5
6347 TLS_RSA_WITH_RC4_128_SHA
6348 TLS_RSA_WITH_3DES_EDE_CBC_SHA
6350 Diameter nodes SHOULD be able to negotiate the following TLS cipher
6351 suite:
6353 TLS_RSA_WITH_AES_128_CBC_SHA
6355 Diameter nodes MAY negotiate other TLS cipher suites.
6357 13.2. Peer-to-Peer Considerations
6359 As with any peer-to-peer protocol, proper configuration of the trust
6360 model within a Diameter peer is essential to security. When
6361 certificates are used, it is necessary to configure the root
6362 certificate authorities trusted by the Diameter peer. These root CAs
6363 are likely to be unique to Diameter usage and distinct from the root
6364 CAs that might be trusted for other purposes such as Web browsing.
6365 In general, it is expected that those root CAs will be configured so
6366 as to reflect the business relationships between the organization
6367 hosting the Diameter peer and other organizations. As a result, a
6368 Diameter peer will typically not be configured to allow connectivity
6369 with any arbitrary peer. With certificate authentication, Diameter
6370 peers may not be known beforehand and therefore peer discovery may be
6371 required.
6373 14. References
6375 14.1. Normative References
6377 [FLOATPOINT]
6378 Institute of Electrical and Electronics Engineers, "IEEE
6379 Standard for Binary Floating-Point Arithmetic, ANSI/IEEE
6380 Standard 754-1985", August 1985.
6382 [IANAADFAM]
6383 IANA,, "Address Family Numbers",
6384 http://www.iana.org/assignments/address-family-numbers.
6386 [RADTYPE] IANA,, "RADIUS Types",
6387 http://www.iana.org/assignments/radius-types.
6389 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
6391 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
6392 January 1981.
6394 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
6395 Accounting (AAA) Transport Profile", RFC 3539, June 2003.
6397 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
6398 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
6399 August 2005.
6401 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
6402 "Diameter Network Access Server Application", RFC 4005,
6403 August 2005.
6405 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
6406 Loughney, "Diameter Credit-Control Application", RFC 4006,
6407 August 2005.
6409 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
6410 Authentication Protocol (EAP) Application", RFC 4072,
6411 August 2005.
6413 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
6414 Canales-Valenzuela, C., and K. Tammi, "Diameter Session
6415 Initiation Protocol (SIP) Application", RFC 4740,
6416 November 2006.
6418 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
6419 Specifications: ABNF", RFC 4234, October 2005.
6421 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
6422 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
6424 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
6425 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
6426 October 1998.
6428 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
6429 RFC 4306, December 2005.
6431 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
6432 Architecture", RFC 4291, February 2006.
6434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6435 Requirement Levels", BCP 14, RFC 2119, March 1997.
6437 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
6438 Network Access Identifier", RFC 4282, December 2005.
6440 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
6441 Part Three: The Domain Name System (DNS) Database",
6442 RFC 3403, October 2002.
6444 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
6445 Requirements for Security", BCP 106, RFC 4086, June 2005.
6447 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
6448 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
6449 Zhang, L., and V. Paxson, "Stream Control Transmission
6450 Protocol", RFC 2960, October 2000.
6452 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
6453 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
6455 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6456 Resource Identifier (URI): Generic Syntax", STD 66,
6457 RFC 3986, January 2005.
6459 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
6460 10646", STD 63, RFC 3629, November 2003.
6462 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
6463 X.509 Public Key Infrastructure Certificate and
6464 Certificate Revocation List (CRL) Profile", RFC 3280,
6465 April 2002.
6467 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
6468 "Internationalizing Domain Names in Applications (IDNA)",
6469 RFC 3490, March 2003.
6471 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
6472 Profile for Internationalized Domain Names (IDN)",
6473 RFC 3491, March 2003.
6475 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
6476 for Internationalized Domain Names in Applications
6477 (IDNA)", RFC 3492, March 2003.
6479 14.2. Informational References
6481 [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
6482 Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
6483 D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
6484 S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
6485 B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
6486 "Criteria for Evaluating AAA Protocols for Network
6487 Access", RFC 2989, November 2000.
6489 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
6490 Accounting Management", RFC 2975, October 2000.
6492 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
6493 an On-line Database", RFC 3232, January 2002.
6495 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
6496 Aboba, "Dynamic Authorization Extensions to Remote
6497 Authentication Dial In User Service (RADIUS)", RFC 3576,
6498 July 2003.
6500 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
6501 RFC 1661, July 1994.
6503 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
6505 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
6506 Extensions", RFC 2869, June 2000.
6508 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
6509 "Remote Authentication Dial In User Service (RADIUS)",
6510 RFC 2865, June 2000.
6512 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
6513 RFC 3162, August 2001.
6515 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
6516 Internet Protocol", RFC 4301, December 2005.
6518 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
6519 A., Peterson, J., Sparks, R., Handley, M., and E.
6520 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
6521 June 2002.
6523 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
6524 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
6526 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
6527 TACACS", RFC 1492, July 1993.
6529 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
6530 Recommendations for Internationalized Domain Names
6531 (IDNs)", RFC 4690, September 2006.
6533 [IANA-EXP]
6534 Narten, T., "Assigning Experimental and Testing Numbers
6535 Considered Useful, Work in Progress.".
6537 Appendix A. Acknowledgements
6539 A.1. RFC3588bis
6541 The authors would like to thank the following people that have
6542 provided proposals and contributions to this document:
6544 To Vishnu Ram and Satendra Gera for their contributions on
6545 Capabilities Updates, Predictive Loop Avoidance as well as many other
6546 technical proposals. To Tolga Asveren for his insights and
6547 contributions on almost all of the proposed solutions incorporated
6548 into this document. To Timothy Smith for helping on the Capabilities
6549 Updates and other topics. To Tony Zhang for providing fixes to loop
6550 holes on composing Failed-AVPs as well as many other issues and
6551 topics. To Jan Nordqvist for clearly stating the usage of
6552 Application Ids. To Anders Kristensen for providing needed technical
6553 opinions. To David Frascone for providing invaluable review of the
6554 document. To Mark Jones for providing clarifying text on vendor
6555 command codes and other vendor specific indicators.
6557 Special thanks to the Diameter extensibility design team which helped
6558 resolve the tricky question of mandatory AVPs and ABNF semantics.
6559 The members of this team are as follows:
6561 Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga
6562 Asveren Jouni Korhonen, Glenn McGregor.
6564 Special thanks also to people who have provided invaluable comments
6565 and inputs especially in resolving controversial issues:
6567 Glen Zorn, Yoshihiro Ohba, Marco Stura, and Pasi Eronen.
6569 Finally, we would like to thank the original authors of this
6570 document:
6572 Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman and Glen Zorn.
6574 Their invaluable knowledge and experience has given us a robust and
6575 flexible AAA protocol that many people have seen great value in
6576 adopting. We greatly appreciate their support and stewardship for
6577 the continued improvements of Diameter as a protocol. We would also
6578 like to extend our gratitude to folks aside from the authors who have
6579 assisted and contributed to the original version of this document.
6580 Their efforts significantly contributed to the success of Diameter.
6582 A.2. RFC3588
6584 The authors would like to thank Nenad Trifunovic, Tony Johansson and
6585 Pankaj Patel for their participation in the pre-IETF Document Reading
6586 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided
6587 invaluable assistance in working out transport issues, and similarly
6588 with Steven Bellovin in the security area.
6590 Paul Funk and David Mitton were instrumental in getting the Peer
6591 State Machine correct, and our deep thanks go to them for their time.
6593 Text in this document was also provided by Paul Funk, Mark Eklund,
6594 Mark Jones and Dave Spence. Jacques Caron provided many great
6595 comments as a result of a thorough review of the spec.
6597 The authors would also like to acknowledge the following people for
6598 their contribution in the development of the Diameter protocol:
6600 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell,
6601 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy
6602 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien,
6603 Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin,
6604 Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and
6605 Jeff Weisberg.
6607 Finally, Pat Calhoun would like to thank Sun Microsystems since most
6608 of the effort put into this document was done while he was in their
6609 employ.
6611 Appendix B. NAPTR Example
6613 As an example, consider a client that wishes to resolve aaa:
6614 example.com. The client performs a NAPTR query for that domain, and
6615 the following NAPTR records are returned:
6617 ;; order pref flags service regexp replacement
6618 IN NAPTR 50 50 "s" "AAA+D2L" "" _diameter._tls.example.com
6619 IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com
6620 IN NAPTR 150 50 "s" "AAA+D2S" "" _diameter._sctp.example.com
6622 This indicates that the server supports TLS, TCP and SCTP in that
6623 order. If the client supports TLS, TLS will be used, targeted to a
6624 host determined by an SRV lookup of _diameter._tls.example.com. That
6625 lookup would return:
6627 ;; Priority Weight Port Target
6628 IN SRV 0 1 5060 server1.example.com
6629 IN SRV 0 2 5060 server2.example.com
6631 Appendix C. Duplicate Detection
6633 As described in Section 9.4, accounting record duplicate detection is
6634 based on session identifiers. Duplicates can appear for various
6635 reasons:
6637 o Failover to an alternate server. Where close to real-time
6638 performance is required, failover thresholds need to be kept low
6639 and this may lead to an increased likelihood of duplicates.
6640 Failover can occur at the client or within Diameter agents.
6642 o Failure of a client or agent after sending of a record from non-
6643 volatile memory, but prior to receipt of an application layer ACK
6644 and deletion of the record. record to be sent. This will result
6645 in retransmission of the record soon after the client or agent has
6646 rebooted.
6648 o Duplicates received from RADIUS gateways. Since the
6649 retransmission behavior of RADIUS is not defined within [RFC2865],
6650 the likelihood of duplication will vary according to the
6651 implementation.
6653 o Implementation problems and misconfiguration.
6655 The T flag is used as an indication of an application layer
6656 retransmission event, e.g., due to failover to an alternate server.
6657 It is defined only for request messages sent by Diameter clients or
6658 agents. For instance, after a reboot, a client may not know whether
6659 it has already tried to send the accounting records in its non-
6660 volatile memory before the reboot occurred. Diameter servers MAY use
6661 the T flag as an aid when processing requests and detecting duplicate
6662 messages. However, servers that do this MUST ensure that duplicates
6663 are found even when the first transmitted request arrives at the
6664 server after the retransmitted request. It can be used only in cases
6665 where no answer has been received from the Server for a request and
6666 the request is sent again, (e.g., due to a failover to an alternate
6667 peer, due to a recovered primary peer or due to a client re-sending a
6668 stored record from non-volatile memory such as after reboot of a
6669 client or agent).
6671 In some cases the Diameter accounting server can delay the duplicate
6672 detection and accounting record processing until a post-processing
6673 phase takes place. At that time records are likely to be sorted
6674 according to the included User-Name and duplicate elimination is easy
6675 in this case. In other situations it may be necessary to perform
6676 real-time duplicate detection, such as when credit limits are imposed
6677 or real-time fraud detection is desired.
6679 In general, only generation of duplicates due to failover or re-
6680 sending of records in non-volatile storage can be reliably detected
6681 by Diameter clients or agents. In such cases the Diameter client or
6682 agents can mark the message as possible duplicate by setting the T
6683 flag. Since the Diameter server is responsible for duplicate
6684 detection, it can choose to make use of the T flag or not, in order
6685 to optimize duplicate detection. Since the T flag does not affect
6686 interoperability, and may not be needed by some servers, generation
6687 of the T flag is REQUIRED for Diameter clients and agents, but MAY be
6688 implemented by Diameter servers.
6690 As an example, it can be usually be assumed that duplicates appear
6691 within a time window of longest recorded network partition or device
6692 fault, perhaps a day. So only records within this time window need
6693 to be looked at in the backward direction. Secondly, hashing
6694 techniques or other schemes, such as the use of the T flag in the
6695 received messages, may be used to eliminate the need to do a full
6696 search even in this set except for rare cases.
6698 The following is an example of how the T flag may be used by the
6699 server to detect duplicate requests.
6701 A Diameter server MAY check the T flag of the received message to
6702 determine if the record is a possible duplicate. If the T flag is
6703 set in the request message, the server searches for a duplicate
6704 within a configurable duplication time window backward and
6705 forward. This limits database searching to those records where
6706 the T flag is set. In a well run network, network partitions and
6707 device faults will presumably be rare events, so this approach
6708 represents a substantial optimization of the duplicate detection
6709 process. During failover, it is possible for the original record
6710 to be received after the T flag marked record, due to differences
6711 in network delays experienced along the path by the original and
6712 duplicate transmissions. The likelihood of this occurring
6713 increases as the failover interval is decreased. In order to be
6714 able to detect out of order duplicates, the Diameter server should
6715 use backward and forward time windows when performing duplicate
6716 checking for the T flag marked request. For example, in order to
6717 allow time for the original record to exit the network and be
6718 recorded by the accounting server, the Diameter server can delay
6719 processing records with the T flag set until a time period
6720 TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing
6721 of the original transport connection. After this time period has
6722 expired, then it may check the T flag marked records against the
6723 database with relative assurance that the original records, if
6724 sent, have been received and recorded.
6726 Appendix D. Internationalized Domain Names
6728 To be compatible with the existing DNS infrastructure and simplify
6729 host and domain name comparison, Diameter identities (FQDNs) are
6730 represented in ASCII form. This allows the Diameter protocol to fall
6731 in-line with the DNS strategy of being transparent from the effects
6732 of Internationalized Domain Names (IDNs) by following the
6733 recommnedations in [RFC4690] and [RFC3490]. Applications that
6734 provide support for IDNs outside of the Diameter protocol but
6735 interacting with it SHOULD use the representation and conversion
6736 framework described in [RFC3490], [RFC3491] and [RFC3492].
6738 Authors' Addresses
6740 Victor Fajardo (editor)
6741 Toshiba America Research
6742 One Telcordia Drive, 1S-222
6743 Piscataway, NJ 08854
6744 USA
6746 Phone: 1 908-421-1845
6747 Email: vfajardo@tari.toshiba.com
6749 Jari Arkko
6750 Ericsson Research
6751 02420 Jorvas
6752 Finland
6754 Phone: +358 40 5079256
6755 Email: jari.arkko@ericsson.com
6757 John Loughney
6758 Nokia Research Center
6759 955 Page Mill Road
6760 Palo Alto, CA 94304
6761 US
6763 Phone: 1-650-283-8068
6764 Email: john.loughney@nokia.com
6766 Glenn Zorn
6767 NetCube
6768 1310 East Thomas Street, #306
6769 Seattle, WA 98102
6770 US
6772 Phone:
6773 Email: glenzorn@comcast.net
6775 Full Copyright Statement
6777 Copyright (C) The IETF Trust (2008).
6779 This document is subject to the rights, licenses and restrictions
6780 contained in BCP 78, and except as set forth therein, the authors
6781 retain all their rights.
6783 This document and the information contained herein are provided on an
6784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
6785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
6786 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
6787 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
6788 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
6789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6791 Intellectual Property
6793 The IETF takes no position regarding the validity or scope of any
6794 Intellectual Property Rights or other rights that might be claimed to
6795 pertain to the implementation or use of the technology described in
6796 this document or the extent to which any license under such rights
6797 might or might not be available; nor does it represent that it has
6798 made any independent effort to identify any such rights. Information
6799 on the procedures with respect to rights in RFC documents can be
6800 found in BCP 78 and BCP 79.
6802 Copies of IPR disclosures made to the IETF Secretariat and any
6803 assurances of licenses to be made available, or the result of an
6804 attempt made to obtain a general license or permission for the use of
6805 such proprietary rights by implementers or users of this
6806 specification can be obtained from the IETF on-line IPR repository at
6807 http://www.ietf.org/ipr.
6809 The IETF invites any interested party to bring to its attention any
6810 copyrights, patents or patent applications, or other proprietary
6811 rights that may cover technology that may be required to implement
6812 this standard. Please address the information to the IETF at
6813 ietf-ipr@ietf.org.