idnits 2.17.1 draft-ietf-aaa-diameter-12.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 142 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 143 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 2 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 320 has weird spacing: '...ing for simpl...' == Line 385 has weird spacing: '...essages to re...' == Line 605 has weird spacing: '...oose to deplo...' == Line 1543 has weird spacing: '... answer messa...' == Line 4054 has weird spacing: '...ly with wit...' == (5 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 (July 2002) is 7954 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 6069, but not defined == Missing Reference: 'ROAMCRIT' is mentioned on line 6079, but not defined == Missing Reference: 'ROAMREV' is mentioned on line 293, but not defined == Missing Reference: 'PROXYCHAIN' is mentioned on line 6072, but not defined == Missing Reference: 'CDMA2000REQ' is mentioned on line 374, but not defined == Missing Reference: 'MIPREQ' is mentioned on line 6055, but not defined == Missing Reference: 'MIPV4' is mentioned on line 6052, but not defined == Missing Reference: 'NASNG' is mentioned on line 6059, but not defined == Missing Reference: 'NASCRIT' is mentioned on line 6066, but not defined == Missing Reference: 'DIAMMIP' is mentioned on line 6045, but not defined == Missing Reference: 'RADIUS' is mentioned on line 6075, but not defined == Missing Reference: 'NASREQ' is mentioned on line 6063, but not defined == Missing Reference: 'SECARCH' is mentioned on line 6082, but not defined == Missing Reference: 'AAACMS' is mentioned on line 6042, but not defined == Missing Reference: 'UFT8' is mentioned on line 1760, but not defined == Missing Reference: 'PXY' is mentioned on line 3819, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 6036, but not defined == Missing Reference: 'IPComp' is mentioned on line 6048, but not defined == Missing Reference: 'IPsec' is mentioned on line 5799, but not defined == Missing Reference: 'CDMA2000' is mentioned on line 6039, but not defined == Unused Reference: 'DIFFSERVAF' is defined on line 5958, but no explicit reference was found in the text == Unused Reference: 'DIFFSERVEF' is defined on line 5961, but no explicit reference was found in the text == Unused Reference: 'DNSSRV' is defined on line 5964, but no explicit reference was found in the text == Unused Reference: 'IANAWEB' is defined on line 5979, but no explicit reference was found in the text == Unused Reference: 'TLSSCTP' is defined on line 6024, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 6031, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AAATRANS' ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** 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: 17 errors (**), 0 flaws (~~), 40 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track John Loughney 5 Nokia 6 Erik Guttman 7 Sun Microsystems, Inc. 8 Glen Zorn 9 Cisco Systems, Inc. 10 Jari Arkko 11 Ericsson 12 Nokia 13 July 2002 15 Diameter Base Protocol 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Distribution of this memo is unlimited. 40 Copyright (C) The Internet Society 2002. All Rights Reserved. 42 Abstract 44 The Diameter base protocol is intended to provide an AAA framework 45 for applications such as network access or IP mobility. Diameter is 46 also intended to work both with local AAA and with roaming 47 situations. This draft specifies the message format, transport, error 48 reporting, accounting and security services to be used by all 49 Diameter applications and MUST be supported by all Diameter 50 implementations. 52 Table of Contents 54 1 Introduction 55 1.1 Diameter Protocol 56 1.1.1 Differences from RADIUS 57 1.1.2 Description of the Document Set 58 1.2 Approach to Extensibility 59 1.2.1 Defining New AVP Values 60 1.2.2 Creating New AVPs 61 1.2.3 Creating New Authentication Applications 62 1.2.4 Creating New Accounting Applications 63 1.2.5 Application Authentication Procedures 64 1.3 Requirements Language 65 1.4 Terminology 67 2 Protocol Overview 68 2.1 Transport 69 2.1.1 SCTP Guidelines 70 2.2 Securing Diameter Messages 71 2.3 Diameter Application Compliance 72 2.4 Application Identifiers 73 2.5 Connections vs. Sessions 74 2.6 Peer Table 75 2.7 Realm-Based Routing Table 76 2.8 Role of Diameter Agents 77 2.8.1 Relay Agents 78 2.8.2 Proxy Agents 79 2.8.3 Redirect Agents 80 2.8.4 Translation Agents 81 2.9 End-to-End Security Framework 83 3 Diameter Header 84 3.1 Command Codes 85 3.2 Command Code ABNF specification 86 3.3 Diameter Command Naming Conventions 88 4 Diameter AVPs 89 4.1 AVP Header 90 4.2 Optional Header Elements 91 4.3 Basic AVP Data Formats 92 4.4 Derived AVP Data Formats 93 4.5 Grouped AVP Values 94 4.5.1 Example AVP with a Grouped Data Type 95 4.6 Diameter Base Protocol AVPs 97 5 Diameter Peers 98 5.1 Peer Connections 99 5.2 Diameter Peer Discovery 100 5.3 Capabilities Exchange 101 5.3.1 Capabilities-Exchange-Request 102 5.3.2 Capabilities-Exchange-Answer 103 5.3.3 Vendor-Id AVP 104 5.3.4 Firmware-Revision AVP 105 5.3.5 Host-IP-Address AVP 106 5.3.6 Supported-Vendor-Id AVP 107 5.3.7 Product-Name AVP 108 5.4 Disconnecting Peer Connections 109 5.4.1 Disconnect-Peer-Request 110 5.4.2 Disconnect-Peer-Answer 111 5.4.3 Disconnect-Cause AVP 112 5.5 Transport Failure Detection 113 5.5.1 Device-Watchdog-Request 114 5.5.2 Device-Watchdog-Answer 115 5.5.3 Transport Failure Algorithm 116 5.5.4 Failover and Failback Procedures 117 5.6 Peer State Machine 118 5.6.1 Incoming connections 119 5.6.2 Events 120 5.6.3 Actions 121 5.6.4 The Election Process 123 6 Diameter Message Processing 124 6.1 Diameter Request Routing Overview 125 6.1.1 Originating a Request 126 6.1.2 Sending a Request 127 6.1.3 Receiving Requests 128 6.1.4 Processing Local Requests 129 6.1.5 Request Forwarding 130 6.1.6 Request Routing 131 6.1.7 Redirecting Requests 132 6.1.8 Relaying and Proxying Requests 133 6.2 Diameter Answer Processing 134 6.2.1 Processing Received Answers 135 6.2.2 Relaying and Proxying Answers 136 6.3 Origin-Host AVP 137 6.4 Origin-Realm AVP 138 6.5 Destination-Host AVP 139 6.6 Destination-Realm AVP 140 6.7 Routing AVPs 141 6.7.1 Route-Record AVP 142 6.7.2 Proxy-Info AVP 143 6.7.3 Proxy-Host AVP 144 6.7.4 Proxy-State AVP 145 6.8 Auth-Application-Id AVP 146 6.9 Acct-Application-Id AVP 147 6.10 Inband-Security-Id AVP 148 6.11 Vendor-Specific-Application-Id AVP 149 6.12 Redirect-Host AVP 150 6.13 Redirect-Host-Usage AVP 151 6.14 Redirect-Max-Cache-Time AVP 152 6.15 E2E-Sequence AVP 154 7 Error Handling 155 7.1 Result-Code AVP 156 7.1.1 Informational 157 7.1.2 Success 158 7.1.3 Protocol Errors 159 7.1.4 Transient Failures 160 7.1.5 Permanent Failures 161 7.2 Error Bit 162 7.3 Error-Message AVP 163 7.4 Error-Reporting-Host AVP 164 7.5 Failed-AVP AVP 165 7.6 Vendor-Specific-Result AVP 166 7.7 Vendor-Specific-Result-Code AVP 168 8 Diameter User Sessions 169 8.1 Authorization Session State Machine 170 8.2 Accounting Session State Machine 171 8.3 Server-Initiated Re-Auth 172 8.3.1 Re-Auth-Request 173 8.3.2 Re-Auth-Answer 174 8.4 Session Termination 175 8.4.1 Session-Termination-Request 176 8.4.2 Session-Termination-Answer 177 8.5 Aborting a Session 178 8.5.1 Abort-Session-Request 179 8.5.2 Abort-Session-Answer 180 8.6 Inferring Session Termination from Origin-State-Id 181 8.7 Auth-Request-Type AVP 182 8.8 Session-Id AVP 183 8.9 Authorization-Lifetime AVP 184 8.10 Auth-Grace-Period AVP 185 8.11 Auth-Session-State AVP 186 8.12 Re-Auth-Request-Type AVP 187 8.13 Session-Timeout AVP 188 8.14 User-Name AVP 189 8.15 Termination-Cause AVP 190 8.16 Origin-State-Id AVP 191 8.17 Session-Binding AVP 192 8.18 Session-Server-Failover AVP 193 8.19 Multi-Round-Time-Out AVP 194 8.20 Class AVP 195 8.21 Event-Timestamp AVP 197 9 Accounting 198 9.1 Server Directed Model 199 9.2 Protocol Messages 200 9.3 Application Document Requirements 201 9.4 Fault Resilience 202 9.5 Accounting Records 203 9.6 Correlation of Accounting Records 204 9.7 Accounting Command-Codes 205 9.7.1 Accounting-Request 206 9.7.2 Accounting-Answer 207 9.8 Accounting AVPs 208 9.8.1 Accounting-Record-Type AVP 209 9.8.2 Acct-Interim-Interval AVP 210 9.8.3 Accounting-Record-Number AVP 211 9.8.4 Accounting-RADIUS-Session-Id AVP 212 9.8.5 Acct-Multi-Session-Id AVP 213 9.8.6 Accounting-Sub-Session-Id AVP 214 9.8.7 Accounting-Realtime-Required AVP 216 10 AVP Occurrence Table 217 10.1 Base Protocol Command AVP Table 218 10.2 Accounting AVP Table 220 11 IANA Considerations 221 11.1 AVP Header 222 11.1.1 AVP Code 223 11.1.2 AVP Flags 224 11.2 Diameter Header 225 11.2.1 Command Codes 226 11.2.2 Command Flags 227 11.3 Application Identifiers 228 11.4 Result-Code AVP Values 229 11.5 Accounting-Record-Type AVP Values 230 11.6 Termination-Cause AVP Values 231 11.7 Redirect-Host-Usage AVP Values 232 11.8 Session-Server-Failover AVP Values 233 11.9 Session-Binding AVP Values 234 11.10 Diameter TCP/SCTP Port Numbers 235 11.11 Disconnect-Cause AVP Values 236 11.12 Auth-Request-Type AVP Values 237 11.13 Auth-Session-State AVP Values 238 11.14 Re-Auth-Request-Type AVP Values 239 11.15 NAPTR Service Fields 240 11.16 Accounting-Realtime-Required AVP Values 242 12 Diameter Protocol Related Configurable Parameters 244 13 Security Considerations 245 13.1 IPsec Usage 246 13.2 TLS Usage 247 13.3 Peer-to-Peer Considerations 249 14 References 250 14.1 Normative 251 14.2 Non-Normative 253 15 Acknowledgements 255 16 Authors' Addresses 257 17 Full Copyright Statement 259 18 Expiration Date 261 Appendix A. Diameter Service Template 263 Appendix B. NAPTR Example 265 Appendix C. Duplicate Detection 267 1 Introduction 269 Historically, the RADIUS protocol has been used to provide AAA 270 services for dial-up PPP [PPP] and terminal server access. Over time, 271 routers and network access servers (NAS) have increased in complexity 272 and density, making the RADIUS protocol increasingly unsuitable for 273 use in such networks. 275 Some of the major issues of using RADIUS include: 277 - RADIUS does not define a backoff procedure. 278 - RADIUS leaves failover mechanisms unspecified. 279 - Application layer acknowledgement is missing. 280 - The behaviour of proxies isn't clearly defined. 281 - The lack of error messages prevent intelligent failure responses. 282 - Transport security applied in RADIUS has no confidentiality, and 283 there are known attacks against it. 284 - Replay protection can only be done in post-processing. 285 - RADIUS does not protect data objects passed through it, and it is 286 open to man-in-the-middle attacks 288 The effort to fix RADIUS would be substantial, and the result would 289 be a protocol very close to Diameter. In fact, quite a bit of effort 290 has been made to insure that Diameter will interoperate with RADIUS. 292 The Roaming Operations Working Group (ROAMOPS) has published a set of 293 specifications [ROAMCRIT, ROAMREV, PROXYCHAIN] that define how a PPP 294 user can gain access to the Internet without having to dial into 295 his/her home service provider's modem pool. This is achieved by 296 allowing service providers to cross-authenticate their users. 297 Effectively, a user can dial into any service provider's point of 298 presence (POP) that has a roaming agreement with his/her home 299 Internet service provider (ISP), the benefit being that the user does 300 not have to incur a long distance charge while traveling, which can 301 sometimes be quite expensive. 303 Given the number of ISPs today, ROAMOPS realized that requiring each 304 ISP to set up roaming agreements with all other ISPs did not scale. 305 Therefore, the working group defined a "broker", which acts as an 306 intermediate server, whose sole purpose is to set up these roaming 307 agreements. A collection of ISPs and a broker is called a "roaming 308 consortium". There are many such brokers in existence today; many 309 also provide settlement services for member ISPs. 311 The Mobile-IP Working Group has recently changed its focus to inter- 312 administrative domain mobility, which is a requirement for cellular 313 carriers wishing to deploy IETF-based mobility protocols. The current 314 cellular carriers requirements [CDMA2000REQ, MIPREQ] are very similar 315 to the ROAMOPS model, with the exception that the access protocol is 316 Mobile-IP [MIPV4] instead of PPP. 318 The Network Access Server Requirements (NASREQ) working group has 319 focused on proving next generation Authentication, Authorization and 320 usage Accounting for simple dial-in access and beyond; such as 321 Virtual Private Network support, smart authentication methods, and 322 roaming concerns. The Working Group has published number of 323 documents including the requirements for NAS service protocols 324 [NASNG] as well as criteria for evaluating NAS protocols [NASCRIT]. 326 The basic concept behind Diameter is to provide a base protocol that 327 can be extended in order to provide AAA services to new access 328 technologies. Currently, the protocol only concerns itself with 329 Internet access, both in the traditional PPP sense as well as taking 330 into account the ROAMOPS model, and Mobile-IP. 332 Although Diameter could be used to solve a wider set of AAA problems, 333 we are currently limiting the scope of the protocol in order to 334 ensure that the effort remains focused on satisfying the requirements 335 of network access. Note that a truly generic AAA protocol used by 336 many applications might provide functionality not provided by 337 Diameter. Therefore, it is imperative that the designers of new 338 applications understand their requirements before using Diameter. 340 1.1 Diameter Protocol 342 The Diameter protocol allows peers to exchange a variety of messages. 343 The base protocol provides the following facilities: 345 - Delivery of AVPs (attribute value pairs) 346 - Capabilities negotiation, as required in [ROAMCRIT] 347 - Error notification 348 - Extensibility, through addition of new commands and AVPs, as 349 required in [NASCRIT] 350 - Basic services necessary for applications, such as handling of 351 user sessions or accounting 353 All data delivered by the protocol is in the form of an AVP. Some of 354 these AVP values are used by the Diameter protocol itself, while 355 others deliver data associated with particular applications that 356 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 357 so long as the required AVPs are included and AVPs that are 358 explicitly excluded are not included. AVPs are used by the base 359 Diameter protocol to support the following required features: 361 - Transporting of user authentication information, for the 362 purposes of enabling the Diameter server to authenticate the 363 user. 364 - Transporting of service specific authorization information, 365 between client and servers, allowing the peers to decide whether 366 a user's access request should be granted. 367 - Exchanging resource usage information, which MAY be used for 368 accounting purposes, capacity planning, etc. 369 - Relaying, proxying and redirecting of Diameter messages through 370 a server hierarchy. 372 The Diameter base protocol provides the minimum requirements needed 373 for an AAA transport protocol, as required by NASREQ [NASCRIT], 374 Mobile IP [CDMA2000REQ, MIPREQ], and ROAMOPS [ROAMCRIT]. The base 375 protocol is not intended to be used by itself, and must be used with 376 a Diameter application, such as Mobile IP [DIAMMIP]. The Diameter 377 protocol was heavily inspired by and builds upon the tradition of the 378 RADIUS [RADIUS] protocol. See section 2.4 for more information on 379 Diameter applications. 381 Any node can initiate a request. In that sense, Diameter is a peer- 382 to-peer protocol. In this document, a Diameter Client is a device at 383 the edge of the network that performs access control, such as 384 aNetwork Access Server (NAS) or a Foreign Agent (FA). A Diameter 385 client generates Diameter messages to request authentication, 386 authorization, and accounting services for the user. A Diameter agent 387 is a node that does not authenticate and/or authorize messages 388 locally. Examples of agents are proxies and relay agents. A Diameter 389 server is one that performs authentication and/or authorization of 390 the user based on some profile. A Diameter node MAY act as an agent 391 for certain requests while acting as a server for others. 393 The Diameter protocol also supports server-initiated messages towards 394 access devices, such as a request to abort service to a particular 395 user. 397 1.1.1 Differences from RADIUS 399 The Diameter protocol was not designed from the ground up. Instead, 400 the basic RADIUS model was retained while fixing the flaws in the 401 RADIUS protocol itself. Diameter does not share a common protocol 402 data unit (PDU) with RADIUS, but does borrow sufficiently from the 403 protocol to ease migration. The major differences include: 405 - Peer-to-peer nature 406 - Explicit support for intermediaries 407 - Connection-oriented versus connectionless transport 408 - Extensibility [see section 1.2] 409 - Built-in failover support 410 - Larger attribute space 411 - Integrated accounting 412 - Bit to indicate mandatory status of data 413 - Application-layer ACKs and error messages 414 - Unsolicited server messages 415 - Peer discovery 416 - Capabilities negotiation 417 - Stronger peer-to-peer security 418 - Optional end-to-end payload security 419 - Transport layer retransmission 421 1.1.2 Description of the Document Set 423 Currently, the Diameter specification consists of a base 424 specification (this document), Transport Issues [AAATRANS] and a 425 number of applications: Mobile IPv4 [DIAMMIP], NASREQ [NASREQ]. 427 The Transport Issues document [AAATRANS] discusses transport layer 428 issues that arise with AAA protocols and recommendations on how to 429 overcome these issues. 431 The Mobile IPv4 [DIAMMIP] application defines a Diameter application 432 that allows a Diameter server to perform AAA functions for Mobile 433 IPv4 services to a mobile node. 435 The NASREQ [NASREQ] application defines a Diameter Application that 436 allows a Diameter server to be used in a PPP/SLIP Dial-Up and 437 Terminal Server Access environment. Consideration was given for 438 servers that need to perform protocol conversion between Diameter and 439 RADIUS. 441 In summary, this document defines the base protocol specification for 442 AAA. The MIPv4 and the NASREQ documents describe applications that 443 use this base specification to achieve Authentication, Authorization 444 and Accounting. 446 1.2 Approach to Extensibility 448 The Diameter protocol is designed to be extensible. However, it is 449 strongly encouraged to reuse existing mechanisms before attempting 450 any Diameter extensions. The extensibility includes: 452 - Defining new AVP values. 453 - Creating new AVPs 454 - Creating new authentication/authorization applications 455 - Creating new accounting applications 456 - Application authentication procedures 458 Reuse of existing AVP values, AVPs, applications and command codes 459 are strongly recommended. Reuse simplifies standardization effort, 460 implentation effort and avoids potential interoperability issues. 462 1.2.1 Defining New AVP Values 464 New applications should attempt to reuse AVPs defined in existing 465 applications when possible, as opposed to creating new AVPs. For AVPs 466 of type Enumerated, it is possible the application requires a new 467 value to communicate some service-specific information. 469 In order to allocate a new AVP value, a request MUST be sent to IANA 470 [IANA], with a detailed explanation of the value along with 471 documenation on the new AVP value. 473 1.2.2 Creating New AVPs 475 When no existing AVP can be used appropriately to communicate some 476 service-specific information, a new AVP should be created. The new 477 AVP being defined MUST follow one of the types listed in section 4.3. 478 In the event that a logical grouping of AVPs is necessary, and 479 multiple "groups" are possible in a given command, it is highly 480 recommended that a Grouped AVP be used (see Section 4.5). 482 In order to create a new AVP, a request MUST be sent to IANA, with a 483 detailed explanation of the AVP, its type and possible values. 484 Furthermore, the request MUST include the commands that would make 485 use of the AVP. 487 1.2.3 Creating New Authentication Applications 489 Should a new application require Diameter support, but it cannot fit 490 within an existing application without requiring major changes to the 491 specification, it may be desirable to create a new Diameter 492 application. Major changes to an application include: 494 - Requiring a whole different set of mandatory AVPs to a command 495 - Requiring a command that has a different number of round trips 496 to satisfy a request (e.g. application foo has a command that 497 requires one round trip, but new application bar has a command 498 that requires two round trips to complete). 499 - The method used to authenticate the user is drastically 500 different from any existing application, and the authentication 501 information cannot be carried within the AVPs defined in the 502 application. 504 Note that the creation of a new application should be viewed as a 505 last resort. 507 New Diameter applications MUST define one Command Code or set of 508 mandatory AVPs. The expected AVPs MUST be defined in an ABNF [ABNF] 509 grammar (see section 3.2). A new application MAY also define new 510 AVPs. If the Diameter application has any accounting requirements, it 511 MUST also specify the AVPs that are to be present in the Diameter 512 Accounting messages (see section 9.3). 514 When possible, a new Diameter application SHOULD attempt to re-use 515 any existing Diameter AVP, in order to reduce the possibility of 516 having multiple AVPs that carry similar information. 518 Every Diameter application specification MUST have an IANA assigned 519 Application Identifier (see section 2.4) or a vendor specific 520 Application Identifier. 522 1.2.4 Creating New Accounting Applications 524 Services that have an Application Identifier MUST use the same 525 identifier also to identify the service when Diameter accounting is 526 used. 528 There are services that only require the use of Diameter accounting. 529 Such services need to define the service specific AVPs that must be 530 carried in the Accounting-Request/Answer messages, but do not need to 531 define command codes. Application Identifiers are, however, still 532 required for accounting due to the Diameter capability discovery 533 process. Every accounting application MUST have either an IANA 534 allocated Application Identifier, or a vendor specific Application 535 Identifier. 537 Note that the creation of a new application should be viewed as a 538 last resort and should be used only when Vendor-Specific AVPs are 539 insufficient. In most cases, reusing an existing Application ID with 540 Vendor-Specific AVPs should work. For example, many accounting 541 servers are set up to write AVPs to disk, so they can handle even 542 mandatory vendor-specific AVPs that they don't understand. 544 This is why "disk writing" accounting servers should advertise 545 themselves as "Relays" that can handle any Application ID, including 546 Vendor-Specific. 548 When possible, a new Diameter accounting application SHOULD attempt 549 to re-use any existing Diameter AVP, in order to reduce the 550 possibility of having multiple AVPs that carry similar information. 552 Every Diameter accounting application specification MUST have an IANA 553 assigned Application Identifier (see section 2.4) a vendor specific 554 Application Identifier. 556 1.2.5 Application Authentication Procedures 558 When possible, applications SHOULD be designed such that new 559 authentication methods MAY be added without requiring changes to the 560 application. This MAY require that new AVP values be assigned to 561 represent the new authentication transform, or any other scheme that 562 produces similar results. When possible, authentication frameworks, 563 such as Extensible Authentication Protocol [EAP], SHOULD be used. 565 1.3 Requirements Language 567 In this document, the key words "MAY", "MUST", "MUST NOT", 568 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 569 interpreted as described in [KEYWORDS]. 571 1.4 Terminology 573 AAA 574 Authentication, Authorization and Accounting. 576 Accounting 577 The act of collecting information on resource usage for the 578 purpose of capacity planning, auditing, billing or cost 579 allocation. 581 Accounting Record 582 A session record represents a summary of the resource consumption 583 of a user over the entire session. Accounting servers creating the 584 session record may do so by processing interim accounting events 585 or accounting events from several devices serving the same user. 587 Authentication 588 The act of verifying the identity of an entity (subject). 590 Authorization 591 The act of determining whether a requesting entity (subject) will 592 be allowed access to a resource (object). 594 AVP 595 The Diameter protocol consists of a header followed by one or more 596 Attribute-Value-Pairs (AVPs). An AVP includes a header and is used 597 to encapsulate protocol-specific data (e.g. routing information) 598 as well as authentication, authorization or accounting 599 information. 601 Broker 602 A broker is a business term commonly used in AAA infrastructures. 603 A broker is either a relay, proxy or redirect agent, and MAY be 604 operated by roaming consortiums. Depending on the business model, 605 a broker may either choose to deploy relay agents or proxy 606 agents. 608 Diameter Agent 609 A Diameter Agent is a Diameter node that provides either relay, 610 proxy, redirect or translation services. 612 Diameter Client 613 A Diameter Client is a device at the edge of the network that 614 performs access control. An example of a Diameter client is a 615 Network Access Server (NAS) or a Foreign Agent (FA). 617 Diameter Node 618 A Diameter node is a host process that implements the Diameter 619 protocol, and acts either as a Client, Agent or Server. 621 Diameter Peer 622 A Diameter Peer is a Diameter Node to which a given Diameter Node 623 has a direct transport connection. 625 Diameter Security Exchange 626 A Diameter Security Exchange is a process through which two 627 Diameter nodes establish end-to-end security. 629 Diameter Server 630 A Diameter Server is one that handles authentication, 631 authorization and accounting requests for a particular realm. By 632 its very nature, a Diameter Server MUST support Diameter 633 applications in addition to the base protocol. 635 Downstream 636 Downstream is used to identify the direction of a particular 637 Diameter message from the home server towards the access device. 639 End-to-End Security 640 TLS and IPsec provide hop-by-hop security, or security across a 641 transport connection. When relays or proxy are involved, this 642 hop-by-hop security does not protect the entire Diameter user 643 session. End-to-end security is security across a Diameter 644 session. 646 Home Realm 647 A Home Realm is the administrative domain with which the user 648 maintains an account relationship. 650 Home Server 651 See Diameter Server. 653 Interim accounting 654 An interim accounting message provides a snapshot of usage during 655 a user's session. It is typically implemented in order to provide 656 for partial accounting of a user's session in the case of a device 657 reboot or other network problem prevents the reception of a 658 session summary message or session record. 660 Local Realm 661 A local realm is the administrative domain providing services to a 662 user. An administrative domain MAY act as a local realm for 663 certain users, while being a home realm for others. 665 Multi-session 666 A multi-session represents a logical linking of several sessions. 667 Multi-sessions are tracked by using the Acct-Multi-Session-Id. An 668 example of a multi-session would be a Multi-link PPP bundle. Each 669 leg of the bundle would be a session while the entire bundle would 670 be a multi-session. 672 Network Access Identifier 673 The Network Access Identifier, or NAI [NAI], is used in the 674 Diameter protocol to extract a user's identity and realm. The 675 identity is used to identify the user during authentication and/or 676 authorization, while the realm is used for message routing 677 purposes. 679 Proxy Agent or Proxy 680 In addition to forwarding requests and responses, proxies make 681 policy decisions relating to resource usage and provisioning. This 682 is typically accomplished by tracking the state of NAS devices. 683 While proxies typically do not respond to client Requests prior to 684 receiving a Response from the server, they may originate Reject 685 messages in cases where policies are violated. As a result, 686 proxies need to understand the semantics of the messages passing 687 through them, and may not support all Diameter applications. 689 Realm 690 The string in the NAI that immediately follows the '@' character. 691 NAI realm names are required to be unique, and are piggybacked on 692 the administration of the DNS namespace. Diameter makes use of the 693 realm, also loosely referred to as domain, to determine whether 694 messages can be satisfied locally, or whether they must be routed 695 or redirected. In RADIUS, realm names are not necessarily 696 piggybacked on the DNS namespace but may be independent of it. 698 Real-time Accounting 699 Real-time accounting involves the processing of information on 700 resource usage within a defined time window. Time constraints are 701 typically imposed in order to limit financial risk. 703 Relay Agent or Relay 704 Relays forward requests and responses based on routing-related 705 AVPs and realm routing table entries. Since relays do not make 706 policy decisions, they do not examine or alter non-routing AVPs. 707 As a result, relays never originate messages, do not need to 708 understand the semantics of messages or non-routing AVPs, and are 709 capable of handling any Diameter application or message type. 710 Since relays make decisions based on information in routing AVPs 711 and realm forwarding tables they do not keep state on NAS resource 712 usage or sessions in progress. 714 Redirect Agent 715 Rather than forwarding requests and responses between clients and 716 servers, redirect agents refer clients to servers and allow them 717 to communicate directly. Since redirect agents do not sit in the 718 forwarding path, they do not alter any AVPs transiting between 719 client and server. Redirect agents do not originate messages and 720 are capable of handling any message type, although they may be 721 configured only to redirect messages of certain types, while 722 acting as relay or proxy agents for other types. As with proxy 723 agents, redirect agents do not keep state with respect to sessions 724 or NAS resources. 726 Roaming Relationships 727 Roaming relationships include relationships between companies and 728 ISPs, relationships among peer ISPs within a roaming consortium, 729 and relationships between an ISP and a roaming consortium. 731 Security Association 732 A security association is an association between two endpoints in 733 a Diameter session which allows the endpoints to communicate with 734 integrity and confidentially, even in the presense of relays 735 and/or proxies. 737 Session 738 A session is a related progression of events devoted to a 739 particular activity. Each application SHOULD provide guidelines as 740 to when a session begins and ends. All Diameter packets with the 741 same Session-Identifier are considered to be part of the same 742 session. 744 Sub-session 745 A sub-session represents a distinct service (e.g. QoS or data 746 characteristics) provided to a given session. These services may 747 happen concurrently (e.g. simultaneous voice and data transfer 748 during the same session) or serially. These changes in sessions 749 are tracked with the Accounting-Sub-Session-Id. 751 Translation Agent 752 A translation agent is a stateful Diameter node that performs 753 protocol translation between Diameter and another AAA protocol, 754 such as RADIUS. 756 Tranport Connection 757 A transport connection is a TCP or SCTP connection existing 758 directy between two Diameter peers, otherwise known as a Peer-to- 759 Peer Connection. 761 Upstream 762 Upstream is used to identify the direction of a particular 763 Diameter message from the access device towards the home server. 765 2 Protocol Overview 767 The base Diameter protocol is never used on its own. It is always 768 extended for a particular application. Two Diameter applications are 769 defined by companion documents: NASREQ [NASREQ], Mobile IP 770 [DIAMMIP]. These applications are introduced in this document but 771 specified elsewhere. Additional Diameter applications MAY be defined 772 in the future (see Section 11.3). 774 Diameter Clients MUST support the base protocol, which includes 775 accounting. In addition, they MUST fully support each Diameter 776 application that is needed to implement the client's service, e.g. 777 NASREQ and/or Mobile IP. A Diameter Client that does not support both 778 NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" 779 where X is the application which it supports, and not a "Diameter 780 Client." 782 Diameter Servers MUST support the base protocol, which includes 783 accounting. In addition, they MUST fully support each Diameter 784 application that is needed to implement the intended service, e.g. 785 NASREQ and/or Mobile IP. A Diameter Server that does not support both 786 NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" 787 where X is the application which it supports, and not a "Diameter 788 Server." 790 Diameter Relays and Redirect agents are, by definition, protocol 791 transparent, and MUST transparently support the Diameter base 792 protocol, which includes accounting, and all Diameter applications. 794 Diameter Proxies MUST support the base protocol, which includes 795 accounting. In addition, they MUST fully support each Diameter 796 application that is needed to implement proxied services, e.g. NASREQ 797 and/or Mobile IP. A Diameter Proxy which does not support also both 798 NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" where 799 X is the application which it supports, and not a "Diameter Proxy." 801 The base Diameter protocol concerns itself with capabilities 802 negotiation, how messages are sent and how peers may eventually be 803 abandoned. The base protocol also defines certain rules that apply 804 to all exchanges of messages between Diameter nodes. 806 Communication between Diameter peers begins with one peer sending a 807 message to another Diameter peer. The set of AVPs included in the 808 message is determined by a particular Diameter application. One AVP 809 that is included to reference a user's session is the Session-Id. 811 The initial request for authentication and/or authorization of a user 812 would include the Session-Id. The Session-Id is then used in all 813 subsequent messages to identify the user's session (see section 8 for 814 more information). The communicating party may accept the request, or 815 reject it by returning an answer message with the Result-Code AVP set 816 to indicate an error occurred. The specific behavior of the Diameter 817 server or client receiving a request depends on the Diameter 818 application employed. 820 Session state (associated with a Session-Id) MUST be freed upon 821 receipt of the Session-Termination-Request, Session-Termination- 822 Answer, expiration of authorized service time in the Session-Timeout 823 AVP, and according to rules established in a particular Diameter 824 application. 826 2.1 Transport 828 The base Diameter protocol is run on port TBD of both TCP [TCP] and 829 SCTP [SCTP] transport protocols (for interoperability test purposes 830 port 1812 will be used until IANA assigns a port to the protocol). 832 Diameter clients MUST support either TCP or SCTP, while agents and 833 servers MUST support both. Future versions of this specification MAY 834 mandate that clients support SCTP. 836 A Diameter node MAY initiate connections from a source port other 837 than the one that it declares it accepts incoming connections on, and 838 MUST be prepared to receive connections on port TBD. A given Diameter 839 instance of the peer state machine MUST NOT use more than one 840 transport connection to communicate with a given peer, unless 841 multiple instances exist on the peer in which case a separate 842 connection per process is allowed. 844 When no transport connection exists with a peer, an attempt to 845 connect SHOULD be periodically attempted. This behavior is handled 846 via the Tc timer, who's recommended value is 30 seconds. There are 847 certain exceptions to this rule, such as when a peer has terminated 848 the transport connection stating that it does not wish to 849 communicate. 851 When connecting to a peer and either zero or more transports are 852 specified, SCTP SHOULD be tried first, followed by TCP. See section 853 5.2 for more information on peer discovery. 855 Diameter implementations SHOULD be able to interpret ICMP protocol 856 port unreachable messages as explicit indications that the server is 857 not reachable, subject to security policy on trusting such messages. 858 Diameter implementations SHOULD also be able to interpret 859 ECONNREFUSED (a reset from the transport) and timed-out connection 860 attempts. 862 If Diameter receives data up from TCP that cannot be parsed or 863 identified as a Diameter error made by the peer, the stream is 864 compromised and cannot be recovered. The transport connection MUST 865 be closed using a RESET call (graceful closure is also compromised). 867 2.1.1 SCTP Guidelines 869 The following are guidelines for Diameter implementations that 870 support SCTP: 872 1. For interoperability: All Diameter nodes MUST be prepared to 873 receive Diameter messages on any SCTP stream in the 874 association. 875 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 876 streams available to the association to prevent head-of-the- 877 line blocking. 879 2.2 Securing Diameter Messages 881 Diameter clients, such as Network Access Servers (NASes) and Mobility 882 Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. 883 Diameter servers MUST support TLS and IPsec. The Diameter protocol 884 MUST NOT be used without any security mechanism (TLS or IPsec). 886 It is suggested that IPsec can be used primarily at the edges and in 887 intra-domain traffic, such as using pre-shared keys between a NAS a 888 local AAA proxy. This also eases the requirements on the NAS to 889 support certificates. It is also suggested that inter-domain traffic 890 would primarily use TLS. See sections 13.1 and 13.2 for more details 891 on IPsec and TLS usage. 893 2.3 Diameter Application Compliance 895 Application Identifiers are advertised during the capabilities 896 exchange phase (see section 5.3). For a given application, 897 advertising support of an application implies that the sender 898 supports all command codes, and the AVPs specified in the associated 899 ABNFs, described in the specification. 901 An implementation MAY add arbitrary AVPs to any command defined in an 902 application, including vendor-specific AVPs. Please refer to section 903 11.1.1 for details. 905 2.4 Application Identifiers 907 Each Diameter application MUST have an IANA assigned Application 908 Identifier (see section 11.3). The base protocol does not require an 909 Application Identifier since its support is mandatory. During the 910 capabilities exchange, Diameter nodes inform their peers of locally 911 supported applications. Furthermore, all Diameter messages contain an 912 Application Identifier, which is used in the message forwarding 913 process. 915 The following Application Identifier values are defined: 917 NASREQ 1 [NASREQ] 918 Mobile-IP 4 [DIAMMIP] 919 Relay 0xffffffff 921 Relay and redirect agents MUST advertise the Relay Application 922 Identifier, accounting servers capable of storing any records MUST 923 advertise the Relay Application Identifier for accounting, while all 924 other Diameter nodes MUST advertise locally supported applications. 925 The receiver of a Capabilities Exchange message advertising Relay 926 service MUST assume that the sender supports all current and future 927 applications. 929 Diameter relay and proxy agents are responsible for finding an 930 upstream server that supports the application of a particular 931 message. If none can be found, an error message is returned with the 932 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 934 2.5 Connections vs. Sessions 936 This section attempts to provide the reader with an understanding of 937 the difference between connection and session, which are terms used 938 extensively throughout this document. 940 A connection is a transport level connection between two peers, used 941 to send and receive Diameter messages. A session is a logical concept 942 at the application layer, and is shared between an access device and 943 a server, and is identified via the Session-Id AVP 945 +--------+ +-------+ +--------+ 946 | Client | | Relay | | Server | 947 +--------+ +-------+ +--------+ 948 <----------> <----------> 949 peer connection A peer connection B 951 <-----------------------------> 952 User session x 953 Figure 1: Diameter connections and sessions 955 In the example provided in Figure 1, peer connection A is established 956 between the Client and its local Relay. Peer connection B is 957 established between the Relay and the Server. User session X spans 958 from the Client via the Relay to the Server. Each "user" of a service 959 causes an auth request to be sent, with a unique session identifier. 960 Once accepted by the server, both the client and the server are aware 961 of the session. It is important to note that there is no relationship 962 between a connection and a session, and that Diameter messages for 963 multiple sessions are all multiplexed through a single connection. 965 2.6 Peer Table 967 The Diameter Peer Table is used in message forwarding, and referenced 968 by the Realm Routing Table. A Peer Table entry contains the following 969 fields: 971 - Host identity. Following the conventions described for the 972 DiameterIdentity derived AVP data format in section 4.4. This 973 field contains the contents of the Origin-Host AVP found in the 974 CER or CEA message. 975 - Status. This is the state of the peer entry, and MUST match one 976 of the values listed in section 5.6. 977 - Static or Dynamic. Specifies whether a peer entry was statically 978 configured, or dynamically discovered. 979 - Expiration time. Specifies the time at which dynamically 980 discovered peer table entries are to be either refreshed, or 981 expired. 982 - TLS Enabled. Specifies whether TLS is to be used when 983 communicating with the peer. 984 - Additional security information, when needed (e.g. keys, 985 certificates) 987 2.7 Realm-Based Routing Table 989 All Realm-Based routing lookups are performed against what is 990 commonly known as the Realm Routing Table (see section 12). A Realm 991 Routing Table Entry contains the following fields: 993 - Realm Name. This is the field that is typically used as a 994 primary key in the routing table lookups. Note that some 995 implementations perform their lookups based on longest-match- 996 from-the-right on the realm rather than requiring an exact 997 match. 998 - Application Identifier. An application is identified by a vendor 999 id and an application id. For all IETF standards track Diameter 1000 applications, the vendor id is zero. A route entry can have a 1001 different destination based on the application identification 1002 avp of the message. This field MUST be used as a secondary key 1003 field in routing table lookups. 1004 - Local Action. The Local Action field is used to identify how a 1005 message should be treated. The following actions are supported: 1006 1. LOCAL - Diameter messages that resolve to a route entry 1007 with the Local Action set to Local can be satisfied 1008 locally, and do not need to be routed to another server. 1009 2. RELAY - All Diameter messages that fall within this 1010 category MUST be routed to a next hop server, without 1011 modifying any non-routing AVPs. See section 6.1.8 for 1012 relaying guidelines 1013 3. PROXY - All Diameter messages that fall within this 1014 category MUST be routed to a next hop server. The local 1015 server MAY apply its local policies to the message by 1016 including new AVPs to the message prior to routing. See 1017 section 6.1.8 for proxying guidelines. 1018 4. REDIRECT - Diameter messages that fall within this 1019 category MUST have the identity of the home Diameter 1020 server(s) appended, and returned to the sender of the 1021 message. See section 6.1.7 for redirect guidelines. 1022 - Server Identifier. One or more servers the message is to be 1023 routed to. These servers MUST also be present in the Peer table. 1024 When the Local Action is set to RELAY or PROXY, this field 1025 contains the identity of the server(s) the message must be 1026 routed to. When the Local Action field is set to REDIRECT, this 1027 field contains the identity of one or more servers the message 1028 should be redirected to. 1029 - Static or Dynamic. Specifies whether a route entry was 1030 statically configured, or dynamically discovered. 1031 - Expiration time. Specifies the time which a dynamically 1032 discovered route table entry expires. 1034 It is important to note that Diameter agents MUST support at least 1035 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents 1036 do not need to support all modes of operation in order to conform 1037 with the protocol specification, but MUST follow the protocol 1038 compliance guidelines in section 2. Relay agents MUST NOT reorder 1039 AVPs, and proxies MUST NOT reorder AVPs. 1041 The routing table MAY include a default entry that MUST be used for 1042 any requests not matching any of the other entries. The routing table 1043 MAY consist of only such an entry. 1045 When a request is routed, the target server MUST have advertised the 1046 Application Identifier (see section 2.4) for the given message, or 1047 have advertised itself as a relay or proxy agent. Otherwise, an error 1048 is returned with the Result-Code AVP set to 1049 DIAMETER_UNABLE_TO_DELIVER. 1051 2.8 Role of Diameter Agents 1053 In addition to client and servers, the Diameter protocol introduces 1054 relay, proxy, redirect, and translation agents, each of which is 1055 defined in Section 1.4. These Diameter agents are useful for several 1056 reasons: 1058 - They can distribute administration of systems to a configurable 1059 grouping, including the maintenance of security associations. 1060 - They can be used for concentration of requests from an number of 1061 co-located or distributed NAS equipment sets to a set of like 1062 user groups. 1063 - They can do value-added processing to the requests or responses. 1064 - They can be used for load balancing. 1065 - A complex network will have multiple authentication sources, 1066 they can sort requests and forward towards the correct target. 1068 The Diameter protocol requires that agents maintain transaction 1069 state, which is used for failover purposes. Transaction state implies 1070 that upon forwarding a request, its Hop-by-Hop identifier is saved; 1071 the field is replaced with a locally unique identifier, which is 1072 restored to its original value when the corresponding answer is 1073 received. The request's state is released upon receipt of the answer. 1074 A stateless agent is one that only maintains transaction state. 1076 The Proxy-Info AVP allows stateless agents to add local state to a 1077 Diameter request, with the guarantee that the same state will be 1078 present in the answer. However, the protocol's failover procedures 1079 require that agents maintain a copy of pending requests. 1081 A stateful agent is one that maintains session state information; by 1082 keeping track of all authorized active sessions. Each authorized 1083 session is bound to a particular service, and its state is considered 1084 active either until it is notified otherwise, or by expiration. Each 1085 authorized session has an expiration, which is communicated by 1086 Diameter servers via the Session-Timeout AVP. 1088 Maintaining session state MAY be useful in certain applications, such 1089 as: 1091 - Protocol translation (e.g. RADIUS <-> Diameter) 1092 - Limiting resources authorized to a particular user 1093 - Per user or transaction auditing 1095 A Diameter agent MAY act in a stateful manner for some requests and 1096 be stateless for others. A Diameter implementation MAY act as one 1097 type of agent for some requests, and as another type of agent for 1098 others. 1100 2.8.1 Relay Agents 1102 Relay Agents are Diameter agents that accept requests and route 1103 messages to other Diameter nodes based on information found in the 1104 messages (e.g. Destination-Realm). This routing decision is performed 1105 using a list of supported realms, and known peers. This is known as 1106 the Realm Routing Table, as is defined further in section 2.7. 1108 Relays MAY be used to aggregate requests from multiple Network Access 1109 Servers (NASes) within a common geographical area (POP). The use of 1110 Relays is advantageous since it eliminates the need for NASes to be 1111 configured with the necessary security information they would 1112 otherwise require to communicate with Diameter servers in other 1113 realms. Likewise, this reduces the configuration load on Diameter 1114 servers that would otherwise be necessary when NASes are added, 1115 changed or deleted. 1117 Relays modify Diameter messages by inserting, and removing routing 1118 information, but do not modify any other portion of a message. 1119 Further, Relays' inherent simplicity implies that they are stateless 1120 and therefore SHOULD NOT maintain session state but MUST maintain 1121 transaction state. 1123 +------+ ---------> +------+ ---------> +------+ 1124 | | 1. Request | | 2. Request | | 1125 | NAS | | DRL | | HMS | 1126 | | 4. Answer | | 3. Answer | | 1127 +------+ <--------- +------+ <--------- +------+ 1128 mno.net mno.net abc.com 1129 Figure 2: Relaying of Diameter messages 1131 The example provided in Figure 2 depicts a request issued from NAS, 1132 which is an access device, for the user bob@abc.com. Prior to issuing 1133 the request, NAS performs a Diameter route lookup, using "abc.com" as 1134 the key, and determines that the message is to be relayed to DRL, 1135 which is a Diameter Relay. DRL performs the same route lookup as NAS, 1136 and relays the message to HMS, which is abc.com's Home Diameter 1137 Server. HMS identifies that the request can be locally supported (via 1138 the realm), processes the authentication and/or authorization 1139 request, and replies with an answer, which is routed back to NAS 1140 using saved transaction state. 1142 Since Relays do not perform any application level processing, they 1143 provide relaying services for all Diameter applications, and 1144 therefore MUST advertise the Relay Application Identifier. 1146 2.8.2 Proxy Agents 1148 Similarly to Relays, Proxy agents route Diameter messages using the 1149 Diameter Routing Table. However, they differ since they modify 1150 messages to implement policy enforcement. This requires that proxies 1151 maintain the state of their downstream peers (e.g. access devices) to 1152 enforce resource usage, provide admission control, and provisioning. 1154 It is important to note that although proxies MAY provide a value-add 1155 function for NASes, they do not allow access devices to use end-to- 1156 end security, since modifying messages breaks authentication. 1158 Proxies MAY be used in call control centers or access ISPs that 1159 provide outsourced connections, they can monitor the number and types 1160 of ports in use, and make allocation and admission decisions 1161 according to their configuration. 1163 Proxies that wish to limit resources MUST be stateful, and all 1164 Proxies MUST maintain transaction state. 1166 Since enforcing policies requires an understanding of the service 1167 being provided, Proxies MUST only advertise the Diameter applications 1168 they support. 1170 2.8.3 Redirect Agents 1172 Redirect agents provide Realm to Server address resolution and MAY 1173 also provide User to Server address resolution. These redirect agents 1174 would make use of the Diameter routing table or optionally, a user 1175 table to determine where a given request should be forwarded. When a 1176 request is received by a redirect agent, a special answer is created, 1177 which includes the identity of the Diameter server(s) the originator 1178 of the request should contact directly. 1180 Redirect agents are useful in scenarios where the Diameter routing 1181 configuration needs to be centralized. An example is a redirect agent 1182 that provides services to all members of a consortium, but does not 1183 wish to be burdened with relaying all messages between realms. This 1184 scenario is advantageous since it does not require that the 1185 consortium provide routing updates to its members when changes are 1186 made to a member's infrastructure. 1188 Since redirect agents do not relay messages, and only return an 1189 answer with the information necessary for Diameter agents to 1190 communicate directly, they do not modify messages. Since redirect 1191 agents do not receive answer messages, they cannot maintain session 1192 state. Further, since redirect agents never relay requests, they are 1193 not required to maintain transaction state. 1195 The example provided in Figure 3 depicts a request issued from the 1196 access device, NAS, for the user bob@abc.com. The message is 1197 forwarded by the NAS to its relay, DRL, which does not have a routing 1198 entry in its Diameter Routing Table for abc.com. DRL has a default 1199 route configured to DRD, which is a redirect agent that returns a 1200 redirect notification to DRL, as well as HMS' contact information. 1201 Upon receipt of the redirect notification, DRL establishes a 1202 transport connection with HMS, if one doesn't already exist, and 1203 forwards the request to it. 1205 +------+ 1206 | | 1207 | DRD | 1208 | | 1209 +------+ 1210 ^ | 1211 2. Request | | 3. Redirection 1212 | | Notification 1213 | v 1214 +------+ ---------> +------+ ---------> +------+ 1215 | | 1. Request | | 4. Request | | 1216 | NAS | | DRL | | HMS | 1217 | | 6. Answer | | 5. Answer | | 1218 +------+ <--------- +------+ <--------- +------+ 1219 mno.net mno.net abc.com 1220 Figure 3: Redirecting a Diameter Message 1222 Since Redirect agents do not perform any application level 1223 processing, they provide relaying services for all Diameter 1224 applications, and therefore MUST advertise the Relay Application 1225 Identifier. 1227 2.8.4 Translation Agents 1229 A Translation Agent is a device that provides translation between two 1230 protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation 1231 agents are likely to be used as aggregation servers to communicate 1232 with a Diameter infrastructure, while allowing for the embedded 1233 systems to be migrated at a slower pace. 1235 Given that the Diameter protocol introduces the concept of long-lived 1236 authorized sessions, translation agents MUST be session stateful and 1237 MUST maintain transaction state. 1239 Translation of messages can only occur if the agent recognizes the 1240 application of a particular request, and therefore translation agents 1241 MUST only advertise their locally supported applications. 1243 +------+ ---------> +------+ ---------> +------+ 1244 | | RADIUS Request | | Diameter Request | | 1245 | NAS | | TLA | | HMS | 1246 | | RADIUS Answer | | Diameter Answer | | 1247 +------+ <--------- +------+ <--------- +------+ 1248 mno.net mno.net abc.com 1249 Figure 4: Translation of RADIUS to Diameter 1251 2.9 End-to-End Security Framework 1252 The basic components of end-to-end security include encryption and 1253 message origin authentication, or in otherwords, AVP integrity and 1254 confidentiality between two peers communicating through agents. 1256 End-to-end security can be provided by an end-to-end security 1257 extension, which is not defined in the base protocol specification. 1258 There is ongoing work toward an end-to-end security session [AAACMS] 1260 The circumstances requiring the use of end-to-end security are 1261 determined by service provider policy. This policy is not the subject 1262 of standardization. This policy may be indexed by next hop Diameter 1263 peer or by destination realm. For example, use of TLS or IPsec for 1264 Diameter peers communicating in on a peer-to-peer basis, without 1265 relays or proxies may be sufficient in many cases. 1267 The use of end-to-end security can be classified as the following: 1269 - Never use end-to-end security. 1271 - Use end-to-end security on messages containing sensitive AVPs. 1272 Which AVPs are sensitive is determined by service provider 1273 policy. AVPs containing keys and passwords should be considered 1274 sensitive. Accounting AVPs may be considered sensitive. Any 1275 AVP for which the P bit may be set or which may be encrypted may 1276 be considered sensitive. 1278 Always use end-to-end security. 1280 It is strongly recommended that all Diameter implementations support 1281 end-to-end security. 1283 3 Diameter Header 1285 A summary of the Diameter header format is shown below. The fields 1286 are transmitted in network byte order. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Ver | Message Length | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 |R P E r r r r r| Command-Code | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Application-ID | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Hop-by-Hop Identifier | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | End-to-End Identifier | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | AVPs ... 1302 +-+-+-+-+-+-+-+-+-+-+-+-+- 1304 Version 1305 This Version field MUST be set to 1 to indicate Diameter Version 1306 1. 1308 Message Length 1309 The Message Length field is three octets and indicates the length 1310 of the Diameter message including the header fields. 1312 Command Flags 1313 The Command Flags field is eight bits. The following bits are 1314 assigned: 1316 R(equest) - If set, the message is a request. If cleared, the 1317 message is an answer. 1318 P(roxiable) - If set, the message MAY be proxied, relayed or 1319 redirected. If cleared, the message MUST be 1320 locally processed. 1321 E(rror) - If set, the message contains a protocol error, 1322 and the message will not conform to the ABNF 1323 described for this command. Messages with the 'E' 1324 bit set are commonly referred to as an error 1325 messages. This bit MUST NOT be set in request 1326 messages. See section 7.2. 1327 r(eserved) - these flag bits are reserved for future use, and 1328 MUST be set to zero, otherwise an error MUST be 1329 sent to the sender. 1331 Command-Code 1332 The Command-Code field is three octets, and is used in order to 1333 communicate the command associated with the message. The 24-bit 1334 address space is managed by IANA (see section 11.2.1). 1336 Command-Code values in the range 0xfffff0 through 0xffffff are 1337 reserved for experimental use. Commands in this range MUST use an 1338 IANA-assigned Application ID from the range 0xff00000000 - 1339 0xfffffffe (see Section 11.3). Commands in this range MUST also 1340 include a Vendor-Specific Application ID AVP (see section 6.11). 1342 Application-ID 1344 Application-ID is four octets and is used to identify to which 1345 application the message is applicable for. The application can be 1346 an authentication application, an accounting application or a 1347 vendor specific application. See section 11.3 for the possible 1348 values that the application-id may use. 1350 The application-id in the header MUST be the same as what is 1351 contained in any relevant AVPs contained in the message. 1353 Hop-by-Hop Identifier 1354 The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in 1355 network byte order) and aids in matching requests and replies. The 1356 sender MUST ensure that the Hop-by-Hop identifier in a request is 1357 unique on a given connection at any given time, and MAY attempt to 1358 ensure that the number is unique across reboots. The sender of an 1359 Answer message MUST ensure that the Hop-by-Hop Identifier field 1360 contains the same value that was found in the corresponding 1361 request. The Hop-by-Hop identifier is normally a monotonically 1362 increasing number, whose start value was randomly generated. An 1363 answer message that is received with an unknown Hop-by-Hop 1364 Identifier MUST be discarded. 1366 End-to-End Identifier 1367 The End-to-End Identifier is an unsigned 32-bit integer field (in 1368 network byte order) and is used to detect duplicate messages. Upon 1369 reboot implementations MAY set the high order 12 bits to contain 1370 the low order 12 bits of current time, and the low order 20 bits 1371 to a random value. Senders of request messages MUST insert a 1372 unique identifier on each message. The identifier MUST remain 1373 locally unique for a period of at least 4 minutes, even across 1374 reboots. The originator of an Answer message MUST ensure that the 1375 End-to-End Identifier field contains the same value that was found 1376 in the corresponding request. The End-to-End Identifier MUST NOT 1377 be modified by relay agents. The combination of the Origin-Host 1378 and this field is used to detect duplicates. Duplicate requests 1379 SHOULD cause the same answer to be transmitted (modulo the hop- 1380 by-hop Identifier field and any routing AVPs that may be present), 1381 and MUST NOT affect any state that was set when the original 1382 request was processed. Duplicate answer messages that are to be 1383 locally consumed (see Section 6.2) SHOULD be silently discarded. 1385 AVPs 1386 AVPs are a method of encapsulating information relevant to the 1387 Diameter message. See section 4 for more information on AVPs. 1389 3.1 Command Codes 1391 Each command Request/Answer pair is assigned a command code, and the 1392 sub-type (i.e. - request or answer) is identified via the 'R' bit in 1393 the Command Flags field of the Diameter header. 1395 Every Diameter message MUST contain a command code in its header's 1396 Command-Code field, which is used to determine the action that is to 1397 be taken for a particular message. The following Command Codes are 1398 defined in the Diameter base protocol: 1400 Command-Name Abbrev. Code Reference 1401 -------------------------------------------------------- 1402 Abort-Session-Request ASR 274 8.5.1 1403 Abort-Session-Answer ASA 274 8.5.2 1404 Accounting-Request ACR 271 9.7.1 1405 Accounting-Answer ACA 271 9.7.2 1406 Capabilities-Exchange- CER 257 5.3.1 1407 Request 1408 Capabilities-Exchange- CEA 257 5.3.2 1409 Answer 1410 Device-Watchdog-Request DWR 280 5.5.1 1411 Device-Watchdog-Answer DWA 280 5.5.2 1412 Disconnect-Peer-Request DPR 282 5.4.1 1413 Disconnect-Peer-Answer DPA 282 5.4.2 1414 Re-Auth-Request RAR 258 8.3.1 1415 Re-Auth-Answer RAA 258 8.3.2 1416 Session-Termination- STR 275 8.4.1 1417 Request 1418 Session-Termination- STA 275 8.4.2 1419 Answer 1421 3.2 Command Code ABNF specification 1423 Every Command Code defined MUST include a corresponding ABNF 1424 specification, which is used to define the AVPs that MUST or MAY be 1425 present. The following format is used in the definition: 1427 command-def = command-name "::=" diameter-message 1428 command-name = diameter-name 1430 diameter-name = ALPHA *(ALPHA / DIGIT / "-") 1432 diameter-message = header [ *fixed] [ *required] [ *optional] 1433 [ *fixed] 1435 header = "<" Diameter-Header:" command-id 1436 [r-bit] [p-bit] [e-bit] ">" 1438 command-id = 1*DIGIT 1439 ; The Command Code assigned to the command 1441 r-bit = ", REQ" 1442 ; If present, the 'R' bit in the Command 1443 ; Flags is set, indicating that the message 1444 ; is a request, as opposed to an answer. 1446 p-bit = ", PXY" 1447 ; If present, the 'P' bit in the Command 1448 ; Flags is set, indicating that the message 1449 ; is proxiable. 1451 e-bit = ", ERR" 1452 ; If present, the 'E' bit in the Command 1453 ; Flags is set, indicating that the answer 1454 ; message contains a Result-Code AVP in 1455 ; the "protocol error" class. 1457 fixed = [qual] "<" avp-spec ">" 1458 ; Defines the fixed position of an AVP 1460 required = [qual] "{" avp-spec "}" 1461 ; The AVP MUST be present and can appear 1462 ; anywhere in the message. 1464 optional = [qual] "[" avp-name "]" 1465 ; The avp-name in the 'optional' rule cannot 1466 ; evaluate to any AVP Name which is included 1467 ; in a fixed or required rule. The AVP can 1468 ; appear anywhere in the message. 1470 qual = [min] "*" [max] 1471 ; See ABNF conventions, RFC 2234 section 6.6. 1472 ; The absence of any qualifiers depends on whether 1473 ; it precedes a fixed, required, or optional 1474 ; rule. If a fixed or required rule has no 1475 ; qualifier, then exactly one such AVP MUST 1476 ; be present. If an optional rule has no 1477 ; qualifier, then 0 or 1 such AVP may be 1478 ; present. 1479 ; 1480 ; NOTE: "[" and "]" have a different meaning 1481 ; than in ABNF (see the optional rule, above). 1482 ; These braces cannot be used to express 1483 ; optional fixed rules (such as an optional 1484 ; ICV at the end.) To do this, the convention 1485 ; is '0*1fixed'. 1487 min = 1*DIGIT 1488 ; The minimum number of times the element may 1489 ; be present. The default value is zero. 1491 max = 1*DIGIT 1492 ; The maximum number of times the element may 1493 ; be present. The default value is infinity. A 1494 ; value of zero implies the AVP MUST NOT be 1495 ; present. 1497 avp-spec = diameter-name 1498 ; The avp-spec has to be an AVP Name, defined 1499 ; in the base or extended Diameter 1500 ; specifications. 1502 avp-name = avp-spec / "AVP" 1503 ; The string "AVP" stands for *any* arbitrary 1504 ; AVP Name, which does not conflict with the 1505 ; required or fixed position AVPs defined in 1506 ; the command code definition. 1508 The following is a definition of a fictitious command code: 1510 Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY > 1511 { User-Name } 1512 * { Origin-Host } 1513 * [ AVP ] 1515 3.3 Diameter Command Naming Conventions 1517 Diameter commands typically includes one or more English words 1518 followed by the verb Request or Answer. Each English word is 1519 delimited by a hyphen. A three-letter acronym for both the request 1520 and answer is also normally provided. 1522 An example is a message set used to terminate a session. The command 1523 name is Session-Terminate-Request and Session-Terminate-Answer, while 1524 the acronyms are STR and STA, respectively. 1526 Both the request and the answer for a given command share the same 1527 command code. The request is identified by the R(equest) bit in the 1528 Diameter header set to one (1), to ask that a particular action be 1529 performed, such as authorizing a user or terminating a session. Once 1530 the receiver has completed the request it issues the corresponding 1531 answer, which includes a result code that communicates one of the 1532 following: 1534 - The request was successful 1535 - The request failed 1536 - An additional request must be sent to provide information the 1537 peer requires prior to returning a successful or failed answer. 1538 - The receiver could not process the request, but provides 1539 information about a Diameter peer that is able to satisfy the 1540 request, known as redirect. 1542 Additional information, encoded within AVPs, MAY also be 1543 included in answer messages. 1545 4 Diameter AVPs 1547 Diameter AVPs carry specific authentication, accounting, 1548 authorization, routing and security information as well as 1549 configuration details for the request and reply. 1551 Some AVPs MAY be listed more than once. The effect of such an AVP is 1552 specific, and is specified in each case by the AVP description. 1554 Each AVP of type OctetString MUST be padded to align on a 32-bit 1555 boundary, while other AVP types align naturally. Zero bytes are added 1556 to the end of the AVP Data field till a word boundary is reached. The 1557 length of the padding is not reflected in the AVP Length field. 1559 4.1 AVP Header 1561 The fields in the AVP header MUST be sent in network byte order. The 1562 format of the header is: 1564 0 1 2 3 1565 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 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | AVP Code | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 |V M P r r r r r| AVP Length | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Vendor-ID (opt) | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | Data ... 1574 +-+-+-+-+-+-+-+-+ 1576 AVP Code 1577 The AVP Code, combined with the Vendor-Id field, identifies the 1578 attribute uniquely. AVP numbers 0 through 255, with the Vendor-Id 1579 set to zero (0) are reserved for backward compatibility with 1580 RADIUS. AVP numbers 256 and above are used for Diameter, which are 1581 allocated by IANA (see section 11.1). 1583 AVP Flags 1584 The AVP Flags field informs the receiver how each attribute must 1585 be handled. The 'r' (reserved) bits are unused and SHOULD be set 1586 to 0. Note that subsequent Diameter applications MAY define 1587 additional bits within the AVP Header, and an unrecognized bit 1588 SHOULD be considered an error. The 'P' bit indicates the need for 1589 encryption for end-to-end security. 1591 The 'M' Bit, known as the Mandatory bit, indicates whether support 1592 of the AVP is required. If an AVP with the 'M' bit set is received 1593 by a Diameter client, server, proxy, or translation agent and 1594 either the AVP or its value is unrecognized, the message MUST be 1595 rejected. Diameter Relay and Redirect agents MUST NOT reject 1596 messages with unrecognized AVPs. 1598 The 'M' bit MUST be set according to the rules defined for the AVP 1599 containing it. In order to preserve interoperability, a Diameter 1600 implementation MUST be able to exclude from a Diameter message any 1601 Mandatory AVP which is neither defined in the base Diameter 1602 standard nor in any of the Diameter Application specifications 1603 governing the message in which it appears. It MAY do this in one 1604 of the following ways: 1606 1) If a message is rejected because it contains a Mandatory AVP 1607 which is neither defined in the base Diameter standard nor in 1608 any of the Diameter Application specifications governing the 1609 message in which it appears, the implementation may resend the 1610 message without the AVP, possibly inserting additional standard 1611 AVPs instead. 1613 2) A configuration option may be provided on a system wide, per 1614 peer, or per realm basis that would allow/prevent particular 1615 Mandatory AVPs to be sent. Thus an administrator could change 1616 the configuration to avoid interoperability problems. 1618 Diameter implementations are required to support all Mandatory 1619 AVPs which are allowed by the message's formal syntax and defined 1620 either in the base Diameter standard or in one of the Diameter 1621 Application specifications governing the message. 1623 AVPs with the 'M' bit cleared are informational only and a 1624 receiver that receives a message with such an AVP that is not 1625 supported, or whose value is not supported, MAY simply ignore the 1626 AVP. 1628 The 'V' bit, known as the Vendor-Specific bit, indicates whether 1629 the optional Vendor-ID field is present in the AVP header. When 1630 set the AVP Code belongs to the specific vendor code address 1631 space. 1633 Unless otherwise noted, AVPs will have the following default AVP 1634 Flags field settings: 1636 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 1638 AVP Length 1639 The AVP Length field is three octets, and indicates the number of 1640 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 1641 Vendor-ID field (if present) and the AVP data. If a message is 1642 received with an invalid attribute length, the message SHOULD be 1643 rejected. 1645 4.2 Optional Header Elements 1647 The AVP Header contains one optional field. This field is only 1648 present if the respective bit-flag is enabled. 1650 Vendor-ID 1651 The Vendor-ID field is present if the 'V' bit is set in the AVP 1652 Flags field. The optional four-octet Vendor-ID field contains the 1653 IANA assigned "SMI Network Management Private Enterprise Codes" 1654 [ASSIGNNO] value, encoded in network byte order. Any vendor 1655 wishing to implement a vendor-specific Diameter AVP MUST use their 1656 own Vendor-ID along with their privately managed AVP address 1657 space, guaranteeing that they will not collide with any other 1658 vendor's vendor-specific AVP(s), nor with future IETF 1659 applications. 1661 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 1662 values, as managed by the IANA. Since the absence of the vendor ID 1663 field implies that the AVP in question is not vendor specific, 1664 implementations MUST NOT use the zero (0) vendor ID. 1666 4.3 Basic AVP Data Formats 1668 The Data field is zero or more octets and contains information 1669 specific to the Attribute. The format and length of the Data field is 1670 determined by the AVP Code and AVP Length fields. The format of the 1671 Data field MUST be one of the following base data types or a data 1672 type derived from the base data types. In the event that a new Basic 1673 AVP Data Format is needed, a new version of this RFC must be created. 1675 OctetString 1676 The data contains arbitrary data of variable length. Unless 1677 otherwise noted, the AVP Length field MUST be set to at least 8 1678 (12 if the 'V' bit is enabled). AVP Values of this type that 1679 are not a multiple of four-octets in length is followed by the 1680 necessary padding so that the next AVP (if any) will start on a 1681 32-bit boundary. 1683 Integer32 1684 32 bit signed value, in network byte order. The AVP Length 1685 field MUST be set to 12 (16 if the 'V' bit is enabled). 1687 Integer64 1688 64 bit signed value, in network byte order. The AVP Length 1689 field MUST be set to 16 (20 if the 'V' bit is enabled). 1691 Unsigned32 1692 32 bit unsigned value, in network byte order. The AVP Length 1693 field MUST be set to 12 (16 if the 'V' bit is enabled). 1695 Unsigned64 1696 64 bit unsigned value, in network byte order. The AVP Length 1697 field MUST be set to 16 (20 if the 'V' bit is enabled). 1699 Float32 1700 This represents floating point values of single precision as 1701 described by [FLOATPOINT]. The 32-bit value is transmitted in 1702 network byte order. The AVP Length field MUST be set to 12 (16 1703 if the 'V' bit is enabled). 1705 Float64 1706 This represents floating point values of double precision as 1707 described by [FLOATPOINT]. The 64-bit value is transmitted in 1708 network byte order. The AVP Length field MUST be set to 16 (20 1709 if the 'V' bit is enabled). 1711 Grouped 1712 The Data field is specified as a sequence of AVPs. Each of 1713 these AVPs follows - in the order in which they are specified - 1714 including their headers and padding. The AVP Length field is 1715 set to 8 (12 if the 'V' bit is enabled) plus the total length 1716 of all included AVPs, including their headers and padding. Thus 1717 the AVP length field of an AVP of type Grouped is always a 1718 multiple of 4. 1720 4.4 Derived AVP Data Formats 1722 In addition to using the Basic AVP Data Formats, applications may 1723 define data formats derived from the Basic AVP Data Formats. An 1724 application that defines new AVP Derived Data Formats MUST include 1725 them in a section entitled "AVP Derived Data Formats", using the same 1726 format as the definitions below. Each new definition must be either 1727 defined or listed with a reference to the RFC that defines the 1728 format. 1730 The below AVP Derived Data Formats are commonly used by applications. 1732 IPAddress 1733 The IPAddress format is derived from the OctetString AVP Base 1734 Format. It represents 32 bit (IPv4) [IPV4] or 128-bit (IPv6) 1735 [IPV6] address, most significant octet first. The format of the 1736 address (IPv4 or IPv6) is determined by the length. If the 1737 attribute value is an IPv4 address, the AVP Length field MUST 1738 be 12 (16 if 'V' bit is enabled); otherwise, the AVP Length 1739 field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 1740 addresses. 1742 Time 1743 The Time format is derived from the OctetString AVP Base 1744 Format. The string MUST contain four octets, in the same format 1745 as the first four bytes are in the NTP timestamp format. The 1746 NTP Timestamp format is defined in chapter 3 of [SNTP]. 1748 This represents the number of seconds since 0h on 1 January 1749 1900 with respect to the Coordinated Universal Time (UTC). 1751 On 6h 28m 16s UTC, 7 February 2036 the time value will 1752 overflow. SNTP [SNTP] describes a procedure to extend the time 1753 to 2104. This procedure MUST be supported by all DIAMETER 1754 nodes. 1756 UTF8String 1757 The UTF8String format is derived from the OctetString AVP Base 1758 Format. This is a human readable string represented using the 1759 ISO/IEC IS 10646-1 character set, encoded as an OctetString 1760 using the UTF-8 [UFT8] transformation format described in RFC 1761 2279. 1763 Since additional code points are added by amendments to the 1764 10646 standard from time to time, implementations MUST be 1765 prepared to encounter any code point from 0x00000001 to 1766 0x7fffffff. Byte sequences that do not correspond to the valid 1767 encoding of a code point into UTF-8 charset or are outside this 1768 range are prohibited. 1770 The use of control codes SHOULD be avoided. When it is 1771 necessary to represent a newline, the control code sequence CR 1772 LF SHOULD be used. 1774 The use of leading or trailing white space SHOULD be avoided. 1776 For code points not directly supported by user interface 1777 hardware or software, an alternative means of entry and 1778 display, such as hexadecimal, MAY be provided. 1780 For information encoded in 7-bit US-ASCII, the UTF-8 charset is 1781 identical to the US-ASCII charset. 1783 UTF-8 may require multiple bytes to represent a single 1784 character / code point; thus the length of an UTF8String in 1785 octets may be different from the number of characters encoded. 1787 Note that the AVP Length field of an UTF8String is measured in 1788 octets, not characters. 1790 DiameterIdentity 1791 The DiameterIdentity format is derived from the OctetString AVP 1792 Base Format. It uses the UTF-8 charset and has the same 1793 requirements as the UTF8String: 1795 DiameterIdentity = fqdn 1797 DiameterIdentity value is used to uniquely identify a Diameter 1798 node for purposes of duplicate connection and routing loop 1799 detection. 1801 The DiameterIdentity format is derived from the OctetString 1802 Base AVP Format. It uses the UTF-8 charset and has the same 1803 requirements as UTF8String. 1805 The contents of the string MUST be the fqdn of the Diameter 1806 node. If multiple Diameter nodes run on the same host, each 1807 Diameter node MUST be assigned a unique DiameterIdentity. If a 1808 Diameter node can be identified by several FQDNs, a single FQDN 1809 should be picked at startup, and used as the only 1810 DiameterIdentity for that node, whatever the connection it is 1811 sent on. 1813 DiameterURI 1815 The DiameterURI MUST follow the Uniform Resource Identifiers 1816 (URI) syntax [URI] rules specified below: 1818 "aaa://" fqdn [ port ] [ transport ] [ protocol ] 1820 ; No transport security 1822 "aaas://" fqdn [ port ] [ transport ] [ protocol ] 1824 ; Transport security used 1826 fqdn = Fully Qualified Host Name 1828 port = ":" 1*DIGIT 1830 ; One of the ports used to listen for 1831 ; incoming connections. 1832 ; If absent, 1833 ; the default Diameter port (TBD) is 1834 ; assumed. 1836 transport = ";transport=" transport-protocol 1838 ; One of the transports used to listen 1839 ; for incoming connections. If absent, 1840 ; the default SCTP [SCTP] protocol is 1841 ; assumed. UDP MUST NOT be used when 1842 ; the aaa-protocol field is set to 1843 ; diameter. 1845 transport-protocol = ( "tcp" / "sctp" / "udp" ) 1847 protocol = ";protocol=" aaa-protocol 1849 ; If absent, the default AAA protocol 1850 ; is diameter. 1852 aaa-protocol = ( "diameter" / "radius" / "tacacs+" ) 1853 The following are examples of valid Diameter host identities: 1855 aaa://host.abc.com;transport=tcp 1856 aaa://host.abc.com:6666;transport=tcp 1857 aaa://host.abc.com;protocol=diameter 1858 aaa://host.abc.com:6666;protocol=diameter 1859 aaa://host.abc.com:6666;transport=tcp;protocol=diameter 1860 aaa://host.abc.com:1813;transport=udp;protocol=radius 1862 Enumerated 1863 Enumerated is derived from the Integer32 AVP Base Format. The 1864 definition contains a list of valid values and their 1865 interpretation and is described in the Diameter application 1866 introducing the AVP. 1868 IPFilterRule 1869 The IPFilterRule format is derived from the OctetString AVP 1870 Base Format. It uses the UTF-8 charset and has the same 1871 requirements as the UTF8String. Packets may be filtered based 1872 on the following information that is associated with it: 1874 Direction (in or out) 1875 Source and destination IP address (possibly masked) 1876 Protocol 1877 Source and destination port (lists or ranges) 1878 TCP flags 1879 IP fragment flag 1880 IP options 1881 ICMP types 1883 Rules for the appropriate direction are evaluated in order, 1884 with the first matched rule terminating the evaluation. Each 1885 packet is evaluated once. If no rule matches, the packet is 1886 dropped if the last rule evaluated was a permit, and passed if 1887 the last rule was a deny. 1889 IPFilterRule filters MUST follow the format: 1891 action dir proto from src to dst [options] 1893 action permit - Allow packets that match the rule. 1894 deny - Drop packets that match the rule. 1896 dir "in" is from the terminal, "out" is to the 1897 terminal. 1899 proto An IP protocol specified by number. The "ip" 1900 keyword means any protocol will match. 1902 src and dst
[ports] 1904 The
may be specified as: 1905 ipno An IPv4 or IPv6 number in dotted- 1906 quad or canonical IPv6 form. Only 1907 this exact IP number will match the 1908 rule. 1909 ipno/bits An IP number as above with a mask 1910 width of the form 1.2.3.4/24. In 1911 this case, all IP numbers from 1912 1.2.3.0 to 1.2.3.255 will match. 1913 The bit width MUST be valid for the 1914 IP version and the IP number MUST 1915 NOT have bits set beyond the mask. 1916 For a match to occur, the same IP 1917 version must be present in the 1918 packet that was used in describing 1919 the IP address. To test for a 1920 particular IP version, the bits part 1921 can be set to zero. The keyword 1922 "any" is 0.0.0.0/0 or the IPv6 1923 equivalent. The keyword "assigned" 1924 is the address or set of addresses 1925 assigned to the terminal. For IPv4, 1926 a typical first rule is often "deny 1927 in ip! assigned" 1929 The sense of the match can be inverted by 1930 preceding an address with the not modifier (!), 1931 causing all other addresses to be matched 1932 instead. This does not affect the selection of 1933 port numbers. 1935 With the TCP, UDP and SCTP protocols, optional 1936 ports may be specified as: 1938 {port/port-port}[,ports[,...]] 1940 The '-' notation specifies a range of ports 1941 (including boundaries). 1943 Fragmented packets that have a non-zero offset 1944 (i.e. not the first fragment) will never match 1945 a rule that has one or more port 1946 specifications. See the frag option for 1947 details on matching fragmented packets. 1949 options: 1950 frag Match if the packet is a fragment and this is not 1951 the first fragment of the datagram. frag may not 1952 be used in conjunction with either tcpflags or 1953 TCP/UDP port specifications. 1955 ipoptions spec 1956 Match if the IP header contains the comma 1957 separated list of options specified in spec. The 1958 supported IP options are: 1960 ssrr (strict source route), lsrr (loose source 1961 route), rr (record packet route) and ts 1962 (timestamp). The absence of a particular option 1963 may be denoted with a '!'. 1965 tcpoptions spec 1966 Match if the TCP header contains the comma 1967 separated list of options specified in spec. The 1968 supported TCP options are: 1970 mss (maximum segment size), window (tcp window 1971 advertisement), sack (selective ack), ts (rfc1323 1972 timestamp) and cc (rfc1644 t/tcp connection 1973 count). The absence of a particular option may 1974 be denoted with a '!'. 1976 established 1977 TCP packets only. Match packets that have the RST 1978 or ACK bits set. 1980 setup TCP packets only. Match packets that have the SYN 1981 bit set but no ACK bit. 1983 tcpflags spec 1984 TCP packets only. Match if the TCP header 1985 contains the comma separated list of flags 1986 specified in spec. The supported TCP flags are: 1988 fin, syn, rst, psh, ack and urg. The absence of a 1989 particular flag may be denoted with a '!'. A rule 1990 that contains a tcpflags specification can never 1991 match a fragmented packet that has a non-zero 1992 offset. See the frag option for details on 1993 matching fragmented packets. 1995 icmptypes types 1996 ICMP packets only. Match if the ICMP type is in 1997 the list types. The list may be specified as any 1998 combination of ranges or individual types 1999 separated by commas. Both the numeric values and 2000 the symbolic values listed below can be used. The 2001 supported ICMP types are: 2003 echo reply (0), destination unreachable (3), 2004 source quench (4), redirect (5), echo request 2005 (8), router advertisement (9), router 2006 solicitation (10), time-to-live exceeded (11), IP 2007 header bad (12), timestamp request (13), 2008 timestamp reply (14), information request (15), 2009 information reply (16), address mask request (17) 2010 and address mask reply (18). 2012 There is one kind of packet that the access device MUST always 2013 discard, that is an IP fragment with a fragment offset of one. 2014 This is a valid packet, but it only has one use, to try to 2015 circumvent firewalls. 2017 An access device that is unable to interpret or apply a deny 2018 rule MUST terminate the session. An access device that is 2019 unable to interpret or apply a permit rule MAY apply a more 2020 restrictive rule. An access device MAY apply deny rules of 2021 its own before the supplied rules, for example to protect 2022 the access device owner's infrastructure. 2024 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 2025 and the ipfw.c code may provide a useful base for 2026 implementations. 2028 QoSFilterRule 2029 The QosFilterRule format is derived from the OctetString AVP 2030 Base Format. It uses the UTF-8 charset and has the same 2031 requirements as the UTF8String. Packets may be marked or 2032 metered based on the following information that is associated 2033 with it: 2035 Direction (in or out) 2036 Source and destination IP address (possibly masked) 2037 Protocol 2038 Source and destination port (lists or ranges) 2039 DSCP values (no mask or range) 2041 Rules for the appropriate direction are evaluated in order, 2042 with the first matched rule terminating the evaluation. Each 2043 packet is evaluated once. If no rule matches, the packet is 2044 treated as best effort. An access device that is unable to 2045 interpret or apply a QoS rule SHOULD NOT terminate the session. 2047 QoSFilterRule filters MUST follow the format: 2049 action dir proto from src to dst [options] 2051 tag - Mark packet with a specific DSCP 2052 [DIFFSERV]. The DSCP option MUST be 2053 included. 2054 meter - Meter traffic. The metering options 2055 MUST be included. 2057 dir The format is as described under IPFilterRule. 2059 proto The format is as described under 2060 IPFilterRule. 2062 src and dst The format is as described under 2063 IPFilterRule. 2065 4.5 Grouped AVP Values 2067 The Diameter protocol allows AVP values of type 'Grouped.' This 2068 implies that the Data field is actually a sequence of AVPs. It is 2069 possible to include an AVP with a Grouped type within a Grouped type, 2070 that is, to nest them. AVPs within an AVP of type Grouped have the 2071 same padding requirements as non-Grouped AVPs, as defined in section 2072 4. 2074 The AVP Code numbering space of all AVPs included in a Grouped AVP is 2075 the same as for non-grouped AVPs. Further, if any of the AVPs 2076 encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, 2077 the Grouped AVP itself MUST also include the 'M' bit set. 2079 Every Grouped AVP defined MUST include a corresponding grammar, using 2080 ABNF [ABNF] (with modifications), as defined below. 2082 grouped-avp-def = name "::=" avp 2084 name-fmt = ALPHA *(ALPHA / DIGIT / "-") 2086 name = name-fmt 2087 ; The name has to be the name of an AVP, 2088 ; defined in the base or extended Diameter 2089 ; specifications. 2091 avp = header [ *fixed] [ *required] [ *optional] 2093 [ *fixed] 2095 header = "<" "AVP-Header:" avpcode [vendor] ">" 2097 avpcode = 1*DIGIT 2098 ; The AVP Code assigned to the Grouped AVP 2100 vendor = 1*DIGIT 2101 ; The Vendor-ID assigned to the Grouped AVP. 2102 ; If absent, the default value of zero is 2103 ; used. 2105 4.5.1 Example AVP with a Grouped Data type 2107 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: 2109 Example-AVP ::= < AVP Header: 999999 > 2110 { Origin-Host } 2111 1*{ Session-Id } 2112 *[ AVP ] 2114 An Example-AVP with Grouped Data follows. 2116 The Origin-Host AVP is required. In this case: 2118 Origin-Host = "abc.com". 2120 One or more Session-Ids must follow. Here there are two: 2122 Session-Id = 2123 "grump.abc.com:33041;23432;893;0AF3B81" 2125 Session-Id = 2126 "grump.abc.com:33054;23561;2358;0AF3B82" 2128 optional AVPs included are 2130 Recovery-Policy = 2131 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2132 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 2133 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd 2134 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a 2135 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 2136 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 2137 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 2139 Futuristic-Acct-Record = 2140 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 2141 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 2142 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 2143 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 2144 d3427475e49968f841 2146 The data for the optional AVPs is represented in hex since the format 2147 of these AVPs is neither known at the time of definition of the 2148 Example-AVP group, nor (likely) at the time when the example instance 2149 of this AVP is interpreted - except by Diameter implementations which 2150 support the same set of AVPs. The encoding example illustrates how 2151 padding is used and how length fields are calculated. Also note that 2152 AVPs may be present in the Grouped AVP value which the receiver 2153 cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record 2154 AVPs). 2156 This AVP would be encoded as follows: 2158 0 1 2 3 4 5 6 7 2159 +-------+-------+-------+-------+-------+-------+-------+-------+ 2160 0 | Example AVP Header (AVP Code = 999999), Length = 468 | 2161 +-------+-------+-------+-------+-------+-------+-------+-------+ 2162 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | 2163 +-------+-------+-------+-------+-------+-------+-------+-------+ 2164 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 2165 +-------+-------+-------+-------+-------+-------+-------+-------+ 2166 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | 2167 +-------+-------+-------+-------+-------+-------+-------+-------+ 2168 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | 2169 +-------+-------+-------+-------+-------+-------+-------+-------+ 2170 . . . 2171 +-------+-------+-------+-------+-------+-------+-------+-------+ 2172 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| 2173 +-------+-------+-------+-------+-------+-------+-------+-------+ 2174 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | 2175 +-------+-------+-------+-------+-------+-------+-------+-------+ 2176 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | 2177 +-------+-------+-------+-------+-------+-------+-------+-------+ 2178 . . . 2179 +-------+-------+-------+-------+-------+-------+-------+-------+ 2180 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| 2181 +-------+-------+-------+-------+-------+-------+-------+-------+ 2182 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | 2183 +-------+-------+-------+-------+-------+-------+-------+-------+ 2184 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | 2185 +-------+-------+-------+-------+-------+-------+-------+-------+ 2186 . . . 2187 +-------+-------+-------+-------+-------+-------+-------+-------+ 2188 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| 2189 +-------+-------+-------+-------+-------+-------+-------+-------+ 2190 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| 2191 +-------+-------+-------+-------+-------+-------+-------+-------+ 2192 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 2193 +-------+-------+-------+-------+-------+-------+-------+-------+ 2194 . . . 2195 +-------+-------+-------+-------+-------+-------+-------+-------+ 2196 464 | 0x41 |Padding|Padding|Padding| 2197 +-------+-------+-------+-------+ 2199 4.6 Diameter Base Protocol AVPs 2201 The following table describes the Diameter AVPs defined in the base 2202 protocol, their AVP Code values, types, possible flag values and 2203 whether the AVP MAY be encrypted. For the originator of a Diameter 2204 message, "MAY Encr" means that if a message containing that AVP is to 2205 be sent via a proxy/agent then the message MUST NOT be sent unless 2206 there is end-to-end security between the originator and the recipient 2207 OR the originator has locally trusted configuration that indicates 2208 that end-to-end security is not needed. Similarly, for the originator 2209 of a Diameter message, a "P" in the "MAY" column means that if a 2210 message containing that AVP is to be sent via a proxy/agent then the 2211 message MUST NOT be sent unless there is end-to-end security between 2212 the originator and the recipient or the originator has locally 2213 trusted configuration that indicates that end-to-end security is not 2214 needed. 2216 Due to space constraints, the short form DiamIdent is used to 2217 represent DiameterIdentity. 2219 +---------------------+ 2220 | AVP Flag rules | 2221 |----+-----+----+-----|----+ 2222 AVP Section | | |SHLD| MUST|MAY | 2223 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2224 -----------------------------------------|----+-----+----+-----|----| 2225 Accounting- 85 9.8.2 Unsigned32 | M | P | | V | Y | 2226 Interim-Interval | | | | | | 2227 Accounting- 483 9.8.7 Unsigned32 | M | P | | V | Y | 2228 Realtime-Required | | | | | | 2229 Acct- 50 9.8.5 UTF8String | M | P | | V | Y | 2230 Multi-Session-Id | | | | | | 2231 Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | 2232 Record-Number | | | | | | 2233 Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | 2234 Record-Type | | | | | | 2235 Accounting- 44 9.8.4 OctetString| M | P | | V | Y | 2236 RADIUS-Session-Id | | | | | | 2237 Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y | 2238 Sub-Session-Id | | | | | | 2239 Acct- 259 6.9 Integer32 | M | P | | V | N | 2240 Application-Id | | | | | | 2241 Auth- 258 6.8 Integer32 | M | P | | V | N | 2242 Application-Id | | | | | | 2243 Auth-Request- 274 8.7 Enumerated | M | P | | V | N | 2244 Type | | | | | | 2245 Authorization- 291 8.9 Unsigned32 | M | P | | V | N | 2246 Lifetime | | | | | | 2247 Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | 2248 Period | | | | | | 2249 Auth-Session- 277 8.11 Enumerated | M | P | | V | N | 2250 State | | | | | | 2251 Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | 2252 Type | | | | | | 2253 Class 25 8.20 OctetString| M | P | | V | Y | 2254 Destination-Host 293 6.5 DiamIdent | M | P | | V | N | 2255 Destination- 283 6.6 UTF8String | M | P | | V | N | 2256 Realm | | | | | | 2257 Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N | 2258 Error-Message 281 7.3 OctetString| | P | | V,M | N | 2259 Error-Reporting- 294 7.4 UTF8String | | P | | V,M | N | 2260 Host | | | | | | 2261 Event-Timestamp 55 8.21 Time | M | P | | V | N | 2262 Failed-AVP 279 7.5 Grouped | M | P | | V | N | 2263 Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N | 2264 Revision | | | | | | 2265 Host-IP-Address 257 5.3.5 IPAddress | M | P | | V | N | 2266 -----------------------------------------|----+-----+----+-----|----| 2267 +---------------------+ 2268 | AVP Flag rules | 2269 |----+-----+----+-----|----+ 2270 AVP Section | | |SHLD| MUST|MAY | 2271 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2272 -----------------------------------------|----+-----+----+-----|----| 2273 Inband-Security | | | | | | 2274 -Id 299 6.10 Unsigned32 | | | | | | 2275 Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | 2276 Time-Out | | | | | | 2277 Origin-Host 264 6.3 DiamIdent | M | P | | V | N | 2278 Origin-Realm 296 6.4 UTF8String | M | P | | V | N | 2279 Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N | 2280 Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N | 2281 Proxy-Host 280 6.7.3 DiamIdent | M | | | P,V | N | 2282 Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N | 2283 Proxy-State 33 6.7.4 OctetString| M | | | P,V | N | 2284 Redirect-Host 292 6.12 DiamURI | M | P | | V | N | 2285 Redirect-Host- 261 6.13 Enumerated | M | P | | V | N | 2286 Usage | | | | | | 2287 Redirect-Max- 262 6.14 Unsigned32 | M | P | | V | N | 2288 Cache-Time | | | | | | 2289 Result-Code 268 7.1 Unsigned32 | M | P | | V | N | 2290 Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N | 2291 Session-Id 263 8.8 UTF8String | M | P | | V | Y | 2292 Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N | 2293 Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y | 2294 Session-Server- 271 8.18 Enumerated | M | P | | V | Y | 2295 Failover | | | | | | 2296 Supported- 265 5.3.6 Unsigned32 | M | P | | V | N | 2297 Vendor-Id | | | | | | 2298 Termination- 295 8.15 Enumerated | M | P | | V | N | 2299 Cause | | | | | | 2300 User-Name 1 8.14 UTF8String | M | P | | V | Y | 2301 Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V | N | 2302 Vendor-Specific- 260 6.11 Grouped | M | P | | V | N | 2303 Application-Id | | | | | | 2304 Vendor-Specific- 297 7.6 Grouped | M | P | | V | N | 2305 Result | | | | | | 2306 Vendor-Specific- 298 7.7 Unsigned32 | M | P | | V | N | 2307 Result-Code | | | | | | 2308 -----------------------------------------|----+-----+----+-----|----| 2310 5 Diameter Peers 2312 This section describes how Diameter nodes establish connections and 2313 communicate with peers. 2315 5.1 Peer Connections 2317 Although a Diameter node may have many possible peers that it is able 2318 to communicate with, it may not be economical to have an established 2319 connection to all of them. At a minimum, a Diameter node SHOULD have 2320 an established connection with two peers per realm, known as the 2321 primary and secondary peers. Of course, a node MAY have additional 2322 connections, if it is deemed necessary. Typically, all messages for a 2323 realm are sent to the primary peer, but in the event that failover 2324 procedures are invoked, any pending requests are sent to the 2325 secondary peer. However, implementations are free to load balance 2326 requests between a set of peers. 2328 Note that a given peer MAY act as a primary for a given realm, while 2329 acting as a secondary for another realm. 2331 When a peer is deemed suspect, which could occur for various reasons, 2332 including not receiving a DWA within an allotted timeframe, no new 2333 requests should be forwarded to the peer, but failover procedures are 2334 invoked. When an active peer is moved to this mode, additional 2335 connections SHOULD be established to ensure that the necessary number 2336 of active connections exists. 2338 There are two ways that a peer is removed from the suspect peer list: 2339 1. The peer is no longer reachable, causing the transport 2340 connection to be shutdown. The peer is moved to the closed 2341 state. 2342 2. Three watchdog messages are exchanged with accepted round trip 2343 times, and the connection to the peer is considered stabilized. 2345 In the event the peer being removed is either the primary or 2346 secondary, an alternate peer SHOULD replace the deleted peer, and 2347 assume the role of either primary or secondary. 2349 5.2 Diameter Peer Discovery 2351 Allowing for dynamic Diameter agent discovery will make it possible 2352 for simpler and more robust deployment of Diameter services. In 2353 order to promote interoperable implementations of Diameter peer 2354 discovery, the following mechanisms are described. These are based 2355 on existing IETF standards. The first option (manual configuration) 2356 MUST be supported by all DIAMETER nodes, while the latter two options 2357 (SRVLOC and DNS) MAY be supported. 2359 There are two cases where Diameter peer discovery may be performed. 2360 The first is when a Diameter client needs to discover a first-hop 2361 Diameter agent. The second case is when a Diameter agent needs to 2362 discover another agent - for further handling of a Diameter 2363 operation. In both cases, the following 'search order' is 2364 recommended: 2366 1. The Diameter implementation consults its list of static 2367 (manually) configured Diameter agent locations. These will be 2368 used if they exist and respond. 2370 2. The Diameter implementation uses SLPv2 [SLP] to discover 2371 Diameter services. The Diameter service template [TEMPLATE] is 2372 included in Appendix A. It is recommended that SLPv2 security 2373 be deployed (this requires distributing keys to SLPv2 agents). 2374 This is discussed further in Appendix A. 2376 SLPv2 will allow Diameter implementations to discover the 2377 location of Diameter agents in the local site, as well as their 2378 characteristics. Diameter agents with specific capabilities 2379 (say support for the Mobile IP application) can be requested, 2380 and only those will be discovered. 2382 3. The Diameter implementation performs a NAPTR query for a server 2383 in a particular realm. The Diameter implementation has to know 2384 in advance which realm to look for a Diameter agent in. This 2385 could be deduced, for example, from the 'realm' in a NAI that a 2386 Diameter implementation needed to perform a Diameter operation 2387 on. 2389 3.1 The services relevant for the task of transport protocol 2390 selection are those with NAPTR service fields with values 2391 "AAA+D2x", where x is a letter that corresponds to a 2392 transport protocol supported by the domain. This 2393 specification defines D2T for TCP and D2S for SCTP. We also 2394 establish an IANA registry for NAPTR service name to 2395 transport protocol mappings. 2397 These NAPTR records provide a mapping from a domain, to the 2398 SRV record for contacting a server with the specific 2399 transport protocol in the NAPTR services field. The resource 2400 record will contain an empty regular expression and a 2401 replacement value, which is the SRV record for that 2402 particular transport protocol. If the server supports 2403 multiple transport protocols, there will be multiple NAPTR 2404 records, each with a different service value. As per RFC 2405 2915 [NAPTR], the client discards any records whose services 2406 fields are not applicable. For the purposes of this 2407 specification, several rules are defined. 2409 3.2 A client MUST discard any service fields that identify a 2410 resolution service whose value is not "D2X", for values of X 2411 that indicate transport protocols supported by the client. 2412 The NAPTR processing as described in RFC 2915 will result in 2413 discovery of the most preferred transport protocol of the 2414 server that is supported by the client, as well as an SRV 2415 record for the server. 2417 The domain suffixes in the NAPTR replacement field SHOULD 2418 match the domain of the original query. It is not necessary 2419 for the domain suffixes in the NAPTR replacement field to 2420 match the domain of the original query. 2422 3.3 If no NAPTR records are found, the requester queries for 2423 those address records for the destination address, 2424 '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address 2425 records include A RR's, AAAA RR's or other similar records, 2426 chosen according to the requestor's network protocol 2427 capabilities. If the DNS server returns no address records, 2428 the requestor gives up. 2430 If the server is using a site certificate, the domain name in 2431 the query and the domain name in the replacement field MUST 2432 both be valid based on the site certificate handed out by the 2433 server in the TLS exchange. Similarly, the domain name in the 2434 SRV query and the domain name in the target in the SRV record 2435 MUST both be valid based on the same site certificate. 2436 Otherwise, an attacker could modify the DNS records to contain 2437 replacement values in a different domain, and the client could 2438 not validate that this was the desired behavior, or the result 2439 of an attack. 2441 A dynamically discovered peer causes an entry in the Peer Table (see 2442 section 2.6) to be created. Note that entries created via DNS MUST 2443 expire (or be refreshed) within the DNS TTL. If a peer is discovered 2444 outside of the local realm, a routing table entry (see Section 2.7) 2445 for the peer's realm is created. The routing table entry's expiration 2446 MUST match the peer's expiration value. 2448 5.3 Capabilities Exchange 2450 When two Diameter peers establish a transport connection, they MUST 2451 exchange the Capabilities Exchange messages, as specified in the peer 2452 state machine (see section 5.6). This message allows the discovery of 2453 a peer's identity and its capabilities (protocol version number, 2454 supported Diameter applications, security model, etc.) 2456 The receiver only issues commands to its peers that have advertised 2457 support for the Diameter application that defines the command. A 2458 Diameter node MUST cache the supported applications in order to 2459 ensure that unrecognized commands and/or AVPs are not unnecessarily 2460 sent to a peer. 2462 A receiver of a Capabilities-Exchange-Req (CER) message that does not 2463 have any applications in common with the sender MUST return a 2464 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to 2465 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport 2466 layer connection. Note that receiving a CER or CEA from a peer 2467 advertising itself as a Relay (see section 2.4) MUST be interpreted 2468 as having common applications with the peer. 2470 Similarly, a receiver of a Capabilities-Exchange-Req (CER) message 2471 that does not have any security model in common with the sender MUST 2472 return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP 2473 set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the 2474 transport layer connection. 2476 CERs received from unknown peers MAY be silently discarded, or a CEA 2477 MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. 2478 In both cases, the transport connection is closed. If the local 2479 policy permits receiving CERs from unknown hosts, a successful CEA 2480 MAY be returned. If a CER from an unknown peer is answered with a 2481 successful CEA, the lifetime of the peer entry is equal to the 2482 lifetime of the transport connection. In case of a transport failure, 2483 all the pending transactions destined to the unknown peer can be 2484 discarded. 2486 The CER and CEA messages MUST NOT be proxied, or redirected. 2488 Since the CER/CEA messages cannot be proxied, it is still possible 2489 that an upstream agent receives a message for which it has no 2490 available peers to handle the application that corresponds to the 2491 Command-Code. In such instances, the 'E' bit is set in the answer 2492 message (see Section 7.2) with the Result-Code AVP set to 2493 DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action 2494 (e.g. re-routing request to an alternate peer). 2496 With the exception of the Capabilities-Exchange-Request message, a 2497 message of type Request that includes the Auth-Application-Id or 2498 Acct-Application-Id AVPs, or a message with an application-specific 2499 command code, MAY only be forwarded to a host that has explicitly 2500 advertised support for the application (or has advertised the Relay 2501 Application Identifier). 2503 5.3.1 Capabilities-Exchange-Request 2504 The Capabilities-Exchange-Request (CER), indicated by the Command- 2505 Code set to 257 and the Command Flags' 'R' bit set, is sent to 2506 exchange local capabilities. Upon detection of a transport failure, 2507 this message MUST NOT be sent to an alternate peer. 2509 When Diameter is run over SCTP [SCTP], which allows for connections 2510 to span multiple interfaces and multiple IP addresses, the 2511 Capabilities-Exchange-Request message MUST contain one Host-IP- 2512 Address AVP for each potential IP address that MAY be locally used 2513 when transmitting Diameter messages. 2515 Message Format 2517 ::= < Diameter Header: 257, REQ > 2518 { Origin-Host } 2519 { Origin-Realm } 2520 1* { Host-IP-Address } 2521 { Vendor-Id } 2522 { Product-Name } 2523 [ Origin-State-Id ] 2524 * [ Supported-Vendor-Id ] 2525 * [ Auth-Application-Id ] 2526 * [ Inband-Security-Id ] 2527 * [ Acct-Application-Id ] 2528 * [ Vendor-Specific-Application-Id ] 2529 [ Firmware-Revision ] 2530 * [ AVP ] 2532 5.3.2 Capabilities-Exchange-Answer 2534 The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code 2535 set to 257 and the Command Flags' 'R' bit cleared, is sent in 2536 response to a CER message. 2538 When Diameter is run over SCTP [SCTP], which allows connections to 2539 span multiple interfaces, hence, multiple IP addresses, the 2540 Capabilities-Exchange-Answer message MUST contain one Host-IP-Address 2541 AVP for each potential IP address that MAY be locally used when 2542 transmitting Diameter messages. 2544 Message Format 2545 ::= < Diameter Header: 257 > 2546 { Result-Code } 2547 { Origin-Host } 2548 { Origin-Realm } 2549 1* { Host-IP-Address } 2550 { Vendor-Id } 2551 { Product-Name } 2552 [ Origin-State-Id ] 2553 [ Error-Message ] 2554 * [ Failed-AVP ] 2555 * [ Supported-Vendor-Id ] 2556 * [ Auth-Application-Id ] 2557 * [ Inband-Security-Id ] 2558 * [ Acct-Application-Id ] 2559 * [ Vendor-Specific-Application-Id ] 2560 [ Firmware-Revision ] 2561 * [ AVP ] 2563 5.3.3 Vendor-Id AVP 2565 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 2566 the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] 2567 value assigned to the vendor of the Diameter device. In combination 2568 with the Supported-Vendor-Id AVP (section 5.3.6), this MAY be used in 2569 order to know which vendor specific attributes may be sent to the 2570 peer. It is also envisioned that the combination of the Vendor-Id, 2571 Product-Name (section 5.3.7) and the Firmware-Revision (section 2572 5.3.4) AVPs MAY provide very useful debugging information. 2574 A Vendor-Id value of zero in the CER or CEA messages is reserved and 2575 indicates that the Diameter peer is in the experimental or concept 2576 stage and that an IANA Private Enterprise Number has yet to be 2577 obtained by the implementer. 2579 5.3.4 Firmware-Revision AVP 2581 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 2582 used to inform a Diameter peer of the firmware revision of the 2583 issuing device. 2585 For devices that do not have a firmware revision (general purpose 2586 computers running Diameter software modules, for instance), the 2587 revision of the Diameter software module may be reported instead. 2589 5.3.5 Host-IP-Address AVP 2590 The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is 2591 used to inform a Diameter peer of the sender's IP address. All source 2592 addresses that a Diameter node expects to use with SCTP [SCTP] MUST 2593 be advertised in the CER and CEA messages by including a Host-IP- 2594 Address AVP for each address. This AVP MUST ONLY be used in the CER 2595 and CEA messages. 2597 5.3.6 Supported-Vendor-Id AVP 2599 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and 2600 contains the IANA "SMI Network Management Private Enterprise Codes" 2601 [ASSIGNNO] value assigned to a vendor other than the device vendor. 2602 This is used in the CER and CEA messages in order to inform the peer 2603 that the sender supports a subset of the vendor-specific AVPs defined 2604 by the vendor identified in this AVP. 2606 5.3.7 Product-Name AVP 2608 The Product-Name AVP (AVP Code 269) is of type UTF8String, and 2609 contains the vendor assigned name for the product. The Product-Name 2610 AVP SHOULD remain constant across firmware revisions for the same 2611 product. 2613 5.4 Disconnecting Peer connections 2615 When a Diameter node disconnects one of its transport connections, 2616 its peer cannot know the reason for the disconnect, and will most 2617 likely assume that a connectivity problem occurred, or that the peer 2618 has rebooted. In these cases, the peer may periodically attempt to 2619 reconnect, as stated in section 2.1. In the event that the disconnect 2620 was a result of either a shortage of internal resources, or simply 2621 that the node in question has no intentions of forwarding any 2622 Diameter messages to the peer in the foreseeable future, a periodic 2623 connection request would not be welcomed. The Disconnection-Reason 2624 AVP contains the reason the Diameter node issued the Disconnect- 2625 Peer-Request message. 2627 The Disconnect-Peer-Request message is used by a Diameter node to 2628 inform its peer of its intent to disconnect the transport layer, and 2629 that the peer shouldn't reconnect unless it has a valid reason to do 2630 so (e.g. message to be forwarded). Upon receipt of the message, the 2631 Disconnect-Peer-Answer is returned, which SHOULD contain an error if 2632 messages have recently been forwarded, and are likely in flight, 2633 which would otherwise cause a race condition. 2635 The receiver of the Disconnect-Peer-Answer initiates the transport 2636 disconnect. 2638 5.4.1 Disconnect-Peer-Request 2640 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set 2641 to 282 and the Command Flags' 'R' bit set, is sent to a peer to 2642 inform its intentions to shutdown the transport connection. Upon 2643 detection of a transport failure, this message MUST NOT be sent to an 2644 alternate peer. 2646 Message Format 2648 ::= < Diameter Header: 282, REQ > 2649 { Origin-Host } 2650 { Origin-Realm } 2651 { Disconnect-Cause } 2653 5.4.2 Disconnect-Peer-Answer 2655 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set 2656 to 282 and the Command Flags' 'R' bit cleared, is sent as a response 2657 to the Disconnect-Peer-Request message. Upon receipt of this message, 2658 the transport connection is shutdown. 2660 Message Format 2662 ::= < Diameter Header: 282 > 2663 { Result-Code } 2664 { Origin-Host } 2665 { Origin-Realm } 2666 [ Error-Message ] 2667 * [ Failed-AVP ] 2669 5.4.3 Disconnect-Cause AVP 2671 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A 2672 Diameter node MUST include this AVP in the Disconnect-Peer-Request 2673 message to inform the peer of the reason for its intention to 2674 shutdown the transport connection. The following values are 2675 supported: 2677 REBOOTING 0 2678 A scheduled reboot is imminent. 2680 BUSY 1 2681 The peer's internal resources are constrained, and it has 2682 determined that the transport connection needs to be closed. 2684 DO_NOT_WANT_TO_TALK_TO_YOU 2 2685 The peer has determined that it does not see a need for the 2686 transport connection to exist, since it does not expect any 2687 messages to be exchanged in the near future. 2689 5.5 Transport Failure Detection 2691 Given the nature of the Diameter protocol, it is recommended that 2692 transport failures be detected as soon as possible. Detecting such 2693 failures will minimize the occurrence of messages sent to unavailable 2694 agents, resulting in unnecessary delays, and will provide better 2695 failover performance. The Device-Watchdog-Request and Device- 2696 Watchdog-Answer messages, defined in this section, are used to pro- 2697 actively detect transport failures. 2699 5.5.1 Device-Watchdog-Request 2701 The Device-Watchdog-Request (DWR), indicated by the Command-Code set 2702 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no 2703 traffic has been exchanged between two peers (see Section 5.5.3). 2704 Upon detection of a transport failure, this message MUST NOT be sent 2705 to an alternate peer. 2707 Message Format 2709 ::= < Diameter Header: 280, REQ > 2710 { Origin-Host } 2711 { Origin-Realm } 2712 [ Origin-State-Id ] 2714 5.5.2 Device-Watchdog-Answer 2716 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 2717 to 280 and the Command Flags' 'R' bit cleared, is sent as a response 2718 to the Device-Watchdog-Request message. 2720 Message Format 2721 ::= < Diameter Header: 280 > 2722 { Result-Code } 2723 { Origin-Host } 2724 { Origin-Realm } 2725 [ Error-Message ] 2726 * [ Failed-AVP ] 2727 [ Original-State-Id ] 2729 5.5.3 Transport Failure Algorithm 2731 The transport failure algorithm is defined in [AAATRANS]. All 2732 Diameter implementations MUST support the algorithm defined in the 2733 specification in order to be compliant to the Diameter base protocol. 2735 5.5.4 Failover and Failback Procedures 2737 In the event that a transport failure is detected with a peer, it is 2738 necessary for all pending request messages to be forwarded to an 2739 alternate agent, if possible. This is commonly referred to as 2740 failover. 2742 In order for a Diameter node to perform failover procedures, it is 2743 necessary for the node to maintain a pending message queue for a 2744 given peer. When an answer message is received, the corresponding 2745 request is removed from the queue. The Hop-by-Hop Identifier field is 2746 used to match the answer with the queued request. 2748 When a transport failure is detected, all messages in the queue are 2749 sent to an alternate agent, if possible. An example of a case where 2750 it is not possible to forward the message to an alternate server is 2751 when the message has a fixed destination, and the unavailable peer is 2752 the message's final destination (see Destination-Host AVP). Such an 2753 error requires that the agent return an answer message with the 'E' 2754 bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 2756 It is important to note that multiple identical requests or answers 2757 MAY be received as a result of a failover. The End-to-End Identifier 2758 field in the Diameter header along with the Origin-Host AVP MUST be 2759 used to identify duplicate messages. 2761 As described in section 2.1, a connection request should be 2762 periodically attempted with the failed peer in order to re-establish 2763 the transport connection. Once a connection has been successfully 2764 established, messages can once again be forwarded to the peer. This 2765 is commonly referred to as failback. 2767 5.6 Peer State Machine 2769 This section contains a finite state machine that MUST be observed by 2770 all Diameter implementations. Each Diameter node MUST follow the 2771 state machine described below when communicating with each peer. 2772 Multiple actions are separated by commas, and may continue on 2773 succeeding lines, as space requires. Similarly, state and next state 2774 may also span multiple lines, as space requires. 2776 This state machine is closely coupled with the state machine 2777 described in [AAATRANS], which is used to open, close, failover, 2778 probe, and reopen transport connections. Note in particular that 2779 [AAATRANS] requires the use of watchdog messages to probe 2780 connections. For Diameter, DWR and DWA messages are to be used. 2782 I- is used to represent the initiator (connecting) connection, while 2783 the R- is used to represent the responder (listening) connection. The 2784 lack of a prefix indicates that the event or action is the same 2785 regardless of the connection on which the event occurred. 2787 The stable states that a state machine may be in are Closed, I-Open 2788 and R-Open; all other states are intermediate. Note that I-Open and 2789 R-Open are equivalent except for whether the initiator or responder 2790 transport connection is used for communication. 2792 A CER message is always sent on the initiating connection immediately 2793 after the connection request is successfully completed. In the case 2794 of an election, one of the two connections will shut down. The 2795 responder connection will survive if the Origin-Host of the local 2796 Diameter entity is higher than that of the peer; the initiator 2797 connection will survive if the peer's Origin-Host is higher. All 2798 subsequent messages are sent on the surviving connection. Note that 2799 the results of an election on one peer are guaranteed to be the 2800 inverse of the results on the other. 2802 For TLS usage, a TLS handshake will begin when both ends are in the 2803 open state. If the TLS handshake is successful, all further messages 2804 will be sent via TLS. If the handshake fails, both ends move to the 2805 closed state. 2807 The state machine constrains only the behavior of a Diameter 2808 implementation as seen by Diameter peers through events on the wire. 2809 Any implementation that produces equivalent results is considered 2810 compliant. 2812 state event action next state 2813 ----------------------------------------------------------------- 2814 Closed Start I-Snd-Conn-Req Wait-Conn-Ack 2815 R-Conn-CER R-Accept, R-Open 2816 Process-CER, 2817 R-Snd-CEA 2819 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA 2820 I-Rcv-Conn-Nack Cleanup Closed 2821 R-Conn-CER R-Accept, Wait-Conn-Ack/ 2822 Process-CER Elect 2823 Timeout Error Closed 2825 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open 2826 R-Conn-CER R-Accept, Wait-Returns 2827 Process-CER, 2828 Elect 2829 I-Peer-Disc I-Disc Closed 2830 I-Rcv-Non-CEA Error Closed 2831 Timeout Error Closed 2833 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns 2834 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open 2835 R-Peer-Disc R-Disc Wait-Conn-Ack 2836 R-Conn-CER R-Reject Wait-Conn-Ack/ 2837 Elect 2838 Timeout Error Closed 2840 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open 2841 I-Peer-Disc I-Disc, R-Open 2842 R-Snd-CEA 2843 I-Rcv-CEA R-Disc I-Open 2844 R-Peer-Disc R-Disc Wait-I-CEA 2845 R-Conn-CER R-Reject Wait-Returns 2846 Timeout Error Closed 2848 R-Open Send-Message R-Snd-Message R-Open 2849 R-Rcv-Message Process R-Open 2850 R-Rcv-DWR Process-DWR, R-Open 2851 R-Snd-DWA 2852 R-Rcv-DWA Process-DWA R-Open 2853 R-Conn-CER R-Snd-CEA R-Open 2854 R-Reject 2855 Stop R-Snd-DPR Closing 2856 R-Rcv-DPR R-Snd-DPA, Closed 2857 R-Disc 2858 R-Peer-Disc R-Disc Closed 2859 R-Rcv-CER R-Snd-CEA R-Open 2860 R-Rcv-CEA Process-CEA R-Open 2862 I-Open Send-Message I-Snd-Message I-Open 2863 I-Rcv-Message Process I-Open 2864 I-Rcv-DWR Process-DWR, I-Open 2865 I-Snd-DWA 2866 I-Rcv-DWA Process-DWA I-Open 2867 R-Conn-CER R-Reject I-Open 2868 Stop I-Snd-DPR Closing 2869 I-Rcv-DPR I-Snd-DPA, Closed 2870 I-Disc 2871 I-Peer-Disc I-Disc Closed 2872 I-Rcv-CER I-Snd-CEA I-Open 2873 I-Rcv-CEA Process-CEA I-Open 2875 Closing I-Rcv-DPA I-Disc Closed 2876 R-Rcv-DPA R-Disc Closed 2877 Timeout Error Closed 2878 I-Peer-Disc I-Disc Closed 2879 R-Peer-Disc R-Disc Closed 2881 5.6.1 Incoming connections 2883 When a connection request is received from a Diameter peer, it is 2884 not, in the general case, possible to know the identity of that peer 2885 until a CER is received from it. This is because host and port 2886 determine the identity of a Diameter peer; and the source port of an 2887 incoming connection is arbitrary. Upon receipt of CER, the identity 2888 of the connecting peer can be uniquely determined from Origin-Host. 2890 For this reason, a Diameter peer must employ logic separate from the 2891 state machine to receive connection requests, accept them, and await 2892 CER. Once CER arrives on a new connection, the Origin-Host that 2893 identifies the peer is used to locate the state machine associated 2894 with that peer, and the new connection and CER are passed to the 2895 state machine as an R-Conn-CER event. 2897 The logic that handles incoming connections SHOULD close and discard 2898 the connection if any message other than CER arrives, or if an 2899 implementation-defined timeout occurs prior to receipt of CER. 2901 Because handling of incoming connections up to and including receipt 2902 of CER requires logic, separate from that of any individual state 2903 machine associated with a particular peer, it is described separately 2904 in this section rather than in the state machine above. 2906 5.6.2 Events 2908 Transitions and actions in the automaton are caused by events. In 2909 this section, we will ignore the -I and -R prefix, since the actual 2910 event would be identical, but would occur on one of two possible 2911 connections. 2913 Start The Diameter application has signaled that a 2914 connection should be initiated with the peer. 2916 R-Conn-CER An acknowledgement is received stating that the 2917 transport connection has been established, and the 2918 associated CER has arrived. 2920 Rcv-Conn-Ack A positive acknowledgement is received confirming 2921 that the transport connection is established. 2923 Rcv-Conn-Nack A negative acknowledgement was received stating 2924 that the transport connection was not established. 2926 Timeout An application-defined timer has expired while 2927 waiting for some event. 2929 Rcv-CER A CER message from the peer was received. 2931 Rcv-CEA A CEA message from the peer was received. 2933 Rcv-Non-CEA A message other than CEA from the peer was 2934 received. 2936 Peer-Disc A disconnection indication from the peer was 2937 received. 2939 Rcv-DPR A DPR message from the peer was received. 2941 Rcv-DPA A DPA message from the peer was received. 2943 Win-Election An election was held, and the local node was the 2944 winner. 2946 Send-Message A message is to be sent. 2948 Rcv-Message A message other than CER, CEA, DPR, DPA, DWR or DWA 2949 was received. 2951 Stop The Diameter application has signaled that a 2952 connection should be terminated (e.g., on system 2953 shutdown). 2955 5.6.3 Actions 2956 Actions in the automaton are caused by events and typically indicate 2957 the transmission of packets and/or an action to be taken on the 2958 connection. In this section we will ignore the I- and R- prefix, 2959 since the actual action would be identical, but would occur on one of 2960 two possible connections. 2962 Snd-Conn-Req A transport connection is initiated with the peer. 2964 Accept The incoming connection associated with the R- 2965 Conn-CER is accepted as the responder connection. 2967 Reject The incoming connection associated with the R- 2968 Conn-CER is disconnected. 2970 Process-CER The CER associated with the R-Conn-CER is 2971 processed. 2973 Snd-CER A CER message is sent to the peer. 2975 Snd-CEA A CEA message is sent to the peer. 2977 Cleanup If necessary, the connection is shutdown, and any 2978 local resources are freed. 2980 Error The transport layer connection is disconnected, 2981 either politely or abortively, in response to an 2982 error condition. Local resources are freed. 2984 Process-CEA A received CEA is processed. 2986 Snd-DPR A DPR message is sent to the peer. 2988 Snd-DPA A DPA message is sent to the peer. 2990 Disc The transport layer connection is disconnected, and 2991 local resources are freed. 2993 Elect An election occurs (see Section 5.6.4 for more 2994 information). 2996 Snd-Message A message is sent. 2998 Snd-DWR A DWR message is sent. 3000 Snd-DWA A DWA message is sent. 3002 Process-DWR The DWR message is serviced. 3004 Process-DWA The DWA message is serviced. 3006 Process A message is serviced. 3008 5.6.4 The Election Process 3010 The election is performed on the responder. The responder compares 3011 the Origin-Host received in the CER sent by its peer with its own 3012 Origin-Host. If the local Diameter entity's Origin-Host is higher 3013 than the peer's, a Win-Election event is issued locally. 3015 The comparison proceeds by considering the shorter OctetString to be 3016 padded with zeros so that it length is the same as the length of the 3017 longer, then performing an octet-by-octet unsigned comparison with 3018 the first octet being most significant. Hanging octets are assumed to 3019 have value 0x80. 3021 6 Diameter message processing 3023 This section describes how Diameter requests and answers are created 3024 and processed. 3026 6.1 Diameter Request Routing Overview 3028 A request is sent towards its final destination using a combination 3029 of the Destination-Realm and Destination-Host AVPs, in one of these 3030 three combinations: 3031 - a request that is not able to be proxied (such as CER) MUST NOT 3032 contain either Destination-Realm or Destination-Host AVPs. 3033 - a request that needs to be sent to a home server serving a 3034 specific realm, but not to a specific server (such as the first 3035 request of a series of round-trips), MUST contain a 3036 Destination-Realm AVP, but MUST NOT contain a Destination-Host 3037 AVP. 3038 - otherwise, a request that needs to be sent to a specific home 3039 server among those serving a given realm, MUST contain both the 3040 Destination-Realm and Destination-Host AVPs. 3042 The Destination-Host AVP is used as described above when the 3043 destination of the request is fixed, which includes: 3044 - Authentication requests that span multiple round trips 3045 - A Diameter message that uses a security mechanism that makes use 3046 of a pre-established session key shared between the source and 3047 the final destination of the message. 3048 - Server initiated messages that MUST be received by a specific 3049 Diameter client (e.g. access device), such as the Abort- 3050 Session-Request message, which is used to request that a 3051 particular user's session be terminated. 3053 Note that an agent can forward a request to a host described in the 3054 Destination-Host AVP only if the host in question is included in its 3055 peer table (see section 2.7). Otherwise, the request is routed based 3056 on the Destination-Realm only (see sections 6.1.6). 3058 The Destination-Realm AVP MUST be present if the message is 3059 proxiable. Proxiable request messages MUST also contain an Acct- 3060 Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific- 3061 Application-Id AVP. A message that MUST NOT be relayed, proxied or 3062 redirected MUST NOT include the Destination-Realm in its ABNF. The 3063 value of the Destination-Realm AVP MAY be extracted from the User- 3064 Name AVP, or other application-specific methods. 3066 When a message is received, the message is processed in the following 3067 order: 3068 1. If the message is destined for the local host, the procedures 3069 listed in section 6.1.4 are followed. 3070 2. If the message is intended for a Diameter peer with whom the 3071 local host is able to directly communicate, the procedures 3072 listed in section 6.1.5 are followed. This is known as Request 3073 Forwarding. x.ti -3 3. The procedures listed in section 6.1.6 3074 are followed, which is known as Request Routing. 3075 4. If none of the above is successful, an answer is returned with 3076 the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. 3078 For routing of Diameter messages to work within an administrative 3079 domain, all Diameter nodes within the realm MUST be peers. 3081 Note the processing rules contained in this section are intended to 3082 be used as general guidelines to Diameter developers. Certain 3083 implementations MAY use different methods than the ones described 3084 here, and still comply with the protocol specification. 3086 6.1.1 Originating a Request 3088 When creating a request, in addition to any other procedures 3089 described in the application definition for that specific request, 3090 the following procedures MUST be followed: 3091 - the Command-Code should be set to the appropriate value 3092 - the 'R' bit should be set 3093 - the End-to-End Identifier should be set to a locally unique 3094 value 3095 - the Origin-Host and Origin-Realm AVPs MUST be set to the 3096 appropriate values, used to identify the source of the message 3097 - the Destination-Host and Destination-Realm AVPs MUST be set to 3098 the appropriate values as described in section 6.1. 3099 - an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor- 3100 Specific-Application-Id AVP must be included if the request is 3101 proxiable. 3103 6.1.2 Sending a Request 3105 When sending a request, originated either locally, or as the result 3106 of a forwarding or routing operation, the following procedures MUST 3107 be followed: 3108 - the Hop-by-Hop Identifier should be set to a locally unique 3109 value 3110 - The message should be saved in the list of pending requests. 3112 Other actions to perform on the message based on the particular role 3113 the agent is playing are described in the following sections. 3115 6.1.3 Receiving Requests 3117 A relay or proxy agent MUST check for forwarding loops when receiving 3118 requests. A loop is detected if the server finds its own identity in 3119 a Route-Record AVP. When such an event occurs, the agent MUST answer 3120 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 3122 6.1.4 Processing Local Requests 3124 A request is known to be for local consumption when one of the 3125 following conditions occur: 3126 - The Destination-Host AVP contains the local host's identity, 3127 - The Destination-Host AVP is not present, the Destination-Realm 3128 AVP contains a realm the server is configured to process 3129 locally, and the Diameter application is locally supported, or 3130 - Both the Destination-Host and the Destination-Realm are not 3131 present. 3133 When a request is locally processed, the rules in section 6.2 should 3134 be used to generate the corresponding answer. 3136 6.1.5 Request Forwarding 3138 Request forwarding is done using the Diameter Peer Table. The 3139 Diameter peer table contains all of the peers that the local node is 3140 able to directly communicate with. 3142 When a request is received, and the host encoded in the Destination- 3143 Host AVP is one that is present in the peer table, the message SHOULD 3144 be forwarded to the peer. 3146 6.1.6 Request Routing 3148 Diameter request message routing is done via realms and applications. 3149 A Diameter message that is able to be proxied MUST include the target 3150 realm in the Destination-Realm AVP and one of the application 3151 identification AVPs Auth-Application-Id, Acct-Application-Id or 3152 Vendor-Specific-Application-Id. The realm MAY be retrieved from the 3153 User-Name AVP, which is in the form of a Network Access Identifier 3154 (NAI). The realm portion of the NAI is inserted in the Destination- 3155 Realm AVP. 3157 Diameter agents MAY have a list of locally supported realms and 3158 applications, and MAY have a list of externally supported realms and 3159 applications. When a request is received that includes a realm and/or 3160 application that is not locally supported, the message is routed to 3161 the peer configured in the Realm Routing Table table (see section 3162 2.7). 3164 6.1.7 Redirecting requests 3166 When a redirect agent receives a request whose routing entry is set 3167 to REDIRECT, it MUST reply with an answer message with the 'E' bit 3168 set, while maintaining the Hop-by-Hop Identifier in the header, and 3169 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of 3170 the servers associated with the routing entry are added in separate 3171 Redirect-Host AVP. 3173 +------------------+ 3174 | Diameter | 3175 | Redirect Agent | 3176 +------------------+ 3177 ^ | 2. command + 'E' bit 3178 1. Request | | Result-Code = 3179 joe@xyz.com | | DIAMETER_REDIRECT_INDICATION + 3180 | | Redirect-Host AVP(s) 3181 | v 3182 +---------+ 3. Request +----------+ 3183 | abc.net |------------->| xyz.net | 3184 | Relay | | Diameter | 3185 | Agent |<-------------| Server | 3186 +---------+ 4. Answer +----------+ 3187 Figure 6: Diameter Redirect Agent 3189 The receiver of the answer message with the 'E' bit set, and the 3190 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- 3191 hop field in the Diameter header to identify the request in the 3192 pending message queue (see Section 5.3) that is to be redirected. If 3193 no transport connection exists with the new agent, one is created, 3194 and the request is sent directly to it. 3196 Multiple Redirect-Host AVPs are allowed. The receiver of the answer 3197 message with the 'E' bit set selects exactly one of these hosts as 3198 the destination of the redirected message. 3200 6.1.8 Relaying and Proxying Requests 3202 A relay or proxy agent MUST append a Route-Record AVP to all requests 3203 forwarded. The AVP contains the identity of the peer the request was 3204 received from. 3206 The Hop-by-Hop identifier in the request is saved, and replaced with 3207 a locally unique value. The source of the request is also saved, 3208 which includes the IP address, port and protocol. 3210 A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if 3211 it requires access to any local state information when the 3212 corresponding response is received. Alternatively, it MAY simply use 3213 local storage to store state information. 3215 The message is then forwarded to the next hop, as identified in the 3216 Realm Routing Table. 3218 Figure 7 provides an example of message routing using the procedures 3219 listed in these sections. 3221 (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) 3222 (Origin-Realm=mno.net) (Origin-Realm=mno.net) 3223 (Destination-Realm=abc.com) (Destination-Realm=abc.com) 3224 (Route-Record=nas.mno.net) 3225 +------+ ------> +------+ ------> +------+ 3226 | | (Request) | | (Request) | | 3227 | NAS +-------------------+ DRL +-------------------+ HMS | 3228 | | | | | | 3229 +------+ <------ +------+ <------ +------+ 3230 mno.net (Answer) mno.net (Answer) abc.com 3231 (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) 3232 (Origin-Realm=abc.com) (Origin-Realm=abc.com) 3233 Figure 7: Routing of Diameter messages 3235 6.2 Diameter Answer Processing 3236 When a request is locally processed, the following procedures MUST be 3237 applied to create the associated answer, in addition to any 3238 additional procedures that MAY be discussed in the Diameter 3239 application defining the command: 3241 - The same Hop-by-Hop identifier in the request is used in the 3242 answer. 3243 - The local host's identity is encoded in the Origin-Host AVP. 3244 - The Destination-Host and Destination-Realm AVPs MUST NOT be 3245 present in the answer message. 3246 - The Result-Code AVP is added with its value indicating success 3247 or failure. 3248 - If the Session-Id is present in the request, it MUST be included 3249 in the answer. 3250 - Any Proxy-Info AVPs in the request MUST be added to the answer 3251 message, in the same order they were present in the request. 3252 - The 'P' bit is set to the same value as the one in the request. 3253 - The same End-to-End identifier in the request is used in the 3254 answer. 3256 Note that the error messages (see section 7.2) are also subjected to 3257 the above processing rules. 3259 6.2.1 Processing received Answers 3261 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an 3262 answer received against the list of pending requests. The 3263 corresponding message should be removed from the list of pending 3264 requests. It SHOULD ignore answers received that do not match a known 3265 Hop-by-Hop Identifier. 3267 6.2.2 Relaying and Proxying Answers 3269 If the answer is for a request which was proxied or relayed, the 3270 agent MUST restore the original value of the Diameter header's Hop- 3271 by-Hop Identifier field. 3273 If the last Proxy-Info AVP in the message is targeted to the local 3274 Diameter server, the AVP MUST be removed before the answer is 3275 forwarded. 3277 If a relay or proxy agent receives an answer with a Result-Code AVP 3278 indicating a failure, it MUST NOT modify the contents of the AVP. Any 3279 additional local errors detected SHOULD be logged, but not reflected 3280 in the Result-Code AVP. If the agent receives an answer message with 3281 a Result-Code AVP indicating success, and it wishes to modify the AVP 3282 to indicate an error, it MUST modify the Result-Code AVP to contain 3283 the appropriate error in the message destined towards the access 3284 device as well as include the Error-Reporting-Host AVP and it MUST 3285 issue an STR on behalf of the access device. 3287 The agent MUST then send the answer to the host that it received the 3288 original request from. 3290 6.3 Origin-Host AVP 3292 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and 3293 MUST be present in all Diameter messages. This AVP identifies the 3294 endpoint that originated the Diameter message. Relay agents MUST NOT 3295 modify this AVP. 3297 The value of the Origin-Host AVP is guaranteed to be unique within a 3298 single host. 3300 Note that the Origin-Host AVP may resolve to more than one address as 3301 the Diameter peer may support more than one address. 3303 This AVP SHOULD be placed as close to the Diameter header as 3304 possible. 3306 6.4 Origin-Realm AVP 3308 The Origin-Realm AVP (AVP Code 296) is of type UTF8String. This AVP 3309 contains the Realm of the originator of any Diameter message and MUST 3310 be present in all messages. 3312 This AVP SHOULD be placed as close to the Diameter header as 3313 possible. 3315 6.5 Destination-Host AVP 3317 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. 3318 This AVP MUST be present in all unsolicited agent initiated messages, 3319 MAY be present in request messages, and MUST NOT be present in Answer 3320 messages. 3322 The absence of the Destination-Host AVP will cause a message to be 3323 sent to any Diameter server supporting the application within the 3324 realm specified in Destination-Realm AVP. 3326 This AVP SHOULD be placed as close to the Diameter header as 3327 possible. 3329 6.6 Destination-Realm AVP 3331 The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and 3332 contains the realm the message is to be routed to. The Destination- 3333 Realm AVP MUST NOT be present in Answer messages. Diameter Clients 3334 insert the realm portion of the User-Name AVP. Diameter servers 3335 initiating a request message use the value of the Origin-Realm AVP 3336 from a previous message received from the intended target host 3337 (unless it is known a priori). When present, the Destination-Realm 3338 AVP is used to perform message routing decisions. 3340 Request messages whose ABNF does not list the Destination-Realm AVP 3341 as a mandatory AVP are inherently non-routable messages. 3343 This AVP SHOULD be placed as close to the Diameter header as 3344 possible. 3346 6.7 Routing AVPs 3348 The AVPs defined in this section are Diameter AVPs used for routing 3349 purposes. These AVPs change as Diameter messages are processed by 3350 agents, and therefore MUST NOT be protected by end-to-end security. 3352 6.7.1 Route-Record AVP 3354 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The 3355 identity added in this AVP MUST be the same as the one received in 3356 the Origin-Host of the Capabilities Exchange message. 3358 6.7.2 Proxy-Info AVP 3360 The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped 3361 Data field has the following ABNF grammar: 3363 Proxy-Info ::= < AVP Header: 284 > 3364 { Proxy-Host } 3365 { Proxy-State } 3366 * [ AVP ] 3368 6.7.3 Proxy-Host AVP 3369 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This 3370 AVP contains the identity of the host that added the Proxy-Info AVP. 3372 6.7.4 Proxy-State AVP 3374 The Proxy-State AVP (AVP Code 33) is of type OctetString, and 3375 contains state local information, and MUST be treated as opaque data. 3377 6.8 Auth-Application-Id AVP 3379 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and 3380 is used in order to advertise support of the Authentication and 3381 Authorization portion of an application (see Section 2.4). The Auth- 3382 Application-Id MUST also be present in all Authentication and/or 3383 Authorization messages that are defined in a separate Diameter 3384 specification and have an Application ID assigned. 3386 This AVP SHOULD be placed as close to the Diameter header as 3387 possible. 3389 6.9 Acct-Application-Id AVP 3391 The Acct-application-Id AVP (AVP Code 259) is of type Unsigned32 and 3392 is used in order to advertise support of the Accounting portion of an 3393 application (see Section 2.4). The Acct-Application-Id MUST also be 3394 present in all Accounting messages that are defined in a separate 3395 Diameter specification and have an Application ID assigned. 3397 This AVP SHOULD be placed as close to the Diameter header as 3398 possible. 3400 6.10 Inband-Security-Id AVP 3402 The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and 3403 is used in order to advertise support of the Security portion of the 3404 application. 3406 Currently, the following values are supported, but there is ample 3407 room to add new security Ids. 3409 NO_INBAND_SECURITY 0 3410 This peer does not support the TLS security model. This is the 3411 default value, if the AVP is omitted. 3413 TLS 1 3414 This node supports TLS security, as defined by [TLS]. 3416 6.11 Vendor-Specific-Application-Id AVP 3418 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type 3419 Grouped and is used to advertise support of a vendor-specific 3420 Diameter Application. Exactly one of the Auth-Application-Id and 3421 Acct-Application-Id AVPs MAY be present. 3423 This AVP MUST also be present as the first AVP in all experimental 3424 commands defined in the vendor-specific application. 3426 This AVP SHOULD be placed as close to the Diameter header as 3427 possible. 3429 AVP Format 3431 ::= < AVP Header: 260 > 3432 1* [ Vendor-Id ] 3433 0*1{ Auth-Application-Id } 3434 0*1{ Acct-Application-Id } 3436 6.12 Redirect-Host AVP 3438 One or more of instances of this AVP MUST be present if the answer 3439 message's 'E' bit is set and the Result-Code AVP is set to 3440 DIAMETER_REDIRECT_INDICATION. 3442 Upon receiving the above, the receiving Diameter node SHOULD forward 3443 the request directly to one of the hosts identified in these AVPs. 3444 The server contained in the selected Redirect-Host AVP SHOULD be used 3445 for all messages pertaining to this session. 3447 6.13 Redirect-Host-Usage AVP 3449 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. 3450 This AVP MAY be present in answer messages whose 'E' bit is set and 3451 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3453 When present, this AVP dictates how the routing entry resulting from 3454 the Redirect-Host is to be used. The following values are supported: 3456 DONT_CACHE 0 3457 The host specified in the Redirect-Host AVP should not be 3458 cached. This is the default value. 3460 ALL_SESSION 1 3461 All messages within the same session, as defined by the same 3462 value of the Session-ID AVP MAY be sent to the host specified 3463 in the Redirect-Host AVP. 3465 ALL_REALM 2 3466 All messages destined for the realm requested MAY be sent to 3467 the host specified in the Redirect-Host AVP. 3469 REALM_AND_APPLICATION 3 3470 All messages for the application requested to the realm 3471 specified MAY be sent to the host specified in the Redirect- 3472 Host AVP. 3474 ALL_APPLICATION 4 3475 All messages for the application requested MAY be sent to the 3476 host specified in the Redirect-Host AVP. 3478 ALL_HOST 5 3479 All messages that would be sent to the host that generated the 3480 Redirect-Host MAY be sent to the host specified in the 3481 Redirect-Host AVP. 3483 ALL_USER 6 3484 All messages for the user requested MAY be sent to the host 3485 specified in the Redirect-Host AVP. 3487 6.14 Redirect-Max-Cache-Time AVP 3489 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. 3490 This AVP MUST be present in answer messages whose 'E' bit is set, the 3491 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 3492 Redirect-Host-Usage AVP set to a non-zero value. 3494 This AVP contains the maximum number of seconds the peer and route 3495 table entries, created as a result of the Redirect-Host, will be 3496 cached. Note that once a host created due to a redirect indication is 3497 no longer reachable, any associated peer and routing table entries 3498 MUST be deleted. 3500 6.15 E2E-Sequence AVP 3502 The E2E-Sequence AVP provides anti-replay protection for end to end 3503 messages and is of type grouped. It contains a random value (an 3504 OctetString with a nonce) and counter (an Integer). For each end-to- 3505 end peer with which a node communicates (or remembers communicating) 3506 a different nonce value MUST be used and the counter is intitiated at 3507 zero and increases by one each time this AVP is emitted to that peer. 3509 This AVP MUST be included in all messages which use end-to-end 3510 protection (e.g. CMS signing or encryption). 3512 7 Error Handling 3514 There are two different types of errors in Diameter; protocol and 3515 application errors. A protocol error is one that occurs at the base 3516 protocol level, and MAY require per hop attention (e.g. message 3517 routing error). Application errors, on the other hand, are generally 3518 occur due to a problem with a function specified in a Diameter 3519 application (e.g. user authentication, Missing AVP). 3521 Result-Code AVP values that are used to report protocol errors MUST 3522 only be present in answer messages whose 'E' bit is set. When a 3523 request message is received that causes a protocol error, an answer 3524 message is returned with the 'E' bit set, and the Result-Code AVP is 3525 set to the appropriate protocol error value. As the answer is sent 3526 back towards the originator of the request, each proxy or relay agent 3527 MAY take action on the message. 3529 1. Request +---------+ Link Broken 3530 +-------------------------->|Diameter |----///----+ 3531 | +---------------------| | v 3532 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+ 3533 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| 3534 | | | Home | 3535 | Relay 1 |--+ +---------+ | Server | 3536 +---------+ | 3. Request |Diameter | +--------+ 3537 +-------------------->| | ^ 3538 | Relay 3 |-----------+ 3539 +---------+ 3540 Figure 8: Example of Protocol Error causing answer message 3542 Figure 8 provides an example of a message forwarded upstream by a 3543 Diameter relay. When the message is received by Relay 2, and it 3544 detects that it cannot forward the request to the home server, an 3545 answer message is returned with the 'E' bit set and the Result-Code 3546 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls 3547 within the protocol error category, Relay 1 would take special 3548 action, and given the error, attempt to route the message through its 3549 alternate Relay 3. 3551 +---------+ 1. Request +---------+ 2. Request +---------+ 3552 | Access |------------>|Diameter |------------>|Diameter | 3553 | | | | | Home | 3554 | Device |<------------| Relay |<------------| Server | 3555 +---------+ 4. Answer +---------+ 3. Answer +---------+ 3556 (Missing AVP) (Missing AVP) 3557 Figure 9: Example of Application Error Answer message 3559 Figure 9 provides an example of a Diameter message that caused an 3560 application error. When application errors occur, the Diameter entity 3561 reporting the error clears the 'R' bit in the Command Flags, and adds 3562 the Result-Code AVP with the proper value. Application errors do not 3563 require any proxy or relay agent involvement, and therefore the 3564 message would be forwarded back to the originator of the request. 3566 There are certain Result-Code AVP application errors that require 3567 additional AVPs to be present in the answer. In these cases, the 3568 Diameter node that sets the Result-Code AVP to indicate the error 3569 MUST add the AVPs. Examples are: 3571 - An unrecognized AVP is received with the 'M' bit (Mandatory bit) 3572 set, causes an answer to be sent with the Result-Code AVP set to 3573 DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the 3574 offending AVP. 3575 - An AVP that is received with an unrecognized value causes an 3576 answer to be returned with the Result-Code AVP set to 3577 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing 3578 the AVP causing the error. 3579 - A command is received with an AVP that is omitted, yet is 3580 mandatory according to the command's ABNF. The receiver issues 3581 an answer with the Result-Code set to DIAMETER_MISSING_AVP, and 3582 creates an AVP with the AVP Code and other fields set as 3583 expected in the missing AVP. The created AVP is then added to 3584 the Failed-AVP AVP. 3586 The Result-Code AVP describes the error that the Diameter node 3587 encountered in its processing. In case there are multiple errors, the 3588 Diameter node MUST report only the first error it encountered 3589 (detected possibly in some implementation dependent order). The 3590 specific errors that can be described by this AVP are described in 3591 the following section. 3593 7.1 Result-Code AVP 3595 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 3596 indicates whether a particular request was completed successfully or 3597 whether an error occurred. All Diameter answer messages defined in 3598 IETF applications MUST include one Result-Code AVP. A non-successful 3599 Result-Code AVP (one containing a non 2xxx value other than 3600 DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host 3601 AVP if the host setting the Result-Code AVP is different from the 3602 identity encoded in the Origin-Host AVP. 3604 The Result-Code data field contains an IANA-managed 32-bit address 3605 space representing errors (see section 11.4). Diameter provides the 3606 following classes of errors, all identified by the thousands digit in 3607 the decimal notation: 3608 - 1xxx (Informational) 3609 - 2xxx (Success) 3610 - 3xxx (Protocol Errors) 3611 - 4xxx (Transient Failures) 3612 - 5xxx (Permanent Failure) 3614 A non-recognize class (one whose first digit is not defined in this 3615 section) MUST be handled as a permanent failure. 3617 7.1.1 Informational 3619 Errors that fall within this category are used to inform the 3620 requester that a request could not be satisfied, and additional 3621 action is required on its part before access is granted. 3623 DIAMETER_MULTI_ROUND_AUTH 1001 3624 This informational error is returned by a Diameter server to 3625 inform the access device that the authentication mechanism 3626 being used required multiple round trips, and a subsequent 3627 request needs to be issued in order for access to be granted. 3629 7.1.2 Success 3631 Errors that fall within the Success category are used to inform a 3632 peer that a request has been successfully completed. 3634 DIAMETER_SUCCESS 2001 3635 The Request was successfully completed. 3637 DIAMETER_LIMITED_SUCCESS 2002 3638 When returned, the request was successfully completed, but 3639 additional processing is required by the application in order 3640 to provide service to the user. 3642 7.1.3 Protocol Errors 3643 Errors that fall within the Protocol Error category SHOULD be treated 3644 on a per-hop basis, and Diameter proxies MAY attempt to correct the 3645 error, if it is possible. Note that these and only these errors MUST 3646 only be used in answer messages whose 'E' bit is set. 3648 DIAMETER_COMMAND_UNSUPPORTED 3001 3649 The Request contained a Command-Code that the receiver did not 3650 recognize or support. This MUST be used when when a Diameter 3651 node receives an experimental command that it does not 3652 understand. 3654 DIAMETER_UNABLE_TO_DELIVER 3002 3655 This error is given when Diameter can not deliver the message 3656 to the destination, either because no host within the realm was 3657 available to process the request, or because Destination-Host 3658 AVP was given without the associated Destination-Realm AVP. 3660 DIAMETER_REALM_NOT_SERVED 3003 3661 The intended realm of the request is not recognized. 3663 DIAMETER_TOO_BUSY 3004 3664 When returned, a Diameter node SHOULD attempt to send the 3665 message to an alternate peer. This error MUST only be used when 3666 a specific server is requested, and it cannot provide the 3667 requested service. 3669 DIAMETER_LOOP_DETECTED 3005 3670 An agent detected a loop while trying to get the message to the 3671 intended recipient. The message MAY be sent to an alternate 3672 peer, if one is available, but the peer reporting the error has 3673 identified a configuration problem. 3675 DIAMETER_REDIRECT_INDICATION 3006 3676 A redirect agent has determined that the request could not be 3677 satisfied locally and the initiator of the request should 3678 direct the request directly to the server, whose contact 3679 information has been added to the response. When set, the 3680 Redirect-Host AVP MUST be present. 3682 DIAMETER_APPLICATION_UNSUPPORTED 3007 3683 A request was sent for an application that is not supported. 3685 DIAMETER_INVALID_HDR_BITS 3008 3686 A request was received whose bits in the Diameter header were 3687 either set to an invalid combination, or to a value that is 3688 inconsistent with the command code's definition. 3690 DIAMETER_INVALID_AVP_BITS 3009 3691 A request was received that included an AVP whose flag bits are 3692 set to an unrecognized value, or that is inconsistent with the 3693 AVP's definition. 3695 DIAMETER_UNKNOWN_PEER 3010 3696 A CER was received from an unknown peer. 3698 7.1.4 Transient Failures 3700 Errors that fall within the transient failures category are used to 3701 inform a peer that the request could not be satisfied at the time it 3702 was received, but MAY be able to satisfy the request in the future. 3704 DIAMETER_AUTHENTICATION_REJECTED 4001 3705 The authentication process for the user failed, most likely due 3706 to an invalid password used by the user. Further attempts MUST 3707 only be tried after prompting the user for a new password. 3709 DIAMETER_OUT_OF_SPACE 4002 3710 A Diameter node received the accounting request but was unable 3711 to commit it to stable storage due to a temporary lack of 3712 space. 3714 ELECTION_LOST 4003 3715 The peer has determined that it has lost the election process 3716 and has therefore disconnected the transport connection. 3718 7.1.5 Permanent Failures 3720 Errors that fall within the permanent failures category are used to 3721 inform the peer that the request failed, and should not be attempted 3722 again. 3724 DIAMETER_AVP_UNSUPPORTED 5001 3725 The peer received a message that contained an AVP that is not 3726 recognized or supported and was marked with the Mandatory bit. 3727 A Diameter message with this error MUST contain one or more 3728 Failed-AVP AVP containing the AVPs that caused the failure. 3730 DIAMETER_UNKNOWN_SESSION_ID 5002 3731 The request contained an unknown Session-Id. 3733 DIAMETER_AUTHORIZATION_REJECTED 5003 3734 A request was received for which the user could not be 3735 authorized. This error could occur if the service requested is 3736 not permitted to the user. 3738 DIAMETER_INVALID_AVP_VALUE 5004 3739 The request contained an AVP with an invalid value in its data 3740 portion. A Diameter message indicating this error MUST include 3741 the offending AVPs within a Failed-AVP AVP. 3743 DIAMETER_MISSING_AVP 5005 3744 The request did not contain an AVP that is required by the 3745 Command Code definition. If this value is sent in the Result- 3746 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 3747 The Failed-AVP AVP MUST contain an example of the missing AVP 3748 complete with the Vendor-Id if applicable. The value field of 3749 the missing AVP should be of correct minimum length and contain 3750 zeroes. 3752 DIAMETER_RESOURCES_EXCEEDED 5006 3753 A request was received that cannot be authorized because the 3754 user has already expended allowed resources. An example of this 3755 error condition is a user that is restricted to one dial-up PPP 3756 port, attempts to establish a second PPP connection. 3758 DIAMETER_CONTRADICTING_AVPS 5007 3759 The Home Diameter server has detected AVPs in the request that 3760 contradicted each other, and is not willing to provide service 3761 to the user. One or more Failed-AVP AVPs MUST be present, 3762 containing the AVPs that contradicted each other. 3764 DIAMETER_AVP_NOT_ALLOWED 5008 3765 A message was received with an AVP that MUST NOT be present. 3766 The Failed-AVP AVP MUST be included and contain a copy of the 3767 offending AVP. 3769 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 3770 A message was received that included an AVP that appeared more 3771 often than permitted in the message definition. The Failed-AVP 3772 AVP MUST be included and contain a copy of the first instance 3773 of the offending AVP that exceeded the maximum number of 3774 occurrences 3776 DIAMETER_NO_COMMON_APPLICATION 5010 3777 This error is returned when a CER message is received, and 3778 there are no common applications supported between the peers. 3780 DIAMETER_UNSUPPORTED_VERSION 5011 3781 This error is returned when a request was received, whose 3782 version number is unsupported. 3784 DIAMETER_UNABLE_TO_COMPLY 5012 3785 This error is returned when a request is rejected for 3786 unspecified reasons. 3788 DIAMETER_INVALID_BIT_IN_HEADER 5013 3789 This error is returned when an unrecognized bit in the Diameter 3790 header is set to one (1). 3792 DIAMETER_INVALID_AVP_LENGTH 5014 3793 The request contained an AVP with an invalid length. A Diameter 3794 message indicating this error MUST include the offending AVPs 3795 within a Failed-AVP AVP. 3797 DIAMETER_INVALID_MESSAGE_LENGTH 5015 3798 This error is returned when a request is received with an 3799 invalid message length. 3801 DIAMETER_INVALID_AVP_BIT_COMBO 5016 3802 The request contained an AVP with which is not allowed to have 3803 the given value in the AVP Flags field. A Diameter message 3804 indicating this error MUST include the offending AVPs within a 3805 Failed-AVP AVP. 3807 7.2 Error Bit 3809 The 'E' (Error Bit) in the Diameter header is set when the request 3810 caused a protocol-related error (see section 7.1.3). A message with 3811 the 'E' bit MUST NOT be sent as a response to an answer message. Note 3812 that a message with the 'E' bit set is still subjected to the 3813 processing rules defined in section 6.2. When set, the answer message 3814 will not conform to the ABNF specification for the command, and will 3815 instead conform to the following ABNF: 3817 Message Format 3819 ::= < Diameter Header: code, ERR [PXY] > 3820 0*1< Session-Id > 3821 { Origin-Host } 3822 { Origin-Realm } 3823 { Result-Code } 3824 [ Origin-State-Id ] 3825 [ Error-Reporting-Host ] 3826 [ Proxy-Info ] 3827 * [ AVP ] 3829 Note that the code used in the header is the same that the one found 3830 in the request message, but with the 'R' bit cleared and the 'E' bit 3831 set. The 'P' bit in the header is set to the same value as the one 3832 found in the request message. 3834 7.3 Error-Message AVP 3836 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY 3837 accompany a Result-Code AVP as a human readable error message. The 3838 Error-Message AVP is not intended to be useful in real-time, and 3839 SHOULD NOT be expected to be parsed by network entities. 3841 7.4 Error-Reporting-Host AVP 3843 The Error-Reporting-Host AVP (AVP Code 294) is of type 3844 DiameterIdentity. This AVP contains the identity of the Diameter host 3845 that sent the Result-Code AVP to a value other than 2001 (Success), 3846 only if the host setting the Result-Code is different from the one 3847 encoded in the Origin-Host AVP. This AVP is intended to be used for 3848 troubleshooting purposes, and MUST be set when the Result-Code AVP 3849 indicates a failure. 3851 7.5 Failed-AVP AVP 3853 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides 3854 debugging information in cases where a request is rejected or not 3855 fully processed due to erroneous information in a specific AVP. The 3856 value of the Result-Code AVP will provide information on the reason 3857 for the Failed-AVP AVP. 3859 The possible reasons for this AVP are the presence of an improperly 3860 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 3861 value, the omission of a required AVP, the presence of an explicitly 3862 excluded AVP (see tables in section 10), or the presence of two or 3863 more occurrences of an AVP which is restricted to 0, 1, or 0-1 3864 occurrences. 3866 A Diameter message MAY contain one Failed-AVP AVP, containing the 3867 entire AVP that could not be processed successfully. If the failure 3868 reason is omission of a required AVP, an AVP with the missing AVP 3869 code, the missing vendor id, and a zero filled payload of the minimum 3870 required length for the omitted AVP will be added. 3872 AVP Format 3874 ::= < AVP Header: 279 > 3875 1* {AVP} 3877 7.6 Vendor-Specific-Result AVP 3878 The Vendor-Specific-Result AVP (AVP Code 297) is of type Grouped, and 3879 indicates whether a particular vendor-specific request was completed 3880 successfully or whether an error occurred. Its Data field has the 3881 following ABNF grammar: 3883 AVP Format 3885 Vendor-Specific-Result ::= < AVP Header: 297 > 3886 { Vendor-Id } 3887 { Vendor-Specific-Result-Code } 3889 The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies 3890 the vendor responsible for the assignment of the result code which 3891 follows. All Diameter answer messages defined in vendor-specific 3892 applications MUST include either one Result-Code AVP or one Vendor- 3893 Specific-Result AVP. 3895 7.7 Vendor-Specific-Result-Code AVP 3897 The Vendor-Specific-Result-Code AVP (AVP Code 298) is of type 3898 Unsigned32 and contains a vendor-assigned value representing the 3899 result of processing the request. 3901 It is recommended that vendor-specific result codes follow the same 3902 conventions given for the Result-Code AVP regarding the different 3903 types of result codes and the handling of errors (for non 2xxx 3904 values). 3906 8 Diameter User Sessions 3908 Diameter can provide two different types of services to applications. 3909 The first involves authentication and authorization, and can 3910 optionally make use of accounting. The second only makes use of 3911 accounting. 3913 When a service makes use of the authentication and/or authorization 3914 portion of an application, and a user requests access to the network, 3915 the Diameter client issues an auth request to its local server. The 3916 auth request is defined in a service specific Diameter application 3917 (e.g. NASREQ). The request contains a Session-Id AVP, which is used 3918 in subsequent messages (e.g. subsequent authorization, accounting, 3919 etc) relating to the user's session. The Session-Id AVP is a means 3920 for the client and servers to correlate a Diameter message with a 3921 user session. 3923 When a Diameter server authorizes a user to use network resources for 3924 a finite amount of time, and it is willing to extend the 3925 authorization via a future request, it MUST add the Authorization- 3926 Lifetime AVP to the answer message. The Authorization-Lifetime AVP 3927 defines the maximum number of seconds a user MAY make use of the 3928 resources before another authorization request is expected by the 3929 server. The Auth-Grace-Period AVP contains the number of seconds 3930 following the expiration of the Authorization-Lifetime, after which 3931 the server will release all state information related to the user's 3932 session. Note that if payment for services is expected by the serving 3933 realm from the user's home realm, the Authorization-Lifetime AVP, 3934 combined with the Auth-Grace-Period AVP, implies the maximum length 3935 of the session the home realm is willing to be fiscally responsible 3936 for. Services provided past the expiration of the Authorization- 3937 Lifetime and Auth-Grace-Period AVPs are the responsibility of the 3938 access device. Of course, the actual cost of services rendered is 3939 clearly outside the scope of the protocol. 3941 An access device that does not expect to send a re-authorization or a 3942 session termination request to the server MAY include the Auth- 3943 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint 3944 to the server. If the server accepts the hint, it agrees that since 3945 no session termination message will be received once service to the 3946 user is terminated, it cannot maintain state for the session. If the 3947 answer message from the server contains a different value in the 3948 Auth-Session-State AVP (or the default value if the AVP is absent), 3949 the access device MUST follow the server's directives. Note that the 3950 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re- 3951 authorization requests and answers. 3953 The base protocol does not include any authorization request 3954 messages, since these are largely application-specific and are 3955 defined in a Diameter application document. However, the base 3956 protocol does define a set of messages that is used to terminate user 3957 sessions. These are used to allow servers that maintain state 3958 information to free resources. 3960 When a service only makes use of the Accounting portion of the 3961 Diameter protocol, even in combination with an application, the 3962 Session-Id is still used to identify user sessions. However, the 3963 session termination messages are not used, since a session is 3964 signaled as being terminated by issuing an accounting stop message. 3966 8.1 Authorization Session State Machine 3968 This section contains a set of finite state machines, representing 3969 the life cycle of Diameter sessions, and which MUST be observed by 3970 all Diameter implementations that make use of the authentication 3971 and/or authorization portion of a Diameter application. The term 3972 Service-Specific below refers to a message defined in a Diameter 3973 application (e.g. Mobile IP, NASREQ). 3975 There are four different authorization session state machines 3976 supported in the Diameter base protocol. The first two describe a 3977 session in which the server is maintaining session state, indicated 3978 by the value of the Auth-Session-State AVP (or its absence). One 3979 describes the session from a client perspective, the other from a 3980 server perspective. The second two state machines are used when the 3981 server does not maintain session state. Here again, one describes the 3982 session from a client perspective, the other from a server 3983 perspective. 3985 When a session is moved to the Idle state, any resources that were 3986 allocated for the particular session must be released. Any event not 3987 listed in the state machines MUST be considered as an error 3988 condition, and an answer, if applicable, MUST be returned to the 3989 originator of the message. 3991 In the state table, the event 'Failure to send X' means that the 3992 Diameter agent is unable to send command X to the desired 3993 destination. This could be due to the peer being down, or due to the 3994 peer sending back a transient failure or temporary protocol error 3995 notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the 3996 Result-Code AVP of the corresponding Answer command. The event 'X 3997 successfully sent' is the complement of 'Failure to send X'. 3999 The following state machine is observed by a client when state is 4000 maintained on the server: 4002 CLIENT, STATEFUL 4003 State Event Action New State 4004 ------------------------------------------------------------- 4005 Idle Client or Device Requests Send Pending 4006 access service 4007 specific 4008 auth req 4010 Idle ASR Received Send ASA Idle 4011 for unknown session with 4012 Result-Code 4013 = UNKNOWN_ 4014 SESSION_ID 4016 Pending Successful Service-specific Grant Open 4017 authorization answer Access 4018 received with default 4019 Auth-Session-State value 4021 Pending Successful Service-specific Sent STR Discon 4022 authorization answer received 4023 but service not provided 4025 Pending Error processing successful Sent STR Discon 4026 Service-specific authorization 4027 answer 4029 Pending Failed Service-specific Cleanup Idle 4030 authorization answer received 4032 Open User or client device Send Open 4033 requests access to service service 4034 specific 4035 auth req 4037 Open Successful Service-specific Provide Open 4038 authorization answer received Service 4040 Open Failed Service-specific Discon. Idle 4041 authorization answer user/device 4042 received. 4044 Open Session-Timeout Expires on Send STR Discon 4045 Access Device 4047 Open ASR Received, Send ASA Discon 4048 client will comply with with 4049 request to end the session Result-Code 4050 = SUCCESS, 4051 Send STR. 4053 Open ASR Received, Send ASA Open 4054 client will not comply with with 4055 request to end the session Result-Code 4056 != SUCCESS 4058 Open Authorization-Lifetime + Send STR Discon 4059 Auth-Grace-Period expires on 4060 access device 4062 Discon ASR Received Send ASA Discon 4064 Discon STA Received Discon. Idle 4065 user/device 4067 The following state machine is observed by a server when it is 4068 maintaining state for the session: 4070 SERVER, STATEFUL 4071 State Event Action New State 4072 ------------------------------------------------------------- 4073 Idle Service-specific authorization Send Open 4074 request received, and successful 4075 user is authorized serv. 4076 specific answer 4078 Idle Service-specific authorization Send Idle 4079 request received, and failed serv. 4080 user is not authorized specific answer 4082 Open Service-specific authorization Send Open 4083 request received, and user successful 4084 is authorized serv. specific 4085 answer 4087 Open Service-specific authorization Send Idle 4088 request received, and user failed serv. 4089 is not authorized specific 4090 answer, 4091 Cleanup 4093 Open Home server wants to Send ASR Discon 4094 terminate the service 4096 Open Authorization-Lifetime (and Cleanup Idle 4097 Auth-Grace-Period) expires 4098 on home server. 4100 Open Session-Timeout expires on Cleanup Idle 4101 home server 4103 Discon Failure to send ASR Wait, Discon 4104 resend ASR 4106 Discon ASR successfully sent and Cleanup Idle 4107 ASA Received with Result-Code 4109 Not ASA Received None No Change. 4110 Discon 4112 Any STR Received Send STA, Idle 4113 Cleanup. 4114 fi 4116 The following state machine is observed by a client when state is not 4117 maintained on the server: 4119 CLIENT, STATELESS 4120 State Event Action New State 4121 ------------------------------------------------------------- 4122 Idle Client or Device Requests Send Pending 4123 access service 4124 specific 4125 auth req 4127 Pending Successful Service-specific Grant Open 4128 authorization answer Access 4129 received with Auth-Session- 4130 State set to 4131 NO_STATE_MAINTAINED 4133 Pending Failed Service-specific Cleanup Idle 4134 authorization answer 4135 received 4137 Open Session-Timeout Expires on Discon. Idle 4138 Access Device user/device 4140 Open Service to user is terminated Discon. Idle 4141 user/device 4143 The following state machine is observed by a server when it is not 4144 maintaining state for the session: 4146 SERVER, STATELESS 4147 State Event Action New State 4148 ------------------------------------------------------------- 4149 Idle Service-specific authorization Send serv. Idle 4150 request received, and specific 4151 successfully processed answer 4153 8.2 Accounting Session State Machine 4155 The following state machines MUST be supported for applications that 4156 have an accounting portion or that require only accounting services. 4157 The first state machine is to be observed by clients. 4159 The server side in the accounting state machine depends in some cases 4160 on the particular application. The Diameter base protocol defines a 4161 default state machine that MUST be followed by accounting servers 4162 advertising support for the Relay application identifier and all 4163 applications that have not specified other state machines. This is 4164 the second state machine in this section described below. 4166 The default server side state machine requires the reception of 4167 accounting records in any order and at any time, and does not place 4168 any standards requirement on the processing of these records. 4169 Implementations of Diameter MAY perform checking, ordering, 4170 correlation, fraud detection, and other tasks based on these records. 4171 Both base Diameter AVPs as well as application specific AVPs MAY be 4172 inspected as a part of these tasks. The tasks can happen either 4173 immediately after record reception or in a post-processing phase. 4174 However, as these tasks are typically application or even policy 4175 dependent, they are not standardized by the Diameter specifications. 4176 Applications MAY define requirements on when to accept accounting 4177 records based on the used value of Accounting-Realtime-Required AVP, 4178 credit limits checks, and so on. 4180 However, the Diameter base protocol defines one optional server side 4181 state machine that MAY be followed by applications that require 4182 keeping track of the session state at the accounting server. Note 4183 that such tracking is incompatible with the ability to sustain long 4184 duration connectivity problems. Theferore, the use of this state 4185 machine is recommended only in applications where the value of the 4186 Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence 4187 accounting connectivity problems are required to cause the serviced 4188 user to be disconnected. Otherwise, records produced by the client 4189 may be lost by the server which no longer accepts them after the 4190 connectivity is re-established. This state machine is the third state 4191 machine in this section. The state machine is supervised by a 4192 supervision session timer Ts, which the value should be reasonably 4193 higher than the Interim_Record_Interval value. Ts MAY be set to two 4194 times the value of the Interim_Record_Interval so as to avoid the 4195 accounting session in the Diameter server to change to Idle state in 4196 case of short transient network failure. 4198 Any event not listed in the state machines MUST be considered as an 4199 error condition, and a corresponding answer, if applicable, MUST be 4200 returned to the originator of the message. 4202 In the state table, the event 'Failure to send' means that the 4203 Diameter client is unable to communicate with the desired 4204 destination. This could be due to the peer being down, or due to the 4205 peer sending back a transient failure or temporary protocol error 4206 notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or 4207 DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting 4208 Answer command. 4210 The event 'Failed answer' means that the Diameter client received a 4211 non-transient failure notification in the Accounting Answer command. 4213 Note that the action 'Disconnect user/dev' MUST have an effect also 4214 to the authorization session state table, e.g. cause the STR message 4215 to be sent, if the given application has both 4216 authentication/authorization and accounting portions. 4218 The states PendingS, PendingI, PendingL, PendingE and PendingB stand 4219 for pending states to wait for an answer to an accounting request 4220 related to a Start, Interim, Stop, Event or buffered record, 4221 respectively. 4223 Note that the server side state machine requires the reception of 4224 accounting records and does not place any standard requirements on 4225 the processing of these records. Implementations of Diameter MAY 4226 perform checking, ordering, correlation, fraud detection and other 4227 tasks based on these records. Both base Diameter AVPs as well as 4228 application specific AVPs MAY be inspected as a part of these tasks. 4229 The tasks can happen either immediately after record reception or in 4230 a post-processing phase. However, as these tasks are typically 4231 application or even policy dependent, they are not standardized by 4232 the Diameter specifications. 4234 CLIENT, ACCOUNTING 4235 State Event Action New State 4236 ------------------------------------------------------------- 4237 Idle Client or device requests Send PendingS 4238 access accounting 4239 start req. 4241 Idle Client or device requests Send PendingE 4242 a one-time service accounting 4243 event req 4245 Idle Records in storage Send PendingB 4246 record 4248 PendingS Successful accounting Open 4249 start answer received 4251 PendingS Failure to send and buffer Store Open 4252 space available and realtime Start 4253 not equal to DELIVER_AND_GRANT Record 4255 PendingS Failure to send and no buffer Open 4256 space available and realtime 4257 equal to GRANT_AND_LOSE 4259 PendingS Failure to send and no buffer Disconnect Idle 4260 space available and realtime user/dev 4261 not equal to 4262 GRANT_AND_LOSE 4264 PendingS Failed accounting start answer Open 4265 received and realtime equal 4266 to GRANT_AND_LOSE 4268 PendingS Failed accounting start answer Disconnect Idle 4269 received and realtime not user/dev 4270 equal to GRANT_AND_LOSE 4272 PendingS User service terminated Store PendingS 4273 stop 4274 record 4276 Open Interim interval elapses Send PendingI 4277 accounting 4278 interim 4279 record 4281 Open User service terminated Send PendingL 4282 accounting 4283 stop req. 4285 PendingI Successful accounting interim Open 4286 answer received 4288 PendingI Failure to send and (buffer Store Open 4289 space available or old record interim 4290 can be overwritten) and record 4291 realtime not equal to 4292 DELIVER_AND_GRANT 4294 PendingI Failure to send and no buffer Open 4295 space available and realtime 4296 equal to GRANT_AND_LOSE 4298 PendingI Failure to send and no buffer Disconnect Idle 4299 space available and realtime user/dev 4300 not equal to GRANT_AND_LOSE 4302 PendingI Failed accounting interim Open 4303 answer received and realtime 4304 equal to GRANT_AND_LOSE 4306 PendingI Failed accounting interim Disconnect Idle 4307 answer received and realtime user/dev 4308 not equal to GRANT_AND_LOSE 4310 PendingI User service terminated Store PendingI 4311 stop 4312 record 4314 PendingE Successful accounting Idle 4315 event answer received 4317 PendingE Failure to send and buffer Store Idle 4318 space available event 4319 record 4321 PendingE Failure to send and no buffer Idle 4322 space available 4324 PendingE Failed accounting event answer Idle 4325 received 4327 PendingB Successful accounting answer Delete Idle 4328 received record 4330 PendingB Failure to send Idle 4332 PendingB Failed accounting answer Delete Idle 4333 received record 4335 PendingL Successful accounting Idle 4336 stop answer received 4338 PendingL Failure to send and buffer Store Idle 4339 space available stop 4340 record 4342 PendingL Failure to send and no buffer Idle 4343 space available 4345 PendingL Failed accounting stop answer Idle 4346 received 4347 SERVER, STATELESS ACCOUNTING 4348 State Event Action New State 4349 ------------------------------------------------------------- 4351 Idle Accounting start request Send Idle 4352 received, and successfully accounting 4353 processed. start 4354 answer 4356 Idle Accounting event request Send Idle 4357 received, and successfully accounting 4358 processed. event 4359 answer 4361 Idle Interim record received, Send Idle 4362 and successfully processed. accounting 4363 interim 4364 answer 4366 Idle Accounting stop request Send Idle 4367 received, and successfully accounting 4368 processed stop answer 4370 Idle Accounting request received, Send Idle 4371 no space left to store accounting 4372 records answer, 4373 Result-Code 4374 = OUT_OF_ 4375 SPACE 4377 SERVER, STATEFUL ACCOUNTING 4378 State Event Action New State 4379 ------------------------------------------------------------- 4381 Idle Accounting start request Send Open 4382 received, and successfully accounting 4383 processed. start 4384 answer, 4385 Start Ts 4387 Idle Accounting event request Send Idle 4388 received, and successfully accounting 4389 processed. event 4390 answer 4392 Idle Accounting request received, Send Idle 4393 no space left to store accounting 4394 records answer, 4395 Result-Code 4396 = OUT_OF_ 4397 SPACE 4399 Open Interim record received, Send Open 4400 and successfully processed. accounting 4401 interim 4402 answer, 4403 Restart Ts 4405 Open Accounting stop request Send Idle 4406 received, and successfully accounting 4407 processed stop answer, 4408 Stop Ts 4410 Open Accounting request received, Send Idle 4411 no space left to store accounting 4412 records answer, 4413 Result-Code 4414 = OUT_OF_ 4415 SPACE, 4416 Stop Ts 4418 Open Session supervision timer Ts Stop Ts Idle 4419 expired 4421 8.3 Server-Initiated Re-Auth 4423 A Diameter server may initiate a re-authentication and/or re- 4424 authorization service for a particular session by issuing a Re-Auth- 4425 Request (RAR). 4427 For example, for pre-paid services, the Diameter server that 4428 originally authorized a session may need some confirmation that the 4429 user is still using the services. 4431 An access device that receives a RAR message with Session-Id equal to 4432 a currently active session MUST initiate a re-auth towards the user, 4433 if the service supports this particular feature. Each Diameter 4434 application MUST state whether service-initiated re-auth is 4435 supported, since some applications do not allow access devices to 4436 prompt the user for re-auth. 4438 8.3.1 Re-Auth-Request 4440 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 4441 and the message flags' 'R' bit set, may be sent by any server to the 4442 access device that is providing session service, to request that the 4443 user be re-authenticated and/or re-authorized. 4445 Message Format 4447 ::= < Diameter Header: 258, REQ, PXY > 4448 < Session-Id > 4449 { Origin-Host } 4450 { Origin-Realm } 4451 { Destination-Realm } 4452 { Destination-Host } 4453 { Auth-Application-Id } 4454 { Re-Auth-Request-Type } 4455 [ User-Name ] 4456 [ Origin-State-Id ] 4457 * [ Proxy-Info ] 4458 * [ Route-Record ] 4459 * [ AVP ] 4461 8.3.2 Re-Auth-Answer 4463 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 4464 and the message flags' 'R' bit clear, is sent in response to the RAR. 4465 The Result-Code AVP MUST be present, and indicates the disposition of 4466 the request. 4468 A successful RAA message MUST be followed by an application-specific 4469 authentication and/or authorization message. 4471 Message Format 4473 ::= < Diameter Header: 258, PXY > 4474 < Session-Id > 4475 { Result-Code } 4476 { Origin-Host } 4477 { Origin-Realm } 4478 [ User-Name ] 4479 [ Origin-State-Id ] 4480 [ Error-Message ] 4481 [ Error-Reporting-Host ] 4482 * [ Failed-AVP ] 4483 * [ Redirected-Host ] 4484 [ Redirected-Host-Usage ] 4485 [ Redirected-Host-Cache-Time ] 4486 * [ Proxy-Info ] 4487 * [ AVP ] 4489 8.4 Session Termination 4491 It is necessary for a Diameter server that authorized a session, for 4492 which it is maintaining state, to be notified when that session is no 4493 longer active, both for tracking purposes as well as to allow 4494 stateful agents to release any resources that they may have provided 4495 for the user's session. For sessions whose state is not being 4496 maintained, this section is not used. 4498 When a user session that required Diameter authorization terminates, 4499 the access device that provided the service MUST issue a Session- 4500 Termination-Request (STR) message to the Diameter server that 4501 authorized the service, to notify it that the session is no longer 4502 active. An STR MUST be issued when a user session terminates for any 4503 reason, including user logoff, expiration of Session-Timeout, 4504 administrative action, termination upon receipt of an Abort-Session- 4505 Request (see below), orderly shutdown of the access device, etc. 4507 The access device also MUST issue an STR for a session that was 4508 authorized but never actually started. This could occur, for example, 4509 due to a sudden resource shortage in the access device, or because 4510 the access device is unwilling to provide the type of service 4511 requested in the authorization, or because the access device does not 4512 support a mandatory AVP returned in the authorization, etc. 4514 It is also possible that a session that was authorized is never 4515 actually started due to action of a proxy. For example, a proxy may 4516 modify an authorization answer, converting the result from success to 4517 failure, prior to forwarding the message to the access device. If the 4518 answer did not contain an Auth-Session-State AVP with the value 4519 NO_STATE_MAINTAINED, a proxy that causes an authorized session not to 4520 be started MUST issue an STR to the Diameter server that authorized 4521 the session, since the access device has no way of knowing that the 4522 session had been authorized. 4524 A Diameter server that receives an STR message MUST clean up 4525 resources (e.g., session state) associated with the Session-Id 4526 specified in the STR, and return a Session-Termination-Answer. 4528 A Diameter server also MUST clean up resources when the Session- 4529 Timeout expires, or when the Authorization-Lifetime and the Auth- 4530 Grace-Period AVPs expires without receipt of a re-authorization 4531 request, regardless of whether an STR for that session is received. 4532 The access device is not expected to provide service beyond the 4533 expiration of these timers; thus, expiration of either of these 4534 timers implies that the access device may have unexpectedly shut 4535 down. 4537 8.4.1 Session-Termination-Request 4539 The Session-Termination-Request (STR), indicated by the Command-Code 4540 set to 275 and the Command Flags' 'R' bit set, is sent by the access 4541 device to inform the Diameter Server that an authenticated and/or 4542 authorized session is being terminated. 4544 Message Format 4546 ::= < Diameter Header: 275, REQ, PXY > 4547 < Session-Id > 4548 { Origin-Host } 4549 { Origin-Realm } 4550 { Destination-Realm } 4551 { Auth-Application-Id } 4552 { Termination-Cause } 4553 [ User-Name ] 4554 [ Destination-Host ] 4555 * [ Class ] 4556 [ Origin-State-Id ] 4557 * [ Proxy-Info ] 4558 * [ Route-Record ] 4559 * [ AVP ] 4561 8.4.2 Session-Termination-Answer 4563 The Session-Termination-Answer (STA), indicated by the Command-Code 4564 set to 275 and the message flags' 'R' bit clear, is sent by the 4565 Diameter Server to acknowledge the notification that the session has 4566 been terminated. The Result-Code AVP MUST be present, and MAY contain 4567 an indication that an error occurred while servicing the STR. 4569 Upon sending or receipt of the STA, the Diameter Server MUST release 4570 all resources for the session indicated by the Session-Id AVP. Any 4571 intermediate server in the Proxy-Chain MAY also release any 4572 resources, if necessary. 4574 Message Format 4576 ::= < Diameter Header: 275, PXY > 4577 < Session-Id > 4578 { Result-Code } 4579 { Origin-Host } 4580 { Origin-Realm } 4581 [ User-Name ] 4582 * [ Class ] 4583 [ Error-Message ] 4584 [ Error-Reporting-Host ] 4585 * [ Failed-AVP ] 4586 [ Origin-State-Id ] 4587 * [ Redirect-Host ] 4588 [ Redirect-Host-Usase ] 4589 [ Redirect-Max-Cache-Time ] 4590 * [ Proxy-Info ] 4591 * [ AVP ] 4593 8.5 Aborting a Session 4595 A Diameter server may request that the access device stop providing 4596 service for a particular session by issuing an Abort-Session-Request 4597 (ASR). 4599 For example, the Diameter server that originally authorized the 4600 session may be required to cause that session to be stopped for 4601 credit or other reasons that were not anticipated when the session 4602 was first authorized. On the other hand, an operator may maintain a 4603 management server for the purpose of issuing ASRs to administratively 4604 remove users from the network. 4606 An access device that receives an ASR with Session-ID equal to a 4607 currently active session MAY stop the session. Whether the access 4608 device stops the session or not is implementation- and/or 4609 configuration-dependent. For example, an access device may honor ASRs 4610 from certain agents only. In any case, the access device MUST respond 4611 with an Abort-Session-Answer, including a Result-Code AVP to indicate 4612 what action it took. 4614 Note that if the access device does stop the session upon receipt of 4615 an ASR, it issues an STR to the authorizing server (which may or may 4616 not be the agent issuing the ASR) just as it would if the session 4617 were terminated for any other reason. 4619 8.5.1 Abort-Session-Request 4621 The Abort-Session-Request (ASR), indicated by the Command-Code set to 4622 274 and the message flags' 'R' bit set, may be sent by any server to 4623 the access device that is providing session service, to request that 4624 the session identified by the Session-Id be stopped. 4626 Message Format 4628 ::= < Diameter Header: 274, REQ, PXY > 4629 < Session-Id > 4630 { Origin-Host } 4631 { Origin-Realm } 4632 { Destination-Realm } 4633 { Destination-Host } 4634 { Auth-Application-Id } 4635 [ User-Name ] 4636 [ Origin-State-Id ] 4637 * [ Proxy-Info ] 4638 * [ Route-Record ] 4639 * [ AVP ] 4641 8.5.2 Abort-Session-Answer 4643 The Abort-Session-Answer (ASA), indicated by the Command-Code set to 4644 274 and the message flags' 'R' bit clear, is sent in response to the 4645 ASR. The Result-Code AVP MUST be present, and indicates the 4646 disposition of the request. 4648 If the session identified by Session-Id in the ASR was successfully 4649 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is 4650 not currently active, Result-Code is set to 4651 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the 4652 session for any other reason, Result-Code is set to 4653 DIAMETER_UNABLE_TO_COMPLY. 4655 Message Format 4656 ::= < Diameter Header: 274, PXY > 4657 < Session-Id > 4658 { Result-Code } 4659 { Origin-Host } 4660 { Origin-Realm } 4661 [ User-Name ] 4662 [ Origin-State-Id ] 4663 [ Error-Message ] 4664 [ Error-Reporting-Host ] 4665 * [ Failed-AVP ] 4666 * [ Redirected-Host ] 4667 [ Redirected-Host-Usage ] 4668 [ Redirected-Max-Cache-Time ] 4669 * [ Proxy-Info ] 4670 * [ AVP ] 4672 8.6 Inferring Session Termination from Origin-State-Id 4674 Origin-State-Id is used to allow rapid detection of terminated 4675 sessions for which no STR would have been issued, due to 4676 unanticipated shutdown of an access device. 4678 By including Origin-State-Id in CER/CAA messages, an access device 4679 allows a next-hop server to determine immediately upon connection 4680 whether the device has lost its sessions since the last connection. 4682 By including Origin-State-Id in request messages, an access device 4683 also allows a server with which it communicates via proxy to make 4684 such a determination. However, a server that is not directly 4685 connected with the access device will not discover that the access 4686 device has been restarted unless and until it receives a new request 4687 from the access device. Thus, use of this mechanism across proxies is 4688 opportunistic rather than reliable, but useful nonetheless. 4690 When a Diameter server receives an Origin-State-Id that is greater 4691 than the Origin-State-Id previously received from the same issuer, it 4692 may assume that the issuer has lost state since the previous message 4693 and that all sessions that were active under the lower Origin-State- 4694 Id have been terminated. The Diameter server MAY clean up all session 4695 state associated with such lost sessions, and MAY also issues STRs 4696 for all such lost sessions that were authorized on upstream servers, 4697 to allow session state to be cleaned up globally. 4699 8.7 Auth-Request-Type AVP 4701 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is 4702 included in application-specific auth requests to inform the peers 4703 whether a user is to be authenticated only, authorized only or both. 4704 Note any value other than both MAY cause RADIUS interoperability 4705 issues. The following values are defined: 4707 AUTHENTICATE_ONLY 1 4708 The request being sent is for authentication only, and MUST 4709 contain the relevant application specific authentication AVPs 4710 that are needed by the Diameter server to authenticate the 4711 user. 4713 AUTHORIZE_ONLY 2 4714 The request being sent is for authorization only, and MUST 4715 contain the application specific authorization AVPs that are 4716 necessary to identify the service being requested/offered. 4718 AUTHORIZE_AUTHENTICATE 3 4719 The request contains a request for both authentication and 4720 authorization. The request MUST include both the relevant 4721 application specific authentication information, and 4722 authorization information necessary to identify the service 4723 being requested/offered. 4725 8.8 Session-Id AVP 4727 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used 4728 to identify a specific session (see section 8). All messages 4729 pertaining to a specific session MUST include only one Session-Id AVP 4730 and the same value MUST be used throughout the life of a session. 4731 When present, the Session-Id SHOULD appear immediately following the 4732 Diameter Header (see section 3). 4734 The Session-Id MUST be globally and eternally unique, as it is meant 4735 to uniquely identify a user session without reference to any other 4736 information, and may be needed to correlate historical authentication 4737 information with accounting information. The Session-Id includes a 4738 mandatory portion and an implementation-defined portion; a 4739 recommended format for the implementation-defined portion is outlined 4740 below. 4742 The Session-Id MUST begin with the sender's identity encoded in the 4743 DiameterIdentity type (see section 4.4). The remainder of the 4744 Session-Id MAY be any sequence that the client can guarantee to be 4745 eternally unique; however, the following format is recommended, 4746 (square brackets [] indicate an optional element): 4748 ;;[;] 4749 and are decimal representations of the 4750 high and low 32 bits of a monotonically increasing 64-bit value. The 4751 64-bit value is rendered in two part to simplify formatting by 32-bit 4752 processors. At startup, the high 32 bits of the 64-bit value MAY be 4753 initialized to the time, and the low 32 bits MAY be initialized to 4754 zero. This will for practical purposes eliminate the possibility of 4755 overlapping Session-Ids after a reboot, assuming the reboot process 4756 takes longer than a second. Alternatively, an implementation MAY keep 4757 track of the increasing value in non-volatile memory. 4759 is implementation specific but may include a modem's 4760 device Id, a layer 2 address, timestamp, etc. 4762 Example, in which there is no optional value: 4763 accesspoint7.acme.com;1876543210;523 4765 Example, in which there is an optional value: 4766 accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 4768 The Session-Id is created by the Diameter device initiating the 4769 session, which in most cases is done by the client. Note that a 4770 Session-Id MAY be used for both the authorization and accounting 4771 commands of a given application. 4773 8.9 Authorization-Lifetime AVP 4775 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 4776 and contains the maximum number of seconds of service to be provided 4777 to the user before the user is to be re-authenticated and/or re- 4778 authorized. Great care should be taken when the Authorization- 4779 Lifetime value is determined, since a low, non-zero, value could 4780 create significant Diameter traffic, which could congest both the 4781 network and the agents. 4783 A value of zero (0) means that immediate re-auth is necessary by the 4784 access device. This is typically used in cases where multiple 4785 authentication methods are used, and a successful auth response with 4786 this AVP set to zero is used to signal that the next authentication 4787 method is to be immediately initiated. The absence of this AVP, or a 4788 value of all ones (meaning all bits in the 32 bit field are set to 4789 one) means no re-auth is expected. 4791 If both this AVP and the Session-Timeout AVP are present in a 4792 message, the value of the latter MUST NOT be smaller than the 4793 Authorization-Lifetime AVP. 4795 An Authorization-Lifetime AVP MAY be present in re-authorization 4796 messages, and contains the number of seconds the user is authorized 4797 to receive service from the time the re-auth answer message is 4798 received by the access device. 4800 This AVP MAY be provided by the client as a hint of the maximum 4801 lifetime that it is willing to accept. However, the server MAY return 4802 a value that is equal to, or smaller, than the one provided by the 4803 client. 4805 8.10 Auth-Grace-Period AVP 4807 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and 4808 contains the number of seconds the Diameter server will wait 4809 following the expiration of the Authorization-Lifetime AVP before 4810 cleaning up resources for the session. 4812 8.11 Auth-Session-State AVP 4814 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and 4815 specifies whether state is maintained for a particular session. The 4816 client MAY include this AVP in requests as a hint to the server, but 4817 the value in the server's answer message is binding. The following 4818 values are supported: 4820 STATE_MAINTAINED 0 4821 This value is used to specify that session state is being 4822 maintained, and the access device MUST issue a session 4823 termination message when service to the user is terminated. 4824 This is the default value. 4826 NO_STATE_MAINTAINED 1 4827 This value is used to specify that no session termination 4828 messages will be sent by the access device upon expiration of 4829 the Authorization-Lifetime. 4831 8.12 Re-Auth-Request-Type AVP 4833 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and 4834 is included in application-specific auth answers to inform the client 4835 of the action expected upon expiration of the Authorization-Lifetime. 4836 If the answer message contains an Authorization-Lifetime AVP with a 4837 positive value, the Re-Auth-Request-Type AVP MUST be present in an 4838 answer message. The following values are defined: 4840 AUTHORIZE_ONLY 0 4841 An authorization only re-auth is expected upon expiration of 4842 the Authorization-Lifetime. This is the default value if the 4843 AVP is not present in answer messages that include the 4844 Authorization-Lifetime. 4846 AUTHORIZE_AUTHENTICATE 1 4847 An authentication and authorization re-auth is expected upon 4848 expiration of the Authorization-Lifetime. 4850 8.13 Session-Timeout AVP 4852 The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 4853 and contains the maximum number of seconds of service to be provided 4854 to the user before termination of the session. When both the 4855 Session-Timeout and the Authorization-Lifetime AVPs are present in an 4856 answer message, the former MUST be equal to or greater than the value 4857 of the latter. 4859 A session that terminates on an access device due to the expiration 4860 of the Session-Timeout MUST cause an STR to be issued, unless both 4861 the access device and the home server had previously agreed that no 4862 session termination messages would be sent (see section 8.9). 4864 A Session-Timeout AVP MAY be present in a re-authorization answer 4865 message, and contains the remaining number of seconds from the 4866 beginning of the re-auth. 4868 A value of zero, or the absence of this AVP, means that this session 4869 has an unlimited number of seconds before termination. 4871 This AVP MAY be provided by the client as a hint of the maximum 4872 timeout that it is willing to accept. However, the server MAY return 4873 a value that is equal to, or smaller, than the one provided by the 4874 client. 4876 8.14 User-Name AVP 4878 The User-Name AVP (AVP Code 1) [RADIUS] is of type UTF8String, which 4879 contains the User-Name, in a format consistent with the NAI 4880 specification [NAI]. 4882 8.15 Termination-Cause AVP 4884 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and 4885 is used to indicate the reason why a session was terminated on the 4886 access device. The following values are defined: 4888 DIAMETER_LOGOUT 1 4889 The user initiated a disconnect 4891 DIAMETER_SERVICE_NOT_PROVIDED 2 4892 This value is used when the user disconnected prior to the 4893 receipt of the authorization answer message. 4895 DIAMETER_BAD_ANSWER 3 4896 This value indicates that the authorization answer received by 4897 the access device was not processed successfully. 4899 DIAMETER_ADMINISTRATIVE 4 4900 The user was not granted access, or was disconnected, due to 4901 administrative reasons, such as the receipt of a Abort- 4902 Session-Request message. 4904 DIAMETER_LINK_BROKEN 5 4905 The communication to the user was abruptly disconnected. 4907 DIAMETER_AUTH_EXPIRED 6 4908 The user's access was terminated since its authorized session 4909 time has expired. 4911 DIAMETER_USER_MOVED 7 4912 The user is receiving services from another access device. 4914 DIAMETER_SESSION_TIMEOUT 8 4915 The user's session has timed out, and service has been 4916 terminated. 4918 8.16 Origin-State-Id AVP 4920 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a 4921 monotonically increasing value that is advanced whenever a Diameter 4922 entity restarts with loss of previous state, for example upon reboot. 4923 Origin-State-Id MAY be included in any Diameter message, including 4924 CER. 4926 A Diameter entity issuing this AVP MUST create a higher value for 4927 this AVP each time its state is reset. A Diameter entity MAY set 4928 Origin-State-Id to the time of startup, or it MAY use an incrementing 4929 counter retained in non-volatile memory across restarts. 4931 The Origin-State-Id, if present, MUST reflect the state of the entity 4932 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST 4933 either remove Origin-State-Id or modify it appropriately as well. 4935 Typically, Origin-State-Id is used by an access device that always 4936 starts up with no active sessions; that is, any session active prior 4937 to restart will have been lost. By including Origin-State-Id in a 4938 message, it allows other Diameter entities to infer that sessions 4939 associated with a lower Origin-State-Id are no longer active. If an 4940 access device does not intend for such inferences to be made, it MUST 4941 either not include Origin-State-Id in any message, or set its value 4942 to 0. 4944 8.17 Session-Binding AVP 4946 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY 4947 be present in application-specific authorization answer messages. If 4948 present, this AVP MAY inform the Diameter client that all future 4949 application-specific re-auth messages for this session MUST be sent 4950 to the same authorization server. This AVP MAY also specify that a 4951 Session-Termination-Request message for this session MUST be sent to 4952 the same authorizing server. 4954 This field is a bit mask, and the following bits have been defined: 4956 RE_AUTH 1 4957 When set, future re-auth messages for this session MUST NOT 4958 include the Destination-Host AVP. When cleared, the default 4959 value, the Destination-Host AVP MUST be present in all re-auth 4960 messages for this session. 4962 STR 2 4963 When set, the STR message for this session MUST NOT include the 4964 Destination-Host AVP. When cleared, the default value, the 4965 Destination-Host AVP MUST be present in the STR message for 4966 this session. 4968 ACCOUNTING 4 4969 When set, all accounting messages for this session MUST NOT 4970 include the Destination-Host AVP. When cleared, the default 4971 value, the Destination-Host AVP, if known, MUST be present in 4972 all accounting messages for this session. 4974 8.18 Session-Server-Failover AVP 4976 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated, 4977 and MAY be present in application-specific authorization answer 4978 messages that either do not include the Session-Binding AVP or 4979 include the Session-Binding AVP with any of the bits set to a zero 4980 value. If present, this AVP MAY inform the Diameter client that if a 4981 re-auth or STR message fails due to a delivery problem, the Diameter 4982 client SHOULD issue a subsequent message without the Destination-Host 4983 AVP. When absent, the default value is REFUSE_SERVICE. 4985 The following values are supported: 4987 REFUSE_SERVICE 0 4988 If either the re-auth or the STR message delivery fails, 4989 terminate service with the user, and do not attempt any 4990 subsequent attempts. 4992 TRY_AGAIN 1 4993 If either the re-auth or the STR message delivery fails, resend 4994 the failed message without the Destination-Host AVP present. 4996 ALLOW_SERVICE 2 4997 If re-auth message delivery fails, assume that re-authorization 4998 succeeded. If STR message delivery fails, terminate the 4999 session. 5001 TRY_AGAIN_ALLOW_SERVICE 3 5002 If either the re-auth or the STR message delivery fails, resend 5003 the failed message without the Destination-Host AVP present. 5004 If the second delivery fails for re-auth, assume re- 5005 authorization succeeded. If the second delivery fails for STR, 5006 terminate the session. 5008 8.19 Multi-Round-Time-Out AVP 5010 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32, 5011 and SHOULD be present in application-specific authorization answer 5012 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. 5013 This AVP contains the maximum number of seconds that the access 5014 device MUST provide the user in responding to an authentication 5015 request. 5017 8.20 Class AVP 5019 The Class AVP (AVP Code 25) is of type OctetString and is used to by 5020 Diameter servers to return state information to the access device. 5021 When one or more Class AVPs are present in application-specific 5022 authorization answer messages, they MUST be present in subsequent 5023 re-authorization, session termination and accounting messages. Class 5024 AVPs found in a re-authorization answer message override the ones 5025 found in any previous authorization answer message. Diameter server 5026 implementations SHOULD NOT return Class AVPs that require more than 5027 4096 bytes of storage on the Diameter client. A Diameter client that 5028 receives Class AVPs whose size exceeds local available storage MUST 5029 terminate the session. 5031 8.21 Event-Timestamp AVP 5033 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 5034 included in an Accounting-Request and Accounting-Answer messages to 5035 record the time that the reported event occurred, in seconds since 5036 January 1, 1970 00:00 UTC. 5038 9 Accounting 5040 This accounting protocol is based on a server directed model with 5041 capabilities for real-time delivery of accounting information. 5042 Several fault resilience methods [ACCMGMT] have been built in to the 5043 protocol in order minimize loss of accounting data in various fault 5044 situations and under different assumptions about the capabilities of 5045 the used devices. 5047 9.1 Server Directed Model 5049 The server directed model means that the device generating the 5050 accounting data gets information from either the authorization server 5051 (if contacted) or the accounting server regarding the way accounting 5052 data shall be forwarded. This information includes accounting record 5053 timeliness requirements. 5055 As discussed in [ACCMGMT], real-time transfer of accounting records 5056 is a requirement, such as the need to perform credit limit checks and 5057 fraud detection. Note that batch accounting is not a requirement, and 5058 is therefore not supported by Diameter. Should batched accounting be 5059 required in the future, a new Diameter application will need to be 5060 created, or it could be handled using another protocol. Note, 5061 however, that even if at the Diameter layer accounting requests are 5062 processed one by one, transport protocols used under Diameter 5063 typically batch several requests in the same packet under heavy 5064 traffic conditions. This may be sufficient for many applications. 5066 The authorization server (chain) directs the selection of proper 5067 transfer strategy, based on its knowledge of the user and 5068 relationships of roaming partnerships. The server (or agents) uses 5069 the Acct-interim-Interval and Accounting-Realtime-Required AVPs to 5070 control the operation of the Diameter peer operating as a client. The 5071 Acct-interim-Interval AVP, when present, instructs the Diameter node 5072 acting as a client to produce accounting records continuously even 5073 during a session. Accounting-Realtime-Required AVP is used to control 5074 the behavior of the client when the transfer of accounting records 5075 from the Diameter client is delayed or unsuccessful. 5077 The Diameter accounting server MAY override the interim interval or 5078 the realtime requirements by including the Acct-interim-Interval or 5079 Accounting-Realtime-Required AVP in the Accounting-Answer message. 5080 When one of these AVPs is present, the latest value received SHOULD 5081 be used in further accounting activities for the same session. 5083 9.2 Protocol Messages 5085 A Diameter node that receives a successful authentication and/or 5086 authorization messages from the Home AAA server MUST collect 5087 accounting information for the session. The Accounting-Request 5088 message is used to transmit the accounting information to the Home 5089 AAA server, which MUST reply with the Accounting-Answer message to 5090 confirm reception. The Accounting-Answer message includes the 5091 Result-Code AVP, which MAY indicate that an error was present in the 5092 accounting message. A rejected Accounting-Request message MAY cause 5093 the user's session to be terminated, depending on the value of the 5094 Accounting-Realtime-Required AVP received earlier for the session in 5095 question. 5097 Each Diameter Accounting protocol message MAY be compressed using 5098 IPComp [IPComp] in order to reduce the used network bandwidth, which 5099 MAY use IKE [IKE] to negotiate the compression parameters. 5101 9.3 Application document requirements 5103 Each Diameter application (e.g. NASREQ, MobileIP), MUST define their 5104 Service-Specific AVPs that MUST be present in the Accounting-Request 5105 message in a section entitled "Accounting AVPs". The application MUST 5106 assume that the AVPs described in this document will be present in 5107 all Accounting messages, so only their respective service-specific 5108 AVPs need to be defined in this section. 5110 9.4 Fault Resilience 5112 Diameter Base protocol mechanisms are used to overcome small message 5113 loss and network faults of temporary nature. 5115 Diameter peers acting as clients MUST implement the use of failover 5116 to guard against server failures and certain network failures. 5117 Diameter peers acting as agents or related off-line processing 5118 systems MUST detect duplicate accounting records caused by the 5119 sending of same record to several servers and duplication of messages 5120 in transit. This detection MUST be based on the inspection of the 5121 Session-Id and Accounting-Record-Number AVP pairs. Appendix C 5122 discusses duplicate detection needs and implementation issues. 5124 Diameter clients MAY have non-volatile memory for the safe storage of 5125 accounting records over reboots or extended network failures, network 5126 partitions, and server failures. If such memory is available, the 5127 client SHOULD store new accounting records there as soon as the 5128 records are created and until a positive acknowledgement of their 5129 reception from the Diameter Server has been received. Upon a reboot, 5130 the client MUST starting sending the records in the non-volatile 5131 memory to the accounting server with appropriate modifications in 5132 termination cause, session length, and other relevant information in 5133 the records. 5135 A further application of this protocol may include AVPs to control 5136 how many accounting records may at most be stored in the Diameter 5137 client without committing them to the non-volatile memory or 5138 transferring them to the Diameter server. 5140 The client SHOULD NOT remove the accounting data from any of its 5141 memory areas before the correct Accounting-Answer has been received. 5142 The client MAY remove oldest, undelivered or yet unacknowledged 5143 accounting data if it runs out of resources such as memory. It is an 5144 implementation dependent matter for the client to accept new sessions 5145 under this condition. 5147 9.5 Accounting Records 5149 In all accounting records, the Session-Id AVP MUST be present; the 5150 User-Name AVP MUST be present if it is available to the Diameter 5151 client. If strong authentication across agents is required, end-to- 5152 end security may be used for authentication purposes. 5154 Different types of accounting records are sent depending on the 5155 actual type of accounted service and the authorization server's 5156 directions for interim accounting. If the accounted service is a 5157 one-time event, meaning that the start and stop of the event are 5158 simultaneous, then the Accounting-Record-Type AVP MUST be present and 5159 set to the value EVENT_RECORD. 5161 If the accounted service is of a measurable length, then the AVP MUST 5162 use the values START_RECORD, STOP_RECORD, and possibly, 5163 INTERIM_RECORD. If the authorization server has not directed interim 5164 accounting to be enabled for the session, two accounting records MUST 5165 be generated for each service of type session. When the initial 5166 Accounting-Request for a given session is sent, the Accounting- 5167 Record-Type AVP MUST be set to the value START_RECORD. When the last 5168 Accounting-Request is sent, the value MUST be STOP_RECORD. 5170 If the authorization server has directed interim accounting to be 5171 enabled, the Diameter client MUST produce additional records between 5172 the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The 5173 production of these records is directed by Acct-interim-Interval as 5174 well as any re-authentication or re-authorization of the session. 5175 The Diameter client MUST overwrite any previous interim accounting 5176 records that are locally stored for delivery, if a new record is 5177 being generated for the same session. This ensures that only one 5178 pending interim record can exist on an access device for any given 5179 session. 5181 A particular value of Accounting-Sub-Session-Id MUST appear only in 5182 one sequence of accounting records from a DIAMETER client, except for 5183 the purposes of retransmission. The one sequence that is sent MUST 5184 be either one record with Accounting-Record-Type AVP set to the value 5185 EVENT_RECORD, or several records starting with one having the value 5186 START_RECORD, followed by zero or more INTERIM_RECORD and a single 5187 STOP_RECORD. A particular Diameter application specification MUST 5188 define the type of sequences that MUST be used. 5190 9.6 Correlation of Accounting Records 5192 The Diameter protocol's Session-Id AVP, which is globally unique (see 5193 section 8.8), is used during the authorization phase to identify a 5194 particular session. Services that do not require any authorization 5195 still use the Session-Id AVP to identify sessions. Accounting 5196 messages MAY use a different Session-Id from that sent in 5197 authorization messages. Specific applications MAY require different 5198 a Session-ID for accounting messages. 5200 However, there are certain applications that require multiple 5201 accounting sub-sessions. Such applications would send messages with a 5202 constant Session-Id AVP, but a different Accounting-Sub-Session-Id 5203 AVP. In these cases, correlation is performed using the Session-Id. 5204 It is important to note that receiving a STOP_RECORD with no 5205 Accounting-Sub-Session-Id AVP when sub-sessions were originally used 5206 in the START_RECORD messages implies that all sub-sessions are 5207 terminated. 5209 Furthermore, there are certain applications where a user receives 5210 service from different access devices (e.g. Mobile IP), each with 5211 their own unique Session-Id. In such cases, the Acct-Multi-Session-Id 5212 AVP is used for correlation. During authorization, a server that 5213 determines that a request is for an existing session SHOULD include 5214 the Acct-Multi-Session-Id AVP, which the access device MUST include 5215 in all subsequent accounting messages. 5217 The Acct-Multi-Session-Id AVP MAY include the value of the original 5218 Session-Id. It's contents are implementation specific, but MUST be 5219 globally unique across other Acct-Multi-Session-Id, and MUST NOT 5220 change during the life of a session. 5222 A Diameter application document MUST define the exact concept of a 5223 session that is being accounted, and MAY define the concept of a 5224 multi-session. For instance, the NASREQ DIAMETER application treats a 5225 single PPP connection to a Network Access Server as one session, and 5226 a set of Multilink PPP sessions as one multi-session. 5228 9.7 Accounting Command-Codes 5230 This section defines new Command-Code values that MUST be supported 5231 by all Diameter implementations that provide Accounting services. 5233 9.7.1 Accounting-Request 5235 The Accounting-Request (ACR) command, indicated by the Command-Code 5236 field set to 271 and the Command Flags' 'R' bit set, is sent by a 5237 Diameter node, acting as a client, in order to exchange accounting 5238 information with a peer. 5240 One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs 5241 MUST be present. If the Vendor-Specific-Application-Id grouped AVP is 5242 present, it must have an Acct-Application-Id inside. 5244 The AVP listed below SHOULD include service specific accounting AVPs, 5245 as described in section 9.3. 5247 Message Format 5249 ::= < Diameter Header: 271, REQ, PXY > 5250 < Session-Id > 5251 { Origin-Host } 5252 { Origin-Realm } 5253 { Destination-Realm } 5254 { Accounting-Record-Type } 5255 { Accounting-Record-Number } 5256 [ Acct-Application-Id ] 5257 [ Vendor-Specific-Application-Id ] 5258 [ User-Name ] 5259 [ Accounting-Sub-Session-Id ] 5260 [ Accounting-RADIUS-Session-Id ] 5261 [ Acct-Multi-Session-Id ] 5262 [ Acct-interim-Interval ] 5263 [ Accounting-Realtime-Required ] 5264 [ Origin-State-Id ] 5265 [ Event-Timestamp ] 5266 * [ Proxy-Info ] 5267 * [ Route-Record ] 5268 * [ AVP ] 5270 9.7.2 Accounting-Answer 5272 The Accounting-Answer (ACA) command, indicated by the Command-Code 5273 field set to 271 and the Command Flags' 'R' bit cleared, is used to 5274 acknowledge an Accounting-Request command. The Accounting-Answer 5275 command contains the same Session-Id and includes the usage AVPs only 5276 if CMS is in use when sending this command. Note that the inclusion 5277 of the usage AVPs when CMS is not being used leads to unnecessarily 5278 large answer messages, and can not be used as a server's proof of the 5279 receipt of these AVPs in an end-to-end fashion. If the Accounting- 5280 Request was protected by end-to-end security, then the corresponding 5281 ACA message MUST be protected by end-to-end security. 5283 Only the target Diameter Server, known as the home Diameter Server, 5284 SHOULD respond with the Accounting-Answer command. 5286 One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs 5287 MUST be present. If the Vendor-Specific-Application-Id grouped AVP is 5288 present, it must have an Acct-Application-Id inside. 5290 The AVP listed below SHOULD include service specific accounting AVPs, 5291 as described in section 9.3. 5293 Message Format 5295 ::= < Diameter Header: 271, PXY > 5296 < Session-Id > 5297 { Result-Code } 5298 { Origin-Host } 5299 { Origin-Realm } 5300 { Accounting-Record-Type } 5301 { Accounting-Record-Number } 5302 [ Acct-Application-Id ] 5303 [ Vendor-Specific-Application-Id ] 5304 [ User-Name ] 5305 [ Accounting-Sub-Session-Id ] 5306 [ Accounting-RADIUS-Session-Id ] 5307 [ Acct-Multi-Session-Id ] 5308 [ Error-Reporting-Host ] 5309 [ Acct-interim-Interval ] 5310 [ Accounting-Realtime-Required ] 5311 [ Origin-State-Id ] 5312 [ Event-Timestamp ] 5313 * [ Proxy-Info ] 5314 * [ AVP ] 5316 9.8 Accounting AVPs 5318 This section contains AVPs that describe accounting usage information 5319 related to a specific session. 5321 9.8.1 Accounting-Record-Type AVP 5323 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated 5324 and contains the type of accounting record being sent. The following 5325 values are currently defined for the Accounting-Record-Type AVP: 5327 EVENT_RECORD 1 5328 An Accounting Event Record is used to indicate that a one-time 5329 event has occurred (meaning that the start and end of the event 5330 are simultaneous). This record contains all information 5331 relevant to the service, and is the only record of the service. 5333 START_RECORD 2 5334 An Accounting Start, Interim, and Stop Records are used to 5335 indicate that a service of a measurable length has been given. 5336 An Accounting Start Record is used to initiate an accounting 5337 session, and contains accounting information that is relevant 5338 to the initiation of the session. 5340 INTERIM_RECORD 3 5341 An Interim Accounting Record contains cumulative accounting 5342 information for an existing accounting session. Interim 5343 Accounting Records SHOULD be sent every time a re- 5344 authentication or re-authorization occurs. Further, additional 5345 interim record triggers MAY be defined by application-specific 5346 Diameter applications. The selection of whether to use 5347 INTERIM_RECORD records is done by the Acct-interim-Interval 5348 AVP. 5350 STOP_RECORD 4 5351 An Accounting Stop Record is sent to terminate an accounting 5352 session and contains cumulative accounting information relevant 5353 to the existing session. 5355 9.8.2 Acct-interim-Interval AVP 5357 The Acct-interim-Interval AVP (AVP Code 85) is of type Unsigned32 and 5358 is sent from the Diameter home authorization server to the Diameter 5359 client. The client uses information in this AVP to decide how and 5360 when to produce accounting records. With different values in this 5361 AVP, service sessions can result in one, two, or two+N accounting 5362 records, based on the needs of the home-organization. The following 5363 accounting record production behavior is directed by the inclusion of 5364 this AVP: 5366 1. The omission of the Acct-interim-Interval AVP or its inclusion 5367 with Value field set to 0 means that EVENT_RECORD, 5368 START_RECORD, and STOP_RECORD are produced, as appropriate for 5369 the service. 5371 2. The inclusion of the AVP with Value field set to a non-zero 5372 value means that INTERIM_RECORD records MUST be produced 5373 between the START_RECORD and STOP_RECORD records. The Value 5374 field of this AVP is the nominal interval between these records 5375 in seconds. The Diameter node that originates the accounting 5376 information, known as the client, MUST produce the first 5377 INTERIM_RECORD record roughly at the time when this nominal 5378 interval has elapsed from the START_RECORD, the next one again 5379 as the interval has elapsed once more, and so on until the 5380 session ends and a STOP_RECORD record is produced. 5382 The client MUST ensure that the interim record production times 5383 are randomized so that large accounting message storms are not 5384 created either among records or around a common service start 5385 time. 5387 9.8.3 Accounting-Record-Number AVP 5389 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 5390 and identifies this record within one session. As Session-Id AVPs are 5391 globally unique, the combination of Session-Id and Accounting- 5392 Record-Number AVPs is also globally unique, and can be used in 5393 matching accounting records with confirmations. An easy way to 5394 produce unique numbers is to set the value to 0 for records of type 5395 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 5396 INTERIM_RECORD, 2 for the second, and so on until the value for 5397 STOP_RECORD is one more than for the last INTERIM_RECORD. 5399 9.8.4 Accounting-RADIUS-Session-Id AVP 5401 The Accounting-RADIUS-Session-Id AVP (AVP Code 44) is of type 5402 OctetString is only used when RADIUS/Diameter translation occurs. 5403 This AVP contains the contents of the RADIUS Accounting-Session-Id 5404 attribute. 5406 9.8.5 Acct-Multi-Session-Id AVP 5408 The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String, 5409 following the format specified in section 8.8. The Acct-Multi- 5410 Session-Id AVP is used to link together multiple related accounting 5411 sessions, where each session would have a unique Session-Id, but the 5412 same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the 5413 Diameter server in an authorization answer, and MUST be used in all 5414 accounting messages for the given session. 5416 9.8.6 Accounting-Sub-Session-Id AVP 5418 The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type 5419 Unsigned64 and contains the accounting sub-session identifier. The 5420 combination of the Session-Id and this AVP MUST be unique per sub- 5421 session, and the value of this AVP MUST be monotonically increased by 5422 one for all new sub-sessions. The absence of this AVP implies no 5423 sub-sessions are in use, with the exception of an Accounting-Request 5424 whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD 5425 message with no Accounting-Sub-Session-Id AVP present will signal the 5426 termination of all sub-sessions for a given Session-Id. 5428 9.8.7 Accounting-Realtime-Required AVP 5430 The Accounting-Realtime-Required AVP (AVP Code 483) is of type 5431 Enumerated and is sent from the Diameter home authorization server to 5432 the Diameter client or in the Accounting-Answer from the accounting 5433 server. The client uses information in this AVP to decide what to do 5434 if the sending of accounting records to the accounting server has 5435 been temporarily prevented due to, for instance, a network problem. 5437 DELIVER_AND_GRANT 1 5439 The AVP with Value field set to DELIVER_AND_GRANT means that 5440 the service MUST only be granted as long as there is a 5441 connection to an accounting server. Note that the set of 5442 alternative accounting servers are treated as one server in 5443 this sense. Having to move the accounting record stream to a 5444 backup server is not a reason to discontinue the service to the 5445 user. 5447 GRANT_AND_STORE 2 5449 The AVP with Value field set to GRANT_AND_STORE means that 5450 service SHOULD be granted if there is a connection, or as long 5451 as records can still be stored as described in section 9.4. 5453 This is the default behaviour if the AVP isn't included in the 5454 reply from the authorization server. 5456 GRANT_AND_LOSE 3 5458 The AVP with Value field set to GRANT_AND_LOSE means that 5459 service SHOULD be granted even if the records can not be 5460 delivered or stored. 5462 10 AVP Occurrence Table 5464 The following tables presents the AVPs defined in this document, and 5465 specifies in which Diameter messages they MAY, or MAY NOT be present. 5466 Note that AVPs that can only be present within a Grouped AVP are not 5467 represented in this table. 5469 The table uses the following symbols: 5470 0 The AVP MUST NOT be present in the message. 5471 0+ Zero or more instances of the AVP MAY be present in the 5472 message. 5473 0-1 Zero or one instance of the AVP MAY be present in the 5474 message. It is considered an error if there are more than 5475 once instance of the AVP. 5476 1 One instance of the AVP MUST be present in the message. 5477 1+ At least one instance of the AVP MUST be present in the 5478 message. 5480 10.1 Base Protocol Command AVP Table 5482 The table in this section is limited to the non-accounting Command 5483 Codes defined in this specification. 5485 +-----------------------------------------------+ 5486 | Command-Code | 5487 |---+---+---+---+---+---+---+---+---+---+---+---+ 5488 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| 5489 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5490 Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5491 Interval | | | | | | | | | | | | | 5492 Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 | 5493 Required | | | | | | | | | | | | | 5494 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5495 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5496 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5497 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5498 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5499 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5500 Lifetime | | | | | | | | | | | | | 5501 Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ | 5502 Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 | 5503 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 5504 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5505 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| 5506 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5507 Failed-AVP |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ | 5508 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5509 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5510 Inband-Security-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5511 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5512 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5513 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 5514 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| 5515 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5516 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ | 5517 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ | 5518 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5519 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 5520 Time | | | | | | | | | | | | | 5521 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 | 5522 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 | 5523 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 | 5524 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5525 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | 5526 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5527 Failover | | | | | | | | | | | | | 5528 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5529 Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5530 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 | 5531 User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1| 5532 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5533 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 5534 Application-Id | | | | | | | | | | | | | 5535 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 5537 10.2 Accounting AVP Table 5539 The table in this section is used to represent which AVPs defined in 5540 this document are to be present in the Accounting messages. These 5541 AVP occurrence requirements are guidelines, which may be expanded, 5542 and/or overriden by application-specific requirements in the Diameter 5543 applications documents. 5545 +-----------+ 5546 | Command | 5547 | Code | 5548 |-----+-----+ 5549 Attribute Name | ACR | ACA | 5550 ------------------------------|-----+-----+ 5551 Acct-Interim-Interval | 0-1 | 0-1 | 5552 Acct-Multi-Session-Id | 0-1 | 0-1 | 5553 Accounting-Record-Number | 1 | 1 | 5554 Accounting-Record-Type | 1 | 1 | 5555 Accounting-RADIUS-Session-Id | 0-1 | 0-1 | 5556 Accounting-Sub-Session-Id | 0-1 | 0-1 | 5557 Accounting-Realtime-Required | 0-1 | 0-1 | 5558 Acct-Application-Id | 0-1 | 0-1 | 5559 Auth-Application-Id | 0 | 0 | 5560 Class | 0+ | 0+ | 5561 Destination-Host | 0-1 | 0 | 5562 Destination-Realm | 1 | 0 | 5563 Error-Reporting-Host | 0 | 0+ | 5564 Event-Timestamp | 0-1 | 0-1 | 5565 Origin-Host | 1 | 1 | 5566 Origin-Realm | 1 | 1 | 5567 Proxy-Info | 0+ | 0+ | 5568 Route-Record | 0+ | 0+ | 5569 Result-Code | 0 | 1 | 5570 Session-Id | 1 | 1 | 5571 Termination-Cause | 0-1 | 0-1 | 5572 User-Name | 0-1 | 0-1 | 5573 Vendor-Specific-Application-Id| 0-1 | 0-1 | 5574 ------------------------------|-----+-----+ 5576 11 IANA Considerations 5578 This document defines a number of assigned numbers to be maintained 5579 by the IANA. This section explains the criteria to be used by the 5580 IANA to assign additional numbers in each of these lists. The 5581 following subsections describe the assignment policy for the 5582 namespaces defined elsewhere in this document. 5584 11.1 AVP Header 5586 As defined in section 4, the AVP header contains two fields that 5587 requires IANA namespace management; the AVP Code and Flags field. 5589 11.1.1 AVP Code 5591 The AVP Code namespace is used to identify attributes. When the 5592 Vendor ID value is set to zero (0), IANA will maintain a registry of 5593 assigned AVP codes and in some cases also their values. AVP Codes 5594 0-254 are managed separately as RADIUS Attribute Types [RADTYPE], 5595 while the remaining namespace is available for assignment via 5596 Specification Required [IANA]. 5598 Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP 5599 header is set to a non-zero value, are for Private Use. 5601 This document defines the AVP Codes 257-274, 276-285, 287, 291-299, 5602 480, 483 and 485-486. See section 4.6 for the assignment of the 5603 namespace in this specification. 5605 11.1.2 AVP Flags 5607 There are 8 bits in the AVP Flags field of the AVP header, defined in 5608 section 4. This document assigns bit 8 ('V'endor Specific), bit 7 5609 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only 5610 be assigned via a Standards Action [IANA]. 5612 11.2 Diameter Header 5614 As defined in section 3, the Diameter header contains two fields that 5615 require IANA namespace management; Command Code and Command Flags. 5617 11.2.1 Command Codes 5619 The Command Code namespace is used to identify Diameter commands. The 5620 values 0-255 are reserved for RADIUS backward compatibility, and are 5621 defined as "RADIUS Packet Type Codes" in [RADTYPE]. The values 5622 4,294,967,295 to 4,294,967,279 (heximdecimal values FFFFF0-FFFFFF) 5623 are reserved for temporary, experimental commands. The remaining 5624 values are available via Standards Action [IANA]. 5626 Experimental Command Codes, are for private, experimental usage. As 5627 these codes are only for experimental purposes, no guarentee is made 5628 for interoperability between Diameter peers using experimental 5629 commands. The range of values will have a limited lifetime, and will 5630 eventually be reconsumed into the range available for 5631 standardization. 5633 This document defines the Command Codes 257, 258, 271, 274-275, 280 5634 and 282. See section 3.1 for the assignment of the namespace in this 5635 specification. 5637 11.2.2 Command Flags 5639 There are eight bits in the Command Flags field of the Diameter 5640 header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and 5641 bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a 5642 Standards Action [IANA]. 5644 11.3 Application Identifiers 5646 As defined in section 2.4, the Application Identifier is used to 5647 identify a specific Diameter Application. There are standards-track 5648 application ids and vendor specific application ids. 5650 IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for 5651 standards-track applications; and 0xff00000000 - 0xfffffffe for 5652 vendor specific applications. 5654 Both Application-Id and Acct-Application-Id AVPs use the same 5655 Application Identifier space. 5657 Vendor-Specific Application Identifiers, encoded in the Vendor- 5658 Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to 5659 the vendor's enterprise number, is for Private Use. 5661 Note that the Diameter protocol is not intended to be extended for 5662 any purpose. Any applications defined MUST ensure that they fit 5663 within the existing framework, and that no changes to the base 5664 protocol are required. 5666 11.4 Result-Code AVP Values 5667 As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines 5668 the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017. 5670 All remaining values are available for assignment via IETF Consensus 5671 [IANA]. 5673 11.5 Accounting-Record-Type AVP Values 5675 As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 5676 480) defines the values 1-4. All remaining values are available for 5677 assignment via IETF Consensus [IANA]. 5679 11.6 Termination-Cause AVP Values 5681 As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) 5682 defines the values 1-8. All remaining values are available for 5683 assignment via IETF Consensus [IANA]. 5685 11.7 Redirect-Host-Usage AVP Values 5687 As defined in Section 6.13, the Redirect-Host-Usage AVP (AVP Code 5688 261) defines the values 0-5. All remaining values are available for 5689 assignment via IETF Consensus [IANA]. 5691 11.8 Session-Server-Failover AVP Values 5693 As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 5694 271) defines the values 0-3. All remaining values are available for 5695 assignment via IETF Consensus [IANA]. 5697 11.9 Session-Binding AVP Values 5699 As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) 5700 defines the bits 1-4. All remaining bits are available for assignment 5701 via IETF Consensus [IANA]. 5703 11.10 Diameter TCP/SCTP Port Numbers 5705 An IANA request has been placed for TCP and SCTP port numbers. The 5706 IANA has informed the authors that "TBD" should be used in section 5707 2.1 and throughout this document, and will be updated by the RFC 5708 editor during the RFC publication process. 5710 IANA should also replace "TBD" in sections 4.4 and 5.2 with the port 5711 number assigned in section 2.1. 5713 11.11 Disconnect-Cause AVP Values 5715 As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) 5716 defines the values 0-2. All remaining values are available for 5717 assignment via IETF Consensus [IANA]. 5719 11.12 Auth-Request-Type AVP Values 5721 As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) 5722 defines the values 1-3. All remaining values are available for 5723 assignment via IETF Consensus [TCP]. 5725 11.13 Auth-Session-State AVP Values 5727 As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) 5728 defines the values 0-1. All remaining values are available for 5729 assignment via IETF Consensus [TCP]. 5731 11.14 Re-Auth-Request-Type AVP Values 5733 As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 5734 285) defines the values 0-1. All remaining values are available for 5735 assignment via IETF Consensus [TCP]. 5737 11.15 NAPTR Service Fields 5739 The registration in the RFC MUST include the following information: 5741 Service Field: The service field being registered. An example for a 5742 new fictitious transport protocol called NCTP might be "AAA+D2N". 5744 Protocol: The specific transport protocol associated with that 5745 service field. This MUST include the name and acronym for the 5746 protocol, along with reference to a document that describes the 5747 transport protocol. For example - "New Connectionless Transport 5748 Protocol (NCTP), RFC 5766". 5750 Name and Contact Information: The name, address, email address and 5751 telephone number for the person performing the registration. 5753 The following values are to be placed into the registry: 5755 Services Field Protocol 5756 AAA+D2T TCP 5757 AAA+D2S SCTP 5759 11.16 Accounting-Realtime-Required AVP Values 5761 As defined in Section 9.8.7, the Accounting-Realtime-Required AVP 5762 (AVP Code 483) defines the values 1-3. All remaining values are 5763 available for assignment via IETF Consensus [IANA]. 5765 12 Diameter protocol related configurable parameters 5767 This section contains the configurable parameters that are found 5768 throughout this document: 5770 Diameter Peer 5771 A Diameter entity MAY communicate with peers that are 5772 statically configured. A statically configured Diameter peer 5773 would require that either the IP address or the fully qualified 5774 domain name (FQDN) be supplied, which would then be used to 5775 resolve through DNS. 5777 Realm Routing Table 5778 A Diameter Proxy server routes messages based on the realm 5779 portion of a Network Access Identifier (NAI). The server MUST 5780 have a table of Realms Names, and the address of the peer to 5781 which the message must be forwarded to. The routing table MAY 5782 also include a "default route", which is typically used for all 5783 messages that cannot be locally processed. 5785 Tc timer 5786 The Tc timer controls the frequency that transport connection 5787 attempts are done to a peer with whom no active transport 5788 connection exists. The recommended value is 30 seconds. 5790 13 Security Considerations 5792 The Diameter base protocol assumes that messages are secured by using 5793 either IPSec or TLS. This security model is acceptable in 5794 environments where there is no untrusted third party agent. In other 5795 situations, end-to-end security is needed. 5797 13.1 IPsec Usage 5799 All Diameter implementations MUST support IPsec ESP [IPsec] in 5800 transport mode with with non-null encryption and authentication 5801 algorithms to provide per-packet authentication, integrity protection 5802 and confidentiality, and MUST support the replay protection 5803 mechanisms of IPsec. 5805 Diameter implementations MUST support IKE for peer authentication, 5806 negotiation of security associations, and key management, using the 5807 IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer 5808 authentication using a pre-shared key, and MAY support certificate- 5809 based peer authentication using digital signatures. Peer 5810 authentication using the public key encryption methods outlined in 5811 IKE's sections 5.2 and 5.3 [IKE] SHOULD NOT be used. 5813 Conformant implementations MUST support both IKE Main Mode and 5814 Aggressive Mode. When pre-shared keys are used for authentication, 5815 IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be 5816 used. When digital signatures are used for authentication, either IKE 5817 Main Mode or IKE Aggressive Mode MAY be used. 5819 When digital signatures are used to achieve authentication, an IKE 5820 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 5821 the certificate authority (or authorities) that are trusted in 5822 accordance with its local policy. IKE negotiators SHOULD use 5823 pertinent certificate revocation checks before accepting a PKI 5824 certificate for use in IKE's authentication procedures. 5826 The Phase 2 Quick Mode exchanges used to negotiate protection for 5827 Diameter connections MUST explicitly carry the Identity Payload 5828 fields (IDci and IDcr). The DOI provides for several types of 5829 identification data. However, when used in conformant 5830 implementations, each ID Payload MUST carry a single IP address and a 5831 single non-zero port number, and MUST NOT use the IP Subnet or IP 5832 Address Range formats. This allows the Phase 2 security association 5833 to correspond to specific TCP and SCTP connections. 5835 Since IPsec acceleration hardware may only be able to handle a 5836 limited number of active IKE Phase 2 SAs, Phase 2 delete messages may 5837 be sent for idle SAs, as a means of keeping the number of active 5838 Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 5839 message SHOULD NOT be interpreted as a reason for tearing down a 5840 Diameter connection. Rather, it is preferable to leave the connection 5841 up, and if additional traffic is sent on it, to bring up another IKE 5842 Phase 2 SA to protect it. This avoids the potential for continually 5843 bringing connections up and down. 5845 13.2 TLS Usage 5847 A Diameter node that initiates a connection to another Diameter node 5848 acts as a TLS client according to [TLS], and a Diameter node that 5849 accepts a connection acts as a TLS server. Diameter nodes 5850 implementing TLS for security MUST mutually authenticate as part of 5851 TLS session establishment. In order to ensure mutual authentication, 5852 the Diameter node acting as TLS server must request a certificate 5853 from the Diameter node acting as TLS client, and the Diameter node 5854 acting as TLS client MUST be prepared to supply a certificate on 5855 request. 5857 Diameter nodes MUST be able to negotiate the following TLS cipher 5858 suites: 5860 TLS_RSA_WITH_RC4_128_MD5 5861 TLS_RSA_WITH_RC4_128_SHA 5862 TLS_RSA_WITH_3DES_EDE_CBC_SHA 5864 Diameter nodes MAY negotiate other TLS cipher suites. 5866 13.3 Peer-to-Peer Considerations 5868 As with any peer-to-peer protocol, proper configuration of the trust 5869 model within a Diameter peer is essential to security. When 5870 certificates are used, it is necessary to configure the root 5871 certificate authorities trusted by the Diameter peer. These root CAs 5872 are likely to be unique to Diameter usage and distinct from the root 5873 CAs that might be trusted for other purposes such as Web browsing. In 5874 general, it is expected that those root CAs will be configured so as 5875 to reflect the business relationships between the organization 5876 hosting the Diameter peer and other organizations. As a result, a 5877 Diameter peer will typically not be configured to allow connectivity 5878 with any arbitrary peer. When certificate authentication Diameter 5879 peers may not be known beforehand, and therefore peer discovery may 5880 be required. 5882 Note that IPsec is considerably less flexible than TLS when it comes 5883 to configuring root CAs. Since use of Port identifiers is prohibited 5884 within IKE Phase 1, within IPsec it is not possible to uniquely 5885 configure trusted root CAs for each application individually; the 5886 same policy must be used for all applications. This implies, for 5887 example, that a root CA trusted for use with Diameter must also be 5888 trusted to protect SNMP. These restrictions can be awkward at best. 5889 Since TLS supports application-level granularity in certificate 5890 policy, TLS SHOULD be used to protect Diameter connections between 5891 administrative domains. IPsec is most appropriate for intra-domain 5892 usage when pre-shared keys are used as a security mechanism. 5894 When pre-shared key authentication is used with IPsec to protect 5895 Diameter, unique pre-shared keys are configured with Diameter peers, 5896 who are identified by their IP address (Main Mode), or possibly their 5897 FQDN (Aggressive Mode). As a result, it is necessary for the set of 5898 Diameter peers to be known beforehand. Therefore, peer discovery is 5899 typically not necessary. 5901 The following is intended to provide some guidance on the issue. 5903 It is recommended that a Diameter peer implement the same security 5904 mechanism (IPsec or TLS) across all its peer-to-peer connections. 5905 Inconsistent use of security mechanisms can result in redundant 5906 security mechanisms being used (e.g. TLS over IPsec) or worse, 5907 potential security vulnerabilities. When IPsec is used with Diameter, 5908 a typical security policy for outbound traffic is "Initiate IPsec, 5909 from me to any, destination port Diameter"; for inbound traffic, the 5910 policy would be "Require IPsec, from any to me, destination port 5911 Diameter". 5913 This policy causes IPsec to be used whenever a Diameter peer 5914 initiates a connection to another Diameter peer, and to be required 5915 whenever an inbound Diameter connection occurs. This policy is 5916 attractive, since it does not require policy to be set for each peer 5917 or dynamically modified each time a new Diameter connection is 5918 created; an IPsec SA is automatically created based on a simple 5919 static policy. Since IPsec extensions are typically not available to 5920 the sockets API on most platforms, and IPsec policy functionality is 5921 implementation dependent, use of a simple static policy is the often 5922 the simplest route to IPsec-enabling a Diameter implementation. 5924 One implication of the recommended policy is that if a node is using 5925 both TLS and IPsec, there is not a convenient way in which to use 5926 either TLS or IPsec, but not both, without reserving an additional 5927 port for TLS usage. Since Diameter uses the same port for TLS and 5928 non-TLS usage, where the recommended IPsec policy is put in place, a 5929 TLS-protected connection will match the IPsec policy, and both IPsec 5930 and TLS will be used to protect the Diameter connection. To avoid 5931 this, it would be necessary to plumb peer-specific policies either 5932 statically or dynamically. 5934 If IPsec is used to secure Diameter peer-to-peer connections, IPsec 5935 policy SHOULD be set so as to require IPsec protection for inbound 5936 connections, and to initiate IPsec protection for outbound 5937 connections. This can be accomplished via use of inbound and outbound 5938 filter policy. 5940 14 References 5942 14.1 Normative 5944 [AAATRANS] B. Aboba, J. Wood, "Authentication, Authorization and 5945 Accounting (AAA) Transport Profile", IETF Work in Pro- 5946 gress. 5948 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax 5949 Specifications: ABNF", RFC 2234, November 1997. 5951 [ASSIGNNO] Reynolds, Postel, "Assigned Numbers", RFC 1700, 5952 October 1994. 5954 [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 5955 of the Differentiated Services Field (DS Field) in the 5956 IPv4 and IPv6 Headers," RFC 2474, December 1998. 5958 [DIFFSERVAF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, 5959 "Assured Forwarding PHB Group," RFC 2597, June 1999. 5961 [DIFFSERVEF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited For- 5962 warding PHB", RFC 2598, June 1999. 5964 [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for 5965 specifying the location of services (DNS SRV)", RFC 5966 2782, February 2000. 5968 [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authen- 5969 tication Protocol (EAP)." RFC 2284, March 1998. 5971 [FLOATPOINT] Institute of Electrical and Electronics Engineers, 5972 "IEEE Standard for Binary Floating-Point Arithmetic", 5973 ANSI/IEEE Standard 754-1985, August 1985. 5975 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 5976 Considerations Section in RFCs", BCP 26, RFC 2434, 5977 October 1998 5979 [IANAWEB] IANA, "Number assignment", http://www.iana.org 5981 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 5982 (IKE)", RFC 2409, November 1998. 5984 [IPSECDOI] D. Piper, "The Internet IP Security Domain of 5985 Interpretation for ISAKMP", RFC 2407, November 1998. 5987 [IPV4] ISI, "Internet Protocol", RFC 791, September 1981. 5989 [IPV6] Hinden, Deering, "IP Version 6 Addressing Architec- 5990 ture", RFC 2373, July 1998. 5992 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 5993 Requirement Levels", BCP 14, RFC 2119, March 1997. 5995 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 5996 2486. January 1999. 5998 [NAPTR] M. Mealling and R. Daniel, "The naming authority 5999 pointer (NAPTR) DNS resource record," Request for Com- 6000 ments 2915, Internet Engineering Task Force, Sept. 6001 2000. 6003 [RADTYPE] IANA, "RADIUS Types", 6004 http://www.iana.org/assignments/radius-types 6006 [SCTP] R. Stewart et al., "Stream Control Transmission Proto- 6007 col". RFC 2960. October 2000. 6009 [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service 6010 Location Protocol, Version 2", RFC 2165, June 1999. 6012 [SNTP] Mills, "Simple Network Time Protocol (SNTP) Version 4 6013 for IPv4, IPv6 and OSI, RFC 2030, October 1996. 6015 [TCP] Postel, J. "Transmission Control Protocol", RFC 793, 6016 January 1981. 6018 [TEMPLATE] E. Guttman, C. Perkins, J. Kempf, "Service Templates 6019 and Service: Schemes", RFC 2609, June 1999. 6021 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 6022 RFC 2246, January 1999. 6024 [TLSSCTP] M. Tuexen, et al. "TLS over SCTP" IETF Work in Pro- 6025 gress. 6027 [URI] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, 6028 "Uniform Resource Identifiers (URI): Generic Syntax". 6029 RFC 2396, August 1998. 6031 [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 6032 10646", RFC 2279, January 1998. 6034 14.2 Non-Normative 6036 [ACCMGMT] B. Aboba, J. Arkko, D. Harrington. "Introduction to 6037 Accounting Management", RFC 2975, October 2000. 6039 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 6040 for AAA", RFC 3141, June 2001. 6042 [AAACMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 6043 application," IETF Work in Progress. 6045 [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 6046 IETF work in progress. 6048 [IPComp] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Pay- 6049 load Compression Protocol (IPComp)", RFC 2393, December 6050 1998. 6052 [MIPV4] C. Perkins, Editor. IP Mobility Support. RFC 3220, 6053 January 2002. 6055 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica- 6056 tion, Authorization, and Accounting Requirements". RFC 6057 2977. October 2000. 6059 [NASNG] D. Mitton, M. Beadles, "Network Access Server Require- 6060 ments Next Generation (NASREQNG) NAS Model", RFC 2881. 6061 July 2000. 6063 [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter 6064 NASREQ Application", IETF work in progress. 6066 [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network 6067 Access Server Protocols", RFC 3169, September 2001. 6069 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 6070 1661, STD 51, July 1994. 6072 [PROXYCHAIN] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy 6073 Implementation in Roaming", RFC 2607, June 1999. 6075 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 6076 Authentication Dial In User Service (RADIUS)", RFC 2865, 6077 June 2000. 6079 [ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro- 6080 tocols", RFC 2477, January 1999. 6082 [SECARCH] S. Kent, R. Atkinson, "Security Architecture for the 6083 Internet Protocol", RFC 2401, November 1998. 6085 15 Acknowledgements 6086 The authors would like to thank Nenad Trifunovic, Tony Johansson and 6087 Pankaj Patel for their participation in the pre-IETF Document Reading 6088 Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided 6089 invaluable assistance in working out transport issues, and similarly 6090 with Steven Bellovin in the security area. 6092 Paul Funk and David Mitton were instrumental in getting the Peer 6093 State Machine correct, and our deep thanks go to them for their time. 6094 Text in this document was also provided by Paul Funk, Mark Eklund, 6095 Mark Jones and Dave Spence. Jacques Caron provided many great com- 6096 ments as a result of a thorough review of the spec. 6098 The authors would also like to acknowledge the following people for 6099 their contribution in the development of the Diameter protocol: 6101 Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, 6102 David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy 6103 Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, 6104 Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, 6105 Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and 6106 Jeff Weisberg. 6108 Finally, Pat Calhoun would like to thank Sun Microsystems since most 6109 of the effort put into this document was done while he was in their 6110 employ. 6112 16 Authors' Addresses 6114 Questions about this memo can be directed to: 6116 Pat R. Calhoun 6117 Black Storm Networks 6118 250 Cambridge Avenue, Suite 200 6119 Palo Alto, California, 94306 6120 USA 6122 Phone: +1 650-617-2932 6123 Fax: +1 650-786-6445 6124 E-mail: pcalhoun@bstormnetworks.com 6125 John Loughney 6126 Nokia Research Center 6127 It�merenkatu 11-13 6128 00180 Helsinki 6129 Finland 6131 Phone: +358 50 483 6242 6132 E-mail: john.Loughney@nokia.com 6134 Jari Arkko 6135 Ericsson 6136 02420 Jorvas 6137 Finland 6139 Phone: +358 40 5079256 6140 E-Mail: Jari.Arkko@ericsson.com 6142 Erik Guttman 6143 Solaris Advanced Development 6144 Sun Microsystems, Inc. 6145 Eichhoelzelstr. 7 6146 74915 Waibstadt 6147 Germany 6149 Phone: +49-7263-911-701 6150 E-mail: erik.guttman@germany.sun.com 6152 Glen Zorn 6153 Cisco Systems, Inc. 6154 500 108th Avenue N.E., Suite 500 6155 Bellevue, WA 98004 6156 USA 6158 Phone: +1 425 438 8218 6160 17 Full Copyright Statement 6162 Copyright (C) The Internet Society (2002). All Rights Reserved. 6164 This document and translations of it may be copied and furnished to 6165 others, and derivative works that comment on or otherwise explain it 6166 or assist in its implementation may be prepared, copied, published 6167 and distributed, in whole or in part, without restriction of any 6168 kind, provided that the above copyright notice and this paragraph are 6169 included on all such copies and derivative works. However, this docu- 6170 ment itself may not be modified in any way, such as by removing the 6171 copyright notice or references to the Internet Society or other 6172 Internet organizations, except as needed for the purpose of develop- 6173 ing Internet standards in which case the procedures for copyrights 6174 defined in the Internet Standards process must be followed, or as 6175 required to translate it into languages other than English. The lim- 6176 ited permissions granted above are perpetual and will not be revoked 6177 by the Internet Society or its successors or assigns. This document 6178 and the information contained herein is provided on an "AS IS" basis 6179 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 6180 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 6181 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 6182 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 6183 FITNESS FOR A PARTICULAR PURPOSE. 6185 18 Expiration Date 6187 This memo is filed as and expires in 6188 October 2002. 6190 Appendix A. Diameter Service Template 6192 The following service template describes the attributes used by Diam- 6193 eter servers to advertise themselves. This simplifies the process of 6194 selecting an appropriate server to communicate with. A Diameter 6195 client can request specific Diameter servers based on characteristics 6196 of the Diameter service desired (for example, an AAA server to use 6197 for accounting.) 6199 Name of submitter: "Erik Guttman" 6200 Language of service template: en 6202 Security Considerations: 6203 Diameter clients and servers use various cryptographic mechanisms 6204 to protect communication integrity, confidentiality as well as 6205 perform end-point authentication. It would thus be difficult if 6206 not impossible for an attacker to advertise itself using SLPv2 and 6207 pose as a legitimate Diameter peer without proper preconfigured 6208 secrets or cryptographic keys. Still, as Diameter services are 6209 vital for network operation it is important to use SLPv2 authenti- 6210 cation to prevent an attacker from modifying or eliminating ser- 6211 vice advertisements for legitimate Diameter servers. 6213 Template text: 6214 -------------------------template begins here----------------------- 6215 template-type=service:diameter 6217 template-version=0.0 6219 template-description= 6220 The Diameter protocol is defined by draft-ietf-aaa-diameter-09.txt 6222 template-url-syntax= 6223 url-path= ; The Diameter URL format is described in section 2.9. 6224 ; Example: 'aaa://aaa.abc.com:1812;transport=tcp 6226 supported-auth-applications= string L M 6227 # This attribute lists the Diameter applications supported by the 6228 # AAA implementation. The applications currently defined are: 6229 # Application Name Defined by 6230 # ---------------- ----------------------------------- 6231 # NASREQ draft-ietf-aaa-diameter-nasreq-09.txt 6232 # MobileIP draft-ietf-aaa-diameter-mobileip-09.txt 6233 # 6234 # Notes: 6235 # . Diameter implementations support one or more applications. 6236 # . Additional applications may be defined in the future. 6237 # An updated service template will be created at that time. 6238 # 6239 NASREQ,MobileIP 6241 supported-acct-applications= string L M 6242 # This attribute lists the Diameter applications supported by the 6243 # AAA implementation. The applications currently defined are: 6244 # Application Name Defined by 6245 # ---------------- ----------------------------------- 6246 # NASREQ draft-ietf-aaa-diameter-nasreq-09.txt 6247 # MobileIP draft-ietf-aaa-diameter-mobileip-09.txt 6248 # 6249 # Notes: 6250 # . Diameter implementations support one or more applications. 6251 # . Additional applications may be defined in the future. 6252 # An updated service template will be created at that time. 6253 # 6254 NASREQ,MobileIP 6256 supported-transports= string L M 6257 SCTP 6258 # This attribute lists the supported transports that the Diameter 6259 # implementation accepts. Note that a compliant Diameter 6260 # implementation MUST support SCTP, though it MAY support other 6261 # transports, too. 6262 SCTP,TCP 6264 -------------------------template ends here----------------------- 6266 Appendix B. NAPTR Example 6268 As an example, consider a client that wishes to resolve aaa:ex.com. 6269 The client performs a NAPTR query for that domain, and the following 6270 NAPTR records are returned: 6272 ;; order pref flags service regexp replacement 6273 IN NAPTR 50 50 "s" "AAA+D2S" "" 6274 _diameter._sctp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T" 6275 "" _aaa._tcp.ex.com 6277 This indicates that the server supports SCTP, and TCP, in that order. 6278 If the client supports over SCTP, SCTP will be used, targeted to a 6279 host determined by an SRV lookup of _diameter._sctp.ex.com. That 6280 lookup would return: 6282 ;; Priority Weight Port Target 6283 IN SRV 0 1 5060 server1.ex.com IN SRV 0 2 6284 5060 server2.ex.com 6286 Appendix C. Duplicate Detection 6288 As described in section 9.4, accounting record duplicate detection is 6289 based on the session identifiers. Duplicates can appear for various 6290 reasons: 6292 - Failover to an alternate server. Where we close to real-time 6293 performance is expected, failover tresholds need to be kept low 6294 and this may lead to a relatively large likelihood of duplicates. 6296 - A crash of a client at the time it just had managed to send a 6297 record from a non-volatile memory would likely cause the same 6298 record to be sent soon after the client has rebooted. 6300 - Duplicates received from RADIUS gateways. 6302 - Implementation problems and misconfiguration. 6304 In some cases the Diameter accounting server can delay the duplicate 6305 detection and accounting record processing until a post-processing 6306 phase takes place. At that time records are likely to be sorted 6307 according to the User-Name contained in them and duplicate elimina- 6308 tion is easy in this case. 6310 In other situations it may be necessary to perform real-time dupli- 6311 cate detection, e.g. when the credit limits or fraud attempts are 6312 being monitored in real time. 6314 In general, only the duplicate generation at failover case is some- 6315 thing that can be reliably detected by the Diameter client. The Diam- 6316 eter server is therefore responsible for the duplicate detection pro- 6317 cess. When real-time duplicate detection is required, this implies a 6318 database-like search functionality to find duplicate records. Imple- 6319 mentors are advised, however, that there exists ways to avoid 6320 expensive all-record searches. For instance, it can be usually safely 6321 assumed that duplicates appear within a time window of longest ima- 6322 ginable network partition, perhaps a day as an example. So only 6323 records within this time window need to be looked at. Secondly, hash- 6324 ing techniques or other schemes may be used to eliminate the need to 6325 do a full search even in this set except for rare cases.