idnits 2.17.1 draft-ietf-aaa-diameter-10.txt: 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 is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 138 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 139 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 91 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 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 296 has weird spacing: '...ing for simpl...' == Line 1481 has weird spacing: '... answer messa...' == Line 2900 has weird spacing: '...onn-Ack an a...' == Line 3950 has weird spacing: '...ly with wit...' == Line 4156 has weird spacing: '...ealtime user...' == (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 (April 2002) is 8019 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 5962, but not defined == Missing Reference: 'ROAMCRIT' is mentioned on line 5972, but not defined == Missing Reference: 'ROAMREV' is mentioned on line 269, but not defined == Missing Reference: 'PROXYCHAIN' is mentioned on line 5965, but not defined == Missing Reference: 'CDMA2000REQ' is mentioned on line 350, but not defined == Missing Reference: 'MIPREQ' is mentioned on line 5952, but not defined == Missing Reference: 'MIPV4' is mentioned on line 5949, but not defined == Missing Reference: 'NASCRIT' is mentioned on line 5959, but not defined == Missing Reference: 'DIAMMIP' is mentioned on line 5942, but not defined == Missing Reference: 'RADIUS' is mentioned on line 5968, but not defined == Missing Reference: 'NASREQ' is mentioned on line 5956, but not defined == Missing Reference: 'CMS' is mentioned on line 5939, but not defined -- Looks like a reference, but probably isn't: '47' on line 446 == Missing Reference: 'ABNF' is mentioned on line 5930, but not defined == Missing Reference: 'SEC ARCH' is mentioned on line 839, but not defined == Missing Reference: 'UFT8' is mentioned on line 1696, but not defined == Missing Reference: 'ASSIGN NO' is mentioned on line 2532, but not defined == Missing Reference: 'PXY' is mentioned on line 3745, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 5933, but not defined == Missing Reference: 'IPComp' is mentioned on line 5945, but not defined == Missing Reference: 'IPsec' is mentioned on line 5692, but not defined == Missing Reference: 'CDMA2000' is mentioned on line 5936, but not defined == Missing Reference: 'SECARCH' is mentioned on line 5975, but not defined == Unused Reference: 'DIFFSERVAF' is defined on line 5852, but no explicit reference was found in the text == Unused Reference: 'DIFFSERVEF' is defined on line 5855, but no explicit reference was found in the text == Unused Reference: 'DNSSRV' is defined on line 5858, but no explicit reference was found in the text == Unused Reference: 'IANAWEB' is defined on line 5873, but no explicit reference was found in the text == Unused Reference: 'TLSSCTP' is defined on line 5918, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 5925, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AAATRANS' ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNNO') (Obsoleted by RFC 3232) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NAPTR' -- 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: 16 errors (**), 0 flaws (~~), 42 warnings (==), 11 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 Ericsson 6 Erik Guttman 7 Sun Microsystems, Inc. 8 Glen Zorn 9 Cisco Systems, Inc. 10 John Loughney 11 Nokia 12 April 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 applications such as network access or IP mobility. Diameter is 45 also intended to work both with local AAA and with roaming 46 situations. This draft specifies the message format, transport, error 47 reporting, accounting and security services to be used by all 48 Diameter applications and MUST be supported by all Diameter 49 implementations. 51 Table of Contents 53 1 Introduction 54 1.1 Diameter Protocol 55 1.1.1 Differences from RADIUS 56 1.1.2 Description of the Document Set 57 1.2 Approach to Extensibility 58 1.2.1 Defining New AVP Values 59 1.2.2 Creating New AVPs 60 1.2.3 Creating New Authentication Applications 61 1.2.4 Creating New Accounting Applications 62 1.2.5 Application Authentication Procedures 63 1.3 Requirements Language 64 1.4 Terminology 66 2 Protocol Overview 67 2.1 Transport 68 2.1.1 SCTP Guidelines 69 2.2 Securing Diameter Messages 70 2.3 Diameter Application Compliance 71 2.4 Application Identifiers 72 2.5 Connections vs. Sessions 73 2.6 Peer Table 74 2.7 Realm-Based Routing Table 75 2.8 Role of Diameter Agents 76 2.8.1 Relay Agents 77 2.8.2 Proxy Agents 78 2.8.3 Redirect Agents 79 2.8.4 Translation Agents 81 3 Diameter Header 82 3.1 Command Codes 83 3.2 Command Code ABNF specification 84 3.3 Diameter Command Naming Conventions 86 4 Diameter AVPs 87 4.1 AVP Header 88 4.2 Optional Header Elements 89 4.3 Basic AVP Data Formats 90 4.4 Derived AVP Data Formats 91 4.5 Grouped AVP Values 92 4.5.1 Example AVP with a Grouped Data type 93 4.6 Diameter Base Protocol AVPs 95 5 Diameter Peers 96 5.1 Peer Connections 97 5.2 Diameter Peer Discovery 98 5.3 Capabilities Exchange 99 5.3.1 Capabilities-Exchange-Request 100 5.3.2 Capabilities-Exchange-Answer 101 5.3.3 Vendor-Id AVP 102 5.3.4 Firmware-Revision AVP 103 5.3.5 Host-IP-Address AVP 104 5.3.6 Supported-Vendor-Id AVP 105 5.3.7 Product-Name AVP 106 5.4 Disconnecting Peer connections 107 5.4.1 Disconnect-Peer-Request 108 5.4.2 Disconnect-Peer-Answer 109 5.4.3 Disconnect-Cause AVP 110 5.5 Transport Failure Detection 111 5.5.1 Device-Watchdog-Request 112 5.5.2 Device-Watchdog-Answer 113 5.5.3 Transport Failure Algorithm 114 5.5.4 Failover and Failback Procedures 115 5.6 Peer State Machine 116 5.6.1 Incoming connections 117 5.6.2 Events 118 5.6.3 Actions 119 5.6.4 The Election Process 121 6 Diameter message processing 122 6.1 Diameter request routing overview 123 6.1.1 Originating a Request 124 6.1.2 Sending a Request 125 6.1.3 Receiving Requests 126 6.1.4 Processing Local Requests 127 6.1.5 Request Forwarding 128 6.1.6 Request Routing 129 6.1.7 Redirecting requests 130 6.1.8 Relaying and Proxying Requests 131 6.2 Diameter Answer Processing 132 6.2.1 Processing received Answers 133 6.2.2 Relaying and Proxying Answers 134 6.3 Origin-Host AVP 135 6.4 Origin-Realm AVP 136 6.5 Destination-Host AVP 137 6.6 Destination-Realm AVP 138 6.7 Routing AVPs 139 6.7.1 Route-Record AVP 140 6.7.2 Proxy-Info AVP 141 6.7.3 Proxy-Host AVP 142 6.7.4 Proxy-State AVP 143 6.8 Auth-Application-Id AVP 144 6.9 Acct-Application-Id AVP 145 6.10 Vendor-Specific-Application-Id AVP 146 6.11 Redirect-Host AVP 147 6.12 Redirect-Host-Usage AVP 148 6.13 Redirect-Max-Cache-Time AVP 150 7 Error Handling 151 7.1 Result-Code AVP 152 7.1.1 Informational 153 7.1.2 Success 154 7.1.3 Protocol Errors 155 7.1.4 Transient Failures 156 7.1.5 Permanent Failures 157 7.2 Error Bit 158 7.3 Error-Message AVP 159 7.4 Error-Reporting-Host AVP 160 7.5 Failed-AVP AVP 162 8 Diameter User Sessions 163 8.1 Authorization Session State Machine 164 8.2 Accounting Session State Machine 165 8.3 Server-Initiated Re-Auth 166 8.3.1 Re-Auth-Request 167 8.3.2 Re-Auth-Answer 168 8.4 Session Termination 169 8.4.1 Session-Termination-Request 170 8.4.2 Session-Termination-Answer 171 8.5 Aborting a Session 172 8.5.1 Abort-Session-Request 173 8.5.2 Abort-Session-Answer 174 8.6 Inferring Session Termination from Origin-State-Id 175 8.7 Auth-Request-Type AVP 176 8.8 Session-Id AVP 177 8.9 Authorization-Lifetime AVP 178 8.10 Auth-Grace-Period AVP 179 8.11 Auth-Session-State AVP 180 8.12 Re-Auth-Request-Type AVP 181 8.13 Session-Timeout AVP 182 8.14 User-Name AVP 183 8.15 Termination-Cause AVP 184 8.16 Origin-State-Id AVP 185 8.17 Session-Binding AVP 186 8.18 Session-Server-Failover AVP 187 8.19 Multi-Round-Time-Out AVP 188 8.20 Class AVP 190 9 Accounting 191 9.1 Server Directed Model 192 9.2 Protocol Messages 193 9.3 Application document requirements 194 9.4 Fault Resilience 195 9.5 Accounting Records 196 9.6 Correlation of Accounting Records 197 9.7 Accounting Command-Codes 198 9.7.1 Accounting-Request 199 9.7.2 Accounting-Answer 200 9.8 Accounting AVPs 201 9.8.1 Accounting-Record-Type AVP 202 9.8.2 Accounting-Interim-Interval AVP 203 9.8.3 Accounting-Record-Number AVP 204 9.8.4 Accounting-RADIUS-Session-Id AVP 205 9.8.5 Accounting-Multi-Session-Id AVP 206 9.8.6 Accounting-Sub-Session-Id AVP 207 9.8.7 Accounting-Realtime-Required AVP 209 10 AVP Occurrence Table 210 10.1 Base Protocol Command AVP Table 211 10.2 Accounting AVP Table 213 11 IANA Considerations 214 11.1 AVP Header 215 11.1.1 AVP Code 216 11.1.2 AVP Flags 217 11.2 Diameter Header 218 11.2.1 Command Codes 219 11.2.2 Command Flags 220 11.3 Application Identifier Values 221 11.4 Result-Code AVP Values 222 11.5 Accounting-Record-Type AVP Values 223 11.6 Termination-Cause AVP Values 224 11.7 Redirect-Host-Usage AVP Values 225 11.8 Session-Server-Failover AVP Values 226 11.9 Session-Binding AVP Values 227 11.10 Diameter TCP/SCTP Port Numbers 228 11.11 Disconnect-Cause AVP Values 229 11.12 Auth-Request-Type AVP Values 230 11.13 Auth-Session-State AVP Values 231 11.14 Re-Auth-Request-Type AVP Values 232 11.15 NAPTR Service Fields 233 11.16 Accounting-Realtime-Required AVP Values 235 12 Diameter protocol related configurable parameters 237 13 Security Considerations 238 13.1 IPsec Usage 239 13.2 TLS Usage 240 13.3 Peer-to-Peer Considerations 242 14 References 243 14.1 Normative 244 14.2 Non-Normative 246 15 Acknowledgements 248 16 Authors' Addresses 250 17 Full Copyright Statement 252 18 Expiration Date 254 Appendix A. Diameter Service Template 256 Appendix B. NAPTR Example 258 Appendix C. Duplicate Detection 260 1 Introduction 262 Historically, the RADIUS protocol has been used to provide AAA 263 services for dial-up PPP [PPP] and terminal server access. Over time, 264 routers and network access servers (NAS) have increased in complexity 265 and density, making the RADIUS protocol increasingly unsuitable for 266 use in such networks. 268 The Roaming Operations Working Group (ROAMOPS) has published a set of 269 specifications [ROAMCRIT, ROAMREV, PROXYCHAIN] that define how a PPP 270 user can gain access to the Internet without having to dial into 271 his/her home service provider's modem pool. This is achieved by 272 allowing service providers to cross-authenticate their users. 273 Effectively, a user can dial into any service provider's point of 274 presence (POP) that has a roaming agreement with his/her home 275 Internet service provider (ISP), the benefit being that the user does 276 not have to incur a long distance charge while traveling, which can 277 sometimes be quite expensive. 279 Given the number of ISPs today, ROAMOPS realized that requiring each 280 ISP to set up roaming agreements with all other ISPs did not scale. 281 Therefore, the working group defined a "broker", which acts as an 282 intermediate server, whose sole purpose is to set up these roaming 283 agreements. A collection of ISPs and a broker is called a "roaming 284 consortium". There are many such brokers in existence today; many 285 also provide settlement services for member ISPs. 287 The Mobile-IP Working Group has recently changed its focus to inter- 288 administrative domain mobility, which is a requirement for cellular 289 carriers wishing to deploy IETF-based mobility protocols. The current 290 cellular carriers requirements [CDMA2000REQ, MIPREQ] are very similar 291 to the ROAMOPS model, with the exception that the access protocol is 292 Mobile-IP [MIPV4] instead of PPP. 294 The Network Access Server Requirements (NASREQ) working group has 295 focused on proving next generation Authentication, Authorization and 296 usage Accounting for simple dial-in access and beyond; such as 297 Virtual Private Network support, smart authentication methods, and 298 roaming concerns. The Working Group has published number of 299 documents the requirements for NAS user authorization as well as 300 criteria for evaluating NAS protocols [NASCRIT]. 302 The basic concept behind Diameter is to provide a base protocol that 303 can be extended in order to provide AAA services to new access 304 technologies. Currently, the protocol only concerns itself with 305 Internet access, both in the traditional PPP sense as well as taking 306 into account the ROAMOPS model, and Mobile-IP. 308 Although Diameter could be used to solve a wider set of AAA problems, 309 we are currently limiting the scope of the protocol in order to 310 ensure that the effort remains focused on satisfying the requirements 311 of network access. Note that a truly generic AAA protocol used by 312 many applications might provide functionality not provided by 313 Diameter. Therefore, it is imperative that the designers of new 314 applications understand their requirements before using Diameter. 316 1.1 Diameter Protocol 318 The Diameter protocol allows peers to exchange a variety of messages. 319 The base protocol provides the following facilities: 321 - Delivery of AVPs (attribute value pairs) 322 - Capabilities negotiation, as required in [ROAMCRIT] 323 - Error notification 324 - Extensibility, through addition of new commands and AVPs, as 325 required in [NASCRIT] 326 - Basic services necessary for applications, such as handling of 327 user sessions or accounting 329 All data delivered by the protocol is in the form of an AVP. Some of 330 these AVP values are used by the Diameter protocol itself, while 331 others deliver data associated with particular applications that 332 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 333 so long as the required AVPs are included and AVPs that are 334 explicitly excluded are not included. AVPs are used by the base 335 Diameter protocol to support the following required features: 337 - Transporting of user authentication information, for the 338 purposes of enabling the Diameter server to authenticate the 339 user. 340 - Transporting of service specific authorization information, 341 between client and servers, allowing the peers to decide whether 342 a user's access request should be granted. 343 - Exchanging resource usage information, which MAY be used for 344 accounting purposes, capacity planning, etc. 345 - Relaying, proxying and redirecting of Diameter messages through 346 a server hierarchy. 348 The Diameter base protocol provides the minimum requirements needed 349 for an AAA transport protocol, as required by NASREQ [NASCRIT], 350 Mobile IP [CDMA2000REQ, MIPREQ], and ROAMOPS [ROAMCRIT]. The base 351 protocol is not intended to be used by itself, and must be used with 352 a Diameter application, such as Mobile IP [DIAMMIP]. The Diameter 353 protocol was heavily inspired by and builds upon the tradition of the 354 RADIUS [RADIUS] protocol. See section 2.4 for more information on 355 Diameter applications. 357 Any node can initiate a request. In that sense, Diameter is a peer- 358 to-peer protocol. In this document, a Diameter client is an access 359 device that initiates a request for authentication and/or 360 authorization of a given user. A Diameter agent is a node that does 361 not authenticate and/or authorize messages locally. Examples of 362 agents are proxies and relay agents. A Diameter server is one that 363 performs authentication and/or authorization of the user based on 364 some profile. A Diameter node MAY act as an agent for certain 365 requests while acting as a server for others. 367 The Diameter protocol also supports server-initiated messages towards 368 access devices, such as a request to abort service to a particular 369 user. 371 1.1.1 Differences from RADIUS 373 The Diameter protocol was not designed from the ground up. Instead, 374 the basic RADIUS model was retained while fixing the flaws in the 375 RADIUS protocol itself. Diameter does not share a common protocol 376 data unit (PDU) with RADIUS, but does borrow sufficiently from the 377 protocol to ease migration. The major differences include: 379 - Peer-to-peer nature 380 - Explicit support for intermediaries 381 - Connection-oriented versus connectionless 382 - Extensibility [see section 1.2] 383 - Built-in failover support 384 - Larger attribute space 385 - Integrated accounting 386 - Bit to indicate mandatory status of data 387 - Application-layer ACKs and error messages 388 - Unsolicited server messages 389 - Peer discovery 390 - Capabilities negotiation 392 1.1.2 Description of the Document Set 394 Currently, the Diameter specification consists of a base 395 specification (this document), Transport Issues [AAATRANS] and a 396 number of applications: Mobile IPv4 [DIAMMIP], NASREQ [NASREQ] and 397 CMS Security [CMS]. 399 The Transport Issues document [AAATRANS] discusses transport layer 400 issues that arise with AAA protocols and recommendations on how to 401 overcome these issues. 403 The Mobile IPv4 [DIAMMIP] application defines a Diameter application 404 that allows a Diameter server to perform AAA functions for Mobile 405 IPv4 services to a mobile node. 407 The NASREQ [NASREQ] application defines a Diameter Application that 408 allows a Diameter server to be used in a PPP/SLIP Dial-Up and 409 Terminal Server Access environment. Consideration was given for 410 servers that need to perform protocol conversion between Diameter and 411 RADIUS. 413 The CMS Security [CMS] application defines how security associations 414 are established even through Diameter agents, and how authentication, 415 integrity, confidentialy, and data-origin authentication can be 416 achieved. It should be noted that the recommendations with regards 417 to CMS in this specicication are not normative. 419 In summary, this document defines the base protocol specification for 420 AAA. The MIPv4 and the NASREQ documents describe applications that 421 use this base specification to achieve Authentication, Authorization 422 and Accounting. The CMS Application describes a security application 423 for providing secure communication in the presence of relay and peer 424 agents. 426 1.2 Approach to Extensibility 428 The Diameter protocol is designed to be extensible. However, it is 429 strongly encouraged to reuse existing mechanism before attempting any 430 Diameter extensions. The extensibility includes: 432 - Defining new AVP values. 433 - Creating new AVPs 434 - Creating new authentication applications 435 - Creating new Accounting Applications 436 - Application Authentication Procedures 438 1.2.1 Defining New AVP Values 440 New applications should attempt to reuse AVPs defined in existing 441 application when possible, as opposed to creating a new AVP. For AVPs 442 of type Enumerated, it is possible the application requires a new 443 value to communicate some service-specific information. 445 In order to allocate a new AVP value, a request MUST be sent to IANA 446 [47], with a detailed explanation of the value. 448 1.2.2 Creating New AVPs 450 When no existing AVP can be used appropriately to communicate some 451 service-specific information, a new AVP should be created. The new 452 AVP being defined MUST follow one of the types listed in section 4.3. 453 In the event that a logical grouping of AVPs is necessary, and 454 multiple "groups" are possible in a given command, it is highly 455 recommended that a Grouped AVP be used (see Section 4.5). 457 In order to create a new AVP, a request MUST be sent to IANA, with a 458 detailed explanation of the AVP, its type and possible values. 459 Furthermore, the request MUST include the commands that would make 460 use of the AVP. 462 1.3.3 Creating New Authentication Applications 464 Should a new application require Diameter support, but it cannot fit 465 within an existing application without requiring major changes to the 466 specification, it may be desirable to create a new Diameter 467 application. Major changes to an application include: 469 - Requiring a whole different set of mandatory AVPs to a command 470 - Requiring a command that has a different number of round trips 471 to satisfy a request (e.g. application foo has a command that 472 requires one round trip, but new application bar has a command 473 that requires two round trips to complete). 474 - The method used to authenticate the user is drastically 475 different from any existing application, and the authentication 476 information cannot be carried within the AVPs defined in the 477 application. 479 Note that the creation of a new application should be viewed as a 480 last resort. 482 New Diameter applications MUST define at least one Command Code, the 483 expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY 484 also define new AVPs. If the Diameter application has any accounting 485 requirements, it MUST also specify the AVPs that are to be present in 486 the Diameter Accounting messages (see section 9.3). 488 When possible, a new Diameter application SHOULD attempt to re-use 489 any existing Diameter AVP, in order to reduce the possibility of 490 having multiple AVPs that carry similar information. 492 Every Diameter application specification MUST have an IANA assigned 493 Application Identifier (see section 2.4). 495 1.2.4 Creating New Accounting Applications 497 Services that have an Application Identifier MUST use the same 498 identifier also to identify the service when Diameter accounting is 499 used. 501 There are services that only require the use of Diameter accounting. 502 Such services need to define the service specific AVPs that must be 503 carried in the Accounting-Request/Answer messages, but do not need to 504 define command codes. Application Identifiers are, however, still 505 required for accounting due to the Diameter capability discovery 506 process. Every accounting application MUST have either an IANA 507 allocated Application Identifier, or a vendor specific Application 508 Identifier. 510 When possible, a new Diameter accounting application SHOULD attempt 511 to re-use any existing Diameter AVP, in order to reduce the 512 possibility of having multiple AVPs that carry similar information. 514 Every Diameter accounting application specification MUST have an IANA 515 assigned Application Identifier (see section 2.4). 517 1.2.5 Application Authentication Procedures 519 When possible, applications SHOULD be designed such that new 520 authentication methods MAY be added without requiring changes to the 521 application. This MAY require that new AVP values be assigned to 522 represent the new authentication transform, or any other scheme that 523 produces similar results. When possible, authentication frameworks, 524 such as Extensible Authentication Protocol [EAP], SHOULD be used. 526 1.3 Requirements Language 528 In this document, the key words "MAY", "MUST", "MUST NOT", 529 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 530 interpreted as described in [KEYWORDS]. 532 1.4 Terminology 534 AAA 535 Authentication, Authorization and Accounting. 537 Accounting 538 The act of collecting information on resource usage for the 539 purpose of trend analysis, auditing, billing or cost allocation. 541 Accounting record 542 A session record represents a summary of the resource consumption 543 of a user over the entire session. Accounting gateways creating 544 the session record may do so by processing interim accounting 545 events or accounting events from several devices serving the same 546 user. 548 Authentication 549 The act of verifying the identity of an entity (subject). 551 Authorization 552 The act of determining whether a requesting entity (subject) will 553 be allowed access to a resource (object). 555 AVP 556 The Diameter protocol consists of a header followed by one or more 557 Attribute-Value-Pairs (AVPs). The AVP includes a header and is 558 used to encapsulate protocol-specific data (e.g. routing 559 information) as well as authentication, authorization or 560 accounting information. 562 Broker 563 A broker is a business term commonly used in AAA infrastructures. 564 A broker is either a relay, proxy or redirect agent, and MAY be 565 operated by roaming consortiums. 567 Diameter Agent 568 A Diameter Agent is a host that provides either relay, proxy, 569 redirect or translation services. 571 Diameter Client 572 A Diameter Client is a device at the edge of the network that 573 performs access control. An example of a Diameter client is a 574 Network Access Server (NAS) or a Foreign Agent (FA). 576 Diameter Node 577 A Diameter node is a host that implements the Diameter protocol, 578 and acts either as a Client, Agent or Server. 580 Diameter Peer 581 A Diameter Peer is a Diameter Node to which a given Diameter Node 582 has a direct transport connection. 584 Diameter Server 585 A Diameter Server is one that handles authentication, 586 authorization and accounting requests for a particular realm. By 587 its very nature, a Diameter Server MUST support Diameter 588 applications in addition to the base protocol. 590 Downstream 591 Downstream is used to identify the direction of a particular 592 Diameter message from the home server towards the access device. 594 Home Realm 595 A Home Realm is the administrative domain with which the user 596 maintains an account relationship. 598 Home Server 599 See Diameter Server. 601 Interim accounting 602 An interim accounting message provides a snapshot of usage during 603 a user's session. It is typically implemented in order to provide 604 for partial accounting of a user's session in the event of a 605 device reboot or other network problem that prevents the reception 606 of a session summary message or session record. 608 Local Realm 609 A local realm is the administrative domain providing services to a 610 user. An administrative domain MAY act as a local realm for 611 certain users, while being a home realm for others. 613 Multi-session 614 A multi-session represents a logical linking of several sessions. 615 Multi-sessions are tracked by using the Acct-Multi-Session-Id. An 616 example of a multi-session would be a Multi-link PPP bundle. Each 617 leg of the bundle would be a session while the entire bundle would 618 be a multi-session. 620 Network Access Identifier 621 The Network Access Identifier, or NAI [NAI], is used in the 622 Diameter protocol to extract a user's identity and realm. The 623 identity is used to identify the user during authentication and/or 624 authorization, while the realm is used for message routing 625 purposes. 627 Proxy 628 In addition to forwarding requests and responses, proxies enforce 629 policies relating to resource usage and provisioning. This is 630 typically accomplished by tracking the state of NAS devices. While 631 proxies typically do not respond to client Requests prior to 632 receiving a Response from the server, they may originate Reject 633 messages in cases where policies are violated. As a result, 634 proxies need to understand the semantics of the messages passing 635 through them, and may not support all Diameter applications. 637 Realm 638 The string in the NAI that immediately follows the '@' character. 639 NAI realm names are required to be unique, and are piggybacked on 640 the administration of the DNS namespace. Diameter makes use of the 641 realm, also loosely referred to as domain, to determine whether 642 messages can be satisfied locally, or whether they must be routed 643 or redirected. 645 Real-time Accounting 646 Real-time accounting involves the processing of information on 647 resource usage within a defined time window. Time constraints are 648 typically imposed in order to limit financial risk. 650 Relay 651 Relays forward requests and responses based on routing-related 652 AVPs and realm routing table entries. Since relays do not enforce 653 policies, they do not examine or alter non-routing AVPs. As a 654 result, relays never originate messages, do not need to understand 655 the semantics of messages or non-routing AVPs, and are capable of 656 handling any Diameter application or message type. Since relays 657 make decisions based on information in routing AVPs and realm 658 forwarding tables they do not keep state on NAS resource usage or 659 conversations in progress. 661 Redirect Agent 662 Rather than forwarding requests and responses between clients and 663 servers, redirect agents refer clients to servers and allow them 664 to communicate directly. Since redirect agents do not sit in the 665 forwarding path, they do not alter any AVPs transiting between 666 client and server. Redirect agents do not originate messages and 667 are capable of handling any message type, although they may be 668 configured only to redirect messages of certain types, while 669 acting as Routing or Policy proxies for other types. As with 670 Routing proxies, redirect agents do not keep state with respect to 671 conversations or NAS resources. 673 Roaming Relationships 674 Roaming relationships include relationships between companies and 675 ISPs, relationships among peer ISPs within a roaming consortium, 676 and relationships between an ISP and a roaming consortia. 678 Session 679 A session is a related progression of events devoted to a 680 particular activity. Each application SHOULD provide guidelines as 681 to when a session begins and ends. All Diameter packets with the 682 same Session-Identifier are considered to be part of the same 683 session. 685 Sub-session 686 A sub-session represents a distinct service (e.g. QoS or data 687 characteristics) provided to a given session. These services may 688 happen concurrently (e.g. simultaneous voice and data transfer 689 during the same session) or serially. These changes in sessions 690 are tracked with the Accounting-Sub-Session-Id. An example of a 691 session divided into several sub-sessions would be a dial-up 692 connection in which the pre-authentication activity (call setup, 693 resource allocation, etc.), interactive login, and PPP 694 communication would all be sub-sessions. 696 Translation Agent 697 A translation agent is a stateful Diameter node that performs 698 protocol translation between Diameter and another AAA protocol. 700 Upstream 701 Upstream is used to identify the direction of a particular 702 Diameter message from the access device towards the home server. 704 2 Protocol Overview 706 The base Diameter protocol is never used on its own. It is always 707 extended for a particular application. Three Diameter applications 708 are defined by companion documents: NASREQ [NASREQ], Mobile IP 709 [DIAMMIP], CMS Security [CMS]. These applications are introduced in 710 this document but specified elsewhere. Additional Diameter 711 applications MAY be defined in the future (see Section 11.3). 713 Diameter Clients MUST support the base protocol, which includes 714 accounting. In addition, they MUST fully support each Diameter 715 application that is needed to implement the client's service, e.g. 716 NASREQ and/or Mobile IP. A Diameter Client that does not support both 717 NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" 718 where X is the application which it supports, and not a "Diameter 719 Client." 721 Diameter Servers MUST support the base protocol, which includes 722 accounting. In addition, they MUST fully support each Diameter 723 application that is needed to implement the intended service, e.g. 724 NASREQ and/or Mobile IP. A Diameter Server that does not support both 725 NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" 726 where X is the application which it supports, and not a "Diameter 727 Server." 729 Diameter Relays and Redirect agents are, by definition, protocol 730 transparent, and MUST transparently support the Diameter base 731 protocol, which includes accounting, and all Diameter applications. 733 Diameter Proxies MUST support the base protocol, which includes 734 accounting. In addition, they MUST fully support each Diameter 735 application that is needed to implement proxied services, e.g. NASREQ 736 and/or Mobile IP. A Diameter Proxy which does not support also both 737 NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" where 738 X is the application which it supports, and not a "Diameter Proxy." 740 The Diameter CMS security application [CMS] contains two features: 742 1. A set of messages that allows a Diameter node to establish a 743 security association, which is used to secure AVPs within a 744 Diameter message, even though the message may traverse 745 intermediate Diameter agents. A set of AVPs is also defined to 746 sign and encrypt AVPs, as well as to transport certificates. 747 This feature MUST be supported by Diameter server and proxy 748 agents, SHOULD be supported by Diameter clients, and MAY be 749 supported by relay and redirect agents. 750 2. A set of messages, known as PDSR and PDSA, allows a Diameter 751 client to request that an agent establish a Diameter security 752 association with a server in a specific realm. This feature 753 MUST be supported by Diameter clients and Proxy agents, and MAY 754 be supported by Diameter servers, relay and redirect agents. 756 The base Diameter protocol concerns itself with capabilities 757 negotiation, how messages are sent and how peers may eventually be 758 abandoned. The base protocol also defines certain rules that apply 759 to all exchanges of messages between Diameter nodes. 761 Communication between Diameter peers begins with one peer sending a 762 message to another Diameter peer. The set of AVPs included in the 763 message is determined by a particular Diameter application. One AVP 764 that is included to reference a user's session is the Session-Id. 766 The initial request for authentication and/or authorization of a user 767 would include the Session-Id. The Session-Id is then used in all 768 subsequent messages to identify the user's session (see section 8 for 769 more information). The communicating party may accept the request, or 770 reject it by returning an answer message with Result-Code AVP set to 771 indicate an error occurred. The specific behavior of the diameter 772 server or client receiving a request depends on the Diameter 773 application employed. 775 Session state (associated with a Session-Id) MUST be freed upon 776 receipt of the Session-Termination-Request, Session-Termination- 777 Answer, expiration of authorized service time in the Session-Timeout 778 AVP, and according to rules established in a particular Diameter 779 application. 781 2.1 Transport 783 The base Diameter protocol is run on port TBD of both TCP [TCP] and 784 SCTP [SCTP] transport protocols (for interoperability test purposes 785 port 1812 will be used until IANA assigns a port to the protocol). 786 When used with TLS [TLS], the Diameter protocol is run on port TBD of 787 both TCP and SCTP. 789 Diameter clients MUST support either TCP or SCTP, while agents and 790 servers MUST support both. Future versions of this specification MAY 791 mandate that clients support SCTP. 793 A Diameter node MAY initiate connections from a source port other 794 than the one that it declares it accepts incoming connections on, and 795 MUST be prepared to receive connections on port TBD. A given Diameter 796 process MUST NOT use more than one transport connection to 797 communicate with a given peer, unless multiple processes exist on the 798 peer in which case a separate connection per process is allowed. 800 When no transport connection exists with a peer, an attempt to 801 connect SHOULD be periodically attempted. This behavior is handled 802 via the Tc timer, who's recommended value is 30 seconds. There are 803 certain exceptions to this rule, such as when a peer has terminated 804 the transport connection stating that it does not wish to 805 communicate. 807 When connecting to a peer and either zero or more transports are 808 specified, SCTP SHOULD be tried first, followed by TCP. See section 809 5.2 for more information on peer discovery. 811 Diameter implementations SHOULD be able to interpret ICMP protocol 812 port unreachable messages as explicit indications that the server is 813 not reachable, subject to security policy on trusting such messages. 814 Diameter implementations SHOULD also be able to interpret 815 ECONNREFUSED (a reset from the transport) and timed-out connection 816 attempts. 818 If Diameter receives data up from TCP that cannot be parsed or 819 identified as a Diameter error made by the peer, the stream is 820 compromised and cannot be recovered. The transport connection MUST 821 be closed using a RESET call (graceful closure is also compromised). 823 2.1.1 SCTP Guidelines 825 The following are guidelines for Diameter implementations that 826 support SCTP: 828 1. For interoperability: All Diameter nodes MUST be prepared to 829 receive Diameter messages on any SCTP stream in the 830 association. 832 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 833 streams available to the association to prevent head-of-the- 834 line blocking. 836 2.2 Securing Diameter Messages 838 Diameter clients, such as Network Access Servers (NASes) and Mobility 839 Agents MUST support IP Security [SEC ARCH], and MAY support TLS 840 [TLS]. Diameter servers MUST support TLS and IPsec. Operating the 841 Diameter protocol without any security mechanism is not recommended. 843 It is suggested that IPsec can be used primarily at the edges and in 844 intra-domain traffic, such as using pre-shared keys between a NAS a 845 local AAA proxy. This also eases the requirements on the NAS to 846 support certificates. It is also suggested that inter-domain traffic 847 would primarily use TLS. See sections 13.1 and 13.2 for more details 848 on IPsec and TLS usage. 850 2.3 Diameter Application Compliance 852 Application Identifiers are advertised during the capabilities 853 exchange phase (see section 2.4). For a given application, there are 854 two different ways of advertising support. First, advertising support 855 of the application via the Auth-Application-Id implies that the 856 sender supports all authentication and authorization command codes, 857 and the AVPs specified in the associated ABNFs, described in the 858 specification. Second, advertising support of the application via the 859 Acct-Application-Id implies that the sender supports the Accounting 860 command codes defined in this specification, as well as the 861 accounting AVPs defined in the application's specification. 863 An implementation MAY add arbitrary AVPs to any command defined in an 864 application, including vendor-specific AVPs. Please refer to section 865 4.6 for details. 867 2.4 Application Identifiers 869 Each Diameter application MUST have an IANA assigned Application 870 Identifier (see section 11.3). The base protocol does not require an 871 Application Identifier since its support is mandatory. During the 872 capabilities exchange, Diameter nodes inform their peers of locally 873 supported applications. Furthermore, all Diameter messages contain an 874 Application Identifier, which is used in the message forwarding 875 process. 877 The following Application Identifier values are defined: 879 NASREQ 1 [NASREQ] 880 CMS Security 2 [CMS] 881 Mobile-IP 4 [DIAMMIP] 882 Relay 0xffffffff 884 Relay and redirect agents MUST advertise the Relay Application 885 Identifier, accounting servers capable of storing any records MUST 886 advertise the Relay Application Identifier for accounting, while all 887 other Diameter nodes MUST advertise locally supported applications. 888 The receiver of a Capabilities Exchange message advertising Relay 889 service MUST assume that the sender supports all current and future 890 applications. 892 Diameter relay and proxy agents are responsible for finding an 893 upstream server that supports the application of a particular 894 message. If none can be found, an error message is returned with the 895 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 897 2.5 Connections vs. Sessions 899 This section attempts to provide the reader with an understanding of 900 the difference between connection and session, which are terms used 901 extensively throughout this document. 903 A connection is a transport level connection between two peers, used 904 to send and receive Diameter messages. A session is a logical concept 905 at the application layer, and is shared between an access device and 906 a server, and is identified via the Session-Id AVP 908 +--------+ +-------+ +--------+ 909 | Client | | Relay | | Server | 910 +--------+ +-------+ +--------+ 911 <----------> <----------> 912 peer connection A peer connection B 914 <-----------------------------> 915 User session x 916 Figure 1: Diameter connections and sessions 918 In the example provided in Figure 1, peer connection A is established 919 between the Client and its local Relay. Peer connection B is 920 established between the Relay and the Server. User session X spans 921 from the Client via the Relay to the Server. Each "user" of a service 922 causes an auth request to be sent, with a unique session identifier. 923 Once accepted by the server, both the client and the server are aware 924 of the session. It is important to note that there is no relationship 925 between a connection and a session, and that Diameter messages for 926 multiple sessions are all multiplexed through a single connection. 928 2.6 Peer Table 930 The Diameter Peer Table is used in message forwarding, and referenced 931 by the Realm Routing Table. A Peer Table entry contains the following 932 fields: 934 - Host identity. following the conventions described for the 935 DiameterIdentity derived AVP data format in section 4.4. This 936 field contains the contents of the Origin-Host AVP found in the 937 CER or CEA message. 938 - Status. This is the state of the peer entry, and MUST match one 939 of the values listed in section 5.6. 940 - Static or Dynamic. Specifies whether a peer entry was statically 941 configured, or dynamically discovered. 942 - Expiration time. Specifies the time at which dynamically 943 discovered peer table entries are to be either refreshed, or 944 expired. 945 - TLS Enabled. Specifies whether TLS is to be used when 946 communicating with the peer. 947 - Additional security information, when needed (e.g. keys, 948 certificates) 950 2.7 Realm-Based Routing Table 952 All Realm-Based routing lookups are performed against what is 953 commonly known as the Realm Routing Table (see section 12). A Realm 954 Routing Table Entry contains the following fields: 956 - Realm Name. This is the field that is typically used as a 957 primary key in the routing table lookups. Note that some 958 implementations perform their lookups based on longest-match- 959 from-the-right on the realm rather than requiring an exact 960 match. 961 - Application Identifier. A route entry can have a different 962 destination based on the Acct-Application-Id for accounting 963 messages) or Auth-Application-Id (for non-accounting messages) 964 of the message. This field MUST be used as a secondary key field 965 in routing table lookups. 966 - Local Action. The Local Action field is used to identify how a 967 message should be treated. The following actions are supported: 968 1. LOCAL - Diameter messages that resolve to a route entry 969 with the Local Action set to Local can be satisfied 970 locally, and do not need to be routed to another server. 971 2. RELAY - All Diameter messages that fall within this 972 category MUST be routed to a next hop server, without 973 modifying any non-routing AVPs. See section 6.1.8 for 974 relaying guidelines 975 3. PROXY - All Diameter messages that fall within this 976 category MUST be routed to a next hop server. The local 977 server MAY apply its local policies to the message by 978 including new AVPs to the message prior to routing. See 979 section 6.1.8 for proxying guidelines. 980 4. REDIRECT - Diameter messages that fall within this 981 category MUST have the identity of the home Diameter 982 server(s) appended, and returned to the sender of the 983 message. See section 6.1.7 for redirect guidelines. 984 - Server Identifier. One or more servers the message is to be 985 routed to. These servers MUST also be present in the Peer table. 986 When the Local Action is set to RELAY or PROXY, this field 987 contains the identity of the server(s) the message must be 988 routed to. When the Local Action field is set to REDIRECT, this 989 field contains the identity of one or more servers the message 990 should be redirected to. 991 - Static or Dynamic. Specifies whether a route entry was 992 statically configured, or dynamically discovered. 993 - Expiration time. Specifies the time which a dynamically 994 discovered route table entry expires. 996 It is important to note that Diameter agents MUST support at least 997 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents 998 do not need to support all modes of operation in order to conform 999 with the protocol specification, but MUST follow the protocol 1000 compliance guidelines in section 2. Relay agents MUST NOT reorder 1001 AVPs, and proxies MUST NOT reorder AVPs. 1003 The routing table MAY include a default entry that MUST be used for 1004 any requests not matching any of the other entries. The routing table 1005 MAY consist of only such an entry. 1007 When a request is routed, the target server MUST have advertised the 1008 Application Identifier (see section 2.4) for the given message, or 1009 have advertised itself as a relay or proxy agent. Otherwise, an error 1010 is returned with the Result-Code AVP set to 1011 DIAMETER_UNABLE_TO_DELIVER. 1013 2.8 Role of Diameter Agents 1015 In addition to client and servers, the Diameter protocol introduces 1016 relay, proxy, redirect, and translation agents, each of which is 1017 defined in Section 1.3. These Diameter agents are useful for several 1018 reasons: 1020 - They can distribute administration of systems to a configurable 1021 grouping, including the maintenance of security associations. 1022 - They can be used for concentration of requests from an number of 1023 co-located or distributed NAS equipment sets to a set of like 1024 user groups. 1025 - They can do value-added processing to the requests or responses. 1026 - They can be used for load balancing. 1027 - A complex network will have multiple authentication sources, 1028 they can sort requests and forward towards the correct target. 1030 The Diameter protocol requires that agents maintain transaction 1031 state, which is used for failover purposes. Transaction state implies 1032 that upon forwarding a request, its Hop-by-Hop identifier is saved; 1033 the field is replaced with a locally unique identifier, which is 1034 restored to its original value when the corresponding answer is 1035 received. The request's state is released upon receipt of the answer. 1036 A stateless agent is one that only maintains transaction state. 1038 The Proxy-Info AVP allows stateless agents to add local state to a 1039 Diameter request, with the guarantee that the same state will be 1040 present in the answer. However, the protocol's failover procedures 1041 require that agents maintain a copy of pending requests. 1043 A stateful agent is one that maintains session state information; by 1044 keeping track of all authorized active sessions. Each authorized 1045 session is bound to a particular service, and its state is considered 1046 active either until it is notified otherwise, or by expiration. Each 1047 authorized session has an expiration, which is communicated by 1048 Diameter servers via the Session-Timeout AVP. 1050 Maintaining session state MAY be useful in certain applications, such 1051 as: 1053 - Protocol translation (e.g. RADIUS <-> Diameter) 1054 - Limiting resources authorized to a particular user 1055 - Per user or transaction auditing 1057 A Diameter agent MAY act in a stateful manner for some requests and 1058 be stateless for others. A Diameter implementation MAY act as one 1059 type of agent for some requests, and as another type of agent for 1060 others. 1062 2.8.1 Relay Agents 1063 Relay Agents are Diameter agents that accept requests and route 1064 messages to other Diameter nodes based on information found in the 1065 messages (e.g. Destination-Realm). This routing decision is performed 1066 using a list of supported realms, and known peers. This is known as 1067 the Realm Routing Table, as is defined further in section 2.8. 1069 Relays MAY be used to aggregate requests from multiple Network Access 1070 Servers (NASes) within a common geographical area (POP). The use of 1071 Relays is advantageous since it eliminates the need for NASes to be 1072 configured with the necessary security information they would 1073 otherwise require to communicate with Diameter servers in other 1074 realms. Likewise, this reduces the configuration load on Diameter 1075 servers that would otherwise be necessary when NASes are added, 1076 changed or deleted. 1078 Relays modify Diameter messages by inserting, and removing routing 1079 information, but do not modify any other portion of a message. 1080 Further, Relays' inherent simplicity implies that they are stateless 1081 and therefore SHOULD NOT maintain session state but MUST maintain 1082 transaction state. 1084 +------+ ---------> +------+ ---------> +------+ 1085 | | 1. Request | | 2. Request | | 1086 | NAS | | DRL | | HMS | 1087 | | 4. Answer | | 3. Answer | | 1088 +------+ <--------- +------+ <--------- +------+ 1089 mno.net mno.net abc.com 1090 Figure 2: Relaying of Diameter messages 1092 The example provided in Figure 2 depicts a request issued from NAS, 1093 which is an access device, for the user bob@abc.com. Prior to issuing 1094 the request, NAS performs a Diameter route lookup, using "abc.com" as 1095 the key, and determines that the message is to be relayed to DRL, 1096 which is a Diameter Relay. DRL performs the same route lookup as NAS, 1097 and relays the message to HMS, which is abc.com's Home Diameter 1098 Server. HMS identifies that the request can be locally supported (via 1099 the realm), processes the authentication and/or authorization 1100 request, and replies with an answer, which is routed back to NAS 1101 using saved transaction state. 1103 Since Relays do not perform any application level processing, they 1104 provide relaying services for all Diameter applications, and 1105 therefore MUST advertise the Relay Application Identifier. 1107 2.8.2 Proxy Agents 1109 Similarly to Relays, Proxy agents route Diameter messages using the 1110 Diameter Routing Table. However, they differ since they modify 1111 messages to implement policy enforcement. This requires that proxies 1112 maintain the state of their downstream peers (e.g. access devices) to 1113 enforce resource usage, provide admission control, and provisioning. 1115 It is important to note that although proxies MAY provide a value-add 1116 function for NASes, they do not allow access devices to use the 1117 Diameter CMS Security application, since modifying messages breaks 1118 authentication. 1120 Proxies MAY be used in call control centers or access ISPs that 1121 provide outsourced connections, they can monitor the number and types 1122 of ports in use, and make allocation and admission decisions 1123 according to their configuration. 1125 Proxies that wish to limit resources MUST be stateful, and all 1126 Proxies MUST maintain transaction state. 1128 Proxy agents MUST NOT allow CMS security to be established between 1129 two peers if it expects to modify ANY non-routing AVP in messages 1130 exchanged between the peers. See [CMS] for more information. 1132 Since enforcing policies requires an understanding of the service 1133 being provided, Proxies MUST only advertise the Diameter applications 1134 they support. 1136 2.8.3 Redirect Agents 1138 Redirect agents provide Realm to Server address resolution and MAY 1139 also provide User to Server address resolution. These redirect agents 1140 would make use of the Diameter routing table or optionally, a user 1141 table to determine where a given request should be forwarded. When a 1142 request is received by a redirect agent, a special answer is created, 1143 which includes the identity of the Diameter server(s) the originator 1144 of the request should contact directly. 1146 Redirect agents are useful in scenarios where the Diameter routing 1147 configuration needs to be centralized. An example is a redirect agent 1148 that provides services to all members of a consortium, but does not 1149 wish to be burdened with relaying all messages between realms. This 1150 scenario is advantageous since it does not require that the 1151 consortium provide routing updates to its members when changes are 1152 made to a member's infrastructure. 1154 Since redirect agents do not relay messages, and only return an 1155 answer with the information necessary for Diameter agents to 1156 communicate directly, they do not modify messages. Since redirect 1157 agents do not receive answer messages, they cannot maintain session 1158 state. Further, since redirect agents never relay requests, they are 1159 not required to maintain transaction state. 1161 The example provided in Figure 3 depicts a request issued from the 1162 access device, NAS, for the user bob@abc.com. The message is 1163 forwarded by the NAS to its relay, DRL, which does not have a routing 1164 entry in its Diameter Routing Table for abc.com. DRL has a default 1165 route configured to DRD, which is a redirect agent that returns a 1166 redirect notification to DRL, as well as HMS' contact information. 1167 Upon receipt of the redirect notification, DRL establishes a 1168 transport connection with HMS, if one doesn't already exist, and 1169 forwards the request to it. 1171 +------+ 1172 | | 1173 | DRD | 1174 | | 1175 +------+ 1176 ^ | 1177 2. Request | | 3. Redirection 1178 | | Notification 1179 | v 1180 +------+ ---------> +------+ ---------> +------+ 1181 | | 1. Request | | 4. Request | | 1182 | NAS | | DRL | | HMS | 1183 | | 6. Answer | | 5. Answer | | 1184 +------+ <--------- +------+ <--------- +------+ 1185 mno.net mno.net abc.com 1186 Figure 3: Redirecting a Diameter Message 1188 Since Redirect agents do not perform any application level 1189 processing, they provide relaying services for all Diameter 1190 applications, and therefore MUST advertise the Relay Application 1191 Identifier. 1193 2.8.4 Translation Agents 1195 A Translation Agent is a device that provides translation between two 1196 protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation 1197 agents are likely to be used as aggregation servers to communicate 1198 with a Diameter infrastructure, while allowing for the embedded 1199 systems to be migrated at a slower pace. 1201 Given that the Diameter protocol introduces the concept of long-lived 1202 authorized sessions, translation agents MUST be session stateful and 1203 MUST maintain transaction state. 1205 Translation of messages can only occur if the agent recognizes the 1206 application of a particular request, and therefore translation agents 1207 MUST only advertise their locally supported applications. 1209 +------+ ---------> +------+ ---------> +------+ 1210 | | RADIUS Request | | Diameter Request | | 1211 | NAS | | TLA | | HMS | 1212 | | RADIUS Answer | | Diameter Answer | | 1213 +------+ <--------- +------+ <--------- +------+ 1214 mno.net mno.net abc.com 1215 Figure 4: Translation of RADIUS to Diameter 1217 3 Diameter Header 1219 A summary of the Diameter header format is shown below. The fields 1220 are transmitted in network byte order. 1222 0 1 2 3 1223 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 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Ver | Message Length | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 |R P E r r r r r| Command-Code | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Vendor-ID | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Hop-by-Hop Identifier | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | End-to-End Identifier | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | AVPs ... 1236 +-+-+-+-+-+-+-+-+-+-+-+-+- 1238 Version 1239 This Version field MUST be set to 1 to indicate Diameter Version 1240 1. 1242 Message Length 1243 The Message Length field is three octets and indicates the length 1244 of the Diameter message including the header fields. 1246 Command Flags 1247 The Command Flags field is eight bits. The following bits are 1248 assigned: 1250 R(equest) - If set, the message is a request. If cleared, the 1251 message is an answer. 1253 P(roxiable) - If set, the message MAY be proxied, relayed or 1254 redirected. If cleared, the message MUST be 1255 locally processed. 1256 E(rror) - If set, the message contains a protocol error, 1257 and the message will not conform to the ABNF 1258 described for this command. Messages with the 'E' 1259 bit set are commonly referred to as an error 1260 messages. This bit MUST NOT be set in request 1261 messages. See section 7.2. 1262 r(eserved) - these flag bits are reserved for future use, and 1263 MUST be set to zero, otherwise an error MUST be 1264 sent to the sender. 1266 Command-Code 1267 The Command-Code field is three octets, and is used in order to 1268 communicate the command associated with the message. The 24-bit 1269 address space is managed by IANA (see section 11.2). 1271 Vendor-ID 1272 In the event that the Command-Code field contains a vendor 1273 specific command, the four-octet Vendor-ID field contains the IANA 1274 assigned "SMI Network Management Private Enterprise Codes" [ASSIGN 1275 NO] value. If the Command-Code field contains an IETF standard 1276 Command, the Vendor-ID field MUST be set to zero (0). Any vendor 1277 wishing to implement a vendor-specific Diameter command MUST use 1278 their own Vendor-ID along with their privately managed Command- 1279 Code address space, guaranteeing that they will not collide with 1280 any other vendor's vendor-specific command, nor with future IETF 1281 applications. All vendor-specific Diameter commands require 1282 Informational RFCs documenting the command unless for Private Use 1283 as described in Section 11.1.1. 1285 Hop-by-Hop Identifier 1286 The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in 1287 network byte order) and aids in matching requests and replies. The 1288 sender MUST ensure that the Hop-by-Hop identifier in a request is 1289 unique on a given connection at any given time, and MAY attempt to 1290 ensure that the number is unique across reboots. The sender of an 1291 Answer message MUST ensure that the Hop-by-Hop Identifier field 1292 contains the same value that was found in the corresponding 1293 request. The Hop-by-Hop identifier is normally a monotonically 1294 increasing number, whose start value was randomly generated. An 1295 answer message that is received with an unknown Hop-by-Hop 1296 Identifier MUST be discarded. 1298 End-to-End Identifier 1299 The End-to-End Identifier is an unsigned 32-bit integer field (in 1300 network byte order) and is used to detect duplicate messages. Upon 1301 reboot implementations MAY set the high order 12 bits to contain 1302 the low order 12 bits of current time, and the low order 20 bits 1303 to a random value. Senders of request messages MUST insert a 1304 unique identifier on each message. The identifier MUST remain 1305 locally unique for a period of at least 4 minutes, even across 1306 reboots. The originator of an Answer message MUST ensure that the 1307 End-to-End Identifier field contains the same value that was found 1308 in the corresponding request. The End-to-End Identifier MUST NOT 1309 be modified by relay agents. The combination of the Origin-Host 1310 and this field is used to detect duplicates. Duplicate requests 1311 SHOULD cause the same answer to be transmitted (modulo the hop- 1312 by-hop Identifier field and any routing AVPs that may be present), 1313 and MUST NOT affect any state that was set when the original 1314 request was processed. Duplicate answer messages that are to be 1315 locally consumed (see Section 6.2) SHOULD be silently discarded. 1317 AVPs 1318 AVPs are a method of encapsulating information relevant to the 1319 Diameter message. See section 4 for more information on AVPs. 1321 3.1 Command Codes 1323 Each command Request/Answer pair is assigned a command code, and the 1324 sub-type (i.e. - request or answer) is identified via the 'R' bit in 1325 the Command Flags field of the Diameter header. 1327 Every Diameter message MUST contain a command code in its header's 1328 Command-Code field, which is used to determine the action that is to 1329 be taken for a particular message. The following Command Codes are 1330 defined in the Diameter base protocol: 1332 Command-Name Abbrev. Code Reference 1333 -------------------------------------------------------- 1334 Abort-Session-Request ASR 274 8.5.1 1335 Abort-Session-Answer ASA 274 8.5.2 1336 Accounting-Request ACR 271 9.7.1 1337 Accounting-Answer ACA 271 9.7.2 1338 Capabilities-Exchange- CER 257 5.3.1 1339 Request 1340 Capabilities-Exchange- CEA 257 5.3.2 1341 Answer 1342 Device-Watchdog-Request DWR 280 5.5.1 1343 Device-Watchdog-Answer DWA 280 5.5.2 1344 Disconnect-Peer-Request DPR 282 5.4.1 1345 Disconnect-Peer-Answer DPA 282 5.4.2 1346 Re-Auth-Request RAR 258 8.3.1 1347 Re-Auth-Answer RAA 258 8.3.2 1348 Session-Termination- STR 275 8.4.1 1349 Request 1350 Session-Termination- STA 275 8.4.2 1351 Answer 1353 3.2 Command Code ABNF specification 1355 Every Command Code defined MUST include a corresponding ABNF 1356 specification, which is used to define the AVPs that MUST or MAY be 1357 present. The following format is used in the definition: 1359 command-def = command-name "::=" diameter-message 1361 command-name = diameter-name 1363 diameter-name = ALPHA *(ALPHA | DIGIT | "-") 1365 diameter-message = header [ *fixed] [ *required] [ *optional] 1366 [ *fixed] 1368 header = "<" Diameter-Header:" [vendor-id] command-id 1369 [r-bit] [p-bit] [e-bit] ">" 1371 vendor-id = 1*DIGIT ":" 1372 ; The optional vendor-id is used to define 1373 ; vendor specific commands 1375 command-id = 1*DIGIT 1376 ; The Command Code assigned to the command 1378 r-bit = ", REQ" 1379 ; If present, the 'R' bit in the Command 1380 ; Flags is set, indicating that the message 1381 ; is a request, as opposed to an answer. 1383 p-bit = ", PXY" 1384 ; If present, the 'P' bit in the Command 1385 ; Flags is set, indicating that the message 1386 ; is proxiable. 1388 e-bit = ", ERR" 1389 ; If present, the 'E' bit in the Command 1390 ; Flags is set, indicating that the answer 1391 ; message contains a Result-Code AVP in 1392 ; the "protocol error" class. 1394 fixed = [qual] "<" avp-spec ">" 1395 ; Defines the fixed position of an AVP 1397 required = [qual] "{" avp-spec "}" 1398 ; The AVP MUST be present and can appear 1399 ; anywhere in the message. 1401 optional = [qual] "[" avp-name "]" 1402 ; The avp-name in the 'optional' rule cannot 1403 ; evaluate to any AVP Name which is included 1404 ; in a fixed or required rule. The AVP can 1405 ; appear anywhere in the message. 1407 qual = [min] "*" [max] 1408 ; See ABNF conventions, RFC 2234 section 6.6. 1409 ; The absence of any qualifiers depends on whether 1410 ; it precedes a fixed, required, or optional 1411 ; rule. If a fixed or required rule has no 1412 ; qualifier, then exactly one such AVP MUST 1413 ; be present. If an optional rule has no 1414 ; qualifier, then 0 or 1 such AVP may be 1415 ; present. 1416 ; 1417 ; NOTE: "[" and "]" have a different meaning 1418 ; than in ABNF (see the optional rule, above). 1419 ; These braces cannot be used to express 1420 ; optional fixed rules (such as an optional 1421 ; ICV at the end.) To do this, the convention 1422 ; is '0*1fixed'. 1424 min = 1*DIGIT 1425 ; The minimum number of times the element may 1426 ; be present. The default value is zero. 1428 max = 1*DIGIT 1429 ; The maximum number of times the element may 1430 ; be present. The default value is infinity. A 1431 ; value of zero implies the AVP MUST NOT be 1432 ; present. 1434 avp-spec = diameter-name 1435 ; The avp-spec has to be an AVP Name, defined 1436 ; in the base or extended Diameter 1437 ; specifications. 1439 avp-name = avp-spec | "AVP" 1440 ; The string "AVP" stands for *any* arbitrary 1441 ; AVP Name, which does not conflict with the 1442 ; required or fixed position AVPs defined in 1443 ; the command code definition. 1445 The following is a definition of a fictitious command code: 1447 Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > 1448 { User-Name } 1449 * { Origin-Host } 1450 * [ AVP ] 1452 3.3 Diameter Command Naming Conventions 1454 Diameter commands typically includes one or more English words 1455 followed by the verb Request or Answer. Each English word is 1456 delimited by a hyphen. A three-letter acronym for both the request 1457 and answer is also normally provided. 1459 An example is a message set used to terminate a session. The command 1460 name is Session-Terminate-Request and Session-Terminate-Answer, while 1461 the acronyms are STR and STA, respectively. 1463 Both the request and the answer for a given command share the same 1464 command code. The request is identified by the R(equest) bit in the 1465 Diameter header set to one (1), to ask that a particular action be 1466 performed, such as authorizing a user or terminating a session. Once 1467 the receiver has completed the request it issues the corresponding 1468 answer, which includes a result code that communicates one of the 1469 following: 1471 - The request was successful 1472 - The request failed 1473 - An additional request must be sent to provide information the 1474 peer requires prior to returning a successful or failed answer. 1476 - The receiver could not process the request, but provides 1477 information about a Diameter peer that is able to satisfy the 1478 request, known as redirect. 1480 Additional information, encoded within AVPs, MAY also be 1481 included in answer messages. 1483 4 Diameter AVPs 1485 Diameter AVPs carry specific authentication, accounting, 1486 authorization, routing and security information as well as 1487 configuration details for the request and reply. 1489 Some AVPs MAY be listed more than once. The effect of such an AVP is 1490 specific, and is specified in each case by the AVP description. 1492 Each AVP of type OctetString MUST be padded to align on a 32-bit 1493 boundary, while other AVP types align naturally. Zero bytes are added 1494 to the end of the AVP Data field till a word boundary is reached. The 1495 length of the padding is not reflected in the AVP Length field. 1497 4.1 AVP Header 1499 The fields in the AVP header MUST be sent in network byte order. The 1500 format of the header is: 1502 0 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | AVP Code | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 |V M P r r r r r| AVP Length | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Vendor-ID (opt) | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Data ... 1512 +-+-+-+-+-+-+-+-+ 1514 AVP Code 1515 The AVP Code, combined with the Vendor-Id field, identifies the 1516 attribute uniquely. AVP numbers 0 through 255, with the Vendor-Id 1517 set to zero (0) are reserved for backward compatibility with 1518 RADIUS. AVP numbers 256 and above are used for Diameter, which are 1519 allocated by IANA (see section 11.1). 1521 AVP Flags 1522 The AVP Flags field informs the receiver how each attribute must 1523 be handled. The 'r' (reserved) bits are unused and SHOULD be set 1524 to 0. Note that subsequent Diameter applications MAY define 1525 additional bits within the AVP Header, and an unrecognized bit 1526 SHOULD be considered an error. The 'P' bit is defined in [CMS]. 1528 The 'M' Bit, known as the Mandatory bit, indicates whether support 1529 of the AVP is required. If an AVP with the 'M' bit set is received 1530 by a Diameter client, server, proxy, or translation agent and 1531 either the AVP or its value is unrecognized, the message MUST be 1532 rejected. Diameter Relay and Redirect agents MUST NOT reject 1533 messages with unrecognized AVPs. 1535 The 'M' bit MUST be set according to the rules defined for the AVP 1536 containing it. In order to preserve interoperability, a Diameter 1537 implementation MUST be able to exclude from a Diameter message any 1538 Mandatory AVP which is neither defined in the base Diameter 1539 standard nor in any of the Diameter Application specifications 1540 governing the message in which it appears. It MAY do this in one 1541 of the following ways: 1543 1) If a message is rejected because it contains a Mandatory AVP 1544 which is neither defined in the base Diameter standard nor in 1545 any of the Diameter Application specifications governing the 1546 message in which it appears, the implementation may resend the 1547 message without the AVP, possibly inserting additional standard 1548 AVPs instead. 1550 2) A configuration option may be provided on a system wide, per 1551 peer, or per realm basis that would allow/prevent particular 1552 Mandatory AVPs to be sent. Thus an administrator could change 1553 the configuration to avoid interoperability problems. 1555 Diameter implementations are required to support all Mandatory 1556 AVPs which are allowed by the message's formal syntax and defined 1557 either in the base Diameter standard or in one of the Diameter 1558 Application specifications governing the message. 1560 AVPs with the 'M' bit cleared are informational only and a 1561 receiver that receives a message with such an AVP that is not 1562 supported, or whose value is not supported, MAY simply ignore the 1563 AVP. 1565 The 'V' bit, known as the Vendor-Specific bit, indicates whether 1566 the optional Vendor-ID field is present in the AVP header. When 1567 set the AVP Code belongs to the specific vendor code address 1568 space. 1570 Unless otherwise noted, AVPs will have the following default AVP 1571 Flags field settings: 1573 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 1575 AVP Length 1576 The AVP Length field is three octets, and indicates the number of 1577 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1578 Vendor-ID field (if present) and the AVP data. If a message is 1579 received with an invalid attribute length, the message SHOULD be 1580 rejected. 1582 4.2 Optional Header Elements 1584 The AVP Header contains one optional field. This field is only 1585 present if the respective bit-flag is enabled. 1587 Vendor-ID 1588 The Vendor-ID field is present if the 'V' bit is set in the AVP 1589 Flags field. The optional four-octet Vendor-ID field contains the 1590 IANA assigned "SMI Network Management Private Enterprise Codes" 1591 [ASSIGNNO] value, encoded in network byte order. Any vendor 1592 wishing to implement a vendor-specific Diameter AVP MUST use their 1593 own Vendor-ID along with their privately managed AVP address 1594 space, guaranteeing that they will not collide with any other 1595 vendor's vendor-specific AVP, nor with future IETF applications. 1597 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 1598 values, as managed by the IANA. Since the absence of the vendor ID 1599 field implies that the AVP in question is not vendor specific, 1600 implementations MUST NOT use the zero (0) vendor ID. 1602 4.3 Basic AVP Data Formats 1604 The Data field is zero or more octets and contains information 1605 specific to the Attribute. The format and length of the Data field is 1606 determined by the AVP Code and AVP Length fields. The format of the 1607 Data field MUST be one of the following base data types or a data 1608 type derived from the base data types. In the event that a new Basic 1609 AVP Data Format is needed, a new version of this RFC must be created. 1611 OctetString 1612 The data contains arbitrary data of variable length. Unless 1613 otherwise noted, the AVP Length field MUST be set to at least 8 1614 (12 if the 'V' bit is enabled). AVP Values of this type that 1615 are not a multiple of four-octets in length is followed by the 1616 necessary padding so that the next AVP (if any) will start on a 1617 32-bit boundary. 1619 Integer32 1620 32 bit signed value, in network byte order. The AVP Length 1621 field MUST be set to 12 (16 if the 'V' bit is enabled). 1623 Integer64 1624 64 bit signed value, in network byte order. The AVP Length 1625 field MUST be set to 16 (20 if the 'V' bit is enabled). 1627 Unsigned32 1628 32 bit unsigned value, in network byte order. The AVP Length 1629 field MUST be set to 12 (16 if the 'V' bit is enabled). 1631 Unsigned64 1632 64 bit unsigned value, in network byte order. The AVP Length 1633 field MUST be set to 16 (20 if the 'V' bit is enabled). 1635 Float32 1636 This represents floating point values of single precision as 1637 described by [FLOATPOINT]. The 32-bit value is transmitted in 1638 network byte order. The AVP Length field MUST be set to 12 (16 1639 if the 'V' bit is enabled). 1641 Float64 1642 This represents floating point values of double precision as 1643 described by [FLOATPOINT]. The 64-bit value is transmitted in 1644 network byte order. The AVP Length field MUST be set to 16 (20 1645 if the 'V' bit is enabled). 1647 Grouped 1648 The Data field is specified as a sequence of AVPs. Each of 1649 these AVPs follows - in the order in which they are specified - 1650 including their headers and padding. The AVP Length field is 1651 set to 8 (12 if the 'V' bit is enabled) plus the total length 1652 of all included AVPs, including their headers and padding. Thus 1653 the AVP length field of an AVP of type Grouped is always a 1654 multiple of 4. 1656 4.4 Derived AVP Data Formats 1658 In addition to using the Basic AVP Data Formats, applications may 1659 define data formats derived from the Basic AVP Data Formats. An 1660 application that defines new AVP Derived Data Formats MUST include 1661 them in a section entitled "AVP Derived Data Formats", using the same 1662 format as the definitions below. Each new definition must be either 1663 defined or listed with a reference to the RFC that defines the 1664 format. 1666 The below AVP Derived Data Formats are commonly used by applications. 1668 IPAddress 1669 The IPAddress format is derived from the OctetString AVP Base 1670 Format. It represents 32 bit (IPv4) [IPV4] or 128-bit (IPv6) 1671 [IPV6] address, most significant octet first. The format of the 1672 address (IPv4 or IPv6) is determined by the length. If the 1673 attribute value is an IPv4 address, the AVP Length field MUST 1674 be 12 (16 if 'V' bit is enabled); otherwise, the AVP Length 1675 field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 1676 addresses. 1678 Time 1679 The Time format is derived from the OctetString AVP Base 1680 Format. The string MUST contain four octets, in the same format 1681 as the first four bytes are in the NTP timestamp format. The 1682 NTP Timestamp format is defined in chapter 3 of [SNTP]. 1684 This represents the number of seconds since 0h on 1 January 1685 1900 with respect to the Coordinated Universal Time (UTC). 1687 On 6h 28m 16s UTC, 7 February 2036 the time value will 1688 overflow. SNTP [SNTP] describes a procedure to extend the time 1689 to 2104. This procedure MUST be supported by all DIAMETER 1690 nodes. 1692 UTF8String 1693 The UTF8String format is derived from the OctetString AVP Base 1694 Format. This is a human readable string represented using the 1695 ISO/IEC IS 10646-1 character set, encoded as an OctetString 1696 using the UTF-8 [UFT8] transformation format described in RFC 1697 2279. 1699 Since additional code points are added by amendments to the 1700 10646 standard from time to time, implementations MUST be 1701 prepared to encounter any code point from 0x00000001 to 1702 0x7fffffff. Byte sequences that do not correspond to the valid 1703 UTF-8 encoding of a code point or are outside this range are 1704 prohibited. 1706 The use of control codes SHOULD be avoided. When it is 1707 necessary to represent a newline, the control code sequence CR 1708 LF SHOULD be used. 1710 The use of leading or trailing white space SHOULD be avoided. 1712 For code points not directly supported by user interface 1713 hardware or software, an alternative means of entry and 1714 display, such as hexadecimal, MAY be provided. 1716 For information encoded in 7-bit US-ASCII, the UTF-8 encoding 1717 is identical to the US-ASCII encoding. 1719 UTF-8 may require multiple bytes to represent a single 1720 character / code point; thus the length of an UTF8String in 1721 octets may be different from the number of characters encoded. 1723 Note that the AVP Length field of an UTF8String is measured in 1724 octets, not characters. 1726 DiameterIdentity 1727 The DiameterIdentity format is derived from the OctetString AVP 1728 Base Format. It uses the UTF-8 encoding and has the same 1729 requirements as the UTF8String: 1731 DiameterIdentity = fqdn 1733 DiameterIdentity value is used to uniquely identify a Diameter 1734 node for purposes of duplicate connection and routing loop 1735 detection. 1737 The DiameterIdentity format is derived from the OctetString 1738 Base AVP Format. It uses the UTF-8 encoding and has the same 1739 requirements as UTF8String. 1741 The contents of the string MUST be the fqdn of the Diameter 1742 node. If multiple Diameter nodes run on the same host, each 1743 Diameter node MUST be assigned a unique DiameterIdentity. If a 1744 Diameter node can be identified by several FQDNs, a single FQDN 1745 should be picked at startup, and used as the only 1746 DiameterIdentity for that node, whatever the connection it is 1747 sent on. 1749 DiameterURI 1751 The DiameterURI MUST follow the Uniform Resource Identifiers 1752 (URI) syntax [URI] rules specified below: 1754 "aaa://" fqdn [ port ] [ transport ] [ protocol ] 1756 ; No transport security 1758 "aaas://" fqdn [ port ] [ transport ] [ protocol ] 1759 ; Transport security used 1761 fqdn = Fully Qualified Host Name 1763 port = ":" 1*DIGIT 1765 ; One of the ports used to listen for 1766 ; incoming connections. 1767 ; If absent, 1768 ; the default Diameter port (TBD) is 1769 ; assumed. 1771 transport = ";transport=" transport-protocol 1773 ; One of the transports used to listen 1774 ; for incoming connections. If absent, 1775 ; the default SCTP [SCTP] protocol is 1776 ; assumed. UDP MUST NOT be used when 1777 ; the aaa-protocol field is set to 1778 ; diameter. 1780 transport-protocol = ( "tcp" | "sctp" | "udp" ) 1782 protocol = ";protocol=" aaa-protocol 1784 ; If absent, the default AAA protocol 1785 ; is diameter. 1787 aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) 1789 The following are examples of valid Diameter host identities: 1791 aaa://host.abc.com;transport=tcp 1792 aaa://host.abc.com:6666;transport=tcp 1793 aaa://host.abc.com;protocol=diameter 1794 aaa://host.abc.com:6666;protocol=diameter 1795 aaa://host.abc.com:6666;transport=tcp;protocol=diameter 1796 aaa://host.abc.com:1813;transport=udp;protocol=radius 1797 aaas://host.abc.com;transport=tcp 1798 aaas://host.abc.com;protocol=diameter 1800 Enumerated 1801 Enumerated is derived from the Integer32 AVP Base Format. The 1802 definition contains a list of valid values and their 1803 interpretation and is described in the Diameter application 1804 introducing the AVP. 1806 IPFilterRule 1807 The IPFilterRule format is derived from the OctetString AVP 1808 Base Format. It uses the UTF-8 encoding and has the same 1809 requirements as the UTF8String. Packets may be filtered based 1810 on the following information that is associated with it: 1812 Direction (in or out) 1813 Source and destination IP address (possibly masked) 1814 Protocol 1815 Source and destination port (lists or ranges) 1816 TCP flags 1817 IP fragment flag 1818 IP options 1819 ICMP types 1821 Rules for the appropriate direction are evaluated in order, 1822 with the first matched rule terminating the evaluation. Each 1823 packet is evaluated once. If no rule matches, the packet is 1824 dropped if the last rule evaluated was a permit, and passed if 1825 the last rule was a deny. 1827 IPFilterRule filters MUST follow the format: 1829 action dir proto from src to dst [options] 1831 action permit - Allow packets that match the rule. 1832 deny - Drop packets that match the rule. 1834 dir "in" is from the terminal, "out" is to the 1835 terminal. 1837 proto An IP protocol specified by number. The "ip" 1838 keyword means any protocol will match. 1840 src and dst
[ports] 1842 The
may be specified as: 1843 ipno An IPv4 or IPv6 number in dotted- 1844 quad or canonical IPv6 form. Only 1845 this exact IP number will match the 1846 rule. 1847 ipno/bits An IP number as above with a mask 1848 width of the form 1.2.3.4/24. In 1849 this case, all IP numbers from 1850 1.2.3.0 to 1.2.3.255 will match. 1851 The bit width MUST be valid for the 1852 IP version and the IP number MUST 1853 NOT have bits set beyond the mask. 1855 For a match to occur, the same IP 1856 version must be present in the 1857 packet that was used in describing 1858 the IP address. To test for a 1859 particular IP version, the bits part 1860 can be set to zero. The keyword 1861 "any" is 0.0.0.0/0 or the IPv6 1862 equivalent. The keyword "assigned" 1863 is the address or set of addresses 1864 assigned to the terminal. For IPv4, 1865 a typical first rule is often "deny 1866 in ip! assigned" 1868 The sense of the match can be inverted by 1869 preceding an address with the not modifier (!), 1870 causing all other addresses to be matched 1871 instead. This does not affect the selection of 1872 port numbers. 1874 With the TCP, UDP and SCTP protocols, optional 1875 ports may be specified as: 1877 {port|port-port}[,ports[,...]] 1879 The '-' notation specifies a range of ports 1880 (including boundaries). 1882 Fragmented packets that have a non-zero offset 1883 (i.e. not the first fragment) will never match 1884 a rule that has one or more port 1885 specifications. See the frag option for 1886 details on matching fragmented packets. 1888 options: 1889 frag Match if the packet is a fragment and this is not 1890 the first fragment of the datagram. frag may not 1891 be used in conjunction with either tcpflags or 1892 TCP/UDP port specifications. 1894 ipoptions spec 1895 Match if the IP header contains the comma 1896 separated list of options specified in spec. The 1897 supported IP options are: 1899 ssrr (strict source route), lsrr (loose source 1900 route), rr (record packet route) and ts 1901 (timestamp). The absence of a particular option 1902 may be denoted with a '!'. 1904 tcpoptions spec 1905 Match if the TCP header contains the comma 1906 separated list of options specified in spec. The 1907 supported TCP options are: 1909 mss (maximum segment size), window (tcp window 1910 advertisement), sack (selective ack), ts (rfc1323 1911 timestamp) and cc (rfc1644 t/tcp connection 1912 count). The absence of a particular option may 1913 be denoted with a '!'. 1915 established 1916 TCP packets only. Match packets that have the RST 1917 or ACK bits set. 1919 setup TCP packets only. Match packets that have the SYN 1920 bit set but no ACK bit. 1922 tcpflags spec 1923 TCP packets only. Match if the TCP header 1924 contains the comma separated list of flags 1925 specified in spec. The supported TCP flags are: 1927 fin, syn, rst, psh, ack and urg. The absence of a 1928 particular flag may be denoted with a '!'. A rule 1929 that contains a tcpflags specification can never 1930 match a fragmented packet that has a non-zero 1931 offset. See the frag option for details on 1932 matching fragmented packets. 1934 icmptypes types 1935 ICMP packets only. Match if the ICMP type is in 1936 the list types. The list may be specified as any 1937 combination of ranges or individual types 1938 separated by commas. Both the numeric values and 1939 the symbolic values listed below can be used. The 1940 supported ICMP types are: 1942 echo reply (0), destination unreachable (3), 1943 source quench (4), redirect (5), echo request 1944 (8), router advertisement (9), router 1945 solicitation (10), time-to-live exceeded (11), IP 1946 header bad (12), timestamp request (13), 1947 timestamp reply (14), information request (15), 1948 information reply (16), address mask request (17) 1949 and address mask reply (18). 1951 There is one kind of packet that the access device MUST always 1952 discard, that is an IP fragment with a fragment offset of one. 1953 This is a valid packet, but it only has one use, to try to 1954 circumvent firewalls. 1956 An access device that is unable to interpret or apply a deny 1957 rule MUST terminate the session. An access device that is 1958 unable to interpret or apply a permit rule MAY apply a more 1959 restrictive rule. An access device MAY apply deny rules of 1960 its own before the supplied rules, for example to protect 1961 the access device owner's infrastructure. 1963 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 1964 and the ipfw.c code may provide a useful base for 1965 implementations. 1967 QoSFilterRule 1968 The QosFilterRule format is derived from the OctetString AVP 1969 Base Format. It uses the UTF-8 encoding and has the same 1970 requirements as the UTF8String. Packets may be marked or 1971 metered based on the following information that is associated 1972 with it: 1974 Direction (in or out) 1975 Source and destination IP address (possibly masked) 1976 Protocol 1977 Source and destination port (lists or ranges) 1978 DSCP values (no mask or range) 1980 Rules for the appropriate direction are evaluated in order, 1981 with the first matched rule terminating the evaluation. Each 1982 packet is evaluated once. If no rule matches, the packet is 1983 treated as best effort. An access device that is unable to 1984 interpret or apply a QoS rule SHOULD NOT terminate the session. 1986 QoSFilterRule filters MUST follow the format: 1988 action dir proto from src to dst [options] 1990 tag - Mark packet with a specific DSCP 1991 [DIFFSERV]. The DSCP option MUST be 1992 included. 1993 meter - Meter traffic. The metering options 1994 MUST be included. 1996 dir The format is as described under IPFilterRule. 1998 proto The format is as described under 1999 IPFilterRule. 2001 src and dst The format is as described under 2002 IPFilterRule. 2004 4.5 Grouped AVP Values 2006 The Diameter protocol allows AVP values of type 'Grouped.' This 2007 implies that the Data field is actually a sequence of AVPs. It is 2008 possible to include an AVP with a Grouped type within a Grouped type, 2009 that is, to nest them. AVPs within an AVP of type Grouped have the 2010 same padding requirements as non-Grouped AVPs, as defined in section 2011 4. 2013 The AVP Code numbering space of all AVPs included in a Grouped AVP is 2014 the same as for non-grouped AVPs. Further, if any of the AVPs 2015 encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, 2016 the Grouped AVP itself MUST also include the 'M' bit set. 2018 Every Grouped AVP defined MUST include a corresponding grammar, using 2019 ABNF [ABNF] (with modifications), as defined below. 2021 grouped-avp-def = name "::=" avp 2023 name-fmt = ALPHA *(ALPHA | DIGIT | "-") 2025 name = name-fmt 2026 ; The name has to be the name of an AVP, 2027 ; defined in the base or extended Diameter 2028 ; specifications. 2030 avp = header [ *fixed] [ *required] [ *optional] 2031 [ *fixed] 2033 header = "<" "AVP-Header:" avpcode [vendor] ">" 2035 avpcode = 1*DIGIT 2036 ; The AVP Code assigned to the Grouped AVP 2038 vendor = 1*DIGIT 2039 ; The Vendor-ID assigned to the Grouped AVP. 2040 ; If absent, the default value of zero is 2041 ; used. 2043 4.5.1 Example AVP with a Grouped Data type 2045 The Example-AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following ABNF grammar: 2047 Example-AVP ::= < AVP Header: 999999 > 2048 { Origin-Host } 2049 1*{ Session-Id } 2050 *[ AVP ] 2052 An Example-AVP with Grouped Data follows. 2054 The Origin-Host AVP is required. In this case: 2056 Origin-Host = "abc.com". 2058 One or more Session-Ids must follow. Here there are two: 2060 Session-Id = 2061 "grump.abc.com:33041;23432;893;0AF3B81" 2063 Session-Id = 2064 "grump.abc.com:33054;23561;2358;0AF3B82" 2066 optional AVPs included are 2068 Recovery-Policy = 2069 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2070 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 2071 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd 2072 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a 2073 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 2074 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 2075 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 2077 Futuristic-Acct-Record = 2078 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 2079 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 2080 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 2081 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 2082 d3427475e49968f841 2084 The data for the optional AVPs is represented in hex since the format 2085 of these AVPs is neither known at the time of definition of the 2086 Example-AVP group, nor (likely) at the time when the example instance 2087 of this AVP is interpreted - except by Diameter implementations which 2088 support the same set of AVPs. The encoding example illustrates how 2089 padding is used and how length fields are calculated. Also note that 2090 AVPs may be present in the Grouped AVP value which the receiver 2091 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record 2092 AVPs). 2094 This AVP would be encoded as follows: 2096 0 1 2 3 4 5 6 7 2097 +-------+-------+-------+-------+-------+-------+-------+-------+ 2098 0 | Example AVP Header (AVP Code = 999999), Length = 468 | 2099 +-------+-------+-------+-------+-------+-------+-------+-------+ 2100 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | 2101 +-------+-------+-------+-------+-------+-------+-------+-------+ 2102 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 2103 +-------+-------+-------+-------+-------+-------+-------+-------+ 2104 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | 2105 +-------+-------+-------+-------+-------+-------+-------+-------+ 2106 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | 2107 +-------+-------+-------+-------+-------+-------+-------+-------+ 2108 . . . 2109 +-------+-------+-------+-------+-------+-------+-------+-------+ 2110 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| 2111 +-------+-------+-------+-------+-------+-------+-------+-------+ 2112 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | 2113 +-------+-------+-------+-------+-------+-------+-------+-------+ 2114 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | 2115 +-------+-------+-------+-------+-------+-------+-------+-------+ 2116 . . . 2117 +-------+-------+-------+-------+-------+-------+-------+-------+ 2118 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| 2119 +-------+-------+-------+-------+-------+-------+-------+-------+ 2120 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | 2121 +-------+-------+-------+-------+-------+-------+-------+-------+ 2122 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | 2123 +-------+-------+-------+-------+-------+-------+-------+-------+ 2124 . . . 2125 +-------+-------+-------+-------+-------+-------+-------+-------+ 2126 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| 2127 +-------+-------+-------+-------+-------+-------+-------+-------+ 2128 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| 2129 +-------+-------+-------+-------+-------+-------+-------+-------+ 2130 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 2131 +-------+-------+-------+-------+-------+-------+-------+-------+ 2132 . . . 2133 +-------+-------+-------+-------+-------+-------+-------+-------+ 2134 464 | 0x41 |Padding|Padding|Padding| 2135 +-------+-------+-------+-------+ 2137 4.6 Diameter Base Protocol AVPs 2139 The following table describes the Diameter AVPs defined in the base 2140 protocol, their AVP Code values, types, possible flag values and 2141 whether the AVP MAY be encrypted. For the originator of a Diameter 2142 message, "MAY Encr" means that if a message containing that AVP is to 2143 be sent via a proxy/agent then the message MUST NOT be sent unless 2144 there is a DSA between the originator and the recipient OR the 2145 originator has locally trusted configuration that indicates that CMS 2146 need not be used. Similarly, for the originator of a Diameter 2147 message, a "P" in the "MAY" column means that if a message containing 2148 that AVP is to be sent via a proxy/agent then the message MUST NOT be 2149 sent unless there is a DSA between the originator and the recipient 2150 or the originator has locally trusted configuration that indicates 2151 that CMS need not be used. 2153 Due to space constraints, the short form DiamIdent is used to 2154 represent DiameterIdentity. 2156 +---------------------+ 2157 | AVP Flag rules | 2158 |----+-----+----+-----|----+ 2159 AVP Section | | |SHLD| MUST|MAY | 2160 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2161 -----------------------------------------|----+-----+----+-----|----| 2162 Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y | 2163 Interim-Interval | | | | | | 2164 Accounting- 483 9.8.7 Unsigned32 | M | P | | V | Y | 2165 Realtime-Required | | | | | | 2166 Accounting- 50 9.8.5 UTF8String | M | P | | V | Y | 2167 Multi-Session-Id | | | | | | 2168 Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | 2169 Record-Number | | | | | | 2170 Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | 2171 Record-Type | | | | | | 2172 Accounting- 44 9.8.4 OctetString| M | P | | V | Y | 2173 RADIUS-Session-Id | | | | | | 2174 Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y | 2175 Sub-Session-Id | | | | | | 2176 Acct- 259 6.9 Integer32 | M | P | | V | N | 2177 Application-Id | | | | | | 2178 Auth- 258 6.8 Integer32 | M | P | | V | N | 2179 Application-Id | | | | | | 2180 Auth-Request- 274 8.7 Enumerated | M | P | | V | N | 2181 Type | | | | | | 2182 Authorization- 291 8.9 Unsigned32 | M | P | | V | N | 2183 Lifetime | | | | | | 2184 Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | 2185 Period | | | | | | 2186 Auth-Session- 277 8.11 Enumerated | M | P | | V | N | 2187 State | | | | | | 2188 Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | 2189 Type | | | | | | 2190 Class 25 8.20 OctetString| M | P | | V | Y | 2191 Destination-Host 293 6.5 DiamIdent | M | P | | V | N | 2192 Destination- 283 6.6 UTF8String | M | P | | V | N | 2193 Realm | | | | | | 2194 Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N | 2195 Error-Message 281 7.3 OctetString| | P | | V,M | N | 2196 Error-Reporting- 294 7.4 UTF8String | | P | | V,M | N | 2197 Host | | | | | | 2198 Failed-AVP 279 7.5 Grouped | M | P | | V | N | 2199 Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N | 2200 Revision | | | | | | 2201 Host-IP-Address 257 5.3.5 IPAddress | M | P | | V | N | 2202 -----------------------------------------|----+-----+----+-----|----| 2203 +---------------------+ 2204 | AVP Flag rules | 2205 |----+-----+----+-----|----+ 2206 AVP Section | | |SHLD| MUST|MAY | 2207 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2208 -----------------------------------------|----+-----+----+-----|----| 2209 Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | 2210 Time-Out | | | | | | 2211 Origin-Host 264 6.3 DiamIdent | M | P | | V | N | 2212 Origin-Realm 296 6.4 UTF8String | M | P | | V | N | 2213 Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N | 2214 Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N | 2215 Proxy-Host 280 6.7.3 DiamIdent | M | | | P,V | N | 2216 Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N | 2217 Proxy-State 33 6.7.4 OctetString| M | | | P,V | N | 2218 Redirect-Host 292 6.11 DiamURI | M | P | | V | N | 2219 Redirect-Host- 261 6.12 Enumerated | M | P | | V | N | 2220 Usage | | | | | | 2221 Redirect-Max- 262 6.13 Unsigned32 | M | P | | V | N | 2222 Cache-Time | | | | | | 2223 Result-Code 268 7.1 Unsigned32 | M | P | | V | N | 2224 Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N | 2225 Session-Id 263 8.8 UTF8String | M | P | | V | Y | 2226 Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N | 2227 Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y | 2228 Session-Server- 271 8.18 Enumerated | M | P | | V | Y | 2229 Failover | | | | | | 2230 Supported- 265 5.3.6 Unsigned32 | M | P | | V | N | 2231 Vendor-Id | | | | | | 2232 Termination- 295 8.15 Enumerated | M | P | | V | N | 2233 Cause | | | | | | 2234 User-Name 1 8.14 UTF8String | M | P | | V | Y | 2235 Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V | N | 2236 Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | 2237 Application-Id | | | | | | 2238 -----------------------------------------|----+-----+----+-----|----| 2240 5 Diameter Peers 2242 This section describes how Diameter nodes establish connections and 2243 communicate with peers. 2245 5.1 Peer Connections 2247 Although a Diameter node may have many possible peers that it is able 2248 to communicate with, it may not be economical to have an established 2249 connection to all of them. At a minimum, a Diameter node SHOULD have 2250 an established connection with two peers per realm, known as the 2251 primary and secondary peers. Of course, a node MAY have additional 2252 connections, if it is deemed necessary. Typically, all messages for a 2253 realm are sent to the primary peer, but in the event that failover 2254 procedures are invoked, any pending requests are sent to the 2255 secondary peer. However, implementations are free to load balance 2256 requests between a set of peers. 2258 Note that a given peer MAY act as a primary for a given realm, while 2259 acting as a secondary for another realm. 2261 When a peer is deemed suspect, which could occur for various reasons, 2262 including not receiving a DWA within an allotted timeframe, no new 2263 requests should be forwarded to the peer, but failover procedures are 2264 invoked. When an active peer is moved to this mode, additional 2265 connections SHOULD be established to ensure that the necessary number 2266 of active connections exists. 2268 There are two ways that a peer is removed from the suspect peer list: 2269 1. The peer is no longer reachable, causing the transport 2270 connection to be shutdown. The peer is moved to the closed 2271 state. 2272 2. Three watchdog messages are exchanged with accepted round trip 2273 times, and the connection to the peer is considered stabilized. 2275 In the event the peer being removed is either the primary or 2276 secondary, an alternate peer SHOULD replace the deleted peer, and 2277 assume the role of either primary or secondary. 2279 5.2 Diameter Peer Discovery 2281 Allowing for dynamic Diameter agent discovery will make it possible 2282 for simpler and more robust deployment of Diameter services. In 2283 order to promote interoperable implementations of Diameter peer 2284 discovery, the following mechanisms are described. These are based 2285 on existing IETF standards. The first option (manual configuration) 2286 MUST be supported by all DIAMETER nodes, while the latter two options 2287 (SRVLOC and DNS) MAY be supported. 2289 There are two cases where Diameter peer discovery may be performed. 2290 The first is when a Diameter client needs to discover a first-hop 2291 Diameter agent. The second case is when a Diameter agent needs to 2292 discover another agent - for further handling of a Diameter 2293 operation. In both cases, the following 'search order' is 2294 recommended: 2296 1. The Diameter implementation consults its list of static 2297 (manually) configured Diameter agent locations. These will be 2298 used if they exist and respond. 2300 2. The Diameter implementation uses SLPv2 [SLP] to discover 2301 Diameter services. The Diameter service template [TEMPLATE] is 2302 included in Appendix A. It is recommended that SLPv2 security 2303 be deployed (this requires distributing keys to SLPv2 agents). 2304 This is discussed further in Appendix A. 2306 SLPv2 will allow Diameter implementations to discover the 2307 location of Diameter agents in the local site, as well as their 2308 characteristics. Diameter agents with specific capabilities 2309 (say support for the Mobile IP application) can be requested, 2310 and only those will be discovered. 2312 3. The Diameter implementation performs a NAPTR query for a server 2313 in a particular realm. The Diameter implementation has to know 2314 in advance which realm to look for a Diameter agent in. This 2315 could be deduced, for example, from the 'realm' in a NAI that a 2316 Diameter implementation needed to perform a Diameter operation 2317 on. 2319 3.1 The services relevant for the task of transport protocol 2320 selection are those with NAPTR service fields with values 2321 "AAA+D2x" and "AAAS+D2X", where x is a letter that 2322 corresponds to a transport protocol supported by the domain. 2323 This specification defines D2T for TCP and D2S for SCTP. We 2324 also establish an IANA registry for NAPTR service name to 2325 transport protocol mappings. 2327 These NAPTR records provide a mapping from a domain, to the 2328 SRV record for contacting a server with the specific 2329 transport protocol in the NAPTR services field. The resource 2330 record will contain an empty regular expression and a 2331 replacement value, which is the SRV record for that 2332 particular transport protocol. If the server supports 2333 multiple transport protocols, there will be multiple NAPTR 2334 records, each with a different service value. As per RFC 2335 2915 [NAPTR], the client discards any records whose services 2336 fields are not applicable. For the purposes of this 2337 specification, several rules are defined. 2339 3.2 First, a client resolving a AAAS URI MUST discard any 2340 services that do not contain "AAAS" as the protocol in the 2341 service field. The converse is not true, however. A client 2342 resolving an AAA URI SHOULD retain records with "AAAS" as 2343 the protocol, if the client supports TLS. Second, a client 2344 MUST discard any service fields that identify a resolution 2345 service whose value is not "D2X", for values of X that 2346 indicate transport protocols supported by the client. The 2347 NAPTR processing as described in RFC 2915 will result in 2348 discovery of the most preferred transport protocol of the 2349 server that is supported by the client, as well as an SRV 2350 record for the server. It will also allow the client to 2351 discover if TLS is available and its preference for its 2352 usage. 2354 The domain suffixes in the NAPTR replacement field SHOULD 2355 match the domain of the original query. It is not necessary 2356 for the domain suffixes in the NAPTR replacement field to 2357 match the domain of the original query. 2359 3.3 If no NAPTR records are found, the requester queries for 2360 those address records for the destination address, 2361 '_diameters._sctp'.realm or '_diameters._tcp'.realm when 2362 using TLS or '_diameter._sctp'.realm or 2363 '_diameter._tcp'.realm when not using TLS. Address records 2364 include A RR's, AAAA RR's or other similar records, chosen 2365 according to the requestor's network protocol capabilities. 2366 If the DNS server returns no address records, the requestor 2367 gives up. 2369 For NAPTR records with AAAS protocol fields, if the server is 2370 using a site certificate, the domain name in the query and the 2371 domain name in the replacement field MUST both be valid based 2372 on the site certificate handed out by the server in the TLS 2373 exchange. Similarly, the domain name in the SRV query and the 2374 domain name in the target in the SRV record MUST both be valid 2375 based on the same site certificate. Otherwise, an attacker 2376 could modify the DNS records to contain replacement values in a 2377 different domain, and the client could not validate that this 2378 was the desired behavior, or the result of an attack. 2380 A dynamically discovered peer causes an entry in the Peer Table (see 2381 section 2.7) to be created. Note that entries created via DNS MUST 2382 expire (or be refreshed) within the DNS TTL. If a peer is discovered 2383 outside of the local realm, a routing table entry (see Section 2.8) 2384 for the peer's realm is created. The routing table entry's expiration 2385 MUST match the peer's expiration value. 2387 5.3 Capabilities Exchange 2389 When two Diameter peers establish a transport connection, they MUST 2390 exchange the Capabilities Exchange messages, as specified in the peer 2391 state machine (see section 5.6). This message allows the discovery of 2392 a peer's identity and its capabilities (protocol version number, 2393 supported Diameter applications, etc.) 2395 The receiver only issues commands to its peers that have advertised 2396 support for the Diameter application that defines the command. A 2397 Diameter node MUST cache the supported applications in order to 2398 ensure that unrecognized commands and/or AVPs are not unnecessarily 2399 sent to a peer. 2401 A receiver of a Capabilities-Exchange-Req (CER) message that does not 2402 have any applications in common with the sender MUST return a 2403 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to 2404 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport 2405 layer connection. Note that receiving a CER or CEA from a peer 2406 advertising itself as a Relay (see section 2.4) MUST be interpreted 2407 as having common applications with the peer. 2409 CERs received from unknown peers MAY be silently discarded, or a CEA 2410 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. 2411 In both cases, the transport connection is closed. If the local 2412 policy permits receiving CERs from unknown hosts, a successful CEA 2413 MAY be returned. If a CER from an unknown peer is answered with a 2414 successful CEA, the lifetime of the peer entry is equal to the 2415 lifetime of the transport connection. In case of a transport failure, 2416 all the pending transactions destined to the unknown peer can be 2417 discarded. 2419 The CER and CEA messages MUST NOT be proxied, or redirected. 2421 Since the CER/CEA messages cannot be proxied, it is still possible 2422 that an upstream agent receives a message for which it has no 2423 available peers to handle the application that corresponds to the 2424 Command-Code. In such instances, the 'E' bit is set in the answer 2425 message (see Section 7.2) with the Result-Code AVP set to 2426 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action 2427 (e.g. re-routing request to an alternate peer). 2429 With the exception of the Capabilities-Exchange-Request message, a 2430 message of type Request that includes the Auth-Application-Id or 2431 Acct-Application-Id AVPs, or a message with an application-specific 2432 command code, MAY only be forwarded to a host that has explicitly 2433 advertised support for the application (or has advertised the Relay 2434 Application Identifier). 2436 5.3.1 Capabilities-Exchange-Request 2437 The Capabilities-Exchange-Request (CER), indicated by the Command- 2438 Code set to 257 and the Command Flags' 'R' bit set, is sent to 2439 exchange local capabilities. Upon detection of a transport failure, 2440 this message MUST NOT be sent to an alternate peer. 2442 When Diameter is run over SCTP [SCTP], which allows for connections 2443 to span multiple interfaces and multiple IP addresses, the 2444 Capabilities-Exchange-Request message MUST contain one Host-IP- 2445 Address AVP for each potential IP address that MAY be locally used 2446 when transmitting Diameter messages. 2448 Message Format 2450 ::= < Diameter Header: 257, REQ > 2451 { Origin-Host } 2452 { Origin-Realm } 2453 1* { Host-IP-Address } 2454 { Vendor-Id } 2455 { Product-Name } 2456 [ Origin-State-Id ] 2457 * [ Supported-Vendor-Id ] 2458 * [ Auth-Application-Id ] 2459 * [ Acct-Application-Id ] 2460 * [ Vendor-Specific-Application-Id ] 2461 [ Firmware-Revision ] 2462 * [ AVP ] 2464 5.3.2 Capabilities-Exchange-Answer 2466 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code 2467 set to 257 and the Command Flags' 'R' bit cleared, is sent in 2468 response to a CER message. 2470 When Diameter is run over SCTP [SCTP], which allows connections to 2471 span multiple interfaces, hence, multiple IP addresses, the 2472 Capabilities-Exchange-Answer message MUST contain one Host-IP-Address 2473 AVP for each potential IP address that MAY be locally used when 2474 transmitting Diameter messages. 2476 Message Format 2477 ::= < Diameter Header: 257 > 2478 { Result-Code } 2479 { Origin-Host } 2480 { Origin-Realm } 2481 1* { Host-IP-Address } 2482 { Vendor-Id } 2483 { Product-Name } 2484 [ Origin-State-Id ] 2485 [ Error-Message ] 2486 * [ Failed-AVP ] 2487 * [ Supported-Vendor-Id ] 2488 * [ Auth-Application-Id ] 2489 * [ Acct-Application-Id ] 2490 * [ Vendor-Specific-Application-Id ] 2491 [ Firmware-Revision ] 2492 * [ AVP ] 2494 5.3.3 Vendor-Id AVP 2496 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 2497 the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] 2498 value assigned to the vendor of the Diameter device. In combination 2499 with the Supported-Vendor-Id AVP (section 5.3.6), this MAY be used in 2500 order to know which vendor specific attributes may be sent to the 2501 peer. It is also envisioned that the combination of the Vendor-Id, 2502 Product-Name (section 5.3.7) and the Firmware-Revision (section 2503 5.3.4) AVPs MAY provide very useful debugging information. 2505 A Vendor-Id value of zero in the CER or CEA messages is reserved and 2506 indicates that the Diameter peer is in the experimental or concept 2507 stage and that an IANA Private Enterprise Number has yet to be 2508 obtained by the implementer. 2510 5.3.4 Firmware-Revision AVP 2512 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 2513 used to inform a Diameter peer of the firmware revision of the 2514 issuing device. 2516 For devices that do not have a firmware revision (general purpose 2517 computers running Diameter software modules, for instance), the 2518 revision of the Diameter software module may be reported instead. 2520 5.3.5 Host-IP-Address AVP 2521 The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is 2522 used to inform a Diameter peer of the sender's IP address. All source 2523 addresses that a Diameter node expects to use with SCTP [SCTP] MUST 2524 be advertised in the CER and CEA messages by including a Host-IP- 2525 Address AVP for each address. This AVP MUST ONLY be used in the CER 2526 and CEA messages. 2528 5.3.6 Supported-Vendor-Id AVP 2530 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and 2531 contains the IANA "SMI Network Management Private Enterprise Codes" 2532 [ASSIGN NO] value assigned to a vendor other than the device vendor. 2533 This is used in the CER and CEA messages in order to inform the peer 2534 that the sender supports a subset of the vendor-specific commands 2535 and/or AVPs defined by the vendor identified in this AVP. 2537 5.3.7 Product-Name AVP 2539 The Product-Name AVP (AVP Code 269) is of type UTF8String, and 2540 contains the vendor assigned name for the product. The Product-Name 2541 AVP SHOULD remain constant across firmware revisions for the same 2542 product. 2544 5.4 Disconnecting Peer connections 2546 When a Diameter node disconnects one of its transport connections, 2547 its peer cannot know the reason for the disconnect, and will most 2548 likely assume that a connectivity problem occurred, or that the peer 2549 has rebooted. In these cases, the peer may periodically attempt to 2550 reconnect, as stated in section 2.1. In the event that the disconnect 2551 was a result of either a shortage of internal resources, or simply 2552 that the node in question has no intentions of forwarding any 2553 Diameter messages to the peer in the foreseeable future, a periodic 2554 connection request would not be welcomed. The Disconnection-Reason 2555 AVP contains the reason the Diameter node issued the Disconnect- 2556 Peer-Request message. 2558 The Disconnect-Peer-Request message is used by a Diameter node to 2559 inform its peer of its intent to disconnect the transport layer, and 2560 that the peer shouldn't reconnect unless it has a valid reason to do 2561 so (e.g. message to be forwarded). Upon receipt of the message, the 2562 Disconnect-Peer-Answer is returned, which SHOULD contain an error if 2563 messages have recently been forwarded, and are likely in flight, 2564 which would otherwise cause a race condition. 2566 The receiver of the Disconnect-Peer-Answer initiates the transport 2567 disconnect. 2569 5.4.1 Disconnect-Peer-Request 2571 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set 2572 to 282 and the Command Flags' 'R' bit set, is sent to a peer to 2573 inform its intentions to shutdown the transport connection. Upon 2574 detection of a transport failure, this message MUST NOT be sent to an 2575 alternate peer. 2577 Message Format 2579 ::= < Diameter Header: 282, REQ > 2580 { Origin-Host } 2581 { Origin-Realm } 2582 { Disconnect-Cause } 2584 5.4.2 Disconnect-Peer-Answer 2586 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set 2587 to 282 and the Command Flags' 'R' bit cleared, is sent as a response 2588 to the Disconnect-Peer-Request message. Upon receipt of this message, 2589 the transport connection is shutdown. 2591 Message Format 2593 ::= < Diameter Header: 282 > 2594 { Result-Code } 2595 { Origin-Host } 2596 { Origin-Realm } 2597 [ Error-Message ] 2598 * [ Failed-AVP ] 2600 5.4.3 Disconnect-Cause AVP 2602 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A 2603 Diameter node MUST include this AVP in the Disconnect-Peer-Request 2604 message to inform the peer of the reason for its intention to 2605 shutdown the transport connection. The following values are 2606 supported: 2608 REBOOTING 0 2609 A scheduled reboot is imminent. 2611 BUSY 1 2612 The peer's internal resources are constrained, and it has 2613 determined that the transport connection needs to be closed. 2615 DO_NOT_WANT_TO_TALK_TO_YOU 2 2616 The peer has determined that it does not see a need for the 2617 transport connection to exist, since it does not expect any 2618 messages to be exchanged in the near future. 2620 5.5 Transport Failure Detection 2622 Given the nature of the Diameter protocol, it is recommended that 2623 transport failures be detected as soon as possible. Detecting such 2624 failures will minimize the occurrence of messages sent to unavailable 2625 agents, resulting in unnecessary delays, and will provide better 2626 failover performance. The Device-Watchdog-Request and Device- 2627 Watchdog-Answer messages, defined in this section, are used to pro- 2628 actively detect transport failures. 2630 5.5.1 Device-Watchdog-Request 2632 The Device-Watchdog-Request (DWR), indicated by the Command-Code set 2633 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no 2634 traffic has been exchanged between two peers (see Section 5.5.3). 2635 Upon detection of a transport failure, this message MUST NOT be sent 2636 to an alternate peer. 2638 Message Format 2640 ::= < Diameter Header: 280, REQ > 2641 { Origin-Host } 2642 { Origin-Realm } 2643 [ Origin-State-Id ] 2645 5.5.2 Device-Watchdog-Answer 2647 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 2648 to 280 and the Command Flags' 'R' bit cleared, is sent as a response 2649 to the Device-Watchdog-Request message. 2651 Message Format 2652 ::= < Diameter Header: 280 > 2653 { Result-Code } 2654 { Origin-Host } 2655 { Origin-Realm } 2656 [ Error-Message ] 2657 * [ Failed-AVP ] 2658 [ Original-State-Id ] 2660 5.5.3 Transport Failure Algorithm 2662 The transport failure algorithm is defined in [AAATRANS]. All 2663 Diameter implementations MUST support the algorithm defined in the 2664 specification in order to be compliant to the Diameter base protocol. 2666 5.5.4 Failover and Failback Procedures 2668 In the event that a transport failure is detected with a peer, it is 2669 necessary for all pending request messages to be forwarded to an 2670 alternate agent, if possible. This is commonly referred to as 2671 failover. 2673 In order for a Diameter node to perform failover procedures, it is 2674 necessary for the node to maintain a pending message queue for a 2675 given peer. When an answer message is received, the corresponding 2676 request is removed from the queue. The Hop-by-Hop Identifier field is 2677 used to match the answer with the queued request. 2679 When a transport failure is detected, all messages in the queue are 2680 sent to an alternate agent, if possible. An example of a case where 2681 it is not possible to forward the message to an alternate server is 2682 when the message has a fixed destination, and the unavailable peer is 2683 the message's final destination (see Destination-Host AVP). Such an 2684 error requires that the agent return an answer message with the 'E' 2685 bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 2687 It is important to note that multiple identical requests or answers 2688 MAY be received as a result of a failover. The End-to-End Identifier 2689 field in the Diameter header along with the Origin-Host AVP MUST be 2690 used to identify duplicate messages. 2692 As described in section 2.1, a connection request should be 2693 periodically attempted with the failed peer in order to re-establish 2694 the transport connection. Once a connection has been successfully 2695 established, messages can once again be forwarded to the peer. This 2696 is commonly referred to as failback. 2698 5.6 Peer State Machine 2700 This section contains a finite state machine that MUST be observed by 2701 all Diameter implementations. Each Diameter node MUST follow the 2702 state machine described below when communicating with each peer. 2703 Multiple actions are separated by commas, and may continue on 2704 succeeding lines, as space requires. Similarly, state and next state 2705 may also span multiple lines, as space requires. 2707 This state machine is closely coupled with the state machine 2708 described in [AAATRANS], which is used to open, close, failover, 2709 probe, and reopen transport connections. Note in particular that 2710 [AAATRANS] requires the use of watchdog messages to probe 2711 connections. For Diameter, DWR and DWA messages are to be used. 2713 I- is used to represent the initiator (connecting) connection, while 2714 the R- is used to represent the responder (listening) connection. The 2715 lack of a prefix indicates that the event or action is the same 2716 regardless of the connection on which the event occurred. 2718 The stable states that a state machine may be in are Closed, I-Open 2719 and R-Open; all other states are intermediate. Note that I-Open and 2720 R-Open are equivalent except for whether the initiator or responder 2721 transport connection is used for communication. 2723 A CER message is always sent on the initiating connection immediately 2724 after the connection request is successfully completed. In the case 2725 of an election, one of the two connections will shut down. The 2726 responder connection will survive if the Origin-Host of the local 2727 Diameter entity is higher than that of the peer; the initiator 2728 connection will survive if the peer's Origin-Host is higher. All 2729 subsequent messages are sent on the surviving connection. Note that 2730 the results of an election on one peer are guaranteed to be the 2731 inverse of the results on the other. 2733 The state machine constrains only the behavior of a Diameter 2734 implementation as seen by Diameter peers through events on the wire. 2735 Any implementation that produces equivalent results is considered 2736 compliant. 2738 state event action next state 2739 ----------------------------------------------------------------- 2740 Closed Start I-Snd-Conn-Req Wait-Conn-Ack 2741 R-Conn-CER R-Accept, R-Open 2742 Process-CER, 2743 R-Snd-CEA 2745 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA 2746 I-Rcv-Conn-Nack Cleanup Closed 2747 R-Conn-CER R-Accept, Wait-Conn-Ack/ 2748 Process-CER Elect 2749 Timeout Error Closed 2751 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open 2752 R-Conn-CER R-Accept, Wait-Returns 2753 Process-CER, 2754 Elect 2755 I-Peer-Disc I-Disc Closed 2756 I-Rcv-Non-CEA Error Closed 2757 Timeout Error Closed 2759 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns 2760 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open 2761 R-Peer-Disc R-Disc Wait-Conn-Ack 2762 R-Conn-CER R-Reject Wait-Conn-Ack/ 2763 Elect 2764 Timeout Error Closed 2766 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open 2767 I-Peer-Disc I-Disc, R-Open 2768 R-Snd-CEA 2769 I-Rcv-CEA R-Disc I-Open 2770 R-Peer-Disc R-Disc Wait-I-CEA 2771 R-Conn-CER R-Reject Wait-Returns 2772 Timeout Error Closed 2774 R-Open Send-Message R-Snd-Message R-Open 2775 R-Rcv-Message Process R-Open 2776 R-Rcv-DWR Process-DWR, R-Open 2777 R-Snd-DWA 2778 R-Rcv-DWA Process-DWA R-Open 2779 R-Conn-CER R-Snd-CEA R-Open 2780 R-Reject 2781 Stop R-Snd-DPR Closing 2782 R-Rcv-DPR R-Snd-DPA, Closed 2783 R-Disc 2784 R-Peer-Disc R-Disc Closed 2785 R-Rcv-CER R-Snd-CEA R-Open 2786 R-Rcv-CEA Process-CEA R-Open 2788 I-Open Send-Message I-Snd-Message I-Open 2789 I-Rcv-Message Process I-Open 2790 I-Rcv-DWR Process-DWR, I-Open 2791 I-Snd-DWA 2792 I-Rcv-DWA Process-DWA I-Open 2793 R-Conn-CER R-Reject I-Open 2794 Stop I-Snd-DPR Closing 2795 I-Rcv-DPR I-Snd-DPA, Closed 2796 I-Disc 2797 I-Peer-Disc I-Disc Closed 2798 I-Rcv-CER I-Snd-CEA I-Open 2799 I-Rcv-CEA Process-CEA I-Open 2801 Closing I-Rcv-DPA I-Disc Closed 2802 R-Rcv-DPA R-Disc Closed 2803 Timeout Error Closed 2804 I-Peer-Disc I-Disc Closed 2805 R-Peer-Disc R-Disc Closed 2807 5.6.1 Incoming connections 2809 When a connection request is received from a Diameter peer, it is 2810 not, in the general case, possible to know the identity of that peer 2811 until a CER is received from it. This is because host and port 2812 determine the identity of a Diameter peer; and the source port of an 2813 incoming connection is arbitrary. Upon receipt of CER, the identity 2814 of the connecting peer can be uniquely determined from Origin-Host. 2816 For this reason, a Diameter peer must employ logic separate from the 2817 state machine to receive connection requests, accept them, and await 2818 CER. Once CER arrives on a new connection, the Origin-Host that 2819 identifies the peer is used to locate the state machine associated 2820 with that peer, and the new connection and CER are passed to the 2821 state machine as an R-Conn-CER event. 2823 The logic that handles incoming connections SHOULD close and discard 2824 the connection if any message other than CER arrives, or if an 2825 implementation-defined timeout occurs prior to receipt of CER. 2827 Because handling of incoming connections up to and including receipt 2828 of CER requires logic, separate from that of any individual state 2829 machine associated with a particular peer, it is described separately 2830 in this section rather than in the state machine above. 2832 5.6.2 Events 2834 Transitions and actions in the automaton are caused by events. In 2835 this section, we will ignore the -I and -R prefix, since the actual 2836 event would be identical, but would occur on one of two possible 2837 connections. 2839 Start The Diameter application has signaled that a 2840 connection should be initiated with the peer. 2842 R-Conn-CER An acknowledgement is received stating that the 2843 transport connection has been established, and the 2844 associated CER has arrived. 2846 Rcv-Conn-Ack A positive acknowledgement is received confirming 2847 that the transport connection is established. 2849 Rcv-Conn-Nack A negative acknowledgement was received stating 2850 that the transport connection was not established. 2852 Timeout An application-defined timer has expired while 2853 waiting for some event. 2855 Rcv-CER A CER message from the peer was received. 2857 Rcv-CEA A CEA message from the peer was received. 2859 Rcv-Non-CEA A message other than CEA from the peer was 2860 received. 2862 Peer-Disc A disconnection indication from the peer was 2863 received. 2865 Rcv-DPR A DPR message from the peer was received. 2867 Rcv-DPA A DPA message from the peer was received. 2869 Win-Election An election was held, and the local node was the 2870 winner. 2872 Send-Message A message is to be sent. 2874 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR or DWA 2875 was received. 2877 Stop The Diameter application has signaled that a 2878 connection should be terminated (e.g., on system 2879 shutdown). 2881 5.6.3 Actions 2883 Actions in the automaton are caused by events and typically indicate 2884 the transmission of packets and/or an action to be taken on the 2885 connection. In this section we will ignore the I- and R- prefix, 2886 since the actual action would be identical, but would occur on one of 2887 two possible connections. 2889 Snd-Conn-Req A transport connection is initiated with the peer. 2891 Accept The incoming connection associated with the R- 2892 Conn-CER is accepted as the responder connection. 2894 Reject The incoming connection associated with the R- 2895 Conn-CER is disconnected. 2897 Process-CER The CER associated with the R-Conn-CER is 2898 processed. 2900 Snd-Conn-Ack an acknowledgement is received confirming that the 2901 transport connection is established. 2903 Snd-CER A CER message is sent to the peer. 2905 Snd-CEA A CEA message is sent to the peer. 2907 Cleanup If necessary, the connection is shutdown, and any 2908 local resources are freed. 2910 Error The transport layer connection is disconnected, 2911 either politely or abortively, in response to an 2912 error condition. Local resources are freed. 2914 Process-CEA A received CEA is processed. 2916 Snd-DPR A DPR message is sent to the peer. 2918 Snd-DPA A DPA message is sent to the peer. 2920 Disc The transport layer connection is disconnected, and 2921 local resources are freed. 2923 Elect An election occurs (see Section 5.6.4 for more 2924 information). 2926 Snd-Message A message is sent. 2928 Snd-DWR A DWR message is sent. 2930 Snd-DWA A DWA message is sent. 2932 Process-DWR The DWR message is serviced. 2934 Process-DWA The DWA message is serviced. 2936 Process A message is serviced. 2938 5.6.4 The Election Process 2940 The election is performed on the responder. The responder compares 2941 the Origin-Host received in the CER sent by its peer with its own 2942 Origin-Host. If the local Diameter entity's Origin-Host is higher 2943 than the peer's, a Win-Election event is issued locally. 2945 The comparison proceeds by considering the shorter OctetString to be 2946 padded with zeros so that it length is the same as the length of the 2947 longer, then performing an octet-by-octet unsigned comparison with 2948 the first octet being most significant. Hanging octets are assumed to 2949 have value 0x80. 2951 6 Diameter message processing 2953 This section describes how Diameter requests and answers are created 2954 and processed. 2956 6.1 Diameter request routing overview 2958 A request is sent towards its final destination using a combination 2959 of the Destination-Realm and Destination-Host AVPs, in one of these 2960 three combinations: 2961 - a request that is not able to be proxied (such as CER) MUST NOT 2962 contain either Destination-Realm or Destination-Host AVPs. 2963 - a request that needs to be sent to a home server serving a 2964 specific realm, but not to a specific server (such as the first 2965 request of a series of round-trips), MUST contain a 2966 Destination-Realm AVP, but MUST NOT contain a Destination-Host 2967 AVP. 2968 - otherwise, a request that needs to be sent to a specific home 2969 server among those serving a given realm, MUST contain both the 2970 Destination-Realm and Destination-Host AVPs. 2972 The Destination-Host AVP is used as described above when the 2973 destination of the request is fixed, which includes: 2974 - Authentication requests that span multiple round trips 2975 - A Diameter message that uses a security mechanism that makes use 2976 of a pre-established session key shared between the source and 2977 the final destination of the message. 2978 - Server initiated messages that MUST be received by a specific 2979 Diameter client (e.g. access device), such as the Abort- 2980 Session-Request message, which is used to request that a 2981 particular user's session be terminated. 2983 Note that an agent can forward a request to a host described in the 2984 Destination-Host AVP only if the host in question is included in its 2985 peer table (see section 2.7). Otherwise, the request is routed based 2986 on the Destination-Realm only (see sections 6.1.6). 2988 The Destination-Realm AVP MUST be present if the message is 2989 proxiable. Proxiable request messages MUST also contain either an 2990 Acct-Application-Id AVP or an Auth-Application-Id AVP. A message that 2991 MUST NOT be relayed, proxied or redirected MUST NOT include the 2992 Destination-Realm in its ABNF. The value of the Destination-Realm AVP 2993 MAY be extracted from the User-Name AVP, or other application- 2994 specific methods. 2996 When a message is received, the message is processed in the following 2997 order: 2998 1. If the message is destined for the local host, the procedures 2999 listed in section 6.1.4 are followed. 3000 2. If the message is intended for a Diameter peer with whom the 3001 local host is able to directly communicate, the procedures 3002 listed in section 6.1.5 are followed. This is known as Request 3003 Forwarding. 3004 3. The procedures listed in section 6.1.6 are followed, which is 3005 known as Request Routing. 3006 4. If none of the above is successful, an answer is returned with 3007 the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. 3009 For routing of Diameter messages to work within an administrative 3010 domain, all Diameter nodes within the realm MUST be peers. If 3011 intermediate nodes are desired (see Figure 5), the destination node 3012 MUST be in a subrealm and routes to that subrealm MUST exist in the 3013 routing table on the sending node and all intermediate nodes. Figure 3014 5 shows an example of a hierarchical network that requires the use of 3015 subrealms. In such a network, routing must be performed with longest 3016 match from right. 3018 +---------+ 3019 | abc.com | 3020 +---------+ 3022 +-------+ +-------+ 3023 | agent | | agent | 3024 +-------+ +-------+ 3026 +-------------+ +--------------+ +-------------+ +--------------+ 3027 | eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com | 3028 +-------------+ +--------------+ +-------------+ +--------------+ 3029 Figure 5: Hierarchical administrative domain 3031 Note the processing rules contained in this section are intended to 3032 be used as general guidelines to Diameter developers. Certain 3033 implementations MAY use different methods than the ones described 3034 here, and still comply with the protocol specification. 3036 6.1.1 Originating a Request 3038 When creating a request, in addition to any other procedures 3039 described in the application definition for that specific request, 3040 the following procedures MUST be followed: 3041 - the Command-Code should be set to the appropriate value 3042 - the 'R' bit should be set 3043 - the End-to-End Identifier should be set to a locally unique 3044 value 3045 - the Origin-Host and Origin-Realm AVPs MUST be set to the 3046 appropriate values, used to identify the source of the message 3047 - the Destination-Host and Destination-Realm AVPs MUST be set to 3048 the appropriate values as described in section 6.1. 3049 - an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor- 3050 Specific-Application-Id AVP must be included if the request is 3051 proxiable. 3053 6.1.2 Sending a Request 3055 When sending a request, originated either locally, or as the result 3056 of a forwarding or routing operation, the following procedures MUST 3057 be followed: 3058 - the Hop-by-Hop Identifier should be set to a locally unique 3059 value 3060 - The message should be saved in the list of pending requests. 3062 Other actions to perform on the message based on the particular role 3063 the agent is playing are described in the following sections. 3065 6.1.3 Receiving Requests 3067 A relay or proxy agent MUST check for forwarding loops when receiving 3068 requests. A loop is detected if the server finds its own identity in 3069 a Route-Record AVP. When such an event occurs, the agent MUST answer 3070 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 3072 6.1.4 Processing Local Requests 3074 A request is known to be for local consumption when one of the 3075 following conditions occur: 3076 - The Destination-Host AVP contains the local host's identity, 3077 - The Destination-Host AVP is not present, the Destination-Realm 3078 AVP contains a realm the server is configured to process 3079 locally, and the Diameter application is locally supported, or 3080 - Both the Destination-Host and the Destination-Realm are not 3081 present. 3083 When a request is locally processed, the rules in section 6.2 should 3084 be used to generate the corresponding answer. 3086 6.1.5 Request Forwarding 3088 Request forwarding is done using the Diameter Peer Table. The 3089 Diameter peer table contains all of the peers that the local node is 3090 able to directly communicate with. 3092 When a request is received, and the host encoded in the Destination- 3093 Host AVP is one that is present in the peer table, the message SHOULD 3094 be forwarded to the peer. 3096 6.1.6 Request Routing 3098 Diameter request message routing is done via realms. A Diameter 3099 message that is able to be proxied MUST include the target realm in 3100 the Destination-Realm AVP. The realm MAY be retrieved from the User- 3101 Name AVP, which is in the form of a Network Access Identifier (NAI). 3102 The realm portion of the NAI is inserted in the Destination-Realm 3103 AVP. 3105 Diameter agents MAY have a list of locally supported realms, and MAY 3106 have a list of externally supported realms. When a request is 3107 received that includes a realm that is not locally supported, the 3108 message is routed to the peer configured in the Realm Routing Table 3109 table (see section 2.8). 3111 6.1.7 Redirecting requests 3113 When a redirect agent receives a request whose routing entry is set 3114 to REDIRECT, it MUST reply with an answer message with the 'E' bit 3115 set, while maintaining the Hop-by-Hop Identifier in the header, and 3116 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of 3117 the servers associated with the routing entry are added in separate 3118 Redirect-Host AVP. 3120 +------------------+ 3121 | Diameter | 3122 | Redirect Agent | 3123 +------------------+ 3124 ^ | 2. command + 'E' bit 3125 1. Request | | Result-Code = 3126 joe@xyz.com | | DIAMETER_REDIRECT_INDICATION + 3127 | | Redirect-Host AVP(s) 3128 | v 3129 +---------+ 3. Request +----------+ 3130 | abc.net |------------->| xyz.net | 3131 | Relay | | Diameter | 3132 | Agent |<-------------| Server | 3133 +---------+ 4. Answer +----------+ 3134 Figure 6: Diameter Redirect Agent 3136 Redirect agents MAY also include the certificate of the servers in 3137 the Redirect-Host AVP(s). These certificates are encapsulated in a 3138 AAA-Node-Cert AVP [CMS]. 3140 The receiver of the answer message with the 'E' bit set, and the 3141 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- 3142 hop field in the Diameter header to identify the request in the 3143 pending message queue (see Section 5.3) that is to be redirected. If 3144 no transport connection exists with the new agent, one is created, 3145 and the request is sent directly to it. 3147 Multiple Redirect-Host AVPs are allowed. The receiver of the answer 3148 message with the 'E' bit set selects exactly one of these hosts as 3149 the destination of the redirected message. 3151 6.1.8 Relaying and Proxying Requests 3153 A relay or proxy agent MUST append a Route-Record AVP to all requests 3154 forwarded. The AVP contains the identity of the peer the request was 3155 received from. 3157 The Hop-by-Hop identifier in the request is saved, and replaced with 3158 a locally unique value. The source of the request is also saved, 3159 which includes the IP address, port and protocol. 3161 A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if 3162 it requires access to any local state information when the 3163 corresponding response is received. Alternatively, it MAY simply use 3164 local storage to store state information. 3166 The message is then forwarded to the next hop, as identified in the 3167 Realm Routing Table. 3169 Figure 7 provides an example of message routing using the procedures 3170 listed in these sections. 3172 (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) 3173 (Origin-Realm=mno.net) (Origin-Realm=mno.net) 3174 (Destination-Realm=abc.com) (Destination-Realm=abc.com) 3175 (Route-Record=nas.mno.net) 3176 +------+ ------> +------+ ------> +------+ 3177 | | (Request) | | (Request) | | 3178 | NAS +-------------------+ DRL +-------------------+ HMS | 3179 | | | | | | 3180 +------+ <------ +------+ <------ +------+ 3181 mno.net (Answer) mno.net (Answer) abc.com 3182 (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) 3183 (Origin-Realm=abc.com) (Origin-Realm=abc.com) 3184 Figure 7: Routing of Diameter messages 3186 6.2 Diameter Answer Processing 3188 When a request is locally processed, the following procedures MUST be 3189 applied to create the associated answer, in addition to any 3190 additional procedures that MAY be discussed in the Diameter 3191 application defining the command: 3193 - The same Hop-by-Hop identifier in the request is used in the 3194 answer. 3195 - The local host's identity is encoded in the Origin-Host AVP. 3196 - The Destination-Host and Destination-Realm AVPs MUST NOT be 3197 present in the answer message. 3198 - The Result-Code AVP is added with its value indicating success 3199 or failure. 3200 - If the Session-Id is present in the request, it MUST be included 3201 in the answer. 3202 - Any Proxy-Info AVPs in the request MUST be added to the answer 3203 message, in the same order they were present in the request. 3204 - The 'P' bit is set to the same value as the one in the request. 3205 - The same End-to-End identifier in the request is used in the 3206 answer. 3208 Note that the error messages (see section 7.2) are also subjected to 3209 the above processing rules. 3211 6.2.1 Processing received Answers 3213 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an 3214 answer received against the list of pending requests. The 3215 corresponding message should be removed from the list of pending 3216 requests. It SHOULD ignore answers received that do not match a known 3217 Hop-by-Hop Identifier. 3219 6.2.2 Relaying and Proxying Answers 3221 If the answer is for a request which was proxied or relayed, the 3222 agent MUST restore the original value of the Diameter header's Hop- 3223 by-Hop Identifier field. 3225 If the last Proxy-Info AVP in the message is targeted to the local 3226 Diameter server, the AVP MUST be removed before the answer is 3227 forwarded. 3229 If a relay or proxy agent receives an answer with a Result-Code AVP 3230 indicating a failure, it MUST NOT modify the contents of the AVP. Any 3231 additional local errors detected SHOULD be logged, but not reflected 3232 in the Result-Code AVP. If the agent receives an answer message with 3233 a Result-Code AVP indicating success, and it wishes to modify the AVP 3234 to indicate an error, it MUST modify the Result-Code AVP to contain 3235 the appropriate error in the message destined towards the access 3236 device as well as include the Error-Reporting-Host AVP and it MUST 3237 issue an STR on behalf of the access device. 3239 The agent MUST then send the answer to the host that it received the 3240 original request from. 3242 6.3 Origin-Host AVP 3244 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and 3245 MUST be present in all Diameter messages. This AVP identifies the 3246 endpoint that originated the Diameter message. Relay agents MUST NOT 3247 modify this AVP. 3249 The value of the Origin-Host AVP is guaranteed to be unique within a 3250 single host. 3252 Note that the Origin-Host AVP may resolve to more than one address as 3253 the Diameter peer may support more than one address. 3255 This AVP SHOULD be placed as close to the Diameter header as 3256 possible. 3258 6.4 Origin-Realm AVP 3260 The Origin-Realm AVP (AVP Code 296) is of type UTF8String. This AVP 3261 contains the Realm of the originator of any Diameter message and MUST 3262 be present in all messages. 3264 This AVP SHOULD be placed as close to the Diameter header as 3265 possible. 3267 6.5 Destination-Host AVP 3269 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. 3270 This AVP MUST be present in all unsolicited agent initiated messages, 3271 MAY be present in request messages, and MUST NOT be present in Answer 3272 messages. 3274 The absence of the Destination-Host AVP will cause a message to be 3275 sent to any Diameter server supporting the application within the 3276 realm specified in Destination-Realm AVP. 3278 This AVP SHOULD be placed as close to the Diameter header as 3279 possible. 3281 6.6 Destination-Realm AVP 3283 The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and 3284 contains the realm the message is to be routed to. The Destination- 3285 Realm AVP MUST NOT be present in Answer messages. Diameter Clients 3286 insert the realm portion of the User-Name AVP. Diameter servers 3287 initiating a request message use the value of the Origin-Realm AVP 3288 from a previous message received from the intended target host 3289 (unless it is known a priori). When present, the Destination-Realm 3290 AVP is used to perform message routing decisions. 3292 Request messages whose ABNF does not list the Destination-Realm AVP 3293 as a mandatory AVP are inherently non-routable messages. 3295 This AVP SHOULD be placed as close to the Diameter header as 3296 possible. 3298 6.7 Routing AVPs 3300 The AVPs defined in this section are Diameter AVPs used for routing 3301 purposes. These AVPs change as Diameter messages are processed by 3302 agents, and therefore MUST NOT be protected using the Diameter CMS 3303 Security application [CMS]. 3305 6.7.1 Route-Record AVP 3307 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The 3308 identity added in this AVP MUST be the same as the one received in 3309 the Origin-Host of the Capabilities Exchange message. 3311 6.7.2 Proxy-Info AVP 3313 The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped 3314 Data field has the following ABNF grammar: 3316 Proxy-Info ::= < AVP Header: 284 > 3317 { Proxy-Host } 3318 { Proxy-State } 3319 * [ AVP ] 3321 6.7.3 Proxy-Host AVP 3323 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This 3324 AVP contains the identity of the host that added the Proxy-Info AVP. 3326 6.7.4 Proxy-State AVP 3328 The Proxy-State AVP (AVP Code 33) is of type OctetString, and 3329 contains state local information, and MUST be treated as opaque data. 3331 6.8 Auth-Application-Id AVP 3333 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and 3334 is used in order to advertise support of the Authentication and 3335 Authorization portion of an application (see Section 2.4). The Auth- 3336 Application-Id MUST also be present in all Authentication and/or 3337 Authorization messages that are defined in a separate Diameter 3338 specification and have an Application ID assigned. 3340 This AVP SHOULD be placed as close to the Diameter header as 3341 possible. 3343 6.9 Acct-Application-Id AVP 3345 The Acct-application-Id AVP (AVP Code 259) is of type Unsigned32 and 3346 is used in order to advertise support of the Accounting portion of an 3347 application (see Section 2.4). The Acct-Application-Id MUST also be 3348 present in all Accounting messages that are defined in a separate 3349 Diameter specification and have an Application ID assigned. 3351 This AVP SHOULD be placed as close to the Diameter header as 3352 possible. 3354 6.10 Vendor-Specific-Application-Id AVP 3356 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type 3357 Grouped and is used to advertise support of a vendor-specific 3358 Diameter Application. Either the Auth-Application-Id or the Acct- 3359 Application-Id AVP MAY be present. Exactly one of the Auth- 3360 Application-Id and Acct-Application-Id AVPs MAY be present. 3362 This AVP MUST also be present in all vendor-specific commands defined 3363 in the vendor-specific application. 3365 This AVP SHOULD be placed as close to the Diameter header as 3366 possible. 3368 AVP Format 3370 ::= < AVP Header: 260 > 3371 1* [ Vendor-Id ] 3372 0*1{ Auth-Application-Id } 3373 0*1{ Acct-Application-Id } 3375 6.11 Redirect-Host AVP 3377 One or more of instances of this AVP MUST be present if the answer 3378 message's 'E' bit is set and the Result-Code AVP is set to 3379 DIAMETER_REDIRECT_INDICATION. 3381 Upon receiving the above, the receiving Diameter node SHOULD forward 3382 the request directly to one of the hosts identified in these AVPs. 3383 The server contained in the selected Redirect-Host AVP SHOULD be used 3384 for all messages pertaining to this session. 3386 6.12 Redirect-Host-Usage AVP 3388 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. 3389 This AVP MAY be present in answer messages whose 'E' bit is set and 3390 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3392 When present, this AVP dictates how the routing entry resulting from 3393 the Redirect-Host is to be used. The following values are supported: 3395 DONT_CACHE 0 3396 The host specified in the Redirect-Host AVP should not be 3397 cached. This is the default value. 3399 ALL_SESSION 1 3400 All messages within the same session, as defined by the same 3401 value of the Session-ID AVP MAY be sent to the host specified 3402 in the Redirect-Host AVP. 3404 ALL_REALM 2 3405 All messages destined for the realm requested MAY be sent to 3406 the host specified in the Redirect-Host AVP. 3408 REALM_AND_APPLICATION 3 3409 All messages for the application requested to the realm 3410 specified MAY be sent to the host specified in the Redirect- 3411 Host AVP. 3413 ALL_APPLICATION 4 3414 All messages for the application requested MAY be sent to the 3415 host specified in the Redirect-Host AVP. 3417 ALL_HOST 5 3418 All messages that would be sent to the host that generated the 3419 Redirect-Host MAY be sent to the host specified in the 3420 Redirect-Host AVP. 3422 ALL_USER 6 3423 All messages for the user requested MAY be sent to the host 3424 specified in the Redirect-Host AVP. 3426 6.13 Redirect-Max-Cache-Time AVP 3428 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. 3429 This AVP MUST be present in answer messages whose 'E' bit is set, the 3430 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 3431 Redirect-Host-Usage AVP set to a non-zero value. 3433 This AVP contains the maximum number of seconds the peer and route 3434 table entries, created as a result of the Redirect-Host, will be 3435 cached. Note that once a host created due to a redirect indication is 3436 no longer reachable, any associated peer and routing table entries 3437 MUST be deleted. 3439 7 Error Handling 3441 There are two different types of errors in Diameter; protocol and 3442 application errors. A protocol error is one that occurs at the base 3443 protocol level, and MAY require per hop attention (e.g. message 3444 routing error). Application errors, on the other hand, are generally 3445 occur due to a problem with a function specified in a Diameter 3446 application (e.g. user authentication, Missing AVP). 3448 Result-Code AVP values that are used to report protocol errors MUST 3449 only be present in answer messages whose 'E' bit is set. When a 3450 request message is received that causes a protocol error, an answer 3451 message is returned with the 'E' bit set, and the Result-Code AVP is 3452 set to the appropriate protocol error value. As the answer is sent 3453 back towards the originator of the request, each proxy or relay agent 3454 MAY take action on the message. 3456 1. Request +---------+ Link Broken 3457 +-------------------------->|Diameter |----///----+ 3458 | +---------------------| | v 3459 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+ 3460 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| 3461 | | | Home | 3462 | Relay 1 |--+ +---------+ | Server | 3463 +---------+ | 3. Request |Diameter | +--------+ 3464 +-------------------->| | ^ 3465 | Relay 3 |-----------+ 3466 +---------+ 3467 Figure 8: Example of Protocol Error causing answer message 3469 Figure 8 provides an example of a message forwarded upstream by a 3470 Diameter relay. When the message is received by Relay 2, and it 3471 detects that it cannot forward the request to the home server, an 3472 answer message is returned with the 'E' bit set and the Result-Code 3473 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls 3474 within the protocol error category, Relay 1 would take special 3475 action, and given the error, attempt to route the message through its 3476 alternate Relay 3. 3478 +---------+ 1. Request +---------+ 2. Request +---------+ 3479 | Access |------------>|Diameter |------------>|Diameter | 3480 | | | | | Home | 3481 | Device |<------------| Relay |<------------| Server | 3482 +---------+ 4. Answer +---------+ 3. Answer +---------+ 3483 (Missing AVP) (Missing AVP) 3484 Figure 9: Example of Application Error Answer message 3486 Figure 9 provides an example of a Diameter message that caused an 3487 application error. When application errors occur, the Diameter entity 3488 reporting the error clears the 'R' bit in the Command Flags, and adds 3489 the Result-Code AVP with the proper value. Application errors do not 3490 require any proxy or relay agent involvement, and therefore the 3491 message would be forwarded back to the originator of the request. 3493 There are certain Result-Code AVP application errors that require 3494 additional AVPs to be present in the answer. In these cases, the 3495 Diameter node that sets the Result-Code AVP to indicate the error 3496 MUST add the AVPs. Examples are: 3498 - An unrecognized AVP is received with the 'M' bit (Mandatory bit) 3499 set, causes an answer to be sent with the Result-Code AVP set to 3500 DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the 3501 offending AVP. 3502 - An AVP that is received with an unrecognized value causes an 3503 answer to be returned with the Result-Code AVP set to 3504 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing 3505 the AVP causing the error. 3506 - A command is received with an AVP that is omitted, yet is 3507 mandatory according to the command's ABNF. The receiver issues 3508 an answer with the Result-Code set to DIAMETER_MISSING_AVP, and 3509 creates an AVP with the AVP Code and other fields set as 3510 expected in the missing AVP. The created AVP is then added to 3511 the Failed-AVP AVP. 3513 The Result-Code AVP contains additional errors conditions, and 3514 defines the expected behavior of each. 3516 7.1 Result-Code AVP 3518 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 3519 indicates whether a particular request was completed successfully or 3520 whether an error occurred. All Diameter answer messages MUST include 3521 one Result-Code AVP. A non-successful Result-Code AVP (one containing 3522 a non 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST 3523 include the Error-Reporting-Host AVP if the host setting the Result- 3524 Code AVP is different from the identity encoded in the Origin-Host 3525 AVP. 3527 The Result-Code data field contains an IANA-managed 32-bit address 3528 space representing errors (see section 11.4). Diameter provides the 3529 following classes of errors, all identified by the thousands digit in 3530 the decimal notation: 3531 - 1xxx (Informational) 3532 - 2xxx (Success) 3533 - 3xxx (Protocol Errors) 3534 - 4xxx (Transient Failures) 3535 - 5xxx (Permanent Failure) 3537 A non-recognize class (one whose first digit is not defined in this 3538 section) MUST be handled as a permanent failure. 3540 7.1.1 Informational 3542 Errors that fall within this category are used to inform the 3543 requester that a request could not be satisfied, and additional 3544 action is required on its part before access is granted. 3546 DIAMETER_MULTI_ROUND_AUTH 1001 3547 This informational error is returned by a Diameter server to 3548 inform the access device that the authentication mechanism 3549 being used required multiple round trips, and a subsequent 3550 request needs to be issued in order for access to be granted. 3552 7.1.2 Success 3554 Errors that fall within the Success category are used to inform a 3555 peer that a request has been successfully completed. 3557 DIAMETER_SUCCESS 2001 3558 The Request was successfully completed. 3560 DIAMETER_LIMITED_SUCCESS 2002 3561 When returned, the request was successfully completed, but 3562 additional processing is required by the application in order 3563 to provide service to the user. 3565 7.1.3 Protocol Errors 3567 Errors that fall within the Protocol Error category SHOULD be treated 3568 on a per-hop basis, and Diameter proxies MAY attempt to correct the 3569 error, if it is possible. Note that these and only these errors MUST 3570 only be used in answer messages whose 'E' bit is set. 3572 DIAMETER_COMMAND_UNSUPPORTED 3001 3573 The Request contained a Command-Code that the receiver did not 3574 recognize or support. 3576 DIAMETER_UNABLE_TO_DELIVER 3002 3577 This error is given when Diameter can not deliver the message 3578 to the destination, either because no host within the realm was 3579 available to process the request, or because Destination-Host 3580 AVP was given without the associated Destination-Realm AVP. 3582 DIAMETER_REALM_NOT_SERVED 3003 3583 The intended realm of the request is not recognized. 3585 DIAMETER_TOO_BUSY 3004 3586 When returned, a Diameter node SHOULD attempt to send the 3587 message to an alternate peer. This error MUST only be used when 3588 a specific server is requested, and it cannot provide the 3589 requested service. 3591 DIAMETER_LOOP_DETECTED 3005 3592 An agent detected a loop while trying to get the message to the 3593 intended recipient. The message MAY be sent to an alternate 3594 peer, if one is available, but the peer reporting the error has 3595 identified a configuration problem. 3597 DIAMETER_REDIRECT_INDICATION 3006 3598 A redirect agent has determined that the request could not be 3599 satisfied locally and the initiator of the request should 3600 direct the request directly to the server, whose contact 3601 information has been added to the response. When set, the 3602 Redirect-Host AVP MUST be present. 3604 DIAMETER_APPLICATION_UNSUPPORTED 3007 3605 A request was sent for an application that is not supported. 3607 DIAMETER_INVALID_HDR_BITS 3008 3608 A request was received whose bits in the Diameter header were 3609 either set to an invalid combination, or to a value that is 3610 inconsistent with the command code's definition. 3612 DIAMETER_INVALID_AVP_BITS 3009 3613 A request was received that included an AVP whose flag bits are 3614 set to an unrecognized value, or that is inconsistent with the 3615 AVP's definition. 3617 DIAMETER_UNKNOWN_PEER 3010 3618 A CER was received from an unknown peer. 3620 7.1.4 Transient Failures 3622 Errors that fall within the transient failures category are used to 3623 inform a peer that the request could not be satisfied at the time it 3624 was received, but MAY be able to satisfy the request in the future. 3626 DIAMETER_AUTHENTICATION_REJECTED 4001 3627 The authentication process for the user failed, most likely due 3628 to an invalid password used by the user. Further attempts MUST 3629 only be tried after prompting the user for a new password. 3631 DIAMETER_OUT_OF_SPACE 4002 3632 A Diameter node received the accounting request but was unable 3633 to commit it to stable storage due to a temporary lack of 3634 space. 3636 ELECTION_LOST 4003 3637 The peer has determined that it has lost the election process 3638 and has therefore disconnected the transport connection. 3640 7.1.5 Permanent Failures 3642 Errors that fall within the permanent failures category are used to 3643 inform the peer that the request failed, and should not be attempted 3644 again. 3646 DIAMETER_AVP_UNSUPPORTED 5001 3647 The peer received a message that contained an AVP that is not 3648 recognized or supported and was marked with the Mandatory bit. 3649 A Diameter message with this error MUST contain one or more 3650 Failed-AVP AVP containing the AVPs that caused the failure. 3652 DIAMETER_UNKNOWN_SESSION_ID 5002 3653 The request contained an unknown Session-Id. 3655 DIAMETER_AUTHORIZATION_REJECTED 5003 3656 A request was received for which the user could not be 3657 authorized. This error could occur if the service requested is 3658 not permitted to the user. 3660 DIAMETER_INVALID_AVP_VALUE 5004 3661 The request contained an AVP with an invalid value in its data 3662 portion. A Diameter message indicating this error MUST include 3663 the offending AVPs within a Failed-AVP AVP. 3665 DIAMETER_MISSING_AVP 5005 3666 The request did not contain an AVP that is required by the 3667 Command Code definition. If this value is sent in the Result- 3668 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 3669 The Failed-AVP AVP MUST contain an example of the missing AVP 3670 complete with the Vendor-Id if applicable. The value field of 3671 the missing AVP should be of correct minimum length and contain 3672 zeroes. 3674 DIAMETER_RESOURCES_EXCEEDED 5006 3675 A request was received that cannot be authorized because the 3676 user has already expended allowed resources. An example of this 3677 error condition is a user that is restricted to one dial-up PPP 3678 port, attempts to establish a second PPP connection. 3680 DIAMETER_CONTRADICTING_AVPS 5007 3681 The Home Diameter server has detected AVPs in the request that 3682 contradicted each other, and is not willing to provide service 3683 to the user. One or more Failed-AVP AVPs MUST be present, 3684 containing the AVPs that contradicted each other. 3686 DIAMETER_AVP_NOT_ALLOWED 5008 3687 A message was received with an AVP that MUST NOT be present. 3688 The Failed-AVP AVP MUST be included and contain a copy of the 3689 offending AVP. 3691 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 3692 A message was received that included an AVP that appeared more 3693 often than permitted in the message definition. The Failed-AVP 3694 AVP MUST be included and contain a copy of the first instance 3695 of the offending AVP that exceeded the maximum number of 3696 occurrences 3698 DIAMETER_UNSUPPORTED_TRANSFORM 5010 3699 A message was received that included a CMS-Data AVP [CMS] that 3700 made use of an unsupported transform. 3702 DIAMETER_NO_COMMON_APPLICATION 5011 3703 This error is returned when a CER message is received, and 3704 there are no common applications supported between the peers. 3706 DIAMETER_UNSUPPORTED_VERSION 5012 3707 This error is returned when a request was received, whose 3708 version number is unsupported. 3710 DIAMETER_UNABLE_TO_COMPLY 5013 3711 This error is returned when a request is rejected for 3712 unspecified reasons. 3714 DIAMETER_INVALID_BIT_IN_HEADER 5014 3715 This error is returned when an unrecognized bit in the Diameter 3716 header is set to one (1). 3718 DIAMETER_INVALID_AVP_LENGTH 5015 3719 The request contained an AVP with an invalid length. A Diameter 3720 message indicating this error MUST include the offending AVPs 3721 within a Failed-AVP AVP. 3723 DIAMETER_INVALID_MESSAGE_LENGTH 5016 3724 This error is returned when a request is received with an 3725 invalid message length. 3727 DIAMETER_INVALID_AVP_BIT_COMBO 5017 3728 The request contained an AVP with which is not allowed to have 3729 the given value in the AVP Flags field. A Diameter message 3730 indicating this error MUST include the offending AVPs within a 3731 Failed-AVP AVP. 3733 7.2 Error Bit 3735 The 'E' (Error Bit) in the Diameter header is set when the request 3736 caused a protocol-related error (see section 7.1.3). A message with 3737 the 'E' bit MUST NOT be sent as a response to an answer message. Note 3738 that a message with the 'E' bit set is still subjected to the 3739 processing rules defined in section 6.2. When set, the answer message 3740 will not conform to the ABNF specification for the command, and will 3741 instead conform to the following ABNF: 3743 Message Format 3745 ::= < Diameter Header: code, ERR [PXY] > 3746 0*1< Session-Id > 3747 { Origin-Host } 3748 { Origin-Realm } 3749 { Result-Code } 3750 [ Origin-State-Id ] 3751 [ Error-Reporting-Host ] 3752 [ Proxy-Info ] 3753 * [ AVP ] 3755 Note that the code used in the header is the same that the one found 3756 in the request message, but with the 'R' bit cleared and the 'E' bit 3757 set. The 'P' bit in the header is set to the same value as the one 3758 found in the request message. 3760 7.3 Error-Message AVP 3762 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY 3763 accompany a Result-Code AVP as a human readable error message. The 3764 Error-Message AVP is not intended to be useful in real-time, and 3765 SHOULD NOT be expected to be parsed by network entities. 3767 7.4 Error-Reporting-Host AVP 3769 The Error-Reporting-Host AVP (AVP Code 294) is of type 3770 DiameterIdentity. This AVP contains the identity of the Diameter host 3771 that sent the Result-Code AVP to a value other than 2001 (Success), 3772 only if the host setting the Result-Code is different from the one 3773 encoded in the Origin-Host AVP. This AVP is intended to be used for 3774 troubleshooting purposes, and MUST be set when the Result-Code AVP 3775 indicates a failure. 3777 7.5 Failed-AVP AVP 3779 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides 3780 debugging information in cases where a request is rejected or not 3781 fully processed due to erroneous information in a specific AVP. The 3782 value of the Result-Code AVP will provide information on the reason 3783 for the Failed-AVP AVP. 3785 The possible reasons for this AVP are the presence of an improperly 3786 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 3787 value, the omission of a required AVP, the presence of an explicitly 3788 excluded AVP (see tables in section 10), or the presence of two or 3789 more occurrences of an AVP which is restricted to 0, 1, or 0-1 3790 occurrences. 3792 A Diameter message MAY contain one Failed-AVP AVP, containing the 3793 entire AVP that could not be processed successfully. If the failure 3794 reason is omission of a required AVP, an AVP with the missing AVP 3795 code, the missing vendor id, and a zero filled payload of the minimum 3796 required length for the omitted AVP will be added. 3798 AVP Format 3800 ::= < AVP Header: 279 > 3801 1* {AVP} 3803 8 Diameter User Sessions 3804 Diameter can provide two different types of services to applications. 3805 The first involves authentication and authorization, and can 3806 optionally make use of accounting. The second only makes use of 3807 accounting. 3809 When a service makes use of the authentication and/or authorization 3810 portion of an application, and a user requests access to the network, 3811 the Diameter client issues an auth request to its local server. The 3812 auth request is defined in a service specific Diameter application 3813 (e.g. NASREQ). The request contains a Session-Id AVP, which is used 3814 in subsequent messages (e.g. subsequent authorization, accounting, 3815 etc) relating to the user's session. The Session-Id AVP is a means 3816 for the client and servers to correlate a Diameter message with a 3817 user session. 3819 When a Diameter server authorizes a user to use network resources for 3820 a finite amount of time, and it is willing to extend the 3821 authorization via a future request, it MUST add the Authorization- 3822 Lifetime AVP to the answer message. The Authorization-Lifetime AVP 3823 defines the maximum number of seconds a user MAY make use of the 3824 resources before another authorization request is expected by the 3825 server. The Auth-Grace-Period AVP contains the number of seconds 3826 following the expiration of the Authorization-Lifetime, after which 3827 the server will release all state information related to the user's 3828 session. Note that if payment for services is expected by the serving 3829 realm from the user's home realm, the Authorization-Lifetime AVP, 3830 combined with the Auth-Grace-Period AVP, implies the maximum length 3831 of the session the home realm is willing to be fiscally responsible 3832 for. Services provided past the expiration of the Authorization- 3833 Lifetime and Auth-Grace-Period AVPs are the responsibility of the 3834 access device. Of course, the actual cost of services rendered is 3835 clearly outside the scope of the protocol. 3837 An access device that does not expect to send a re-authorization or a 3838 session termination request to the server MAY include the Auth- 3839 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint 3840 to the server. If the server accepts the hint, it agrees that since 3841 no session termination message will be received once service to the 3842 user is terminated, it cannot maintain state for the session. If the 3843 answer message from the server contains a different value in the 3844 Auth-Session-State AVP (or the default value if the AVP is absent), 3845 the access device MUST follow the server's directives. Note that the 3846 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re- 3847 authorization requests and answers. 3849 The base protocol does not include any authorization request 3850 messages, since these are largely application-specific and are 3851 defined in a Diameter application document. However, the base 3852 protocol does define a set of messages that is used to terminate user 3853 sessions. These are used to allow servers that maintain state 3854 information to free resources. 3856 When a service only makes use of the Accounting portion of the 3857 Diameter protocol, even in combination with an application, the 3858 Session-Id is still used to identify user sessions. However, the 3859 session termination messages are not used, since a session is 3860 signaled as being terminated by issuing an accounting stop message. 3862 8.1 Authorization Session State Machine 3864 This section contains a set of finite state machines, representing 3865 the life cycle of Diameter sessions, and which MUST be observed by 3866 all Diameter implementations that make use of the authentication 3867 and/or authorization portion of a Diameter application. The term 3868 Service-Specific below refers to a message defined in a Diameter 3869 application (e.g. Mobile IP, NASREQ). 3871 There are four different authorization session state machines 3872 supported in the Diameter base protocol. The first two describe a 3873 session in which the server is maintaining session state, indicated 3874 by the value of the Auth-Session-State AVP (or its absence). One 3875 describes the session from a client perspective, the other from a 3876 server perspective. The second two state machines are used when the 3877 server does not maintain session state. Here again, one describes the 3878 session from a client perspective, the other from a server 3879 perspective. 3881 When a session is moved to the Idle state, any resources that were 3882 allocated for the particular session must be released. Any event not 3883 listed in the state machines MUST be considered as an error 3884 condition, and an answer, if applicable, MUST be returned to the 3885 originator of the message. 3887 In the state table, the event 'Failure to send X' means that the 3888 Diameter agent is unable to send command X to the desired 3889 destination. This could be due to the peer being down, or due to the 3890 peer sending back a transient failure or temporary protocol error 3891 notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the 3892 Result-Code AVP of the corresponding Answer command. The event 'X 3893 successfully sent' is the complement of 'Failure to send X'. 3895 The following state machine is observed by a client when state is 3896 maintained on the server: 3898 CLIENT, STATEFUL 3899 State Event Action New State 3900 ------------------------------------------------------------- 3901 Idle Client or Device Requests Send Pending 3902 access service 3903 specific 3904 auth req 3906 Idle ASR Received Send ASA Idle 3907 for unknown session with 3908 Result-Code 3909 = UNKNOWN_ 3910 SESSION_ID 3912 Pending Successful Service-specific Grant Open 3913 authorization answer Access 3914 received with default 3915 Auth-Session-State value 3917 Pending Successful Service-specific Sent STR Discon 3918 authorization answer received 3919 but service not provided 3921 Pending Error processing successful Sent STR Discon 3922 Service-specific authorization 3923 answer 3925 Pending Failed Service-specific Cleanup Idle 3926 authorization answer received 3928 Open user or client device Send Open 3929 requests access to service service 3930 specific 3931 auth req 3933 Open Successful Service-specific Extend Open 3934 authorization answer received Answer 3936 Open Failed Service-specific Discon. Idle 3937 authorization answer user/device 3938 received. 3940 Open Session-Timeout Expires on Send STR Discon 3941 Access Device 3943 Open ASR Received, Send ASA Discon 3944 client will comply with with 3945 request to end the session Result-Code 3946 = SUCCESS, 3947 Send STR. 3949 Open ASR Received, Send ASA Open 3950 client will not comply with with 3951 request to end the session Result-Code 3952 != SUCCESS 3954 Open Authorization-Lifetime + Send STR Discon 3955 Auth-Grace-Period expires on 3956 access device 3958 Discon ASR Received Send ASA Discon 3960 Discon STA Received Discon. Idle 3961 user/device 3963 The following state machine is observed by a server when it is 3964 maintaining state for the session: 3966 SERVER, STATEFUL 3967 State Event Action New State 3968 ------------------------------------------------------------- 3969 Idle Service-specific authorization Send Open 3970 request received, and successful 3971 user is authorized serv. 3972 specific answer 3974 Idle Service-specific authorization Send Idle 3975 request received, and failed serv. 3976 user is not authorized specific answer 3978 Open Service-specific authorization Send Open 3979 request received, and user successful 3980 is authorized serv. specific 3981 answer 3983 Open Service-specific authorization Send Idle 3984 request received, and user failed serv. 3985 is not authorized specific 3986 answer, 3987 Cleanup 3989 Open Home server wants to Send ASR Discon 3990 terminate the service 3992 Open Authorization-Lifetime (and Cleanup Idle 3993 Auth-Grace-Period) expires 3994 on home server. 3996 Open Session-Timeout expires on Cleanup Idle 3997 home server 3999 Discon Failure to send ASR Wait, Discon 4000 resend ASR 4002 Discon ASR successfully sent and Cleanup Idle 4003 ASA Received with Result-Code 4005 Not ASA Received None No Change. 4006 Discon 4008 Any STR Received Send STA, Idle 4009 Cleanup. 4010 fi 4012 The following state machine is observed by a client when state is not 4013 maintained on the server: 4015 CLIENT, STATELESS 4016 State Event Action New State 4017 ------------------------------------------------------------- 4018 Idle Client or Device Requests Send Pending 4019 access service 4020 specific 4021 auth req 4023 Pending Successful Service-specific Grant Open 4024 authorization answer Access 4025 received with Auth-Session- 4026 State set to 4027 NO_STATE_MAINTAINED 4029 Pending Failed Service-specific Cleanup Idle 4030 authorization answer 4031 received 4033 Open Session-Timeout Expires on Discon. Idle 4034 Access Device user/device 4036 Open Service to user is terminated Discon. Idle 4037 user/device 4039 The following state machine is observed by a server when it is not 4040 maintaining state for the session: 4042 SERVER, STATELESS 4043 State Event Action New State 4044 ------------------------------------------------------------- 4045 Idle Service-specific authorization Send serv. Idle 4046 request received, and specific 4047 successfully processed answer 4049 8.2 Accounting Session State Machine 4051 The following state machines MUST be supported for applications that 4052 have an accounting portion or that require only accounting services. 4053 The first state machine is to be observed by clients. 4055 The server side in the accounting state machine depends in some cases 4056 on the particular application. The Diameter base protocol defines a 4057 default state machine that MUST be followed by accounting servers 4058 advertising support for the Relay application identifier and all 4059 applications that have not specified other state machines. This is 4060 the second state machine in this section described below. 4062 The default server side state machine requires the reception of 4063 accounting records in any order and at any time, and does not place 4064 any standards requirement on the processing of these records. 4065 Implementations of Diameter MAY perform checking, ordering, 4066 correlation, fraud detection, and other tasks based on these records. 4067 Both base Diameter AVPs as well as application specific AVPs MAY be 4068 inspected as a part of these tasks. The tasks can happen either 4069 immediately after record reception or in a post-processing phase. 4070 However, as these tasks are typically application or even policy 4071 dependent, they are not standardized by the Diameter specifications. 4072 Applications MAY define requirements on when to accept accounting 4073 records based on the used value of Accounting-Realtime-Required AVP, 4074 credit limits checks, and so on. 4076 However, the Diameter base protocol defines one optional server side 4077 state machine that MAY be followed by applications that require 4078 keeping track of the session state at the accounting server. Note 4079 that such tracking is incompatible with the ability to sustain long 4080 duration connectivity problems. Theferore, the use of this state 4081 machine is recommended only in applications where the value of the 4082 Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence 4083 accounting connectivity problems are required to cause the serviced 4084 user to be disconnected. Otherwise, records produced by the client 4085 may be lost by the server which no longer accepts them after the 4086 connectivity is re-established. This state machine is the third state 4087 machine in this section. The state machine is supervised by a 4088 supervision session timer Ts, which the value should be reasonably 4089 higher than the Interim_Record_Interval value. Ts MAY be set to two 4090 times the value of the Interim_Record_Interval so as to avoid the 4091 accounting session in the Diameter server to change to Idle state in 4092 case of short transient network failure. 4094 Any event not listed in the state machines MUST be considered as an 4095 error condition, and a corresponding answer, if applicable, MUST be 4096 returned to the originator of the message. 4098 In the state table, the event 'Failure to send' means that the 4099 Diameter client is unable to communicate with the desired 4100 destination. This could be due to the peer being down, or due to the 4101 peer sending back a transient failure or temporary protocol error 4102 notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or 4103 DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting 4104 Answer command. 4106 The event 'Failed answer' means that the Diameter client received a 4107 non-transient failure notification in the Accounting Answer command. 4109 Note that the action 'Disconnect user/dev' MUST have an effect also 4110 to the authorization session state table, e.g. cause the STR message 4111 to be sent, if the given application has both 4112 authentication/authorization and accounting portions. 4114 The states PendingS, PendingI, PendingL, PendingE and PendingB stand 4115 for pending states to wait for an answer to an accounting request 4116 related to a Start, Interim, Stop, Event or buffered record, 4117 respectively. 4119 Note that the server side state machine requires the reception of 4120 accounting records and does not place any standard requirements on 4121 the processing of these records. Implementations of Diameter MAY 4122 perform checking, ordering, correlation, fraud detection and other 4123 tasks based on these records. Both base Diameter AVPs as well as 4124 application specific AVPs MAY be inspected as a part of these tasks. 4125 The tasks can happen either immediately after record reception or in 4126 a post-processing phase. However, as these tasks are typically 4127 application or even policy dependent, they are not standardized by 4128 the Diameter specifications. 4130 CLIENT, ACCOUNTING 4131 State Event Action New State 4132 ------------------------------------------------------------- 4133 Idle Client or device requests Send PendingS 4134 access accounting 4135 start req. 4137 Idle Client or device requests Send PendingE 4138 a one-time service accounting 4139 event req 4141 Idle Records in storage Send PendingB 4142 record 4144 PendingS Successful accounting Open 4145 start answer received 4147 PendingS Failure to send and buffer Store Open 4148 space available and realtime Start 4149 not equal to DELIVER_AND_GRANT Record 4151 PendingS Failure to send and no buffer Open 4152 space available and realtime 4153 equal to GRANT_AND_LOSE 4155 PendingS Failure to send and no buffer Disconnect Idle 4156 space available and realtime user/dev 4157 not equal to 4158 GRANT_AND_LOSE 4160 PendingS Failed accounting start answer Open 4161 received and realtime equal 4162 to GRANT_AND_LOSE 4164 PendingS Failed accounting start answer Disconnect Idle 4165 received and realtime not user/dev 4166 equal to GRANT_AND_LOSE 4168 PendingS User service terminated Store PendingS 4169 stop 4170 record 4172 Open Interim interval elapses Send PendingI 4173 accounting 4174 interim 4175 record 4177 Open User service terminated Send PendingL 4178 accounting 4179 stop req. 4181 PendingI Successful accounting interim Open 4182 answer received 4184 PendingI Failure to send and (buffer Store Open 4185 space available or old record interim 4186 can be overwritten) and record 4187 realtime not equal to 4188 DELIVER_AND_GRANT 4190 PendingI Failure to send and no buffer Open 4191 space available and realtime 4192 equal to GRANT_AND_LOSE 4194 PendingI Failure to send and no buffer Disconnect Idle 4195 space available and realtime user/dev 4196 not equal to GRANT_AND_LOSE 4198 PendingI Failed accounting interim Open 4199 answer received and realtime 4200 equal to GRANT_AND_LOSE 4202 PendingI Failed accounting interim Disconnect Idle 4203 answer received and realtime user/dev 4204 not equal to GRANT_AND_LOSE 4206 PendingI User service terminated Store PendingI 4207 stop 4208 record 4210 PendingE Successful accounting Idle 4211 event answer received 4213 PendingE Failure to send and buffer Store Idle 4214 space available event 4215 record 4217 PendingE Failure to send and no buffer Idle 4218 space available 4220 PendingE Failed accounting event answer Idle 4221 received 4223 PendingB Successful accounting answer Delete Idle 4224 received record 4226 PendingB Failure to send Idle 4228 PendingB Failed accounting answer Delete Idle 4229 received record 4231 PendingL Successful accounting Idle 4232 stop answer received 4234 PendingL Failure to send and buffer Store Idle 4235 space available stop 4236 record 4238 PendingL Failure to send and no buffer Idle 4239 space available 4241 PendingL Failed accounting stop answer Idle 4242 received 4244 SERVER, STATELESS ACCOUNTING 4245 State Event Action New State 4246 ------------------------------------------------------------- 4248 Idle Accounting start request Send Idle 4249 received, and successfully accounting 4250 processed. start 4251 answer 4253 Idle Accounting event request Send Idle 4254 received, and successfully accounting 4255 processed. event 4256 answer 4258 Idle Interim record received, Send Idle 4259 and successfully processed. accounting 4260 answer 4262 Idle Accounting stop request Send Idle 4263 received, and successfully accounting 4264 processed stop answer 4266 Idle Accounting request received, Send Idle 4267 no space left to store accounting 4268 records answer, 4269 Result-Code 4270 = OUT_OF_ 4271 SPACE 4273 SERVER, STATEFUL ACCOUNTING 4274 State Event Action New State 4275 ------------------------------------------------------------- 4277 Idle Accounting start request Send Open 4278 received, and successfully accounting 4279 processed. start 4280 answer, 4281 Start Ts 4283 Idle Accounting event request Send Idle 4284 received, and successfully accounting 4285 processed. event 4286 answer 4288 Idle Accounting request received, Send Idle 4289 no space left to store accounting 4290 records answer, 4291 Result-Code 4292 = OUT_OF_ 4293 SPACE 4295 Open Interim record received, Send Open 4296 and successfully processed. accounting 4297 answer, 4298 Restart Ts 4300 Open Accounting stop request Send Idle 4301 received, and successfully accounting 4302 processed stop answer, 4303 Stop Ts 4305 Open Accounting request received, Send Idle 4306 no space left to store accounting 4307 records answer, 4308 Result-Code 4309 = OUT_OF_ 4310 SPACE, 4311 Stop Ts 4313 Open Session supervision timer Ts Stop Ts Idle 4314 expired 4316 8.3 Server-Initiated Re-Auth 4318 A Diameter server may initiate a re-authentication and/or re- 4319 authorization service for a particular session by issuing a Re-Auth- 4320 Request (RAR). 4322 For example, for pre-paid services, the Diameter server that 4323 originally authorized a session may need some confirmation that the 4324 user is still using the services. 4326 An access device that receives a RAR message with Session-Id equal to 4327 a currently active session MUST initiate a re-auth towards the user, 4328 if the service supports this particular feature. Each Diameter 4329 application MUST state whether service-initiated re-auth is 4330 supported, since some applications do not allow access devices to 4331 prompt the user for re-auth. 4333 8.3.1 Re-Auth-Request 4335 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 4336 and the message flags' 'R' bit set, may be sent by any server to the 4337 access device that is providing session service, to request that the 4338 user be re-authenticated and/or re-authorized. 4340 Message Format 4342 ::= < Diameter Header: 258, REQ, PXY > 4343 < Session-Id > 4344 { Origin-Host } 4345 { Origin-Realm } 4346 { Destination-Realm } 4347 { Destination-Host } 4348 { Auth-Application-Id } 4349 { Re-Auth-Request-Type } 4350 [ User-Name ] 4351 [ Origin-State-Id ] 4352 * [ AVP ] 4353 * [ Proxy-Info ] 4354 * [ Route-Record ] 4356 8.3.2 Re-Auth-Answer 4358 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 4359 and the message flags' 'R' bit clear, is sent in response to the RAR. 4360 The Result-Code AVP MUST be present, and indicates the disposition of 4361 the request. 4363 A successful RAA message MUST be followed by an application-specific 4364 authentication and/or authorization message. 4366 Message Format 4368 ::= < Diameter Header: 258, PXY > 4369 < Session-Id > 4370 { Result-Code } 4371 { Origin-Host } 4372 { Origin-Realm } 4373 [ User-Name ] 4374 [ Origin-State-Id ] 4375 [ Error-Message ] 4376 [ Error-Reporting-Host ] 4377 * [ Failed-AVP ] 4378 * [ Redirected-Host ] 4379 [ Redirected-Host-Usage ] 4380 [ Redirected-Host-Cache-Time ] 4381 * [ AVP ] 4382 * [ Proxy-Info ] 4384 8.4 Session Termination 4386 It is necessary for a Diameter server that authorized a session, for 4387 which it is maintaining state, to be notified when that session is no 4388 longer active, both for tracking purposes as well as to allow 4389 stateful agents to release any resources that they may have provided 4390 for the user's session. For sessions whose state is not being 4391 maintained, this section is not used. 4393 When a user session that required Diameter authorization terminates, 4394 the access device that provided the service MUST issue a Session- 4395 Termination-Request (STR) message to the Diameter server that 4396 authorized the service, to notify it that the session is no longer 4397 active. An STR MUST be issued when a user session terminates for any 4398 reason, including user logoff, expiration of Session-Timeout, 4399 administrative action, termination upon receipt of an Abort-Session- 4400 Request (see below), orderly shutdown of the access device, etc. 4402 The access device also MUST issue an STR for a session that was 4403 authorized but never actually started. This could occur, for example, 4404 due to a sudden resource shortage in the access device, or because 4405 the access device is unwilling to provide the type of service 4406 requested in the authorization, or because the access device does not 4407 support a mandatory AVP returned in the authorization, etc. 4409 It is also possible that a session that was authorized is never 4410 actually started due to action of a proxy. For example, a proxy may 4411 modify an authorization answer, converting the result from success to 4412 failure, prior to forwarding the message to the access device. If the 4413 answer did not contain an Auth-Session-State AVP with the value 4414 NO_STATE_MAINTAINED, a proxy that causes an authorized session not to 4415 be started MUST issue an STR to the Diameter server that authorized 4416 the session, since the access device has no way of knowing that the 4417 session had been authorized. 4419 A Diameter server that receives an STR message MUST clean up 4420 resources (e.g., session state) associated with the Session-Id 4421 specified in the STR, and return a Session-Termination-Answer. 4423 A Diameter server also MUST clean up resources when the Session- 4424 Timeout expires, or when the Authorization-Lifetime and the Auth- 4425 Grace-Period AVPs expires without receipt of a re-authorization 4426 request, regardless of whether an STR for that session is received. 4427 The access device is not expected to provide service beyond the 4428 expiration of these timers; thus, expiration of either of these 4429 timers implies that the access device may have unexpectedly shut 4430 down. 4432 8.4.1 Session-Termination-Request 4434 The Session-Termination-Request (STR), indicated by the Command-Code 4435 set to 275 and the Command Flags' 'R' bit set, is sent by the access 4436 device to inform the Diameter Server that an authenticated and/or 4437 authorized session is being terminated. 4439 Message Format 4441 ::= < Diameter Header: 275, REQ, PXY > 4442 < Session-Id > 4443 { Origin-Host } 4444 { Origin-Realm } 4445 { Destination-Realm } 4446 { Auth-Application-Id } 4447 { Termination-Cause } 4448 [ User-Name ] 4449 [ Destination-Host ] 4450 * [ Class ] 4451 [ Origin-State-Id ] 4452 * [ AVP ] 4453 * [ Proxy-Info ] 4454 * [ Route-Record ] 4456 8.4.2 Session-Termination-Answer 4458 The Session-Termination-Answer (STA), indicated by the Command-Code 4459 set to 275 and the message flags' 'R' bit clear, is sent by the 4460 Diameter Server to acknowledge the notification that the session has 4461 been terminated. The Result-Code AVP MUST be present, and MAY contain 4462 an indication that an error occurred while servicing the STR. 4464 Upon sending or receipt of the STA, the Diameter Server MUST release 4465 all resources for the session indicated by the Session-Id AVP. Any 4466 intermediate server in the Proxy-Chain MAY also release any 4467 resources, if necessary. 4469 Message Format 4471 ::= < Diameter Header: 275, PXY > 4472 < Session-Id > 4473 { Result-Code } 4474 { Origin-Host } 4475 { Origin-Realm } 4476 [ User-Name ] 4477 * [ Class ] 4478 [ Error-Message ] 4479 [ Error-Reporting-Host ] 4480 * [ Failed-AVP ] 4481 [ Origin-State-Id ] 4482 * [ Redirect-Host ] 4483 [ Redirect-Host-Usase ] 4484 [ Redirect-Max-Cache-Time ] 4485 * [ AVP ] 4486 * [ Proxy-Info ] 4488 8.5 Aborting a Session 4490 A Diameter server may request that the access device stop providing 4491 service for a particular session by issuing an Abort-Session-Request 4492 (ASR). 4494 For example, the Diameter server that originally authorized the 4495 session may be required to cause that session to be stopped for 4496 credit or other reasons that were not anticipated when the session 4497 was first authorized. On the other hand, an operator may maintain a 4498 management server for the purpose of issuing ASRs to administratively 4499 remove users from the network. 4501 An access device that receives an ASR with Session-ID equal to a 4502 currently active session MAY stop the session. Whether the access 4503 device stops the session or not is implementation- and/or 4504 configuration-dependent. For example, an access device may honor ASRs 4505 from certain agents only. In any case, the access device MUST respond 4506 with an Abort-Session-Answer, including a Result-Code AVP to indicate 4507 what action it took. 4509 Note that if the access device does stop the session upon receipt of 4510 an ASR, it issues an STR to the authorizing server (which may or may 4511 not be the agent issuing the ASR) just as it would if the session 4512 were terminated for any other reason. 4514 8.5.1 Abort-Session-Request 4516 The Abort-Session-Request (ASR), indicated by the Command-Code set to 4517 274 and the message flags' 'R' bit set, may be sent by any server to 4518 the access device that is providing session service, to request that 4519 the session identified by the Session-Id be stopped. 4521 Message Format 4523 ::= < Diameter Header: 274, REQ, PXY > 4524 < Session-Id > 4525 { Origin-Host } 4526 { Origin-Realm } 4527 { Destination-Realm } 4528 { Destination-Host } 4529 { Auth-Application-Id } 4530 [ User-Name ] 4531 [ Origin-State-Id ] 4532 * [ AVP ] 4533 * [ Proxy-Info ] 4534 * [ Route-Record ] 4536 8.5.2 Abort-Session-Answer 4538 The Abort-Session-Answer (ASA), indicated by the Command-Code set to 4539 274 and the message flags' 'R' bit clear, is sent in response to the 4540 ASR. The Result-Code AVP MUST be present, and indicates the 4541 disposition of the request. 4543 If the session identified by Session-Id in the ASR was successfully 4544 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is 4545 not currently active, Result-Code is set to 4546 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the 4547 session for any other reason, Result-Code is set to 4548 DIAMETER_UNABLE_TO_COMPLY. 4550 Message Format 4551 ::= < Diameter Header: 274, PXY > 4552 < Session-Id > 4553 { Result-Code } 4554 { Origin-Host } 4555 { Origin-Realm } 4556 [ User-Name ] 4557 [ Origin-State-Id ] 4558 [ Error-Message ] 4559 [ Error-Reporting-Host ] 4560 * [ Failed-AVP ] 4561 * [ Redirected-Host ] 4562 [ Redirected-Host-Usage ] 4563 [ Redirected-Max-Cache-Time ] 4564 * [ AVP ] 4565 * [ Proxy-Info ] 4567 8.6 Inferring Session Termination from Origin-State-Id 4569 Origin-State-Id is used to allow rapid detection of terminated 4570 sessions for which no STR would have been issued, due to 4571 unanticipated shutdown of an access device. 4573 By including Origin-State-Id in CER/CAA messages, an access device 4574 allows a next-hop server to determine immediately upon connection 4575 whether the device has lost its sessions since the last connection. 4577 By including Origin-State-Id in request messages, an access device 4578 also allows a server with which it communicates via proxy to make 4579 such a determination. However, a server that is not directly 4580 connected with the access device will not discover that the access 4581 device has been restarted unless and until it receives a new request 4582 from the access device. Thus, use of this mechanism across proxies is 4583 opportunistic rather than reliable, but useful nonetheless. 4585 When a Diameter server receives an Origin-State-Id that is greater 4586 than the Origin-State-Id previously received from the same issuer, it 4587 may assume that the issuer has lost state since the previous message 4588 and that all sessions that were active under the lower Origin-State- 4589 Id have been terminated. The Diameter server MAY clean up all session 4590 state associated with such lost sessions, and MAY also issues STRs 4591 for all such lost sessions that were authorized on upstream servers, 4592 to allow session state to be cleaned up globally. 4594 8.7 Auth-Request-Type AVP 4596 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is 4597 included in application-specific auth requests to inform the peers 4598 whether a user is to be authenticated only, authorized only or both. 4599 Note any value other than both MAY cause RADIUS interoperability 4600 issues. The following values are defined: 4602 AUTHENTICATE_ONLY 1 4603 The request being sent is for authentication only, and MUST 4604 contain the relevant application specific authentication AVPs 4605 that are needed by the Diameter server to authenticate the 4606 user. 4608 AUTHORIZE_ONLY 2 4609 The request being sent is for authorization only, and MUST 4610 contain the application specific authorization AVPs that are 4611 necessary to identify the service being requested/offered. 4613 AUTHORIZE_AUTHENTICATE 3 4614 The request contains a request for both authentication and 4615 authorization. The request MUST include both the relevant 4616 application specific authentication information, and 4617 authorization information necessary to identify the service 4618 being requested/offered. 4620 8.8 Session-Id AVP 4622 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used 4623 to identify a specific session (see section 8). All messages 4624 pertaining to a specific session MUST include only one Session-Id AVP 4625 and the same value MUST be used throughout the life of a session. 4626 When present, the Session-Id SHOULD appear immediately following the 4627 Diameter Header (see section 3). 4629 The Session-Id MUST be globally and eternally unique, as it is meant 4630 to uniquely identify a user session without reference to any other 4631 information, and may be needed to correlate historical authentication 4632 information with accounting information. The Session-Id includes a 4633 mandatory portion and an implementation-defined portion; a 4634 recommended format for the implementation-defined portion is outlined 4635 below. 4637 The Session-Id MUST begin with the sender's identity encoded in the 4638 DiameterIdentity type (see section 4.4). The remainder of the 4639 Session-Id MAY be any sequence that the client can guarantee to be 4640 eternally unique; however, the following format is recommended, 4641 (square brackets [] indicate an optional element): 4643 ;;[;] 4644 and are decimal representations of the 4645 high and low 32 bits of a monotonically increasing 64-bit value. The 4646 64-bit value is rendered in two part to simplify formatting by 32-bit 4647 processors. At startup, the high 32 bits of the 64-bit value MAY be 4648 initialized to the time, and the low 32 bits MAY be initialized to 4649 zero. This will for practical purposes eliminate the possibility of 4650 overlapping Session-Ids after a reboot, assuming the reboot process 4651 takes longer than a second. Alternatively, an implementation MAY keep 4652 track of the increasing value in non-volatile memory. 4654 is implementation specific but may include a modem's 4655 device Id, a layer 2 address, timestamp, etc. 4657 Example, in which there is no optional value: 4658 accesspoint7.acme.com;1876543210;523 4660 Example, in which there is an optional value: 4661 accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 4663 The Session-Id is created by the Diameter device initiating the 4664 session, which in most cases is done by the client. Note that a 4665 Session-Id MAY be used for both the authorization and accounting 4666 commands of a given application. 4668 8.9 Authorization-Lifetime AVP 4670 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 4671 and contains the maximum number of seconds of service to be provided 4672 to the user before the user is to be re-authenticated and/or re- 4673 authorized. Great care should be taken when the Authorization- 4674 Lifetime value is determined, since a low, non-zero, value could 4675 create significant Diameter traffic, which could congest both the 4676 network and the agents. 4678 A value of zero (0) means that immediate re-auth is necessary by the 4679 access device. This is typically used in cases where multiple 4680 authentication methods are used, and a successful auth response with 4681 this AVP set to zero is used to signal that the next authentication 4682 method is to be immediately initiated. The absence of this AVP, or a 4683 value of all ones (meaning all bits in the 32 bit field are set to 4684 one) means no re-auth is expected. 4686 If both this AVP and the Session-Timeout AVP are present in a 4687 message, the value of the latter MUST NOT be smaller than the 4688 Authorization-Lifetime AVP. 4690 An Authorization-Lifetime AVP MAY be present in re-authorization 4691 messages, and contains the number of seconds the user is authorized 4692 to receive service from the time the re-auth answer message is 4693 received by the access device. 4695 This AVP MAY be provided by the client as a hint of the maximum 4696 lifetime that it is willing to accept. However, the server MAY return 4697 a value that is equal to, or smaller, than the one provided by the 4698 client. 4700 8.10 Auth-Grace-Period AVP 4702 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and 4703 contains the number of seconds the Diameter server will wait 4704 following the expiration of the Authorization-Lifetime AVP before 4705 cleaning up resources for the session. 4707 8.11 Auth-Session-State AVP 4709 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and 4710 specifies whether state is maintained for a particular session. The 4711 client MAY include this AVP in requests as a hint to the server, but 4712 the value in the server's answer message is binding. The following 4713 values are supported: 4715 STATE_MAINTAINED 0 4716 This value is used to specify that session state is being 4717 maintained, and the access device MUST issue a session 4718 termination message when service to the user is terminated. 4719 This is the default value. 4721 NO_STATE_MAINTAINED 1 4722 This value is used to specify that no session termination 4723 messages will be sent by the access device upon expiration of 4724 the Authorization-Lifetime. 4726 8.12 Re-Auth-Request-Type AVP 4728 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and 4729 is included in application-specific auth answers to inform the client 4730 of the action expected upon expiration of the Authorization-Lifetime. 4731 If the answer message contains an Authorization-Lifetime AVP with a 4732 positive value, the Re-Auth-Request-Type AVP MUST be present in an 4733 answer message. The following values are defined: 4735 AUTHORIZE_ONLY 0 4736 An authorization only re-auth is expected upon expiration of 4737 the Authorization-Lifetime. This is the default value if the 4738 AVP is not present in answer messages that include the 4739 Authorization-Lifetime. 4741 AUTHORIZE_AUTHENTICATE 1 4742 An authentication and authorization re-auth is expected upon 4743 expiration of the Authorization-Lifetime. 4745 8.13 Session-Timeout AVP 4747 The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 4748 and contains the maximum number of seconds of service to be provided 4749 to the user before termination of the session. When both the 4750 Session-Timeout and the Authorization-Lifetime AVPs are present in an 4751 answer message, the former MUST be equal to or greater than the value 4752 of the latter. 4754 A session that terminates on an access device due to the expiration 4755 of the Session-Timeout MUST cause an STR to be issued, unless both 4756 the access device and the home server had previously agreed that no 4757 session termination messages would be sent (see section 8.9). 4759 A Session-Timeout AVP MAY be present in a re-authorization answer 4760 message, and contains the remaining number of seconds from the 4761 beginning of the re-auth. 4763 A value of zero, or the absence of this AVP, means that this session 4764 has an unlimited number of seconds before termination. 4766 This AVP MAY be provided by the client as a hint of the maximum 4767 timeout that it is willing to accept. However, the server MAY return 4768 a value that is equal to, or smaller, than the one provided by the 4769 client. 4771 8.14 User-Name AVP 4773 The User-Name AVP (AVP Code 1) [RADIUS] is of type UTF8String, which 4774 contains the User-Name, in a format consistent with the NAI 4775 specification [NAI]. 4777 8.15 Termination-Cause AVP 4779 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and 4780 is used to indicate the reason why a session was terminated on the 4781 access device. The following values are defined: 4783 DIAMETER_LOGOUT 1 4784 The user initiated a disconnect 4786 DIAMETER_SERVICE_NOT_PROVIDED 2 4787 This value is used when the user disconnected prior to the 4788 receipt of the authorization answer message. 4790 DIAMETER_BAD_ANSWER 3 4791 This value indicates that the authorization answer received by 4792 the access device was not processed successfully. 4794 DIAMETER_ADMINISTRATIVE 4 4795 The user was not granted access, or was disconnected, due to 4796 administrative reasons, such as the receipt of a Abort- 4797 Session-Request message. 4799 DIAMETER_LINK_BROKEN 5 4800 The communication to the user was abruptly disconnected. 4802 DIAMETER_AUTH_EXPIRED 6 4803 The user's access was terminated since its authorized session 4804 time has expired. 4806 DIAMETER_USER_MOVED 7 4807 The user is receiving services from another access device. 4809 DIAMETER_SESSION_TIMEOUT 8 4810 The user's session has timed out, and service has been 4811 terminated. 4813 8.16 Origin-State-Id AVP 4815 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a 4816 monotonically increasing value that is advanced whenever a Diameter 4817 entity restarts with loss of previous state, for example upon reboot. 4818 Origin-State-Id MAY be included in any Diameter message, including 4819 CER. 4821 A Diameter entity issuing this AVP MUST create a higher value for 4822 this AVP each time its state is reset. A Diameter entity MAY set 4823 Origin-State-Id to the time of startup, or it MAY use an incrementing 4824 counter retained in non-volatile memory across restarts. 4826 The Origin-State-Id, if present, MUST reflect the state of the entity 4827 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST 4828 either remove Origin-State-Id or modify it appropriately as well. 4830 Typically, Origin-State-Id is used by an access device that always 4831 starts up with no active sessions; that is, any session active prior 4832 to restart will have been lost. By including Origin-State-Id in a 4833 message, it allows other Diameter entities to infer that sessions 4834 associated with a lower Origin-State-Id are no longer active. If an 4835 access device does not intend for such inferences to be made, it MUST 4836 either not include Origin-State-Id in any message, or set its value 4837 to 0. 4839 8.17 Session-Binding AVP 4841 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY 4842 be present in application-specific authorization answer messages. If 4843 present, this AVP MAY inform the Diameter client that all future 4844 application-specific re-auth messages for this session MUST be sent 4845 to the same authorization server. This AVP MAY also specify that a 4846 Session-Termination-Request message for this session MUST be sent to 4847 the same authorizing server. 4849 This field is a bit mask, and the following bits have been defined: 4851 RE_AUTH 1 4852 When set, future re-auth messages for this session MUST NOT 4853 include the Destination-Host AVP. When cleared, the default 4854 value, the Destination-Host AVP MUST be present in all re-auth 4855 messages for this session. 4857 STR 2 4858 When set, the STR message for this session MUST NOT include the 4859 Destination-Host AVP. When cleared, the default value, the 4860 Destination-Host AVP MUST be present in the STR message for 4861 this session. 4863 ACCOUNTING 4 4864 When set, all accounting messages for this session MUST NOT 4865 include the Destination-Host AVP. When cleared, the default 4866 value, the Destination-Host AVP, if known, MUST be present in 4867 all accounting messages for this session. 4869 8.18 Session-Server-Failover AVP 4871 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated, 4872 and MAY be present in application-specific authorization answer 4873 messages that either do not include the Session-Binding AVP or 4874 include the Session-Binding AVP with any of the bits set to a zero 4875 value. If present, this AVP MAY inform the Diameter client that if a 4876 re-auth or STR message fails due to a delivery problem, the Diameter 4877 client SHOULD issue a subsequent message without the Destination-Host 4878 AVP. When absent, the default value is REFUSE_SERVICE. 4880 The following values are supported: 4882 REFUSE_SERVICE 0 4883 If either the re-auth or the STR message delivery fails, 4884 terminate service with the user, and do not attempt any 4885 subsequent attempts. 4887 TRY_AGAIN 1 4888 If either the re-auth or the STR message delivery fails, resend 4889 the failed message without the Destination-Host AVP present. 4891 ALLOW_SERVICE 2 4892 If re-auth message delivery fails, assume that re-authorization 4893 succeeded. If STR message delivery fails, terminate the 4894 session. 4896 TRY_AGAIN_ALLOW_SERVICE 3 4897 If either the re-auth or the STR message delivery fails, resend 4898 the failed message without the Destination-Host AVP present. 4899 If the second delivery fails for re-auth, assume re- 4900 authorization succeeded. If the second delivery fails for STR, 4901 terminate the session. 4903 8.19 Multi-Round-Time-Out AVP 4905 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32, 4906 and SHOULD be present in application-specific authorization answer 4907 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. 4908 This AVP contains the maximum number of seconds that the access 4909 device MUST provide the user in responding to an authentication 4910 request. 4912 8.20 Class AVP 4914 The Class AVP (AVP Code 25) is of type OctetString and is used to by 4915 Diameter servers to return state information to the access device. 4916 When one or more Class AVPs are present in application-specific 4917 authorization answer messages, they MUST be present in subsequent 4918 re-authorization, session termination and accounting messages. Class 4919 AVPs found in a re-authorization answer message override the ones 4920 found in any previous authorization answer message. Diameter server 4921 implementations SHOULD NOT return Class AVPs that require more than 4922 4096 bytes of storage on the Diameter client. A Diameter client that 4923 receives Class AVPs whose size exceeds local available storage MUST 4924 terminate the session. 4926 9 Accounting 4928 This accounting protocol is based on a server directed model with 4929 capabilities for real-time delivery of accounting information. 4930 Several fault resilience methods [ACCMGMT] have been built in to the 4931 protocol in order minimize loss of accounting data in various fault 4932 situations and under different assumptions about the capabilities of 4933 the used devices. 4935 9.1 Server Directed Model 4937 The server directed model means that the device generating the 4938 accounting data gets information from either the authorization server 4939 (if contacted) or the accounting server regarding the way accounting 4940 data shall be forwarded. This information includes accounting record 4941 timeliness requirements. 4943 As discussed in [ACCMGMT], real-time transfer of accounting records 4944 is a requirement, such as the need to perform credit limit checks and 4945 fraud detection. Note that batch accounting is not a requirement, and 4946 is therefore not supported by Diameter. Should batched accounting be 4947 required in the future, a new Diameter application will need to be 4948 created, or it could be handled using another protocol. Note, 4949 however, that even if at the Diameter layer accounting requests are 4950 processed one by one, transport protocols used under Diameter 4951 typically batch several requests in the same packet under heavy 4952 traffic conditions. This may be sufficient for many applications. 4954 The authorization server (chain) directs the selection of proper 4955 transfer strategy, based on its knowledge of the user and 4956 relationships of roaming partnerships. The server (or agents) uses 4957 the Accounting-Interim-Interval and Accounting-Realtime-Required AVPs 4958 to control the operation of the Diameter peer operating as a client. 4959 The Accounting-Interim-Interval AVP, when present, instructs the 4960 Diameter node acting as a client to produce accounting records 4961 continuously even during a session. Accounting-Realtime-Required AVP 4962 is used to control the behavior of the client when the transfer of 4963 accounting records from the Diameter client is delayed or 4964 unsuccessful. 4966 The Diameter accounting server MAY override the interim interval or 4967 the realtime requirements by including the Accounting-Interim- 4968 Interval or Accounting-Realtime-Required AVP in the Accounting-Answer 4969 message. When one of these AVPs is present, the latest value received 4970 SHOULD be used in further accounting activities for the same session. 4972 9.2 Protocol Messages 4974 A Diameter node that receives a successful authentication and/or 4975 authorization messages from the Home AAA server MUST collect 4976 accounting information for the session. The Accounting-Request 4977 message is used to transmit the accounting information to the Home 4978 AAA server, which MUST reply with the Accounting-Answer message to 4979 confirm reception. The Accounting-Answer message includes the 4980 Result-Code AVP, which MAY indicate that an error was present in the 4981 accounting message. A rejected Accounting-Request message MAY cause 4982 the user's session to be terminated, depending on the value of the 4983 Accounting-Realtime-Required AVP received earlier for the session in 4984 question. 4986 Each Diameter Accounting protocol message MAY be compressed using 4987 IPComp [IPComp] in order to reduce the used network bandwidth, which 4988 MAY use IKE [IKE] to negotiate the compression parameters. 4990 9.3 Application document requirements 4992 Each Diameter application (e.g. NASREQ, MobileIP), MUST define their 4993 Service-Specific AVPs that MUST be present in the Accounting-Request 4994 message in a section entitled "Accounting AVPs". The application MUST 4995 assume that the AVPs described in this document will be present in 4996 all Accounting messages, so only their respective service-specific 4997 AVPs need to be defined in this section. 4999 9.4 Fault Resilience 5001 Diameter Base protocol mechanisms are used to overcome small message 5002 loss and network faults of temporary nature. 5004 Diameter peers acting as clients MUST implement the use of failover 5005 to guard against server failures and certain network failures. 5006 Diameter peers acting as agents or related off-line processing 5007 systems MUST detect duplicate accounting records caused by the 5008 sending of same record to several servers and duplication of messages 5009 in transit. This detection MUST be based on the inspection of the 5010 Session-Id and Accounting-Record-Number AVP pairs. Appendix C 5011 discusses duplicate detection needs and implementation issues. 5013 Diameter clients MAY have non-volatile memory for the safe storage of 5014 accounting records over reboots or extended network failures, network 5015 partitions, and server failures. If such memory is available, the 5016 client SHOULD store new accounting records there as soon as the 5017 records are created and until a positive acknowledgement of their 5018 reception from the Diameter Server has been received. Upon a reboot, 5019 the client MUST starting sending the records in the non-volatile 5020 memory to the accounting server with appropriate modifications in 5021 termination cause, session length, and other relevant information in 5022 the records. 5024 A further application of this protocol may include AVPs to control 5025 how many accounting records may at most be stored in the Diameter 5026 client without committing them to the non-volatile memory or 5027 transferring them to the Diameter server. 5029 The client SHOULD NOT remove the accounting data from any of its 5030 memory areas before the correct Accounting-Answer has been received. 5031 The client MAY remove oldest, undelivered or yet unacknowledged 5032 accounting data if it runs out of resources such as memory. It is an 5033 implementation dependent matter for the client to accept new sessions 5034 under this condition. 5036 9.5 Accounting Records 5038 In all accounting records, the Session-Id AVP MUST be present; the 5039 User-Name AVP MUST be present if it is available to the Diameter 5040 client. If strong authentication across agents is required, as 5041 described in [CMS], the CMS-Signed-Data AVP may be used to 5042 authenticate the Accounting Data and Service Specific AVPs. It is not 5043 typically necessary that the CMS-Signed-Data AVP cover any additional 5044 AVPs, but it is permitted as long as the AVPs protected are defined 5045 to have their 'P' bit set. 5047 Different types of accounting records are sent depending on the 5048 actual type of accounted service and the authorization server's 5049 directions for interim accounting. If the accounted service is a 5050 one-time event, meaning that the start and stop of the event are 5051 simultaneous, then the Accounting-Record-Type AVP MUST be present and 5052 set to the value EVENT_RECORD. 5054 If the accounted service is of a measurable length, then the AVP MUST 5055 use the values START_RECORD, STOP_RECORD, and possibly, 5056 INTERIM_RECORD. If the authorization server has not directed interim 5057 accounting to be enabled for the session, two accounting records MUST 5058 be generated for each service of type session. When the initial 5059 Accounting-Request for a given session is sent, the Accounting- 5060 Record-Type AVP MUST be set to the value START_RECORD. When the last 5061 Accounting-Request is sent, the value MUST be STOP_RECORD. 5063 If the authorization server has directed interim accounting to be 5064 enabled, the Diameter client MUST produce additional records between 5065 the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The 5066 production of these records is directed by Accounting-Interim- 5067 Interval as well as any re-authentication or re-authorization of the 5068 session. The Diameter client MUST overwrite any previous interim 5069 accounting records that are locally stored for delivery, if a new 5070 record is being generated for the same session. This ensures that 5071 only one pending interim record can exist on an access device for any 5072 given session. 5074 A particular value of Accounting-Sub-Session-Id MUST appear only in 5075 one sequence of accounting records from a DIAMETER client, except for 5076 the purposes of retransmission. The one sequence that is sent MUST 5077 be either one record with Accounting-Record-Type AVP set to the value 5078 EVENT_RECORD, or several records starting with one having the value 5079 START_RECORD, followed by zero or more INTERIM_RECORD and a single 5080 STOP_RECORD. A particular Diameter application specification MUST 5081 define the type of sequences that MUST be used. 5083 9.6 Correlation of Accounting Records 5085 The Diameter protocol's Session-Id AVP, which is globally unique (see 5086 section 8.8), is used during the authorization phase to identify a 5087 particular session. Services that do not require any authorization 5088 still use the Session-Id AVP to identify sessions. 5090 However, there are certain applications that require multiple 5091 accounting sub-sessions. Such applications would send messages with a 5092 constant Session-Id AVP, but a different Accounting-Sub-Session-Id 5093 AVP. In these cases, correlation is performed using the Session-Id. 5094 It is important to note that receiving a STOP_RECORD with no 5095 Accounting-Sub-Session-Id AVP when sub-sessions were originally used 5096 in the START_RECORD messages implies that all sub-sessions are 5097 terminated. 5099 Furthermore, there are certain applications where a user receives 5100 service from different access devices (e.g. Mobile IP), each with 5101 their own unique Session-Id. In such cases, the Acct-Multi-Session-Id 5102 AVP is used for correlation. During authorization, a server that 5103 determines that a request is for an existing session SHOULD include 5104 the Acct-Multi-Session-Id AVP, which the access device MUST include 5105 in all subsequent accounting messages. 5107 The Acct-Multi-Session-Id AVP MAY include the value of the original 5108 Session-Id. It's contents are implementation specific, but MUST be 5109 globally unique across other Acct-Multi-Session-Id, and MUST NOT 5110 change during the life of a session. 5112 A Diameter application document MUST define the exact concept of a 5113 session that is being accounted, and MAY define the concept of a 5114 multi-session. For instance, the NASREQ DIAMETER application treats a 5115 single PPP connection to a Network Access Server as one session, and 5116 a set of Multilink PPP sessions as one multi-session. 5118 9.7 Accounting Command-Codes 5120 This section defines new Command-Code values that MUST be supported 5121 by all Diameter implementations that provide Accounting services. 5123 9.7.1 Accounting-Request 5125 The Accounting-Request (ACR) command, indicated by the Command-Code 5126 field set to 271 and the Command Flags' 'R' bit set, is sent by a 5127 Diameter node, acting as a client, in order to exchange accounting 5128 information with a peer. 5130 When the Accounting-Request is being submitted to a third party (e.g. 5131 settlement service), and includes the CMS-Signed-Data AVP [CMS], the 5132 CMS-Signed-Data AVP MUST be signed by both the local and home 5133 Diameter server using the countersignature procedures described in 5134 [CMS]. 5136 One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs 5137 MUST be present. If the Vendor-Specific-Application-Id grouped AVP is 5138 present, it must have an Acct-Application-Id inside. 5140 The AVP listed below SHOULD include service specific accounting AVPs, 5141 as described in section 9.3. 5143 Message Format 5145 ::= < Diameter Header: 271, REQ, PXY > 5146 < Session-Id > 5147 { Origin-Host } 5148 { Origin-Realm } 5149 { Destination-Realm } 5150 { Accounting-Record-Type } 5151 { Accounting-Record-Number } 5152 [ Acct-Application-Id ] 5153 [ Vendor-Specific-Application-Id ] 5154 [ User-Name ] 5155 [ Accounting-Sub-Session-Id ] 5156 [ Accounting-RADIUS-Session-Id ] 5157 [ Acct-Multi-Session-Id ] 5158 [ Accounting-Interim-Interval ] 5159 [ Accounting-Realtime-Required ] 5160 [ Origin-State-Id ] 5161 * [ AVP ] 5162 * [ Proxy-Info ] 5163 * [ Route-Record ] 5165 9.7.2 Accounting-Answer 5167 The Accounting-Answer (ACA) command, indicated by the Command-Code 5168 field set to 271 and the Command Flags' 'R' bit cleared, is used to 5169 acknowledge an Accounting-Request command. The Accounting-Answer 5170 command contains the same Session-Id and MAY contains the same 5171 Accounting Description and Usage AVPs that were sent in the 5172 Accounting-Request command. If the CMS-Data AVP was present in the 5173 Accounting-Request, the corresponding ACA message MUST include the 5174 CMS-Data AVP signed by the responder to provide strong AVP 5175 authentication, which MAY be used for the purposes of repudiation. 5177 Only the target Diameter Server, known as the home Diameter Server, 5178 SHOULD respond with the Accounting-Answer command. 5180 One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs 5181 MUST be present. If the Vendor-Specific-Application-Id grouped AVP is 5182 present, it must have an Acct-Application-Id inside. 5184 The AVP listed below SHOULD include service specific accounting AVPs, 5185 as described in section 9.3. 5187 Message Format 5189 ::= < Diameter Header: 271, PXY > 5190 < Session-Id > 5191 { Result-Code } 5192 { Origin-Host } 5193 { Origin-Realm } 5194 { Accounting-Record-Type } 5195 { Accounting-Record-Number } 5196 [ Acct-Application-Id ] 5197 [ Vendor-Specific-Application-Id ] 5198 [ User-Name ] 5199 [ Accounting-Sub-Session-Id ] 5200 [ Accounting-RADIUS-Session-Id ] 5201 [ Acct-Multi-Session-Id ] 5202 [ Error-Reporting-Host ] 5203 [ Accounting-Interim-Interval ] 5204 [ Accounting-Realtime-Required ] 5205 [ Origin-State-Id ] 5206 * [ AVP ] 5207 * [ Proxy-Info ] 5209 9.8 Accounting AVPs 5211 This section contains AVPs that describe accounting usage information 5212 related to a specific session. 5214 9.8.1 Accounting-Record-Type AVP 5216 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated 5217 and contains the type of accounting record being sent. The following 5218 values are currently defined for the Accounting-Record-Type AVP: 5220 EVENT_RECORD 1 5221 An Accounting Event Record is used to indicate that a one-time 5222 event has occurred (meaning that the start and end of the event 5223 are simultaneous). This record contains all information 5224 relevant to the service, and is the only record of the service. 5226 START_RECORD 2 5227 An Accounting Start, Interim, and Stop Records are used to 5228 indicate that a service of a measurable length has been given. 5229 An Accounting Start Record is used to initiate an accounting 5230 session, and contains accounting information that is relevant 5231 to the initiation of the session. 5233 INTERIM_RECORD 3 5234 An Interim Accounting Record contains cumulative accounting 5235 information for an existing accounting session. Interim 5236 Accounting Records SHOULD be sent every time a re- 5237 authentication or re-authorization occurs. Further, additional 5238 interim record triggers MAY be defined by application-specific 5239 Diameter applications. The selection of whether to use 5240 INTERIM_RECORD records is done by the Accounting-Interim- 5241 Interval AVP. 5243 STOP_RECORD 4 5244 An Accounting Stop Record is sent to terminate an accounting 5245 session and contains cumulative accounting information relevant 5246 to the existing session. 5248 9.8.2 Accounting-Interim-Interval AVP 5250 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 5251 Unsigned32 and is sent from the Diameter home authorization server to 5252 the Diameter client. The client uses information in this AVP to 5253 decide how and when to produce accounting records. With different 5254 values in this AVP, service sessions can result in one, two, or two+N 5255 accounting records, based on the needs of the home-organization. The 5256 following accounting record production behavior is directed by the 5257 inclusion of this AVP: 5259 1. The omission of the Accounting-Interim-Interval AVP or its 5260 inclusion with Value field set to 0 means that EVENT_RECORD, 5261 START_RECORD, and STOP_RECORD are produced, as appropriate for 5262 the service. 5264 2. The inclusion of the AVP with Value field set to a non-zero 5265 value means that INTERIM_RECORD records MUST be produced 5266 between the START_RECORD and STOP_RECORD records. The Value 5267 field of this AVP is the nominal interval between these records 5268 in seconds. The Diameter node that originates the accounting 5269 information, known as the client, MUST produce the first 5270 INTERIM_RECORD record roughly at the time when this nominal 5271 interval has elapsed from the START_RECORD, the next one again 5272 as the interval has elapsed once more, and so on until the 5273 session ends and a STOP_RECORD record is produced. 5275 The client MUST ensure that the interim record production times 5276 are randomized so that large accounting message storms are not 5277 created either among records or around a common service start 5278 time. 5280 9.8.3 Accounting-Record-Number AVP 5282 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 5283 and identifies this record within one session. As Session-Id AVPs are 5284 globally unique, the combination of Session-Id and Accounting- 5285 Record-Number AVPs is also globally unique, and can be used in 5286 matching accounting records with confirmations. An easy way to 5287 produce unique numbers is to set the value to 0 for records of type 5288 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 5289 INTERIM_RECORD, 2 for the second, and so on until the value for 5290 STOP_RECORD is one more than for the last INTERIM_RECORD. 5292 9.8.4 Accounting-RADIUS-Session-Id AVP 5294 The Accounting-RADIUS-Session-Id AVP (AVP Code 44) is of type 5295 OctetString is only used when RADIUS/Diameter translation occurs. 5296 This AVP contains the contents of the RADIUS Accounting-Session-Id 5297 attribute. 5299 9.8.5 Acct-Multi-Session-Id AVP 5301 The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String, 5302 following the format specified in section 8.8. The Acct-Multi- 5303 Session-Id AVP is used to link together multiple related accounting 5304 sessions, where each session would have a unique Session-Id, but the 5305 same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the 5306 Diameter server in an authorization answer, and MUST be used in all 5307 accounting messages for the given session. 5309 9.8.6 Accounting-Sub-Session-Id AVP 5311 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type 5312 Unsigned64 and contains the accounting sub-session identifier. The 5313 combination of the Session-Id and this AVP MUST be unique per sub- 5314 session, and the value of this AVP MUST be monotonically increased by 5315 one for all new sub-sessions. The absence of this AVP implies no 5316 sub-sessions are in use, with the exception of an Accounting-Request 5317 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD 5318 message with no Accounting-Sub-Session-Id AVP present will signal the 5319 termination of all sub-sessions for a given Session-Id. 5321 9.8.7 Accounting-Realtime-Required AVP 5323 The Accounting-Realtime-Required AVP (AVP Code 483) is of type 5324 Enumerated and is sent from the Diameter home authorization server to 5325 the Diameter client or in the Accounting-Answer from the accounting 5326 server. The client uses information in this AVP to decide what to do 5327 if the sending of accounting records to the accounting server has 5328 been temporarily prevented due to, for instance, a network problem. 5330 DELIVER_AND_GRANT 1 5332 The AVP with Value field set to DELIVER_AND_GRANT means that 5333 the service MUST only be granted as long as there is a 5334 connection to an accounting server. Note that the set of 5335 alternative accounting servers are treated as one server in 5336 this sense. Having to move the accounting record stream to a 5337 backup server is not a reason to discontinue the service to the 5338 user. 5340 GRANT_AND_STORE 2 5342 The AVP with Value field set to GRANT_AND_STORE means that 5343 service SHOULD be granted if there is a connection, or as long 5344 as records can still be stored as described in section 9.4. 5346 This is the default behaviour if the AVP isn't included in the 5347 reply from the authorization server. 5349 GRANT_AND_LOSE 3 5351 The AVP with Value field set to GRANT_AND_LOSE means that 5352 service SHOULD be granted even if the records can not be 5353 delivered or stored. 5355 10 AVP Occurrence Table 5357 The following tables presents the AVPs defined in this document, and 5358 specifies in which Diameter messages they MAY, or MAY NOT be present. 5359 Note that AVPs that can only be present within a Grouped AVP are not 5360 represented in this table. 5362 The table uses the following symbols: 5363 0 The AVP MUST NOT be present in the message. 5364 0+ Zero or more instances of the AVP MAY be present in the 5365 message. 5366 0-1 Zero or one instance of the AVP MAY be present in the 5367 message. It is considered an error if there are more than 5368 once instance of the AVP. 5369 1 One instance of the AVP MUST be present in the message. 5370 1+ At least one instance of the AVP MUST be present in the 5371 message. 5373 10.1 Base Protocol Command AVP Table 5375 The table in this section is limited to the non-accounting Command 5376 Codes defined in this specification. 5378 +-----------------------------------------------+ 5379 | Command-Code | 5380 |---+---+---+---+---+---+---+---+---+---+---+---+ 5381 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| 5382 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5383 Accounting-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5384 Interval | | | | | | | | | | | | | 5385 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5386 Required | | | | | | | | | | | | | 5387 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5388 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5389 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5390 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5391 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5392 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5393 Lifetime | | | | | | | | | | | | | 5394 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ | 5395 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 | 5396 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5397 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5398 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| 5399 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5400 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ | 5401 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5402 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5403 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5404 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5405 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5406 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| 5407 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5408 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ | 5409 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ | 5410 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5411 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5412 Time | | | | | | | | | | | | | 5413 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 | 5414 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 | 5415 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 | 5416 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5417 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | 5418 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5419 Failover | | | | | | | | | | | | | 5420 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5421 Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5422 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 | 5423 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1| 5424 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5425 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5426 Application-Id | | | | | | | | | | | | | 5427 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5429 10.2 Accounting AVP Table 5431 The table in this section is used to represent which AVPs defined in 5432 this document are to be present in the Accounting messages. These 5433 AVP occurrence requirements are guidelines, which may be expanded, 5434 and/or overriden by application-specific requirements in the Diameter 5435 applications documents. 5437 +-----------+ 5438 | Command | 5439 | Code | 5440 |-----+-----+ 5441 Attribute Name | ACR | ACA | 5442 ------------------------------|-----+-----+ 5443 Accounting-Interim-Interval | 0-1 | 0-1 | 5444 Acct-Multi-Session-Id | 0-1 | 0-1 | 5445 Accounting-Record-Number | 1 | 1 | 5446 Accounting-Record-Type | 1 | 1 | 5447 Accounting-RADIUS-Session-Id | 0-1 | 0-1 | 5448 Accounting-Sub-Session-Id | 0-1 | 0-1 | 5449 Accounting-Realtime-Required | 0-1 | 0-1 | 5450 Acct-Application-Id | 0-1 | 0-1 | 5451 Auth-Application-Id | 0 | 0 | 5452 Class | 0+ | 0+ | 5453 Destination-Host | 0-1 | 0 | 5454 Destination-Realm | 1 | 0 | 5455 Error-Reporting-Host | 0 | 0+ | 5456 Event-Timestamp | 0-1 | 0-1 | 5457 Origin-Host | 1 | 1 | 5458 Origin-Realm | 1 | 1 | 5459 Proxy-Info | 0+ | 0+ | 5460 Route-Record | 0+ | 0+ | 5461 Result-Code | 0 | 1 | 5462 Session-Id | 1 | 1 | 5463 Termination-Cause | 0-1 | 0-1 | 5464 User-Name | 1 | 0-1 | 5465 Vendor-Specific-Application-Id| 0-1 | 0-1 | 5466 ------------------------------|-----+-----+ 5468 11 IANA Considerations 5470 This document defines a number of assigned numbers to be maintained 5471 by the IANA. This section explains the criteria to be used by the 5472 IANA to assign additional numbers in each of these lists. The 5473 following subsections describe the assignment policy for the 5474 namespaces defined elsewhere in this document. 5476 11.1 AVP Header 5478 As defined in section 4, the AVP header contains two fields that 5479 requires IANA namespace management; the AVP Code and Flags field. 5481 11.1.1 AVP Code 5483 The AVP Code namespace is used to identify attributes. When the 5484 Vendor ID value is set to zero (0), IANA will maintain a registry of 5485 assigned AVP codes and in some cases also their values. AVP Codes 5486 0-254 are managed separately as RADIUS Attribute Types [RADTYPE], 5487 while the remaining namespace is available for assignment via 5488 Specification Required [IANA]. 5490 Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP 5491 header is set to a non-zero value, are for Private Use. 5493 This document defines the AVP Codes 257-274, 276-285, 287, 291-297, 5494 480, 482-483 and 485-486. See section 4.6 for the assignment of the 5495 namespace in this specification. 5497 11.1.2 AVP Flags 5499 There are 8 bits in the AVP Flags field of the AVP header, defined in 5500 section 4. This document assigns bit 8 ('V'endor Specific), bit 7 5501 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only 5502 be assigned via a Standards Action [IANA]. 5504 11.2 Diameter Header 5506 As defined in section 3, the Diameter header contains two fields that 5507 require IANA namespace management; Command Code and Command Flags. 5509 11.2.1 Command Codes 5511 The Command Code namespace is used to identify Diameter commands. The 5512 values 0-255 are reserved for RADIUS backward compatibility, and are 5513 defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining 5514 values are available via Standards Action [IANA]. 5516 Vendor-Specific Command Codes, where the Vendor-Id field in the 5517 Diameter header is set to a non-zero value, are for Private Use. 5519 This document defines the Command Codes 257, 258, 271, 274-275, 280 5520 and 282. See section 3.1 for the assignment of the namespace in this 5521 specification. 5523 11.2.2 Command Flags 5525 There are eight bits in the Command Flags field of the Diameter 5526 header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and 5527 bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a 5528 Standards Action [IANA]. 5530 11.3 Application Identifier Values 5532 As defined in section 2.4, the Application Identifier is used to 5533 identify a specific Diameter Application. All values except zero (0) 5534 and 0xffffffff are available for assignment via Standards Action 5535 [IANA]. 5537 Both Application-Id and Acct-Application-Id AVPs use the same 5538 Application Identifier space. 5540 Vendor-Specific Application Identifiers, encoded in the Vendor- 5541 Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to 5542 the vendor's enterprise number, is for Private Use. 5544 Note that the Diameter protocol is not intended to be extended for 5545 any purpose. Any applications defined MUST ensure that they fit 5546 within the existing framework, and that no changes to the base 5547 protocol are required. 5549 11.4 Result-Code AVP Values 5551 As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines 5552 the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017. 5554 All remaining values are available for assignment via IETF Consensus 5555 [IANA]. 5557 11.5 Accounting-Record-Type AVP Values 5559 As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 5560 480) defines the values 1-4. All remaining values are available for 5561 assignment via IETF Consensus [IANA]. 5563 11.6 Termination-Cause AVP Values 5565 As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) 5566 defines the values 1-8. All remaining values are available for 5567 assignment via IETF Consensus [IANA]. 5569 11.7 Redirect-Host-Usage AVP Values 5571 As defined in Section 6.12, the Redirect-Host-Usage AVP (AVP Code 5572 261) defines the values 0-5. All remaining values are available for 5573 assignment via IETF Consensus [IANA]. 5575 11.8 Session-Server-Failover AVP Values 5577 As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 5578 271) defines the values 0-3. All remaining values are available for 5579 assignment via IETF Consensus [IANA]. 5581 11.9 Session-Binding AVP Values 5583 As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) 5584 defines the bits 1-4. All remaining bits are available for assignment 5585 via IETF Consensus [IANA]. 5587 11.10 Diameter TCP/SCTP Port Numbers 5589 An IANA request has been placed for TCP and SCTP port numbers. The 5590 IANA has informed the authors that "TBD" should be used in section 5591 2.1 and throughout this document, and will be updated by the RFC 5592 editor during the RFC publication process. 5594 IANA should also replace "TBD" in sections 4.4 and 5.2 with the port 5595 number assigned in section 2.1. 5597 11.11 Disconnect-Cause AVP Values 5599 As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) 5600 defines the values 0-2. All remaining values are available for 5601 assignment via IETF Consensus [IANA]. 5603 11.12 Auth-Request-Type AVP Values 5605 As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) 5606 defines the values 1-3. All remaining values are available for 5607 assignment via IETF Consensus [TCP]. 5609 11.13 Auth-Session-State AVP Values 5611 As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) 5612 defines the values 0-1. All remaining values are available for 5613 assignment via IETF Consensus [TCP]. 5615 11.14 Re-Auth-Request-Type AVP Values 5617 As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 5618 285) defines the values 0-1. All remaining values are available for 5619 assignment via IETF Consensus [TCP]. 5621 11.15 NAPTR Service Fields 5623 The registration in the RFC MUST include the following information: 5625 Service Field: The service field being registered. An example for a 5626 new fictitious transport protocol called NCTP might be "AAA+D2N". 5628 Protocol: The specific transport protocol associated with that 5629 service field. This MUST include the name and acronym for the 5630 protocol, along with reference to a document that describes the 5631 transport protocol. For example - "New Connectionless Transport 5632 Protocol (NCTP), RFC 5766". 5634 Name and Contact Information: The name, address, email address and 5635 telephone number for the person performing the registration. 5637 The following values are to be placed into the registry: 5639 Services Field Protocol AAA+D2T 5640 TCP AAAS+D2T TLS over TCP AAA+D2S 5641 SCTP AAAS+D2S TLS over SCTP 5643 11.16 Accounting-Realtime-Required AVP Values 5645 As defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP 5646 Code 483) defines the values 1-3. All remaining values are available for 5647 assignment via IETF Consensus [IANA]. 5649 12 Diameter protocol related configurable parameters 5651 This section contains the configurable parameters that are found 5652 throughout this document: 5654 Diameter Peer 5655 A Diameter entity MAY communicate with peers that are 5656 statically configured. A statically configured Diameter peer 5657 would require that either the IP address or the fully qualified 5658 domain name (FQDN) be supplied, which would then be used to 5659 resolve through DNS. 5661 Realm Routing Table 5662 A Diameter Proxy server routes messages based on the realm 5663 portion of a Network Access Identifier (NAI). The server MUST 5664 have a table of Realms Names, and the address of the peer to 5665 which the message must be forwarded to. The routing table MAY 5666 also include a "default route", which is typically used for all 5667 messages that cannot be locally processed. 5669 Tc timer 5670 The Tc timer controls the frequency that transport connection 5671 attempts are done to a peer with whom no active transport 5672 connection exists. The recommended value is 30 seconds. 5674 13 Security Considerations 5676 The Diameter base protocol assumes that messages are secured by using 5677 either IP Security, or TLS. This security model is acceptable in 5678 environments where there is no untrusted third party relay, proxy, or 5679 redirect agent. 5681 When third party brokers or redirect agents are used, strong 5682 application level security SHOULD be required, such as non- 5683 repudiation. When the communicating peers do require this level of 5684 security either for legal or business purposes, the Diameter 5685 application defined in [CMS] MAY be used. This security model 5686 provides AVP-level authentication, and the encryption mechanism is 5687 designed such that only the target host has the keying information 5688 required to decrypt the information. 5690 13.1 IPsec Usage 5692 All Diameter implementations MUST support IPsec ESP [IPsec] in 5693 transport mode with with non-null encryption and authentication 5694 algorithms to provide per-packet authentication, integrity protection 5695 and confidentiality, and MUST support the replay protection 5696 mechanisms of IPsec. 5698 Diameter implementations MUST support IKE for peer authentication, 5699 negotiation of security associations, and key management, using the 5700 IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer 5701 authentication using a pre-shared key, and MAY support certificate- 5702 based peer authentication using digital signatures. Peer 5703 authentication using the public key encryption methods outlined in 5704 IKE's sections 5.2 and 5.3 [IKE] SHOULD NOT be used. 5706 Conformant implementations MUST support both IKE Main Mode and 5707 Aggressive Mode. When pre-shared keys are used for authentication, 5708 IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be 5709 used. When digital signatures are used for authentication, either IKE 5710 Main Mode or IKE Aggressive Mode MAY be used. 5712 When digital signatures are used to achieve authentication, an IKE 5713 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 5714 the certificate authority (or authorities) that are trusted in 5715 accordance with its local policy. IKE negotiators SHOULD use 5716 pertinent certificate revocation checks before accepting a PKI 5717 certificate for use in IKE's authentication procedures. 5719 The Phase 2 Quick Mode exchanges used to negotiate protection for 5720 Diameter connections MUST explicitly carry the Identity Payload 5721 fields (IDci and IDcr). The DOI provides for several types of 5722 identification data. However, when used in conformant 5723 implementations, each ID Payload MUST carry a single IP address and a 5724 single non-zero port number, and MUST NOT use the IP Subnet or IP 5725 Address Range formats. This allows the Phase 2 security association 5726 to correspond to specific TCP and SCTP connections. 5728 Since IPsec acceleration hardware may only be able to handle a 5729 limited number of active IKE Phase 2 SAs, Phase 2 delete messages may 5730 be sent for idle SAs, as a means of keeping the number of active 5731 Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 5732 message SHOULD NOT be interpreted as a reason for tearing down a 5733 Diameter connection. Rather, it is preferable to leave the connection 5734 up, and if additional traffic is sent on it, to bring up another IKE 5735 Phase 2 SA to protect it. This avoids the potential for continually 5736 bringing connections up and down. 5738 13.2 TLS Usage 5740 A Diameter node that initiates a connection to another Diameter node 5741 acts as a TLS client according to [TLS], and a Diameter node that 5742 accepts a connection acts as a TLS server. Diameter nodes 5743 implementing TLS for security MUST mutually authenticate as part of 5744 TLS session establishment. In order to ensure mutual authentication, 5745 the Diameter node acting as TLS server must request a certificate 5746 from the Diameter node acting as TLS client, and the Diameter node 5747 acting as TLS client MUST be prepared to supply a certificate on 5748 request. 5750 When Diameter uses TLS, it MUST have the same dNSName field 5751 requirements as the Diameter CMS Security Application [CMS] listed in 5752 section 3.2. 5754 Diameter nodes MUST be able to negotiate the following TLS cipher 5755 suites: 5757 TLS_RSA_WITH_RC4_128_MD5 5758 TLS_RSA_WITH_RC4_128_SHA 5759 TLS_RSA_WITH_3DES_EDE_CBC_SHA 5761 Diameter nodes MAY negotiate other TLS cipher suites. 5763 13.3 Peer-to-Peer Considerations 5765 As with any peer-to-peer protocol, proper configuration of the trust 5766 model within a Diameter peer is essential to security. When 5767 certificates are used, it is necessary to configure the root 5768 certificate authorities trusted by the Diameter peer. These root CAs 5769 are likely to be unique to Diameter usage and distinct from the root 5770 CAs that might be trusted for other purposes such as Web browsing. In 5771 general, it is expected that those root CAs will be configured so as 5772 to reflect the business relationships between the organization 5773 hosting the Diameter peer and other organizations. As a result, a 5774 Diameter peer will typically not be configured to allow connectivity 5775 with any arbitrary peer. When certificate authentication Diameter 5776 peers may not be known beforehand, and therefore peer discovery may 5777 be required. 5779 Note that IPsec is considerably less flexible than TLS when it comes 5780 to configuring root CAs. Since use of Port identifiers is prohibited 5781 within IKE Phase 1, within IPsec it is not possible to uniquely 5782 configure trusted root CAs for each application individually; the 5783 same policy must be used for all applications. This implies, for 5784 example, that a root CA trusted for use with Diameter must also be 5785 trusted to protect SNMP. These restrictions can be awkward at best. 5786 Since TLS supports application-level granularity in certificate 5787 policy, TLS SHOULD be used to protect Diameter connections between 5788 administrative domains. IPsec is most appropriate for intra-domain 5789 usage when pre-shared keys are used as a security mechanism. 5791 When pre-shared key authentication is used with IPsec to protect 5792 Diameter, unique pre-shared keys are configured with Diameter peers, 5793 who are identified by their IP address (Main Mode), or possibly their 5794 FQDN (Aggressive Mode). As a result, it is necessary for the set of 5795 Diameter peers to be known beforehand. Therefore, peer discovery is 5796 typically not necessary. 5798 The following is intended to provide some guidance on the issue. 5800 It is recommended that a Diameter peer implement the same security 5801 mechanism (IPsec or TLS) across all its peer-to-peer connections. 5802 Inconsistent use of security mechanisms can result in redundant 5803 security mechanisms being used (e.g. TLS over IPsec) or worse, 5804 potential security vulnerabilities. When IPsec is used with Diameter, 5805 a typical security policy for outbound traffic is "Initiate IPsec, 5806 from me to any, destination port Diameter"; for inbound traffic, the 5807 policy would be "Require IPsec, from any to me, destination port 5808 Diameter". 5810 This policy causes IPsec to be used whenever a Diameter peer 5811 initiates a connection to another Diameter peer, and to be required 5812 whenever an inbound Diameter connection occurs. This policy is 5813 attractive, since it does not require policy to be set for each peer 5814 or dynamically plumbed each time a new Diameter connection is 5815 created; an IPsec SA is automatically created based on a simple 5816 static policy. Since IPsec extensions are typically not available to 5817 the sockets API on most platforms, and IPsec policy functionality is 5818 implementation dependent, use of a simple static policy is the often 5819 the simplest route to IPsec-enabling a Diameter implementation. 5821 One implication of the recommended policy is that if a node is using 5822 both TLS and IPsec, there is not a convenient way in which to use 5823 either TLS or IPsec, but not both, without reserving an additional 5824 port for TLS usage. Since Diameter uses the same port for TLS and 5825 non-TLS usage, where the recommended IPsec policy is put in place, a 5826 TLS-protected connection will match the IPsec policy, and both IPsec 5827 and TLS will be used to protect the Diameter connection. To avoid 5828 this, it would be necessary to plumb peer-specific policies either 5829 statically or dynamically. 5831 If IPsec is used to secure Diameter peer-to-peer connections, IPsec 5832 policy SHOULD be set so as to require IPsec protection for inbound 5833 connections, and to initiate IPsec protection for outbound 5834 connections. This can be accomplished via use of inbound and outbound 5835 filter policy. 5837 14 References 5839 14.1 Normative 5841 [AAATRANS] B. Aboba, J. Wood, "Authentication, Authorization and 5842 Accounting (AAA) Transport Profile", IETF Work in Pro- 5843 gress. 5845 [ASSIGNNO] Reynolds, Postel, "Assigned Numbers", RFC 1700, 5846 October 1994. 5848 [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 5849 of the Differentiated Services Field (DS Field) in the 5850 IPv4 and IPv6 Headers," RFC 2474, December 1998. 5852 [DIFFSERVAF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, 5853 "Assured Forwarding PHB Group," RFC 2597, June 1999. 5855 [DIFFSERVEF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited For- 5856 warding PHB", RFC 2598, June 1999. 5858 [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for 5859 specifying the location of services (DNS SRV)", RFC 5860 2782, February 2000. 5862 [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authen- 5863 tication Protocol (EAP)." RFC 2284, March 1998. 5865 [FLOATPOINT] Institute of Electrical and Electronics Engineers, 5866 "IEEE Standard for Binary Floating-Point Arithmetic", 5867 ANSI/IEEE Standard 754-1985, August 1985. 5869 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 5870 Considerations Section in RFCs", BCP 26, RFC 2434, 5871 October 1998 5873 [IANAWEB] IANA, "Number assignment", http://www.iana.org 5875 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 5876 (IKE)", RFC 2409, November 1998. 5878 [IPSECDOI] D. Piper, "The Internet IP Security Domain of 5879 Interpretation for ISAKMP", RFC 2407, November 1998. 5881 [IPV4] ISI, "Internet Protocol", RFC 791, September 1981. 5883 [IPV6] Hinden, Deering, "IP Version 6 Addressing Architec- 5884 ture", RFC 2373, July 1998. 5886 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 5887 Requirement Levels", BCP 14, RFC 2119, March 1997. 5889 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 5890 2486. January 1999. 5892 [NAPTR] M. Mealling and R. Daniel, "The naming authority 5893 pointer (NAPTR) DNS resource record," Request for Com- 5894 ments 2915, Internet Engineering Task Force, Sept. 5895 2000. 5897 [RADTYPE] IANA, "RADIUS Types", http://www.isi.edu/in- 5898 notes/iana/assignments/radius-types 5900 [SCTP] R. Stewart et al., "Stream Control Transmission Proto- 5901 col". RFC 2960. October 2000. 5903 [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service 5904 Location Protocol, Version 2", RFC 2165, June 1999. 5906 [SNTP] Mills, "Simple Network Time Protocol (SNTP) Version 4 5907 for IPv4, IPv6 and OSI, RFC 2030, October 1996. 5909 [TCP] Postel, J. "Transmission Control Protocol", RFC 793, 5910 January 1981. 5912 [TEMPLATE] E. Guttman, C. Perkins, J. Kempf, "Service Templates 5913 and Service: Schemes", RFC 2609, June 1999. 5915 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 5916 RFC 2246, January 1999. 5918 [TLSSCTP] M. Tuexen, et al. "TLS over SCTP" IETF Work in Pro- 5919 gress. 5921 [URI] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, 5922 "Uniform Resource Identifiers (URI): Generic Syntax". 5923 RFC 2396, August 1998. 5925 [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 5926 10646", RFC 2279, January 1998. 5928 14.2 Non-Normative 5930 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specif- 5931 ications: ABNF", RFC 2234, November 1997. 5933 [ACCMGMT] B. Aboba, J. Arkko, D. Harrington. "Introduction to 5934 Accounting Management", RFC 2975, October 2000. 5936 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 5937 for AAA", RFC 3141, June 2001. 5939 [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 5940 application," IETF Work in Progress. 5942 [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 5943 IETF work in progress. 5945 [IPComp] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Pay- 5946 load Compression Protocol (IPComp)", RFC 2393, December 5947 1998. 5949 [MIPV4] C. Perkins, Editor. IP Mobility Support. RFC 3220, 5950 January 2002. 5952 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica- 5953 tion, Authorization, and Accounting Requirements". RFC 5954 2977. October 2000. 5956 [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter 5957 NASREQ Application", IETF work in progress. 5959 [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network 5960 Access Server Protocols", RFC 3169, September 2001. 5962 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 5963 1661, STD 51, July 1994. 5965 [PROXYCHAIN] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy 5966 Implementation in Roaming", RFC 2607, June 1999. 5968 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 5969 Authentication Dial In User Service (RADIUS)", RFC 2865, 5970 June 2000. 5972 [ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro- 5973 tocols", RFC 2477, January 1999. 5975 [SECARCH] S. Kent, R. Atkinson, "Security Architecture for the 5976 Internet Protocol", RFC 2401, November 1998. 5978 15 Acknowledgements 5980 The authors would like to thank Nenad Trifunovic, Tony Johansson and 5981 Pankaj Patel for their participation in the pre-IETF Document Reading 5982 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided 5983 invaluable assistance in working out transport issues, and similarly 5984 with Steven Bellovin in the security area. 5986 Paul Funk and David Mitton were instrumental in getting the Peer 5987 State Machine correct, and our deep thanks go to them for their time. 5988 Text in this document was also provided by Paul Funk, Mark Eklund, 5989 Mark Jones and Dave Spence. Jacques Caron provided many great com- 5990 ments as a result of a thorough review of the spec. 5992 The authors would also like to acknowledge the following people for 5993 their contribution in the development of the Diameter protocol: 5995 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, 5996 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy 5997 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, 5998 Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, 5999 Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and 6000 Jeff Weisberg. 6002 Finally, Pat Calhoun would like to thank Sun Microsystems since most 6003 of the effort put into this document was done while he was in their 6004 employ. 6006 16 Authors' Addresses 6008 Questions about this memo can be directed to: 6010 Pat R. Calhoun 6011 Black Storm Networks 6012 250 Cambridge Avenue, Suite 200 6013 Palo Alto, California, 94306 6014 USA 6016 Phone: +1 650-617-2932 6017 Fax: +1 650-786-6445 6018 E-mail: pcalhoun@bstormnetworks.com 6020 Jari Arkko 6021 Ericsson 6022 02420 Jorvas 6023 Finland 6025 Phone: +358 40 5079256 6026 E-Mail: Jari.Arkko@ericsson.com 6027 Erik Guttman 6028 Solaris Advanced Development 6029 Sun Microsystems, Inc. 6030 Eichhoelzelstr. 7 6031 74915 Waibstadt 6032 Germany 6034 Phone: +49-7263-911-701 6035 E-mail: erik.guttman@germany.sun.com 6037 Glen Zorn 6038 Cisco Systems, Inc. 6039 500 108th Avenue N.E., Suite 500 6040 Bellevue, WA 98004 6041 USA 6043 Phone: +1 425 438 8218 6045 John Loughney 6046 Nokia Research Center 6047 It�merenkatu 11-13 6048 00180 Helsinki 6049 Finland 6051 Phone: +358 50 483 6242 6052 E-mail: john.Loughney@nokia.com 6054 17 Full Copyright Statement 6056 Copyright (C) The Internet Society (2002). All Rights Reserved. 6058 This document and translations of it may be copied and furnished to 6059 others, and derivative works that comment on or otherwise explain it 6060 or assist in its implementation may be prepared, copied, published 6061 and distributed, in whole or in part, without restriction of any 6062 kind, provided that the above copyright notice and this paragraph are 6063 included on all such copies and derivative works. However, this docu- 6064 ment itself may not be modified in any way, such as by removing the 6065 copyright notice or references to the Internet Society or other 6066 Internet organizations, except as needed for the purpose of develop- 6067 ing Internet standards in which case the procedures for copyrights 6068 defined in the Internet Standards process must be followed, or as 6069 required to translate it into languages other than English. The lim- 6070 ited permissions granted above are perpetual and will not be revoked 6071 by the Internet Society or its successors or assigns. This document 6072 and the information contained herein is provided on an "AS IS" basis 6073 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 6074 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 6075 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 6076 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 6077 FITNESS FOR A PARTICULAR PURPOSE. 6079 18 Expiration Date 6081 This memo is filed as and expires in 6082 October 2002. 6084 Appendix A. Diameter Service Template 6086 The following service template describes the attributes used by Diam- 6087 eter servers to advertise themselves. This simplifies the process of 6088 selecting an appropriate server to communicate with. A Diameter 6089 client can request specific Diameter servers based on characteristics 6090 of the Diameter service desired (for example, an AAA server to use 6091 for accounting.) 6093 Name of submitter: "Erik Guttman" 6094 Language of service template: en 6096 Security Considerations: 6097 Diameter clients and servers use various cryptographic mechanisms 6098 to protect communication integrity, confidentiality as well as 6099 perform end-point authentication. It would thus be difficult if 6100 not impossible for an attacker to advertise itself using SLPv2 and 6101 pose as a legitimate Diameter peer without proper preconfigured 6102 secrets or cryptographic keys. Still, as Diameter services are 6103 vital for network operation it is important to use SLPv2 authenti- 6104 cation to prevent an attacker from modifying or eliminating ser- 6105 vice advertisements for legitimate Diameter servers. 6107 Template text: 6108 -------------------------template begins here----------------------- 6109 template-type=service:diameter 6111 template-version=0.0 6113 template-description= 6114 The Diameter protocol is defined by draft-ietf-aaa-diameter-09.txt 6116 template-url-syntax= 6117 url-path= ; The Diameter URL format is described in section 2.9. 6118 ; Example: 'aaa://aaa.abc.com:1812;transport=tcp 6120 supported-auth-applications= string L M 6121 # This attribute lists the Diameter applications supported by the 6122 # AAA implementation. The applications currently defined are: 6123 # Application Name Defined by 6124 # ---------------- ----------------------------------- 6125 # NASREQ draft-ietf-aaa-diameter-nasreq-09.txt 6126 # MobileIP draft-ietf-aaa-diameter-mobileip-09.txt 6127 # CMS Security draft-ietf-aaa-diameter-cms-sec-04.txt 6128 # 6129 # Notes: 6130 # . Diameter implementations support one or more applications. 6131 # . Additional applications may be defined in the future. 6132 # An updated service template will be created at that time. 6133 # 6134 NASREQ,MobileIP,CMS Security 6136 supported-acct-applications= string L M 6137 # This attribute lists the Diameter applications supported by the 6138 # AAA implementation. The applications currently defined are: 6139 # Application Name Defined by 6140 # ---------------- ----------------------------------- 6141 # NASREQ draft-ietf-aaa-diameter-nasreq-09.txt 6142 # MobileIP draft-ietf-aaa-diameter-mobileip-09.txt 6143 # CMS Security draft-ietf-aaa-diameter-cms-sec-04.txt 6144 # 6145 # Notes: 6146 # . Diameter implementations support one or more applications. 6147 # . Additional applications may be defined in the future. 6148 # An updated service template will be created at that time. 6149 # 6150 NASREQ,MobileIP,CMS Security 6152 supported-transports= string L M 6153 SCTP 6154 # This attribute lists the supported transports that the Diameter 6155 # implementation accepts. Note that a compliant Diameter 6156 # implementation MUST support SCTP, though it MAY support other 6157 # transports, too. 6158 SCTP,TCP 6160 -------------------------template ends here----------------------- 6162 Appendix B. NAPTR Example 6164 As an example, consider a client that wishes to resolve aaa:ex.com. 6165 The client performs a NAPTR query for that domain, and the following 6166 NAPTR records are returned: 6168 ;; order pref flags service regexp replacement 6169 IN NAPTR 20 50 "s" "AAAS+D2S" "" 6170 _diameters._sctp.ex.com. IN NAPTR 50 50 "s" "AAA+D2S" 6171 "" _diameter._sctp.ex.com. IN NAPTR 90 50 "s" "AAAS+D2T" 6172 "" _diameters._tcp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T" 6173 "" _aaa._tcp.ex.com 6175 This indicates that the server supports TLS over SCTP, SCTP, TLS over 6176 TCP, and TCP, in that order. If the client supports TLS over SCTP, 6177 SCTP will be used, targeted to a host determined by an SRV lookup of 6178 _diameters._sctp.ex.com. That lookup would return: 6180 ;; Priority Weight Port Target 6181 IN SRV 0 1 5060 server1.ex.com IN SRV 0 2 6182 5060 server2.ex.com 6184 Appendix C. Duplicate Detection 6186 As described in section 9.4, accounting record duplicate detection is 6187 based on the session identifiers. Duplicates can appear for various 6188 reasons: 6190 - Failover to an alternate server. Where we close to real-time 6191 performance is expected, failover tresholds need to be kept low 6192 and this may lead to a relatively large likelihood of duplicates. 6194 - A crash of a client at the time it just had managed to send a 6195 record from a non-volatile memory would likely cause the same 6196 record to be sent soon after the client has rebooted. 6198 - Duplicates received from RADIUS gateways. 6200 - Implementation problems and misconfiguration. 6202 In some cases the Diameter accounting server can delay the duplicate 6203 detection and accounting record processing until a post-processing 6204 phase takes place. At that time records are likely to be sorted 6205 according to the User-Name contained in them and duplicate elimina- 6206 tion is easy in this case. 6208 In other situations it may be necessary to perform real-time dupli- 6209 cate detection, e.g. when the credit limits or fraud attempts are 6210 being monitored in real time. 6212 In general, only the duplicate generation at failover case is some- 6213 thing that can be reliably detected by the Diameter client. The 6214 Diameter server is therefore responsible for the duplicate detection 6215 process. When real-time duplicate detection is required, this implies 6216 a database-like search functionality to find duplicate records. 6217 Implementors are advised, however, that there exists ways to avoid 6218 expensive all-record searches. For instance, it can be usually safely 6219 assumed that duplicates appear within a time window of longest ima- 6220 ginable network partition, perhaps a day as an example. So only 6221 records within this time window need to be looked at. Secondly, hash- 6222 ing techniques or other schemes may be used to eliminate the need to 6223 do a full search even in this set except for rare cases.