idnits 2.17.1 draft-ietf-aaa-diameter-09.txt: -(5571): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5575): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5582): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5591): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5621): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5641): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5665): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5682): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5772): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5775): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5778): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5782): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5795): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5812): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5930): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 26 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 132 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 133 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 272 has weird spacing: '...ing for simpl...' == Line 1439 has weird spacing: '... answer messa...' == Line 2189 has weird spacing: '...that if a mes...' == Line 2191 has weird spacing: '...s there is a ...' == Line 2192 has weird spacing: '...dicates that...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- 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 (March 2002) is 8079 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'PPP' is mentioned on line 5672, but not defined == Missing Reference: 'ROAMCRIT' is mentioned on line 5682, but not defined == Missing Reference: 'ROAMREV' is mentioned on line 245, but not defined == Missing Reference: 'PROXYCHAIN' is mentioned on line 5675, but not defined == Missing Reference: 'CDMA2000REQ' is mentioned on line 324, but not defined == Missing Reference: 'MIPREQ' is mentioned on line 5661, but not defined == Missing Reference: 'MIPV4' is mentioned on line 5658, but not defined == Missing Reference: 'NASCRIT' is mentioned on line 5669, but not defined == Missing Reference: 'DIAMMIP' is mentioned on line 5650, but not defined == Missing Reference: 'RADIUS' is mentioned on line 5678, but not defined == Missing Reference: 'NASREQ' is mentioned on line 5665, but not defined -- Looks like a reference, but probably isn't: '47' on line 418 == Missing Reference: 'ABNF' is mentioned on line 5641, but not defined == Missing Reference: 'SEC ARCH' is mentioned on line 803, but not defined == Missing Reference: 'ASSIGN NO' is mentioned on line 2571, but not defined == Missing Reference: 'UFT8' is mentioned on line 1654, but not defined == Missing Reference: 'PXY' is mentioned on line 3770, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 5644, but not defined == Missing Reference: 'IPComp' is mentioned on line 5654, but not defined == Missing Reference: 'RAD TYPE' is mentioned on line 5279, but not defined == Missing Reference: 'IPsec' is mentioned on line 5475, but not defined == Missing Reference: 'CDMA2000' is mentioned on line 5647, but not defined == Missing Reference: 'SECARCH' is mentioned on line 5685, but not defined == Unused Reference: 'DNSSRV' is defined on line 5571, but no explicit reference was found in the text == Unused Reference: 'IANAWEB' is defined on line 5586, but no explicit reference was found in the text == Unused Reference: 'TLSSCTP' is defined on line 5630, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 5637, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-aaa-transport-04 ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNNO') (Obsoleted by RFC 3232) == Outdated reference: A later version (-04) exists of draft-ietf-aaa-diameter-cms-sec-03 -- Possible downref: Normative reference to a draft: ref. 'CMS' ** Obsolete normative reference: RFC 2598 (ref. 'DIFFSERVEF') (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'FLOATPOINT' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAWEB' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'IPSECDOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2373 (ref. 'IPV6') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2915 (ref. 'NAPTR') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Possible downref: Non-RFC (?) normative reference: ref. 'RADTYPE' ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2030 (ref. 'SNTP') (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSSCTP' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) Summary: 17 errors (**), 0 flaws (~~), 42 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track Jari Arkko 5 Oy LM Ericsson Ab 6 Erik Guttman 7 Sun Microsystems, Inc. 8 Glen Zorn 9 Cisco Systems, Inc. 10 John Loughney 11 Nokia 12 March 2002 14 Diameter Base Protocol 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Distribution of this memo is unlimited. 39 Copyright (C) The Internet Society 2002. All Rights Reserved. 41 Abstract 43 The Diameter base protocol is intended to provide an AAA framework 44 for Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message 45 format, transport, error reporting and security services to be used 46 by all Diameter applications and MUST be supported by all Diameter 47 implementations. 49 Table of Contents 51 1.0 Introduction 52 1.1 Diameter Protocol 53 1.1.1 Differences from Radius 54 1.1.2 Description of the Document Set 55 1.2 Approach to Extensibility 56 1.2.1 Defining New AVP Values 57 1.2.2 Creating New AVPs 58 1.2.3 Creating a New Authentication Application 59 1.2.4 Creating a new Accounting Application 60 1.2.5 Application Authentication Procedures 61 1.3 Requirements Language 62 1.4 Terminology 63 2.0 Protocol Overview 64 2.1 Transport 65 2.1.1 SCTP Guidelines 66 2.2 Securing Diameter Messages 67 2.3 Diameter Application Compliance 68 2.4 Application Identifiers 69 2.5 Peer Table 70 2.6 Realm-Based Routing Table 71 2.7 Realm-Based Routing Table 72 2.8 Role of Diameter Agents 73 2.8.1 Relay Agents 74 2.8.2 Proxy Agents 75 2.8.3 Redirect Agents 76 2.8.4 Translation Agents 77 3.0 Diameter Header 78 3.1 Command Code Definitions 79 3.2 Command Code ABNF specification 80 3.3 Diameter Command Naming Conventions 81 4.0 Diameter AVPs 82 4.1 AVP Header 83 4.2 Optional Header Elements 84 4.3 AVP Data Formats 85 4.4 Derived AVP Data Formats 86 4.5 Grouped AVP Values 87 4.5.1 Example AVP with a Grouped Data type 89 4.6 Diameter Base Protocol AVPs 90 5.0 Diameter Peers 91 5.1 Connecting to Peers 92 5.2 Diameter Peer Discovery 93 5.3 Capabilities Negotiation 94 5.3.1 Capabilities-Exchange-Request 95 5.3.2 Capabilities-Exchange-Answer 96 5.3.3 Vendor-Id AVP 97 5.3.4 Firmware-Revision AVP 98 5.3.5 Host-IP-Address AVP 99 5.3.6 Supported-Vendor-Id AVP 100 5.3.7 Product-Name AVP 101 5.4 Disconnecting Peer connections 102 5.4.1 Disconnect-Peer-Request 103 5.4.2 Disconnect-Peer-Answer 104 5.4.3 Disconnect-Cause AVP 105 5.5 Transport Failure Detection 106 5.5.1 Device-Watchdog-Request 107 5.5.2 Device-Watchdog-Answer 108 5.5.3 Transport Failure Algorithm 109 5.5.4 Failover/Failback Procedures 110 5.6 Peer State Machine 111 5.6.1 Incoming connections 112 5.6.2 Events 113 5.6.3 Actions 114 5.6.4 The Election Process 115 6.0 Diameter message processing 116 6.1 Diameter request routing overview 117 6.1.1 Originating a Request 118 6.1.2 Sending a Request 119 6.1.3 Receiving Requests 120 6.1.4 Processing Local Requests 121 6.1.5 Request Forwarding 122 6.1.6 Request Routing 123 6.1.7 Redirecting requests 124 6.1.8 Relaying and Proxying Requests 125 6.2 Diameter Answer Processing 126 6.2.1 Processing received Answers 127 6.2.2 Relaying and Proxying Answers 128 6.3 Origin-Host AVP 129 6.4 Origin-Realm AVP 130 6.5 Destination-Host AVP 131 6.6 Destination-Realm AVP 132 6.7 Routing AVPs 133 6.7.1 Route-Record AVP 134 6.7.2 Proxy-Info AVP 135 6.7.3 Proxy-Host AVP 136 6.7.4 Proxy-State AVP 138 6.8 Auth-Application-Id AVP 139 6.9 Acct-Application-Id AVP 140 6.10 Vendor-Specific-Application-Id AVP 141 6.11 Redirect-Host AVP 142 6.12 Redirect-Host-Usage AVP 143 6.13 Redirect-Max-Cache-Time AVP 144 7.0 Error Handling 145 7.1 Result-Code AVP 146 7.1.1 Informational 147 7.1.2 Success 148 7.1.3 Protocol Errors 149 7.1.4 Transient Failures 150 7.1.5 Permanent Failures 151 7.2 Error Bit 152 7.3 Error-Message AVP 153 7.4 Error-Reporting-Host AVP 154 7.5 Failed-AVP AVP 155 8.0 Diameter User Sessions 156 8.1 Authorization Session State Machine 157 8.2 Accounting Session State Machine 158 8.3 Server-Initiated Re-Auth 159 8.3.1 Re-Auth-Request 160 8.3.2 Re-Auth-Answer 161 8.4 Session Termination 162 8.4.1 Session-Termination-Request 163 8.4.2 Session-Termination-Answer 164 8.5 Aborting a Session 165 8.5.1 Abort-Session-Request 166 8.5.2 Abort-Session-Answer 167 8.6 Inferring Session Termination from Origin-State-Id 168 8.7 Auth-Request-Type AVP 169 8.8 Session-Id AVP 170 8.9 Authorization-Lifetime AVP 171 8.10 Auth-Grace-Period AVP 172 8.11 Auth-Session-State AVP 173 8.12 Re-Auth-Request-Type AVP 174 8.13 Session-Timeout AVP 175 8.14 User-Name AVP 176 8.15 Termination-Cause AVP 177 8.16 Origin-State-Id AVP 178 8.17 Session-Binding AVP 179 8.18 Session-Server-Failover AVP 180 8.19 Multi-Round-Time-Out AVP 181 8.20 Class AVP 182 9.0 Accounting 183 9.1 Server Directed Model 184 9.2 Protocol Messages 185 9.3 Application document requirements 186 9.4 Fault Resilience 187 9.5 Accounting Records 188 9.6 Correlation of Accounting Records 189 9.7 Accounting Command-Codes 190 9.7.1 Accounting-Request 191 9.7.2 Accounting-Answer 192 9.8 Accounting AVPs 193 9.8.1 Accounting-Record-Type AVP 194 9.8.2 Accounting-Interim-Interval AVP 195 9.8.3 Accounting-Record-Number AVP 196 9.8.4 Accounting-RADIUS-Session-Id AVP 197 9.8.5 Accounting-Multi-Session-Id AVP 198 9.8.6 Accounting-Sub-Session-Id AVP 199 9.8.7 Accounting-Realtime-Required AVP 200 10.0 AVP Occurrence Table 201 10.1 Base Protocol Command AVP Table 202 10.2 Accounting AVP Table 203 11.0 IANA Considerations 204 11.1 AVP Header 205 11.1.1 AVP Code 206 11.1.2 AVP Flags 207 11.2 Diameter Header 208 11.2.1 Command Codes 209 11.2.2 Message Flags 210 11.3 Application Identifier Values 211 11.4 Result-Code AVP Values 212 11.5 Accounting-Record-Type AVP Values 213 11.6 Termination-Cause AVP Values 214 11.7 Redirect-Host-Usage AVP Values 215 11.8 Session-Server-Failover AVP Values 216 11.9 Session-Binding AVP Values 217 11.10 Diameter TCP/SCTP Port Numbers 218 11.11 Disconnect-Cause AVP Values 219 11.12 Auth-Request-Type AVP Values 220 11.13 Auth-Session-State AVP Values 221 11.14 Re-Auth-Request-Type AVP Values 222 11.15 NAPTR Service Fields 223 12.0 Diameter protocol related configurable parameters 224 13.0 Security Considerations 225 13.1 IPsec Usage 226 13.2 TLS Usage 227 14.0 References 228 15.0 Acknowledgements 229 16.0 Authors' Addresses 230 17.0 Full Copyright Statement 231 18.0 Expiration Date 232 Appendix A. Diameter Service Template 233 Appendix B. NAPTR Example 234 Appendix C. Duplicate Detection 236 1.0 Introduction 238 Historically, the RADIUS protocol has been used to provide AAA 239 services for dial-up PPP [PPP] and terminal server access. Over time, 240 routers and network access servers (NAS) have increased in complexity 241 and density, making the RADIUS protocol increasingly unsuitable for 242 use in such networks. 244 The Roaming Operations Working Group (ROAMOPS) has published a set of 245 specifications [ROAMCRIT, ROAMREV, PROXYCHAIN] that define how a PPP 246 user can gain access to the Internet without having to dial into 247 his/her home service provider's modem pool. This is achieved by 248 allowing service providers to cross-authenticate their users. 249 Effectively, a user can dial into any service provider's point of 250 presence (POP) that has a roaming agreement with his/her home 251 Internet service provider (ISP), the benefit being that the user does 252 not have to incur a long distance charge while traveling, which can 253 sometimes be quite expensive. 255 Given the number of ISPs today, ROAMOPS realized that requiring each 256 ISP to set up roaming agreements with all other ISPs did not scale. 257 Therefore, the working group defined a "broker", which acts as an 258 intermediate server, whose sole purpose is to set up these roaming 259 agreements. A collection of ISPs and a broker is called a "roaming 260 consortium". There are many such brokers in existence today; many 261 also provide settlement services for member ISPs. 263 The Mobile-IP Working Group has recently changed its focus to inter- 264 administrative domain mobility, which is a requirement for cellular 265 carriers wishing to deploy IETF-based mobility protocols. The current 266 cellular carriers requirements [CDMA2000REQ, MIPREQ] are very similar 267 to the ROAMOPS model, with the exception that the access protocol is 268 Mobile-IP [MIPV4] instead of PPP. 270 The Network Access Server Requirements (NASREQ) working group has 271 focused on proving next generation Authentication, Authorization and 272 usage Accounting for simple dial-in access and beyond; such as 273 Virtual Private Network support, smart authentication methods, and 274 roaming concerns. The Working Group has published number of 275 documents the requirements for NAS user authorization as well as 276 criteria for evaluating NAS protocols [NASCRIT]. 278 The basic concept behind Diameter is to provide a base protocol that 279 can be extended in order to provide AAA services to new access 280 technologies. Currently, the protocol only concerns itself with 281 Internet access, both in the traditional PPP sense as well as taking 282 into account the ROAMOPS model, and Mobile-IP. 284 Although Diameter could be used to solve a wider set of AAA problems, 285 we are currently limiting the scope of the protocol in order to 286 ensure that the effort remains focused on satisfying the requirements 287 of network access. Note that a truly generic AAA protocol used by 288 many applications might provide functionality not provided by 289 Diameter. Therefore, it is imperative that the designers of new 290 applications understand their requirements before using Diameter. 292 1.1 Diameter Protocol 294 The Diameter protocol allows peers to exchange a variety of messages. 295 The base protocol provides the following facilities: 297 - Delivery of AVPs (attribute value pairs) 298 - Capabilities negotiation, as required in [ROAMCRIT] 299 - Error notification 300 - Extensibility, through addition of new commands and AVPs, as 301 required in [NASCRIT] 303 All data delivered by the protocol is in the form of an AVP. Some of 304 these AVP values are used by the Diameter protocol itself, while 305 others deliver data associated with particular applications that 306 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 307 so long as the required AVPs are included and AVPs that are 308 explicitly excluded are not included. AVPs are used by the base 309 Diameter protocol to support the following required features: 311 - Transporting of user authentication information, for the 312 purposes of enabling the Diameter server to authenticate the 313 user. 314 - Transporting of service specific authorization information, 315 between client and servers, allowing the peers to decide whether 316 a user's access request should be granted. 317 - Exchanging resource usage information, which MAY be used for 318 accounting purposes, capacity planning, etc. 319 - Relaying, proxying and redirecting of Diameter messages through 320 a server hierarchy. 322 The Diameter base protocol provides the minimum requirements needed 323 for an AAA transport protocol, as required by NASREQ [NASCRIT], 324 Mobile IP [CDMA2000REQ, MIPREQ], and ROAMOPS [ROAMCRIT]. The base 325 protocol is not intended to be used by itself, and must be used with 326 a Diameter application, such as Mobile IP [DIAMMIP]. The Diameter 327 protocol was heavily inspired by and builds upon the tradition of the 328 RADIUS [RADIUS] protocol. See section 2.4 for more information on 329 Diameter applications. 331 Any node can initiate a request. In that sense, Diameter is a peer- 332 to-peer protocol. In this document, a Diameter client is an access 333 device that initiates a request for authentication and/or 334 authorization of a given user. A Diameter agent is a node that does 335 not authenticate and/or authorize messages locally. Examples of 336 agents are proxies and relay agents. A Diameter server is one that 337 performs authentication and/or authorization of the user based on 338 some profile. A Diameter node MAY act as an agent for certain 339 requests while acting as a server for others. 341 The Diameter protocol also supports server-initiated messages towards 342 access devices, such as a request to abort service to a particular 343 user. 345 1.1.1 Differences from Radius 347 The Diameter protocol was not designed from the ground up. Instead, 348 the basic RADIUS model was retained while fixing the flaws in the 349 RADIUS protocol itself. Diameter does not share a common protocol 350 data unit (PDU) with RADIUS, but does borrow sufficiently from the 351 protocol to ease migration. The major differences include: 353 - Peer-to-peer nature 354 - Explicit support for intermediaries 355 - Connection-oriented versus connectionless 356 - Extensibility [see section 1.2] 357 - Built-in failover support 358 - Larger attribute space 359 - Integrated accounting 360 - Mandatory bit 361 - Application-layer ACKs and error messages 362 - Unsolicited server messages 363 - Peer discovery 364 - Capabilities negotiation 366 1.1.2 Description of the Document Set 368 Currently, the Diameter specification consists of a base 369 specification (this document), Transport Issues [AAATRANS] and a 370 number of applications: Mobile IPv4 [DIAMMIP], NASREQ [NASREQ] and 371 CMS Security [CMS]. 373 The Transport Issues document [AAATRANS] discusses transport layer 374 issues that arise with AAA protocols and recommendations on how to 375 overcome these issues. 377 The Mobile IPv4 [DIAMMIP] application defines a Diameter application 378 that allows a Diameter server to perform AAA functions for Mobile 379 IPv4 services to a mobile node. 381 The NASREQ [NASREQ] application defines a Diameter Application that 382 allows a Diameter server to be used in a PPP/SLIP Dial-Up and 383 Terminal Server Access environment. Consideration was given for 384 servers that need to perform protocol conversion between Diameter and 385 RADIUS. 387 The CMS Security [CMS] application defines how security associations 388 are established between two peers and how authentication, integrity, 389 confidentiality and non-repudiation can be achieved. 391 In summary, this document defines the base protocol specification for 392 AAA. The MIPv4 and the NASREQ documents describe applications that 393 use this base specification to achieve Authentication, Authorization 394 and Accounting. The CMS Application describes a security application 395 for providing secure communication in the presence of relay and peer 396 agents. 398 1.2 Approach to Extensibility 400 The Diameter protocol is designed to be extensible. However, it is 401 strongly encouraged to reuse existing mechanism before attempting any 402 Diameter extensions. The extensibility includes: 404 - Defining new AVP values. 405 - Creating new AVPs 406 - Creating new authentication applications 407 - Creating a new Accounting Application 408 - Application Authentication Procedures 410 1.2.1 Defining New AVP Values 412 New applications should attempt to reuse AVPs defined in existing 413 application when possible, as opposed to creating a new AVP. For AVPs 414 of type Enumerated, it is possible the application requires a new 415 value to communicate some service-specific information. 417 In order to allocate a new AVP value, a request MUST be sent to IANA 418 [47], with a detailed explanation of the value. If the new AVP value 419 changes an existing command code's ABNF, the IANA AVP value request 420 MUST include the new ABNF itself. 422 1.2.2 Creating New AVPs 424 When no existing AVP can be used appropriately to communicate some 425 service-specific information, a new AVP should be created. The new 426 AVP being defined MUST follow one of the types listed in section 4.3. 428 In the event that a logical grouping of AVPs is necessary, and 429 multiple "groups" are possible in a given command, it is highly 430 recommended that a Grouped AVP be used (see Section 4.5). 432 In order to create a new AVP, a request MUST be sent to IANA, with a 433 detailed explanation of the AVP, its type and possible values. 434 Furthermore, the request MUST include the commands that would make 435 use of the AVP. 437 2.3.3 Creating New Auth Applications 439 Should a new application require Diameter support, but it cannot fit 440 within an existing application without requiring major changes to the 441 specification, it may be desirable to create a new Diameter 442 application. Major changes to an application include: 443 - Requiring a whole different set of mandatory AVPs to a command 444 - Requiring a command that has a different number of round trips 445 to satisfy a request (e.g. application foo has a command that 446 requires one round trip, but new application bar has a command 447 that requires two round trips to complete). 448 - The method used to authenticate the user is drastically 449 different from any existing application, and the authentication 450 information cannot be carried within the AVPs defined in the 451 application. 453 Note that the creation of a new application should be viewed as a 454 last resort. 456 New Diameter applications MUST define at least one Command Code, the 457 expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY 458 also define new AVPs. If the Diameter application has any accounting 459 requirements, it MUST also specify the AVPs that are to be present in 460 the Diameter Accounting messages (see section 9.3). 462 When possible, a new Diameter application SHOULD attempt to re-use 463 any existing Diameter AVP, in order to reduce the possibility of 464 having multiple AVPs that carry similar information. 466 Every Diameter application specification MUST have an IANA assigned 467 Application Identifier (see section 2.4). 469 1.2.4 Creating New Accounting Applications 471 There are services that only require the use of Diameter accounting. 472 Since such services need to define the service specific AVPs that 473 must be carried in the Accounting-Request/Answer messages, but do not 474 need to define command codes, the rules on allocation of Accounting 475 Application Identifiers is different from the ones defined in section 476 2.3.3. 478 When possible, a new Diameter accounting application SHOULD attempt 479 to re-use any existing Diameter AVP, in order to reduce the 480 possibility of having multiple AVPs that carry similar information. 482 Every Diameter accounting application specification MUST have an IANA 483 assigned Application Identifier (see section 2.4). 485 1.2.5 Application Authentication Procedures 487 When possible, applications SHOULD be designed such that new 488 authentication methods MAY be added without requiring changes to the 489 application. This MAY require that new AVP values be assigned to 490 represent the new authentication transform, or any other scheme that 491 produces similar results. When possible, authentication frameworks, 492 such as Extensible Authentication Protocol [EAP], SHOULD be used. 494 1.3 Requirements Language 496 In this document, the key words "MAY", "MUST", "MUST NOT", 497 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 498 interpreted as described in [KEYWORDS]. 500 1.4 Terminology 502 AAA 503 Authentication, Authorization and Accounting. 505 Accounting 506 The act of collecting information on resource usage for the 507 purpose of trend analysis, auditing, billing or cost allocation. 509 Accounting record 510 A session record represents a summary of the resource consumption 511 of a user over the entire session. Accounting gateways creating 512 the session record may do so by processing interim accounting 513 events or accounting events from several devices serving the same 514 user. 516 Authentication 517 The act of verifying the identity of an entity (subject). 519 Authorization 520 The act of determining whether a requesting entity (subject) will 521 be allowed access to a resource (object). 523 AVP 524 The Diameter protocol consists of a header followed by one or more 525 Attribute-Value-Pair (AVP). The AVP includes a header and is used 526 to encapsulate protocol-specific data (e.g. routing information) 527 as well as authentication, authorization or accounting 528 information. 530 Broker 531 A broker is a business term commonly used in AAA infrastructures. 532 A broker is either a relay, proxy or redirect agent, and MAY be 533 operated by roaming consortiums. 535 Diameter Agent 536 A Diameter Agent is a host that is providing either relay, proxy, 537 redirect or translation services. 539 Diameter Client 540 A Diameter Client is a device at the edge of the network that 541 performs access control. An example of a Diameter client is a 542 Network Access Server (NAS) or a Foreign Agent (FA). 544 Diameter Node 545 A Diameter node is a host that implements the Diameter protocol, 546 and acts either as a Client, Agent or Server. 548 Diameter Peer 549 A Diameter Peer is a Diameter Node to which a given Diameter Node 550 has a direct transport connection. 552 Diameter Server 553 A Diameter Server is one that handles authentication, 554 authorization and accounting requests for a particular realm. By 555 its very nature, a Diameter Server MUST support Diameter 556 applications in addition to the base protocol. 558 Downstream 559 Downstream is used to identify the direction of a particular 560 Diameter message from the home server towards the access device. 562 Home Realm 563 A Home Realm is the administrative domain with which the user 564 maintains an account relationship. 566 Home Server 567 See Diameter Server. 569 Interim accounting 570 An interim accounting message provides a snapshot of usage during 571 a user's session. It is typically implemented in order to provide 572 for partial accounting of a user's session in the event of a 573 device reboot or other network problem that prevents the reception 574 of a session summary message or session record. 576 Local Realm 577 A local realm is the administrative domain providing services to a 578 user. An administrative domain MAY act as a local realm for 579 certain users, while being a home realm for others. 581 Multi-session 582 A multi-session represents a logical linking of several sessions. 583 Multi-sessions are tracked by using the Accounting-Multi-Session- 584 Id. An example of a multi-session would be a MLP bundle. Each leg 585 of the bundle would be a session while the entire bundle would be 586 a multi-session. 588 Network Access Identifier 589 The Network Access Identifier, or NAI [NAI], is used in the 590 Diameter protocol to extract a user's identity and realm. The 591 identity is used to identify the user during authentication and/or 592 authorization, while the realm is used for message routing 593 purposes. 595 Proxy 596 In addition to forwarding requests and responses, proxies enforce 597 policies relating to resource usage and provisioning. This is 598 typically accomplished by tracking the state of NAS devices. While 599 proxies typically do not respond to client Requests prior to 600 receiving a Response from the server, they may originate Reject 601 messages in cases where policies are violated. As a result, 602 proxies need to understand the semantics of the messages passing 603 through them, and may not support all Diameter applications. 605 Realm 606 The string in the NAI that immediately follows the '@' character. 607 NAI realm names are required to be unique, and are piggybacked on 608 the administration of the DNS namespace. Diameter makes use of the 609 realm, also loosely referred to as domain, to determine whether 610 messages can be satisfied locally, or whether they must be routed 611 or redirected. 613 Real-time Accounting 614 Real-time accounting involves the processing of information on 615 resource usage within a defined time window. Time constraints are 616 typically imposed in order to limit financial risk. 618 Relay 619 Relays forward requests and responses based on routing-related 620 AVPs and realm routing table entries. Since relays do not enforce 621 policies, they do not examine or alter non-routing AVPs. As a 622 result, relays never originate messages, do not need to understand 623 the semantics of messages or non-routing AVPs, and are capable of 624 handling any Diameter application or message type. Since relays 625 make decisions based on information in routing AVPs and realm 626 forwarding tables they do not keep state on NAS resource usage or 627 conversations in progress. 629 Redirect Agent 630 Rather than forwarding requests and responses between clients and 631 servers, redirect agents refer clients to servers and allow them 632 to communicate directly. Since redirect agents do not sit in the 633 forwarding path, they do not alter any AVPs transiting between 634 client and server. Redirect agents do not originate messages and 635 are capable of handling any message type, although they may be 636 configured only to redirect messages of certain types, while 637 acting as Routing or Policy proxies for other types. As with 638 Routing proxies, redirect agents do not keep state with respect to 639 conversations or NAS resources. 641 Roaming Relationships 642 Roaming relationships include relationships between companies and 643 ISPs, relationships among peer ISPs within a roaming consortium, 644 and relationships between an ISP and a roaming consortia. 646 Session 647 A session is a related progression of events devoted to a 648 particular activity. Each application SHOULD provide guidelines as 649 to when a session begins and ends. All Diameter packets with the 650 same Session-Identifier are considered to be part of the same 651 session. 653 Sub-session 654 A sub-session represents a distinct service (e.g. QoS or data 655 characteristics) provided to a given session. These services may 656 happen concurrently (e.g. simultaneous voice and data transfer 657 during the same session) or serially. These changes in sessions 658 are tracked with the Accounting-Sub-Session-Id. An example of a 659 session divided into several sub-sessions would be a dial-up 660 connection in which the pre-authentication activity (call setup, 661 resource allocation, etc.), interactive login, and PPP 662 communication would all be sub-sessions. 664 Translation Agent 665 A translation agent is a stateful Diameter node that performs 666 protocol translation between Diameter and another AAA protocol. 668 Upstream 669 Upstream is used to identify the direction of a particular 670 Diameter message from the access device towards the home server. 672 2.0 Protocol Overview 674 The base Diameter protocol is never used on its own. It is always 675 extended for a particular application. Three Diameter applications 676 are defined by companion documents: NASREQ [NASREQ], Mobile IP 677 [DIAMMIP], CMS Security [CMS]. These applications are introduced in 678 this document but specified elsewhere. Additional Diameter 679 applications MAY be defined in the future (see Section 11.3). 681 Diameter Clients MUST support the base protocol, which includes 682 accounting. In addition, they MUST fully support each Diameter 683 application that is needed to implement the client's service, e.g. 684 NASREQ and/or Mobile IP. A Diameter Client that does not support both 685 NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" 686 where X is the application which it supports, and not a "Diameter 687 Client." 689 Diameter Servers MUST support the base protocol, which includes 690 accounting. In addition, they MUST fully support each Diameter 691 application that is needed to implement the intended service, e.g. 692 NASREQ and/or Mobile IP. A Diameter Server that does not support both 693 NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" 694 where X is the application which it supports, and not a "Diameter 695 Server." 697 Diameter Relays and Redirect agents are, by definition, protocol 698 transparent, and MUST transparently support the Diameter base 699 protocol, which includes accounting, and all Diameter applications. 701 Diameter Proxies MUST support the base protocol, which includes 702 accounting. In addition, they MUST fully support each Diameter 703 application that is needed to implement proxied services, e.g. NASREQ 704 and/or Mobile IP. A Diameter Proxy which does not support also both 705 NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" where 706 X is the application which it supports, and not a "Diameter Proxy." 708 The Diameter CMS security application [CMS] contains two features: 709 1. A set of messages that allows a Diameter node to establish a 710 security association, which is used to secure AVPs within a 711 Diameter message, even though the message may traverse 712 intermediate Diameter agents. A set of AVPs is also defined to 713 sign and encrypt AVPs, as well as to transport certificates. 714 This feature MUST be supported by Diameter server and proxy 715 agents, SHOULD be supported by Diameter clients, and MAY be 716 supported by relay and redirect agents. 717 2. A set of messages, known as PDSR and PDSA, allows a Diameter 718 client to request that an agent establish a Diameter security 719 association with a server in a specific realm. This feature 720 MUST be supported by Diameter clients and Proxy agents, and MAY 721 be supported by Diameter servers, relay and redirect agents. 723 The base Diameter protocol concerns itself with capabilities 724 negotiation, how messages are sent and how peers may eventually be 725 abandoned. The base protocol also defines certain rules that apply 726 to all exchanges of messages between Diameter nodes. 728 Communication between Diameter peers begins with one peer sending a 729 message to another Diameter peer. The set of AVPs included in the 730 message is determined by a particular Diameter application. One AVP 731 that is included to reference a user's session is the Session-Id. 733 The initial request for authentication and/or authorization of a user 734 would include the Session-Id. The Session-Id is then used in all 735 subsequent messages to identify the user's session (see section 8.0 736 for more information). The communicating party may accept the 737 request, or reject it by returning an answer message with Result-Code 738 AVP set to indicate an error occurred. The specific behavior of the 739 diameter server or client receiving a request depends on the Diameter 740 application employed. 742 Session state (associated with a Session-Id) MUST be freed upon 743 receipt of the Session-Termination-Request, Session-Termination- 744 Answer, expiration of authorized service time in the Session-Timeout 745 AVP, and according to rules established in a particular Diameter 746 application. 748 2.1 Transport 750 The base Diameter protocol is run on port TBD of both TCP [TCP] and 751 SCTP [SCTP] transport protocols (for interoperability test purposes 752 port 1812 will be used until IANA assigns a port to the protocol). 753 When used with TLS [TLS], the Diameter protocol is run on port TBD of 754 both TCP and SCTP. 756 Diameter clients MUST support either TCP or SCTP, while agents and 757 servers MUST support both. Future versions of this specification MAY 758 mandate that clients support SCTP. 760 A Diameter node MAY initiate connections from a source port other 761 than the one that it declares it accepts incoming connections on, and 762 MUST be prepared to receive connections on port TBD. A given Diameter 763 process MUST NOT use more than one transport connection to 764 communicate with a given peer, unless multiple processes exist on the 765 peer in which case a separate connection per process is allowed. 767 When no transport connection exists with a peer, an attempt to 768 connect SHOULD be periodically attempted. This behavior is handled 769 via the Tc timer, who's recommended value is 30 seconds. There are 770 certain exceptions to this rule, such as when a peer has terminated 771 the transport connection stating that it does not wish to 772 communicate. 774 When connecting to a peer, and either zero or more transports are 775 specified, SCTP SHOULD be tried first, followed by TCP. See section 776 5.2 for more information on peer discovery. 778 Diameter implementations SHOULD be able to interpret ICMP protocol 779 port unreachable messages as explicit indications that the server is 780 not reachable, in addition to interpreting ECONNREFUSED (a reset from 781 the transport) and timed-out connection attempts. 783 If Diameter receives data up from TCP that cannot be parsed or 784 identified as a Diameter error made by the peer, the stream is 785 compromised and cannot be recovered. The transport connection MUST 786 be closed using a RESET call (graceful closure is also compromised). 788 2.1.1 SCTP Guidelines 790 The following are guidelines for Diameter implementations that 791 support SCTP: 793 1. For interoperability: All Diameter nodes MUST be prepared to 794 receive Diameter messages on any SCTP stream in the 795 association. 796 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 797 streams available to the association to prevent head-of-the- 798 line blocking. 800 2.2 Securing Diameter Messages 802 Diameter clients, such as Network Access Servers (NASes) and Mobility 803 Agents MUST support IP Security [SEC ARCH], and MAY support TLS 804 [TLS]. Diameter servers MUST support TLS and IPsec. Operating the 805 Diameter protocol without any security mechanism is not recommended. 807 It is suggested that IPsec can be used primarily at the edges and in 808 intra-domain traffic, such as using pre-shared keys between a NAS a 809 local AAA proxy. This also eases the requirements on the NAS to 810 support certificates. It is also suggested that inter-domain traffic 811 would primarily use TLS. See sections 13.1 and 13.2 for more details 812 on IPsec and TLS usage. 814 2.3 Diameter Application Compliance 816 Application Identifiers are advertised during the capabilities 817 exchange phase (see section 2.5). For a given application, there are 818 two different ways of advertising support. First, advertising support 819 of the application via the Auth-Application-Id implies that the 820 sender supports all authentication and authorization command codes, 821 and the AVPs specified in the associated ABNFs, described in the 822 specification. Second, advertising support of the application via the 823 Acct-Application-Id implies that the sender supports the Accounting 824 command codes defined in this specification, as well as the 825 accounting AVPs defined in the application's specification. 827 An implementation MAY add arbitrary AVPs to any command defined in an 828 application, including vendor-specific AVPs. Please refer to section 829 4.6 for details. 831 2.4 Application Identifiers 833 Each Diameter application MUST have an IANA assigned Application 834 Identifier (see section 11.3). The base protocol does not require an 835 Application Identifier since its support is mandatory. During the 836 capabilities exchange, Diameter nodes inform their peers of locally 837 supported applications. Furthermore, all Diameter messages contain an 838 Application Identifier, which is used in the message forwarding 839 process. 841 The following Application Identifier values are defined: 843 NASREQ 1 [NASREQ] 844 CMS Security 2 [CMS] 845 Mobile-IP 4 [DIAMMIP] 846 Relay 0xffffffff 848 Relay and redirect agents MUST advertise the Relay Application 849 Identifier, while all other Diameter nodes MUST advertise locally 850 supported applications. The receiver of a Capabilities Exchange 851 message advertising Relay service MUST assume that the sender 852 supports all current and future applications. 854 Diameter relay and proxy agents are responsible for finding an 855 upstream server that supports the application of a particular 856 message. If none can be found, an error message is returned with the 857 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 859 2.5 Connections vs. Sessions 861 This section attempts to provide the reader with an understanding of 862 the difference between connection and session, which are terms used 863 extensively throughout this document. 865 A connection is a transport level connection between two peers, used 866 to send and receive Diameter messages. A session is a logical concept 867 at the application layer, and is shared between an access device and 868 a server, and is identified via the Session-Id AVP 870 +--------+ +-------+ +--------+ 871 | Client | | Relay | | Server | 872 +--------+ +-------+ +--------+ 873 <----------> <----------> 874 peer connection A peer connection B 876 <-----------------------------> 877 User session x 878 Figure 1: Diameter connections and sessions 880 In the example provided in figure 1, peer connection A is established 881 between the Client and its local Relay. Peer connection B is 882 established between the Relay and the Server. User session x spans 883 from the Client via the Relay to the Server. Each "user" of a service 884 causes an auth request to be sent, with a unique session identifier. 885 Once accepted by the server, both the client and the server are aware 886 of the session. It is important to note that there is no relationship 887 between a connection and a session, and that Diameter messages for 888 multiple sessions are all multiplexed through a single connection. 890 2.6 Peer Table 892 The Diameter Peer Table is used in message forwarding, and referenced 893 by the Realm Routing Table. A Peer Table entry contains the following 894 fields: 895 - Host identity. following the conventions described for the 896 DiameterIdentity derived AVP data format in section 4.4. This 897 field contains the contents of the Origin-Host AVP found in the 898 CER or CEA message. 899 - Status. This is the state of the peer entry, and MUST match one 900 of the values listed in section 5.6. 901 - Static or Dynamic. Specifies whether a peer entry was statically 902 configured, or dynamically discovered. 903 - Expiration time. Specifies the time at which dynamically 904 discovered peer table entries are to be either refreshed, or 905 expired. 906 - TLS Enabled. Specifies whether TLS is to be used when 907 communicating with the peer. 908 - Additional security information, when needed (e.g. keys, 909 certificates) 911 2.7 Realm-Based Routing Table 913 All Realm-Based routing lookups are performed against what is 914 commonly known as the Realm Routing Table (see section 12.0). A Realm 915 Routing Table Entry contains the following fields: 916 - Realm Name. This is the field that is typically used as a 917 primary key in the routing table lookups. Note that some 918 implementations perform their lookups based on longest-match- 919 from-the-right on the realm rather than requiring an exact 920 match. 921 - Application Identifier. A route entry can have a different 922 destination based on the Acct-Application-Id for accounting 923 messages) or Auth-Application-Id (for non-accounting messages) 924 of the message. This field MUST be used as a secondary key field 925 in routing table lookups. 926 - Local Action. The Local Action field is used to identify how a 927 message should be treated. The following actions are supported: 928 1. LOCAL - Diameter messages that resolve to a route entry 929 with the Local Action set to Local can be satisfied 930 locally, and do not need to be routed to another server. 931 2. RELAY - All Diameter messages that fall within this 932 category MUST be routed to a next hop server, without 933 modifying any non-routing AVPs. See section 6.1.8 for 934 relaying guidelines 935 3. PROXY - All Diameter messages that fall within this 936 category MUST be routed to a next hop server. The local 937 server MAY apply its local policies to the message by 938 including new AVPs to the message prior to routing. See 939 section 6.1.8 for proxying guidelines. 940 4. REDIRECT - Diameter messages that fall within this 941 category MUST have the identity of the home Diameter 942 server(s) appended, and returned to the sender of the 943 message. See section 6.1.7 for redirect guidelines. 944 - Server Identifier. One or more servers the message is to be 945 routed to. These servers MUST also be present in the Peer table. 946 When the Local Action is set to RELAY or PROXY, this field 947 contains the identity of the server(s) the message must be 948 routed to. When the Local Action field is set to REDIRECT, this 949 field contains the identity of one or more servers the message 950 should be redirected to. 951 - Static or Dynamic. Specifies whether a route entry was 952 statically configured, or dynamically discovered. 953 - Expiration time. Specifies the time which a dynamically 954 discovered route table entry expires. 956 It is important to note that Diameter agents MUST support at least 957 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents 958 do not need to support all modes of operation in order to conform 959 with the protocol specification, but MUST follow the protocol 960 compliance guidelines in section 2.0. Relay agents MUST NOT reorder 961 AVPs, and proxies MUST NOT reorder AVPs. 963 The routing table MAY include a default entry that MUST be used for 964 any requests not matching any of the other entries. The routing table 965 MAY consist of only such an entry. 967 When a request is routed, the target server MUST have advertised the 968 Application Identifier (see section 2.5) for the given message, or 969 have advertised itself as a relay or proxy agent. Otherwise, an error 970 is returned with the Result-Code AVP set to 971 DIAMETER_UNABLE_TO_DELIVER. 973 2.8 Role of Diameter Agents 975 In addition to client and servers, the Diameter protocol introduces 976 relay, proxy, redirect, and translation agents, each of which is 977 defined in Section 1.3. These Diameter agents are useful for several 978 reasons: 979 - They can distribute administration of systems to a configurable 980 grouping, including the maintenance of security associations. 981 - They can be used for concentration of requests from an number of 982 co-located or distributed NAS equipment sets to a set of like 983 user groups. 984 - They can do value-added processing to the requests or responses. 985 - They can be used for load balancing. 986 - A complex network will have multiple authentication sources, 987 they can sort requests and forward towards the correct target. 989 The Diameter protocol requires that agents maintain transaction 990 state, which is used for failover purposes. Transaction state implies 991 that upon forwarding a request, its Hop-by-Hop identifier is saved; 992 the field is replaced with a locally unique identifier, which is 993 restored to its original value when the corresponding answer is 994 received. The request's state is released upon receipt of the answer. 995 A stateless agent is one that only maintains transaction state. 997 The Proxy-Info AVP allows stateless agents to add local state to a 998 Diameter request, with the guarantee that the same state will be 999 present in the answer. However, the protocol's failover procedures 1000 require that agents maintain a copy of pending requests. 1002 A stateful agent is one that maintains session state information; by 1003 keeping track of all authorized active sessions. Each authorized 1004 session is bound to a particular service, and its state is considered 1005 active either until it is notified otherwise, or by expiration. Each 1006 authorized session has an expiration, which is communicated by 1007 Diameter servers via the Session-Timeout AVP. 1009 Maintaining session state MAY be useful in certain applications, such 1010 as: 1011 - Protocol translation (e.g. RADIUS <-> Diameter) 1012 - Limiting resources authorized to a particular user 1013 - Per user or transaction auditing 1015 A Diameter agent MAY act in a stateful manner for some requests and 1016 be stateless for others. A Diameter implementation MAY act as one 1017 type of agent for some requests, and as another type of agent for 1018 others. 1020 2.8.1 Relay Agents 1022 Relay Agents are Diameter agents that accept requests and route 1023 messages to other Diameter nodes based on information found in the 1024 messages (e.g. Destination-Realm). This routing decision is performed 1025 using a list of supported realms, and known peers. This is known as 1026 the Realm Routing Table, as is defined further in section 2.8. 1028 Relays MAY be used to aggregate requests from multiple Network Access 1029 Servers (NASes) within a common geographical area (POP). The use of 1030 Relays is advantageous since it eliminates the need for NASes to be 1031 configured with the necessary security information they would 1032 otherwise require to communicate with Diameter servers in other 1033 realms. Likewise, this reduces the configuration load on Diameter 1034 servers that would otherwise be necessary when NASes are added, 1035 changed or deleted. 1037 Relays modify Diameter messages by inserting, and removing routing 1038 information, but do not modify any other portion of a message. 1039 Further, Relays' inherent simplicity implies that they are stateless 1040 and therefore SHOULD NOT maintain session state but MUST maintain 1041 transaction state. 1043 +------+ ---------> +------+ ---------> +------+ 1044 | | 1. Request | | 2. Request | | 1045 | NAS | | DRL | | HMS | 1046 | | 4. Answer | | 3. Answer | | 1047 +------+ <--------- +------+ <--------- +------+ 1048 mno.net mno.net abc.com 1049 Figure 2: Relaying of Diameter messages 1051 The example provided in Figure 2 depicts a request issued from NAS, 1052 which is an access device, for the user bob@abc.com. Prior to issuing 1053 the request, NAS performs a Diameter route lookup, using "abc.com" as 1054 the key, and determines that the message is to be relayed to DRL, 1055 which is a Diameter Relay. DRL performs the same route lookup as NAS, 1056 and relays the message to HMS, which is abc.com's Home Diameter 1057 Server. HMS identifies that the request can be locally supported (via 1058 the realm), processes the authentication and/or authorization 1059 request, and replies with an answer, which is routed back to NAS 1060 using saved transaction state. 1062 Since Relays do not perform any application level processing, they 1063 provide relaying services for all Diameter applications, and 1064 therefore MUST advertise the Relay Application Identifier. 1066 2.8.2 Proxy Agents 1068 Similarly to Relays, Proxy agents route Diameter messages using the 1069 Diameter Routing Table. However, they differ since they modify 1070 messages to implement policy enforcement. This requires that proxies 1071 maintain the state of their downstream peers (e.g. access devices) to 1072 enforce resource usage, provide admission control, and provisioning. 1074 It is important to note that although proxies MAY provide a value-add 1075 function for NASes, they do not allow access devices to use the 1076 Diameter CMS Security application, since modifying messages breaks 1077 authentication. 1079 Proxies MAY be used in call control centers or access ISPs that 1080 provide outsourced connections, they can monitor the number and types 1081 of ports in use, and make allocation and admission decisions 1082 according to their configuration. 1084 Proxies that wish to limit resources MUST be stateful, and all 1085 Proxies MUST maintain transaction state. 1087 Proxy agents MUST NOT allow CMS security to be established between 1088 two peers if it expects to modify ANY non-routing AVP in messages 1089 exchanged between the peers. See [CMS] for more information. 1091 Since enforcing policies requires an understanding of the service 1092 being provided, Proxies MUST only advertise the Diameter applications 1093 they support. 1095 2.8.3 Redirect Agents 1097 Redirect agents provide Realm to Server address resolution and MAY 1098 also provide User to Server address resolution. These redirect agents 1099 would make use of the Diameter routing table or optionally, a user 1100 table to determine where a given request should be forwarded. When a 1101 request is received by a redirect agent, a special answer is created, 1102 which includes the identity of the Diameter server(s) the originator 1103 of the request should contact directly. 1105 Redirect agents are useful in scenarios where the Diameter routing 1106 configuration needs to be centralized. An example is a redirect agent 1107 that provides services to all members of a consortium, but does not 1108 wish to be burdened with relaying all messages between realms. This 1109 scenario is advantageous since it does not require that the 1110 consortium provide routing updates to its members when changes are 1111 made to a member's infrastructure. 1113 Since redirect agents do not relay messages, and only return an 1114 answer with the information necessary for Diameter agents to 1115 communicate directly, they do not modify messages. Since redirect 1116 agents do not receive answer messages, they cannot maintain session 1117 state. Further, since redirect agents never relay requests, they are 1118 not required to maintain transaction state. 1120 The example provided in Figure 3 depicts a request issued from the 1121 access device, NAS, for the user bob@abc.com. The message is 1122 forwarded by the NAS to its relay, DRL, which does not have a routing 1123 entry in its Diameter Routing Table for abc.com. DRL has a default 1124 route configured to DRD, which is a redirect agent that returns a 1125 redirect notification to DRL, as well as HMS' contact information. 1126 Upon receipt of the redirect notification, DRL establishes a 1127 transport connection with HMS, if one doesn't already exist, and 1128 forwards the request to it. 1130 +------+ 1131 | | 1132 | DRD | 1133 | | 1134 +------+ 1135 ^ | 1136 2. Request | | 3. Redirection 1137 | | Notification 1138 | v 1139 +------+ ---------> +------+ ---------> +------+ 1140 | | 1. Request | | 4. Request | | 1141 | NAS | | DRL | | HMS | 1142 | | 6. Answer | | 5. Answer | | 1143 +------+ <--------- +------+ <--------- +------+ 1144 mno.net mno.net abc.com 1145 Figure 3: Redirecting a Diameter Message 1147 Since Redirect agents do not perform any application level 1148 processing, they provide relaying services for all Diameter 1149 applications, and therefore MUST advertise the Relay Application 1150 Identifier. 1152 2.8.4 Translation Agents 1154 A Translation Agent is a device that provides translation between two 1155 protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation 1156 agents are likely to be used as aggregation servers to communicate 1157 with a Diameter infrastructure, while allowing for the embedded 1158 systems to be migrated at a slower pace. 1160 Given that the Diameter protocol introduces the concept of long-lived 1161 authorized sessions, translation agents MUST be session stateful and 1162 MUST maintain transaction state. 1164 Translation of messages can only occur if the agent recognizes the 1165 application of a particular request, and therefore translation agents 1166 MUST only advertise their locally supported applications. 1168 +------+ ---------> +------+ ---------> +------+ 1169 | | RADIUS Request | | Diameter Request | | 1170 | NAS | | TLA | | HMS | 1171 | | RADIUS Answer | | Diameter Answer | | 1172 +------+ <--------- +------+ <--------- +------+ 1173 mno.net mno.net abc.com 1174 Figure 4: Translation of RADIUS to Diameter 1176 3.0 Diameter Header 1178 A summary of the Diameter header format is shown below. The fields 1179 are transmitted in network byte order. 1181 0 1 2 3 1182 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 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Ver | Message Length | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 |R P E r r r r r| Command-Code | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Vendor-ID | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Hop-by-Hop Identifier | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | End-to-End Identifier | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | AVPs ... 1195 +-+-+-+-+-+-+-+-+-+-+-+-+- 1197 Version 1198 This Version field MUST be set to 1 to indicate Diameter Version 1199 1. 1201 Message Length 1202 The Message Length field is three octets and indicates the length 1203 of the Diameter message including the header fields. 1205 Command Flags 1206 The Command Flags field is eight bits. The following bits are 1207 assigned: 1209 R(equest) - If set, the message is a request. If cleared, the 1210 message is an answer. 1211 P(roxiable) - If set, the message MAY be proxied, relayed or 1212 redirected. If cleared, the message MUST be 1213 locally processed. 1214 E(rror) - If set, the message contains a protocol error, 1215 and the message will not conform to the ABNF 1216 described for this command. Messages with the 'E' 1217 bit set are commonly referred to as an error 1218 messages. This bit MUST NOT be set in request 1219 messages. See section 7.2. 1220 r(eserved) - these flag bits are reserved for future use, and 1221 MUST be set to zero, otherwise an error MUST be 1222 sent to the sender. 1224 Command-Code 1225 The Command-Code field is three octets, and is used in order to 1226 communicate the command associated with the message. The 24-bit 1227 address space is managed by IANA (see section 11.2). 1229 Vendor-ID 1230 In the event that the Command-Code field contains a vendor 1231 specific command, the four-octet Vendor-ID field contains the IANA 1232 assigned "SMI Network Management Private Enterprise Codes" [ASSIGN 1233 NO] value. If the Command-Code field contains an IETF standard 1234 Command, the Vendor-ID field MUST be set to zero (0). Any vendor 1235 wishing to implement a vendor-specific Diameter command MUST use 1236 their own Vendor-ID along with their privately managed Command- 1237 Code address space, guaranteeing that they will not collide with 1238 any other vendor's vendor-specific command, nor with future IETF 1239 applications. All vendor-specific Diameter commands require 1240 Information RFCs documenting the command. 1242 Hop-by-Hop Identifier 1243 The Hop-by-Hop Identifier is an Unsigned32 field and aids in 1244 matching requests and replies. The sender MUST ensure that the 1245 Hop-by-Hop identifier in a request is unique on a given connection 1246 at any given time, and MAY attempt to ensure that the number is 1247 unique across reboots. The sender of an Answer message MUST ensure 1248 that the Hop-by-Hop Identifier field contains the same value that 1249 was found in the corresponding request. The Hop-by-Hop identifier 1250 is normally a monotonically increasing number, whose start value 1251 was randomly generated. An answer message that is received with an 1252 unknown Hop-by-Hop Identifier MUST be discarded. 1254 End-to-End Identifier 1255 The End-to-End Identifier is an Unsigned32 field and is used to 1256 detect duplicate messages. Upon reboot implementations MAY set the 1257 high order 12 bits to contain the low order 12 bits of current 1258 time, and the low order 20 bits to a random value. Senders of 1259 request messages MUST insert a unique identifier on each message. 1260 The identifier MUST remain locally unique for a period of at least 1261 4 minutes, even across reboots. The originator of an Answer 1262 message MUST ensure that the End-to-End Identifier field contains 1263 the same value that was found in the corresponding request. The 1264 End-to-End Identifier MUST NOT be modified by relay agents. The 1265 combination of the Origin-Host and this field is used to detect 1266 duplicates. Duplicate requests SHOULD cause the same answer to be 1267 transmitted (modulo the hop-by-hop Identifier field and any 1268 routing AVPs that may be present), and MUST NOT affect any state 1269 that was set when the original request was processed. Duplicate 1270 answer messages that are to be locally consumed (see Section 6.2) 1271 SHOULD be silently discarded. 1273 AVPs 1274 AVPs are a method of encapsulating information relevant to the 1275 Diameter message. See section 4 for more information on AVPs. 1277 3.1 Command Codes 1279 Each command Request/Answer pair is assigned a command code, and the 1280 sub-type (i.e. - request or answer) is identified via the 'R' bit in 1281 the Command Flags field of the Diameter header. 1283 Every Diameter message MUST contain a command code in its header's 1284 Command-Code field, which is used to determine the action that is to 1285 be taken for a particular message. The following Command Codes are 1286 defined in the Diameter base protocol: 1288 Command-Name Abbrev. Code Reference 1289 -------------------------------------------------------- 1290 Abort-Session-Request ASR 274 8.5.1 1291 Abort-Session-Answer ASA 274 8.5.2 1292 Accounting-Request ACR 271 9.7.1 1293 Accounting-Answer ACA 271 9.7.2 1294 Capabilities-Exchange- CER 257 5.3.1 1295 Request 1296 Capabilities-Exchange- CEA 257 5.3.2 1297 Answer 1298 Device-Watchdog-Request DWR 280 5.5.1 1299 Device-Watchdog-Answer DWA 280 5.5.2 1300 Disconnect-Peer-Request DPR 282 5.4.1 1301 Disconnect-Peer-Answer DPA 282 5.4.2 1302 Re-Auth-Request RAR 258 8.3.1 1303 Re-Auth-Answer RAA 258 8.3.2 1304 Session-Termination- STR 275 8.4.1 1305 Request 1306 Session-Termination- STA 275 8.4.2 1307 Answer 1309 3.2 Command Code ABNF specification 1311 Every Command Code defined MUST include a corresponding ABNF 1312 specification, which is used to define the AVPs that MUST or MAY be 1313 present. The following format is used in the definition: 1315 command-def = command-name "::=" diameter-message 1317 command-name = diameter-name 1318 ; The command-name has to be Command name, 1319 ; defined in the base or extended Diameter 1320 ; specifications. 1322 diameter-name = ALPHA *(ALPHA / DIGIT / "-") 1324 diameter-message = header [ *fixed] [ *required] [ *optional] 1325 [ *fixed] 1327 header = "< Diameter-Header:" [vendor-id] command-id 1328 [r-bit] [p-bit] [e-bit] ">" 1330 vendor-id = 1*DIGIT ":" 1331 ; The optional vendor-id is used to define 1332 ; vendor specific commands 1334 command-id = 1*DIGIT 1335 ; The Command Code assigned to the command 1337 r-bit = ", REQ" 1338 ; If present, the 'R' bit in the Command 1339 ; Flags is set, indicating that the message 1340 ; is a request, as opposed to an answer. 1342 p-bit = ", PXY" 1343 ; If present, the 'P' bit in the Command 1344 ; Flags is set, indicating that the message 1345 ; is proxiable. 1347 e-bit = ", ERR" 1348 ; If present, the 'E' bit in the Command 1349 ; Flags is set, indicating that the answer 1350 ; message contains a Result-Code AVP in 1351 ; the "protocol error" class. 1353 fixed = [qual] "<" avp-spec ">" 1354 ; Defines the fixed position of an AVP 1356 required = [qual] "{" avp-spec "}" 1357 ; The AVP MUST be present and can appear 1358 ; anywhere in the message. 1360 optional = [qual] "[" avp-name "]" 1361 ; The avp-name in the 'optional' rule cannot 1362 ; evaluate to any AVP Name which is included 1363 ; in a fixed or required rule. The AVP can 1364 ; appear anywhere in the message. 1366 qual = [min] "*" [max] 1367 ; See ABNF conventions, RFC 2234 section 6.6. 1368 ; The absence of any qualifiers depends on whether 1369 ; it precedes a fixed, required, or optional 1370 ; rule. If a fixed or required rule has no 1371 ; qualifier, then exactly one such AVP MUST 1372 ; be present. If an optional rule has no 1373 ; qualifier, then 0 or 1 such AVP may be 1374 ; present. 1375 ; 1376 ; NOTE: "[" and "]" have a different meaning 1377 ; than in ABNF (see the optional rule, above). 1378 ; These braces cannot be used to express 1379 ; optional fixed rules (such as an optional 1380 ; ICV at the end.) To do this, the convention 1381 ; is '0*1fixed'. 1383 min = 1*DIGIT 1384 ; The minimum number of times the element may 1385 ; be present. The default value is zero. 1387 max = 1*DIGIT 1388 ; The maximum number of times the element may 1389 ; be present. The default value is infinity. A 1390 ; value of zero implies the AVP MUST NOT be 1391 ; present. 1393 avp-spec = diameter-name 1394 ; The avp-spec has to be an AVP Name, defined 1395 ; in the base or extended Diameter 1396 ; specifications. 1398 avp-name = avp-spec | "AVP" 1399 ; The string "AVP" stands for *any* arbitrary 1400 ; AVP Name, which does not conflict with the 1401 ; required or fixed position AVPs defined in 1402 ; the command code definition. 1404 The following is a definition of a fictitious command code: 1406 Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > 1407 { User-Name } 1408 * { Origin-Host } 1409 * [ AVP ] 1411 3.3 Diameter Command Naming Conventions 1413 Diameter commands typically includes one or more English words 1414 followed by the verb Request or Answer. Each English word is 1415 delimited by a hyphen. A three-letter acronym for both the request 1416 and answer is also normally provided. 1418 An example is a message set used to terminate a session. The command 1419 name is Session-Terminate-Request and Session-Terminate-Answer, while 1420 the acronyms are STR and STA, respectively. 1422 Both the request and the answer for a given command share the same 1423 command code. The request is identified by the R(equest) bit in the 1424 Diameter header set to one (1), to ask that a particular action be 1425 performed, such as authorizing a user or terminating a session. Once 1426 the receiver has completed the request it issues the corresponding 1427 answer, which includes a result code that communicates one of the 1428 following: 1430 - The request was successful 1431 - The request failed 1432 - An additional request must be sent to provide information the 1433 peer requires prior to returning a successful or failed answer. 1434 - The receiver could not process the request, but provides 1435 information about a Diameter peer that is able to satisfy the 1436 request, known as redirect. 1438 Additional information, encoded within AVPs, MAY also be 1439 included in answer messages. 1441 4.0 Diameter AVPs 1443 Diameter AVPs carry specific authentication, accounting, 1444 authorization, routing and security information as well as 1445 configuration details for the request and reply. 1447 Some AVPs MAY be listed more than once. The effect of such an AVP is 1448 specific, and is specified in each case by the AVP description. 1450 Each AVP of type OctetString MUST be padded to align on a 32-bit 1451 boundary, while other AVP types align naturally. NULL bytes are added 1452 to the end of the AVP Data field till a word boundary is reached. The 1453 length of the padding is not reflected in the AVP Length field. 1455 4.1 AVP Header 1457 The fields in the AVP header MUST be sent in network byte order. The 1458 format of the header is: 1460 0 1 2 3 1461 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 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | AVP Code | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 |V M P r r r r r| AVP Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Vendor-ID (opt) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Data ... 1470 +-+-+-+-+-+-+-+-+ 1472 AVP Code 1473 The AVP Code, combined with the Vendor-Id field, identifies the 1474 attribute uniquely. AVP numbers 0 through 255, with the Vendor-Id 1475 set to zero (0) are reserved for backward compatibility with 1476 RADIUS. AVP numbers 256 and above are used for Diameter, which are 1477 allocated by IANA (see section 11.1). 1479 AVP Flags 1480 The AVP Flags field informs the receiver how each attribute must 1481 be handled. The 'r' (reserved) bits are unused and SHOULD be set 1482 to 0. Note that subsequent Diameter applications MAY define 1483 additional bits within the AVP Header, and an unrecognized bit 1484 SHOULD be considered an error. The 'P' bit is defined in [CMS]. 1486 The 'M' Bit, known as the Mandatory bit, indicates whether support 1487 of the AVP is required. If an AVP with the 'M' bit set is received 1488 by a Diameter client, server, proxy, or translation agent and 1489 either the AVP or its value is unrecognized, the message MUST be 1490 rejected. Diameter Relay and Redirect agents MUST NOT reject 1491 messages with unrecognized AVPs. 1493 The 'M' bit MUST be set according to the rules defined for the AVP 1494 containing it. In order to preserve interoperability, a Diameter 1495 implementation MUST be able to exclude from a Diameter message any 1496 Mandatory AVP which is neither defined in the base Diameter 1497 standard nor in any of the Diameter Application specifications 1498 governing the message in which it appears. It MAY do this in one 1499 of the following ways: 1501 1) If a message is rejected because it contains a Mandatory AVP 1502 which is neither defined in the base Diameter standard nor in 1503 any of the Diameter Application specifications governing the 1504 message in which it appears, the implementation may resend the 1505 message without the AVP, possibly inserting additional standard 1506 AVPs instead. 1508 2) A configuration option may be provided on a system wide, per 1509 peer, or per realm basis that would allow/prevent particular 1510 Mandatory AVPs to be sent. Thus an administrator could change 1511 the configuration to avoid interoperability problems. 1513 Diameter implementations are required to support all Mandatory 1514 AVPs which are allowed by the message's formal syntax and defined 1515 either in the base Diameter standard or in one of the Diameter 1516 Application specifications governing the message. 1518 AVPs with the 'M' bit cleared are informational only and a 1519 receiver that receives a message with such an AVP that is not 1520 supported, or whose value is not supported, MAY simply ignore the 1521 AVP. 1523 The 'V' bit, known as the Vendor-Specific bit, indicates whether 1524 the optional Vendor-ID field is present in the AVP header. When 1525 set the AVP Code belongs to the specific vendor code address 1526 space. 1528 Unless otherwise noted, AVPs will have the following default AVP 1529 Flags field settings: 1531 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 1533 AVP Length 1534 The AVP Length field is three octets, and indicates the number of 1535 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1536 Vendor-ID field (if present) and the AVP data. If a message is 1537 received with an invalid attribute length, the message SHOULD be 1538 rejected. 1540 4.2 Optional Header Elements 1542 The AVP Header contains one optional field. This field is only 1543 present if the respective bit-flag is enabled. 1545 Vendor-ID 1546 The Vendor-ID field is present if the 'V' bit is set in the AVP 1547 Flags field. The optional four octet Vendor-ID field contains the 1548 IANA assigned "SMI Network Management Private Enterprise Codes" 1549 [ASSIGN NO] value, encoded in network byte order. Any vendor 1550 wishing to implement a vendor-specific Diameter AVP MUST use their 1551 own Vendor-ID along with their privately managed AVP address 1552 space, guaranteeing that they will not collide with any other 1553 vendor's vendor-specific AVP, nor with future IETF applications. 1555 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 1556 values, as managed by the IANA. Since the absence of the vendor ID 1557 field implies that the AVP in question is not vendor specific, 1558 implementations SHOULD NOT use the zero (0) vendor ID. 1560 4.3 AVP Base Data Format 1562 The Data field is zero or more octets and contains information 1563 specific to the Attribute. The format and length of the Data field is 1564 determined by the AVP Code and AVP Length fields. The format of the 1565 Data field MUST be one of the following base data types or a data 1566 type derived from the base data types. In the event that a new AVP 1567 Base Data Format is needed, a new version of this RFC must be 1568 created. 1570 OctetString 1571 The data contains arbitrary data of variable length. Unless 1572 otherwise noted, the AVP Length field MUST be set to at least 1573 8(12 if the 'V' bit is enabled). AVP Values of this type that 1574 are not a multiple of 4 octets in length be followed by the 1575 necessary padding so that the next AVP (if any) will start on a 1576 32-bit boundary. 1578 Integer32 1579 32 bit signed value, in network byte order. The AVP Length 1580 field MUST be set to 12 (16 if the 'V' bit is enabled). 1582 Integer64 1583 64 bit signed value, in network byte order. The AVP Length 1584 field MUST be set to 16 (20 if the 'V' bit is enabled). 1586 Unsigned32 1587 32 bit unsigned value, in network byte order. The AVP Length 1588 field MUST be set to 12 (16 if the 'V' bit is enabled). 1590 Unsigned64 1591 64 bit unsigned value, in network byte order. The AVP Length 1592 field MUST be set to 16 (20 if the 'V' bit is enabled). 1594 Float32 1595 This represents floating point values of single precision as 1596 described by [FLOATPOINT]. The 32-bit value is transmitted in 1597 network byte order. The AVP Length field MUST be set to 12 (16 1598 if the 'V' bit is enabled). 1600 Float64 1601 This represents floating point values of double precision as 1602 described by [FLOATPOINT]. The 64-bit value is transmitted in 1603 network byte order. The AVP Length field MUST be set to 16 (20 1604 if the 'V' bit is enabled). 1606 Grouped 1607 The Data field is specified as a sequence of AVPs. Each of 1608 these AVPs follows - in the order in which they are specified - 1609 including their headers and padding. The AVP Length field is 1610 set to 8 (12 if the 'V' bit is enabled) plus the total length 1611 of all included AVPs, including their headers and padding. Thus 1612 the AVP length field of an AVP of type Grouped is always a 1613 multiple of 4. 1615 Derived AVP Data Formats 1617 In addition to using the AVP Base Data Formats, applications may 1618 define data formats derived from the AVP Base Data Formats. An 1619 application that defines new AVP Derived Data Formats MUST include 1620 them in a section entitled "AVP Derived Data Formats", using the same 1621 format as the definitions below. Each new definition must be either 1622 defined or listed with a reference to the RFC that defines the 1623 format. 1625 The below AVP Derived Data Formats are commonly used by applications. 1627 IPAddress 1628 The IPAddress format is derived from the OctetString AVP Base 1629 Format. It represents 32 bit (IPv4) [IPV4] or 128-bit (IPv6) 1630 [IPV6] address, most significant octet first. The format of the 1631 address (IPv4 or IPv6) is determined by the length. If the 1632 attribute value is an IPv4 address, the AVP Length field MUST 1633 be 12 (16 if 'V' bit is enabled); otherwise, the AVP Length 1634 field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 1635 addresses. 1637 Time 1638 The Time format is derived from the OctetString AVP Base 1639 Format. The string MUST contain four octets, in the same format 1640 as the first four bytes are in the NTP timestamp format. The 1641 NTP Timestamp format is defined in chapter 3 of [SNTP]. 1643 This represents the number of seconds since 0h on 1 January 1644 1900 with respect to the Coordinated Universal Time (UTC). 1646 On 6h 28m 16s UTC, 7 February 2036 the time value will 1647 overflow. SNTP [SNTP] describes a procedure to extend the time 1648 to 2104. This procedure MUST be used by all DIAMETER nodes. 1650 UTF8String 1651 The UTF8String format is derived from the OctetString AVP Base 1652 Format. This is a human readable string represented using the 1653 ISO/IEC IS 10646-1 character set, encoded as an OctetString 1654 using the UTF-8 [UFT8] transformation format described in RFC 1655 2279. 1657 Since additional code points are added by amendments to the 1658 10646 standard from time to time, implementations MUST be 1659 prepared to encounter any code point from 0x00000001 to 1660 0x7fffffff. Byte sequences that do not correspond to the valid 1661 UTF-8 encoding of a code point or are outside this range are 1662 prohibited. 1664 The use of control codes SHOULD be avoided. When it is 1665 necessary to represent a newline, the control code sequence CR 1666 LF SHOULD be used. 1668 The use of leading or trailing white space SHOULD be avoided. 1670 For code points not directly supported by user interface 1671 hardware or software, an alternative means of entry and 1672 display, such as hexadecimal, MAY be provided. 1674 For information encoded in 7-bit US-ASCII, the UTF-8 encoding 1675 is identical to the US-ASCII encoding. 1677 UTF-8 may require multiple bytes to represent a single 1678 character / code point; thus the length of an UTF8String in 1679 octets may be different from the number of characters encoded. 1681 Note that the size of an UTF8String is measured in octets, not 1682 characters. 1684 DiameterIdentity 1685 The DiameterIdentity format is derived from the OctetString AVP 1686 Base Format. It uses the UTF-8 encoding and has the same 1687 requirements as the UTF8String: 1689 DiameterIdentity = fqdn 1691 A Diameter node must be uniquely identified by its 1692 DiameterIdentity, which contains the fqdn of the Diameter node. 1693 If multiple Diameter nodes run on the same host, each Diameter 1694 node MUST be assigned a unique DiameterIdentity. If a Diameter 1695 node can be identified by several FQDNs, one single FQDN should 1696 be picked at startup, and used as the only DiameterIdentity for 1697 that node, whatever the connection it is sent on. The 1698 DiameterIdentity value is used to uniquely identify a Diameter 1699 node for purposes of duplicate connection and routing loop 1700 detection. 1702 DiameterURI 1704 The DiameterURI MUST follow the Uniform Resource Identifiers (URI) 1705 syntax [URI] rules specified below: 1707 "aaa://" fqdn [ port ] [ transport ] [ protocol ] 1709 ; No transport security 1711 "aaas://" fqdn [ port ] [ transport ] [ protocol ] 1713 ; Transport security used 1715 fqdn = Fully Qualified Host Name 1717 port = ":" 1*DIGIT 1719 ; One of the ports used to listen for ; 1720 incoming connections. ; If absent, ; the 1721 default Diameter port (TBD) is ; assumed. 1723 transport = ";transport=" transport-protocol 1725 ; One of the transports used to listen ; for 1726 incoming connections. If absent, ; the default 1727 SCTP [SCTP] protocol is ; assumed. UDP MUST NOT 1728 be used when ; the aaa-protocol field is set to 1729 ; diameter. 1731 transport-protocol = ( "tcp" | "sctp" | "udp" ) 1733 protocol = ";protocol=" aaa-protocol 1735 ; If absent, the default AAA protocol ; is 1736 diameter. 1738 aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) 1740 The following are examples of valid Diameter host identities: 1742 aaa://host.abc.com;transport=tcp 1743 aaa://host.abc.com:6666;transport=tcp 1744 aaa://host.abc.com;protocol=diameter 1745 aaa://host.abc.com:6666;protocol=diameter 1746 aaa://host.abc.com:6666;transport=tcp;protocol=diameter 1747 aaa://host.abc.com:1813;transport=udp;protocol=radius 1748 aaas://host.abc.com;transport=tcp 1749 aaas://host.abc.com;protocol=diameter 1751 Enumerated 1752 Enumerated is derived from the Integer32 AVP Base Format. This 1753 contains a list of valid values and their interpretation and is 1754 described in the Diameter application introducing the AVP. 1756 IPFilterRule 1757 The IPFilterRule format is derived from the OctetString AVP 1758 Base Format. It uses the UTF-8 encoding and has the same 1759 requirements as the UTF8String. Packets may be filtered based 1760 on the following information that is associated with it: 1762 Direction (in or out) 1763 Source and destination IP address (possibly masked) 1764 Protocol 1765 Source and destination port (lists or ranges) 1766 TCP flags 1767 IP fragment flag 1768 IP options 1769 ICMP types 1771 Rules for the appropriate direction are evaluated in order, 1772 with the first matched rule terminating the evaluation. Each 1773 packet is evaluated once. If no rule matches, the packet is 1774 dropped if the last rule evaluated was a permit, and passed if 1775 the last rule was a deny. 1777 IPFilterRule filters MUST follow the format: 1779 action dir proto from src to dst [options] 1781 action permit - Allow packets that match the rule. 1782 deny - Drop packets that match the rule. 1784 dir "in" is from the terminal, "out" is to the 1785 terminal. 1787 proto An IP protocol specified by number. The "ip" 1788 keyword means any protocol will match. 1790 src and dst
[ports] 1791 The
may be specified as: 1792 ipno An IPv4 or IPv6 number in dotted- 1793 quad or canonical IPv6 form. Only 1794 this exact IP number will match the 1795 rule. 1796 ipno/bits An IP number as above with a mask 1797 width of the form 1.2.3.4/24. In 1798 this case all IP numbers from 1799 1.2.3.0 to 1.2.3.255 will match. 1800 The bit width MUST be valid for the 1801 IP version and the IP number MUST 1802 NOT have bits set beyond the mask. 1804 The sense of the match can be inverted by 1805 preceding an address with the not modifier (!), 1806 causing all other addresses to be matched 1807 instead. This does not affect the selection of 1808 port numbers. 1810 The keyword "any" is 0.0.0.0/0 or the IPv6 1811 equivalent. The keyword "assigned" is the 1812 address or set of addresses assigned to the 1813 terminal. The first rule SHOULD be "deny in 1814 ip !assigned". 1816 With the TCP, UDP and SCTP protocols, optional 1817 ports may be specified as: 1819 {port|port-port}[,ports[,...]] 1821 The `-' notation specifies a range of ports 1822 (including boundaries). 1824 Fragmented packets that have a non-zero offset 1825 (i.e. not the first fragment) will never match 1826 a rule that has one or more port 1827 specifications. See the frag option for 1828 details on matching fragmented packets. 1830 options: 1831 frag Match if the packet is a fragment and this is not 1832 the first fragment of the datagram. frag may not 1833 be used in conjunction with either tcpflags or 1834 TCP/UDP port specifications. 1836 ipoptions spec 1837 Match if the IP header contains the comma 1838 separated list of options specified in spec. The 1839 supported IP options are: 1841 ssrr (strict source route), lsrr (loose source 1842 route), rr (record packet route) and ts 1843 (timestamp). The absence of a particular option 1844 may be denoted with a `!'. 1846 tcpoptions spec 1847 Match if the TCP header contains the comma 1848 separated list of options specified in spec. The 1849 supported TCP options are: 1851 mss (maximum segment size), window (tcp window 1852 advertisement), sack (selective ack), ts (rfc1323 1853 timestamp) and cc (rfc1644 t/tcp connection 1854 count). The absence of a particular option may 1855 be denoted with a `!'. 1857 established 1858 TCP packets only. Match packets that have the RST 1859 or ACK bits set. 1861 setup TCP packets only. Match packets that have the SYN 1862 bit set but no ACK bit. 1864 tcpflags spec 1865 TCP packets only. Match if the TCP header 1866 contains the comma separated list of flags 1867 specified in spec. The supported TCP flags are: 1869 fin, syn, rst, psh, ack and urg. The absence of a 1870 particular flag may be denoted with a `!'. A rule 1871 that contains a tcpflags specification can never 1872 match a fragmented packet that has a non-zero 1873 offset. See the frag option for details on 1874 matching fragmented packets. 1876 icmptypes types 1877 ICMP packets only. Match if the ICMP type is in 1878 the list types. The list may be specified as any 1879 combination of ranges or individual types 1880 separated by commas. The supported ICMP types 1881 are: 1883 echo reply (0), destination unreachable (3), 1884 source quench (4), redirect (5), echo request 1885 (8), router advertisement (9), router 1886 solicitation (10), time-to-live exceeded (11), IP 1887 header bad (12), timestamp request (13), 1888 timestamp reply (14), information request (15), 1889 information reply (16), address mask request (17) 1890 and address mask reply (18). 1892 There is one kind of packet that the access device MUST always 1893 discard, that is an IP fragment with a fragment offset of one. 1894 This is a valid packet, but it only has one use, to try to 1895 circumvent firewalls. 1897 An access device that is unable to interpret or apply a deny 1898 rule MUST terminate the session. An access device that is 1899 unable to interpret or apply a permit rule MAY apply a more 1900 restrictive rule. An access device MAY apply deny rules of 1901 its own before the supplied rules, for example to protect 1902 the access device owner's infrastructure. 1904 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 1905 and the ipfw.c code may provide a useful base for 1906 implementations. 1908 QoSFilterRule 1909 The QosFilterRule format is derived from the OctetString AVP 1910 Base Format. It uses the UTF-8 encoding and has the same 1911 requirements as the UTF8String. Packets may be marked or 1912 metered based on the following information that is associated 1913 with it: 1915 Direction (in or out) 1916 Source and destination IP address (possibly masked) 1917 Protocol 1918 Source and destination port (lists or ranges) 1919 DSCP values (no mask or range) 1921 Rules for the appropriate direction are evaluated in order, 1922 with the first matched rule terminating the evaluation. Each 1923 packet is evaluated once. If no rule matches, the packet is 1924 treated as best effort. 1926 QoSFilterRule filters MUST follow the format: 1928 action dir proto from src to dst [options] 1930 tag - Mark packet with a specific DSCP 1931 [DIFFSERV]. The DSCP option MUST be 1932 included. 1933 meter - Meter traffic. The metering options 1934 MUST be included. 1936 dir "in" is from the terminal, "out" is to the 1937 terminal. 1939 proto An IP protocol specified by number. The "ip" 1940 keyword means any protocol will match. 1942 src and dst
[ports] 1944 The
may be specified as: 1945 ipno An IPv4 or IPv6 number in dotted- 1946 quad or canonical IPv6 form. Only 1947 this exact IP number will match the 1948 rule. 1949 ipno/bits An IP number as above with a mask 1950 width of the form 1.2.3.4/24. In 1951 this case all IP numbers from 1952 1.2.3.0 to 1.2.3.255 will match. 1953 The bit width MUST be valid for the 1954 IP version and the IP number MUST 1955 NOT have bits set beyond the mask. 1957 The sense of the match can be inverted by 1958 preceding an address with the not modifier (!), 1959 causing all other addresses to be matched 1960 instead. This does not affect the selection of 1961 port numbers. 1963 The keyword "any" is 0.0.0.0/0 or the IPv6 1964 equivalent. The keyword "assigned" is the 1965 address or set of addresses assigned to the 1966 terminal. The first rule SHOULD be "deny in 1967 ip !assigned". 1969 With the TCP, UDP and SCTP protocols, optional 1970 ports may be specified as: 1972 {port|port-port}[,ports[,...]] 1974 The `-' notation specifies a range of ports 1975 (including boundaries). 1977 options: 1979 DSCP 1980 color values as defined in [DIFFSERV]. Exact 1981 matching of DSCP values is required (no masks or 1982 ranges). 1984 metering 1985 The metering option provides Assured Forwarding, 1986 as defined in [DIFFSERVAF], and MUST be present 1987 if the action is set to meter. The rate option is 1988 the throughput, in bits per second, which is used 1989 by the access device to mark packets. Traffic 1990 above the rate is marked with the color_over 1991 codepoint, while traffic under the rate is marked 1992 with the color_under codepoint. The color_under 1993 and color_over options contain the drop 1994 preferences, and MUST conform to the recommended 1995 codepoint keywords described in [DIFFSERVAF] 1996 (e.g. AF13). 1998 The metering option also supports the strict 1999 limit on traffic required by Expedited 2000 Forwarding, as defined in [DIFFSERVEF]. The 2001 color_over option may contain the keyword "drop" 2002 to prevent forwarding of traffic that exceeds the 2003 rate parameter. 2005 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 2006 and the ipfw.c code may provide a useful base for 2007 implementations. 2009 4.5 Grouped AVP Values 2011 The Diameter protocol allows AVP values of type 'Grouped.' This 2012 implies that the Data field is actually a sequence of AVPs. It is 2013 possible to include an AVP with a Grouped type within a Grouped type, 2014 that is, to nest them. AVPs within an AVP of type Grouped have the 2015 same padding requirements as non-Grouped AVPs, as defined in section 2016 4.0. 2018 The AVP Code numbering space of all AVPs included in a Grouped AVP is 2019 the same as for non-grouped AVPs. Further, if any of the AVPs 2020 encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, 2021 the Grouped AVP itself MUST also include the 'M' bit set. 2023 Every Grouped AVP defined MUST include a corresponding grammar, using 2024 ABNF [ABNF] (with modifications), as defined below. 2026 avp-def = name "::=" avp 2028 name-fmt = ALPHA *(ALPHA / DIGIT / "-") 2030 name = name-fmt 2031 ; The name has to be the name of an AVP, 2032 ; defined in the base or extended Diameter 2033 ; specifications. 2035 avp = header [ *fixed] [ *required] [ *optional] 2036 [ *fixed] 2038 header = "" 2040 avpcode = 1*DIGIT 2041 ; The AVP Code assigned to the Grouped AVP 2043 vendor = 1*DIGIT 2044 ; The Vendor-ID assigned to the Grouped AVP. 2045 ; If absent, the default value of zero is 2046 ; used. 2048 fixed = [qual] "<" avp-spec ">" 2050 required = [qual] "{" avp-spec "}" 2052 optional = [qual] "[" avp-name "]" 2053 ; The avp-name in the 'optional' rule cannot 2054 ; evaluate to any AVP Name which is included 2055 ; in a fixed or required rule. 2057 qual = [min] "*" [max] 2058 ; See ABNF conventions, RFC 2234 section 6.6. 2059 ; The absence of any qualifiers implies that 2060 ; one and only one such AVP MUST be present. 2061 ; 2062 ; NOTE: "[" and "]" have a different meaning 2063 ; than in ABNF (see the optional rule, above). 2064 ; These braces cannot be used to express 2065 ; optional fixed rules (such as an optional 2066 ; ICV at the end.) To do this, the convention 2067 ; is '0*1fixed'. 2069 min = 1*DIGIT 2070 ; The minimum number of times the element may 2071 ; be present. 2073 max = 1*DIGIT 2074 ; The maximum number of times the element may 2075 ; be present. 2077 avp-spec = name-fmt 2078 ; The avp-spec has to be an AVP Name, defined 2079 ; in the base or extended Diameter 2080 ; specifications. 2082 avp-name = avp-spec | "AVP" 2083 ; The string "AVP" stands for *any* arbitrary 2084 ; AVP Name, which does not conflict with the 2085 ; required or fixed position AVPs defined in 2086 ; the command code definition. 2088 4.5.1 Example AVP with a Grouped Data type 2090 The Example-AVP (AVP Code 999999) is of type Grouped and is used to 2091 clarify how Grouped AVP values work. The Grouped Data field has the 2092 following ABNF grammar: 2094 Example-AVP ::= < AVP Header: 999999 > 2095 { Origin-Host } 2096 1*{ Session-Id } 2097 *[ AVP ] 2099 An Example-AVP with Grouped Data follows. 2101 The Origin-Host AVP is required. In this case: 2103 Origin-Host = "abc.com". 2105 One or more Session-Ids must follow. Here there are two: 2107 Session-Id = 2108 "grump.abc.com:33041;23432;893;0AF3B81" 2110 Session-Id = 2111 "grump.abc.com:33054;23561;2358;0AF3B82" 2113 optional AVPs included are 2115 Recovery-Policy = 2116 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2117 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 2118 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd 2119 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a 2120 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 2121 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 2122 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 2124 Futuristic-Acct-Record = 2125 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 2126 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 2127 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 2128 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 2129 d3427475e49968f841 2131 The data for the optional AVPs is represented in hex since the format 2132 of these AVPs is neither known at the time of definition of the 2133 Example-AVP group, nor (likely) at the time when the example instance 2134 of this AVP is interpreted - except by Diameter implementations which 2135 support the same set of AVPs. The encoding example illustrates how 2136 padding is used and how length fields are calculated. Also note that 2137 AVPs may be present in the Grouped AVP value which the receiver 2138 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record 2139 AVPs). 2141 This AVP would be encoded as follows: 2143 0 1 2 3 4 5 6 7 2144 +-------+-------+-------+-------+-------+-------+-------+-------+ 2145 0 | Example AVP Header (AVP Code = 999999), Length = 468 | 2146 +-------+-------+-------+-------+-------+-------+-------+-------+ 2147 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | 2148 +-------+-------+-------+-------+-------+-------+-------+-------+ 2149 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 2150 +-------+-------+-------+-------+-------+-------+-------+-------+ 2151 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | 2152 +-------+-------+-------+-------+-------+-------+-------+-------+ 2153 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | 2154 +-------+-------+-------+-------+-------+-------+-------+-------+ 2155 . . . 2156 +-------+-------+-------+-------+-------+-------+-------+-------+ 2157 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| 2158 +-------+-------+-------+-------+-------+-------+-------+-------+ 2159 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | 2160 +-------+-------+-------+-------+-------+-------+-------+-------+ 2161 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | 2162 +-------+-------+-------+-------+-------+-------+-------+-------+ 2163 . . . 2164 +-------+-------+-------+-------+-------+-------+-------+-------+ 2165 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| 2166 +-------+-------+-------+-------+-------+-------+-------+-------+ 2167 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | 2168 +-------+-------+-------+-------+-------+-------+-------+-------+ 2169 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | 2170 +-------+-------+-------+-------+-------+-------+-------+-------+ 2171 . . . 2172 +-------+-------+-------+-------+-------+-------+-------+-------+ 2173 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| 2174 +-------+-------+-------+-------+-------+-------+-------+-------+ 2175 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| 2176 +-------+-------+-------+-------+-------+-------+-------+-------+ 2177 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 2178 +-------+-------+-------+-------+-------+-------+-------+-------+ 2179 . . . 2180 +-------+-------+-------+-------+-------+-------+-------+-------+ 2181 464 | 0x41 |Padding|Padding|Padding| 2182 +-------+-------+-------+-------+ 2184 4.6 Diameter Base Protocol AVPs 2186 The following table describes the Diameter AVPs defined in the base 2187 protocol, their AVP Code values, types, possible flag values and 2188 whether the AVP MAY be encrypted. For the originator of a Diameter 2189 message, "MAY Encr" means that if a message containing that AVP is 2190 to be sent via a proxy/agent then the message MUST NOT be sent 2191 unless there is a DSA between the originator and the recipient OR 2192 the originator has locally trusted configuration that indicates that 2193 CMS need not be used. 2195 Due to space constraints, the short form DiamIdent is used to 2196 represent DiameterIdentity. 2198 +---------------------+ 2199 | AVP Flag rules | 2200 |----+-----+----+-----|----+ 2201 AVP Section | | |SHLD| MUST|MAY | 2202 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2203 -----------------------------------------|----+-----+----+-----|----| 2204 Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y | 2205 Interim-Interval | | | | | | 2206 Accounting- 483 9.8.7 Unsigned32 | M | P | | V | Y | 2207 Realtime-Required | | | | | | 2208 Accounting- 50 9.8.5 UTF8String | M | P | | V | Y | 2209 Multi-Session-Id | | | | | | 2210 Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | 2211 Record-Number | | | | | | 2212 Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | 2213 Record-Type | | | | | | 2214 Accounting- 44 9.8.4 OctetString| M | P | | V | Y | 2215 RADIUS-Session-Id | | | | | | 2216 Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y | 2217 Sub-Session-Id | | | | | | 2218 Acct- 259 6.9 Integer32 | M | P | | V | N | 2219 Application-Id | | | | | | 2220 Auth- 258 6.8 Integer32 | M | P | | V | N | 2221 Application-Id | | | | | | 2222 Auth-Request- 274 8.7 Enumerated | M | P | | V | N | 2223 Type | | | | | | 2224 Authorization- 291 8.9 Unsigned32 | M | P | | V | N | 2225 Lifetime | | | | | | 2226 Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | 2227 Period | | | | | | 2228 Auth-Session- 277 8.11 Enumerated | M | P | | V | N | 2229 State | | | | | | 2230 Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | 2231 Type | | | | | | 2232 Class 25 8.20 OctetString| M | P | | V | Y | 2233 Destination-Host 293 6.5 DiamIdent | M | P | | V | N | 2234 Destination- 283 6.6 UTF8String | M | P | | V | N | 2235 Realm | | | | | | 2236 Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N | 2237 Error-Message 281 7.3 OctetString| | P | | V,M | N | 2238 Error-Reporting- 294 7.4 UTF8String | | P | | V,M | N | 2239 Host | | | | | | 2240 Failed-AVP 279 7.5 Grouped | M | P | | V | N | 2241 Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N | 2242 Revision | | | | | | 2243 Host-IP-Address 257 5.3.5 IPAddress | M | P | | V | N | 2244 -----------------------------------------|----+-----+----+-----|----| 2245 +---------------------+ 2246 | AVP Flag rules | 2247 |----+-----+----+-----|----+ 2248 AVP Section | | |SHLD| MUST|MAY | 2249 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2250 -----------------------------------------|----+-----+----+-----|----| 2251 Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | 2252 Time-Out | | | | | | 2253 Origin-Host 264 6.3 DiamIdent | M | P | | V | N | 2254 Origin-Realm 296 6.4 UTF8String | M | P | | V | N | 2255 Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N | 2256 Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N | 2257 Proxy-Host 280 6.7.3 IPAddress | M | | | P,V | N | 2258 Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N | 2259 Proxy-State 33 6.7.4 OctetString| M | | | P,V | N | 2260 Redirect-Host 292 6.11 DiamURI | M | P | | V | N | 2261 Redirect-Host- 261 6.12 Enumerated | M | P | | V | N | 2262 Usage | | | | | | 2263 Redirect-Max- 262 6.13 Unsigned32 | M | P | | V | N | 2264 Cache-Time | | | | | | 2265 Result-Code 268 7.1 Unsigned32 | M | P | | V | N | 2266 Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N | 2267 Session-Id 263 8.8 UTF8String | M | P | | V | Y | 2268 Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N | 2269 Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y | 2270 Session-Server- 271 8.18 Enumerated | M | P | | V | Y | 2271 Failover | | | | | | 2272 Supported- 265 5.3.6 Unsigned32 | M | P | | V | N | 2273 Vendor-Id | | | | | | 2274 Termination- 295 8.15 Enumerated | M | P | | V | N | 2275 Cause | | | | | | 2276 User-Name 1 8.14 UTF8String | M | P | | V | Y | 2277 Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V | N | 2278 Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | 2279 Application-Id | | | | | | 2280 -----------------------------------------|----+-----+----+-----|----| 2282 5.0 Diameter Peers 2284 This section describes how Diameter nodes establish connections and 2285 communicate with peers. 2287 5.1 Peer Connections 2289 Although a Diameter node may have many possible peers that it is able 2290 to communicate with, it may not be economical to have an established 2291 connection to all of them. At a minimum, a Diameter node SHOULD have 2292 an established connection with two peers per realm, known as the 2293 primary and secondary peers. Of course, a node MAY have additional 2294 connections, if it is deemed necessary. Typically, all messages for a 2295 realm are sent to the primary peer, but in the event that failover 2296 procedures are invoked, any pending requests are sent to the 2297 secondary peer. However, implementations are free to load balance 2298 requests between a set of peers. 2300 Note that a given peer MAY act as a primary for a given realm, while 2301 acting as a secondary for another realm. 2303 When a peer is deemed suspect, which could occur for various reasons, 2304 including not receiving a DWA within an allotted timeframe, no new 2305 requests should be forwarded to the peer, but failover procedures are 2306 not invoked. When an active peer is moved to this mode, additional 2307 connections SHOULD be established to ensure that the necessary number 2308 of active connections exists. 2310 There are two ways that a peer is removed from the suspect peer list: 2311 1. The peer is no longer reachable, causing the transport 2312 connection to be shutdown. The peer is moved to the closed 2313 state. 2314 2. Three watchdog messages are exchanged with accepted round trip 2315 times, and the connection to the peer is considered stabilized. 2317 In the event the peer being removed is either the primary or 2318 secondary, an alternate peer SHOULD replace the deleted peer, and 2319 assume the role of either primary or secondary. 2321 5.2 Diameter Peer Discovery 2323 Allowing for dynamic Diameter agent discovery will make it possible 2324 for simpler and more robust deployment of Diameter services. In 2325 order to promote interoperable implementations of Diameter peer 2326 discovery, the following mechanisms are described. These are based 2327 on existing IETF standards. The first option (manual configuration) 2328 MUST be supported by all DIAMETER nodes, while the latter two options 2329 (SRVLOC and DNS) MAY be supported. 2331 There are two cases where Diameter peer discovery may be performed. 2332 The first is when a Diameter client needs to discover a first-hop 2333 Diameter agent. The second case is when a Diameter agent needs to 2334 discover another agent - for further handling of a Diameter 2335 operation. In both cases, the following 'search order' is 2336 recommended: 2338 1. The Diameter implementation consults its list of static 2339 (manual) configured Diameter agent locations. These will be 2340 used if they exist and respond. 2342 2. The Diameter implementation uses SLPv2 [SLP] to discover 2343 Diameter services. The Diameter service template [TEMPLATE] is 2344 included in Appendix A. It is recommended that SLPv2 security 2345 be deployed (this requires distributing keys to SLPv2 agents). 2346 This is discussed further in Appendix A. 2348 SLPv2 will allow Diameter implementations to discover the 2349 location of Diameter agents in the local site, as well as their 2350 characteristics. Diameter agents with specific capabilities 2351 (say support for the Mobile IP application) can be requested, 2352 and only those will be discovered. 2354 3. The Diameter implementation performs a NAPTR query for a server 2355 in a particular realm. The Diameter implementation has to know 2356 in advance which realm to look for a Diameter agent in. This 2357 could be deduced, for example, from the 'realm' in a NAI that a 2358 Diameter implementation needed to perform a Diameter operation 2359 on. 2361 3.1 The services relevant for the task of transport protocol 2362 selection are those with NAPTR service fields with values 2363 "AAA+D2x" and "AAAS+D2X", where x is a letter that 2364 corresponds to a transport protocol supported by the domain. 2365 This specification defines D2T for TCP and D2S for SCTP. We 2366 also establish an IANA registry for NAPTR service name to 2367 transport protocol mappings. 2369 These NAPTR records provide a mapping from a domain, to the 2370 SRV record for contacting a server with the specific 2371 transport protocol in the NAPTR services field. The resource 2372 record will contain an empty regular expression and a 2373 replacement value, which is the SRV record for that 2374 particular transport protocol. If the server supports 2375 multiple transport protocols, there will be multiple NAPTR 2376 records, each with a different service value. As per RFC 2377 2915 [NAPTR], the client discards any records whose services 2378 fields are not applicable. For the purposes of this 2379 specification, several rules are defined. 2381 3.2 First, a client resolving a AAAS URI MUST discard any 2382 services that do not contain "AAAS" as the protocol in the 2383 service field. The converse is not true, however. A client 2384 resolving an AAA URI SHOULD retain records with "AAAS" as 2385 the protocol, if the client supports TLS. Second, a client 2386 MUST discard any service fields that identify a resolution 2387 service whose value is not "D2X", for values of X that 2388 indicate transport protocols supported by the client. The 2389 NAPTR processing as described in RFC 2915 will result in 2390 discovery of the most preferred transport protocol of the 2391 server that is supported by the client, as well as an SRV 2392 record for the server. It will also allow the client to 2393 discover if TLS is available and its preference for its 2394 usage. 2396 The domain suffixes in the NAPTR replacement field SHOULD 2397 match the domain of the original query. It is not necessary 2398 for the domain suffixes in the NAPTR replacement field to 2399 match the domain of the original query. 2401 3.3 If no NAPTR records are found, the requester queries for 2402 those address records for the destination address, 2403 '_diameters._sctp'.realm or '_diameters._tcp'.realm when 2404 using TLS or '_diameter._sctp'.realm or 2405 '_diameter._tcp'.realm when not using TLS. Address records 2406 include A RR's, AAAA RR's or other similar records, chosen 2407 according to the requestor's network protocol capabilities. 2408 If the DNS server returns no address records, the requestor 2409 gives up. 2411 For NAPTR records with AAAS protocol fields, if the server is 2412 using a site certificate, the domain name in the query and the 2413 domain name in the replacement field MUST both be valid based 2414 on the site certificate handed out by the server in the TLS 2415 exchange. Similarly, the domain name in the SRV query and the 2416 domain name in the target in the SRV record MUST both be valid 2417 based on the same site certificate. Otherwise, an attacker 2418 could modify the DNS records to contain replacement values in a 2419 different domain, and the client could not validate that this 2420 was the desired behavior, or the result of an attack. 2422 A dynamically discovered peer causes an entry in the Peer Table (see 2423 section 2.7) to be created. Note that entries created via DNS MUST 2424 expire (or be refreshed) within the DNS TTL. If a peer is discovered 2425 outside of the local realm, a routing table entry (see Section 2.8) 2426 for the peer's realm is created. The routing table entry's expiration 2427 MUST match the peer's expiration value. 2429 5.3 Capabilities Exchange 2431 When two Diameter peers establish a transport connection, they MUST 2432 exchange the Capabilities Exchange messages, as specified in the peer 2433 state machine (see section 5.6). This message allows the discovery of 2434 a peer's identity and its capabilities (protocol version number, 2435 supported Diameter applications, etc.) 2437 The receiver only issues commands to its peers that have advertised 2438 support for the Diameter application that defines the command. A 2439 Diameter node MUST cache the supported applications in order to 2440 ensure that unrecognized commands and/or AVPs are not unnecessarily 2441 sent to a peer. 2443 A receiver of a Capabilities-Exchange-Req (CER) message that does not 2444 have any applications in common with the sender MUST return a 2445 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to 2446 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport 2447 layer connection. Note that receiving a CER or CEA from a peer 2448 advertising itself as a Relay (see section 2.5) MUST be interpreted 2449 as having common applications with the peer. 2451 CERs received from unknown peers MAY be silently discarded, or a CEA 2452 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. 2453 In both cases, the transport connection is closed. If the local 2454 policy permits receiving CERs from unknown hosts, a successful CEA 2455 MAY be returned. 2457 The CER and CEA messages MUST NOT be proxied, or redirected. 2459 Since the CER/CEA messages cannot be proxied, it is still possible 2460 that an upstream agent receives a message for which it has no 2461 available peers to handle the application that corresponds to the 2462 Command-Code. In such instances, the 'E' bit is set in the answer 2463 message (see Section 7.2) with the Result-Code AVP set to 2464 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action 2465 (e.g. re-routing request to an alternate peer). 2467 With the exception of the Capabilities-Exchange-Request message, a 2468 message of type Request that includes the Auth-Application-Id or 2469 Acct-Application-Id AVPs, or a message with an application-specific 2470 command code, MAY only be forwarded to a host that has explicitly 2471 advertised support for the application (or has advertised the Relay 2472 Application Identifier). 2474 5.3.1 Capabilities-Exchange-Request 2476 The Capabilities-Exchange-Request (CER), indicated by the Command- 2477 Code set to 257 and the Command Flags' 'R' bit set, is sent to 2478 exchange local capabilities. Upon detection of a transport failure, 2479 this message MUST NOT be sent to an alternate peer. 2481 When Diameter is run over SCTP [SCTP], which allows for connections 2482 to span multiple interfaces, hence, multiple IP addresses, the 2483 Capabilities-Exchange-Request message MUST contain one Host-IP- 2484 Address AVP for each potential IP address that MAY be locally used 2485 when transmitting Diameter messages. 2487 Message Format 2489 ::= < Diameter Header: 257, REQ > 2490 { Origin-Host } 2491 { Origin-Realm } 2492 1* { Host-IP-Address } 2493 { Vendor-Id } 2494 { Product-Name } 2495 [ Origin-State-Id ] 2496 * [ Supported-Vendor-Id ] 2497 * [ Auth-Application-Id ] 2498 * [ Acct-Application-Id ] 2499 * [ Vendor-Specific-Application-Id ] 2500 [ Firmware-Revision ] 2501 * [ AVP ] 2503 5.3.2 Capabilities-Exchange-Answer 2505 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code 2506 set to 257 and the Command Flags' 'R' bit cleared, is sent in 2507 response to a CER message. 2509 When Diameter is run over SCTP [SCTP], which allows connections to 2510 span multiple interfaces, hence, multiple IP addresses, the 2511 Capabilities-Exchange-Answer message MUST contain one Host-IP-Address 2512 AVP for each potential IP address that MAY be locally used when 2513 transmitting Diameter messages. 2515 Message Format 2516 ::= < Diameter Header: 257 > 2517 { Result-Code } 2518 { Origin-Host } 2519 { Origin-Realm } 2520 1* { Host-IP-Address } 2521 { Vendor-Id } 2522 { Product-Name } 2523 [ Origin-State-Id ] 2524 [ Error-Message ] 2525 * [ Failed-AVP ] 2526 * [ Supported-Vendor-Id ] 2527 * [ Auth-Application-Id ] 2528 * [ Acct-Application-Id ] 2529 * [ Vendor-Specific-Application-Id ] 2530 [ Firmware-Revision ] 2531 * [ AVP ] 2533 5.3.3 Vendor-Id AVP 2535 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 2536 the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] 2537 value assigned to the vendor of the Diameter device. In combination 2538 with the Supported-Vendor-Id AVP (section 5.3.6), this MAY be used in 2539 order to know which vendor specific attributes may be sent to the 2540 peer. It is also envisioned that the combination of the Vendor-Id, 2541 Product-Name (section 5.3.7) and the Firmware-Revision (section 2542 5.3.4) AVPs MAY provide very useful debugging information. 2544 A Vendor-Id value of zero in the CER or CEA messages is reserved and 2545 indicates that the Diameter peer is in the experimental or concept 2546 stage and that an IANA Private Enterprise Number has yet to be 2547 obtained by the implementer. 2549 5.3.4 Firmware-Revision AVP 2551 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 2552 used to inform a Diameter peer of the firmware revision of the 2553 issuing device. 2555 For devices that do not have a firmware revision (general purpose 2556 computers running Diameter software modules, for instance), the 2557 revision of the Diameter software module may be reported instead. 2559 5.3.5 Host-IP-Address AVP 2560 The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is 2561 used to inform a Diameter peer of the sender's IP address. All source 2562 addresses that a Diameter node expects to use with SCTP [SCTP] MUST 2563 be advertised in the CER and CEA messages by including a Host-IP- 2564 Address AVP for each address. This AVP MUST ONLY be used in the CER 2565 and CEA messages. 2567 5.3.6 Supported-Vendor-Id AVP 2569 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and 2570 contains the IANA "SMI Network Management Private Enterprise Codes" 2571 [ASSIGN NO] value assigned to a vendor other than the device vendor. 2572 This is used in the CER and CEA messages in order to inform the peer 2573 that the sender supports a subset of the vendor-specific commands 2574 and/or AVPs defined by the vendor identified in this AVP. 2576 5.3.7 Product-Name AVP 2578 The Product-Name AVP (AVP Code 269) is of type UTF8String, and 2579 contains the vendor assigned name for the product. The Product-Name 2580 AVP SHOULD remain constant across firmware revisions for the same 2581 product. 2583 5.4 Disconnecting Peer connections 2585 When a Diameter node disconnects one of its transport connections, 2586 its peer cannot know the reason for the disconnect, and will most 2587 likely assume that a connectivity problem occurred, or that the peer 2588 has rebooted. In these cases, the peer may periodically attempt to 2589 reconnect, as stated in section 2.1. In the event that the disconnect 2590 was a result of either a shortage of internal resources, or simply 2591 that the node in question has no intentions of forwarding any 2592 Diameter messages to the peer in the foreseeable future, a periodic 2593 connection request would not be welcomed. The Disconnection-Reason 2594 AVP contains the reason the Diameter node issued the Disconnect-Peer- 2595 Request message. 2597 The Disconnect-Peer-Request message is used by a Diameter node to 2598 inform its peer of its intent to disconnect the transport layer, and 2599 that the peer shouldn't reconnect unless it has a valid reason to do 2600 so (e.g. message to be forwarded). Upon receipt of the message, the 2601 Disconnect-Peer-Answer is returned, which SHOULD contain an error if 2602 messages have recently be forwarded, and are likely in flight, which 2603 would otherwise cause a race condition. 2605 The receiver of the Disconnect-Peer-Answer initiates the transport 2606 disconnect. 2608 5.4.1 Disconnect-Peer-Request 2610 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set 2611 to 282 and the Command Flags' 'R' bit set, is sent to a peer to 2612 inform its intentions to shutdown the transport connection. Upon 2613 detection of a transport failure, this message MUST NOT be sent to an 2614 alternate peer. 2616 Message Format 2618 ::= < Diameter Header: 282, REQ > 2619 { Origin-Host } 2620 { Origin-Realm } 2621 { Disconnect-Cause } 2623 5.4.2 Disconnect-Peer-Answer 2625 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set 2626 to 282 and the Command Flags' 'R' bit cleared, is sent as a response 2627 to the Disconnect-Peer-Request message. Upon receipt of this message, 2628 the transport connection is shutdown. 2630 Message Format 2632 ::= < Diameter Header: 282 > 2633 { Result-Code } 2634 { Origin-Host } 2635 { Origin-Realm } 2636 [ Error-Message ] 2637 * [ Failed-AVP ] 2639 5.4.3 Disconnect-Cause AVP 2641 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A 2642 Diameter node MUST include this AVP in the Disconnect-Peer-Request 2643 message to inform the peer of the reason for its intention to 2644 shutdown the transport connection. The following values are 2645 supported: 2647 REBOOTING 0 2648 A scheduled reboot is imminent. 2650 BUSY 1 2651 The peer's internal resources are constrained, and it has 2652 determined that the transport connection needs to be shutdown. 2654 DO_NOT_WANT_TO_TALK_TO_YOU 2 2655 The peer has determined that it does not see a need for the 2656 transport connection to exist, since it does not expect any 2657 messages to be exchanged in the near future. 2659 5.5 Transport Failure Detection 2661 Given the nature of the Diameter protocol, it is recommended that 2662 transport failures be detected as soon as possible. Detecting such 2663 failures will minimize the occurrence of messages sent to unavailable 2664 agents, resulting in unnecessary delays, and will provide better 2665 failover performance. The Device-Watchdog-Request and Device- 2666 Watchdog-Answer messages, defined in this section, are used to pro- 2667 actively detect transport failures. 2669 5.5.1 Device-Watchdog-Request 2671 The Device-Watchdog-Request (DWR), indicated by the Command-Code set 2672 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no 2673 traffic has been exchanged between two peers (see Section 5.5.3). 2674 Upon detection of a transport failure, this message MUST NOT be sent 2675 to an alternate peer. 2677 Message Format 2679 ::= < Diameter Header: 280, REQ > 2680 { Origin-Host } 2681 { Origin-Realm } 2682 [ Origin-State-Id ] 2684 5.5.2 Device-Watchdog-Answer 2686 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 2687 to 280 and the Command Flags' 'R' bit cleared, is sent as a response 2688 to the Device-Watchdog-Request message. 2690 Message Format 2691 ::= < Diameter Header: 280 > 2692 { Result-Code } 2693 { Origin-Host } 2694 { Origin-Realm } 2695 [ Error-Message ] 2696 * [ Failed-AVP ] 2697 [ Original-State-Id ] 2699 5.5.3 Transport Failure Algorithm 2701 The transport failure algorithm is defined in [AAATRANS]. All 2702 Diameter implementations MUST support the algorithm defined in the 2703 specification in order to be compliant to the Diameter base protocol. 2705 5.5.4 Failover/Failback Procedures 2707 In the event that a transport failure is detected with a peer, it is 2708 necessary for all pending request messages to be forwarded to an 2709 alternate agent, if possible. This is commonly referred to as 2710 failover. 2712 In order for a Diameter node to perform failover procedures, it is 2713 necessary for the node to maintain a pending message queue for a 2714 given peer. When an answer message is received, the corresponding 2715 request is removed from the queue. The Hop-by-Hop Identifier field is 2716 used to match the answer with the queued request. 2718 When a transport failure is detected, all messages in the queue are 2719 sent to an alternate agent, if possible. An example of a case where 2720 it is not possible to forward the message to an alternate server is 2721 when the message has a fixed destination, and the unavailable peer is 2722 the message's final destination (see Destination-Host AVP). Such an 2723 error requires that the agent return an answer message with the 'E' 2724 bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 2726 It is important to note that multiple identical requests or answers 2727 MAY be received as a result of a failover. The End-to-End Identifier 2728 field in the Diameter header along with the Origin-Host AVP MUST be 2729 used to identify duplicate messages. 2731 As described in section 2.1, a connection request should be 2732 periodically attempted with the failed peer in order to re-establish 2733 the transport connection. Once a connection has been successfully 2734 established, messages can once again be forwarded to the peer. This 2735 is commonly referred to as failback. 2737 5.6 Peer State Machine 2739 This section contains a finite state machine that MUST be observed by 2740 all Diameter implementations. Each Diameter node MUST follow the 2741 state machine described below when communicating with each peer. 2742 Multiple actions are separated by commas, and may continue on 2743 succeeding lines, as space requires. Similarly, state and next state 2744 may also span multiple lines, as space requires. 2746 This state machine is closely coupled with the state machine 2747 described in [AAATRANS], which is used to open, close, failover, 2748 probe, and reopen transport connections. Note in particular that 2749 [AAATRANS] requires the use of watchdog messages to probe 2750 connections. For Diameter, DWR and DWA messages are to be used. 2752 I- is used to represent the initiator (connecting) connection, while 2753 the R- is used to represent the responder (listening) connection. The 2754 lack of a prefix indicates that the event or action is the same 2755 regardless of the connection on which the event occurred. 2757 The stable states that a state machine may be in are Closed, I-Open 2758 and R-Open; all other states are intermediate. Note that I-Open and 2759 R-Open are equivalent except for whether the initiator or responder 2760 transport connection is used for communication. 2762 A CER message is always sent on the initiating connection immediately 2763 after the connection request is successfully completed. In the case 2764 of an election, one of the two connections will shut down. The 2765 responder connection will survive if the Origin-Host of the local 2766 Diameter entity is higher than that of the peer; the initiator 2767 connection will survive if the peer's Origin-Host is higher. All 2768 subsequent messages are sent on the surviving connection. Note that 2769 the results of an election on one peer are guaranteed to be the 2770 inverse of the results on the other. 2772 The state machine constrains only the behavior of a Diameter 2773 implementation as seen by Diameter peers through events on the wire. 2774 Any implementation that produces equivalent results is considered 2775 compliant. 2777 state event action next state 2778 ----------------------------------------------------------------- 2779 Closed Start I-Snd-Conn-Req Wait-Conn-Ack 2780 R-Conn-CER R-Accept, R-Open 2781 Process-CER, 2782 R-Snd-CEA 2784 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA 2785 I-Rcv-Conn-Nack Cleanup Closed 2786 R-Conn-CER R-Accept, Wait-Conn-Ack/ 2787 Process-CER Elect 2788 Timeout Error Closed 2790 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open 2791 R-Conn-CER R-Accept, Wait-Returns 2792 Process-CER, 2793 Elect 2794 I-Peer-Disc I-Disc Closed 2795 I-Rcv-Non-CEA Error Closed 2796 Timeout Error Closed 2798 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns 2799 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open 2800 R-Peer-Disc R-Disc Wait-Conn-Ack 2801 R-Conn-CER R-Reject Wait-Conn-Ack/ 2802 Elect 2803 Timeout Error Closed 2805 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open 2806 I-Peer-Disc I-Disc, R-Open 2807 R-Snd-CEA 2808 I-Rcv-CEA R-Disc I-Open 2809 R-Peer-Disc R-Disc Wait-I-CEA 2810 R-Conn-CER R-Reject Wait-Returns 2811 Timeout Error Closed 2813 R-Open Send-Message R-Snd-Message R-Open 2814 R-Rcv-Message Process R-Open 2815 R-Rcv-DWR Process-DWR, R-Open 2816 R-Snd-DWA 2817 R-Rcv-DWA Process-DWA R-Open 2818 R-Conn-CER R-Snd-CEA R-Open 2819 R-Reject 2820 Stop R-Snd-DPR Closing 2821 R-Rcv-DPR R-Snd-DPA, Closed 2822 R-Disc 2823 R-Peer-Disc R-Disc Closed 2824 R-Rcv-CER R-Snd-CEA R-Open 2825 R-Rcv-CEA Process-CEA R-Open 2827 I-Open Send-Message I-Snd-Message I-Open 2828 I-Rcv-Message Process I-Open 2829 I-Rcv-DWR Process-DWR, I-Open 2830 I-Snd-DWA 2831 I-Rcv-DWA Process-DWA I-Open 2832 R-Conn-CER R-Reject I-Open 2833 Stop I-Snd-DPR Closing 2834 I-Rcv-DPR I-Snd-DPA, Closed 2835 I-Disc 2836 I-Peer-Disc I-Disc Closed 2837 I-Rcv-CER I-Snd-CEA I-Open 2838 I-Rcv-CEA Process-CEA I-Open 2840 Closing I-Rcv-DPA I-Disc Closed 2841 R-Rcv-DPA R-Disc Closed 2842 Timeout Error Closed 2843 I-Peer-Disc I-Disc Closed 2844 R-Peer-Disc R-Disc Closed 2846 5.6.1 Incoming connections 2848 When a connection request is received from a Diameter peer, it is 2849 not, in the general case, possible to know the identity of that peer 2850 until a CER is received from it. This is because host and port 2851 determine the identity of a Diameter peer; and the source port of an 2852 incoming connection is arbitrary. Upon receipt of CER, the identity 2853 of the connecting peer can be uniquely determined from Origin-Host. 2855 For this reason, a Diameter peer must employ logic separate from the 2856 state machine to receive connection requests, accept them, and await 2857 CER. Once CER arrives on a new connection, the Origin-Host that 2858 identifies the peer is used to locate the state machine associated 2859 with that peer, and the new connection and CER are passed to the 2860 state machine as an R-Conn-CER event. 2862 The logic that handles incoming connections SHOULD close and discard 2863 the connection if any message other than CER arrives, or if an 2864 implementation-defined timeout occurs prior to receipt of CER. 2866 Because handling of incoming connections up to and including receipt 2867 of CER requires logic, separate from that of any individual state 2868 machine associated with a particular peer, it is described separately 2869 in this section rather than in the state machine above. 2871 5.6.2 Events 2873 Transitions and actions in the automaton are caused by events. In 2874 this section, we will ignore the -I and -R prefix, since the actual 2875 event would be identical, but would occur on one of two possible 2876 connections. 2878 Start The Diameter application has signaled that a 2879 connection should be initiated with the peer. 2881 R-Conn-CER An acknowledgement is received stating that the 2882 transport connection has been established, and the 2883 associated CER has arrived. 2885 Rcv-Conn-Ack A positive acknowledgement is received confirming 2886 that the transport connection is established. 2888 Rcv-Conn-Nack A negative acknowledgement was received stating 2889 that the transport connection was not established. 2891 Timeout An application-defined timer has expired while 2892 waiting for some event. 2894 Rcv-CER A CER message from the peer was received. 2896 Rcv-CEA A CEA message from the peer was received. 2898 Rcv-Non-CEA A message other than CEA from the peer was 2899 received. 2901 Peer-Disc A disconnection indication from the peer was 2902 received. 2904 Rcv-DPR A DPR message from the peer was received. 2906 Rcv-DPA A DPA message from the peer was received. 2908 Win-Election An election was held, and the local node was the 2909 winner. 2911 Send-Message A message is to be sent. 2913 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR, or 2914 DWA was received. 2916 Stop The Diameter application has signaled that a 2917 connection should be terminated (e.g., on system 2918 shutdown). 2920 5.6.3 Actions 2922 Actions in the automaton are caused by events and typically indicate 2923 the transmission of packets and/or an action to be taken on the 2924 connection. In this section we will ignore the I- and R- prefix, 2925 since the actual action would be identical, but would occur on one of 2926 two possible connections. 2928 Snd-Conn-Req A transport connection is initiated with the peer. 2930 Accept The incoming connection associated with the R-Conn- 2931 CER is accepted as the responder connection. 2933 Reject The incoming connection associated with the R-Conn- 2934 CER is disconnected. 2936 Process-CER The CER associated with the R-Conn-CER is 2937 processed. 2939 Snd-Conn-Ack an acknowledgement is received confirming that the 2940 transport connection is established. 2942 Snd-CER A CER message is sent to the peer. 2944 Snd-CEA A CEA message is sent to the peer. 2946 Cleanup If necessary, the connection is shutdown, and any 2947 local resources are freed. 2949 Error The transport layer connection is disconnected, 2950 either politely or abortively, in response to an 2951 error condition. Local resources are freed. 2953 Process-CEA A received CEA is processed. 2955 Snd-DPR A DPR message is sent to the peer. 2957 Snd-DPA A DPA message is sent to the peer. 2959 Disc The transport layer connection is disconnected, and 2960 local resources are freed. 2962 Elect An election occurs (see Section 5.6.4 for more 2963 information). 2965 Snd-Message A message is sent. 2967 Snd-DWR A DWR message is sent. 2969 Snd-DWA A DWA message is sent. 2971 Process-DWR The DWR message is serviced. 2973 Process-DWA The DWA message is serviced. 2975 Process A message is serviced. 2977 5.6.4 The Election Process 2979 The election is performed on the responder. The responder compares 2980 the Origin-Host received in the CER sent by its peer with its own 2981 Origin-Host. If the local Diameter entity's Origin-Host is higher 2982 than the peer's, a Win-Election event is issued locally. 2984 The comparison proceeds by considering the shorter OctetString to be 2985 null-padded to the length of the longer, then performing an octet-by- 2986 octet unsigned comparison with the first octet being most 2987 significant. Hanging octets are assumed to have value 0x80, but 2988 dimpled octets are ignored. 2990 6.0 Diameter message processing 2992 This section describes how Diameter requests and answers are created 2993 and processed. 2995 6.1 Diameter request routing overview 2997 A request is sent towards its final destination using a combination 2998 of the Destination-Realm and Destination-Host AVPs, in one of these 2999 three combinations: 3000 - a request that is not able to be proxied (such as CER) MUST NOT 3001 contain either Destination-Realm or Destination-Host AVPs. 3002 - a request that needs to be sent to a home server serving a 3003 specific realm, but not to a specific server (such as the first 3004 request of a series of round-trips), MUST contain a Destination- 3005 Realm AVP, but MUST NOT contain a Destination-Host AVP. 3006 - a request that needs to be sent to a specific home server among 3007 those serving a given realm, MUST contain both the Destination- 3008 Realm and Destination-Host AVPs. 3010 The Destination-Host AVP is used as described above when the 3011 destination of the request is fixed, which includes: 3012 - Authentication requests that span multiple round trips 3013 - A Diameter message that uses a security mechanism that makes use 3014 of a pre-established session key shared between the source and 3015 the final destination of the message. 3016 - Server initiated messages that MUST be received by a specific 3017 Diameter client (e.g. access device), such as the Abort-Session- 3018 Request message, which is used to request that a particular 3019 user's session be terminated. 3021 Note that an agent can forward a request to a host described in the 3022 Destination-Host AVP only if the host in question is included in its 3023 peer table (see section 2.7). Otherwise, the request is routed based 3024 on the Destination-Realm only (see sections 6.1.6). 3026 The Destination-Realm AVP MUST be present if the message is 3027 proxiable. Proxiable request messages MUST also contain either an 3028 Acct-Application-Id AVP or an Auth-Application-Id AVP. A message that 3029 MUST NOT be relayed, proxied or redirected MUST NOT include the 3030 Destination-Realm in its ABNF. The value of the Destination-Realm AVP 3031 MAY be extracted from the User-Name AVP, or other application- 3032 specific methods. 3034 When a message is received, the message is processed in the following 3035 order: 3036 1. If the message is destined for the local host, the procedures 3037 listed in section 6.1.4 are followed. 3038 2. If the message is intended for a Diameter peer with whom the 3039 local host is able to directly communicate, the procedures 3040 listed in section 6.1.5 are followed. This is known as Request 3041 Forwarding. 3042 3. The procedures listed in section 6.1.6 are followed, which is 3043 known as Request Routing. 3044 4. If none of the above is successful, an answer is returned with 3045 the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. 3047 For routing of Diameter messages to work within an administrative 3048 domain, all Diameter nodes within the realm MUST be peers. If 3049 intermediate nodes are desired (see Figure 5), the destination node 3050 MUST be in a subrealm and routes to that subrealm MUST exist in the 3051 routing table on the sending node and all intermediate nodes. Figure 3052 5 shows an example of a hierarchical network that requires the use of 3053 subrealms. In such a network, routing must be performed with longest 3054 match from right. 3056 +---------+ 3057 | abc.com | 3058 +---------+ 3060 +-------+ +-------+ 3061 | agent | | agent | 3062 +-------+ +-------+ 3064 +-------------+ +--------------+ +-------------+ +--------------+ 3065 | eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com | 3066 +-------------+ +--------------+ +-------------+ +--------------+ 3067 Figure 5: Hierarchical administrative domain 3069 Note the processing rules contained in this section are intended to 3070 be used as general guidelines to Diameter developers. Certain 3071 implementations MAY use different methods than the ones described 3072 here, and still comply with the protocol specification. 3074 6.1.1 Originating a Request 3076 When creating a request, in addition to any other procedures 3077 described in the application definition for that specific request, 3078 the following procedures MUST be followed: 3079 - the Command-Code should be set to the appropriate value 3080 - the 'R' bit should be set 3081 - the End-to-End Identifier should be set to a locally unique 3082 value 3083 - the Origin-Host and Origin-Realm AVPs MUST be set to the 3084 appropriate values, used to identify the source of the message 3085 - the Destination-Host and Destination-Realm AVPs MUST be set to 3086 the appropriate values as described in section 6.1. 3087 - either an Acct-Application-Id AVP or an Auth-Application-Id AVP 3088 must be included if the request is proxiable. 3090 6.1.2 Sending a Request 3092 When sending a request, originated either locally, or as the result 3093 of a forwarding or routing operation, the following procedures MUST 3094 be followed: 3095 - the Hop-by-Hop Identifier should be set to a locally unique 3096 value 3097 - The message should be saved in the list of pending requests. 3099 Other actions to perform on the message based on the particular role 3100 the agent is playing are described in the following sections. 3102 6.1.3 Receiving Requests 3104 A relay or proxy agent MUST check for forwarding loops when receiving 3105 requests. A loop is detected if the server finds its own identity in 3106 a Route-Record AVP. When such an event occurs, the agent MUST answer 3107 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 3109 6.1.4 Processing Local Requests 3111 A request is known to be for local consumption when one of the 3112 following conditions occur: 3113 - The Destination-Host AVP contains the local host's identity, 3114 - The Destination-Host AVP is not present, the Destination-Realm 3115 AVP contains a realm the server is configured to process 3116 locally, and the Diameter application is locally supported, or 3117 - Both the Destination-Host and the Destination-Realm are not 3118 present. 3120 When a request is locally processed, the rules in section 6.2 should 3121 be used to generate the corresponding answer. 3123 6.1.5 Request Forwarding 3125 Request forwarding is done using the Diameter Peer Table. The 3126 Diameter peer table contains all of the peers that the local node is 3127 able to directly communicate with. 3129 When a request is received, and the host encoded in the Destination- 3130 Host AVP is one that is present in the peer table, the message SHOULD 3131 be forwarded to the peer. 3133 6.1.6 Request Routing 3135 Diameter request message routing is done via realms. A Diameter 3136 message that is able to be proxied MUST include the target realm in 3137 the Destination-Realm AVP. The realm MAY be retrieved from the User- 3138 Name AVP, which is in the form of a Network Access Identifier (NAI). 3139 The realm portion of the NAI is inserted in the Destination-Realm 3140 AVP. 3142 Diameter agents MAY have a list of locally supported realms, and MAY 3143 have a list of externally supported realms. When a request is 3144 received that includes a realm that is not locally supported, the 3145 message is routed to the peer configured in the Realm Routing Table 3146 table (see section 2.8). 3148 6.1.7 Redirecting requests 3150 When a redirect agent receives a request whose routing entry is set 3151 to REDIRECT, it MUST reply with an answer message with the 'E' bit 3152 set, while maintaining the Hop-by-Hop Identifier in the header, and 3153 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of 3154 the servers associated with the routing entry are added in separate 3155 Redirect-Host AVP. 3157 +------------------+ 3158 | Diameter | 3159 | Redirect Agent | 3160 +------------------+ 3161 ^ | 2. command + 'E' bit 3162 1. Request | | Result-Code = 3163 joe@xyz.com | | DIAMETER_REDIRECT_INDICATION + 3164 | | Redirect-Host AVP(s) 3165 | v 3166 +---------+ 3. Request +----------+ 3167 | abc.net |------------->| xyz.net | 3168 | Relay | | Diameter | 3169 | Agent |<-------------| Server | 3170 +---------+ 4. Answer +----------+ 3171 Figure 6: Diameter Redirect Agent 3173 Redirect agents MAY also include the certificate of the servers in 3174 the Redirect-Host AVP(s). These certificates are encapsulated in a 3175 AAA-Node-Cert AVP [CMS]. 3177 The receiver of the answer message with the 'E' bit set, and the 3178 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- 3179 hop field in the Diameter header to identify the request in the 3180 pending message queue (see Section 5.3) that is to be redirected. If 3181 no transport connection exists with the new agent, one is created, 3182 and the request is sent directly to it. 3184 6.1.8 Relaying and Proxying Requests 3186 A relay or proxy agent MUST append a Route-Record AVP to all requests 3187 forwarded. The AVP contains the identity of the peer the request was 3188 received from. 3190 The Hop-by-Hop identifier in the request is saved, and replaced with 3191 a locally unique value. The source of the request is also saved, 3192 which includes the IP address, port and protocol. 3194 Relay and Proxy agents MAY include the Proxy-Info AVP in requests if 3195 it requires access any local state information when the corresponding 3196 response is received. Alternatively, it MAY simply use local storage 3197 to store state information. 3199 The message is then forwarded to the next hop, as identified in the 3200 Realm Routing Table. 3202 Figure 7 provides an example of message routing using the procedures 3203 listed in these sections. 3205 (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) 3206 (Origin-Realm=mno.net) (Origin-Realm=mno.net) 3207 (Destination-Realm=abc.com) (Destination-Realm=abc.com) 3208 (Route-Record=nas.mno.net) 3209 +------+ ------> +------+ ------> +------+ 3210 | | (Request) | | (Request) | | 3211 | NAS +-------------------+ DRL +-------------------+ HMS | 3212 | | | | | | 3213 +------+ <------ +------+ <------ +------+ 3214 mno.net (Answer) mno.net (Answer) abc.com 3215 (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) 3216 (Origin-Realm=abc.com) (Origin-Realm=abc.com) 3217 Figure 7: Routing of Diameter messages 3219 6.2 Diameter Answer Processing 3221 When a request is locally processed, the following procedures MUST be 3222 applied to create the associated answer, in addition to any 3223 additional procedures that MAY be discussed in the Diameter 3224 application defining the command: 3226 - The same Hop-by-Hop identifier in the request is used in the 3227 answer. 3228 - The local host's identity is encoded in the Origin-Host AVP. 3229 - The Destination-Host and Destination-Realm AVPs MUST NOT be 3230 present in the answer message. 3231 - The Result-Code AVP is added with its value indicating success 3232 or failure. 3233 - If the Session-Id is present in the request, it MUST be included 3234 in the answer. 3235 - Any Proxy-Info AVPs in the request MUST be added to the answer 3236 message, in the same order they were present in the request. 3237 - The 'P' bit is set to the same value as the one in the request. 3238 - The same End-to-End identifier in the request is used in the 3239 answer. 3241 Note that the error messages (see section 7.2) are also subjected to 3242 the above processing rules. 3244 6.2.1 Processing received Answers 3246 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an 3247 answer received against the list of pending requests. The 3248 corresponding message should be removed from the list of pending 3249 requests. It SHOULD ignore answers received that do not match a known 3250 Hop-by-Hop Identifier. 3252 6.2.2 Relaying and Proxying Answers 3254 If the answer is for a request which was proxied or relayed, the 3255 agent MUST restore the original value of the Diameter header's Hop- 3256 by-Hop Identifier field. 3258 If the last Proxy-Info AVP in the message is targeted to the local 3259 Diameter server, the AVP MUST be removed before the answer is 3260 forwarded. 3262 If a relay or proxy agent receives an answer with a Result-Code AVP 3263 indicating a failure, it MUST NOT modify the contents of the AVP. Any 3264 additional local errors detected SHOULD be logged, but not reflected 3265 in the Result-Code AVP. If the agent receives an answer message with 3266 a Result-Code AVP indicating success, and it wishes to modify the AVP 3267 to indicate an error, it MUST modify the Result-Code AVP to contain 3268 the appropriate error in the message destined towards the access 3269 device as well as include the Error-Reporting-Host AVP and it MUST 3270 issue an STR on behalf of the access device. 3272 The agent MUST then send the answer to the host that it received the 3273 original request from. 3275 6.3 Origin-Host AVP 3277 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and 3278 MUST be present in all Diameter messages. This AVP identifies the 3279 endpoint that originated the Diameter message. Relay agents MUST NOT 3280 modify this AVP. 3282 The value of the Origin-Host AVP is guaranteed to be unique within a 3283 single host. 3285 Note that the Origin-Host AVP may resolve to more than one address as 3286 the Diameter peer may support more than one address. 3288 This AVP SHOULD be placed as close to the Diameter header as 3289 possible. 3291 6.4 Origin-Realm AVP 3293 The Origin-Realm AVP (AVP Code 296) is of type UTF8String. This AVP 3294 contains the Realm of the originator of any Diameter message and MUST 3295 be present in all messages. 3297 This AVP SHOULD be placed as close to the Diameter header as 3298 possible. 3300 6.5 Destination-Host AVP 3302 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. 3303 This AVP MUST be present in all unsolicited agent initiated messages, 3304 MAY be present in request messages, and MUST NOT be present in Answer 3305 messages. 3307 The absence of the Destination-Host AVP will cause a message to be 3308 sent to any Diameter server supporting the application within the 3309 realm specified in Destination-Realm AVP. 3311 This AVP SHOULD be placed as close to the Diameter header as 3312 possible. 3314 6.6 Destination-Realm AVP 3316 The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and 3317 contains the realm the message is to be routed to. The Destination- 3318 Realm AVP MUST NOT be present in Answer messages. Diameter Clients 3319 insert the realm portion of the User-Name AVP. Diameter servers 3320 initiating a request message use the value of the Origin-Realm AVP 3321 from a previous message received from the intended target host 3322 (unless it is known a priori). When present, the Destination-Realm 3323 AVP is used to perform message routing decisions. 3325 Request messages whose ABNF does not list the Destination-Realm AVP 3326 as a mandatory AVP are inherently non-routable messages. 3328 This AVP SHOULD be placed as close to the Diameter header as 3329 possible. 3331 6.7 Routing AVPs 3332 The AVPs defined in this section are Diameter AVPs used for routing 3333 purposes. These AVPs change as Diameter messages are processed by 3334 agents, and therefore MUST NOT be protected using the Diameter CMS 3335 Security application [CMS]. 3337 6.7.1 Route-Record AVP 3339 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The 3340 identity added in this AVP MUST be the same as the one received in 3341 the Origin-Host of the Capabilities Exchange message. 3343 6.7.2 Proxy-Info AVP 3345 The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped 3346 Data field has the following ABNF grammar: 3348 Proxy-Info ::= < AVP Header: 284 > 3349 { Proxy-Host } 3350 { Proxy-State } 3351 * [ AVP ] 3353 6.7.3 Proxy-Host AVP 3355 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This 3356 AVP contains the identity of the host that added the Proxy-Info AVP. 3358 6.7.4 Proxy-State AVP 3360 The Proxy-State AVP (AVP Code 33) is of type OctetString, and 3361 contains state local information, and MUST be treated as opaque data. 3363 6.8 Auth-Application-Id AVP 3365 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and 3366 is used in order to advertise support of the Authentication and 3367 Authorization portion of an application (see Section 2.5). The Auth- 3368 Application-Id MUST also be present in all Authentication and/or 3369 Authorization messages that are defined in a separate Diameter 3370 specification and have an Application ID assigned. 3372 This AVP SHOULD be placed as close to the Diameter header as 3373 possible. 3375 6.9 Acct-Application-Id AVP 3377 The Acct-application-Id AVP (AVP Code 259) is of type Unsigned32 and 3378 is used in order to advertise support of the Accounting portion of an 3379 application (see Section 2.5). The Acct-Application-Id MUST also be 3380 present in all Accounting messages that are defined in a separate 3381 Diameter specification and have an Application ID assigned. 3383 This AVP SHOULD be placed as close to the Diameter header as 3384 possible. 3386 6.10 Vendor-Specific-Application-Id AVP 3388 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type 3389 Grouped and is used to advertise support of a vendor-specific 3390 Diameter Application. Either the Auth-Application-Id or the Acct- 3391 Application-Id AVP MAY be present. Both AVPs MAY be present if they 3392 both contain the same value. 3394 This AVP MUST also be present in all vendor-specific commands defined 3395 in the vendor-specific application. 3397 This AVP SHOULD be placed as close to the Diameter header as 3398 possible. 3400 AVP Format 3402 ::= < AVP Header: 260 > 3403 1* [ Vendor-Id ] 3404 0*1{ Auth-Application-Id } 3405 0*1{ Acct-Application-Id } 3407 6.11 Redirect-Host AVP 3409 The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. This AVP 3410 MUST be present if the answer message's 'E' bit is set and the 3411 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3413 Upon receiving the above, the receiving Diameter node SHOULD forward 3414 the request directly to the host identified in this AVP. The server 3415 contained in the Redirect-Host SHOULD be used for all messages 3416 pertaining to this session. 3418 6.12 Redirect-Host-Usage AVP 3419 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. 3420 This AVP MAY be present in answer messages whose 'E' bit is set and 3421 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3423 When present, this AVP dictates how the routing entry resulting from 3424 the Redirect-Host is to be used. The following values are supported: 3426 DONT_CACHE 0 3427 The host specified in the Redirect-Host AVP should not be 3428 cached. This is the default value. 3430 ALL_SESSION 1 3431 All messages within the same session, as defined by the same 3432 value of the Session-ID AVP MAY be sent to the host specified 3433 in the Redirect-Host AVP. 3435 ALL_REALM 2 3436 All messages destined for the realm requested MAY be sent to 3437 the host specified in the Redirect-Host AVP. 3439 REALM_AND_APPLICATION 3 3440 All messages for the application requested to the realm 3441 specified MAY be sent to the host specified in the Redirect- 3442 Host AVP. 3444 ALL_APPLICATION 4 3445 All messages for the application requested MAY be sent to the 3446 host specified in the Redirect-Host AVP. 3448 ALL_HOST 5 3449 All messages that would be sent to the host that generated the 3450 Redirect-Host MAY be sent to the host specified in the 3451 Redirect-Host AVP. 3453 ALL_USER 6 3454 All messages for the user requested MAY be sent to the host 3455 specified in the Redirect-Host AVP. 3457 6.13 Redirect-Max-Cache-Time AVP 3459 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. 3460 This AVP MUST be present in answer messages whose 'E' bit is set, the 3461 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 3462 Redirect-Host-Usage AVP set to a non-zero value. 3464 This AVP contains the maximum number of seconds the peer and route 3465 table entries, created as a result of the Redirect-Host, will be 3466 cached. Note that once a host created due to a redirect indication is 3467 no longer reachable, any associated peer and routing table entries 3468 MUST be deleted. 3470 7.0 Error Handling 3472 There are two different types of errors in Diameter; protocol and 3473 applications. A protocol error is one that occurs at the base 3474 protocol level, and MAY require per hop attention (e.g. message 3475 routing error). Application errors, on the other hand, are generally 3476 occur due to a problem with a function specified in a Diameter 3477 application (e.g. user authentication, Missing AVP). 3479 Result-Code AVP values that are used to report protocol errors MUST 3480 only be present in answer messages whose 'E' bit is set. When a 3481 request message is received that causes a protocol error, an answer 3482 message is returned with the 'E' bit set, and the Result-Code AVP is 3483 set to the appropriate protocol error value. As the answer is sent 3484 back towards the originator of the request, each proxy or relay agent 3485 MAY take action on the message. 3487 1. Request +---------+ Link Broken 3488 +-------------------------->|Diameter |----///----+ 3489 | +---------------------| | v 3490 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+ 3491 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| 3492 | | | Home | 3493 | Relay 1 |--+ +---------+ | Server | 3494 +---------+ | 3. Request |Diameter | +--------+ 3495 +-------------------->| | ^ 3496 | Relay 3 |-----------+ 3497 +---------+ 3498 Figure 8: Example of Protocol Error causing answer message 3500 Figure 8 provides an example of a message forwarded upstream by a 3501 Diameter relay. When the message is received by Relay 2, and it 3502 detects that it cannot forward the request to the home server, an 3503 answer message is returned with the 'E' bit set and the Result-Code 3504 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls 3505 within the protocol error category, Relay 1 would take special 3506 action, and given the error, attempt to route the message through its 3507 alternate Relay 3. 3509 +---------+ 1. Request +---------+ 2. Request +---------+ 3510 | Access |------------>|Diameter |------------>|Diameter | 3511 | | | | | Home | 3512 | Device |<------------| Relay |<------------| Server | 3513 +---------+ 4. Answer +---------+ 3. Answer +---------+ 3514 (Missing AVP) (Missing AVP) 3515 Figure 9: Example of Application Error Answer message 3517 Figure 9 provides an example of a Diameter message that caused an 3518 application error. When application errors occur, the Diameter entity 3519 reporting the error clears the 'R' bit in the Command Flags, and adds 3520 the Result-Code AVP with the proper value. Application errors do not 3521 require any proxy or relay agent involvement, and therefore the 3522 message would be forwarded back to the originator of the request. 3524 There are certain Result-Code AVP application errors that require 3525 additional AVPs to be present in the answer. In these cases, the 3526 Diameter node that sets the Result-Code AVP to indicate the error 3527 MUST add the AVPs. Examples are: 3529 - An unrecognized AVP is received with the 'M' bit (Mandatory bit) 3530 set, causes an answer to be sent with the Result-Code AVP set to 3531 DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the 3532 offending AVP. 3533 - An AVP that is received with an unrecognized value causes an 3534 answer to be returned with the Result-Code AVP set to 3535 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing 3536 the AVP causing the error. 3537 - A command is received with an AVP that is omitted, yet is 3538 mandatory according to the command's ABNF. The receiver issues 3539 an answer with the Result-Code set to DIAMETER_MISSING_AVP, and 3540 creates an AVP with the AVP Code and other fields set to the 3541 missing AVP's. The created AVP is then added to the Failed-AVP 3542 AVP. 3544 The Result-Code AVP contains additional errors conditions, and 3545 defines the expected behavior of each. 3547 7.1 Result-Code AVP 3549 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 3550 indicates whether a particular request was completed successfully or 3551 whether an error occurred. All Diameter answer messages MUST include 3552 one Result-Code AVP. A non-successful Result-Code AVP (one containing 3553 a non 2xxx value) MUST include the Error-Reporting-Host AVP if the 3554 host setting the Result-Code AVP is different from the identity 3555 encoded in the Origin-Host AVP. 3557 The Result-Code data field contains an IANA-managed 32-bit address 3558 space representing errors (see section 11.4). Diameter provides the 3559 following classes of errors, all identified by the thousands digit: 3560 - 1xxx (Informational) 3561 - 2xxx (Success) 3562 - 3xxx (Protocol Errors) 3563 - 4xxx (Transient Failures) 3564 - 5xxx (Permanent Failure) 3566 A non-recognize class (one whose first digit is not defined in this 3567 section) MUST be handled as a permanent failure. 3569 7.1.1 Informational 3571 Errors that fall within this category are used to inform the 3572 requester that a request could not be satisfied, and additional 3573 action is required on its part before access is granted. 3575 DIAMETER_MULTI_ROUND_AUTH 1001 3576 This informational error is returned by a Diameter server to 3577 inform the access device that the authentication mechanism 3578 being used required multiple round trips, and a subsequent 3579 request needs to be issued in order for access to be granted. 3581 7.1.2 Success 3583 Errors that fall within the Success category are used to inform a 3584 peer that a request has been successfully completed. 3586 DIAMETER_SUCCESS 2001 3587 The Request was successfully completed. 3589 DIAMETER_LIMITED_SUCCESS 2002 3590 When returned, the request was successfully completed, but 3591 additional processing is required by the application in order 3592 to provide service to the user. 3594 7.1.3 Protocol Errors 3596 Errors that fall within the Protocol Error category SHOULD be treated 3597 on a per-hop basis, and Diameter proxies MAY attempt to correct the 3598 error, if it is possible. Note that these errors MUST only be used in 3599 answer messages whose 'E' bit is set. 3601 DIAMETER_COMMAND_UNSUPPORTED 3001 3602 The Request contained a Command-Code that the receiver did not 3603 recognize or support. 3605 DIAMETER_UNABLE_TO_DELIVER 3002 3606 This error is given when Diameter can not deliver the message 3607 to the destination, either because no host within the realm was 3608 available to process the request, or because Destination-Host 3609 AVP was given without the associated Destination-Realm AVP. 3611 DIAMETER_REALM_NOT_SERVED 3003 3612 The intended realm of the request is not recognized. 3614 DIAMETER_TOO_BUSY 3004 3615 When returned, a Diameter node SHOULD attempt to send the 3616 message to an alternate peer. This error MUST only be used when 3617 a specific server is requested, and it cannot provide the 3618 requested service. 3620 DIAMETER_LOOP_DETECTED 3005 3621 An agent detected a loop while trying to get the message to the 3622 intended recipient. The message MAY be sent to an alternate 3623 peer, if one is available, but the peer reporting the error has 3624 identified a configuration problem. 3626 DIAMETER_REDIRECT_INDICATION 3006 3627 A redirect agent has determined that the request could not be 3628 satisfied locally and the initiator of the request should 3629 direct the request directly to the server, whose contact 3630 information has been added to the response. When set, the 3631 Redirect-Host AVP MUST be present. 3633 DIAMETER_APPLICATION_UNSUPPORTED 3007 3634 A request was sent for an application that is not supported. 3636 DIAMETER_INVALID_HDR_BITS 3008 3637 A request was received whose bits in the Diameter header were 3638 either set to an invalid combination, or to a value that is 3639 inconsistent with the command code's definition. 3641 DIAMETER_INVALID_AVP_BITS 3009 3642 A request was received that included an AVP whose flag bits are 3643 set to an unrecognized value, or that is inconsistent with the 3644 AVP's definition. 3646 DIAMETER_UNKNOWN_PEER 3010 3647 A CER was received from an unknown peer. 3649 7.1.4 Transient Failures 3651 Errors that fall within the transient failures category are used to 3652 inform a peer that the request could not be satisfied at the time it 3653 was received, but MAY be able to satisfy the request in the future. 3655 DIAMETER_AUTHENTICATION_REJECTED 4001 3656 The authentication process for the user failed, most likely due 3657 to an invalid password used by the user. Further attempts MUST 3658 only be tried after prompting the user for a new password. 3660 DIAMETER_OUT_OF_SPACE 4002 3661 A Diameter node received the accounting request but was unable 3662 to commit it to stable storage due to a temporary lack of 3663 space. 3665 7.1.5 Permanent Failures 3667 Errors that fall within the permanent failures category are used to 3668 inform the peer that the request failed, and should not be attempted 3669 again. 3671 DIAMETER_AVP_UNSUPPORTED 5001 3672 The peer received a message that contained an AVP that is not 3673 recognized or supported and was marked with the Mandatory bit. 3674 A Diameter message with this error MUST contain one or more 3675 Failed-AVP AVP containing the AVPs that caused the failure. 3677 DIAMETER_UNKNOWN_SESSION_ID 5002 3678 The request contained an unknown Session-Id. 3680 DIAMETER_AUTHORIZATION_REJECTED 5003 3681 A request was received for which the user could not be 3682 authorized. This error could occur if the service requested is 3683 not permitted to the user. 3685 DIAMETER_INVALID_AVP_VALUE 5004 3686 The request contained an AVP with an invalid value in its data 3687 portion. A Diameter message indicating this error MUST include 3688 the offending AVPs within a Failed-AVP AVP. 3690 DIAMETER_MISSING_AVP 5005 3691 The request did not contain an AVP that is required by the 3692 Command Code definition. If this value is sent in the Result- 3693 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 3694 The Failed-AVP AVP MUST contain an example of the missing AVP 3695 complete with the Vendor-Id if applicable. The value field of 3696 the missing AVP should be of correct minimum length and contain 3697 zeroes. 3699 DIAMETER_RESOURCES_EXCEEDED 5006 3700 A request was received that cannot be authorized because the 3701 user has already expended allowed resources. An example of this 3702 error condition is a user that is restricted to one dial-up PPP 3703 port, attempts to establish a second PPP connection. 3705 DIAMETER_CONTRADICTING_AVPS 5007 3706 The Home Diameter server has detected AVPs in the request that 3707 contradicted each other, and is not willing to provide service 3708 to the user. One or more Failed-AVP AVPs MUST be present, 3709 containing the AVPs that contradicted each other. 3711 DIAMETER_AVP_NOT_ALLOWED 5008 3712 A message was received with an AVP that MUST NOT be present. 3713 The Failed-AVP AVP MUST be included and contain a copy of the 3714 offending AVP. 3716 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 3717 A message was received that included an AVP that appeared more 3718 often than permitted in the message definition. The Failed-AVP 3719 AVP MUST be included and contain a copy of the first instance 3720 of the offending AVP that exceeded the maximum number of 3721 occurrences 3723 DIAMETER_UNSUPPORTED_TRANSFORM 5010 3724 A message was received that included a CMS-Data AVP [CMS] that 3725 made use of an unsupported transform. 3727 DIAMETER_NO_COMMON_APPLICATION 5011 3728 This error is returned when a CER message is received, and 3729 there are no common applications supported between the peers. 3731 DIAMETER_UNSUPPORTED_VERSION 5012 3732 This error is returned when a request was received, whose 3733 version number is unsupported. 3735 DIAMETER_UNABLE_TO_COMPLY 5013 3736 This error is returned when a request is rejected for 3737 unspecified reasons. 3739 DIAMETER_INVALID_BIT_IN_HEADER 5014 3740 This error is returned when an unrecognized bit in the Diameter 3741 header is set to one (1). 3743 DIAMETER_INVALID_AVP_LENGTH 5015 3744 The request contained an AVP with an invalid length. A Diameter 3745 message indicating this error MUST include the offending AVPs 3746 within a Failed-AVP AVP. 3748 DIAMETER_INVALID_MESSAGE_LENGTH 5016 3749 This error is returned when a request is received with an 3750 invalid message length. 3752 DIAMETER_INVALID_AVP_BIT_COMBO 5017 3753 The request contained an AVP with which is not allowed to have 3754 the given value in the AVP Flags field. A Diameter message 3755 indicating this error MUST include the offending AVPs within a 3756 Failed-AVP AVP. 3758 7.2 Error Bit 3760 The 'E' (Error Bit) in the Diameter header is set when the request 3761 caused a protocol-related error (see section 7.1.3). A message with 3762 the 'E' bit MUST NOT be sent as a response to an answer message. Note 3763 that a message with the 'E' bit set is still subjected to the 3764 processing rules defined in section 6.2. When set, the answer message 3765 will not conform to the ABNF specification for the command, and will 3766 instead conform to the following ABNF: 3768 Message Format 3770 ::= < Diameter Header: code, ERR [PXY] > 3771 0*1< Session-Id > 3772 { Origin-Host } 3773 { Origin-Realm } 3774 { Result-Code } 3775 [ Origin-State-Id ] 3776 [ Error-Reporting-Host ] 3777 [ Proxy-Info ] 3778 * [ AVP ] 3780 Note that the code used in the header is the same that the one found 3781 in the request message, but with the 'R' bit cleared and the 'E' bit 3782 set. The 'P' bit in the header is set to the same value as the one 3783 found in the request message. 3785 7.3 Error-Message AVP 3787 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY 3788 accompany a Result-Code AVP as a human readable error message. The 3789 Error-Message AVP is not intended to be useful in real-time, and 3790 SHOULD NOT be expected to be parsed by network entities. 3792 7.4 Error-Reporting-Host AVP 3794 The Error-Reporting-Host AVP (AVP Code 294) is of type 3795 DiameterIdentity. This AVP contains the identity of the Diameter host 3796 that sent the Result-Code AVP to a value other than 2001 (Success), 3797 only if the host setting the Result-Code is different from the one 3798 encoded in the Origin-Host AVP. This AVP is intended to be used for 3799 troubleshooting purposes, and MUST be set when the Result-Code AVP 3800 indicates a failure. 3802 7.5 Failed-AVP AVP 3804 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides 3805 debugging information in cases where a request is rejected or not 3806 fully processed due to erroneous information in a specific AVP. The 3807 value of the Result-Code AVP will provide information on the reason 3808 for the Failed-AVP AVP. 3810 The possible reasons for this AVP are the presence of an improperly 3811 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 3812 value, the omission of a required AVP, the presence of an explicitly 3813 excluded AVP (see tables in section 10.0), or the presence of two or 3814 more occurrences of an AVP which is restricted to 0, 1, or 0-1 3815 occurrences. 3817 A Diameter message MAY contain one Failed-AVP AVP, containing the 3818 entire AVP that could not be processed successfully. If the failure 3819 reason is omission of a required AVP, an AVP with the missing AVP 3820 code, the missing vendor id, and a zero filled payload of the minimum 3821 required length for the omitted AVP will be added. 3823 AVP Format 3825 ::= < AVP Header: 279 > 3826 1* {AVP} 3828 8.0 Diameter User Sessions 3830 Diameter can provide two different types of services to applications. 3831 The first involves authentication and authorization, and can 3832 optionally make use of accounting. The second only makes use of 3833 accounting. 3835 When a service makes use of the authentication and/or authorization 3836 portion of an application, and a user requests access to the network, 3837 the Diameter client issues an auth request to its local server. The 3838 auth request is defined in a service specific Diameter application 3839 (e.g. NASREQ). The request contains a Session-Id AVP, which is used 3840 in subsequent messages (e.g. subsequent authorization, accounting, 3841 etc) relating to the user's session. The Session-Id AVP is a means 3842 for the client and servers to correlate a Diameter message with a 3843 user session. 3845 When a Diameter server authorizes a user to use network resources for 3846 a finite amount of time, and it is willing to extend the 3847 authorization via a future request, it MUST add the Authorization- 3848 Lifetime AVP to the answer message. The Authorization-Lifetime AVP 3849 defines the maximum number of seconds a user MAY make use of the 3850 resources before another authorization request is expected by the 3851 server. The Auth-Grace-Period AVP contains the number of seconds 3852 following the expiration of the Authorization-Lifetime, after which 3853 the server will release all state information related to the user's 3854 session. Note that if payment for services is expected by the serving 3855 realm from the user's home realm, the Authorization-Lifetime AVP, 3856 combined with the Auth-Grace-Period AVP, implies the maximum length 3857 of the session the home realm is willing to be fiscally responsible 3858 for. Services provided past the expiration of the Authorization- 3859 Lifetime and Auth-Grace-Period AVPs is the responsibility of the 3860 access device. Of course, the actual cost of services rendered is 3861 clearly outside the scope of the protocol. 3863 An access device that does not expect to send a re-authorization or a 3864 session termination request to the server MAY include the Auth- 3865 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint 3866 to the server. If the server accepts the hint, it agrees that since 3867 no session termination message will be received once service to the 3868 user is terminated, it cannot maintain state for the session. If the 3869 answer message from the server contains a different value in the 3870 Auth-Session-State AVP (or the default value if the AVP is absent), 3871 the access device MUST follow the server's directives. Note that the 3872 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re- 3873 authorization requests and answers. 3875 The base protocol does not include any authorization request 3876 messages, since these are largely application-specific and are 3877 defined in a Diameter application document. However, the base 3878 protocol does define a set of messages that are used to terminate 3879 user sessions. These are used to allow servers that maintain state 3880 information to free resources. 3882 When a service only makes use of the Accounting portion of the 3883 Diameter protocol, even in combination with an application, the 3884 Session-Id is still used to identify user sessions. However, the 3885 session termination messages are not used, since a session is 3886 signaled as being terminated by issuing an accounting stop message. 3888 8.1 Authorization Session State Machine 3890 This section contains a finite state machine, representing the life 3891 cycle of Diameter sessions, and MUST be observed by all Diameter 3892 implementations that make use of the authentication and/or 3893 authorization portion of a Diameter application. The term Service- 3894 Specific below refers to a message defined in a Diameter application 3895 (e.g. Mobile IP, NASREQ). 3897 There are two different session state machines supported in the 3898 Diameter base protocol. The first consists of a session in which the 3899 server is maintaining session state, indicated by the value of the 3900 Auth-Session-State AVP (or its absence). The second state machine is 3901 used when the server does not maintain session state. 3903 When a session is moved to the Idle state, any resources that were 3904 allocated for the particular session must be released. Any event not 3905 listed in the state machines MUST be considered as an error 3906 condition, and an answer, if applicable, MUST be returned to the 3907 originator of the message. 3909 The following state machine is used when state is maintained on the 3910 server: 3912 State Event Action New State 3913 ------------------------------------------------------------- 3914 Idle Client or Device Requests send Pending 3915 access service 3916 specific 3917 auth req 3919 Idle Service-specific authorization send Open 3920 request received, and successful 3921 user is authorized serv. 3922 specific answer 3924 Idle Service-specific authorization send Idle 3925 request received, and failed serv. 3926 user is not authorized specific answer 3928 Pending Successful Service-specific Grant Open 3929 authorization answer Access 3930 received with default 3931 Auth-Session-State value 3933 Pending Successful Service-specific Sent STR Discon 3934 authorization answer received 3935 but service not provided 3937 Pending Error processing successful Sent STR Discon 3938 Service-specific authorization 3939 answer 3941 Pending Failed Service-specific Cleanup Idle 3942 authorization answer received 3944 Open user or client device send Open 3945 requests access to service service 3946 specific 3947 auth req 3949 Open Service-specific authorization send Open 3950 request received, and user successful 3951 is authorized serv. specific 3952 answer 3954 Open Service-specific authorization send Idle 3955 request received, and user Failed serv. 3956 is not authorized specific 3957 answer, 3958 Cleanup 3960 Open Successful Service-specific Extend Open 3961 authorization answer received Answer 3963 Open Accounting message sent or process Open 3964 received 3966 Open Failed Service-specific Discon. Idle 3967 authorization answer user/device 3968 received. 3970 Open Session-Timeout Expires on send STR Discon 3971 Access Device 3973 Open Home server wants to send ASR Open 3974 terminate the service 3976 Open ASA Received Cleanup Idle 3977 with Result-Code 3978 = UNKNOWN-SESSION-ID 3980 Open ASA Received None Open 3981 with Result-Code (ignore) 3982 not = UNKNOWN-SESSION-ID 3984 Open ASR Received send ASA, Discon 3985 STR 3987 Open Authorization-Lifetime + send STR Discon 3988 Auth-Grace-Period expires on 3989 access device 3991 Open Authorization-Lifetime (and Cleanup Discon 3992 Auth-Grace-Period) expires 3993 on home server. 3995 Open Session-Timeout expires on Cleanup Discon 3996 home server 3998 Open STR Received Send STA Idle 4000 Not ASA Received None No Change. 4001 Open 4003 Discon ASR Received None Discon 4005 Discon STR Received Send STA Idle 4007 Discon STA Received Discon. Idle 4008 user/device 4010 The following state machine is used when state is not maintained on 4011 the server: 4013 State Event Action New State 4014 ------------------------------------------------------------- 4015 Idle Client or Device Requests send Pending 4016 access service 4017 specific 4018 auth req 4020 Idle Service-specific authorization send serv. Open 4021 request received, and specific 4022 successfully processed answer 4024 Pending Successful Service-specific Grant Open 4025 authorization answer Access 4026 received with Auth-Session- 4027 State set to 4028 NO_STATE_MAINTAINED 4030 Pending Failed Service-specific Cleanup Idle 4031 authorization answer 4032 received 4034 Open Accounting message sent or process Open 4035 received 4037 Open Session-Timeout Expires on Discon. Idle 4038 Access Device user/device 4040 Open Service to user is terminated Discon. Idle 4041 user/device 4043 8.2 Accounting Session State Machine 4045 For applications that only require accounting services, the following 4046 state machine MUST be supported. 4048 When a session is moved to the Idle state, any resources that were 4049 allocated for the particular session must be released. Any event not 4050 listed in the state machines MUST be considered as an error 4051 condition, and an answer, if applicable, MUST be returned to the 4052 originator of the message. 4054 State Event Action New State 4055 ------------------------------------------------------------- 4056 Idle Client or device requests send PendingS 4057 access accounting 4058 start req. 4060 Idle Accounting start request send Open 4061 received, and successfully accounting 4062 processed. start 4063 answer 4065 Idle Client or device requests send PendingE 4066 a one-time service accounting 4067 event req 4069 Idle Accounting event request send Idle 4070 received, and successfully accounting 4071 processed. event 4072 answer 4074 Idle Records in storage Send PendingB 4075 record 4077 Open Receive Interim Record send Open 4078 accounting 4079 answer 4081 Open User service terminated send PendingL 4082 accounting 4083 stop req. 4085 Open Accounting stop request send Idle 4086 received, and successfully accounting 4087 processed stop answer 4089 PendingL Successful accounting Idle 4090 stop answer received 4092 PendingL Failure to send and buffer Store Idle 4093 space available Stop 4094 Record 4096 PendingL Failure to send and no buffer Idle 4097 space available 4099 PendingE Successful accounting Idle 4100 event answer received 4102 PendingE Failure to send and buffer Store Idle 4103 space available Event 4104 Record 4106 PendingE Failure to send and no buffer Idle 4107 space available 4109 PendingS Successful accounting Open 4110 start answer received 4112 PendingS Failure to send and buffer Store Open 4113 space available and realtime Start 4114 not equal to DELIVER_AND_GRANT Record 4116 PendingS Failure to send and no buffer Open 4117 space available and realtime 4118 equal to GRANT_AND_LOSE 4120 PendingS Failure to send and no buffer Disconnect Idle 4121 space available and realtime user/dev 4122 not equal to 4123 GRANT_AND_LOSE 4125 PendingI Failure to send and (buffer Store Open 4126 space available or old record Interim 4127 can be overwritten) and Record 4128 realtime not equal to 4129 DELIVER_AND_GRANT 4131 PendingI Failure to send and no buffer Open 4132 space available and realtime 4133 equal to GRANT_AND_LOSE 4135 PendingI Failure to send and no buffer Disconnect Idle 4136 space available and realtime user/dev 4137 not equal to GRANT_AND_LOSE 4139 PendingB Successful accounting answer Delete Idle 4140 received record 4142 PendingB Failure to send Idle 4144 8.3 Server-Initiated Re-Auth 4146 A Diameter server may initiate a re-authentication and/or re- 4147 authorization service for a particular session by issuing a Re-Auth- 4148 Request (RAR). 4150 For example, for pre-paid services, the Diameter server that 4151 originally authorized a session may need some confirmation that the 4152 user is still using the services. 4154 An access device that receives a RAR message with Session-Id equal to 4155 a currently active session MUST initiate a re-auth towards the user, 4156 if the service supports this particular feature. Each Diameter 4157 application MUST state whether service-initiated re-auth is 4158 supported, since some applications do not allow access devices to 4159 prompt the user for re-auth. 4161 8.3.1 Re-Auth-Request 4163 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 4164 and the message flags' 'R' bit set, may be sent by any server to the 4165 access device that is providing session service, to request that the 4166 user be re-authenticated and/or re-authorized. 4168 Message Format 4170 ::= < Diameter Header: 258, REQ, PXY > 4171 < Session-Id > 4172 { Origin-Host } 4173 { Origin-Realm } 4174 { Destination-Realm } 4175 { Destination-Host } 4176 { Auth-Application-Id } 4177 { Re-Auth-Request-Type } 4178 [ User-Name ] 4179 [ Origin-State-Id ] 4180 * [ AVP ] 4181 * [ Proxy-Info ] 4182 * [ Route-Record ] 4184 8.3.2 Re-Auth-Answer 4186 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 4187 and the message flags' 'R' bit clear, is sent in response to the RAR. 4188 The Result-Code AVP MUST be present, and indicates the disposition of 4189 the request. 4191 A successful RAA message MUST be followed by an application-specific 4192 authentication and/or authorization message. 4194 Message Format 4195 ::= < Diameter Header: 258, PXY > 4196 < Session-Id > 4197 { Result-Code } 4198 { Origin-Host } 4199 { Origin-Realm } 4200 [ User-Name ] 4201 [ Origin-State-Id ] 4202 [ Error-Message ] 4203 [ Error-Reporting-Host ] 4204 * [ Failed-AVP ] 4205 * [ Redirected-Host ] 4206 [ Redirected-Host-Usage ] 4207 [ Redirected-Host-Cache-Time ] 4208 * [ AVP ] 4209 * [ Proxy-Info ] 4211 8.4 Session Termination 4213 It is necessary for a Diameter server that authorized a session, for 4214 which it is maintaining state, to be notified when that session is no 4215 longer active, both for tracking purposes as well as to allow 4216 stateful agents to release any resources that they may have provided 4217 for the user's session. For sessions whose state is not being 4218 maintained, this section is not used. 4220 When a user session that required Diameter authorization terminates, 4221 the access device that provided the service MUST issue a Session- 4222 Termination-Request (STR) message to the Diameter server that 4223 authorized the service, to notify it that the session is no longer 4224 active. An STR MUST be issued when a user session terminates for any 4225 reason, including user logoff, expiration of Session-Timeout, 4226 administrative action, termination upon receipt of an Abort-Session- 4227 Request (see below), orderly shutdown of the access device, etc. 4229 The access device also MUST issue an STR for a session that was 4230 authorized but never actually started. This could occur, for example, 4231 due to a sudden resource shortage in the access device, or because 4232 the access device is unwilling to provide the type of service 4233 requested in the authorization, or because the access device does not 4234 support a mandatory AVP returned in the authorization, etc. 4236 It is also possible that a session that was authorized is never 4237 actually started due to action of a proxy. For example, a proxy may 4238 modify an authorization answer, converting the result from success to 4239 failure, prior to forwarding the message to the access device. A 4240 proxy that causes an authorized session not to be started MUST issue 4241 an STR to the Diameter server that authorized the session, since the 4242 access device has no way of knowing that the session had been 4243 authorized. 4245 A Diameter server that receives an STR message MUST clean up 4246 resources (e.g., session state) associated with the Session-Id 4247 specified in the STR, and return a Session-Termination-Answer. 4249 A Diameter server also MUST clean up resources when the Session- 4250 Timeout expires, or when the Authorization-Lifetime and the Auth- 4251 Grace-Period AVPs expires without receipt of a re-authorization 4252 request, regardless of whether an STR for that session is received. 4253 The access device is not expected to provide service beyond the 4254 expiration of these timers; thus, expiration of either of these 4255 timers implies that the access device may have unexpectedly shut 4256 down. 4258 8.4.1 Session-Termination-Request 4260 The Session-Termination-Request (STR), indicated by the Command-Code 4261 set to 275 and the Command Flags' 'R' bit set, is sent by the access 4262 device to inform the Diameter Server that an authenticated and/or 4263 authorized session is being terminated. 4265 Message Format 4267 ::= < Diameter Header: 275, REQ, PXY > 4268 < Session-Id > 4269 { Origin-Host } 4270 { Origin-Realm } 4271 { Destination-Realm } 4272 { Auth-Application-Id } 4273 { Termination-Cause } 4274 [ User-Name ] 4275 [ Destination-Host ] 4276 * [ Class ] 4277 [ Origin-State-Id ] 4278 * [ AVP ] 4279 * [ Proxy-Info ] 4280 * [ Route-Record ] 4282 8.4.2 Session-Termination-Answer 4284 The Session-Termination-Answer (STA), indicated by the Command-Code 4285 set to 275 and the message flags' 'R' bit clear, is sent by the 4286 Diameter Server to acknowledge the notification that the session has 4287 been terminated. The Result-Code AVP MUST be present, and MAY contain 4288 an indication that an error occurred while servicing the STR. 4290 Upon sending or receipt of the STA, the Diameter Server MUST release 4291 all resources for the session indicated by the Session-Id AVP. Any 4292 intermediate server in the Proxy-Chain MAY also release any 4293 resources, if necessary. 4295 Message Format 4297 ::= < Diameter Header: 275, PXY > 4298 < Session-Id > 4299 { Result-Code } 4300 { Origin-Host } 4301 { Origin-Realm } 4302 [ User-Name ] 4303 * [ Class ] 4304 [ Error-Message ] 4305 [ Error-Reporting-Host ] 4306 * [ Failed-AVP ] 4307 [ Origin-State-Id ] 4308 * [ Redirect-Host ] 4309 [ Redirect-Host-Usase ] 4310 [ Redirect-Max-Cache-Time ] 4311 * [ AVP ] 4312 * [ Proxy-Info ] 4314 8.5 Aborting a Session 4316 A Diameter server may request that the access device stop providing 4317 service for a particular session by issuing an Abort-Session-Request 4318 (ASR). 4320 For example, the Diameter server that originally authorized the 4321 session may be required to cause that session to be stopped for 4322 credit or other reasons that were not anticipated when the session 4323 was first authorized. On the other hand, an operator may maintain a 4324 management server for the purpose of issuing ASRs to administratively 4325 remove users from the network. 4327 An access device that receives an ASR with Session-ID equal to a 4328 currently active session MAY stop the session. Whether the access 4329 device stops the session or not is implementation- and/or 4330 configuration-dependent. For example, an access device may honor ASRs 4331 from certain agents only. In any case, the access device MUST respond 4332 with an Abort-Session-Answer, including a Result-Code AVP to indicate 4333 what action it took. 4335 Note that if the access device does stop the session upon receipt of 4336 an ASR, it issues an STR to the authorizing server (which may or may 4337 not be the agent issuing the ASR) just as it would if the session 4338 were terminated for any other reason. 4340 8.5.1 Abort-Session-Request 4342 The Abort-Session-Request (ASR), indicated by the Command-Code set to 4343 274 and the message flags' 'R' bit set, may be sent by any server to 4344 the access device that is providing session service, to request that 4345 the session identified by the Session-Id be stopped. 4347 Message Format 4349 ::= < Diameter Header: 274, REQ, PXY > 4350 < Session-Id > 4351 { Origin-Host } 4352 { Origin-Realm } 4353 { Destination-Realm } 4354 { Destination-Host } 4355 { Auth-Application-Id } 4356 [ User-Name ] 4357 [ Origin-State-Id ] 4358 * [ AVP ] 4359 * [ Proxy-Info ] 4360 * [ Route-Record ] 4362 8.5.2 Abort-Session-Answer 4364 The Abort-Session-Answer (ASA), indicated by the Command-Code set to 4365 274 and the message flags' 'R' bit clear, is sent in response to the 4366 ASR. The Result-Code AVP MUST be present, and indicates the 4367 disposition of the request. 4369 If the session identified by Session-Id in the ASR was successfully 4370 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is 4371 not currently active, Result-Code is set to 4372 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the 4373 session for any other reason, Result-Code is set to 4374 DIAMETER_UNABLE_TO_COMPLY. 4376 Message Format 4377 ::= < Diameter Header: 274, PXY > 4378 < Session-Id > 4379 { Result-Code } 4380 { Origin-Host } 4381 { Origin-Realm } 4382 [ User-Name ] 4383 [ Origin-State-Id ] 4384 [ Error-Message ] 4385 [ Error-Reporting-Host ] 4386 * [ Failed-AVP ] 4387 * [ Redirected-Host ] 4388 [ Redirected-Host-Usage ] 4389 [ Redirected-Max-Cache-Time ] 4390 * [ AVP ] 4391 * [ Proxy-Info ] 4393 8.6 Inferring Session Termination from Origin-State-Id 4395 Origin-State-Id is used to allow rapid detection of terminated 4396 sessions for which no STR would have been issued, due to 4397 unanticipated shutdown of an access device. 4399 By including Origin-State-Id in CER/CAA messages, an access device 4400 allows a next-hop server to determine immediately upon connection 4401 whether the device has lost its sessions since the last connection. 4403 By including Origin-State-Id in request messages, an access device 4404 also allows a server with which it communicates via proxy to make 4405 such a determination. However, a server that is not directly 4406 connected with the access device will not discover that the access 4407 device has been restarted unless and until it receives a new request 4408 from the access device. Thus, use of this mechanism across proxies is 4409 opportunistic rather than reliable, but useful nonetheless. 4411 When a Diameter server receives an Origin-State-Id that is greater 4412 than the Origin-State-Id previously received from the same issuer, it 4413 may assume that the issuer has lost state since the previous message 4414 and that all sessions that were active under the lower Origin-State- 4415 Id have been terminated. The Diameter server MAY clean up all session 4416 state associated with such lost sessions, and MAY also issues STRs 4417 for all such lost sessions that were authorized on upstream servers, 4418 to allow session state to be cleaned up globally. 4420 8.7 Auth-Request-Type AVP 4422 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is 4423 included in application-specific auth requests to inform the peers 4424 whether a user is to be authenticated only, authorized only or both. 4425 Note any value other than both MAY cause RADIUS interoperability 4426 issues. The following values are defined: 4428 AUTHENTICATE_ONLY 1 4429 The request being sent is for authentication only, and MUST 4430 contain the relevant application specific authentication AVPs 4431 that are needed by the Diameter server to authenticate the 4432 user. 4434 AUTHORIZE_ONLY 2 4435 The request being sent is for authorization only, and MUST 4436 contain the application specific authorization AVPs that are 4437 necessary to identify the service being requested/offered. 4439 AUTHORIZE_AUTHENTICATE 3 4440 The request contains a request for both authentication and 4441 authorization. The request MUST include both the relevant 4442 application specific authentication information, and 4443 authorization information necessary to identify the service 4444 being requested/offered/. 4446 8.8 Session-Id AVP 4448 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used 4449 to identify a specific session (see section 8.0). All messages 4450 pertaining to a specific session MUST include only one Session-Id AVP 4451 and the same value MUST be used throughout the life of a session. 4452 When present, the Session-Id SHOULD appear immediately following the 4453 Diameter Header (see section 3.0). 4455 The Session-Id MUST be globally and eternally unique, as it is meant 4456 to uniquely identify a user session without reference to any other 4457 information, and may be needed to correlate historical authentication 4458 information with accounting information. The Session-Id includes a 4459 mandatory portion and an implementation-defined portion; a 4460 recommended format for the implementation-defined portion is outlined 4461 below. 4463 The Session-Id MUST begin with the sender's identity encoded in the 4464 DiameterIdentity type (see section 4.4). The remainder of the 4465 Session-Id MAY be any sequence that the client can guarantee to be 4466 eternally unique; however, the following format is recommended, 4467 (square brackets [] indicate an optional element): 4469 ;;[;] 4470 and are decimal representations of the 4471 high and low 32 bits of a monotonically increasing 64-bit value. The 4472 64-bit value is rendered in two part to simplify formatting by 32-bit 4473 processors. At startup, the high 32 bits of the 64-bit value MAY be 4474 initialized to the time, and the low 32 bits MAY be initialized to 4475 zero. This will for practical purposes eliminate the possibility of 4476 overlapping Session-Ids after a reboot, assuming the reboot process 4477 takes longer than a second. Alternatively, an implementation MAY keep 4478 track of the increasing value in non-volatile memory. 4480 is implementation specific but may include a modem's 4481 device Id, a layer 2 address, timestamp, etc. 4483 Example, in which there is no optional value: 4484 accesspoint7.acme.com;1876543210;523 4486 Example, in which there is an optional value: 4487 accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 4489 The Session-Id is created by the Diameter device initiating the 4490 session, which in most cases is done by the client. Note that a 4491 Session-Id MAY be used for both the authorization and accounting 4492 commands of a given application. 4494 8.9 Authorization-Lifetime AVP 4496 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 4497 and contains the maximum number of seconds of service to be provided 4498 to the user before the user is to be re-authenticated and/or re- 4499 authorized. Great care should be taken when the Authorization- 4500 Lifetime value is determined, since a low, non-zero, value could 4501 create significant Diameter traffic, which could congest both the 4502 network and the agents. 4504 A value of zero (0) means that immediate re-auth is necessary by the 4505 access device. This is typically used in cases where multiple 4506 authentication methods are used, and a successful auth response with 4507 this AVP set to zero is used to signal that the next authentication 4508 method is to be immediately initiated. The absence of this AVP, or a 4509 value of all ones (meaning all bits in the 32 bit field are set to 4510 one) means no re-auth is expected. 4512 If both this AVP and the Session-Timeout AVP are present in a 4513 message, the value of the latter MUST NOT be smaller than the 4514 Authorization-Lifetime AVP. 4516 An Authorization-Lifetime AVP MAY be present in re-authorization 4517 messages, and contains the number of seconds the user is authorized 4518 to receive service from the time the re-auth answer message is 4519 received by the access device. 4521 This AVP MAY be provided by the client as a hint of the maximum 4522 lifetime that it is willing to accept. However, the server MAY return 4523 a value that is equal to, or smaller, than the one provided by the 4524 client. 4526 8.10 Auth-Grace-Period AVP 4528 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and 4529 contains the number of seconds the Diameter server will wait 4530 following the expiration of the Authorization-Lifetime AVP before 4531 cleaning up resources for the session. 4533 8.11 Auth-Session-State AVP 4535 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and 4536 specifies whether state is maintained for a particular session. The 4537 client MAY include this AVP in requests as a hint to the server, but 4538 the value in the server's answer message is binding. The following 4539 values are supported: 4541 STATE_MAINTAINED 0 4542 This value is used to specify that session state is being 4543 maintained, and the access device MUST issue a session 4544 termination message when service to the user is terminated. 4545 This is the default value. 4547 NO_STATE_MAINTAINED 1 4548 This value is used to specify that no session termination 4549 messages will be sent by the access device upon expiration of 4550 the Authorization-Lifetime. 4552 8.12 Re-Auth-Request-Type AVP 4554 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and 4555 is included in application-specific auth answers to inform the client 4556 of the action expected upon expiration of the Authorization-Lifetime. 4557 The following values are defined: 4559 AUTHORIZE_ONLY 0 4560 An authorization only re-auth is expected upon expiration of 4561 the Authorization-Lifetime. This is the default value if the 4562 AVP is not present in answer messages that include the 4563 Authorization-Lifetime. 4565 AUTHORIZE_AUTHENTICATE 1 4566 An authentication and authorization re-auth is expected upon 4567 expiration of the Authorization-Lifetime. 4569 8.13 Session-Timeout AVP 4571 The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 4572 and contains the maximum number of seconds of service to be provided 4573 to the user before termination of the session. When both the Session- 4574 Timeout and the Authorization-Lifetime AVPs are present in an answer 4575 message, the former MUST be equal to or greater than the value of the 4576 latter. 4578 A session that terminates on an access device due to the expiration 4579 of the Session-Timeout MUST cause an STR to be issued, unless both 4580 the access device and the home server had previously agreed that no 4581 session termination messages would be sent (see section 8.9). 4583 A Session-Timeout AVP MAY be present in a re-authorization message, 4584 and contains the number of seconds from the beginning of the re-auth. 4586 A value of zero, or the absence of this AVP, means that this session 4587 has an unlimited number of seconds before termination. 4589 This AVP MAY be provided by the client as a hint of the maximum 4590 timeout that it is willing to accept. However, the server MAY return 4591 a value that is equal to, or smaller, than the one provided by the 4592 client. 4594 8.14 User-Name AVP 4596 The User-Name AVP (AVP Code 1) [RADIUS] is of type UTF8String, which 4597 contains the User-Name, in a format consistent with the NAI 4598 specification [NAI]. 4600 8.15 Termination-Cause AVP 4602 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and 4603 is used to indicate the reason why a session was terminated on the 4604 access device. The following values are defined: 4606 DIAMETER_LOGOUT 1 4607 The user initiated a disconnect 4609 DIAMETER_SERVICE_NOT_PROVIDED 2 4610 This value is used when the user disconnected prior to the 4611 receipt of the authorization answer message. 4613 DIAMETER_BAD_ANSWER 3 4614 This value indicates that the authorization answer received by 4615 the access device was not processed successfully. 4617 DIAMETER_ADMINISTRATIVE 4 4618 The user was not granted access, or was disconnected, due to 4619 administrative reasons, such as the receipt of a Abort-Session- 4620 Request message. 4622 DIAMETER_LINK_BROKEN 5 4623 The communication to the user was abruptly disconnected. 4625 DIAMETER_AUTH_EXPIRED 6 4626 The user's access was terminated since its authorized session 4627 time has expired. 4629 DIAMETER_USER_MOVED 7 4630 The user is receiving services from another access device. 4632 DIAMETER_SESSION_TIMEOUT 8 4633 The user's session has timed out, and service has been 4634 terminated. 4636 8.16 Origin-State-Id AVP 4638 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a 4639 monotonically increasing value that is advanced whenever a Diameter 4640 entity restarts with loss of previous state, for example upon reboot. 4641 Origin-State-Id MAY be included in any Diameter message, including 4642 CER. 4644 A Diameter entity issuing this AVP MUST create a higher value for 4645 this AVP each time its state is reset. A Diameter entity MAY set 4646 Origin-State-Id to the time of startup, or it MAY use an incrementing 4647 counter retained in non-volatile memory across restarts. 4649 The Origin-State-Id, if present, MUST reflect the state of the entity 4650 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST 4651 either remove Origin-State-Id or modify it appropriately as well. 4653 Typically, Origin-State-Id is used by an access device that always 4654 starts up with no active sessions; that is, any session active prior 4655 to restart will have been lost. By including Origin-State-Id in a 4656 message, it allows other Diameter entities to infer that sessions 4657 associated with a lower Origin-State-Id are no longer active. If an 4658 access device does not intend for such inferences to be made, it MUST 4659 either not include Origin-State-Id in any message, or set its value 4660 to 0. 4662 8.17 Session-Binding AVP 4664 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY 4665 be present in application-specific authorization answer messages. If 4666 present, this AVP MAY inform the Diameter client that all future 4667 application-specific re-auth messages for this session MUST be sent 4668 to the same authorization server. This AVP MAY also specify that a 4669 Session-Termination-Request message for this session MUST be sent to 4670 the same authorizing server. 4672 This field is a bit mask, and the following bits have been defined: 4674 RE_AUTH 1 4675 When set, future re-auth messages for this session MUST NOT 4676 include the Destination-Host AVP. When cleared, the default 4677 value, the Destination-Host AVP MUST be present in all re-auth 4678 messages for this session. 4680 STR 2 4681 When set, the STR message for this session MUST NOT include the 4682 Destination-Host AVP. When cleared, the default value, the 4683 Destination-Host AVP MUST be present in the STR message for 4684 this session. 4686 ACCOUNTING 4 4687 When set, all accounting messages for this session MUST NOT 4688 include the Destination-Host AVP. When cleared, the default 4689 value, the Destination-Host AVP MUST be present in all 4690 accounting messages for this session. 4692 8.18 Session-Server-Failover AVP 4694 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated, 4695 and MAY be present in application-specific authorization answer 4696 messages that either do not include the Session-Binding AVP or 4697 include the Session-Binding AVP with any of the bits set to a zero 4698 value. If present, this AVP MAY inform the Diameter client that if a 4699 re-auth or STR message fails due to a delivery problem, the Diameter 4700 client SHOULD issue a subsequent message without the Destination-Host 4701 AVP. When absent, the default value is REFUSE_SERVICE. 4703 The following values are supported: 4705 REFUSE_SERVICE 0 4706 If either the re-auth or the STR message delivery fails, 4707 terminate service with the user, and do not attempt any 4708 subsequent attempts. 4710 TRY_AGAIN 1 4711 If either the re-auth or the STR message delivery fails, resend 4712 the failed message without the Destination-Host AVP present. 4714 ALLOW_SERVICE 2 4715 If re-auth message delivery fails, assume that re-authorization 4716 succeeded. If STR message delivery fails, terminate the 4717 session. 4719 TRY_AGAIN_ALLOW_SERVICE 3 4720 If either the re-auth or the STR message delivery fails, resend 4721 the failed message without the Destination-Host AVP present. 4722 If the second delivery fails for re-auth, assume re- 4723 authorization succeeded. If the second delivery fails for STR, 4724 terminate the session. 4726 8.19 Multi-Round-Time-Out AVP 4728 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32, 4729 and SHOULD be present in application-specific authorization answer 4730 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. 4731 This AVP contains the maximum number of seconds that the access 4732 device MUST provide the user in responding to an authentication 4733 request. 4735 8.20 Class AVP 4737 The Class AVP (AVP Code 25) is of type OctetString and is used to by 4738 Diameter servers to return state information to the access device. 4739 When one or more Class AVPs are present in application-specific 4740 authorization answer messages, they MUST be present in subsequent re- 4741 authorization, session termination and accounting messages. Class 4742 AVPs found in a re-authorization answer message override the ones 4743 found in any previous authorization answer message. Diameter server 4744 implementations SHOULD NOT return Class AVPs that require more than 4745 4096 bytes of storage on the Diameter client. A Diameter client that 4746 receives Class AVPs whose size exceeds local available storage MUST 4747 terminate the session. 4749 9.0 Accounting 4751 This accounting protocol is based on a server directed model with 4752 capabilities for real-time delivery of accounting information. 4753 Several fault resilience methods [ACCMGMT] have been built in to the 4754 protocol in order minimize loss of accounting data in various fault 4755 situations and under different assumptions about the capabilities of 4756 the used devices. 4758 9.1 Server Directed Model 4760 The server directed model means that the device generating the 4761 accounting data gets information from either the authorization server 4762 (if contacted) or the accounting server regarding the way accounting 4763 data shall be forwarded. This information includes accounting record 4764 timeliness requirements. 4766 As discussed in [ACCMGMT], real-time transfer of accounting records 4767 is a requirement, such as the need to perform credit limit checks and 4768 fraud detection. Note that batch accounting is not a requirement, and 4769 is therefore not supported by Diameter. Should Batched Accounting be 4770 required in the future, a new Diameter application will need to be 4771 created, or it could be handled using another protocol. 4773 The authorization server (chain) directs the selection of proper 4774 transfer strategy, based on its knowledge of the user and 4775 relationships of roaming partnerships. The server (or agents) uses 4776 the Accounting-Interim-Interval AVP to control the operation of the 4777 Diameter peer operating as a client. The Accounting-Interim-Interval 4778 AVP, when present, instructs the Diameter node acting as a client to 4779 produce accounting records continuously even during a session. 4781 The Diameter accounting server MAY override the interim interval by 4782 including an Accounting-Interim-Interval AVP in the Accounting-Answer 4783 message. When the AVP is present, the latest value received SHOULD be 4784 used in the generation of interim accounting messages. 4786 9.2 Protocol Messages 4788 A Diameter node that receives a successful authentication and/or 4789 authorization messages from the Home AAA server MUST collect 4790 accounting information for the session. The Accounting-Request 4791 message is used to transmit the accounting information to the Home 4792 AAA server, which MUST reply with the Accounting-Answer message to 4793 confirm reception. The Accounting-Answer message includes the Result- 4794 Code AVP, which MAY indicate that an error was present in the 4795 accounting message. A rejected Accounting-Request message SHOULD 4796 cause the user's session to be terminated. 4798 Each Diameter Accounting protocol message MAY be compressed using 4799 IPComp [IPComp] in order to reduce the used network bandwidth, which 4800 MAY use IKE [IKE] to negotiate the compression parameters. 4802 9.3 Application document requirements 4804 Each Diameter application (e.g. NASREQ, MobileIP), MUST define their 4805 Service-Specific AVPs that MUST be present in the Accounting-Request 4806 message in a section entitled "Accounting AVPs". The application MUST 4807 assume that the AVPs described in this document will be present in 4808 all Accounting messages, so only their respective service-specific 4809 AVPs need to be defined in this section. 4811 9.4 Fault Resilience 4813 Diameter Base protocol mechanisms are used to overcome small message 4814 loss and network faults of temporary nature. 4816 Diameter peers acting as clients MUST implement the use of failover 4817 to guard against server failures and certain network failures. 4818 Diameter peers acting as agents or related off-line processing 4819 systems MUST detect duplicate accounting records caused by the 4820 sending of same record to several servers and duplication of messages 4821 in transit. This detection MUST be based on the inspection of the 4822 Session-Id and Accounting-Record-Number AVP pairs. Appendix C 4823 discusses duplicate detection need and implementation issues. 4825 Diameter clients MAY have non-volatile memory for the safe storage of 4826 accounting records over reboots or extended network failures, network 4827 partitions, and server failures. If such memory is available, the 4828 client SHOULD store new accounting records there as soon as the 4829 records are created and until a positive acknowledgement of their 4830 reception from the Diameter Server has been received. Upon a reboot, 4831 the client MUST starting sending the records in the non-volatile 4832 memory to the accounting server with appropriate modifications in 4833 termination cause, session length, and other relevant information in 4834 the records. 4836 A further application of this protocol may include AVPs to control 4837 how many accounting records may at most be stored in the Diameter 4838 client without committing them to the non-volatile memory or 4839 transferring them to the Diameter server. 4841 The client SHOULD NOT remove the accounting data from any of its 4842 memory areas before the correct Accounting-Answer has been received. 4843 The client MAY remove oldest, undelivered or yet unacknowledged 4844 accounting data if it runs out of resources such as memory. It is an 4845 implementation dependent matter for the client to accept new sessions 4846 under this condition. 4848 9.5 Accounting Records 4850 In all accounting records, the Session-Id AVP MUST be present; the 4851 User-Name AVP MUST be present if it is available to the Diameter 4852 client. If strong authentication across agents is required, as 4853 described in [CMS], the CMS-Signed-Data AVP may be used to 4854 authenticate the Accounting Data and Service Specific AVPs. It is not 4855 typically necessary that the CMS-Signed-Data AVP cover any additional 4856 AVPs, but it is permitted as long as the AVPs protected are defined 4857 to have their 'P' bit set. 4859 Different types of accounting records are sent depending on the 4860 actual type of accounted service and the authorization server's 4861 directions for interim accounting. If the accounted service is a one- 4862 time event, meaning that the start and stop of the event are 4863 simultaneous, then the Accounting-Record-Type AVP MUST be present and 4864 set to the value EVENT_RECORD. 4866 If the accounted service is of a measurable length, then the AVP MUST 4867 use the values START_RECORD, STOP_RECORD, and possibly, 4868 INTERIM_RECORD. If the authorization server has directed interim 4869 accounting to be enabled for the session, but no interim interval was 4870 specified, two accounting records MUST be generated for each service 4871 of type session. When the initial Accounting-Request for a given 4872 session is sent, the Accounting-Record-Type AVP MUST be set to the 4873 value START_RECORD. When the last Accounting-Request is sent, the 4874 value MUST be STOP_RECORD. 4876 If a specified interim interval exists, the Diameter client MUST 4877 produce additional records between the START_RECORD and STOP_RECORD, 4878 marked INTERIM_RECORD. The production of these records is directed by 4879 both Accounting-Interim-Interval as well as any re-authentication or 4880 re-authorization of the session. The Diameter client MUST overwrite 4881 any previous interim accounting records that are locally stored for 4882 delivery, if a new record is being generated for the same session. 4884 This ensures that only one pending interim record can exist on an 4885 access device for any given session. 4887 A particular value of Accounting-Sub-Session-Id MUST appear only in 4888 one sequence of accounting records from a DIAMETER client, except for 4889 the purposes of retransmission. The one sequence that is sent MUST 4890 be either one record with Accounting-Record-Type AVP set to the value 4891 EVENT_RECORD, or several records starting with one having the value 4892 START_RECORD, followed by zero or more INTERIM_RECORD and a single 4893 STOP_RECORD. A particular Diameter application specification MUST 4894 define the type of sequences that MUST be used. 4896 9.6 Correlation of Accounting Records 4898 The Diameter protocol's Session-Id AVP, which is globally unique (see 4899 section 8.8), is used during the authorization phase to identify a 4900 particular session. Services that do not require any authorization 4901 still use the Session-Id AVP to identify sessions. 4903 However, there are certain applications that require multiple 4904 accounting sub-sessions. Such applications would send messages with a 4905 constant Session-Id AVP, but a different Accounting-Sub-Session-Id 4906 AVP. In these cases, correlation is performed using the Session-Id. 4907 It is important to note that receiving a STOP_RECORD with no 4908 Accounting-Sub-Session-Id AVP when sub-sessions were originally used 4909 in the START_RECORD messages implies that all sub-sessions are 4910 terminated. 4912 Furthermore, there are certain applications where a user receives 4913 service from different access devices (e.g. Mobile IP), each with 4914 their own unique Session-Id. In such cases, the Accounting-Multi- 4915 Session-Id AVP is used for correlation. During authorization, a 4916 server that determines that a request is for an existing session 4917 SHOULD include the Accounting-Multi-Session-Id AVP, which the access 4918 device MUST include in all subsequent accounting messages. 4920 The Accounting-Multi-Session-Id AVP MAY include the value of the 4921 original Session-Id. It's contents are implementation specific, but 4922 MUST be globally unique across other Accounting-Multi-Session-Id, and 4923 MUST NOT change during the life of a session. 4925 A Diameter application document MUST define the exact concept of a 4926 session that is being accounted, and MAY define the concept of a 4927 multi-session. For instance, the NASREQ DIAMETER application treats a 4928 single PPP connection to a Network Access Server as one session, and 4929 a set of Multilink PPP sessions as one multi-session. 4931 9.7 Accounting Command-Codes 4933 This section defines new Command-Code values that MUST be supported 4934 by all Diameter implementations that provide Accounting services. 4936 9.7.1 Accounting-Request 4938 The Accounting-Request (ACR) command, indicated by the Command-Code 4939 field set to 271 and the Command Flags' 'R' bit set, is sent by a 4940 Diameter node, acting as a client, in order to exchange accounting 4941 information with a peer. 4943 When the Accounting-Request is being submitted to a third party (e.g. 4944 settlement service), and includes the CMS-Signed-Data AVP [CMS], the 4945 CMS-Signed-Data AVP MUST be signed by both the local and home 4946 Diameter server using the countersignature procedures described in 4947 [CMS]. 4949 The AVP listed below SHOULD include service specific accounting AVPs, 4950 as described in section 9.3. 4952 Message Format 4954 ::= < Diameter Header: 271, REQ, PXY > 4955 < Session-Id > 4956 { Acct-Application-Id } 4957 { Origin-Host } 4958 { Origin-Realm } 4959 { Destination-Realm } 4960 { Accounting-Record-Type } 4961 { Accounting-Record-Number } 4962 [ User-Name ] 4963 [ Accounting-Sub-Session-Id ] 4964 [ Accounting-RADIUS-Session-Id ] 4965 [ Accounting-Multi-Session-Id ] 4966 [ Accounting-Interim-Interval ] 4967 [ Origin-State-Id ] 4968 * [ AVP ] 4969 * [ Proxy-Info ] 4970 * [ Route-Record ] 4972 9.7.2 Accounting-Answer 4974 The Accounting-Answer (ACA) command, indicated by the Command-Code 4975 field set to 271 and the Command Flags' 'R' bit cleared, is used to 4976 acknowledge an Accounting-Request command. The Accounting-Answer 4977 command contains the same Session-Id and MAY contains the same 4978 Accounting Description and Usage AVPs that were sent in the 4979 Accounting-Request command. If the CMS-Data AVP was present in the 4980 Accounting-Request, the corresponding ACA message MUST include the 4981 CMS-Data AVP signed by the responder to provide strong AVP 4982 authentication, which MAY be used for the purposes of repudiation. 4984 Only the target Diameter Server, known as the home Diameter Server, 4985 SHOULD respond with the Accounting-Answer command. 4987 The AVP listed below SHOULD include service specific accounting AVPs, 4988 as described in section 9.3. 4990 Message Format 4992 ::= < Diameter Header: 271, PXY > 4993 < Session-Id > 4994 { Acct-Application-Id } 4995 { Result-Code } 4996 { Origin-Host } 4997 { Origin-Realm } 4998 { Accounting-Record-Type } 4999 { Accounting-Record-Number } 5000 [ User-Name ] 5001 [ Accounting-Sub-Session-Id ] 5002 [ Accounting-RADIUS-Session-Id ] 5003 [ Accounting-Multi-Session-Id ] 5004 [ Error-Reporting-Host ] 5005 [ Accounting-Interim-Interval ] 5006 [ Origin-State-Id ] 5007 * [ AVP ] 5008 * [ Proxy-Info ] 5010 9.8 Accounting AVPs 5012 This section contains AVPs that describe accounting usage information 5013 related to a specific session. 5015 9.8.1 Accounting-Record-Type AVP 5017 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated 5018 and contains the type of accounting record being sent. The following 5019 values are currently defined for the Accounting-Record-Type AVP: 5021 EVENT_RECORD 1 5022 An Accounting Event Record is used to indicate that a one-time 5023 event has occurred (meaning that the start and end of the event 5024 are simultaneous). This record contains all information 5025 relevant to the service, and is the only record of the service. 5027 START_RECORD 2 5028 An Accounting Start, Interim, and Stop Records are used to 5029 indicate that a service of a measurable length has been given. 5030 An Accounting Start Record is used to initiate an accounting 5031 session, and contains accounting information that is relevant 5032 to the initiation of the session. 5034 INTERIM_RECORD 3 5035 An Interim Accounting Record contains cumulative accounting 5036 information for an existing accounting session. Interim 5037 Accounting Records SHOULD be sent every time a re- 5038 authentication or re-authorization occurs. Further, additional 5039 interim record triggers MAY be defined by application-specific 5040 Diameter applications. The selection of whether to use 5041 INTERIM_RECORD records is directed by the Accounting-Interim- 5042 Interval AVP. 5044 STOP_RECORD 4 5045 An Accounting Stop Record is sent to terminate an accounting 5046 session and contains cumulative accounting information relevant 5047 to the existing session. 5049 9.8.2 Accounting-Interim-Interval AVP 5051 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 5052 Unsigned32 and is sent from the Diameter home authorization server to 5053 the Diameter client. The client uses information in this AVP to 5054 decide how and when to produce accounting records. With different 5055 values in this AVP, service sessions can result in one, two, or two+N 5056 accounting records, based on the needs of the home-organization. The 5057 following accounting record production behavior is directed by the 5058 inclusion of this AVP: 5060 1. The omission of the Accounting-Interim-Interval AVP or its 5061 inclusion with Value field set to 0 means that EVENT_RECORD, 5062 START_RECORD, and STOP_RECORD are produced, as appropriate for 5063 the service. 5065 2. The inclusion of the AVP with Value field set to a non-zero 5066 value means that INTERIM_RECORD records MUST be produced 5067 between the START_RECORD and STOP_RECORD records. The Value 5068 field of this AVP is the nominal interval between these records 5069 in seconds. The Diameter node that originates the accounting 5070 information, known as the client, MUST produce the first 5071 INTERIM_RECORD record roughly at the time when this nominal 5072 interval has elapsed from the START_RECORD, the next one again 5073 as the interval has elapsed once more, and so on until the 5074 session ends and a STOP_RECORD record is produced. 5076 The client MUST ensure that the interim record production times 5077 are randomized so that large accounting message storms are not 5078 created either among records or around a common service start 5079 time. 5081 9.8.3 Accounting-Record-Number AVP 5083 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 5084 and identifies this record within one session. As Session-Id AVPs are 5085 globally unique, the combination of Session-Id and Accounting-Record- 5086 Number AVPs is also globally unique, and can be used in matching 5087 accounting records with confirmations. An easy way to produce unique 5088 numbers is to set the value to 0 for records of type EVENT_RECORD and 5089 START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 5090 for the second, and so on until the value for STOP_RECORD is one more 5091 than for the last INTERIM_RECORD. 5093 9.8.4 Accounting-RADIUS-Session-Id AVP 5095 The Accounting-RADIUS-Session-Id AVP (AVP Code 44) is of type 5096 OctetString is only used when RADIUS/Diameter translation occurs. 5097 This AVP contains the contents of the RADIUS Accounting-Session-Id 5098 attribute. 5100 9.8.5 Accounting-Multi-Session-Id AVP 5102 The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type 5103 UTF8String, following the format specified in section 8.8. The 5104 Accounting-Multi-Session-Id AVP is used to link together multiple 5105 related accounting sessions, where each session would have a unique 5106 Session-Id, but the same Accounting-Multi-Session-Id AVP. This AVP 5107 MAY be returned by the Diameter server in an authorization answer, 5108 and MUST be used in all accounting messages for the given session. 5110 9.8.6 Accounting-Sub-Session-Id AVP 5112 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type 5113 Unsigned64 and contains the accounting sub-session identifier. The 5114 combination of the Session-Id and this AVP MUST be unique per sub- 5115 session, and the value of this AVP MUST be monotonically increased by 5116 one for all new sub-sessions. The absence of this AVP implies no sub- 5117 sessions are in use, with the exception of an Accounting-Request 5118 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD 5119 message with no Accounting-Sub-Session-Id AVP present will signal the 5120 termination of all sub-sessions for a given Session-Id. 5122 9.8.7 Accounting-Realtime-Required AVP 5124 The Accounting-Realtime-Required AVP (AVP Code TBD) is of type 5125 Enumerated and is sent from the Diameter home authorization server to 5126 the Diameter client or in the Accounting-Answer from the accounting 5127 server. The client uses information in this AVP to decide what to do 5128 if the sending of accounting records to the accounting server has 5129 been temporarily prevented due to, for instance, a network problem. 5131 DELIVER_AND_GRANT 1 5133 The AVP with Value field set to DELIVER_AND_GRANT means that 5134 the service MUST only be granted as long as there is a 5135 connection to an accounting server. Note that the set of 5136 alternative accounting servers are treated as one server in 5137 this sense. Having to move the accounting record stream to a 5138 backup server is not a reason to discontinue the service to the 5139 user. 5141 GRANT_AND_STORE 2 5143 The AVP with Value field set to GRANT_AND_STORE means that 5144 service SHOULD be granted if there is a connection, or as long 5145 as records can still be stored as described in section 9.4. 5147 This is the default behaviour if the AVP isn't included in the 5148 reply from the authorization server. 5150 GRANT_AND_LOSE 3 5152 The AVP with Value field set to GRANT_AND_LOSE means that 5153 service SHOULD be granted even if the records can not be 5154 delivered or stored. 5156 10.0 AVP Occurrence Table 5158 The following tables presents the AVPs defined in this document, and 5159 specifies in which Diameter messages they MAY, or MAY NOT be present. 5160 Note that AVPs that can only be present within a Grouped AVP are not 5161 represented in this table. 5163 The table uses the following symbols: 5164 0 The AVP MUST NOT be present in the message. 5165 0+ Zero or more instances of the AVP MAY be present in the 5166 message. 5167 0-1 Zero or one instance of the AVP MAY be present in the 5168 message. It is considered an error if there are more than 5169 once instance of the AVP. 5170 1 One instance of the AVP MUST be present in the message. 5171 1+ At least one instance of the AVP MUST be present in the 5172 message. 5174 10.1 Base Protocol Command AVP Table 5176 The table in this section is limited to the non-accounting Command 5177 Codes defined in this specification. 5179 +-----------------------------------------------+ 5180 | Command-Code | 5181 |---+---+---+---+---+---+---+---+---+---+---+---+ 5182 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| 5183 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5184 Accounting-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5185 Interval | | | | | | | | | | | | | 5186 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5187 Required | | | | | | | | | | | | | 5188 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5189 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5190 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5191 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5192 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5193 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5194 Lifetime | | | | | | | | | | | | | 5195 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ | 5196 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 | 5197 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5198 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5199 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| 5200 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5201 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ | 5202 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5203 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5204 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5205 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5206 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5207 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| 5208 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5209 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ | 5210 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ | 5211 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5212 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5213 Time | | | | | | | | | | | | | 5214 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 | 5215 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 | 5216 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 | 5217 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5218 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | 5219 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5220 Failover | | | | | | | | | | | | | 5221 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5222 Supported-Vendor-Id |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5223 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 | 5224 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 | 5225 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5226 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5227 Application-Id | | | | | | | | | | | | | 5228 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5230 10.2 Accounting AVP Table 5232 The table in this section is used to represent which AVPs defined in 5233 this document are to be present in the Accounting messages. 5234 +-----------+ 5235 | Command | 5236 | Code | 5237 |-----+-----+ 5238 Attribute Name | ACR | ACA | 5239 ------------------------------|-----+-----+ 5240 Accounting-Interim-Interval | 0-1 | 0-1 | 5241 Accounting-Multi-Session-Id | 0-1 | 0-1 | 5242 Accounting-Record-Number | 1 | 1 | 5243 Accounting-Record-Type | 1 | 1 | 5244 Accounting-RADIUS-Session-Id | 0-1 | 0-1 | 5245 Accounting-Sub-Session-Id | 0-1 | 0-1 | 5246 Accounting-Realtime-Required | 0 | 0-1 | 5247 Acct-Application-Id | 1 | 1 | 5248 Class | 0+ | 0+ | 5249 Destination-Host | 0-1 | 0 | 5250 Destination-Realm | 1 | 0 | 5251 Error-Reporting-Host | 0 | 0+ | 5252 Origin-Host | 1 | 1 | 5253 Origin-Realm | 1 | 1 | 5254 Proxy-Info | 0+ | 0+ | 5255 Route-Record | 0+ | 0+ | 5256 Result-Code | 0 | 1 | 5257 Session-Id | 1 | 1 | 5258 User-Name | 0+ | 0+ | 5259 ------------------------------|-----+-----+ 5261 11.0 IANA Considerations 5263 This document defines a number of assigned numbers to be maintained 5264 by the IANA. This section explains the criteria to be used by the 5265 IANA to assign additional numbers in each of these lists. The 5266 following subsections describe the assignment policy for the 5267 namespaces defined elsewhere in this document. 5269 11.1 AVP 5271 As defined in section 4.0, the AVP header contains two fields that 5272 requires IANA namespace management; the AVP Code and Flags field. 5274 11.1.1 AVP Code 5276 The AVP Code namespace is used to identify attributes. When the 5277 Vendor ID value is set to zero (0), IANA will maintain a registry of 5278 assigned AVP codes and in some cases also their values. AVP Codes 5279 0-254 are managed separately as RADIUS Attribute Types [RAD TYPE], 5280 while the remaining namespace is available for assignment via 5281 Specification Required [IANA]. 5283 Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP 5284 header is set to a non-zero value, are for Private Use. 5286 This document defines the AVP Codes 257-274, 276-285, 287, 291-297, 5287 480, 482 and 485-486. See section 4.6 for the assignment of the 5288 namespace in this specification. 5290 11.1.2 AVP Flags 5292 There are 8 bits in the AVP Flags field of the AVP header, defined in 5293 section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7 5294 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only 5295 be assigned via a Standards Action [IANA]. 5297 11.2 Diameter Header 5299 As defined in section 3.0, the Diameter header contains two fields 5300 that require IANA namespace management; Command Code and Command 5301 Flags. 5303 11.2.1 Command Codes 5305 The Command Code namespace is used to identify Diameter commands. The 5306 values 0-255 are reserved for RADIUS backward compatibility, and are 5307 defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining 5308 values are available via Standards Action [IANA]. 5310 Vendor-Specific Command Codes, where the Vendor-Id field in the 5311 Diameter header is set to a non-zero value, are for Private Use. 5313 This document defines the Command Codes 257, 258, 271, 274-275, 280 5314 and 282. See section 3.1 for the assignment of the namespace in this 5315 specification. 5317 11.2.2 Command Flags 5319 There are eight bits in the Command Flags field of the Diameter 5320 header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and 5321 bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a 5322 Standards Action [IANA]. 5324 11.3 Application Identifiers 5326 As defined in section 2.5, the Application Identifier is used to 5327 identify a specific Diameter Application. All values except zero (0) 5328 are available for assignment via Standards Action [IANA]. 5330 Vendor-Specific Application Identifiers, encoded in the Vendor- 5331 Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to 5332 the vendor's enterprise number, is for Private Use. 5334 Note that the Diameter protocol is not intended to be extended for 5335 any purpose. Any applications defined MUST ensure that they fit 5336 within the existing framework, and that no changes to the base 5337 protocol are required. 5339 11.4 Result-Code AVP Values 5341 As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines 5342 the values 1001, 2001-2002, 3001-3009, 4001-4002 and 5001-5017. 5344 All remaining values are available for assignment via IETF Consensus 5345 [IANA]. 5347 11.5 Accounting-Record-Type AVP Values 5349 As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 5350 480) defines the values 1-4. All remaining values are available for 5351 assignment via IETF Consensus [IANA]. 5353 11.6 Termination-Cause AVP Values 5355 As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) 5356 defines the values 1-8. All remaining values are available for 5357 assignment via IETF Consensus [IANA]. 5359 11.7 Redirect-Host-Usage AVP Values 5360 As defined in Section 6.12, the Redirect-Host-Usage AVP (AVP Code 5361 261) defines the values 0-5. All remaining values are available for 5362 assignment via IETF Consensus [IANA]. 5364 11.8 Session-Server-Failover AVP Values 5366 As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 5367 271) defines the values 0-3. All remaining values are available for 5368 assignment via IETF Consensus [IANA]. 5370 11.9 Session-Binding AVP Values 5372 As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) 5373 defines the bits 1-4. All remaining bits are available for assignment 5374 via IETF Consensus [IANA]. 5376 11.10 Diameter TCP/SCTP Port Numbers 5378 An IANA request has been placed for TCP and SCTP port numbers. The 5379 IANA has informed the authors that "TBD" should be used in section 5380 2.1 and throughout this document, and will be updated by the RFC 5381 editor during the RFC publication process. 5383 IANA should also replace "TBD" in sections 4.4 and 5.2 with the port 5384 number assigned in section 2.1. 5386 11.11 Disconnect-Cause AVP Values 5388 As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) 5389 defines the values 0-2. All remaining values are available for 5390 assignment via IETF Consensus [IANA]. 5392 11.12 Auth-Request-Type AVP Values 5394 As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) 5395 defines the values 1-3. All remaining values are available for 5396 assignment via IETF Consensus [TCP]. 5398 11.13 Auth-Session-State AVP Values 5400 As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) 5401 defines the values 0-1. All remaining values are available for 5402 assignment via IETF Consensus [TCP]. 5404 11.14 Re-Auth-Request-Type AVP Values 5406 As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 5407 285) defines the values 0-1. All remaining values are available for 5408 assignment via IETF Consensus [TCP]. 5410 11.15 NAPTR Service Fields 5412 The registration in the RFC MUST include the following information: 5414 Service Field: The service field being registered. An example for a 5415 new fictitious transport protocol called NCTP might be "AAA+D2N". 5417 Protocol: The specific transport protocol associated with that 5418 service field. This MUST include the name and acronym for the 5419 protocol, along with reference to a document that describes the 5420 transport protocol. For example - "New Connectionless Transport 5421 Protocol (NCTP), RFC 5766". 5423 Name and Contact Information: The name, address, email address and 5424 telephone number for the person performing the registration. 5426 The following values are to be placed into the registry: 5428 Services Field Protocol AAA+D2T 5429 TCP AAAS+D2T TLS over TCP AAA+D2S 5430 SCTP AAAS+D2S TLS over SCTP 5432 12.0 Diameter protocol related configurable parameters 5434 This section contains the configurable parameters that are found 5435 throughout this document: 5437 Diameter Peer 5438 A Diameter entity MAY communicate with peers that are 5439 statically configured. A statically configured Diameter peer 5440 would require that either the IP address or the fully qualified 5441 domain name (FQDN) be supplied, which would then be used to 5442 resolve through DNS. 5444 Realm Routing Table 5445 A Diameter Proxy server routes messages based on the realm 5446 portion of a Network Access Identifier (NAI). The server MUST 5447 have a table of Realms Names, and the address of the peer to 5448 which the message must be forwarded to. The routing table MAY 5449 also include a "default route", which is typically used for all 5450 messages that cannot be locally processed. 5452 Tc timer 5453 The Tc timer controls the frequency that transport connection 5454 attempts are done to a peer with whom no active transport 5455 connection exists. The recommended value is 30 seconds. 5457 13.0 Security Considerations 5459 The Diameter base protocol assumes that messages are secured by using 5460 either IP Security, or TLS. This security model is acceptable in 5461 environments where there is no untrusted third party relay, proxy, or 5462 redirect agent. 5464 When third party brokers or redirect agents are used, strong 5465 application level security SHOULD be required, such as non- 5466 repudiation. When the communicating peers do require this level of 5467 security either for legal or business purposes, the Diameter 5468 application defined in [CMS] MAY be used. This security model 5469 provides AVP-level authentication, and the encryption mechanism is 5470 designed such that only the target host has the keying information 5471 required to decrypt the information. 5473 13.1 IPsec Usage 5475 All Diameter implementations MUST support IPsec ESP [IPsec] in 5476 transport mode with with non-null encryption and authentication 5477 algorithms to provide per-packet authentication, integrity protection 5478 and confidentiality, and MUST support the replay protection 5479 mechanisms of IPsec. 5481 Diameter implementations MUST support IKE for peer authentication, 5482 negotiation of security associations, and key management, using the 5483 IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer 5484 authentication using a pre-shared key, and MAY support certificate- 5485 based peer authentication using digital signatures. Peer 5486 authentication using the public key encryption methods outlined in 5487 IKE's sections 5.2 and 5.3 [IKE] SHOULD NOT be used. 5489 Conformant implementations MUST support both IKE Main Mode and 5490 Aggressive Mode. When pre-shared keys are used for authentication, 5491 IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be 5492 used. When digital signatures are used for authentication, either IKE 5493 Main Mode or IKE Aggressive Mode MAY be used. 5495 When digital signatures are used to achieve authentication, an IKE 5496 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 5497 the certificate authority (or authorities) that are trusted in 5498 accordance with its local policy. IKE negotiators SHOULD use 5499 pertinent certificate revocation checks before accepting a PKI 5500 certificate for use in IKE's authentication procedures. 5502 The Phase 2 Quick Mode exchanges used to negotiate protection for 5503 Diameter connections MUST explicitly carry the Identity Payload 5504 fields (IDci and IDcr). The DOI provides for several types of 5505 identification data. However, when used in conformant 5506 implementations, each ID Payload MUST carry a single IP address and a 5507 single non-zero port number, and MUST NOT use the IP Subnet or IP 5508 Address Range formats. This allows the Phase 2 security association 5509 to correspond to specific TCP and SCTP connections. 5511 Since IPsec acceleration hardware may only be able to handle a 5512 limited number of active IKE Phase 2 SAs, Phase 2 delete messages may 5513 be sent for idle SAs, as a means of keeping the number of active 5514 Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 5515 message SHOULD NOT be interpreted as a reason for tearing down a 5516 Diameter connection. Rather, it is preferable to leave the connection 5517 up, and if additional traffic is sent on it, to bring up another IKE 5518 Phase 2 SA to protect it. This avoids the potential for continually 5519 bringing connections up and down. 5521 13.2 TLS Usage 5523 A Diameter node that initiates a connection to another Diameter node 5524 acts as a TLS client according to [TLS], and a Diameter node that 5525 accepts a connection acts as a TLS server. Diameter nodes 5526 implementing TLS for security MUST mutually authenticate as part of 5527 TLS session establishment. In order to ensure mutual authentication, 5528 the Diameter node acting as TLS server must request a certificate 5529 from the Diameter node acting as TLS client, and the Diameter node 5530 acting as TLS client MUST be prepared to supply a certificate on 5531 request. 5533 When Diameter uses TLS, it MUST have the same dNSName field 5534 requirements as the Diameter CMS Security Application [CMS] listed in 5535 section 3.2. 5537 Diameter nodes MUST be able to negotiate the following TLS cipher 5538 suites: 5540 TLS_RSA_WITH_RC4_128_MD5 5541 TLS_RSA_WITH_RC4_128_SHA 5542 TLS_RSA_WITH_3DES_EDE_CBC_SHA 5544 Diameter nodes MAY negotiate other TLS cipher suites. 5546 14.0 References 5548 14.1 Normative 5550 [AAATRANS] B. Aboba, J. Wood, "Authentication, Authorization and 5551 Accounting (AAA) Transport Profile", draft-ietf-aaa- 5552 transport-04.txt, IETF Work in Progress, June 2001. 5554 [ASSIGNNO] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 5555 1994. 5557 [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 5558 application", draft-ietf-aaa-diameter-cms-sec-03.txt, 5559 IETF work in progress, November 2001. 5561 [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 5562 the Differentiated Services Field (DS Field) in the IPv4 5563 and IPv6 Headers," RFC 2474, December 1998. 5565 [DIFFSERVAF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured 5566 Forwarding PHB Group," RFC 2597, June 1999. 5568 [DIFFSERVEF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited For� 5569 warding PHB", RFC 2598, June 1999. 5571 [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for speci� 5572 fying the location of services (DNS SRV)", RFC 2782, 5573 February 2000. 5575 [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authenti� 5576 cation Protocol (EAP)." RFC 2284, March 1998. 5578 [FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE 5579 Standard for Binary Floating-Point Arithmetic", ANSI/IEEE 5580 Standard 754-1985, August 1985. 5582 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Con� 5583 siderations Section in RFCs", BCP 26, RFC 2434, October 5584 1998 5586 [IANAWEB] IANA, "Number assignment", http://www.iana.org 5588 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 5589 RFC 2409, November 1998. 5591 [IPSECDOI] D. Piper, "The Internet IP Security Domain of Interpreta� 5592 tion for ISAKMP", RFC 2407, November 1998. 5594 [IPV4] ISI, "Internet Protocol", RFC 791, September 1981. 5596 [IPV6] Hinden, Deering, "IP Version 6 Addressing Architecture", 5597 RFC 2373, July 1998. 5599 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 5600 Requirement Levels", BCP 14, RFC 2119, March 1997. 5602 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. 5603 January 1999. 5605 [NAPTR] M. Mealling and R. Daniel, "The naming authority pointer 5606 (NAPTR) DNS resource record," Request for Comments 2915, 5607 Internet Engineering Task Force, Sept. 2000. 5609 [RADTYPE] IANA, "RADIUS Types", http://www.isi.edu/in- 5610 notes/iana/assignments/radius-types 5612 [SCTP] R. Stewart et al., "Stream Control Transmission Proto� 5613 col". RFC 2960. October 2000. 5615 [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service 5616 Location Protocol, Version 2", RFC 2165, June 1999. 5618 [SNTP] Mills, "Simple Network Time Protocol (SNTP) Version 4 for 5619 IPv4, IPv6 and OSI, RFC 2030, October 1996. 5621 [TCP] Postel, J. "Transmission Control Protocol", RFC 793, Jan� 5622 uary 1981. 5624 [TEMPLATE] E. Guttman, C. Perkins, J. Kempf, "Service Templates and 5625 Service: Schemes", RFC 2609, June 1999. 5627 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 5628 2246, January 1999. 5630 [TLSSCTP] M. Tuexen, et al. "TLS over SCTP" IETF Work in Progress, 5631 November 2001. 5633 [URI] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, 5634 "Uniform Resource Identifiers (URI): Generic Syntax". RFC 5635 2396, August 1998. 5637 [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 5638 10646", RFC 2279, January 1998. 5640 14.2 Non-Normative 5641 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Speci� 5642 fications: ABNF", RFC 2234, November 1997. 5644 [ACCMGMT] B. Aboba, J. Arkko, D. Harrington. "Introduction to 5645 Accounting Management", RFC 2975, October 2000. 5647 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 5648 for AAA", RFC 3141, June 2001. 5650 [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 5651 draft-ietf-aaa-diameter-mobileip-08.txt, IETF work in 5652 progress, November 2001. 5654 [IPComp] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Pay� 5655 load Compression Protocol (IPComp)", RFC 2393, December 5656 1998. 5658 [MIPV4] C. Perkins, Editor. IP Mobility Support. RFC 2002, 5659 October 1996. 5661 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica� 5662 tion, Authorization, and Accounting Requirements". RFC 5663 2977. October 2000. 5665 [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NAS� 5666 REQ Application", draft-ietf-aaa-diameter-nasreq-08.txt, 5667 IETF work in progress, November 2001. 5669 [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network 5670 Access Server Protocols", RFC 3169, September 2001. 5672 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 5673 1661, STD 51, July 1994. 5675 [PROXYCHAIN] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy 5676 Implementation in Roaming", RFC 2607, June 1999. 5678 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 5679 Authentication Dial In User Service (RADIUS)", RFC 2865, 5680 June 2000. 5682 [ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro� 5683 tocols", RFC 2477, January 1999. 5685 [SECARCH] S. Kent, R. Atkinson, "Security Architecture for the 5686 Internet Protocol", RFC 2401, November 1998. 5688 15.0 Acknowledgements 5689 The authors would like to thank Nenad Trifunovic, Tony Johansson and 5690 Pankaj Patel for their participation in the pre-IETF Document Reading 5691 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided 5692 invaluable assistance in working out transport issues, and similarly 5693 with Steven Bellovin in the security area. 5695 Paul Funk and David Mitton were instrumental in getting the Peer 5696 State Machine correct, and our deep thanks go to them for their time. 5697 Text in this document was also provided by Paul Funk, Mark Eklund, 5698 Mark Jones and Dave Spence. Jacques Caron provided many great com� 5699 ments as a result of a thorough review of the spec. 5701 The authors would also like to acknowledge the following people for 5702 their contribution in the development of the Diameter protocol: 5704 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, 5705 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy 5706 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, 5707 Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth 5708 Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and Jeff 5709 Weisberg 5711 Finally, Pat Calhoun would like to thank Sun Microsystems since most 5712 of the effort put into this document was done while he was in their 5713 employ. 5715 16.0 Authors' Addresses 5717 Questions about this memo can be directed to: 5719 Pat R. Calhoun 5720 Black Storm Networks 5721 250 Cambridge Avenue, Suite 200 5722 Palo Alto, California, 94306 5723 USA 5725 Phone: +1 650-617-2932 5726 Fax: +1 650-786-6445 5727 E-mail: pcalhoun@diameter.org 5728 Jari Arkko 5729 Oy LM Ericsson Ab 5730 02420 Jorvas 5731 Finland 5733 Phone: +358 40 5079256 5734 E-Mail: Jari.Arkko@ericsson.com 5736 Erik Guttman 5737 Solaris Advanced Development 5738 Sun Microsystems, Inc. 5739 Eichhoelzelstr. 7 5740 74915 Waibstadt 5741 Germany 5743 Phone: +49-7263-911-701 5744 E-mail: erik.guttman@germany.sun.com 5746 Glen Zorn 5747 Cisco Systems, Inc. 5748 500 108th Avenue N.E., Suite 500 5749 Bellevue, WA 98004 5750 USA 5752 Phone: +1 425 438 8218 5754 John Loughney 5755 Nokia Research Center 5756 It�merenkatu 11-13 5757 00180 Helsinki 5758 Finland 5760 Phone: +358 50 483 6242 5761 E-mail: john.Loughney@nokia.com 5763 17.0 Full Copyright Statement 5765 Copyright (C) The Internet Society (2001). All Rights Reserved. 5767 This document and translations of it may be copied and furnished to 5768 others, and derivative works that comment on or otherwise explain it 5769 or assist in its implementation may be prepared, copied, published 5770 and distributed, in whole or in part, without restriction of any 5771 kind, provided that the above copyright notice and this paragraph are 5772 included on all such copies and derivative works. However, this docu� 5773 ment itself may not be modified in any way, such as by removing the 5774 copyright notice or references to the Internet Society or other 5775 Internet organizations, except as needed for the purpose of develop� 5776 ing Internet standards in which case the procedures for copyrights 5777 defined in the Internet Standards process must be followed, or as 5778 required to translate it into languages other than English. The lim� 5779 ited permissions granted above are perpetual and will not be revoked 5780 by the Internet Society or its successors or assigns. This document 5781 and the information contained herein is provided on an "AS IS" basis 5782 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 5783 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 5784 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 5785 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 5786 FITNESS FOR A PARTICULAR PURPOSE. 5788 18.0 Expiration Date 5790 This memo is filed as and expires in 5791 September 2002. 5793 Appendix A. Diameter Service Template 5795 The following service template describes the attributes used by Diam� 5796 eter servers to advertise themselves. This simplifies the process of 5797 selecting an appropriate server to communicate with. A Diameter 5798 client can request specific Diameter servers based on characteristics 5799 of the Diameter service desired (for example, an AAA server to use 5800 for accounting.) 5802 Name of submitter: "Erik Guttman" 5803 Language of service template: en 5805 Security Considerations: 5806 Diameter clients and servers use various cryptographic mechanisms 5807 to protect communication integrity, confidentiality as well as 5808 perform end-point authentication. It would thus be difficult if 5809 not impossible for an attacker to advertise itself using SLPv2 and 5810 pose as a legitimate Diameter peer without proper preconfigured 5811 secrets or cryptographic keys. Still, as Diameter services are 5812 vital for network operation it is important to use SLPv2 authenti� 5813 cation to prevent an attacker from modifying or eliminating ser� 5814 vice advertisements for legitimate Diameter servers. 5816 Template text: 5817 -------------------------template begins here----------------------- 5818 template-type=service:diameter 5820 template-version=0.0 5822 template-description= 5823 The Diameter protocol is defined by draft-ietf-aaa-diameter-10.txt 5825 template-url-syntax= 5826 url-path= ; The Diameter URL format is described in section 2.9. 5827 ; Example: 'aaa://aaa.abc.com:1812;transport=tcp 5829 supported-auth-applications= string L M 5830 # This attribute lists the Diameter applications supported by the 5831 # AAA implementation. The applications currently defined are: 5832 # Application Name Defined by 5833 # ---------------- ----------------------------------- 5834 # NASREQ draft-ietf-aaa-diameter-nasreq-08.txt 5835 # MobileIP draft-ietf-aaa-diameter-mobileip-08.txt 5836 # CMS Security draft-ietf-aaa-diameter-cms-sec-03.txt 5837 # 5838 # Notes: 5839 # . Diameter implementations support one or more applications. 5840 # . Additional applications may be defined in the future. 5841 # An updated service template will be created at that time. 5842 # 5843 NASREQ,MobileIP,CMS Security 5845 supported-acct-applications= string L M 5846 # This attribute lists the Diameter applications supported by the 5847 # AAA implementation. The applications currently defined are: 5848 # Application Name Defined by 5849 # ---------------- ----------------------------------- 5850 # NASREQ draft-ietf-aaa-diameter-nasreq-08.txt 5851 # MobileIP draft-ietf-aaa-diameter-mobileip-08.txt 5852 # CMS Security draft-ietf-aaa-diameter-cms-sec-03.txt 5853 # 5854 # Notes: 5855 # . Diameter implementations support one or more applications. 5856 # . Additional applications may be defined in the future. 5857 # An updated service template will be created at that time. 5858 # 5859 NASREQ,MobileIP,CMS Security 5861 supported-transports= string L M 5862 SCTP 5863 # This attribute lists the supported transports that the Diameter 5864 # implementation accepts. Note that a compliant Diameter 5865 # implementation MUST support SCTP, though it MAY support other 5866 # transports, too. 5867 SCTP,TCP 5869 -------------------------template ends here----------------------- 5871 Appendix B. NAPTR Example 5873 As an example, consider a client that wishes to resolve aaa:ex.com. 5874 The client performs a NAPTR query for that domain, and the following 5875 NAPTR records are returned: 5877 ;; order pref flags service regexp replacement 5878 IN NAPTR 20 50 "s" "AAAS+D2S" "" _diame� 5879 ters._sctp.ex.com. IN NAPTR 50 50 "s" "AAA+D2S" "" 5880 _diameter._sctp.ex.com. IN NAPTR 90 50 "s" "AAAS+D2T" 5881 "" _diameters._tcp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T" 5882 "" _aaa._tcp.ex.com 5884 This indicates that the server supports TLS over SCTP, SCTP, TLS over 5885 TCP, and TCP, in that order. If the client supports TLS over SCTP, 5886 SCTP will be used, targeted to a host determined by an SRV lookup of 5887 _diameters._sctp.ex.com. That lookup would return: 5889 ;; Priority Weight Port Target 5890 IN SRV 0 1 5060 server1.ex.com IN SRV 0 2 5891 5060 server2.ex.com 5893 Appendix C. Duplicate Detection 5895 As described in section 9.4, accounting record duplicate detection is 5896 based on the session identifiers. Duplicates can appear for various 5897 reasons: 5899 - Failover to an alternate server. Where we close to real-time 5900 performance is expected, failover tresholds need to be kept low 5901 and this may lead to a relatively large likelihood of duplicates. 5903 - A crash of a client at the time it just had managed to send a 5904 record from a non-volatile memory would likely cause the same 5905 record to be sent soon after the client has rebooted. 5907 - Duplicates received from RADIUS gateways. 5909 - Implementation problems and misconfiguration. 5911 In some cases the Diameter accounting server can delay the duplicate 5912 detection and accounting record processing until a post-processing 5913 phase takes place. At that time records are likely to be sorted 5914 according to the User-Name contained in them and duplicate elimina� 5915 tion is easy in this case. 5917 In other situations it may be necessary to perform real-time dupli� 5918 cate detection, e.g. when the credit limits or fraud attempts are 5919 being monitored in real time. 5921 In general, only the duplicate generation at failover case is some� 5922 thing that can be reliably detected by the Diameter client. The 5923 Diameter server is therefore responsible for the duplicate detection 5924 process. When real-time duplicate detection is required, this implies 5925 a database-like search functionality to find duplicate records. 5926 Implementors are advised, however, that there exists ways to avoid 5927 expensive all-record searches. For instance, it can be usually 5928 safely assumed that duplicates appear within a time window of longest 5929 imaginable network partition, perhaps a day as an example. So only 5930 records within this time window need to be looked at. Secondly, hash� 5931 ing techniques or other schemes may be used to eliminate the need to 5932 do a full search even in this set except for rare cases.