idnits 2.17.1 draft-ietf-aaa-diameter-07.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 119 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 120 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2794 has weird spacing: '...onn-Ack an a...' == Line 4610 has weird spacing: '...nd-Code value...' == 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations SHOULD not use the zero (0) vendor ID. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The UTF8String MUST not contain any octets with a value of zero. == 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 2001) is 8314 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) == Unused Reference: '4' is defined on line 5106, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 5109, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 5113, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 5137, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 5152, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 5169, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 5216, but no explicit reference was found in the text == Unused Reference: '48' is defined on line 5244, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-07 ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-07 == Outdated reference: A later version (-04) exists of draft-ietf-aaa-diameter-cms-sec-01 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2560 (ref. '14') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2409 (ref. '15') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2373 (ref. '16') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2030 (ref. '18') (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 2459 (ref. '19') (Obsoleted by RFC 3280) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '20') ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '21') ** Downref: Normative reference to an Informational RFC: RFC 3141 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '23') ** Obsolete normative reference: RFC 2279 (ref. '24') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2284 (ref. '25') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2960 (ref. '26') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 793 (ref. '27') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2396 (ref. '29') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '30' ** Obsolete normative reference: RFC 2234 (ref. '31') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2535 (ref. '34') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (ref. '35') (Obsoleted by RFC 4641) ** Obsolete normative reference: RFC 2401 (ref. '37') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2246 (ref. '38') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '39' ** Downref: Normative reference to an Informational RFC: RFC 2975 (ref. '40') ** Obsolete normative reference: RFC 2393 (ref. '41') (Obsoleted by RFC 3173) ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '43') ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '44') ** Obsolete normative reference: RFC 2002 (ref. '45') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '46' -- Duplicate reference: RFC2782, mentioned in '47', was also mentioned in '33'. ** Obsolete normative reference: RFC 2598 (ref. '51') (Obsoleted by RFC 3246) Summary: 36 errors (**), 0 flaws (~~), 22 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 Sun Microsystems, Inc. 4 Category: Standards Track Haseeb Akhtar 5 Nortel Networks 6 Jari Arkko 7 Oy LM Ericsson Ab 8 Erik Guttman 9 Sun Microsystems, Inc. 10 Allan C. Rubens 11 Tut Systems, Inc. 12 Glen Zorn 13 Cisco Systems, Inc. 14 July 2001 16 Diameter Base Protocol 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 37 http://www.ietf.org/shadow.html. 39 Distribution of this memo is unlimited. 41 Copyright (C) The Internet Society 2001. All Rights Reserved. 43 Abstract 45 The Diameter base protocol is intended to provide a AAA framework for 46 Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message 47 format, transport, error reporting and security services to be used 48 by all Diameter applications and MUST be supported by all Diameter 49 implementations. 51 Table of Contents 53 1.0 Introduction 54 1.1 Diameter Protocol 55 1.2 Requirements language 56 1.3 Terminology 57 2.0 Protocol Overview 58 2.1 Transport 59 2.1.1 SCTP Guidelines 60 2.2 Securing Diameter Messages 61 2.3 Diameter Protocol Extensibility 62 2.3.1 Defining new AVP Values 63 2.3.2 Creating new AVPs 64 2.3.3 Creating a new Diameter Applications 65 2.3.4 Application authentication procedures 66 2.4 Diameter Application Compliance 67 2.5 Application Identifiers 68 2.6 Peer Table 69 2.7 Realm-Based Routing Table 70 2.8 Role of Diameter Agents 71 2.8.1 Relay Agents 72 2.8.2 Proxy Agents 73 2.8.3 Redirector Agents 74 2.8.4 Translation Agents 75 3.0 Diameter Header 76 3.1 Command Code Definitions 77 3.2 Command Code ABNF specification 78 3.3 Diameter Command Naming Conventions 79 4.0 Diameter AVPs 80 4.1 AVP Header 81 4.2 Optional Header Elements 82 4.3 AVP Data Formats 83 4.4 Derived AVP Data Formats 84 4.5 Grouped AVP Values 85 4.5.1 Example AVP with a Grouped Data type 86 4.6 Diameter Base Protocol AVPs 87 5.0 Diameter Peers 88 5.1 Connecting to Peers 89 5.2 Diameter Peer Discovery 90 5.3 Capabilities Negotiation 91 5.3.1 Capabilities-Exchange-Request 92 5.3.2 Capabilities-Exchange-Answer 93 5.3.3 Vendor-Id AVP 94 5.3.4 Firmware-Revision AVP 95 5.3.5 Host-IP-Address AVP 96 5.3.6 Supported-Vendor-Id AVP 97 5.3.7 Product-Name AVP 98 5.3.8 Alternate-Peer AVP 99 5.4 Disconnecting Peer connections 100 5.4.1 Disconnect-Peer-Request 101 5.4.2 Disconnect-Peer-Answer 102 5.4.3 Disconnect-Cause AVP 103 5.5 Transport Failure Detection 104 5.5.1 Device-Watchdog-Request 105 5.5.2 Device-Watchdog-Answer 106 5.5.3 Transport Failure Algorithm 107 5.5.4 Failover/Failback Procedures 108 5.6 Peer State Machine 109 5.6.1 Incoming connections 110 5.6.2 Events 111 5.6.3 Actions 112 5.6.4 The Election Process 113 6.0 Diameter message processing 114 6.1 Diameter request routing overview 115 6.1.1 Originating a Request 116 6.1.2 Sending a Request 117 6.1.3 Receiving Requests 118 6.1.4 Processing Local Requests 119 6.1.5 Request Forwarding 120 6.1.6 Request Routing 121 6.1.7 Redirecting requests 122 6.1.8 Relaying and Proxying Requests 123 6.1.9 Relaying and Proxying Server-Initiated Requests 124 6.2 Diameter Answer Processing 125 6.2.1 Processing received Answers 126 6.2.2 Relaying and Proxying Answers 127 6.3 Hiding Network Topology 128 6.4 Origin-Host AVP 129 6.5 Origin-Realm AVP 130 6.6 Destination-Host AVP 131 6.7 Destination-Realm AVP 132 6.8 Routing AVPs 133 6.8.1 Route-Record AVP 134 6.8.2 Proxy-Info AVP 135 6.8.3 Proxy-Host AVP 136 6.8.4 Proxy-State AVP 137 6.8.5 Source-Route AVP 139 6.9 Auth-Application-Id AVP 140 6.10 Acct-Application-Id AVP 141 6.11 Vendor-Specific-Application-Id AVP 142 6.12 Redirect-Host AVP 143 6.13 Redirect-Host-Usage AVP 144 6.14 Redirect-Max-Cache-Time AVP 145 7.0 Error Handling 146 7.1 Result-Code AVP 147 7.1.1 Informational 148 7.1.2 Success 149 7.1.3 Protocol Errors 150 7.1.4 Transient Failures 151 7.1.5 Permanent Failures 152 7.2 Error Bit 153 7.3 Error-Message AVP 154 7.4 Error-Reporting-Host AVP 155 7.5 Failed-AVP AVP 156 8.0 Diameter User Sessions 157 8.1 Authorization Session State Machine 158 8.2 Accounting Session State Machine 159 8.3 Server-Initiated Re-Auth 160 8.3.1 Re-Auth-Request 161 8.3.2 Re-Auth-Answer 162 8.4 Session Termination 163 8.4.1 Session-Termination-Request 164 8.4.2 Session-Termination-Answer 165 8.5 Aborting a Session 166 8.5.1 Abort-Session-Request 167 8.5.2 Abort-Session-Answer 168 8.6 Inferring Session Termination from Origin-State-Id 169 8.7 Auth-Request-Type AVP 170 8.8 Session-Id AVP 171 8.9 Authorization-Lifetime AVP 172 8.10 Auth-Grace-Period AVP 173 8.11 Auth-Session-State AVP 174 8.12 Re-Auth-Request-Type AVP 175 8.13 Session-Timeout AVP 176 8.14 User-Name AVP 177 8.15 Termination-Cause AVP 178 8.16 Origin-State-Id AVP 179 8.17 Session-Binding AVP 180 8.18 Session-Server-Failover AVP 181 8.19 Multi-Round-Time-Out AVP 182 8.20 Class AVP 183 9.0 Accounting 184 9.1 Server Directed Model 185 9.2 Protocol Messages 186 9.3 Application document requirements 187 9.4 Fault Resilience 188 9.5 Accounting Records 189 9.6 Correlation of Accounting Records 190 9.7 Accounting Command-Codes 191 9.7.1 Accounting-Request 192 9.7.2 Accounting-Answer 193 9.8 Accounting AVPs 194 9.8.1 Accounting-Record-Type AVP 195 9.8.2 Accounting-Interim-Interval AVP 196 9.8.3 Accounting-Record-Number AVP 197 9.8.4 Accounting-Session-Id AVP 198 9.8.5 Accounting-Multi-Session-Id AVP 199 10.0 AVP Occurrence Table 200 10.1 Base Protocol Command AVP Table 201 10.2 Accounting AVP Table 202 11.0 IANA Considerations 203 11.1 AVP Header 204 11.1.1 AVP Code 205 11.1.2 AVP Flags 206 11.2 Diameter Header 207 11.2.1 Command Codes 208 11.2.2 Message Flags 209 11.3 Application Identifier Values 210 11.4 Result-Code AVP Values 211 11.5 Accounting-Record-Type AVP Values 212 11.6 Termination-Cause AVP Values 213 11.7 Redirect-Host-Usage AVP Values 214 11.8 Session-Server-Failover AVP Values 215 11.9 Session-Binding AVP Values 216 11.10 Diameter TCP/SCTP Port Numbers 217 11.11 Disconnect-Cause AVP Values 218 11.12 Auth-Request-Type AVP Values 219 11.13 Auth-Session-State AVP Values 220 11.14 Re-Auth-Request-Type AVP Values 221 12.0 Diameter protocol related configurable parameters 222 13.0 Security Considerations 223 14.0 References 224 15.0 Acknowledgements 225 16.0 Authors' Addresses 226 17.0 Full Copyright Statement 227 18.0 Expiration Date 228 Appendix A. Diameter Service Template 230 1.0 Introduction 232 Historically, the RADIUS protocol has been used to provide AAA 233 services for dial-up PPP [42] and terminal server access. Over time, 234 routers and network access servers (NAS) have increased in complexity 235 and density, making the RADIUS protocol increasingly unsuitable for 236 use in such networks. 238 The Roaming Operations Working Group (ROAMOPS) has published a set of 239 specifications [20, 43, 44] that define how a PPP user can gain 240 access to the Internet without having to dial into his/her home 241 service provider's modem pool. This is achieved by allowing service 242 providers to cross-authenticate their users. Effectively, a user can 243 dial into any service provider's point of presence (POP) that has a 244 roaming agreement with his/her home Internet service provider (ISP), 245 the benefit being that the user does not have to incur a long 246 distance charge while traveling, which can sometimes be quite 247 expensive. 249 Given the number of ISPs today, ROAMOPS realized that requiring each 250 ISP to set up roaming agreements with all other ISPs did not scale. 251 Therefore, the working group defined a "broker", which acts as an 252 intermediate server, whose sole purpose is to set up these roaming 253 agreements. A collection of ISPs and a broker is called a "roaming 254 consortium". There are many such brokers in existence today; many 255 also provide settlement services for member ISPs. 257 The Mobile-IP Working Group has recently changed its focus to inter 258 administrative domain mobility, which is a requirement for cellular 259 carriers wishing to deploy IETF-based mobility protocols. The current 260 cellular carriers requirements [22, 23] are very similar to the 261 ROAMOPS model, with the exception that the access protocol is 262 Mobile-IP [45] instead of PPP. 264 The Diameter protocol was not designed from the ground up. Instead, 265 the basic RADIUS model was retained while fixing the flaws in the 266 RADIUS protocol itself. Diameter does not share a common protocol 267 data unit (PDU) with RADIUS, but does borrow sufficiently from the 268 protocol to ease migration. 270 The basic concept behind Diameter is to provide a base protocol that 271 can be extended in order to provide AAA services to new access 272 technologies. Currently, the protocol only concerns itself with 273 Internet access, both in the traditional PPP sense as well as taking 274 into account the ROAMOPS model, and Mobile-IP. 276 Although Diameter could be used to solve a wider set of AAA problems, 277 we are currently limiting the scope of the protocol in order to 278 ensure that the effort remains focused on satisfying the requirements 279 of network access. Note that a truly generic AAA protocol used by 280 many applications might provide functionality not provided by 281 Diameter. Therefore, it is imperative that the designers of new 282 applications understand their requirements before using Diameter. 284 1.1 Diameter Protocol 286 The Diameter protocol allows peers to exchange a variety of messages. 287 The base protocol provides the following facilities: 289 - Delivery of AVPs (attribute value pairs) 290 - Capabilities negotiation, as required in [20] 291 - Error notification 292 - Extensibility, through addition of new commands and AVPs, as 293 required in [21] 295 All data delivered by the protocol is in the form of an AVP. Some of 296 these AVP values are used by the Diameter protocol itself, while 297 others deliver data associated with particular applications which 298 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 299 so long as the required AVPs are included and AVPs which are 300 explicitly excluded are not included. AVPs are used by base Diameter 301 protocol to support the following required features: 303 - Transporting of user authentication information, for the 304 purposes of enabling the Diameter server to authenticate the 305 user. 306 - Transporting of service specific authorization information, 307 between client and servers, allowing the peers to decide whether 308 a user's access request should be granted. 309 - Exchanging resource usage information, which MAY be used for 310 accounting purposes, capacity planning, etc. 311 - Relaying, proxying and re-directing of Diameter messages through 312 a server hierarchy. 314 The Diameter base protocol provides the minimum requirements needed 315 for an AAA transport protocol, as required by NASREQ [21], Mobile IP 316 [22, 23], and ROAMOPS [20]. The base protocol is not intended to be 317 used by itself, and must be used with a Diameter application, such as 318 Mobile IP [10]. The Diameter protocol was heavily inspired and builds 319 upon the tradition of the RADIUS [1] protocol. See section 2.4. for 320 more information on Diameter applications. 322 Any node can initiate a request. In that sense, Diameter is a peer to 323 peer protocol. In this document, a Diameter client is the device that 324 normally initiates a request for authentication and/or authorization 325 of a user. A Diameter server is the device that either forwards the 326 request to another Diameter server (known as a proxy), or one that 327 performs the actual authentication and/or authorization of the user 328 based on some profile. Given that the server MAY send unsolicited 329 messages to clients, it is possible for the server to initiate such 330 messages. An example of an unsolicited message would be for a request 331 that the client issue an accounting update. 333 1.2 Requirements language 335 In this document, the key words "MAY", "MUST", "MUST NOT", 336 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 337 interpreted as described in [13]. 339 1.3 Terminology 341 Accounting 342 The act of collecting information on resource usage for the 343 purpose of trend analysis, auditing, billing, or cost allocation. 345 Accounting record 346 A session record represents a summary of the resource consumption 347 of a user over the entire session. Accounting gateways creating 348 the session record may do so by processing interim accounting 349 events or accounting events from several 351 Authentication 352 The act of verifying the identity of an entity (subject). 354 Authorization 355 The act of determining whether a requesting entity (subject) will 356 be allowed access to a resource (object). 358 AVP 359 The Diameter protocol consists of a header followed by one or more 360 Attribute-Value-Pair (AVP). The AVP includes a header and is used 361 to encapsulation authentication, authorization or accounting 362 information. 364 Broker 365 A broker is a business term commonly used in AAA infrastructures. 366 A broker is either a relay, proxy or redirect server, and MAY be 367 operated by roaming consortiums. 369 Diameter Agent 370 A Diameter Agent is a host that is providing either server, relay, 371 proxy or redirector services. 373 Diameter Client 374 A Diameter Client is a device at the edge of the network that 375 performs access control. An example of a Diameter client is a 376 Network Access Server (NAS) or a Foreign Agent (FA). 378 Diameter Node 379 A Diameter node is a host that implements the Diameter protocol, 380 and acts either as a Client, or as a Proxy, Redirector, Server or 381 Translation agent. 383 Diameter Server 384 A Diameter Server is one that handles authentication, 385 authorization and accounting requests for a particular realm. By 386 its very nature, a Diameter Server MUST support Diameter 387 applications in addition to the base protocol. 389 Downstream Server 390 Diameter Proxy servers identify a downstream server as one that is 391 providing routing services towards the Diameter client. 393 Home Domain 394 A Home Domain is the administrative domain with whom the user 395 maintains an account relationship. 397 Home Server 398 See Diameter Server. 400 Interim accounting 401 An interim accounting message provides a snapshot of usage during 402 a user's session. It is typically implemented in order to provide 403 for partial accounting of a user's session in the event of a 404 device reboot or other network problem that prevents the reception 405 of a session summary message or session record. 407 Local Domain 408 A local domain is the administrative domain providing services to 409 a user. An administrative domain MAY act as a local domain for 410 certain users, while being a home domain for others. 412 Network Access Identifier 413 The Network Access Identifier, or NAI [3], is used in the Diameter 414 protocol to extract a user's identity and realm. The identity is 415 used to identify the user during authentication and/or 416 authorization, while the realm is used for message routing 417 purposes. 419 Proxy 420 In addition to forwarding requests and responses, proxies enforce 421 policies relating to resource usage and provisioning. This is 422 typically accomplished by tracking the state of NAS devices. While 423 proxies typically do not respond to client Requests prior to 424 receiving a Response from the server, they may originate Reject 425 messages in cases where policies are violated. As a result, 426 proxies need to understand the semantics of the messages passing 427 through them, and may not support all Diameter applications. 429 Realm 430 The string in the NAI that immediately follows the '@' character. 431 NAI realm names are required to be unique, and are piggybacked on 432 the administration of the DNS namespace. Diameter makes use of the 433 realm, also loosely referred to as domain, to determine whether 434 messages can be satisfied locally, or whether they must be 435 proxied. 437 Real-time Accounting 438 Real-time accounting involves the processing of information on 439 resource usage within a defined time window. Time constraints are 440 typically imposed in order to limit financial risk. 442 Relay 443 Relays forward requests and responses based on routing-related 444 AVPs and domain forwarding table entries. Since relays do not 445 enforce policies, they do not examine or alter non-routing AVPs. 446 As a result, relays never originate messages, do not need to 447 understand the semantics of messages or non-routing AVPs, and are 448 capable of handling any Diameter applications or message type. 449 Since relays make decisions based on information in routing AVPs 450 and domain forwarding tables they do not keep state on NAS 451 resource usage or conversations in progress. 453 Redirector 454 Rather than forwarding requests and responses between clients and 455 servers, Re-directs refer clients to servers and allow them to 456 communicate directly. Since Re-directs do not sit in the 457 forwarding path, they do not alter any AVPs transitting between 458 client and server. Re-direct proxies do not originate messages and 459 are capable of handling any message type, although they may be 460 configured only to re-direct messages of certain types, while 461 acting as Routing or Policy proxies for other types. As with 462 Routing proxies, re-directs do not keep state with respect to 463 conversations or NAS resources. 465 Roaming Relationships 466 Roaming relationships include relationships between companies and 467 ISPs, relationships among peer ISPs within a roaming association, 468 and relationships between an ISP and a roaming consortia. 469 Together, the set of relationships forming a path between a local 470 ISP's authentication proxy and the home authentication server is 471 known as the roaming relationship path. 473 Session 474 The Diameter protocol is session based. When an authorization 475 request is initially transmitted, it includes a session identifier 476 that is used for the duration of the session. The Session- 477 Identifier AVP contains the identifier and must be globally 478 unique. 480 Upstream Server 481 Diameter Proxy servers identify an upstream server as one that is 482 providing routing services towards the home server for a 483 particular message. 485 2.0 Protocol Overview 487 The base Diameter protocol is never used on its own. It is always 488 extended for a particular application. Three Diameter applications 489 are defined by companion documents: NASREQ [7], Mobile IP [10], CMS 490 Security [11]. These options are introduced in this document but 491 specified elsewhere. Additional Diameter applications MAY be defined 492 in the future (see Section 11.3). 494 Diameter Clients MUST support the base protocol, which includes 495 accounting. In addition, they MUST fully support each Diameter 496 application which is needed to implement the client's service, e.g. 497 NASREQ and/or Mobile IP. A Diameter Client which does not support 498 both NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" 499 where X is the application which it supports, and not a "Diameter 500 Client." 502 Diameter Servers must support the base protocol, which includes 503 accounting. In addition, they MUST fully support each Diameter 504 application which is needed to implement the intended service, e.g. 505 NASREQ and/or Mobile IP. A Diameter Server which does not support 506 both NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" 507 where X is the application which it supports, and not a "Diameter 508 Server." 510 Diameter Relays and Redirectors are, by definition, protocol 511 transparent, and MUST transparently support the Diameter base 512 protocol, which includes accounting, and all Diameter applications. 514 Diameter Proxies MUST support the base protocol, which includes 515 accounting. in addition, they MUST fully support each Diameter 516 application which is needed to implement proxied services, e.g. 517 NASREQ and/or Mobile IP. A Diameter Proxy which does not support also 518 both NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" 519 where X is the application which it supports, and not a "Diameter 520 Proxy." 522 The CMS Diameter security application [11] contains two features: 523 1. A set of messages that allows a Diameter node to establish a 524 security association, which is used to secure AVPs within a 525 Diameter message, even though the message may traverse 526 intermediate Diameter agents. A set of AVPs are also defined to 527 sign and encrypt AVPs, as well as to transport certificates. 528 This feature MUST be supported by Diameter server and proxy 529 agents, SHOULD be supported by Diameter clients, and MAY be 530 supported by relay and redirector agents. 531 2. A set of messages, known as PDSR and PDSA, allows a Diameter 532 client to request that an agent establish a Diameter security 533 association with a server in a specific realm. This feature 534 MUST be supported by Diameter clients and Proxy agents, and MAY 535 be supported by Diameter servers, relay and redirector agents. 537 The base Diameter protocol concerns itself with capabilities 538 negotiation, and how messages are sent and how peers may eventually 539 be abandoned. The base protocol also defines certain rules which 540 apply to all exchanges of messages between Diameter peers. 542 Communication between Diameter peers begins with one peer sending a 543 message to another Diameter peer. The set of AVPs included in the 544 message is determined by a particular Diameter application. One AVP 545 that is included to reference a user's session is the Session-Id. 547 The initial request for authentication and/or authorization of a user 548 would include the Session-Id. The Session-Id is then used in all 549 subsequent messages to identify the user's session (see section 8.0 550 for more information). The communicating party may accept the 551 request, or reject it by returning an answer message with Result-Code 552 AVP set to indicate an error occurred. The specific behavior of the 553 diameter server or client receiving a request depends on the Diameter 554 application employed. 556 Session state (associated with a Session-Id) MUST be freed upon 557 receipt of the Session-Termination-Request, Session-Termination- 558 Answer, expiration of authorized service time in the Session-Timeout 559 AVP, and according to rules established in a particular Diameter 560 application. 562 The Diameter base protocol provides the Authorization-Lifetime AVP, 563 which MAY be used by applications to specify the duration of a 564 specific authorized session. 566 2.1 Transport 568 The base Diameter protocol is run on port TBD of both TCP [27] and 569 SCTP [26] transport protocols (for interoperability test purposes 570 port 1812 will be used until IANA assigns a port to the protocol). 571 When used with TLS [38], The Diameter protocol is run on port TBD of 572 both TCP and SCTP. 574 Diameter clients MUST support either TCP or SCTP, while agents and 575 servers MUST support both. Future versions of this specification MAY 576 mandate that clients support SCTP. 578 A Diameter node MAY initiate connections from any source port, but 579 MUST be prepared to receive connections on port TBD. Note that the 580 source and destination addresses used in request and replies MAY any 581 of a peer's valid IP addresses. 583 A given Diameter process SHOULD use the same port number to send all 584 messages to aid in identifying which process sent a given message. 585 More than one Diameter process MAY exist within a single host, so the 586 sender's port number is needed to discriminate them. 588 When no transport connection exists with a peer, an attempt to 589 connect SHOULD be periodically attempted. This behavior is handled 590 via the Tc timer, whose recommended value is 30 seconds. 592 When connecting to a peer, and either zero or more transports are 593 specified, SCTP SHOULD be tried first, followed by TCP. See section 594 5.2 for more information on peer discovery. 596 Diameter implementations SHOULD be able to interpret ICMP protocol 597 and port unreachable messages as explicit indications that the server 598 is not reachable, in addition to interpreting ECONNREFUSED (a reset 599 from the transport) and timed-out connection attempts. 601 2.1.1 SCTP Guidelines 603 The following are guidelines for Diameter implementations that 604 support SCTP: 606 1. For interoperability: All Diameter nodes MUST be prepared to 607 receive Diameter messages on any SCTP stream in the 608 association. 609 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 610 streams available to the association to prevent head-of-the- 611 line blocking. 613 2.2 Securing Diameter Messages 615 Diameter clients, such as Network Access Servers (NASes) and Foreign 616 Agents MUST support IP Security [37], and MAY support TLS [38]. 617 Diameter servers MUST support TLS, but the administrator MAY opt to 618 configure IPSec instead of using TLS. Operating the Diameter protocol 619 without any security mechanism is not recommended. 621 2.3 Diameter Protocol Extensibility 623 There are various ways the Diameter protocol can be extended. This 624 section is intended to assist protocol designers in selecting the 625 best method of using the Diameter protocol. 627 2.3.1 Defining new AVP Values 629 Defining a new AVP value is the best approach when a new application 630 needs to make use of an existing Diameter application, but requires 631 that an existing AVP communicate different service-specific 632 information (e.g. NAS-Port-Type set to avian carriers). 634 When an existing AVP can be used to communicate the new information, 635 this approach is preferred over creating new AVPs. 637 In order to allocate a new AVP value, a request MUST be sent to IANA, 638 with a detailed explanation of the value. Furthermore, if the command 639 code on which the AVP value is to be used would require a different 640 set of mandatory AVPs be present, the list of AVPs must accompany the 641 request. 643 2.3.2 Creating new AVPs 645 New AVPs may be created when a new application requiring Diameter 646 support can make use of an existing Diameter application, but 647 requires new AVPs to communicate service-specific information. 649 Prior to defining the AVP, the AVP type MUST be one of the types 650 listed in section 4.3. In the event that a logical grouping of AVPs 651 is necessary, and multiple "groups" are possible in a given command, 652 it is highly recommended that a Grouped AVP be used (see Section 653 4.5). 655 In order to create a new AVP, a request MUST be sent to IANA, with a 656 detailed explanation of the AVP, its type and possible values. 657 Furthermore, the request MUST include the commands that would make 658 use of the AVP. 660 Note that new AVPS to be used with an existing application MUST NOT 661 be defined to have the 'M'andatory bit set. 663 2.3.3 Creating new Diameter Applications 665 Should a new application require Diameter support, but it cannot fit 666 within an existing application without requiring major changes to the 667 specification, it may be desirable to create a new Diameter 668 application. Major changes to an application include: 669 - Requiring a whole different set of mandatory AVPs to a command 670 - Requiring a command that has a different number of round trips 671 to satisfy a request (e.g. application foo has a command that 672 requires one round trip, but new application bar has a command 673 that requires two round trips to complete). 674 - The method used to authenticate the user is drastically 675 different from any existing application, and the authentication 676 information cannot be carried within the AVPs defined in the 677 application. 679 Note that the creation of a new application should be viewed as a 680 last resort. 682 New Diameter applications MUST define at least one Command Code, the 683 expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also 684 define new AVPs. If the Diameter application has any accounting 685 requirements, it MUST also specify the AVPs that are to be present in 686 the Diameter Accounting messages (see section 9.3). 688 When possible, a new Diameter application SHOULD attempt to re-use 689 any existing Diameter AVP, in order to reduce the possibility of 690 having multiple AVPs that carry similar information. 692 Every Diameter application specification MUST have an IANA assigned 693 Application Identifier (see section 2.4). 695 2.3.4 Application authentication procedures 697 When possible, applications SHOULD be designed such that new 698 authentication methods MAY be added without requiring changes to the 699 application. This MAY require that new AVP values be assigned to 700 represent the new authentication transform, or any other scheme that 701 produces similar results. When possible, authentication frameworks, 702 such as Extensible Authentication Protocol [25], SHOULD be used. 704 2.4 Diameter Application Compliance 706 Application Identifiers are advertised during the capabilities 707 exchange phase (see section 2.5). For a given application, there are 708 two different ways of advertising support. First, advertising support 709 of the application via the Auth-Application-Id implies that the 710 sender supports all authentication and authorization command codes, 711 and the AVPs specified in the associated ABNFs, described in the 712 specification. Second, advertising support of the application via the 713 Acct-Application-Id implies that the sender supports the Accounting 714 command codes defined in this specification, as well as the 715 accounting AVPs defined in the application's specification. 717 An implementation MAY add arbitrary AVPs to any command defined in an 718 application, including vendor-specific AVPs. However, implementations 719 that add such AVPs with the Mandatory 'M' bit set are not compliant, 720 and are at fault if the peer rejects the request. If the sender of 721 such a message wishes to provide service, it MUST resend the message 722 with the offending AVPs removed. 724 2.5 Application Identifiers 726 Each Diameter application MUST have an IANA assigned Application 727 Identifier (see section 11.3). The base protocol does not require an 728 application Identifier since its support is mandatory. During the 729 capabilities exchange, Diameter nodes inform their peers of locally 730 supported applications. Furthermore, all Diameter messages contain an 731 application identifier, which is used in the message forwarding 732 process. 734 The following Application Identifier values are defined: 736 NASREQ 1 [7] 737 End-to-End Security 2 [11] 738 Mobile-IP 4 [10] 739 Relay 0xffffffff 741 Relay and redirect agents MUST advertise the Relay application 742 identifier, while all other Diameter nodes MUST advertise locally 743 supported applications. The receiver of a Capabilities Exchange 744 message advertising Relay service MUST assume that the sender 745 supports all current and future applications. 747 Diameter relay and proxy agents are responsible for finding an 748 upstream server that supports the application of a particular 749 message. If none can be found, an error message is returned with the 750 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 752 2.6 Peer Table 754 The Diameter Peer Table is used in message forwarding, and referenced 755 by the Domain Routing Table. A Peer Table entry contains the 756 following fields: 757 - Host identity. following the conventions described for the 758 DiameterIdentity derived AVP data format in section 4.4. This 759 MAY be resolved locally, or dynamically updated via the Origin- 760 Host AVP of the CER or CEA messages. 761 - Status. This is the state of the peer entry, and MUST match one 762 of the values listed in section 5.6. 763 - Role. This field specifies whether a peer is a primary, 764 secondary or alternate. 765 - Static or Dynamic. Specifies whether a peer entry was statically 766 configured, or dynamically discovered. 767 - Expiration time. Specifies the time which dynamically discovered 768 peer table entries are to be either refreshed, or expired. 769 - TLS Enabled. Specifies whether TLS is to be used when 770 communicating with the peer. 771 - Additional security information, when needed (e.g. keys, 772 certificates) 774 2.7 Realm-Based Routing Table 776 All Realm-Based routing lookups are performed against what is 777 commonly known as the Domain Routing Table (see section 12.0). A 778 Domain Routing Table Entry contains the following fields: 779 - Realm Name. This is the field that is typically used as a 780 primary key in the routing table lookups. Note that some 781 implementations perform their lookups based on longest-match- 782 from-the-right on the realm rather than requiring an exact 783 match. 784 - Application Identifier. It is possible for a route entry to have 785 a different destination based on the Acct-Application-Id (for 786 accounting messages) or Auth-Application-Id (for non-accounting 787 messages) of the message. This field is typically used as a 788 secondary key field in routing table lookups. 789 - Local Action. The Local Action field is used to identify how a 790 message should be treated. The following actions are supported: 791 1. LOCAL - Diameter messages that resolve to a route entry 792 with the Local Action set to Local can be satisfied 793 locally, and do not need to be routed to another server. 794 2. RELAY - All Diameter messages that fall within this 795 category MUST be routed to a next hop server, without 796 modifying any non-routing AVPs. See section 6.1.8 for 797 relaying guidelines 798 3. PROXY - All Diameter messages that fall within this 799 category MUST be routed to a next hop server. The local 800 server MAY apply its local policies to the message by 801 including new AVPs to the message prior to routing. See 802 section 6.1.8 for relaying guidelines. 803 4. REDIRECT - Diameter messages that fall within this 804 category MUST have the identity of the home Diameter 805 server(s) appended, and returned to the sender of the 806 message. See section 6.1.7 for redirect guidelines. 807 - Server Identifier. One or more servers the message is to be 808 routed to. These servers MUST also be present in the Peer 809 table. When the Local Action is set to RELAY or PROXY, this 810 field contains the identity of the server(s) the message must be 811 routed to. When the Local Action field is set to REDIRECT, this 812 field contains the identity of one or more servers the message 813 should be redirected to. 814 - Static or Dynamic. Specifies whether a route entry was 815 statically configured, or dynamically discovered. 816 - Expiration time. Specifies the time which dynamically discovered 817 a route table entry expire. 819 It is important to note that Diameter agents MUST support at least 820 one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents 821 do not need to support all modes of operation in order to conform 822 with the protocol specification, but MUST follow the protocol 823 compliance guidelines in section 2.0. Relay agents MUST NOT reorder 824 AVPs, and proxies SHOULD NOT reorder AVPs. 826 The routing table MAY include a default entry which MUST be used for 827 any requests not matching any of the other entries. The routing table 828 MAY consist of only such an entry. 830 When a request is routed, the target server MUST have advertised the 831 Application Identifier (see section 2.5) for the given message, or 832 have advertised itself as a relay or proxy agent. 834 2.8 Role of Diameter Agents 836 In addition to client and servers, the Diameter protocol introduces 837 relays, redirectors, proxies and translation gateways, each of which 838 is defined in Section 1.3. These Diameter agents are useful for 839 several reasons: 840 - They can distribute administration of systems to a configurable 841 grouping, including the maintenance of security associations. 842 - They can be used for concentration of requests from an number of 843 co-located or distributed NAS equipment sets to a set of like 844 user groups. 845 - They can do value-added processing to the requests or responses. 846 - They can be used for load balancing. 847 - A complex network will have multiple authentication sources, 848 they can sort requests and forward towards the correct target. 850 The Diameter protocol requires that agents maintain transaction 851 state, which is used for failover purposes. Transaction state implies 852 that upon forwarding a request, it's Hop-by-Hop identifier is saved, 853 the field is replaced with a locally unique identifier, which is 854 restored to its original value when the corresponding answer is 855 received. The request's state is released upon receipt of the answer. 856 A stateless agent is one that only maintains transaction state. 858 The Proxy-Info AVP allows stateless agents to add local state to a 859 Diameter request, with the guarantee that the same state will be 860 present in the answer. However, the protocol's failover procedures 861 require that agents maintain a copy of pending requests. 863 A stateful agent is one that maintains session state information, by 864 keeping track of all authorized active sessions. Each authorized 865 session is bound to a particular service, and its state is considered 866 active either until it is notified otherwise, or by expiration. Each 867 authorized session has a expiration, which is communicated by 868 Diameter servers via the Authorized-Lifetime AVP. 870 Maintaining session state MAY be useful in certain applications, such 871 as: 872 - Protocol translation (e.g. RADIUS <-> Diameter) 873 - Limiting resources authorized to a particular user 874 - Per user or transaction auditing 876 A Diameter agent MAY act in a stateful manner for some requests, 877 while be stateless for others. A Diameter implementation MAY act as 878 one type of agent for some requests, and as another type of agent for 879 others. 881 2.8.1 Relay Agents 883 Relay Agents are Diameter agents that accept requests and route 884 messages to other Diameter agents based on information found in the 885 messages (e.g. Destination-Realm). This routing decision is performed 886 using a list of supported domains, and known peers. This is known as 887 the Diameter Routing Table, as is defined further in section 2.7. 889 Relays MAY be used to aggregate requests from multiple Network Access 890 Servers (NASes) within a common geographical area (POP). The use of 891 Relays is advantageous since it eliminates the need for NASes to be 892 configured with the necessary security information they would 893 otherwise require to communicate with Diameter servers in other 894 realms. Likewise, this reduces the configuration load on Diameter 895 servers that would otherwise be necessary when NASes are added, 896 changed or deleted. 898 Relays modify Diameter messages by inserting, and removing, routing 899 information, but do not modify any other portion of a message. 900 Further, Relays inherent simplicity implies that they are stateless, 901 and therefore SHOULD NOT maintain session state, but MUST maintain 902 transaction state. 904 +------+ ---------> +------+ ---------> +------+ 905 | | 1. Request | | 2. Request | | 906 | NAS | | DRL | | HMS | 907 | | 4. Answer | | 3. Answer | | 908 +------+ <--------- +------+ <--------- +------+ 909 mno.net mno.net abc.com 910 Figure 1: Relaying of Diameter messages 912 The example provided in Figure 1 depicts a request issued from NAS, 913 which is an access device, for the user bob@abc.com. Prior to issuing 914 the request, NAS performs a Diameter route lookup, using "abc.com" as 915 the key, and determines that the message is to be relayed to DRL, 916 which is a Diameter Relay. DRL performs the same route lookup as NAS, 917 and relays the message to HMS, which is abc.com's Home Diameter 918 Server. HMS identifies that the request can be locally supported (via 919 the realm), processes the authentication and/or authorization 920 request, and replies with an answer, which is routed back to NAS 921 using Diameter routing AVPs. 923 Since Relays do not perform any application level processing, they 924 provide relaying services for all Diameter applications, and 925 therefore MUST advertise the Relay Application Identifier. 927 2.8.2 Proxy Agents 929 Similarly to Relays, Proxy agents route Diameter messages using the 930 Diameter Routing Table. However, they differ since they modify 931 messages to implement policy enforcement. This requires that proxies 932 maintain the state of their downstream peers (e.g. access devices) to 933 enforce resource usage, provide admission control, and provisioning. 935 It is important to note that although proxies MAY provide a value-add 936 function for NASes, they do not allow access devices to use the 937 Diameter CMS Security application, since modifying messages breaks 938 authentication. 940 Proxies MAY be used in call control centers or access ISPs that 941 provide outsourced connections, they can monitor the number and types 942 of ports in use, and make allocation and admission decisions 943 according to their configuration. 945 Proxies that wish to limit resources MUST be stateful, and all 946 Proxies MUST maintain transaction state. 948 Proxy agents MUST NOT allow CMS security to be established between 949 two peers if it expects to modify ANY non-routing AVP in messages 950 exchanged between the peers. See [11] for more information. 952 Since enforcing policies requires an understanding of the service 953 being provided, Proxies MUST only advertise the Diameter applications 954 they support. 956 2.8.3 Redirector Agents 958 Redirector agents provide Realm to Server address resolution, and use 959 the Diameter routing table to determine where a given request should 960 be forwarded. When a request is received by a Diameter redirector, a 961 special answer is created, which includes the identity of the 962 Diameter server(s) the originator of the request should contact 963 directly. 965 Redirectors are useful in scenarios where the Diameter routing 966 configuration needs to be centralized. An example is a redirector 967 that provides services to all members of a consortium, but does not 968 wish to be burdened with relaying all messages between domains. This 969 scenario is advantageous since it does not require that the 970 consortium provide routing updates to its members when changes are 971 made to a member's infrastructure. 973 Since redirectors do not relay messages, and only return an answer 974 with the information necessary for Diameter agents to communicate 975 directly, they do not modify messages. Since redirectors do not 976 receive answer messages, they cannot maintain session state. 977 Further, since redirectors never relay requests, they are not 978 required to maintain transaction state. 980 The example provided in Figure 2 depicts a request issued from the 981 access device, NAS, for the user bob@abc.com. The message is 982 forwarded by the NAS to its relay, DRL, which does not have a routing 983 entry in its Diameter Routing Table for abc.com. DRL has a default 984 route configured to DRD, which is a redirector that returns a 985 redirect notification to DRL, as well as HMS' contact information. 986 Upon receipt of the redirect notification, DRL establishes a 987 transport connection with HMS, if one doesn't already exist, and 988 forwards the request to it. 990 +------+ 991 | | 992 | DRD | 993 | | 994 +------+ 995 ^ | 996 2. Request | | 3. Redirection 997 | | Notification 998 | v 999 +------+ ---------> +------+ ---------> +------+ 1000 | | 1. Request | | 4. Request | | 1001 | NAS | | DRL | | HMS | 1002 | | 6. Answer | | 5. Answer | | 1003 +------+ <--------- +------+ <--------- +------+ 1004 mno.net mno.net abc.com 1005 Figure 2: Redirecting a Diameter Message 1007 Since Redirectors do not perform any application level processing, 1008 they provide relaying services for all Diameter applications, and 1009 therefore MUST advertise the Relay Application Identifier. 1011 2.8.4 Translation Agents 1013 A Translation Agent is a device that provides translation between two 1014 protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation 1015 agents are likely to be used as aggregation servers to communicate 1016 with a Diameter infrastructure, while allowing for the embedded 1017 systems to be migrated at a slower pace. 1019 Given that the Diameter protocol introduces the concept of long-lived 1020 authorized sessions, translation agents MUST be stateful and MUST 1021 maintain transaction state. 1023 Translation of messages can only occur if the agent recognizes the 1024 application of a particular request, and therefore MUST only 1025 advertise their locally supported applications. 1027 +------+ ---------> +------+ ---------> +------+ 1028 | | RADIUS Request | | Diameter Request | | 1029 | NAS | | TLA | | HMS | 1030 | | RADIUS Answer | | Diameter Answer | | 1031 +------+ <--------- +------+ <--------- +------+ 1032 mno.net mno.net abc.com 1033 Figure 3: Translation of RADIUS to Diameter 1035 3.0 Diameter Header 1037 A summary of the Diameter header format is shown below. The fields 1038 are transmitted in network byte order. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Ver | Message Length | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |R P E r r r r r| Command-Code | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Vendor-ID | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Hop-by-Hop Identifier | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | End-to-End Identifier | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | AVPs ... 1054 +-+-+-+-+-+-+-+-+-+-+-+-+- 1056 Version 1057 This Version field MUST be set to 1 to indicate Diameter Version 1058 1. 1060 Message Length 1061 The Message Length field is three octets and indicates the length 1062 of the Diameter message including the header fields. 1064 Command Flags 1065 The Command Flags field is eight bits. The following bits are 1066 assigned: 1068 R(equest) - If set, the message is a request. If cleared, the 1069 message is an answer. 1070 P(roxiable) - If set, the message MAY be proxied. If cleared, 1071 the message MUST be locally processed. 1073 E(rror) - If set, the message contains a protocol error, 1074 and the message will not conform to the ABNF 1075 described for this command. Messages with the 1076 'E' bit set is commonly referred to as an error 1077 message. This bit MUST NOT be set in request 1078 messages. See section 7.2. 1079 r(eserved) - this flag bit is reserved for future use, and 1080 MUST be set to zero. 1082 Command-Code 1083 The Command-Code field is three octets, and is used in order to 1084 communicate the command associated with the message. The 24-bit 1085 address space is managed by IANA (see section 11.2). 1087 Vendor-ID 1088 In the event that the Command-Code field contains a vendor 1089 specific command, the four octet Vendor-ID field contains the IANA 1090 assigned "SMI Network Management Private Enterprise Codes" [2] 1091 value. If the Command-Code field contains an IETF standard 1092 Command, the Vendor-ID field MUST be set to zero (0). Any vendor 1093 wishing to implement a vendor-specific Diameter command MUST use 1094 their own Vendor-ID along with their privately managed Command- 1095 Code address space, guaranteeing that they will not collide with 1096 any other vendor's vendor-specific command, nor with future IETF 1097 applications. 1099 Hop-by-Hop Identifier 1100 The Hop-by-Hop Identifier field is four octets, and aids in 1101 matching requests and replies. The sender MUST ensure that the 1102 Hop-by-Hop identifier in a request is locally unique (to the 1103 sender) at any given time, and MAY attempt to ensure that the 1104 number is unique across reboots. The sender of an Answer message 1105 MUST ensure that the Hop-by-Hop Identifier field contains the same 1106 value that was found in the corresponding request. The Hop-by-Hop 1107 identifier is normally a monotonically increasing number, whose 1108 start value was randomly generated. An answer message that is 1109 received with an unknown Hop-by-Hop Identifier MUST be discarded. 1111 End-to-End Identifier 1112 The End-to-End Identifier is used to detect duplicate messages. 1113 Upon reboot, the high order 12 bits are initiated to contain the 1114 low order 12 bits of current time, while the low order 20 bits is 1115 set to a random value. Senders of request or answer messages MUST 1116 insert a unique identifier on each message, by incrementing the 1117 identifier by one (1). The End-to-End Identifier MUST NOT be 1118 modified by relay agents. The combination of the Origin-Host and 1119 this field is used to detect duplicates. Duplicate answer messages 1120 that are to be locally consumed (see Section 6.2) SHOULD be 1121 silently discarded. 1123 AVPs 1124 AVPs are a method of encapsulating information relevant to the 1125 Diameter message. See section 4. for more information on AVPs. 1127 3.1 Command Codes 1129 Each command Request/Answer pair is assigned a command code, and the 1130 sub-type (e.g. request or answer) is identified via the 'R' bit in 1131 the Command Flags field of the Diameter header. 1133 Every Diameter message MUST contain a command code in its header's 1134 Command-Code field, which is used to determine the action that is to 1135 be taken for a particular message. The following Command Codes are 1136 defined in the Diameter base protocol: 1138 Command-Name Abbrev. Code Reference 1139 -------------------------------------------------------- 1140 Abort-Session-Request ASR 274 8.5.1 1141 Abort-Session-Answer ASA 274 8.5.2 1142 Accounting-Request ACR 271 9.7.1 1143 Accounting-Answer ACA 271 9.7.2 1144 Capabilities-Exchange- CER 257 5.3.1 1145 Request 1146 Capabilities-Exchange- CEA 257 5.3.2 1147 Answer 1148 Device-Watchdog-Request DWR 280 5.5.1 1149 Device-Watchdog-Answer DWA 280 5.5.2 1150 Disconnect-Peer-Request DPR 282 5.4.1 1151 Disconnect-Peer-Answer DPA 282 5.4.2 1152 Re-Auth-Request RAR 258 8.3.1 1153 Re-Auth-Answer RAA 258 8.3.2 1154 Session-Termination- STR 275 8.4.1 1155 Request 1156 Session-Termination- STA 275 8.4.2 1157 Answer 1159 3.2 Command Code ABNF specification 1161 Every Command Code defined MUST include a corresponding ABNF 1162 specification, which is used to define the AVPs that MUST or MAY be 1163 present. The following format is used in the definition: 1165 command-def = command-name "::=" diameter-message 1166 diameter-name = ALPHA *(ALPHA / DIGIT / "-") 1168 command-name = diameter-name 1169 ; The command-name has to be Command name, 1170 ; defined in the base or extended Diameter 1171 ; specifications. 1173 diameter-message = header [ *fixed] [ *required] [ *optional] 1174 [ *fixed] 1176 header = "< Diameter-Header:" command-id [r-bit] 1177 [p-bit] [e-bit] ">" 1179 command-id = 1*DIGIT 1180 ; The Command Code assigned to the command 1182 r-bit = ", REQ" 1183 ; If present, the 'R' bit in the Command 1184 ; Flags is set, indicating that the message 1185 ; is a request, as opposed to an answer. 1187 p-bit = ", PXY" 1188 ; If present, the 'P' bit in the Command 1189 ; Flags is set, indication that the message 1190 ; is proxiable. 1192 e-bit = ", ERR" 1193 ; If present, the 'E' bit in the Command 1194 ; Flags is set, indication that the answer 1195 ; message contains a Result-Code AVP in 1196 ; the "protocol error" class. 1198 fixed = [qual] "<" avp-spec ">" 1199 ; Defines the fixed position of an AVP 1201 required = [qual] "{" avp-spec "}" 1202 ; The AVP MUST be present 1204 optional = [qual] "[" avp-name "]" 1205 ; The avp-name in the 'optional' rule cannot 1206 ; evaluate to any AVP Name which is included 1207 ; in a fixed or required rule. 1209 qual = [min] "*" [max] 1210 ; See ABNF conventions, RFC 2234 section 6.6. 1211 ; The absence of any qualifiers implies that 1212 ; one and only one such AVP MUST be present. 1213 ; 1214 ; NOTE: "[" and "]" have a different meaning 1215 ; than in ABNF (see the optional rule, above). 1216 ; These braces cannot be used to express 1217 ; optional fixed rules (such as an optional 1218 ; ICV at the end.) To do this, the convention 1219 ; is '0*1fixed'. 1221 min = 1*DIGIT 1222 ; The minimum number of times the element may 1223 ; be present. The default value is zero. 1225 max = 1*DIGIT 1226 ; The maximum number of times the element may 1227 ; be present. The default value is infinity. 1229 avp-spec = diameter-name 1230 ; The avp-spec has to be an AVP Name, defined 1231 ; in the base or extended Diameter 1232 ; specifications. 1234 avp-name = avp-spec | "AVP" 1235 ; The string "AVP" stands for *any* arbitrary 1236 ; AVP Name, which does not conflict with the 1237 ; required or fixed position AVPs defined in 1238 ; the command code definition. 1240 The following is a definition of a fictitious command code: 1242 Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > 1243 { User-Name } 1244 * { Origin-Host } 1245 * [ AVP ] 1247 3.3 Diameter Command Naming Conventions 1249 The following conventions are required for the naming of Diameter 1250 messages. Diameter commands typically start with an object name, and 1251 end with either the Request or Answer verb. 1253 The Request/Answer message pair is used when a Diameter node requests 1254 that some action be performed by a peer (e.g. authorize a user, 1255 terminate a session). The corresponding answer MUST contain either a 1256 positive or negative result code, informing the requester whether the 1257 request was successful or not. Other information MAY also be returned 1258 in the Answer message. 1260 Request and Answer messages share the same command code, and the 1261 R(equest) bit in the Diameter header is used to identify whether a 1262 message is the request or answer. 1264 4.0 Diameter AVPs 1266 Diameter AVPs carry specific authentication, accounting and 1267 authorization information, security information as well as 1268 configuration details for the request and reply. 1270 Some AVPs MAY be listed more than once. The effect of such an AVP is 1271 specific, and is specified in each case by the AVP description. 1273 Each AVP of type OctetString MUST be padded to align on a 32 bit 1274 boundary, while other AVP types align naturally. NULL bytes are added 1275 to the end of the AVP Data field till a word boundary is reached. The 1276 length of the padding is not reflected in the AVP Length field. 1278 4.1 AVP Header 1280 The fields in the AVP header MUST be sent in network byte order. The 1281 format of the header is: 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | AVP Code | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 |V M P r r r r r| AVP Length | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Vendor-ID (opt) | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Data ... 1293 +-+-+-+-+-+-+-+-+ 1295 AVP Code 1296 The AVP Code, combined with the Vendor-Id field, identifies the 1297 attribute uniquely. The first 256 AVP numbers are reserved for 1298 backward compatibility with RADIUS and are to be interpreted as 1299 per NASREQ [7]. AVP numbers 256 and above are used for Diameter, 1300 which are allocated by IANA (see section 11.1). 1302 AVP Flags 1303 The AVP Flags field informs the receiver how each attribute must 1304 be handled. The 'r' (reserved) bits are unused and SHOULD be set 1305 to 0. Note that subsequent Diameter applications MAY define 1306 additional bits within the AVP Header, and an unrecognized bit 1307 SHOULD be considered an error. The 'P' bit is defined in [11]. 1309 The 'M' Bit, known as the Mandatory bit, indicates whether support 1310 of the AVP is required. If an unrecognized AVP with the 'M' bit 1311 set is received by a Diameter node, the message MUST be rejected. 1312 Diameter Relay and Redirector agents MUST NOT reject messages with 1313 unrecognized AVPs. 1315 A Diameter node that sets the 'M' bit in an AVP that is not 1316 defined in a given message's ABNF is at fault if the message is 1317 rejected. In order to provide service to the user, the node at 1318 fault MUST re-issue a request either without the AVP, or without 1319 setting its 'M' bit. 1321 A Diameter node that rejects a message due to an unrecognized AVP 1322 with the 'M' bit set, and the AVP in question is defined in the 1323 message's ABNF is at fault. In most cases the initiator of the 1324 failing request will not provide service to the user. 1326 AVPs with the 'M' bit cleared are informational only and a 1327 receiver that receives a message with such an AVP that is not 1328 supported MAY simply ignore the AVP. 1330 The 'V' bit, known as the Vendor-Specific bit, indicates whether 1331 the optional Vendor-ID field is present in the AVP header. When 1332 set the AVP Code belongs to the specific vendor code address 1333 space. 1335 Unless otherwise noted, AVPs will have the following default AVP 1336 Flags field settings: 1337 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 1339 AVP Length 1340 The AVP Length field is three octets, and indicates the length of 1341 this AVP including the AVP Code, AVP Length, AVP Flags, Reserved, 1342 the Vendor-ID field (if present) and the AVP data. If a message is 1343 received with an invalid attribute length, the message SHOULD be 1344 rejected. 1346 4.2 Optional Header Elements 1348 The AVP Header contains one optional field. This field is only 1349 present if the respective bit-flag is enabled. 1351 Vendor-ID 1352 The Vendor-ID field is present if the 'V' bit is set in the AVP 1353 Flags field. The optional four octet Vendor-ID field contains the 1354 IANA assigned "SMI Network Management Private Enterprise Codes" 1355 [2] value, encoded in network byte order. Any vendor wishing to 1356 implement a vendor-specific Diameter AVP MUST use their own 1357 Vendor-ID along with their privately managed AVP address space, 1358 guaranteeing that they will not collide with any other vendor's 1359 vendor-specific AVP, nor with future IETF applications. 1361 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 1362 values, as managed by the IANA. Since the absence of the vendor ID 1363 field implies that the AVP in question is not vendor specific, 1364 implementations SHOULD not use the zero (0) vendor ID. 1366 4.3 AVP Base Data Format 1368 The Data field is zero or more octets and contains information 1369 specific to the Attribute. The format and length of the Data field is 1370 determined by the AVP Code and AVP Length fields. The format of the 1371 Data field MUST be one of the following base data types or a data 1372 type derived from the base data types. In the event that a new AVP 1373 Base Data Format is needed, a new version of this RFC must be 1374 created. 1376 OctetString 1377 The data contains arbitrary data of variable length. Unless 1378 otherwise noted, the AVP Length field MUST be set to at least 8 1379 (12 if the 'V' bit is enabled). AVP Values of this type that 1380 do not align on a 32-bit boundary MUST have the necessary 1381 padding. 1383 Integer32 1384 32 bit signed value, in network byte order. The AVP Length 1385 field MUST be set to 12 (16 if the 'V' bit is enabled). 1387 Integer64 1388 64 bit signed value, in network byte order. The AVP Length 1389 field MUST be set to 16 (20 if the 'V' bit is enabled). 1391 Unsigned32 1392 32 bit unsigned value, in network byte order. The AVP Length 1393 field MUST be set to 12 (16 if the 'V' bit is enabled). 1395 Unsigned64 1396 64 bit unsigned value, in network byte order. The AVP Length 1397 field MUST be set to 16 (20 if the 'V' bit is enabled). 1399 Float32 1400 This represents floating point values of single precision as 1401 described by [30]. The 32 bit value is transmitted in network 1402 byte order. The AVP Length field MUST be set to 12 (16 if the 1404 Float64 1405 This represents floating point values of double precision as 1406 described by [30]. The 64 bit value is transmitted in network 1407 byte order. The AVP Length field MUST be set to 16 (20 if the 1409 Float128 1410 This represents floating point values of quadruple precision as 1411 described by [30]. The 128 bit value is transmitted in network 1412 byte order. The AVP Length field MUST be set to 24 (28 if the 1414 Grouped 1415 The Data field is specified as a sequence of AVPs. Each of 1416 these AVPs follows - in the order in which they are specified - 1417 including their headers and padding. The AVP Length field is 1418 set to 8 (12 if the 'V' bit is enabled) plus the total length 1419 of all included AVPs, including their headers and padding. 1421 4.4 Derived AVP Data Formats 1423 In addition to the AVP Base Data Formats, applications may define 1424 data formats derived from the AVP Base Data Formats. New AVP Derived 1425 Data Formats MUST be registered with IANA. 1427 An application that uses AVP Derived Data Formats other than those 1428 defined in the base protocol MUST have a section "AVP Derived Data 1429 Formats" that includes each of these formats. In that section, each 1430 format is either defined or listed with a reference to the RFC that 1431 defines this format. If the AVP Derived Data Format is defined, it 1432 SHOULD use a format similar to the format definitions below. 1434 The below AVP Derived DATA Formats are commonly used by applications. 1436 IPAddress 1437 The IPAddress format is derived from the OctetString AVP Base 1438 Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] 1439 address, most significant octet first. The format of the 1440 address (IPv4 or IPv6) is determined by the length. If the 1441 attribute value is an IPv4 address, the AVP Length field MUST 1442 be 12 (16 if 'V' bit is enabled), otherwise the AVP Length 1443 field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 1444 addresses. 1446 Time 1447 The Time format is derived from the Unsigned32 AVP Base Format. 1449 This is 32 bit unsigned value containing the four most 1450 significant octets returned from NTP [18], in network byte 1451 order. 1453 This represent the number of seconds since 0h on 1 January 1900 1454 with respect to the Coordinated Universal Time (UTC). 1456 On 6h 28m 16s UTC, 7 February 2036 the time value will 1457 overflow. NTP [18] describes a procedure to extend the time to 1458 2104. 1460 UTF8String 1461 The UTF8String format is derived from the OctetString AVP Base 1462 Format. This is a human readable string represented using the 1463 ISO/IEC IS 10646-1 character set, encoded as an OctetString 1464 using the UTF-8 [29] transformation format described in RFC 1465 2279. 1467 Since additional code points are added by amendments to the 1468 10646 standard from time to time, implementations MUST be 1469 prepared to encounter any code point from 0x00000001 to 1470 0x7fffffff. Byte sequences that do not correspond to the valid 1471 UTF-8 encoding of a code point or are outside this range are 1472 prohibited. Note that since a code point of 0x00000000 is 1473 prohibited, no octet will contain a value of 0x00. 1475 The use of control codes SHOULD be avoided. When it is 1476 necessary to represent a newline, the control code sequence CR 1477 LF SHOULD be used. 1479 The use of leading or trailing white space SHOULD be avoided. 1481 For code points not directly supported by user interface 1482 hardware or software, an alternative means of entry and 1483 display, such as hexadecimal, MAY be provided. 1485 For information encoded in 7-bit US-ASCII, the UTF-8 encoding 1486 is identical to the US-ASCII encoding. 1488 UTF-8 may require multiple bytes to represent a single 1489 character / code point; thus the length of a UTF8String in 1490 octets may be different from the number of characters encoded. 1492 Note that the size of an UTF8String is measured in octets, not 1493 characters. 1495 The UTF8String MUST not contain any octets with a value of 1496 zero. 1498 DiameterIdentity 1499 The DiameterIdentity format is derived from the OctetString AVP 1500 Base Format. It uses the UTF-8 encoding and has the same 1501 requirements as the UTF8String. In addition, it must follow 1502 the Uniform Resource Identifiers (URI) syntax [29] rules 1503 specified below: 1505 Diameter-Identity = fqdn [ port ] [ transport ] 1506 [ protocol ] 1508 aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) 1510 protocol = ";protocol=" aaa-protocol 1511 ; If absent, the default AAA protocol 1512 ; is diameter. 1514 fqdn = Fully Qualified Host Name 1516 port = ":" 1*DIGIT 1517 ; One of the ports used to listen for 1518 ; incoming connections. ; If absent, 1519 ; the default Diameter port (TBD) is 1520 ; assumed. 1522 transport-protocol = ( "tcp" | "sctp" | "udp" ) 1524 transport = ";transport=" transport-protocol 1526 ; One of the transports used to listen 1527 ; for incoming connections. If absent, 1528 ; the default SCTP [26] protocol is 1529 ; assumed. UDP MUST NOT be used when 1530 ; the aaa-protocol field is set to 1531 ; diameter. 1533 The following are examples of valid Diameter host 1534 identities: 1536 host.abc.com;transport=tcp 1537 host.abc.com:6666;transport=tcp 1538 aaa://host.abc.com;protocol=diameter 1539 aaa://host.abc.com:6666;protocol=diameter 1540 aaa://host.abc.com:6666;transport=tcp;protocol=diameter 1541 aaa://host.abc.com:1813;transport=udp;protocol=radius 1543 Since multiple Diameter processes on a single host cannot 1544 listen for incoming connections on the same port on a given 1545 protocol, the DiameterIdentity is guaranteed to be unique per 1546 host. 1548 A Diameter node MAY advertise different identities on each 1549 connection, via the CER and CEA's Origin-Host AVP, but the same 1550 identity MUST be used throughout the duration of a connection. 1552 When comparing AVPs of this format, it is necessary to add any 1553 absent fields with the default values prior to the comparison. 1554 For example, diameter-host.abc.com would be expanded to 1555 aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. 1557 Enumerated 1558 Enumerated is derived from the Integer32 AVP Base Format. This 1559 contains a list of valid values and their interpretation and is 1560 described in the Diameter application introducing the AVP. 1562 IPFilterRule 1563 The IPFilterRule format is derived from the OctetString AVP 1564 Base Format. It uses the UTF-8 encoding and has the same 1565 requirements as the UTF8String. Packets may be filtered based 1566 on the following information that is associated with it: 1568 Direction (in or out) 1569 Source and destination IP address (possibly masked) 1570 Protocol 1571 Source and destination port (lists or ranges) 1572 TCP flags 1573 IP fragment flag 1574 IP options 1575 ICMP types 1577 Rules for the appropriate direction are evaluated in order, 1578 with the first matched rule terminating the evaluation. Each 1579 packet is evaluated once. If no rule matches, the packet is 1580 dropped if the last rule evaluated was a permit, and passed if 1581 the last rule was a deny. 1583 IPFilterRule filters MUST follow the format: 1585 action dir proto from src to dst [options] 1587 action permit - Allow packets that match the rule. 1588 deny - Drop packets that match the rule. 1590 dir "in" is from the terminal, "out" is to the 1591 terminal. 1593 proto An IP protocol specified by number. The "ip" 1594 keyword means any protocol will match. 1596 src and dst
[ports] 1598 The
may be specified as: 1599 ipno An IPv4 or IPv6 number in dotted- 1600 quad or canonical IPv6 form. Only 1601 this exact IP number will match the 1602 rule. 1603 ipno/bits An IP number as above with a mask 1604 width of the form 1.2.3.4/24. In 1605 this case all IP numbers from 1606 1.2.3.0 to 1.2.3.255 will match. 1607 The bit width MUST be valid for the 1608 IP version and the IP number MUST 1609 NOT have bits set beyond the mask. 1611 The sense of the match can be inverted by 1612 preceding an address with the not modifier, 1613 causing all other addresses to be matched 1614 instead. This does not affect the selection of 1615 port numbers. 1617 The keyword "any" is 0.0.0.0/0 or the IPv6 1618 equivalent. The keyword "assigned" is the 1619 address or set of addresses assigned to the 1620 terminal. The first rule SHOULD be "deny in 1621 ip !assigned". 1623 With the TCP, UDP and SCTP protocols, optional 1624 ports may be specified as: 1626 {port|port-port}[,port[,...]] 1628 The `-' notation specifies a range of ports 1629 (including boundaries). 1631 Fragmented packets which have a non-zero offset 1632 (i.e. not the first fragment) will never match 1633 a rule which has one or more port 1634 specifications. See the frag option for 1635 details on matching fragmented packets. 1637 options: 1638 frag Match if the packet is a fragment and this is not 1639 the first fragment of the datagram. frag may not 1640 be used in conjunction with either tcpflags or 1641 TCP/UDP port specifications. 1643 ipoptions spec 1644 Match if the IP header contains the comma 1645 separated list of options specified in spec. The 1646 supported IP options are: 1648 ssrr (strict source route), lsrr (loose source 1649 route), rr (record packet route) and ts 1650 (timestamp). The absence of a particular option 1651 may be denoted with a `!'. 1653 tcpoptions spec 1654 Match if the TCP header contains the comma 1655 separated list of options specified in spec. The 1656 supported TCP options are: 1658 mss (maximum segment size), window (tcp window 1659 advertisement), sack (selective ack), ts (rfc1323 1660 timestamp) and cc (rfc1644 t/tcp connection 1661 count). The absence of a particular option may 1662 be denoted with a `!'. 1664 established 1665 TCP packets only. Match packets that have the RST 1666 or ACK bits set. 1668 setup TCP packets only. Match packets that have the SYN 1669 bit set but no ACK bit. 1671 tcpflags spec 1672 TCP packets only. Match if the TCP header 1673 contains the comma separated list of flags 1674 specified in spec. The supported TCP flags are: 1676 fin, syn, rst, psh, ack and urg. The absence of a 1677 particular flag may be denoted with a `!'. A rule 1678 which contains a tcpflags specification can never 1679 match a fragmented packet which has a non-zero 1680 offset. See the frag option for details on 1681 matching fragmented packets. 1683 icmptypes types 1684 ICMP packets only. Match if the ICMP type is in 1685 the list types. The list may be specified as any 1686 combination of ranges or individual types 1687 separated by commas. The supported ICMP types 1688 are: 1690 echo reply (0), destination unreachable (3), 1691 source quench (4), redirect (5), echo request 1692 (8), router advertisement (9), router 1693 solicitation (10), time-to-live exceeded (11), IP 1694 header bad (12), timestamp request (13), 1695 timestamp reply (14), information request (15), 1696 information reply (16), address mask request (17) 1697 and address mask reply (18). 1699 There is one kind of packet that the access device MUST always 1700 discard, that is an IP fragment with a fragment offset of one. 1701 This is a valid packet, but it only has one use, to try to 1702 circumvent firewalls. 1704 An access device that is unable to interpret or apply a deny 1705 rule MUST terminate the session. An access device that is 1706 unable to interpret or apply a permit rule MAY apply a more 1707 restrictive rule. An access device MAY apply deny rules of 1708 its own before the supplied rules, for example to protect 1709 the access device owner's infrastructure. 1711 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 1712 and the ipfw.c code may provide a useful base for 1713 implementations. 1715 QoSFilterRule 1716 The QosFilterRule format is derived from the OctetString AVP 1717 Base Format. It uses the UTF-8 encoding and has the same 1718 requirements as the UTF8String. Packets may be marked or 1719 metered based on the following information that is associated 1720 with it: 1722 Direction (in or out) 1723 Source and destination IP address (possibly masked) 1724 Protocol 1725 Source and destination port (lists or ranges) 1726 DSCP values (no mask or range) 1728 Rules for the appropriate direction are evaluated in order, 1729 with the first matched rule terminating the evaluation. Each 1730 packet is evaluated once. If no rule matches, the packet is 1731 treated as best effort. 1733 QoSFilterRule filters MUST follow the format: 1735 action dir proto from src to dst [options] 1737 tag - Mark packet with a specific DSCP [49]. 1738 The DSCP option MUST be included. 1740 meter - Meter traffic. The metering options 1741 MUST be included. 1743 dir "in" is from the terminal, "out" is to the 1744 terminal. 1746 proto An IP protocol specified by number. The "ip" 1747 keyword means any protocol will match. 1749 src and dst
[ports] 1751 The
may be specified as: 1752 ipno An IPv4 or IPv6 number in dotted- 1753 quad or canonical IPv6 form. Only 1754 this exact IP number will match the 1755 rule. 1756 ipno/bits An IP number as above with a mask 1757 width of the form 1.2.3.4/24. In 1758 this case all IP numbers from 1759 1.2.3.0 to 1.2.3.255 will match. 1760 The bit width MUST be valid for the 1761 IP version and the IP number MUST 1762 NOT have bits set beyond the mask. 1764 The sense of the match can be inverted by 1765 preceding an address with the not modifier, 1766 causing all other addresses to be matched 1767 instead. This does not affect the selection of 1768 port numbers. 1770 The keyword "any" is 0.0.0.0/0 or the IPv6 1771 equivalent. The keyword "assigned" is the 1772 address or set of addresses assigned to the 1773 terminal. The first rule SHOULD be "deny in 1774 ip !assigned". 1776 With the TCP, UDP and SCTP protocols, optional 1777 ports may be specified as: 1779 {port|port-port}[,port[,...]] 1781 The `-' notation specifies a range of ports 1782 (including boundaries). 1784 options: 1786 DSCP 1787 color values as defined in [49]. Exact matching 1788 of DSCP values is required (no masks or ranges). 1789 the "deny" can replace the color_under or 1790 color_over values in the meter action for rate- 1791 dependent packet drop. 1793 metering 1794 The metering option provides Assured Forwarding, 1795 as defined in [50], and MUST be present if the 1796 action is set to meter. The rate option is the 1797 throughput, in bits per second, which is used by 1798 the access device to mark packets. Traffic above 1799 the rate is marked with the color_over codepoint, 1800 while traffic under the rate is marked with the 1801 color_under codepoint. The color_under and 1802 color_over options contain the drop preferences, 1803 and MUST conform to the recommended codepoint 1804 keywords described in [50] (e.g. AF13). 1806 The metering option also supports the strict 1807 limit on traffic required by Expedited 1808 Forwarding, as defined in [51]. The color_over 1809 option may contain the keyword "drop" to prevent 1810 forwarding of traffic that exceeds the rate 1811 parameter. 1813 The rule syntax is a modified subset of ipfw(8) from FreeBSD, 1814 and the ipfw.c code may provide a useful base for 1815 implementations. 1817 4.5 Grouped AVP Values 1819 The Diameter protocol allows AVP values of type 'Grouped.' This 1820 implies that the Data field is actually a sequence of AVPs. It is 1821 possible to include an AVP with a Grouped type within a Grouped type, 1822 that is, to nest them. AVPs within an AVP of type Grouped have the 1823 same padding requirements as non-Grouped AVPs, as defined in section 1824 4.0. 1826 The AVP Code numbering space of all AVPs included in a Grouped AVP is 1827 the same as for non-grouped AVPs. Further, if any of the AVPs 1828 encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, 1829 the Grouped AVP itself MUST also include the 'M' bit set. 1831 All AVPs included in a Grouped AVP Every Grouped AVP defined MUST 1832 include a corresponding grammar, using ABNF [31] (with 1833 modifications), as defined below. 1835 avp-def = name "::=" avp 1837 name-fmt = ALPHA *(ALPHA / DIGIT / "-") 1839 name = name-fmt 1840 ; The name has to be the name of an AVP, 1841 ; defined in the base or extended Diameter 1842 ; specifications. 1844 avp = header [ *fixed] [ *required] [ *optional] 1845 [ *fixed] 1847 header = "" 1849 avpcode = 1*DIGIT 1850 ; The AVP Code assigned to the Grouped AVP 1852 fixed = [qual] "<" avp-spec ">" 1854 required = [qual] "{" avp-spec "}" 1856 optional = [qual] "[" avp-name "]" 1857 ; The avp-name in the 'optional' rule cannot 1858 ; evaluate to any AVP Name which is included 1859 ; in a fixed or required rule. 1861 qual = [min] "*" [max] 1862 ; See ABNF conventions, RFC 2234 section 6.6. 1863 ; The absence of any qualifiers implies that 1864 ; one and only one such AVP MUST be present. 1865 ; 1866 ; NOTE: "[" and "]" have a different meaning 1867 ; than in ABNF (see the optional rule, above). 1868 ; These braces cannot be used to express 1869 ; optional fixed rules (such as an optional 1870 ; ICV at the end.) To do this, the convention 1871 ; is '0*1fixed'. 1873 min = 1*DIGIT 1874 ; The minimum number of times the element may 1875 ; be present. 1877 max = 1*DIGIT 1878 ; The maximum number of times the element may 1879 ; be present. 1881 avp-spec = name-fmt 1882 ; The avp-spec has to be an AVP Name, defined 1883 ; in the base or extended Diameter 1884 ; specifications. 1886 avp-name = avp-spec | "AVP" 1887 ; The string "AVP" stands for *any* arbitrary 1888 ; AVP Name, which does not conflict with the 1889 ; required or fixed position AVPs defined in 1890 ; the command code definition. 1892 4.5.1 Example AVP with a Grouped Data type 1894 The Example AVP (AVP Code 999999) is of type Grouped and is used to 1895 clarify how Grouped AVP values work. The Grouped Data field has the 1896 following ABNF grammar: 1898 Example-AVP ::= < AVP Header: 999999 > 1899 { Origin-Host } 1900 1*{ Session-Id } 1901 *[ AVP ] 1903 An Example AVP with Grouped Data follows. 1905 The Origin-Host AVP is required. In this case: 1907 Origin-Host = "example.com". 1909 One or more Session-Ids must follow. Here there are two: 1911 Session-Id = 1912 "grump.example.com:33041;23432;893;0AF3B81" 1914 Session-Id = 1915 "grump.example.com:33054;23561;2358;0AF3B82" 1917 optional AVPs included are 1919 Recovery-Policy = 1920 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 1921 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 1922 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd 1923 f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a 1924 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 1925 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 1926 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 1928 Futuristic-Acct-Record = 1929 fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 1930 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 1931 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 1932 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 1933 d3427475e49968f841 1935 The data for the optional AVPs is represented in hex since the format 1936 of these AVPs is neither known at the time of definition of the 1937 Example-AVP group, nor (likely) at the time when the example instance 1938 of this AVP is interpreted - except by Diameter implementations which 1939 support the same set of AVPs. The encoding example illustrates how 1940 padding is used, how length fields are calculated and how AVPs do not 1941 have to begin on 8 byte boundaries. Also note that AVPs may be 1942 present in the Grouped AVP value which the receiver cannot interpret 1943 (here, the Recover-Policy and Futuristic-Acct-Record AVPs). 1945 This AVP would be encoded as follows: 1947 0 1 2 3 4 5 6 7 1948 +-------+-------+-------+-------+-------+-------+-------+-------+ 1949 0 | Example AVP Header (AVP Code = 999999), Length = 468 | 1950 +-------+-------+-------+-------+-------+-------+-------+-------+ 1951 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | 1952 +-------+-------+-------+-------+-------+-------+-------+-------+ 1953 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 1954 +-------+-------+-------+-------+-------+-------+-------+-------+ 1955 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | 1956 +-------+-------+-------+-------+-------+-------+-------+-------+ 1957 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | 1958 +-------+-------+-------+-------+-------+-------+-------+-------+ 1959 . . . 1960 +-------+-------+-------+-------+-------+-------+-------+-------+ 1961 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| 1962 +-------+-------+-------+-------+-------+-------+-------+-------+ 1963 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | 1964 +-------+-------+-------+-------+-------+-------+-------+-------+ 1965 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | 1966 +-------+-------+-------+-------+-------+-------+-------+-------+ 1967 . . . 1968 +-------+-------+-------+-------+-------+-------+-------+-------+ 1969 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| 1970 +-------+-------+-------+-------+-------+-------+-------+-------+ 1971 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | 1972 +-------+-------+-------+-------+-------+-------+-------+-------+ 1973 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | 1974 +-------+-------+-------+-------+-------+-------+-------+-------+ 1975 . . . 1976 +-------+-------+-------+-------+-------+-------+-------+-------+ 1977 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| 1978 +-------+-------+-------+-------+-------+-------+-------+-------+ 1979 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| 1980 +-------+-------+-------+-------+-------+-------+-------+-------+ 1981 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 1982 +-------+-------+-------+-------+-------+-------+-------+-------+ 1983 . . . 1984 +-------+-------+-------+-------+-------+-------+-------+-------+ 1985 464 | 0x41 |Padding|Padding|Padding| 1986 +-------+-------+-------+-------+ 1988 4.6 Diameter Base Protocol AVPs 1990 The following table describes the Diameter AVPs defined in the base 1991 protocol, their AVP Code values, types, possible flag values and 1992 whether the AVP MAY be encrypted. 1994 +---------------------+ 1995 | AVP Flag rules | 1996 |----+-----+----+-----|----+ 1997 AVP Section | | |SHLD| MUST|MAY | 1998 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 1999 -----------------------------------------|----+-----+----+-----|----| 2000 Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y | 2001 Interim-Interval | | | | | | 2002 Accounting- 50 9.8.5 OctetString| M | P | | V | Y | 2003 Multi-Session-Id | | | | | | 2004 Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | 2005 Record-Number | | | | | | 2006 Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | 2007 Record-Type | | | | | | 2008 Accounting- 44 9.8.4 OctetString| M | P | | V | Y | 2009 Session-Id | | | | | | 2010 Acct- 259 6.10 Integer32 | M | | | V | N | 2011 Application-Id | | | | | | 2012 Alternate-Peer 275 5.3.8 OctetString| M | | | V | N | 2013 Auth- 258 6.9 Integer32 | M | | | V | N | 2014 Application-Id | | | | | | 2015 Auth-Request- 274 8.7 Enumerated | M | | | V | N | 2016 Type | | | | | | 2017 Authorization- 291 8.9 Unsigned32 | M | P | | V | N | 2018 Lifetime | | | | | | 2019 Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | 2020 Period | | | | | | 2021 Auth-Session- 277 8.11 Enumerated | M | P | | V | N | 2022 State | | | | | | 2023 Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | 2024 Type | | | | | | 2025 Class 25 8.20 OctetString| M | P | | V | Y | 2026 Destination-Host 293 6.6 OctetString| M | | | V | N | 2027 Destination- 283 6.7 OctetString| M | | | V | N | 2028 Realm | | | | | | 2029 Disconnect-Cause 273 5.4.3 Enumerated | M | | | V | N | 2030 Error-Message 281 7.3 OctetString| | | | V | N | 2031 Error-Reporting- 294 7.4 OctetString| | | | V | N | 2032 Host | | | | | | 2033 Failed-AVP 279 7.5 OctetString| M | P | | V | N | 2034 Firmware- 267 5.3.4 Unsigned32 | | | | V,M | N | 2035 Revision | | | | | | 2036 Host-IP-Address 257 5.3.5 IPAddress | M | | | V | N | 2037 Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | 2038 Time-Out | | | | | | 2039 Origin-Host 264 6.4 OctetString| M | | | V | N | 2040 Origin-Realm 296 6.5 OctetString| M | | | V | N | 2041 -----------------------------------------|----+-----+----+-----|----| 2042 +---------------------+ 2043 | AVP Flag rules | 2044 |----+-----+----+-----|----+ 2045 AVP Section | | |SHLD| MUST|MAY | 2046 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2047 -----------------------------------------|----+-----+----+-----|----| 2048 Origin-State-Id 278 8.16 Unsigned32 | M | | | V | N | 2049 Product-Name 269 5.3.7 OctetString| | | | V | N | 2050 Proxy-Host 280 6.8.3 IPAddress | M | | | V | N | 2051 Proxy-Info 284 6.8.2 Grouped | M | | | V | N | 2052 Proxy-State 33 6.8.4 OctetString| M | | | V | N | 2053 Redirect-Host 292 6.12 OctetString| M | | | V | N | 2054 Redirect-Host- 261 6.13 Enumerated | M | | | V | N | 2055 Usage | | | | | | 2056 Redirect-Max- 262 6.14 Unsigned32 | M | | | V | N | 2057 Cache-Time | | | | | | 2058 Result-Code 268 7.1 Unsigned32 | M | | | V | N | 2059 Route-Record 282 6.8.1 OctetString| M | | | V | N | 2060 Session-Id 263 8.8 OctetString| M | | | V | Y | 2061 Session-Timeout 27 8.13 Unsigned32 | M | | | V | N | 2062 Session-Binding 270 8.17 Unsigned32 | M | | | V | Y | 2063 Session-Server- 271 8.18 Enumerated | M | | | V | Y | 2064 Failover | | | | | | 2065 Source-Route 286 6.8.5 OctetString| M | | | V | N | 2066 Supported- 265 5.3.6 Unsigned32 | M | | | V | N | 2067 Vendor-Id | | | | | | 2068 Termination- 295 8.15 Enumerated | M | | | V | N | 2069 Cause | | | | | | 2070 User-Name 1 8.14 OctetString| M | | | V | Y | 2071 Vendor-Id 266 5.3.3 Unsigned32 | M | | | V | N | 2072 Vendor-Specific- 260 6.11 Grouped | M | | | V | N | 2073 Application-Id | | | | | | 2074 -----------------------------------------|----+-----+----+-----|----| 2076 5.0 Diameter Peers 2078 This section describes how a Diameter nodes establish connections and 2079 communicate with peers. 2081 5.1 Peer Connections 2083 Although a Diameter node may have many possible peers that it is able 2084 to communicate with, it may not be economical to have an established 2085 connection to all of them. At a minimum, a Diameter node SHOULD have 2086 an established connection with a primary and secondary peer, and MAY 2087 have additional connections, if it is deemed necessary. 2089 When a peer is deemed suspect, which could occur for various reasons, 2090 including not receiving a DWA within an alloted timeframe, no new 2091 requests should be forwarded to the peer, but failover procedures are 2092 not invoked. When an active peer is moved to this mode, additional 2093 connections SHOULD be established to ensure that the necessary number 2094 of active connections exists. 2096 There are two ways that a peer is removed from the suspect peer list: 2097 1. The peer is no longer reachable, causing the transport 2098 connection to be shutdown. The peer is moved to the closed 2099 state. 2100 2. Three watchdog messages are exchanged with accepted round trip 2101 times, and the connection to the peer is considered stabilized. 2103 5.2 Diameter Peer Discovery 2105 Allowing for dynamic Diameter agent discovery will make it possible 2106 for simpler and more robust deployment of Diameter services. In 2107 order to promote interoperable implementations of Diameter peer 2108 discovery, the following mechanisms are described. These are based 2109 on existing IETF standards. 2111 There are two cases where Diameter peer discovery may be performed. 2112 The first is when a Diameter client needs to discover a first-hop 2113 Diameter agent. The second case is when a Diameter agent needs to 2114 discover another agent - for further handling of a Diameter 2115 operation. In both cases, the following 'search order' is 2116 recommended: 2118 1. The Diameter implementation consults its list of static 2119 (manual) configured Diameter agent locations. These will be 2120 used if they exist and respond. 2122 2. The Diameter implementation uses SLPv2 [28] to discover 2123 Diameter services. The Diameter service template [32] is 2124 included in Appendix A. It is recommended that SLPv2 security 2125 be deployed (this requires distributing keys to SLPv2 agents.) 2126 This is discussed further in Appendix A. 2128 SLPv2 will allow Diameter implementations to discover the 2129 location of Diameter agents in the local site, as well as their 2130 characteristics. Diameter agents with specific capabilities 2131 (say support for the Mobile IP application) can be requested, 2132 and only those will be discovered. 2134 3. The Diameter implementation uses DNS to request the SRV RR [33] 2135 for the '_diameter._sctp' and/or '_diameter._tcp' server in a 2136 particular domain. The Diameter implementation has to know in 2137 advance which domain to look for a Diameter agent in. This 2138 could be deduced, for example, from the 'realm' in a NAI that a 2139 Diameter implementation needed to perform a Diameter operation 2140 on. 2142 3.1 If the destination address is a numeric IP address, the 2143 requestor contacts the peer at the given address and the 2144 port number specified in the SRV record or, if not 2145 specified, the default port (TBD). 2147 3.2 The results of the query or queries are merged and ordered 2148 based on priority. Then, the searching technique outlined in 2149 [46] is used to select servers in order. The requestor 2150 attempts to contact each peer in the order listed, at the 2151 port number specified in the SRV record. If none of the 2152 servers can be contacted, the requestor gives up. If there 2153 are no SRV records, DNS address records are used, as 2154 described below. 2156 3.3 If there are no SRV records, the requestor queries the DNS 2157 server for address records for the destination address 2158 '_diameter._sctp'.domain or '_diameter._tcp'.domain. Address 2159 records include A RR's, AAAA RR's, A6 RR's or other similar 2160 records, chosen according to the requestor's network 2161 protocol capabilities. 2163 If the DNS server returns no address records, the requestor 2164 gives up. If there are address records, the same rules as in 2165 step 3.2 apply. 2167 Requestors MUST NOT cache query results except according to the 2168 rules in [47]. Diameter allows AAA peers to protect the 2169 integrity and privacy of communication as well as to perform 2170 end-point authentication. Still, it is prudent to employ DNS 2171 Security as a precaution when using DNS SRV RRs to look up the 2172 location of a Diameter agent [34, 35, 36]. 2174 A dynamically discovered peer causes an entry in the Peer Table (see 2175 section 2.6) to be created. Note that entries created via DNS MUST 2176 expire (or be refreshed) within the DNS TTL. If a peer is discovered 2177 outside of the local realm, a routing table entry (see Section 2.7) 2178 for the peer's realm is created. The routing table entry's expiration 2179 MUST match the peer's expiration value. 2181 5.3 Capabilities Exchange 2182 When two Diameter peers establish a transport connection, they MUST 2183 exchange the Capabilities Exchange messages, as specified in the peer 2184 state machine (see section 5.6). This message allows the discovery of 2185 a peer's identity and its capabilities (protocol version number, 2186 supported Diameter applications, etc.) 2188 The receiver only issues commands to its peers that have advertised 2189 support for the Diameter application that defines the command. A 2190 Diameter node MUST cache the supported applications in order to 2191 ensure that unrecognized commands and/or AVPs are not unnecessarily 2192 sent to a peer. 2194 A receiver of a Capabilities-Exchange-Req (CER) message which does 2195 not have any applications in common with the sender MUST return a 2196 Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to 2197 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport 2198 layer connection. Note that receiving a CER or CEA from a peer 2199 advertising itself as a Relay (see section 2.5) MUST be interpreted 2200 as having common applications with the peer. 2202 The CER and CEA messages MUST NOT be proxied, or redirected. 2204 Since the CER/CEA messages cannot be proxied, it is still possible 2205 that an upstream proxy receives a message for which it has no 2206 available peers to handle the application that corresponds to the 2207 Command-Code. In such instances, the 'E' bit is set in the answer 2208 message (see Section 7.2) to inform the downstream to take action 2209 (e.g. re-routing request to an alternate peer). 2211 With the exception of the Capabilities-Exchange-Request message, a 2212 message of type Request that includes the Auth-Application-Id or 2213 Acct-Application-Id AVPs, or a message with an application-specific 2214 command code, MAY only be forwarded to a host that has explicitly 2215 advertised support for the application (or has advertised the Relay 2216 Application Identifier). 2218 5.3.1 Capabilities-Exchange-Request 2220 The Capabilities-Exchange-Request (CER), indicated by the Command- 2221 Code set to 257 and the Command Flags' 'R' bit set, is sent to inform 2222 a peer that a reboot has occurred. Upon detection of a transport 2223 failure, this message MUST NOT be sent to an alternate peer. 2225 When Diameter is run over SCTP [26], which allows for connections to 2226 span multiple interfaces, hence multiple IP addresses, the 2227 Capabilities-Exchange-Request message MUST contain one Host-IP- 2228 Address AVP for each potential IP address that MAY be locally used 2229 when transmitting Diameter messages. 2231 Message Format 2233 ::= < Diameter Header: 257, REQ > 2234 { Origin-Host } 2235 { Origin-Realm } 2236 1* { Host-IP-Address } 2237 { Vendor-Id } 2238 { Product-Name } 2239 [ Origin-State-Id ] 2240 * [ Supported-Vendor-Id ] 2241 * [ Auth-Application-Id ] 2242 * [ Acct-Application-Id ] 2243 * [ Alternate-Peer ] 2244 [ Destination-Host ] 2245 [ Firmware-Revision ] 2246 * [ AVP ] 2248 5.3.2 Capabilities-Exchange-Answer 2250 The Capabilities-Exchange-Request (CEA), indicated by the Command- 2251 Code set to 257 and the Command Flags' 'R' bit cleared, is sent in 2252 response to a CER message. 2254 When Diameter is run over SCTP [26], which allows for connections to 2255 span multiple interfaces, hence multiple IP addresses, the 2256 Capabilities-Exchange-Answer message MUST contain one Host-IP-Address 2257 AVP for each potential IP address that MAY be locally used when 2258 transmitting Diameter messages. 2260 Message Format 2261 ::= < Diameter Header: 257 > 2262 { Result-Code } 2263 { Origin-Host } 2264 { Origin-Realm } 2265 1* { Host-IP-Address } 2266 { Vendor-Id } 2267 { Product-Name } 2268 [ Origin-State-Id ] 2269 * [ Supported-Vendor-Id ] 2270 * [ Auth-Application-Id ] 2271 * [ Acct-Application-Id ] 2272 * [ Alternate-Peer ] 2273 [ Destination-Host ] 2274 [ Firmware-Revision ] 2275 * [ AVP ] 2277 5.3.3 Vendor-Id AVP 2279 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 2280 the IANA "SMI Network Management Private Enterprise Codes" [2] value 2281 assigned to the vendor of the Diameter device. 2283 In combination with the Supported-Vendor-Id AVP (section 5.3.6), this 2284 MAY be used in order to know which vendor specific attributes may be 2285 sent to the peer. It is also envisioned that the combination of the 2286 Vendor-Id, Product-Name (section 5.3.7) and the Firmware-Revision 2287 (section 5.3.4) AVPs MAY provide very useful debugging information. 2289 A Vendor-Id value of zero in the CER or CEA messages is reserved and 2290 indicates that the Diameter peer is in the experimental or concept 2291 stage and that an IANA Private Enterprise Number has yet to be 2292 obtained by the implementor. 2294 5.3.4 Firmware-Revision AVP 2296 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 2297 used to inform a Diameter peer of the firmware revision of the 2298 issuing device. 2300 For devices that do not have a firmware revision (general purpose 2301 computers running Diameter software modules, for instance), the 2302 revision of the Diameter software module may be reported instead. 2304 5.3.5 Host-IP-Address AVP 2305 The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is 2306 used to inform a Diameter peer of the sender's IP address. All 2307 source addresses that a Diameter node expects to use with SCTP [26] 2308 MUST be advertised in the CER and CEA messages by including a Host- 2309 IP-Address AVP for each address. This AVP MUST ONLY be used in the 2310 CER and CEA messages. 2312 5.3.6 Supported-Vendor-Id AVP 2314 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and 2315 contains the IANA "SMI Network Management Private Enterprise Codes" 2316 [2] value assigned to a vendor other than the device vendor. This is 2317 used in the CER and CEA messages in order to inform the peer that the 2318 sender supports a subset of the vendor-specific commands and/or AVPs 2319 defined by the vendor identified in this AVP. 2321 5.3.7 Product-Name AVP 2323 The Product-Name AVP (AVP Code 269) is of type UTF8String, and 2324 contains the vendor assigned name for the product. The Product-Name 2325 AVP SHOULD remain constant across firmware revisions for the same 2326 product. 2328 5.3.8 Alternate-Peer AVP 2330 The Alternate-Peer AVP (AVP Code 275) is of type DiameterIdentity, 2331 and contains the URI of an alternate peer that MAY be used in 2332 server-initiated requests, when routing using the Source-Route AVP. 2334 5.4 Disconnecting Peer connections 2336 When a Diameter node disconnects one its transport connections, its 2337 peer cannot know the reason for the disconnect, and will most likely 2338 assume that a connectivity problem occurred, or that the peer has 2339 rebooted. In these cases, the peer may periodically attempt to 2340 reconnect, as stated in section 2.1. In the event that the disconnect 2341 was a result of either a shortage of internal resources, or simply 2342 that the node in question has no intentions of forwarding any 2343 Diameter messages to the peer in the foreseeable future, a periodic 2344 connection request would not be welcomed. The Disconnection-Reason 2345 AVP contains the reason the Diameter node issued the Disconnect- 2346 Peer-Request message. 2348 The Disconnect-Peer-Request message is used by a Diameter node to 2349 inform its peer of its intent to disconnect the transport layer, and 2350 that the peer shouldn't reconnect unless it has a valid reason to do 2351 so (e.g. message to be forwarded). Upon receipt of the message, the 2352 Disconnect-Peer-Answer is returned, which SHOULD contain an error if 2353 messages have recently be forwarded, and are likely in flight, which 2354 would otherwise cause a race condition. 2356 The receiver of the Disconnect-Peer-Answer initiates the transport 2357 disconnect. 2359 5.4.1 Disconnect-Peer-Request 2361 The Disconnect-Peer-Request (DPR), indicated by the Command-Code set 2362 to 282 and the Command Flags' 'R' bit set, is sent to a peer to 2363 inform its intentions to shutdown the transport connection. Upon 2364 detection of a transport failure, this message MUST NOT be sent to an 2365 alternate peer. 2367 Message Format 2369 ::= < Diameter Header: 282, REQ > 2370 { Origin-Host } 2371 { Origin-Realm } 2372 { Destination-Host } 2373 { Disconnect-Cause } 2375 5.4.2 Disconnect-Peer-Answer 2377 The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set 2378 to 282 and the Command Flags' 'R' bit cleared, is sent as a response 2379 to the Disconnect-Peer-Request message. Upon receipt of this message, 2380 the transport connection is shutdown. 2382 Message Format 2384 ::= < Diameter Header: 282 > 2385 { Result-Code } 2386 { Origin-Host } 2387 { Origin-Realm } 2388 { Destination-Host } 2390 5.4.3 Disconnect-Cause AVP 2392 The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A 2393 Diameter node MUST include this AVP in the Disconnect-Peer-Request 2394 message to inform the peer of the reason for its intention to 2395 shutdown the transport connection. The following values are 2396 supported: 2398 REBOOTING 0 2399 A scheduled reboot is imminent. 2401 BUSY 1 2402 The peer's internal resources are constrained, and it has 2403 determined that the transport connection needs to be shutdown. 2405 DO_NOT_WANT_TO_TALK_TO_YOU 2 2406 The peer has determined that it does not see a need for the 2407 transport connection to exist, since it does not expect any 2408 messages to be exchanged in the foreseeable future. 2410 5.5 Transport Failure Detection 2412 Given the nature of the Diameter protocol, it is recommended that 2413 transport failures be detected as soon as possible. Detecting such 2414 failures will minimize the occurrence of messages sent to unavailable 2415 agents, resulting in unnecessary delays, and will provide better 2416 failover performance. The Device-Watchdog-Request and Device- 2417 Watchdog-Answer messages, defined in this section, are used to pro- 2418 actively detect transport failures. 2420 5.5.1 Device-Watchdog-Request 2422 The Device-Watchdog-Request (DWR), indicated by the Command-Code set 2423 to 280 and the Command Flags' 'R' bit set, is sent to a peer when no 2424 traffic has been exchanged between two peers (see Section 5.5.3). 2425 Upon detection of a transport failure, this message MUST NOT be sent 2426 to an alternate peer. 2428 Message Format 2430 ::= < Diameter Header: 280, REQ > 2431 { Origin-Host } 2432 { Origin-Realm } 2433 { Destination-Host } 2435 5.5.2 Device-Watchdog-Answer 2437 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 2438 to 280 and the Command Flags' 'R' bit cleared, is sent as a response 2439 to the Device-Watchdog-Request message. 2441 Message Format 2443 ::= < Diameter Header: 280 > 2444 { Result-Code } 2445 { Origin-Host } 2446 { Origin-Realm } 2447 { Destination-Host } 2449 5.5.3 Transport Failure Algorithm 2451 The watchdog behavior is controlled by an algorithm defined in this 2452 section. Note that implementations are not restricted to the 2453 algorithm defined herein, but SHOULD implement an algorithm that 2454 produces similar results. In this section, we will refer to a memory 2455 control structure that contains all information regarding a specific 2456 peer as a Peer Control Block, or PCB. 2458 For the purposes of illustrating the algorithm, each PCB contains the 2459 following fields: 2461 Status - This field represents the level of confidence in the 2462 algorithm. The following values are defined: 2464 OKAY indicates the connection is presumed working 2465 WAIT_DWA indicates that a DWR has been sent but a DWA 2466 has not yet been received 2467 SUSPECT indicates the connection is possibly 2468 congested or down 2470 Pending - This boolean field is set to TRUE when there are no 2471 outstanding unanswered requests. 2473 T is the watchdog timer, measured in seconds. Every second, T is 2474 decremented. When it reaches 0, the OnTimerElapsed event (see below) 2475 is invoked. 2477 The algorithm uses the following time constants, which have default 2478 values but may be configured differently in an implementation: 2480 Ti, the idle time, represents the number of seconds that must 2481 elapse when there is no activity, before a DWR is sent. The 2482 default value of Ti is 30 seconds. In order to avoid 2483 synchronization behaviors that can occur with fixed timers among 2484 distributed systems, each time Ti is calculated with a jitter by 2485 using the Ti configured (or default) value and randomly adding or 2486 subtracting a random value drawn between 0.5 and 2 seconds. 2488 Alternative calculations to create jitter MAY be used. These MUST 2489 be pseudo-random and not cyclic. 2491 Tr, the request pending time, represents the number of seconds 2492 that must elapse when there are requests pending but no messages 2493 have been received, before a DWR is sent. Tr should be less than 2494 Ti. The default value of Tr is 10 seconds. 2496 Tw, the watchdog pending time, represents the number of seconds 2497 that must elapse after a DWR is sent but no DWA has been received, 2498 before the PCB's Status field is set to SUSPECT. The default 2499 value of Tw is 5 seconds. 2501 Td, the disconnect timer, the number of seconds that must elapse 2502 when the PCB's Status field is set to SUSPECT and no DWA has been 2503 received, before the connection is stopped. The default value of 2504 Td is 5 seconds. 2506 Pseudo-code for the algorithm is as follows: 2508 /* 2509 * OnSendRequest() is called whenever a request is sent on 2510 * connection 2511 */ 2512 OnSendRequest(pcb) 2513 { 2514 if pcb->Status = OKAY AND T > Tr 2515 T = Tr 2516 } 2518 /* 2519 * OnReceiveNonDWA() is called whenever a message other 2520 * than DWA is received from the peer. This message MAY 2521 * be a request or an answer. 2522 */ 2523 OnReceiveNonDWA(pcb) 2524 { 2525 if pcb->Status = OKAY 2526 if pcb->Pending 2527 T = Tr 2528 else 2529 T = Ti 2530 } 2532 /* 2533 * OnReceiveDWA() is called whenever a DWA is received 2534 * from the peer. 2535 */ 2537 OnReceiveDWA(pcb) 2538 { 2539 if pcb->status = WAIT_DWA OR pcb->Status = SUSPECT 2540 if pcb->Pending 2541 T = Tr 2542 else 2543 T = Ti 2544 } 2546 /* 2547 * OnTimerElapsed() is called by some timer services 2548 * whenever T reaches zero (0). 2549 */ 2550 OnTimerElapsed(pcb) 2551 { 2552 if pcb->status = OKAY 2553 SendWatchdog(pcb) 2554 pcb->status = WAIT_DWA 2555 else if pcb->status = WAIT_DWA 2556 pcb->status = SUSPECT 2557 T = Td 2558 else if pcb->status = SUSPECT 2559 StopConnection(pcb) 2560 FailoverProcedures(pcb) 2561 } 2563 5.5.4 Failover/Failback Procedures 2565 In the event that a transport failure is detected with a peer, it is 2566 necessary for all pending request messages to be forwarded to an 2567 alternate agent, if possible. This is commonly referred to as 2568 failover. 2570 In order for a Diameter node to perform failover procedures, it is 2571 necessary for the node to maintain a pending message queue for a 2572 given peer. When an answer message is received, the corresponding 2573 request is removed from the queue. The Hop-by-Hop Identifier field 2574 MAY be used to match the answer with the queued request. 2576 When a transport failure is detected, all messages in the queue are 2577 sent to an alternate agent, if possible. An example of a case where 2578 it is not possible for forward the message to an alternate server is 2579 when the message has a fixed destination, and the unavailable peer is 2580 the message's final destination (see Destination-Host AVP). Such an 2581 error requires that the agent return an answer message with the 'E' 2582 bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 2584 It is important to note that multiple identical request or answer MAY 2585 be received as a result of a failover. The End-to-End Identifier 2586 field in the Diameter header along with the Origin-Host AVP MUST be 2587 used to identify duplicate messages. 2589 As described in section 2.1, a connection request should be 2590 periodically attempted with the failed peer in order to re-establish 2591 the transport connection. Once a connection has been successfully 2592 established, messages can once again be forwarded to the peer. This 2593 is commonly referred to as failback. 2595 5.6 Peer State Machine 2597 This section contains a finite state machine, that MUST be observed 2598 by all Diameter implementations. Each Diameter node MUST follow the 2599 state machine described below when communicating with each peer. 2600 Multiple actions are separated by commas, and may continue on 2601 succeeding lines as space requires. Similarly, state and next state 2602 may also span multiple lines as space requires. 2604 There may be at most one transport connection between any two peers 2605 over which Diameter messages may be passed. This state machine is 2606 intended to handle both the simple case, in which one peer initiates 2607 a connection to the other, and the complex case, in which each peer 2608 simultaneously initiates a connection to the other. In the complex 2609 case, an election occurs to determine which transport connection will 2610 survive. It is important to note that the port on which a connection 2611 is initiated MUST NOT be the port Diameter listens for incoming 2612 connections. 2614 I- is used to represent the initiator (connecting) connection, while 2615 the R- is used to represent the responder (listening) connection. The 2616 lack of a prefix indicates that the event or action is the same 2617 regardless of the connection on which the event occurred. 2619 The stable states that a state machine may be in are Closed, I-Open 2620 and R-Open; all other states are intermediate. Note that I-Open and 2621 R-Open are equivalent except for whether the initiator or responder 2622 transport connection is used for communication. 2624 A CER message is always sent on the initiating connection immediately 2625 after the connection request is successfully completed. In the case 2626 of an election, one of the two connections will shut down. The 2627 responder connection will survive if the Origin-Host of the local 2628 Diameter entity is higher than that of the peer; the initiator 2629 connection will survive if the peer's Origin-Host is higher. All 2630 subsequent messages are sent on the surviving connection. Note that 2631 the results of an election on one peer are guaranteed to be the 2632 inverse of the results on the other. 2634 The state machine constrains only the behavior of a Diameter 2635 implementation as seen by Diameter peers through events on the wire. 2636 Any implementation that produces equivalent results is considered 2637 compliant. 2639 state event action next state 2640 ----------------------------------------------------------------- 2641 Closed Start I-Snd-Conn-Req Wait-Conn-Ack 2642 R-Conn-CER R-Accept, R-Open 2643 Process_CER, 2644 R-Snd-CEA 2646 Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA 2647 I-Rcv-Conn-Nack Cleanup Closed 2648 R-Conn-CER R-Accept, Wait-Conn-Ack/ 2649 Process-CER Elect 2650 Timeout Error Closed 2652 Wait-I-CEA I-Rcv-CEA Process-CEA I-Open 2653 R-Conn-CER R-Accept, Wait-Returns 2654 Process_CER, 2655 Elect 2656 I-Peer-Disc I-Disc Closed 2657 I-Rcv-Non-CEA Error Closed 2658 Timeout Error Closed 2660 Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns 2661 Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open 2662 R-Peer-Disc R-Disc Wait-Conn-Ack 2663 R-Conn-CER R-Reject Wait-Conn-Ack/ 2664 Elect 2665 Timeout Error Closed 2667 Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open 2668 I-Peer-Disc I-Disc,R-Snd-CEA R-Open 2669 I-Rcv-CEA R-Disc I-Open 2670 R-Peer-Disc R-Disc Wait-I-CEA 2671 R-Conn-CER R-Reject Wait-Returns 2672 Timeout Error Closed 2674 R-Open Send-Message R-Snd-Message R-Open 2675 R-Rcv-Message Process R-Open 2676 WatchDog-Timer R-Snd-DWR R-Open 2677 R-Rcv-DWR Process-DWR, R-Open 2678 R-Snd-DWA 2679 R-Rcv-DWA Process-DWA R-Open 2680 R-Conn-CER R-Reject R-Open 2681 Stop R-Disc Closed 2682 R-Peer-Disc R-Disc Closed 2683 R-Rcv-CER Error Closed 2684 R-Rcv-CEA Error Closed 2686 I-Open Send-Message I-Snd-Message I-Open 2687 I-Rcv-Message Process I-Open 2688 WatchDog-Timer I-Snd-DWR I-Open 2689 I-Rcv-DWR Process-DWR, I-Open 2690 I-Snd-DWA 2691 I-Rcv-DWA Process-DWA I-Open 2692 R-Conn-CER R-Reject I-Open 2693 Stop I-Disc Closed 2694 I-Peer-Disc I-Disc Closed 2695 I-Rcv-CER Error Closed 2696 I-Rcv-CEA Error Closed 2698 5.6.1 Incoming connections 2700 When a connection request is received from a Diameter peer, it is 2701 not, in the general case, possible to know the identity of that peer 2702 until a CER is received from it. This is because the identity of a 2703 Diameter peer is determined by host and port; and the source port of 2704 an incoming connection is arbitrary. Upon receipt of CER, the 2705 identity of the connecting peer can be uniquely determined from 2706 Origin-Host. 2708 For this reason, a Diameter peer must employ logic separate from the 2709 state machine to receive connection requests, accept them, and await 2710 CER. Once CER arrives on a new connection, the Origin-Host which 2711 identifies the peer is used to locate the state machine associated 2712 with that peer, and the new connection and CER are passed to the 2713 state machine as an R-Conn-CER event. 2715 The logic that handles incoming connections SHOULD close and discard 2716 the connection if any message other than CER arrives, or if an 2717 implementation-defined timeout occurs prior to receipt of CER. 2719 Because handling of incoming connections up to and including receipt 2720 of CER requires logic separate from that of any individual state 2721 machine associated with a particular peer, it is described separately 2722 in this section rather than in the state machine below. 2724 5.6.2 Events 2726 Transitions and actions in the automaton are caused by events. In 2727 this section we will ignore the -I and -R prefix, since the actual 2728 event would be identical, but would occur on one of two possible 2729 connections. 2731 Start The Diameter application has signaled that a 2732 connection should be initiated with the peer. 2734 R-Conn-CER A new incoming connection and associated CER has 2735 arrived. 2737 Rcv-Conn-Ack A positive acknowledgement was received to a 2738 locally initiated transport connection. 2740 Rcv-Conn-Nack A negative acknowledgement was received to a 2741 locally initiated transport connection. 2743 Timeout An application-defined timer has expired while 2744 waiting for some event. 2746 Rcv-CER A CER message from the peer was received. 2748 Rcv-CEA A CEA message from the peer was received. 2750 Rcv-Non-CEA A message other than CEA from the peer was 2751 received. 2753 Peer-Disc A disconnection indication from the peer was 2754 received. 2756 Win-Election An election was held, and the local node was the 2757 winner. 2759 Send-Message A message is to be sent. 2761 Rcv-Message A message other than CER, CEA, DWR, or DWA was 2762 received. 2764 WatchDog-Timer The Watchdog timer expired, indicating that a DWR 2765 message is to be sent to the peer. 2767 Rcv-DWR A DWR message was received. 2769 Rcv-DWA A DWA message was received. 2771 Stop The Diameter application has signaled that a 2772 connection should be terminated (e.g., on system 2773 shutdown). 2775 5.6.3 Actions 2777 Actions in the automaton are caused by events and typically indicate 2778 the transmission of packets and/or an action to be taken on the 2779 connection. In this section we will ignore the I- and R- prefix, 2780 since the actual action would be identical, but would occur on one of 2781 two possible connections. 2783 Snd-Conn-Req A transport connection is initiated with the peer. 2785 Accept The incoming connection associated with the R- 2786 Conn-CER is accepted as the responder connection. 2788 Reject The incoming connection associated with the R- 2789 Conn-CER is disconnected. 2791 Process-CER The CER associated with the R-Conn-CER is 2792 processed. 2794 Snd-Conn-Ack an acknowledgement is sent in response to a connect 2795 request, confirming that the transport layer 2796 connection is open. 2798 Snd-CER A CER message is sent to the peer. 2800 Snd-CEA A CEA message is sent to the peer. 2802 Cleanup If necessary, the connection is shutdown, and any 2803 local resources are freed. 2805 Error The transport layer connection is disconnected, 2806 either politely or abortively, in response to an 2807 error condition. Local resources are freed. 2809 Process-CEA A received CEA is processed. 2811 Disc The transport layer connection is disconnected, and 2812 local resources are freed. 2814 Elect An election occurs (see Section 8.4 for more 2815 information). 2817 Snd-Message A message is sent. 2819 Snd-DWR A DWR message is sent. 2821 Snd-DWA A DWA message is sent. 2823 Process-DWR The DWR message is serviced. 2825 Process-DWA The DWA message is serviced. 2827 Process A message is serviced. 2829 5.6.4 The Election Process 2831 The election is performed on the responder. The responder compares 2832 the Origin-Host received in the CER sent by its peer with its own 2833 Origin-Host. If the local Diameter entity's Origin-Host is higher 2834 than the peer's, a Win-Election event is issued locally. 2836 The comparison proceeds by considering the shorter OctetString to be 2837 null-padded to the length of the longer, then performing an octet by 2838 octet unsigned comparison with the first octet being most 2839 significant. Hanging octets are assumed to have value 0x80, but 2840 dimpled octets are ignored. 2842 6.0 Diameter message processing 2844 This section describes how Diameter requests and answers are created 2845 and processed. 2847 6.1 Diameter request routing overview 2849 A request is sent towards its final destination using a combination 2850 of the Destination-Realm and Destination-Host AVPs, in one of these 2851 three combinations: 2852 - a request that is not proxiable (such as CER) MUST NOT contain 2853 either Destination-Realm or Destination-Host AVPs. 2854 - a request that needs to be sent to a home server serving a 2855 specific realm, but not to a specific server (such as the first 2856 request of a series of round-trips), MUST contain a 2857 Destination-Realm AVP, but MUST NOT contain a Destination-Host 2858 AVP. 2859 - a request that needs to be sent to a specific home server among 2860 those serving a given realm, MUST contain both the Destination- 2861 Realm and Destination-Host AVPs. 2863 The Destination-Host AVP is used as described above when the 2864 destination of the request is fixed, which includes: 2865 - Authentication requests that span multiple round trips 2866 - A Diameter message that uses a security mechanism that makes use 2867 of a pre-established session key shared between the source and 2868 the final destination of the message. 2869 - Server initiated messages that MUST be received by a specific 2870 Diameter client (e.g. access device), such as the Abort- 2871 Session-Request message, which is used to request that a 2872 particular user's session be terminated. 2874 Note that an agent can forward a request to a host described in the 2875 Destination-Host AVP only if the host in question is included in its 2876 peer table (see section 2.6). Otherwise, the request is routed based 2877 on the Destination-Realm only (see sections 6.1.6). 2879 The Destination-Realm AVP MUST be present if the message is routable. 2880 A message that MUST NOT be relayed, proxied or redirected MUST NOT 2881 include the Destination-Realm in its ABNF. The value of the 2882 Destination-Realm AVP MAY be extracted from the User-Name AVP, or 2883 other application-specific methods. 2885 When a message is received, the message is processed in the following 2886 order: 2887 1. If the message is destined for the local host, the procedures 2888 listed in section 6.1.1 are followed. 2889 2. If the message is intended for a Diameter peer with whom the 2890 local host is able to directly communicate, the procedures 2891 listed in section 6.1.2 are followed. This is known as Message 2892 Forwarding. 2893 3. The procedures listed in section 6.1.5 are followed, which is 2894 known as Message Routing. 2895 4. If none of the above are successful, an answer is returned with 2896 the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. 2898 Note the processing rules contained in this section are intended to 2899 be used as general guidelines to Diameter developers. Certain 2900 implementations MAY use different methods than the ones described 2901 here, and still be in compliance with the protocol specification. 2903 6.1.1 Originating a Request 2905 When creating a request, in addition to any other procedures 2906 described in the application definition for that specific request, 2907 the following procedures MUST be followed: 2908 - the Command-Code should be set to the appropriate value 2909 - the 'R' bit should be set 2910 - the End-to-End Identifier should be set to a locally unique 2911 value 2912 - the Origin-Host and Origin-Realm AVPs MUST be set to the 2913 appropriate values, used to identify the source of the message 2914 - the Destination-Host and Destination-Realm AVPs MUST be set to 2915 the appropriate values as described in section 6.1. 2917 6.1.2 Sending a Request 2919 When sending a request, either originated locally, or as the result 2920 of a forwarding or routing operation, the following procedures MUST 2921 be followed: 2922 - the Hop-by-Hop Identifier should be set to a locally unique 2923 value 2924 - The message should be saved in the list of pending requests. 2926 Other actions to perform on the message based on the particular role 2927 the agent is playing are described in the following sections. 2929 6.1.3 Receiving Requests 2931 A relay or proxy agent MUST check for forwarding loops when receiving 2932 requests. A loop is detected if the server finds its own identity in 2933 a Route-Record AVP. When such an event occurs, the agent MUST answer 2934 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 2936 6.1.4 Processing Local Requests 2938 A request is known to be for local consumption when one of the 2939 following conditions occur: 2940 - The Destination-Host AVP contains the local host's identity, 2941 - The Destination-Host AVP is not present, the Destination-Realm 2942 AVP contains a realm the server is configured to process 2943 locally, and the Diameter application is locally supported, or 2944 - The Destination-Realm AVP is not present. 2946 When a request is locally processed, the rules in section 6.2 should 2947 be used to generate the corresponding answer. 2949 6.1.5 Request Forwarding 2951 Request forwarding is done using the Diameter Peer Table. The 2952 Diameter peer table contains all of the peers that the local node is 2953 able to directly communicate with. 2955 When a request is received, and the host encoded in the Destination- 2956 Host AVP is one that is present in the peer table, the message SHOULD 2957 be forwarded to the peer. 2959 6.1.6 Request Routing 2961 Diameter request message routing is done via realms. A Diameter 2962 message that is proxyable MUST include the target realm in the 2963 Destination-Realm AVP. The realm MAY be retrieved from the User-Name 2964 AVP, which is in the form of a Network Access Identifier (NAI). The 2965 realm portion of the NAI is inserted in the Destination-Realm AVP. 2967 Diameter agents MAY have a list of locally supported realms, and MAY 2968 have a list of externally supported realms. When a request is 2969 received that includes a realm that is not locally supported, the 2970 message is routed to the peer configured in the Domain Routing Table 2971 table (see section 2.7). 2973 6.1.7 Redirecting requests 2975 When a redirector agent receives a request whose routing entry is set 2976 to REDIRECT, it MUST reply with an answer message with the 'E' bit 2977 set, while maintaining the Hop-by-Hop Identifier in the header, and 2978 include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of 2979 the servers associated with the routing entry are added in separate 2980 Redirect-Host AVP. 2982 +------------------+ 2983 | Diameter | 2984 | Redirector Agent | 2985 +------------------+ 2986 ^ | 2. command + 'E' bit 2987 1. Request | | Result-Code = 2988 joe@xyz.com | | DIAMETER_REDIRECT_INDICATION + 2989 | | Redirect-Host AVP(s) 2990 | v 2991 +---------+ 3. Request +----------+ 2992 | abc.net |------------->| xyz.net | 2993 | Relay | | Diameter | 2994 | Agent |<-------------| Server | 2995 +---------+ 4. Answer +----------+ 2996 Figure 4: Diameter Redirect Server 2998 Redirector agents MAY also include the certificate of the servers in 2999 the Redirect-Host AVP(s). These certificates are encapsulated in a 3000 CMS-Cert AVP [11]. 3002 The receiver of the answer message with the 'E' bit set, and the 3003 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- 3004 hop field in the Diameter header to identify the request in the 3005 pending message queue (see Section 5.3) that is to be redirected. If 3006 no transport connection exists with the new agent, one is created, 3007 and the request is sent directly to it. 3009 6.1.8 Relaying and Proxying Requests 3011 A relay or proxy agent MUST append a Route-Record AVP to all requests 3012 forwarded. The AVP contains the identity of the peer the request was 3013 received from. 3015 The Hop-by-Hop identifier in the request is saved, and replaced with 3016 a locally unique value. The source of the request is also saved, 3017 which includes the IP address, port and protocol. 3019 Relay and Proxy agents MAY include the Proxy-Info AVP in requests if 3020 it requires access any local state information when the corresponding 3021 response is received. Alternatively, it MAY simply use local storage 3022 to store state information. 3024 The message is then forwarded to the next hop, as identified in the 3025 Domain Routing Table. 3027 Figure 5 provides an example of message routing using the procedures 3028 listed in these sections. 3030 (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) 3031 (Origin-Realm=mno.net) (Origin-Realm=mno.net) 3032 (Destination-Realm=abc.com) (Destination-Realm=abc.com) 3033 (Route-Record=drl.mno.net) 3034 +------+ ------> +------+ ------> +------+ 3035 | | (Request) | | (Request) | | 3036 | NAS +-------------------+ DRL +-------------------+ HMS | 3037 | | | | | | 3038 +------+ <------ +------+ <------ +------+ 3039 mno.net (Answer) mno.net (Answer) abc.com 3040 (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) 3041 (Origin-Realm=abc.com) (Origin-Realm=abc.com) 3042 Figure 5: Routing of Diameter messages 3044 6.1.9 Relaying and Proxying Server-Initiated Requests 3046 Server-initiated messages MUST include the Source-Route AVPs, whose 3047 contents are identical to the Record-Route AVPs received in requests 3048 from the access device for the given session, but in the reverse 3049 order. Agents receiving requests with one or more Source-Route AVP 3050 MUST use the last Source-Route AVP in the request to determine the 3051 request's next hop. 3053 In the event that the next hop encoded in the Source-Route is not 3054 reachable, an alternate peer MAY be used if the peer in question had 3055 advertised such peers via the Alternate-Peer AVP in the CER or CEA 3056 message. 3058 6.2 Diameter Answer Processing 3060 When a request is locally processed, the following procedures MUST be 3061 applied to create the associated answer, in addition to any 3062 additional procedures that MAY be discussed in the Diameter 3063 application defining the command: 3065 - The same Hop-by-Hop identifier in the request is used in the 3066 answer. 3067 - The local host's identity is encoded in the Origin-Host AVP. 3068 - The Destination-Host and Destination-Realm AVPs MUST NOT be 3069 present in the answer message. 3070 - The Result-Code AVP is added with its value indicating success 3071 or failure. 3072 - If the Session-Id is present in the request, it MUST be included 3073 in the answer. 3074 - Any Proxy-Info AVPs in the request MUST be added to the answer 3075 message, in the same order they were present in the request. 3076 - The 'P' bit is set to the same value as the one in the request. 3078 6.2.1 Processing received Answers 3080 A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an 3081 answer received against the list of pending requests. The 3082 corresponding message should be removed from the list of pending 3083 requests. It SHOULD ignore answers received that do not match a known 3084 Hop-by-Hop Identifier. 3086 6.2.2 Relaying and Proxying Answers 3088 If the answer is for a request which was proxied or relayed, the 3089 agent MUST restore the original value of the Diameter header's Hop- 3090 by-Hop Identifier field. 3092 If the last Proxy-Info AVP in the message is targeted to the local 3093 Diameter server, the AVP MUST be removed before the answer is 3094 forwarded. 3096 If a relay or proxy agent receives an answer with a Result-Code AVP 3097 indicating a failure, it MUST NOT modify the contents of the AVP. Any 3098 additional local errors detected SHOULD be logged, but not reflected 3099 in the Result-Code AVP. If the agent receives an answer message with 3100 a Result-Code AVP indicating success, and it wishes to modify the AVP 3101 to indicate an error, it MUST issue an STR on behalf of the access 3102 device. 3104 The agent MUST then send the answer to the host which it received the 3105 original request from. 3107 6.3 Hiding Network Topology 3109 A Relay or Proxy agent routing messages outside of their 3110 administrative domain MAY need to hide the internal Diameter 3111 topology. This is done by removing all Route-Record AVPs in a 3112 request. 3114 6.4 Origin-Host AVP 3116 The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and 3117 MUST be present in all Diameter messages. This AVP identifies the 3118 endpoint which originated the Diameter message, i.e. the access 3119 device, home server, or broker. Relay agents MUST NOT modify this 3120 AVP. 3122 The value of the Origin-Host AVP is guaranteed to be unique within a 3123 single host. 3125 Note that the Origin-Host AVP may resolve to more than one address as 3126 the Diameter peer may support more than one address. 3128 This AVP SHOULD be placed as close to the Diameter header as 3129 possible. 3131 6.5 Origin-Realm AVP 3133 The Origin-Realm AVP (AVP Code 296) is of type UTF8String. This AVP 3134 contains the Realm of the originator of any Diameter message and MUST 3135 be present in all messages 3137 This AVP SHOULD be placed as close to the Diameter header as 3138 possible. 3140 6.6 Destination-Host AVP 3142 The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. 3143 This AVP MUST be present in all unsolicited agent initiated messages, 3144 MAY be present in request messages, and MUST NOT be present in Answer 3145 messages. 3147 The absence of the Destination-Host AVP will cause a message to be 3148 sent to any Diameter server supporting the application within the 3149 realm specified in Destination-Realm AVP. 3151 This AVP SHOULD be placed as close to the Diameter header as 3152 possible. 3154 6.7 Destination-Realm AVP 3156 The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and 3157 contains the realm the message is to be routed to. The Destination- 3158 Realm AVP MUST NOT be present in Answer messages. Diameter Clients 3159 insert the realm portion of the User-Name AVP. Diameter servers 3160 initiating a request message use the value of the Origin-Realm AVP 3161 from a previous message received from the intended target host 3162 (unless it is known a priori). When present, the Destination-Realm 3163 AVP is used to perform message routing decisions. 3165 Request messages whose ABNF does not list the Destination-Realm AVP 3166 as a mandatory AVP are inherently non-routable messages. 3168 This AVP SHOULD be placed as close to the Diameter header as 3169 possible. 3171 6.8 Routing AVPs 3173 The AVPs defined in this section are Diameter AVPs used for routing 3174 purposes. These AVPs change as Diameter messages are processed by 3175 agents, and therefore MUST NOT be protected using the Diameter CMS 3176 Security application [11]. 3178 6.8.1 Route-Record AVP 3180 The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The 3181 identity added in this AVP MUST be the same as the one sent in the 3182 Origin-Host of the Capabilities-Exchange-Request message. 3184 6.8.2 Proxy-Info AVP 3186 The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped 3187 Data field has the following ABNF grammar: 3189 Proxy-Info ::= < AVP Header: 284 > 3190 { Proxy-Host } 3191 { Proxy-State } 3192 * [ AVP ] 3194 6.8.3 Proxy-Host AVP 3196 The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This 3197 AVP contains the identity of the host that added the Proxy-Info AVP. 3199 6.8.4 Proxy-State AVP 3201 The Proxy-State AVP (AVP Code 33) is of type OctetString, and 3202 contains state local information, and MUST be treated as opaque data. 3204 6.8.5 Source-Route AVP 3206 The Source-Route AVP (AVP Code 286) is of type DiameterIdentity. 3207 This AVP is used for routing decisions by agents for server-initiated 3208 messages. The order of the Source-Route AVPs MUST be the inverse of 3209 the Route-Record AVPs of auth messages received by the server for the 3210 session in question. 3212 6.9 Auth-Application-Id AVP 3214 The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and 3215 is used in order to advertise support of the Authentication and 3216 Authorization portion of an application (see Section 2.5). The Auth- 3217 Application-Id MUST also be present in all Authentication and/or 3218 Authorization messages that are defined in a separate Diameter 3219 specification and have an Application ID assigned. 3221 This AVP SHOULD be placed as close to the Diameter header as 3222 possible. 3224 6.10 Acct-Application-Id AVP 3226 The Acct-application-Id AVP (AVP Code 259) is of type Unsigned32 and 3227 is used in order to advertise support of the Accounting portion of an 3228 application (see Section 2.5). The Acct-Application-Id MUST also be 3229 present in all Accounting messages that are defined in a separate 3230 Diameter specification and have an Application ID assigned. 3232 This AVP SHOULD be placed as close to the Diameter header as 3233 possible. 3235 6.11 Vendor-Specific-Application-Id AVP 3237 The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type 3238 Grouped and is used to advertise support of a vendor-specific 3239 Diameter Application. Either the Auth-Application-Id or the Acct- 3240 Application-Id AVP MAY be present. Both AVPs MAY be present if they 3241 both contain the same value. 3243 This AVP MUST also be present in all vendor-specific commands defined 3244 in the vendor-specific application. 3246 This AVP SHOULD be placed as close to the Diameter header as 3247 possible. 3249 AVP Format 3251 ::= < AVP Header: 260 > 3252 1* [ Vendor-Id ] 3253 0*1{ Auth-Application-Id } 3254 0*1{ Acct-Application-Id } 3256 6.12 Redirect-Host AVP 3258 The Redirect-Host AVP (AVP Code 292) is of type DiameterIdentity. 3259 This AVP MUST be present if the answer message's 'E' bit is set and 3260 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3262 Upon receiving the above, the receiving Diameter node SHOULD forward 3263 the request directly to the host identified in this AVP. The server 3264 contained in the Redirect-Host SHOULD be used for all messages 3265 pertaining to this session. 3267 6.13 Redirect-Host-Usage AVP 3268 The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. 3269 This AVP MAY be present in answer messages whose 'E' bit is set and 3270 the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. 3272 When present, this AVP dictates how the routing entry resulting from 3273 the Redirect-Host is to be used. The following values are supported: 3275 DONT_CACHE 0 3276 The host specified in the Redirect-Host AVP should not be 3277 cached. This is the default value. 3279 ALL_SESSION 1 3280 All messages within the same session, as defined by the same 3281 value of the Session-ID AVP MAY be sent to the host specified 3282 in the Redirect-Host AVP. 3284 ALL_REALM 2 3285 All messages destined for the realm requested MAY be sent to 3286 the host specified in the Redirect-Host AVP. 3288 REALM_AND_APPLICATION 3 3289 All messages for the application requested to the realm 3290 specified MAY be sent to the host specified in the Redirect- 3291 Host AVP. 3293 ALL_APPLICATION 4 3294 All messages for the application requested MAY be sent to the 3295 host specified in the Redirect-Host AVP. 3297 ALL_HOST 5 3298 All messages that would be sent to the host that generated the 3299 Redirect-Host MAY be sent to the host specified in the 3300 Redirect-Host AVP. 3302 6.14 Redirect-Max-Cache-Time AVP 3304 The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. 3305 This AVP MUST be present in answer messages whose 'E' bit is set, the 3306 Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 3307 Redirect-Host-Usage AVP set to a non-zero value. 3309 This AVP contains the maximum number of seconds the peer and route 3310 table entries, created as a result of the Redirect-Host, will be 3311 cached. Note that once a host created due to a redirect indication is 3312 no longer reachable, any associated peer and routing table entries 3313 MUST be deleted. 3315 7.0 Error Handling 3317 There are two different types of errors in Diameter; protocol and 3318 applications. A protocol error is one that occurs at the base 3319 protocol level, and MAY require per hop attention (e.g. message 3320 routing error). Application errors, on the other hand, are generally 3321 occur due to a problem with a function specified in a Diameter 3322 application (e.g. user authentication, Missing AVP). 3324 Result-Code AVP values that are used to report protocol errors MUST 3325 only be present in answer messages whose 'E' bit is set. When a 3326 request message is received that causes a protocol error, an answer 3327 message is returned with the 'E' bit set, and the Result-Code AVP is 3328 set to the appropriate protocol error value. As the answer is sent 3329 back towards the originator of the request, each proxy or relay agent 3330 MAY take action on the message. 3332 1. Request +---------+ Link Broken 3333 +-------------------------->|Diameter |----///----+ 3334 | +---------------------| | v 3335 +------+--+ | 2. answer + 'E' set | Relay 2 | +--------+ 3336 |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| 3337 | | | Home | 3338 | Relay 1 |--+ +---------+ | Server | 3339 +---------+ | 3. Request |Diameter | +--------+ 3340 +-------------------->| | ^ 3341 | Relay 3 |-----------+ 3342 +---------+ 3343 Figure 7 - Example of Protocol Error causing answer message 3345 Figure 7 provides an example of a message forwarded upstream by a 3346 Diameter relay. When the message is received by Relay 2, and it 3347 detects that it cannot forward the request to the home server, an 3348 answer message is returned with the 'E' bit set and the Result-Code 3349 AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls 3350 within the protocol error category, Relay 1 would take special 3351 action, and given the error, attempt to route the message through its 3352 alternate Relay 3. 3354 +---------+ 1. Request +---------+ 2. Request +---------+ 3355 | Access |------------>|Diameter |------------>|Diameter | 3356 | | | | | Home | 3357 | Device |<------------| Relay |<------------| Server | 3358 +---------+ 4. Answer +---------+ 3. Answer +---------+ 3359 (Missing AVP) (Missing AVP) 3360 Figure 8 - Example of Application Error Answer message 3362 Figure 8 provides an example of a Diameter message that caused an 3363 application error. When application errors occur, the Diameter entity 3364 reporting the error clears the 'R' bit in the Command Flags, and adds 3365 the Result-Code AVP with the proper value. Application errors do not 3366 require any proxy or relay agent involvement, and therefore the 3367 message would be forwarded back to the originator of the request. 3369 There are certain Result-Code AVP application errors that require 3370 additional AVPs to be present in the answer. In these cases, the 3371 Diameter node that sets the Result-Code AVP to indicate the error 3372 MUST add the AVPs. Examples are: 3374 - An unrecognized AVP is received with the 'M' bit (Mandatory bit) 3375 set, causes an answer to be sent with the Result-Code AVP set to 3376 DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the 3377 offending AVP. 3378 - An AVP that is received with an unrecognized value causes an 3379 answer to be returned with the Result-Code AVP set to 3380 DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing 3381 the AVP causing the error. 3382 - A command is received with an AVP that is omitted, yet is 3383 mandatory according to the command's ABNF. The receiver issues 3384 an answer with the Result-Code set to DIAMETER_MISSING_AVP, and 3385 creates an AVP with the AVP Code and other fields set to the 3386 missing AVP's. The created AVP is then added to the Failed-AVP 3387 AVP. 3389 The Result-Code AVP contains additional errors conditions, and 3390 defines the expected behavior of each. 3392 7.1 Result-Code AVP 3394 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 3395 indicates whether a particular request was completed successfully or 3396 whether an error occurred. All Diameter answer messages MUST include 3397 one Result-Code AVP. A non-successful Result-Code AVP (one containing 3398 a non 2xxx value) MUST include the Error-Reporting-Host AVP if the 3399 host setting the Result-Code AVP is different from the identity 3400 encoded in the Origin-Host AVP. 3402 The Result-Code data field contains an IANA-managed 32-bit address 3403 space representing errors (see section 11.4). Diameter provides the 3404 following classes of errors, all identified by the thousands digit: 3405 - 1xxx (Informational) 3406 - 2xxx (Success) 3407 - 3xxx (Protocol Errors) 3408 - 4xxx (Transient Failures) 3409 - 5xxx (Permanent Failure) 3411 A non-recognize class (one whose first digit is not defined in this 3412 section) MUST be handled as a permanent failure. 3414 7.1.1 Informational 3416 Errors that fall within this category are used to inform the 3417 requester that a request could not be satisfied, and additional 3418 action is required on its part before access is granted. 3420 DIAMETER_MULTI_ROUND_AUTH 1001 3421 This informational error is returned by a Diameter server to 3422 inform the access device that the authentication mechanism 3423 being used required multiple round trip, and a subsequent 3424 request needs to be issued in order for access to be granted. 3426 7.1.2 Success 3428 Errors that fall within the Success category are used to inform a 3429 peer that a request has been successfully completed. 3431 DIAMETER_SUCCESS 2001 3432 The Request was successfully completed. 3434 DIAMETER_LIMITED_SUCCESS 2002 3435 When returned, the request was successfully completed, but 3436 additional processing is required by the application in order 3437 to provide service to the user. 3439 7.1.3 Protocol Errors 3441 Errors that fall within the Protocol Error category SHOULD be treated 3442 on a per-hop basis, and Diameter proxies MAY attempt to correct the 3443 error, if it is possible. Note that these errors MUST only be used in 3444 answer messages whose 'E' bit is set. 3446 DIAMETER_INVALID_ROUTE_RECORD 3001 3447 The last Route-Record AVP in the message is not set to the 3448 identity of the sender of the message. See Section 9.0 for more 3449 information. 3451 DIAMETER_COMMAND_UNSUPPORTED 3002 3452 The Request contained a Command-Code that the receiver did not 3453 recognize or support. 3455 DIAMETER_UNABLE_TO_DELIVER 3003 3456 The realm requested is recognized, but no host within the realm 3457 was available to process the request. This event occurs if no 3458 Diameter server supporting the requested application is 3459 reachable within the intended realm. 3461 DIAMETER_REALM_NOT_SERVED 3004 3462 The intended realm of the request is not recognized. 3464 DIAMETER_TOO_BUSY 3005 3465 When returned, a Diameter node SHOULD attempt to send the 3466 message to an alternate peer. This error MUST only be used when 3467 a specific server is requested, and it cannot provide the 3468 requested service. 3470 DIAMETER_INVALID_CMS_DATA 3006 3471 The Request did not contain a valid CMS-Data [11] AVP. 3473 DIAMETER_LOOP_DETECTED 3007 3474 An agent detected a loop while trying to get the message to the 3475 Home Diameter server. The message MAY be sent to an alternate 3476 peer, if one is available, but the peer reporting the error has 3477 identified a configuration problem. 3479 DIAMETER_CMS_SECURITY 3008 3480 A proxy has detected that CMS security has been applied to 3481 portions of the Diameter message, and the proxy does not allow 3482 this security mode since it needs to alter the message by 3483 applying some local policies. 3485 DIAMETER_REDIRECT_INDICATION 3009 3486 A redirector has determined that the request could not be 3487 satisfied locally and the initiator of the request should 3488 direct the request directly to the server, whose contact 3489 information has been added to the response. When set, the 3490 Redirect-Host AVP MUST be present. 3492 DIAMETER_APPLICATION_UNSUPPORTED 3010 3493 A request was sent for an application that is not supported. 3495 DIAMETER_INVALID_HDR_BITS 3011 3496 A request was received whose bits in the Diameter header were 3497 either set to an invalid combination, or to a value that is 3498 inconsistent with the command code's definition. 3500 7.1.4 Transient Failures 3502 Errors that fall within the transient failures category are used to 3503 inform a peer that the request could not be satisfied at the time it 3504 was received, but MAY be able to satisfy the request in the future. 3506 DIAMETER_AUTHENTICATION_REJECTED 4001 3507 The authentication process for the user failed, most likely due 3508 to an invalid password used by the user. Further attempts MUST 3509 only be tried after prompting the user for a new password. 3511 DIAMETER_OUT_OF_SPACE 4002 3512 A Diameter node received the accounting request but was unable 3513 to commit it to stable storage due to a temporary lack of 3514 space. 3516 7.1.5 Permanent Failures 3518 Errors that fall within the permanent failures category are used to 3519 inform the peer that the request failed, and should not be attempted 3520 again. 3522 DIAMETER_USER_UNKNOWN 5001 3523 A request was received for a user that is unknown, therefore 3524 authentication and/or authorization failed. 3526 DIAMETER_AVP_UNSUPPORTED 5002 3527 The peer received a message that contained an AVP that is not 3528 recognized or supported and was marked with the Mandatory bit. 3529 A Diameter message with this error MUST contain one or more 3530 Failed-AVP AVP containing the AVPs that caused the failure. 3532 DIAMETER_UNKNOWN_SESSION_ID 5003 3533 The request contained an unknown Session-Id. 3535 DIAMETER_AUTHORIZATION_REJECTED 5004 3536 A request was received for which the user could not be 3537 authorized. This error could occur if the service requested is 3538 not permitted to the user. 3540 DIAMETER_INVALID_AVP_VALUE 5005 3541 The request contained an AVP with an invalid value in its data 3542 portion. A Diameter message indicating this error MUST include 3543 the offending AVPs within a Failed-AVP AVP. 3545 DIAMETER_MISSING_AVP 5006 3546 The request did not contain an AVP that is required by the 3547 Command Code definition. If this value is sent in the Result- 3548 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 3549 The Failed-AVP AVP MUST contain an example of the missing AVP 3550 complete with the Vendor-Id if applicable. The value field of 3551 the missing AVP should be of correct minimum length and contain 3552 zeroes. 3554 DIAMETER_RESOURCES_EXCEEDED 5007 3555 A request was received that cannot be authorized because the 3556 user has already expended allowed resources. An example of this 3557 error condition is a user that is restricted to one dial-up PPP 3558 port, attempts to establish a second PPP connection. 3560 DIAMETER_CONTRADICTING_AVPS 5008 3561 The Home Diameter server has detected AVPs in the request that 3562 contradicted each other, and is not willing to provide service 3563 to the user. One or more Failed-AVP AVPs MUST be present, 3564 containing the AVPs that contradicted each other. 3566 DIAMETER_AVP_NOT_ALLOWED 5009 3567 A message was received with an AVP that MUST NOT be present. 3568 The Failed-AVP AVP MUST be included and contain a copy of the 3569 offending AVP. 3571 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 3572 A message was received that included an AVP that appeared more 3573 often than permitted in the message definition. The Failed-AVP 3574 AVP MUST be included and contain a copy of the first instance 3575 of the offending AVP that exceeded the maximum number of 3576 occurrences 3578 DIAMETER_UNSUPPORTED_TRANSFORM 5011 3579 A message was received that included an CMS-Data AVP [11] that 3580 made use of an unsupported transform. 3582 DIAMETER_NO_COMMON_APPLICATION 5012 3583 This error is returned when a CEA message is received, and 3584 there are no common applications supported between the peer. 3586 DIAMETER_UNSUPPORTED_VERSION 5013 3587 This error is returned when a request was received, whose 3588 version number is unsupported. 3590 DIAMETER_UNABLE_TO_COMPLY 5014 3591 This error is returned when a request is rejected for 3592 unspecified reasons. 3594 DIAMETER_INVALID_BIT_IN_HEADER 5015 3595 This error is returned when an unrecognized bit in the Diameter 3596 header is set to one (1). 3598 DIAMETER_INVALID_AVP_LENGTH 5016 3599 The request contained an AVP with an invalid length. A Diameter 3600 message indicating this error MUST include the offending AVPs 3601 within a Failed-AVP AVP. 3603 DIAMETER_INVALID_MESSAGE_LENGTH 5017 3604 This error is returned when a request is received with an 3605 invalid message length. 3607 7.2 Error Bit 3609 The 'E' (Error Bit) in the Diameter header is set when the request 3610 caused a protocol-related error (see section 7.1.3). When set, the 3611 answer message will not conform to the ABNF specification for the 3612 command, and will instead conform to the following ABNF: 3614 Message Format 3616 ::= < Diameter Header: code, ERR > 3617 < Session-Id > 3618 { Origin-Host } 3619 { Origin-Realm } 3620 { Result-Code } 3621 { Destination-Host } 3622 [ Origin-State-Id ] 3623 [ Error-Reporting-Host ] 3624 * [ AVP ] 3626 Note that the code used in the header is the same that the one found 3627 in the request message, but with the 'R' bit cleared and the 'E' bit 3628 set. 3630 7.3 Error-Message AVP 3632 The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY 3633 accompany a Result-Code AVP as a human readable error message. The 3634 Error-Message AVP is not intended to be useful in real-time, and 3635 SHOULD NOT be expected to be parsed by network entities. 3637 7.4 Error-Reporting-Host AVP 3639 The Error-Reporting-Host AVP (AVP Code 294) is of type 3640 DiameterIdentity. This AVP contains the identity of the Diameter 3641 host that sent the Result-Code AVP to a value other than 2001 3642 (Success), only if the host setting the Result-Code is different from 3643 the one encoded in the Origin-Host AVP. This AVP is intended to be 3644 used for troubleshooting purposes, and MUST be set when the Result- 3645 Code AVP indicates a failure. 3647 7.5 Failed-AVP AVP 3649 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides 3650 debugging information in cases where a request is rejected or not 3651 fully processed due to erroneous information in a specific AVP. The 3652 value of the Result-Code AVP will provide information on the reason 3653 for the Failed-AVP AVP. 3655 The possible reasons for this AVP are the presence of an improperly 3656 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 3657 value, the omission of a required AVP, the presence of an explicitly 3658 excluded AVP (see tables in section 10.0), or the presence of two or 3659 more occurrences of an AVP which is restricted to 0, 1, or 0-1 3660 occurrences. 3662 A Diameter message MAY contain one Failed-AVP AVP, containing the 3663 entire AVP that could not be processed successfully. If the failure 3664 reason is omission of a required AVP, an AVP with the missing AVP 3665 code, the missing vendor id, and a zero filled payload of the minimum 3666 required length for the omitted AVP will be added. 3668 AVP Format 3670 ::= < AVP Header: 279 > 3671 1* {AVP} 3673 8.0 Diameter User Sessions 3675 Diameter can provide two different type of services to applications. 3676 The first involves authentication and authorization, and can 3677 optionally make use of accounting. The second only makes use of 3678 accounting. 3680 When a service makes use of the authentication and/or authorization 3681 portion of an application, and a user requests access to the network, 3682 the Diameter client issues an auth request to its local server. The 3683 auth request is defined in a service specific Diameter application 3684 (e.g. NASREQ). The request contains a Session-Id AVP, which is used 3685 in subsequent messages (e.g. subsequent authorization, accounting, 3686 etc) relating to the user's session. The Session-Id AVP is a means 3687 for the client and servers to correlate a Diameter message with a 3688 user session. 3690 When a Diameter server authorizes a user to use network resources for 3691 a finite amount of time, and it is willing to extend the 3692 authorization via a future request, it MUST add the Authorization- 3693 Lifetime AVP to the answer message. The Authorization-Lifetime AVP 3694 defines the maximum number of seconds a user MAY make use of the 3695 resources before another authorization request is expected by the 3696 server. The Auth-Grace-Period AVP contains the number of seconds 3697 following the expiration of the Authorization-Lifetime, after which 3698 the server will release an state information related to the user's 3699 session. Note that if payment for services is expected by the serving 3700 realm from the user's home realm, the Authorization-Lifetime AVP, 3701 combined with the Auth-Grace-Period AVP, implies the maximum length 3702 the session the home realm is willing to be fiscally responsible for. 3703 Services provided past the expiration of the Authorization-Lifetime 3704 and Auth-Grace-Perioc AVPs is the responsibility of the access 3705 device. Of course, the actual cost of services rendered is clearly 3706 outside the scope of the protocol. 3708 An access device that does not expect to send a re-authorization or a 3709 session termination request to the server MAY include the Auth- 3710 Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint 3711 to the server. If the server accepts the hint, it agrees that since 3712 no session termination message will be received once service to the 3713 user is terminated, it cannot maintain state for the session. If the 3714 answer message from the server contains a different value in the 3715 Auth-Session-State AVP (or the default value if the AVP is absent), 3716 the access device MUST follow the server's directives. Note that the 3717 value NO_STATE_MAINTAINED MUST NOT be set in subsequent re- 3718 authorization requests and answers. 3720 The base protocol does not include any authorization request 3721 messages, since these are largely application-specific and are 3722 defined in a Diameter application document. However, the base 3723 protocol does define a set of messages that are used to terminate 3724 user sessions. These are used to allow servers that maintain state 3725 information to free resources. 3727 When a service only makes use of the Accounting portion of the 3728 Diameter protocol, even in combination with an application, the 3729 Session-Id is still used to identify user sessions. However, the 3730 session termination messages are not used, since a session is 3731 signaled as being terminated by issuing an accounting stop message. 3733 8.1 Authorization Session State Machine 3735 This section contains a finite state machine, representing the life 3736 cycle of Diameter sessions, and MUST be observed by all Diameter 3737 implementations that makes use of the authentication and/or 3738 authorization portion of a Diameter application. The term Service- 3739 Specific below refers to a message defined in a Diameter application 3740 (e.g. Mobile IP, NASREQ). 3742 The following table contains the authorization session state machine. 3744 State Event Action New State 3745 ------------------------------------------------------------- 3746 Idle Client or Device Requests send Pending 3747 access service 3748 specific 3749 auth req 3751 Idle Service-Specific authorization send serv. Open 3752 request received, and specific 3753 successfully processed answer 3755 Pending Successful Service-Specific Grant Open 3756 Authorization answer Access 3757 received with default 3758 Auth-Session-State value 3760 Pending Successful Service-Specific Grant Active 3761 Authorization answer Access 3762 received with Auth-Session- 3763 State set to 3764 NO_SESSION_MAINTAINED 3766 Pending Successful Service-Specific Sent STR Discon 3767 authorization answer received 3768 but service not provided 3770 Pending Error processing successful Sent STR Discon 3771 Service-Specific authorization 3772 answer 3774 Open Authorization-Lifetime send Open 3775 expires on access device service 3776 specific 3777 auth req 3779 Open Successful Service-Specific Extend Open 3780 Authorization answer Access 3781 received 3783 Open Accounting message sent or process Open 3784 received 3786 Open Failed Service-Specific Discon. Closed 3787 Authorization answer user/device 3788 received. 3790 Open Session-Timeout Expires on send STR Discon 3791 Access Device 3793 Open ASR Received send ASA, Discon 3794 STR 3796 Open Authorization-Lifetime (and Cleanup Discon 3797 Auth-Grace-Period) expires 3798 on home server. 3800 Open Session-Timeout expires on Cleanup Discon 3801 home server 3803 Open ASA Received Cleanup Closed 3805 Discon ASR Received ignore Discon 3807 Discon STR Received Send STA Closed 3809 Discon STA Received Discon. Closed 3810 user/device 3812 Active Service to user is terminated Cleanup Closed 3814 Closed Transition to state Cleanup 3816 When the Cleanup action is invoked, the Diameter node MAY attempt to 3817 release all resources for the particular session. Any event not 3818 listed above MUST be considered as an error condition, and an answer, 3819 if applicable, MUST be returned to the originator of the message. 3821 8.2 Accounting Session State Machine 3823 For applications that only require accounting services, the following 3824 state machine MUST be supported. 3826 State Event Action New State 3827 ------------------------------------------------------------- 3828 Idle Client or device requests send Pending 3829 access accounting 3830 start req. 3832 Idle Accounting start request send Open 3833 received, and successfully accounting 3834 processed. start 3835 answer 3837 Pending Successful accounting grant Open 3838 start answer received access 3840 Open Receive Interim Record send Open 3841 accounting 3842 answer 3844 Open User service terminated send Discon 3845 accounting 3846 stop req. 3848 Open Accounting stop request send Closed 3849 received, and successfully accounting 3850 processed stop answer 3852 Discon Successful accounting discon. Closed 3853 stop answer received user/device 3855 8.3 Server-Initiated Re-Auth 3857 A Diameter server may initiate a re-authentication and/or re- 3858 authorization service for a particular session by issuing a Re-Auth- 3859 Request (RAR). 3861 For example, for pre-paid services, the Diameter server that 3862 originally authorized a session may need some confirmation that the 3863 user is still using the services. 3865 An access device that receives a RAR message with Session-Id equal to 3866 a currently active session MUST initiate a re-auth towards the user, 3867 if the service supports this particular feature. Each Diameter 3868 application MUST state whether service-initiated re-auth is 3869 supported, since some applications do not allow for access devices to 3870 prompt the user for re-auth. 3872 8.3.1 Re-Auth-Request 3874 The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 3875 and the message flags' 'R' bit set, may be sent by any server to the 3876 access device that is providing session service, to request that the 3877 user be re-authenticated and/or re-authorized. 3879 Message Format 3881 ::= < Diameter Header: 258, REQ, PXY > 3882 < Session-Id > 3883 { Origin-Host } 3884 { Origin-Realm } 3885 { Destination-Realm } 3886 { Destination-Host } 3887 { Re-Auth-Request-Type } 3888 [ Origin-State-Id ] 3889 * [ AVP ] 3890 * [ Proxy-Info ] 3891 * [ Route-Record ] 3892 * [ Source-Route ] 3894 8.3.2 Re-Auth-Answer 3896 The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 3897 and the message flags' 'R' bit clear, is sent in response to the RAR. 3898 The Result-Code AVP MUST be present, and indicates the disposition of 3899 the request. 3901 A successful RAA message MUST be followed by an application-specific 3902 authentication and/or authorization message. 3904 Message Format 3906 ::= < Diameter Header: 258, PXY > 3907 < Session-Id > 3908 { Result-Code } 3909 { Origin-Host } 3910 { Origin-Realm } 3911 { Destination-Host } 3912 [ Origin-State-Id ] 3913 * [ AVP ] 3914 * [ Proxy-Info ] 3915 * [ Route-Record ] 3917 8.4 Session Termination 3918 It is necessary for a Diameter server that authorized a session to be 3919 notified when that session is no longer active, both for tracking 3920 purposes as well as to allow stateful agents to release any resources 3921 that they may have provided for the user's session. 3923 When a user session that required Diameter authorization terminates, 3924 the access device that provided the service MUST issue a Session- 3925 Termination- Request (STR) message to the Diameter server that 3926 authorized the service, to notify it that the session is no longer 3927 active. An STR MUST be issued when a user session terminates for any 3928 reason, including user logoff, expiration of Session-Timeout, 3929 administrative action, termination upon receipt of an Abort-Session- 3930 Request (see below), orderly shutdown of the access device, etc. 3932 The access device also MUST issue an STR for a session that was 3933 authorized but never actually started. This could occur, for example, 3934 due to a sudden resource shortage in the access device, or because 3935 the access device is unwilling to provide the type of service 3936 requested in the authorization, or because the access device does not 3937 support a mandatory AVP returned in the authorization, etc. 3939 It is also possible that a session that was authorized is never 3940 actually started due to action of a proxy. For example, a proxy may 3941 modify an authorization answer, converting the result from success to 3942 failure, prior to forwarding the message to the access device. A 3943 proxy that causes an authorized session not to be started MUST issue 3944 an STR to the Diameter server that authorized the session, since the 3945 access device has no way of knowing that the session had been 3946 authorized. 3948 A Diameter server that receives an STR message MUST clean up 3949 resources (e.g., session state) associated with the Session-Id 3950 specified in the STR, and return a Session-Termination-Answer. 3952 A Diameter server also MUST clean up resources when the Session- 3953 Timeout expires, or when the Authorization-Lifetime and the Auth- 3954 Grace-Period AVPs expires without receipt of a re-authorization 3955 request, regardless of whether an STR for that session is received. 3956 The access device is not expected to provide service beyond the 3957 expiration of these timers; thus, expiration of either of these 3958 timers implies that the access device may have unexpectedly shut 3959 down. 3961 8.4.1 Session-Termination-Request 3963 The Session-Termination-Request (STR), indicated by the Command-Code 3964 set to 275 and the Command Flags' 'R' bit set, is sent by the access 3965 device to inform the Diameter Server that an authenticated and/or 3966 authorized session is being terminated. 3968 Message Format 3970 ::= < Diameter Header: 275, REQ, PXY > 3971 < Session-Id > 3972 { Origin-Host } 3973 { Origin-Realm } 3974 { Destination-Realm } 3975 { Destination-Host } 3976 { User-Name } 3977 { Termination-Cause } 3978 [ Origin-State-Id ] 3979 * [ AVP ] 3980 * [ Proxy-Info ] 3981 * [ Route-Record ] 3983 8.4.2 Session-Termination-Answer 3985 The Session-Termination-Answer (STA), indicated by the Command- Code 3986 set to 275 and the message flags' 'R' bit clear, is sent by the 3987 Diameter Server to acknowledge the notification that the session has 3988 been terminated. The Result-Code AVP MUST be present, and MAY contain 3989 an indication that an error occurred while servicing the STR. 3991 Upon sending or receipt of the STA, the Diameter Server MUST release 3992 all resources for the session indicated by the Session-Id AVP. Any 3993 intermediate server in the Proxy-Chain MAY also release any 3994 resources, if necessary. 3996 Message Format 3998 ::= < Diameter Header: 275, PXY > 3999 < Session-Id > 4000 { Result-Code } 4001 { Origin-Host } 4002 { Origin-Realm } 4003 { Destination-Host } 4004 { User-Name } 4005 [ Origin-State-Id ] 4006 * [ AVP ] 4007 * [ Proxy-Info ] 4008 * [ Route-Record ] 4010 8.5 Aborting a Session 4011 A Diameter server may request that the access device stop providing 4012 service for a particular session by issuing an Abort-Session-Request 4013 (ASR). 4015 For example, the Diameter server that originally authorized the 4016 session may be required to cause that session to be stopped for 4017 credit or other reasons that were not anticipated when the session 4018 was first authorized. Or, an operator may maintain a management 4019 server for the purpose of issuing ASRs to administratively remove 4020 users from the network. 4022 An access device that receives an ASR with Session-ID equal to a 4023 currently active session MAY stop the session. Whether the access 4024 device stops the session or not is implementation- and/or 4025 configuration- dependent. For example, an access device may honor 4026 ASRs from certain agents only. In any case, the access device MUST 4027 respond with an Abort-Session-Answer, including a Result-Code AVP to 4028 indicate what action it took. 4030 Note that if the access device does stop the session upon receipt of 4031 an ASR, it issues an STR to the authorizing server (which may or may 4032 not be the agent issuing the ASR) just as it would if the session 4033 were terminated for any other reason. 4035 8.5.1 Abort-Session-Request 4037 The Abort-Session-Request (ASR), indicated by the Command-Code set to 4038 274 and the message flags' 'R' bit set, may be sent by any server to 4039 the access device that is providing session service, to request that 4040 the session identified by the Session-Id be stopped. 4042 Message Format 4044 ::= < Diameter Header: 274, REQ, PXY > 4045 < Session-Id > 4046 { Origin-Host } 4047 { Origin-Realm } 4048 { Destination-Realm } 4049 { Destination-Host } 4050 [ Origin-State-Id ] 4051 * [ AVP ] 4052 * [ Proxy-Info ] 4053 * [ Route-Record ] 4055 8.5.2 Abort-Session-Answer 4056 The Abort-Session-Answer (ASA), indicated by the Command-Code set to 4057 274 and the message flags' 'R' bit clear, is sent in response to the 4058 ASR. The Result-Code AVP MUST be present, and indicates the 4059 disposition of the request. 4061 If the session identified by Session-Id in the ASR was successfully 4062 terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is 4063 not currently active, Result-Code is set to 4064 DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the 4065 session for any other reason, Result-Code is set to 4066 DIAMETER_UNABLE_TO_COMPLY. 4068 Message Format 4070 ::= < Diameter Header: 274, PXY > 4071 < Session-Id > 4072 { Result-Code } 4073 { Origin-Host } 4074 { Origin-Realm } 4075 { Destination-Host } 4076 [ Origin-State-Id ] 4077 * [ AVP ] 4078 * [ Proxy-Info ] 4079 * [ Route-Record ] 4081 8.6 Inferring Session Termination from Origin-State-Id 4083 Origin-State-Id is used to allow rapid detection of terminated 4084 sessions for which no STR would have been issued, due to 4085 unanticipated shutdown of an access device. 4087 By including Origin-State-Id in CER/CAA messages, an access device 4088 allows a next-hop server to determine immediately upon connection 4089 whether the device has lost its sessions since the last connection. 4091 By including Origin-State-Id in request messages, an access device 4092 also allows a server with which it communicates via proxy to make 4093 such a determination. However, a server that is not directly 4094 connected with the access device will not discover that the access 4095 device has been restarted unless and until it receives a new request 4096 from the access device. Thus, use of this mechanism across proxies is 4097 opportunistic rather than reliable, but useful nonetheless. 4099 When a Diameter server receives a Origin-State-Id that is greater 4100 than the Origin-State-Id previously received from the same issuer, it 4101 may assume that the issuer has lost state since the previous message 4102 and that all sessions that were active under the lower Origin-State- 4103 Id have been terminated. The Diameter server MAY clean up all session 4104 state associated with such lost sessions, and MAY also issues STRs 4105 for all such lost sessions that were authorized on upstream servers, 4106 to allow session state to be cleaned up globally. 4108 8.7 Auth-Request-Type AVP 4110 The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is 4111 included in application-specific auth requests to inform the peers 4112 whether a user is to be authenticated only, authorized only or both. 4113 Note any value other than both MAY cause RADIUS interoperability 4114 issues. The following values are defined: 4116 AUTHENTICATE_ONLY 1 4117 The request being sent is for authentication only, and MUST 4118 contain the relevant application specific authentication AVPs 4119 that are needed by the Diameter server to authenticate the 4120 user. 4122 AUTHORIZE_ONLY 2 4123 The request being sent is for authorization only, and MUST 4124 contain the application specific authorization AVPs that are 4125 necessary to identify the service being requested/offered. 4127 AUTHORIZE_AUTHENTICATE 3 4128 The request contains a request for both authentication and 4129 authorization. The request MUST include both the relevant 4130 application specific authentication information, and 4131 authorization information necessary to identify the service 4132 being requested/offered/. 4134 8.8 Session-Id AVP 4136 The Session-Id AVP (AVP Code 263) is of type UTF8String and is used 4137 to identify a specific session (see section 8.0). All messages 4138 pertaining to a specific session MUST include only one Session-Id AVP 4139 and the same value MUST be used throughout the life of a session. 4140 When present, the Session-Id SHOULD appear immediately following the 4141 Diameter Header (see section 3.0). 4143 The Session-Id MUST be globally and eternally unique, as it is meant 4144 to uniquely identify a user session without reference to any other 4145 information, and may be needed to correlate historical authentication 4146 information with accounting information. The Session-Id includes a 4147 mandatory portion and an implementation-defined portion; a 4148 recommended format for the implementation-defined portion is outlined 4149 below. 4151 The Session-Id MUST begin with the sender's identity encoded in the 4152 DiameterIdentity type (see section 4.4). The remainder of the 4153 Session-Id MAY be any sequence that the client can guarantee to be 4154 eternally unique; however, the following format is recommended, 4155 (square brackets [] indicate an optional element): 4157 ;;[;] 4159 and are decimal representations of the 4160 high and low 32 bits of a monotonically increasing 64-bit value. The 4161 64-bit value is rendered in two part to simplify formatting by 32-bit 4162 processors. At startup, the high 32 bits of the 64-bit value MAY be 4163 initialized to the time, and the low 32 bits MAY be initialized to 0. 4164 This will for practical purposes eliminate the possibility of 4165 overlapping Session-Ids after a reboot, assuming the reboot process 4166 takes longer than a second. Alternatively, an implementation MAY keep 4167 track of the increasing value in non-volatile memory. 4169 is implementation specific but may include a modem's 4170 device Id, a layer 2 address, timestamp, etc. 4172 Example, in which the standard port is used and there is no optional 4173 value: 4174 aaa://diameter/accesspoint7.acme.com;1876543210;523 4175 or 4176 accesspoint7.acme.com;1876543210;523 4178 Example, in which a non-standard port is used and there is an 4179 optional value: 4180 accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88 4182 The session Id is created by the Diameter device initiating the 4183 session, which in most cases is done by the client. Note that a 4184 Session-Id MAY be used for both the authorization and accounting 4185 commands of a given application. 4187 8.9 Authorization-Lifetime AVP 4189 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 4190 and contains the maximum number of seconds of service to be provided 4191 to the user before the user is to be re-authenticated and/or re- 4192 authorized. Great care should be taken when the Authorization- 4193 Lifetime value is determined, since a low, non-zero, value could 4194 create significant Diameter traffic, which could congest both the 4195 network and the agents. 4197 A value of zero (0) means that immediate re-auth is necessary by the 4198 access device. This is typically used in cases where multiple 4199 authentication methods are used, and a successful auth response with 4200 this AVP set to one is used to signal that the next authentication 4201 method is to be immediately initiated. The absence of this AVP, or a 4202 value of all ones (-1) means no re-auth is expected. 4204 If both this AVP and the Session-Timeout AVP are present in a 4205 message, the value of the latter MUST NOT be smaller than the 4206 Authorization-Lifetime AVP. 4208 An Authorization-Lifetime AVP MAY be present in a re-authorization 4209 messages, and contains the number of seconds the user is authorized 4210 to receive service from the time the re-auth answer message is 4211 received by the access device. 4213 This AVP MAY be provided by the client as a hint of the maximum 4214 lifetime that it is willing to accept. However, the server MAY return 4215 a value that is equal to, or smaller, than the one provided by the 4216 client. 4218 8.10 Auth-Grace-Period AVP 4220 The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and 4221 contains the number of seconds the Diameter server will wait 4222 following the expiration of the Authorization-Lifetime AVP before 4223 cleaning up resources for the session. 4225 This AVP MAY be provided by the client as a hint of the maximum 4226 lifetime that it is willing to accept. However, the server MAY return 4227 a value that is equal to, or smaller, than the one provided by the 4228 client. 4230 8.11 Auth-Session-State AVP 4232 The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and 4233 specifies whether state is maintained for a particular session. The 4234 client MAY include this AVP in requests as a hint to the server. The 4235 following values are supported: 4237 STATE_MAINTAINED 0 4238 This value is used to specify that session state is being 4239 maintained, and the access device MUST issue a session 4240 termination message when service to the user is terminated. 4241 This is the default value. 4243 NO_STATE_MAINTAINED 1 4244 This value is used to specify that no session termination 4245 messages will be sent by the access device upon expiration of 4246 the Authorization-Lifetime. 4248 8.12 Re-Auth-Request-Type AVP 4250 The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and 4251 is included in application-specific auth answers to inform the client 4252 of the action expected upon expiration of the Authorization-Lifetime. 4253 The following values are defined: 4255 AUTHORIZE_ONLY 0 4256 An authorization only re-auth is expected upon expiration of 4257 the Authorization-Lifetime. This is the default value if the 4258 AVP is not present in answer messages that include the 4259 Authorization-Lifetime. 4261 AUTHORIZE_AUTHENTICATE 1 4262 An authentication and authorization re-auth is expected upon 4263 expiration of the Authorization-Lifetime. 4265 8.13 Session-Timeout AVP 4267 The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and 4268 contains the maximum number of seconds of service to be provided to 4269 the user before termination of the session. When both the Session- 4270 Timeout and the Authorization-Lifetime AVPs are present in an answer 4271 message, the former MUST be equal to or greater than the value of the 4272 latter. 4274 A session that terminates on an access device due to the expiration 4275 of the Session-Timeout MUST cause an STR to be issued, unless both 4276 the access device and the home server had previously agreed that no 4277 session termination messages would be sent (see section 8.9). 4279 A Session-Timeout AVP MAY be present in a re-authorization messages, 4280 and contains the number of seconds from the beginning of the re-auth. 4282 A value of zero, or the absence of this AVP, means that this session 4283 has an unlimited number of seconds before termination. 4285 This AVP MAY be provided by the client as a hint of the maximum 4286 timeout that it is willing to accept. However, the server MAY return 4287 a value that is equal to, or smaller, than the one provided by the 4288 client. 4290 8.14 User-Name AVP 4292 The User-Name AVP (AVP Code 1) [1] is of type UTF8String, which 4293 contains the User-Name, in a format consistent with the NAI 4294 specification [8]. 4296 8.15 Termination-Cause AVP 4298 The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and 4299 is used to indicate the reason why a session was terminated on the 4300 access device. The following values are defined: 4302 DIAMETER_LOGOUT 1 4303 The user initiated a disconnect 4305 DIAMETER_SERVICE_NOT_PROVIDED 2 4306 This value is used when the user disconnected prior to the 4307 receipt of the authorization answer message. 4309 DIAMETER_BAD_ANSWER 3 4310 This value indicates that the authorization answer received by 4311 the access device was not processed successfully. 4313 DIAMETER_ADMINISTRATIVE 4 4314 The user was not granted access, or was disconnected, due to 4315 administrative reasons, such as the receipt of a Abort- 4316 Session-Request message. 4318 DIAMETER_LINK_BROKEN 5 4319 The communication to the user was abruptly disconnected. 4321 8.16 Origin-State-Id AVP 4323 The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a 4324 monotonically increasing value that is advanced whenever a Diameter 4325 entity restarts with loss of previous state, for example upon reboot. 4326 Origin-State-Id MAY be included in any Diameter message, including 4327 CER. 4329 A Diameter entity issuing this AVP MUST create a higher value for 4330 this AVP each time its state is reset. A Diameter entity MAY set 4331 Origin-State-Id to the time of startup, or it MAY use an incrementing 4332 counter retained in non-volatile memory across restarts. 4334 The Origin-State-Id, if present, MUST reflect the state of the entity 4335 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST 4336 either remove Origin-State-Id or modify it appropriately as well. 4338 Typically, Origin-State-Id is used by an access device that always 4339 starts up with no active sessions; that is, any session active prior 4340 to restart will have been been lost. By including Origin-State-Id in 4341 a message, it allows other Diameter entities to infer that sessions 4342 associated with a lower Origin-State-Id are no longer active. If an 4343 access device does not intend for such inferences to be made, it MUST 4344 either not include Origin-State-Id in any message, or set its value 4345 to 0. 4347 8.17 Session-Binding AVP 4349 The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY 4350 be present in application-specific authorization answer messages. If 4351 present, this AVP MAY inform the Diameter client that all future 4352 application-specific re-auth messages for this session MUST be sent 4353 to the same authorization server. This AVP MAY also specify that a 4354 Session-Termination-Request message for this session MUST be sent to 4355 the same authorizing server. 4357 This field is a bit mask, and the following bits have been defined: 4359 RE_AUTH 1 4360 When set, future re-auth messages for this session MUST NOT 4361 include the Destination-Host AVP. When cleared, the default 4362 value, the Destination-Host AVP MUST be present in all re-auth 4363 messages for this session. 4365 STR 2 4366 When set, the STR message for this session MUST NOT include the 4367 Destination-Host AVP. When cleared, the default value, the 4368 Destination-Host AVP MUST be present in the STR message for 4369 this session. 4371 ACCOUNTING 4 4372 When set, all accounting messages for this session MUST NOT 4373 include the Destination-Host AVP. When cleared, the default 4374 value, the Destination-Host AVP MUST be present in all 4375 accounting messages for this session. 4377 8.18 Session-Server-Failover AVP 4379 The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated, 4380 and MAY be present in application-specific authorization answer 4381 messages that either do not include the Session-Binding AVP or 4382 include the Session-Binding AVP with any of the bits set to a zero 4383 value. If present, this AVP MAY inform the Diameter client that if a 4384 re-auth or STR message fails due to a delivery problem, the Diameter 4385 client SHOULD issue a subsequent message without the Destination-Host 4386 AVP. When absent, the default value is REFUSE_SERVICE. 4388 The following values are supported: 4390 REFUSE_SERVICE 0 4391 If either the re-auth or the STR message delivery fails, 4392 terminate service with the user, and do not attempt any 4393 subsequent attempts. 4395 TRY_AGAIN 1 4396 If either the re-auth or the STR message delivery fails, resend 4397 the failed message without the Destination-Host AVP present. 4399 ALLOW_SERVICE 2 4400 If re-auth message delivery fails, assume that re-authorization 4401 succeeded. If STR message delivery fails, terminate the 4402 session. 4404 TRY_AGAIN_ALLOW_SERVICE 3 4405 If either the re-auth or the STR message delivery fails, resend 4406 the failed message without the Destination-Host AVP present. 4407 If the second delivery fails for re-auth, assume re- 4408 authorization succeeded. If the second delivery fails for STR, 4409 terminate the session. 4411 8.19 Multi-Round-Time-Out AVP 4413 The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32, 4414 and SHOULD be present in application-specific authorization answer 4415 messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. 4416 This AVP contains the maximum number of seconds that the access 4417 device MUST provide the user in responding to an authentication 4418 request. 4420 8.20 Class AVP 4422 The Class AVP (AVP Code 25) is of type OctetString and is used to by 4423 Diameter servers to return state information to the access device. 4424 When one or more Class AVPs are present in application-specific 4425 authorization answer messages, they MUST be present in subsequent 4426 re-authorization, session termination and accounting messages. Class 4427 AVPs found in a re-authorization answer message override the ones 4428 found in any previous authorization answer message. Diameter server 4429 implementations SHOULD NOT return Class AVPs that require more than 4430 4096 bytes of storage on the Diameter client. A Diameter client that 4431 receives Class AVPs whose size exceeds local available storage MUST 4432 terminate the session. 4434 9.0 Accounting 4436 This accounting protocol is based on a server directed model with 4437 capabilities for real-time delivery of accounting information. 4438 Several fault resilience methods [40] have been built in to the 4439 protocol in order minimize loss of accounting data in various fault 4440 situations and under different assumptions about the capabilities of 4441 the used devices. 4443 9.1 Server Directed Model 4445 The server directed model means that the device generating the 4446 accounting data gets information from either the authorization server 4447 (if contacted) or the accounting server regarding the way accounting 4448 data shall be forwarded. This information includes accounting record 4449 timeliness requirements. 4451 As discussed in [40], real-time transfer of accounting records is a 4452 requirement, such as the need to perform credit limit checks and 4453 fraud detection. Note that batch accounting is not a requirement, and 4454 is therefore not supported by Diameter. Should Batched Accounting be 4455 required in the future, a new Diameter application will need to be 4456 created, or it could be handled using another protocol. 4458 The authorization server (chain) directs the selection of proper 4459 transfer strategy, based on its knowledge of the user and 4460 relationships of roaming partnerships. The server (or agents) uses 4461 the Accounting-Interim-Interval AVP to control the operation of the 4462 Diameter peer operating as a client. The Accounting-Interim-Interval 4463 AVP, when present, instructs the Diameter node acting as a client to 4464 produce accounting records continuously even during a session. 4466 The Diameter accounting server MAY override the interim interval by 4467 including an Accounting-Interim-Interval AVP in the Accounting-Answer 4468 message. When the AVP is present, the latest value received SHOULD be 4469 used in the generation of interim accounting messages. 4471 9.2 Protocol Messages 4472 A Diameter node that receives a successful authentication and/or 4473 authorization messages from the Home AAA Server, MUST collect 4474 accounting information for the session. The Accounting-Request 4475 message is used to transmit the accounting information to the Home 4476 AAA server, which MUST reply with the Accounting-Answer message to 4477 confirm reception. The Accounting-Answer message includes the 4478 Result-Code AVP, which MAY indicate that an error was present in the 4479 accounting message. A rejected Accounting-Request message SHOULD 4480 cause the user's session to be terminated. 4482 Each Diameter Accounting protocol message MAY be compressed using 4483 IPComp [41] in order to reduce the used network bandwidth, which MAY 4484 use IKE [15] to negotiate the compression parameters. 4486 9.3 Application document requirements 4488 Each Diameter application (e.g. NASREQ, MobileIP), MUST define their 4489 Service-Specific AVPs that MUST be present in the Accounting-Request 4490 message in a section entitled "Accounting AVPs". The application MUST 4491 assume that the AVPs described in this document will be present in 4492 all Accounting messages, so only their respective service-specific 4493 AVPs need to be defined in this section. 4495 9.4 Fault Resilience 4497 Diameter Base protocol mechanisms are used to overcome small message 4498 loss and network faults of temporary nature. 4500 Diameter peers acting as clients MUST implement the use of failover 4501 to guard against server failures and certain network failures. 4502 Diameter peers acting as agents or related off-line processing 4503 systems MUST detect duplicate accounting records caused by the 4504 sending of same record to several servers and duplication of messages 4505 in transit. This detection MUST be based on the inspection of the 4506 Session-Id and Accounting-Record-Number AVP pairs. 4508 Diameter clients MAY have non-volatile memory for the safe storage of 4509 accounting records over reboots or extended network failures, network 4510 partitions, and server failures. If such memory is available the 4511 client SHOULD store new accounting records there as soon as the 4512 records are created and until a positive acknowledgement of their 4513 reception from the Diameter Server has been received. Upon a reboot, 4514 the client MUST starting sending the records in the non-volatile 4515 memory to the accounting server with appropriate modifications in 4516 termination cause, session length, and other relevant information in 4517 the records. 4519 A further application of this protocol may include AVPs to control 4520 how many accounting records may at most be stored in the Diameter 4521 client without committing them to the non-volatile memory or 4522 transferring them to the Diameter server. 4524 The client SHOULD NOT remove the accounting data from any of its 4525 memory areas before the correct Accounting-Answer has been received. 4526 The client MAY remove oldest, undelivered or yet unacknowledged 4527 accounting data if it runs out of resources such as memory. It is an 4528 implementation dependent matter for the client to accept new sessions 4529 under this condition. 4531 9.5 Accounting Records 4533 In all accounting records the Session-Id and User-Name AVPs MUST be 4534 present. If end-to-end authentication is required, as described in 4535 [11], the CMS-Data AVP may be used to authenticate the Accounting 4536 Data and Service Specific AVPs. It is not typically necessary, nor 4537 recommended, that the end-to-end authentication cover any additional 4538 AVPs since the Data and Service Specific AVP, and associated CMS- 4539 Data, MAY need to be submitted to a third party. 4541 Different types of accounting records are sent depending on the 4542 actual type of accounted service and the authorization server's 4543 directions for interim accounting. If the accounted service is a 4544 one-time event, meaning that the start and stop of the event are 4545 simultaneous, then the Accounting-Record-Type AVP MUST be present and 4546 set to the value EVENT_RECORD. 4548 If the accounted service is of a measurable length, then the AVP MUST 4549 use the values START_RECORD, STOP_RECORD, and possibly, 4550 INTERIM_RECORD. If the authorization server has directed interim 4551 accounting to be enabled for the session, but no interim interval was 4552 specified, two accounting records MUST be generated for each service 4553 of type session. When the initial Accounting-Request is sent for a 4554 given session is sent, the Accounting-Record-Type AVP MUST be set to 4555 the value START_RECORD. When the last Accounting-Request is sent, the 4556 value MUST be STOP_RECORD. 4558 If a specified interim interval exists, the Diameter client MUST 4559 produce additional records between the START_RECORD and STOP_RECORD, 4560 marked INTERIM_RECORD. The production of these records is directed 4561 both by Accounting-Interim-Interval as well as any re-authentication 4562 or re-authorization of the session. The Diameter client MUST 4563 overwrite any previous interim accounting records that are locally 4564 stored for delivery, if a new record is being generated for the same 4565 session. This ensures that only one pending interim record can exist 4566 on an access device for any given session. 4568 A particular value of Accounting-Session-Id MUST appear only in one 4569 sequence of accounting records from a DIAMETER client, except for the 4570 purposes of retransmission. The one sequence that is sent MUST be 4571 either one record with Accounting-Record-Type AVP set to the value 4572 EVENT_RECORD, or several records starting with one having the value 4573 START_RECORD, followed by zero or more INTERIM_RECORD, and a single 4574 STOP_RECORD. A particular Diameter application specification MUST 4575 define the type of sequences that MUST be used. 4577 9.6 Correlation of Accounting Records 4579 The Diameter protocol's Session-Id AVP, which is globally unique (see 4580 section 8.8), is used during the authorization phase to identify a 4581 particular session. Services that do not require any authorization 4582 still use the Session-Id AVP to identify sessions. 4584 However, there are certain applications that require multiple 4585 accounting sub-sessions. Such applications would send messages with a 4586 constant Session-Id AVP, but a different Accounting-Session-Id AVP. 4587 In these cases, correlation is performed using the Session-Id. 4589 Furthermore, there are certain applications where a user receives 4590 service from different access devices (e.g. Mobile IP), each with 4591 their own unique Session-Id. In such cases, the Accounting-Multi- 4592 Session-Id AVP is used for correlation. During authorization, a 4593 server that determines that a request is for an existing session, 4594 SHOULD include the Accounting-Multi-Session-Id AVP, which the access 4595 device MUST include in all subsequent accounting messages. 4597 The Accounting-Multi-Session-Id AVP MAY include the value of the 4598 original Session-Id. It's contents are implementation specific, but 4599 MUST be globally unique across other Accounting-Multi-Session-Id, and 4600 MUST NOT change during the life of a session. 4602 A Diameter application document MUST define the exact concept of a 4603 session that is being accounted, and MAY define the concept of a 4604 multi-session. For instance, the NASREQ DIAMETER application treats a 4605 single PPP connection to a Network Access Server as one session, and 4606 a set of Multilink PPP sessions as one multi-session. 4608 9.7 Accounting Command-Codes 4610 This section defines new Command-Code values that MUST be supported 4611 by all Diameter implementations that provide Accounting services. 4613 9.7.1 Accounting-Request 4615 The Accounting-Request command, indicated by the Command-Code field 4616 set to 271 and the Command Flags' 'R' bit set, is sent by a Diameter 4617 node, acting as a client, in order to exchange accounting information 4618 with a peer. 4620 When the Accounting-Request is being submitted to a third party (e.g. 4621 settlement service), and includes the CMS-Data AVP [11], the CMS-Data 4622 AVP MUST be signed by both the local and home Diameter server using 4623 the countersignature procedures described in [11]. 4625 The AVP listed below SHOULD include service specific accounting AVPs, 4626 as described in section 9.3. 4628 Message Format 4630 ::= < Diameter Header: 271, REQ, PXY > 4631 < Session-Id > 4632 { Acct-Application-Id } 4633 { User-Name } 4634 { Origin-Host } 4635 { Origin-Realm } 4636 { Destination-Realm } 4637 { Accounting-Record-Type } 4638 { Accounting-Record-Number } 4639 { Accounting-Session-Id } 4640 [ Accounting-Interim-Interval ] 4641 [ Origin-State-Id ] 4642 * [ AVP ] 4643 * [ Proxy-Info ] 4644 * [ Route-Record ] 4646 9.7.2 Accounting-Answer 4648 The Accounting-Answer command, indicated by the Command-Code field 4649 set to 271 and the Command Flags' 'R' bit cleared, is used to 4650 acknowledge an Accounting-Request command. The Accounting-Answer 4651 command contains the same Session-Id and MAY contains the same 4652 Accounting Description and Usage AVPs that were sent in the 4653 Accounting-Request command. If the CMS-Data AVP was present in the 4654 Accounting-Request, the corresponding ACA message MUST include the 4655 CMS-Data AVP signed by the responder to provide strong AVP 4656 authentication, which MAY be used for the purposes of repudiation. 4658 Only the target Diameter Server, known as the home Diameter Server, 4659 SHOULD respond with the Accounting-Answer command. 4661 The AVP listed below SHOULD include service specific accounting AVPs, 4662 as described in section 9.3. 4664 Message Format 4666 ::= < Diameter Header: 271, PXY > 4667 < Session-Id > 4668 { Acct-Application-Id } 4669 { User-Name } 4670 { Result-Code } 4671 { Origin-Host } 4672 { Origin-Realm } 4673 { Destination-Host } 4674 { Accounting-Record-Type } 4675 { Accounting-Record-Number } 4676 { Accounting-Session-Id } 4677 [ Error-Reporting-Host ] 4678 [ Accounting-Interim-Interval ] 4679 [ Origin-State-Id ] 4680 * [ AVP ] 4681 * [ Proxy-Info ] 4682 * [ Route-Record ] 4684 9.8 Accounting AVPs 4686 This section contains AVPs that describe accounting usage information 4687 related to a specific session. 4689 9.8.1 Accounting-Record-Type AVP 4691 The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated 4692 and contains the type of accounting record being sent. The following 4693 values are currently defined for the Accounting-Record-Type AVP: 4695 EVENT_RECORD 1 4696 An Accounting Event Record is used to indicate that a one-time 4697 event has occurred (meaning that the start and end of the event 4698 are simultaneous). This record contains all information 4699 relevant to the service, and is the only record of the service. 4701 START_RECORD 2 4702 An Accounting Start, Interim, and Stop Records are used to 4703 indicate that a service of a measurable length has been given. 4704 An Accounting Start Record is used to initiate an accounting 4705 session, and contains accounting information that is relevant 4706 to the initiation of the session. 4708 INTERIM_RECORD 3 4709 An Interim Accounting Record contains cumulative accounting 4710 information for an existing accounting session. Interim 4711 Accounting Records SHOULD be sent every time a re- 4712 authentication or re-authorization occurs. Further, additional 4713 interim record triggers MAY be defined by application-specific 4714 Diameter applications. The selection of whether to use 4715 INTERIM_RECORD records is directed by the Accounting-Interim- 4716 Interval AVP. 4718 STOP_RECORD 4 4719 An Accounting Stop Record is sent to terminate an accounting 4720 session and contains cumulative accounting information relevant 4721 to the existing session. 4723 9.8.2 Accounting-Interim-Interval AVP 4725 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 4726 Unsigned32 and is sent from the Diameter home authorization server to 4727 the Diameter client. The client uses information in this AVP to 4728 decide how and when to produce accounting records. With different 4729 values in this AVP, service sessions can result in one, two, or two+N 4730 accounting records, based on the needs of the home-organization. The 4731 following accounting record production behavior is directed by the 4732 inclusion of this AVP: 4734 1. The omission of the Accounting-Interim-Interval AVP or its 4735 inclusion with Value field set to 0 means that EVENT_RECORD, 4736 START_RECORD, and STOP_RECORD are produced, as appropriate for 4737 the service. 4739 2. The inclusion of the AVP with Value field set to a non-zero 4740 value means that INTERIM_RECORD records MUST be produced 4741 between the START_RECORD and STOP_RECORD records. The Value 4742 field of this AVP is the nominal interval between these records 4743 in seconds. The Diameter node that originates the accounting 4744 information, known as the client, MUST produce the first 4745 INTERIM_RECORD record roughly at the time when this nominal 4746 interval has elapsed from the START_RECORD, the next one again 4747 as the interval has elapsed once more, and so on until the 4748 session ends and a STOP_RECORD record is produced. 4750 The client MUST ensure that the interim record production times 4751 are randomized so that large accounting message storms are not 4752 created either among records or around a common service start 4753 time. 4755 9.8.3 Accounting-Record-Number AVP 4757 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 4758 and identifies this record within one session. As Session-Id AVPs are 4759 globally unique, the combination of Session-Id and Accounting- 4760 Record-Number AVPs is also globally unique, and can be used in 4761 matching accounting records with confirmations. An easy way to 4762 produce unique numbers is to set the value to 0 for records of type 4763 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 4764 INTERIM_RECORD, 2 for the second, and so on until the value for 4765 STOP_RECORD is one more than for the last INTERIM_RECORD. 4767 9.8.4 Accounting-Session-Id AVP 4769 The Accounting-Session-Id AVP (AVP Code 44) is of type UTF8String, 4770 following the format specified in section 8.8. The Accounting- 4771 Session-Id is not used by the Diameter protocol, since the Session-Id 4772 defined in [1] is used for both authentication/authorization and 4773 accounting purposes. However, a RADIUS/Diameter gateway MAY need to 4774 include the Accounting-Session-Id in Diameter accounting messages. 4776 9.8.5 Accounting-Multi-Session-Id AVP 4778 The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type 4779 UTF8String, following the format specified in section 8.8. The 4780 Accounting-Multi-Session-Id AVP is used to link together multiple 4781 related accounting sessions, where each session would have a unique 4782 Accounting-Session-Id, but the same Accounting-Multi-Session-Id AVP. 4783 This AVP MAY be returned by the Diameter server in an authorization 4784 answer, and MUST be used in all accounting messages for the given 4785 session. 4787 10.0 AVP Occurrence Table 4789 The following tables presents the AVPs defined in this document, and 4790 specifies in which Diameter messages they MAY, or MAY NOT be present. 4791 Note that AVPs that can only be present within a Grouped AVP are not 4792 represented in this table. 4794 The table uses the following symbols: 4795 0 The AVP MUST NOT be present in the message. 4796 0+ Zero or more instances of the AVP MAY be present in the 4797 message. 4798 0-1 Zero or one instance of the AVP MAY be present in the 4799 message. It is considered an error if there are more than 4800 once instance of the AVP. 4801 1 One instance of the AVP MUST be present in the message. 4802 1+ At least one instance of the AVP MUST be present in the 4803 message. 4805 10.1 Base Protocol Command AVP Table 4807 The table in this section is limited to the non-accounting Command 4808 Codes defined in this specification. 4810 +-----------------------------------------------+ 4811 | Command-Code | 4812 |---+---+---+---+---+---+---+---+---+---+---+---+ 4813 Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| 4814 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 4815 Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4816 Alternate-Peer |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4817 Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4818 Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4819 Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4820 Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4821 Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4822 Lifetime | | | | | | | | | | | | | 4823 Class |0 |0 |0 |0 |0+ |0 |0 |0 |0 |0 |0+ |0+ | 4824 Destination-Host |0-1|0 |1 |1 |0-1|0 |1 |1 |1 |0 |0-1|0 | 4825 Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | 4826 Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4827 Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| 4828 Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 4829 Failed-AVP |0 |0+ |0 |0 |0 |0+ |0 |0 |0 |0+ |0 |0+ | 4830 Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4831 Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4832 Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4833 Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 4834 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 | 4835 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| 4836 Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4837 Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ | 4838 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ | 4839 Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 4840 Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1| 4841 Time | | | | | | | | | | | | | 4842 Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 | 4843 Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 | 4844 Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0+ |0+ |0+ | 4845 Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4846 Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | 4847 Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4848 Failover | | | | | | | | | | | | | 4849 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4850 Source-Route |0 |0 |0 |0 |0 |0 |0+ |0 |0 |0 |0 |0 | 4851 Supported-Vendor-Id |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 4852 Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 | 4853 User-Name |0 |0 |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 | 4854 Vendor-Id |1 |1 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 | 4855 Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0+ |0 |0 |0 |0 | 4856 Application-Id | | | | | | | | | | | | | 4857 --------------------|---+---+---+---+---+---+---+---+---+---+---+---| 4859 10.2 Accounting AVP Table 4861 The table in this section is used to represent which AVPs defined in 4862 this document are to be present in the Accounting messages. 4863 +-----------+ 4864 | Command | 4865 | Code | 4866 |-----+-----+ 4867 Attribute Name | ACR | ACA | 4868 ------------------------------|-----+-----+ 4869 Accounting-Interim-Interval | 0-1 | 0-1 | 4870 Accounting-Multi-Session-Id | 0-1 | 0-1 | 4871 Accounting-Record-Number | 1 | 1 | 4872 Accounting-Record-Type | 1 | 1 | 4873 Accounting-Session-Id | 1 | 1 | 4874 Acct-Application-Id | 1 | 1 | 4875 Class | 0+ | 0+ | 4876 Destination-Host | 0-1 | 0 | 4877 Destination-Realm | 1 | 0 | 4878 Error-Reporting-Host | 0 | 0+ | 4879 Max-Time-Wait | 0+ | 0 | 4880 Origin-Host | 1 | 1 | 4881 Origin-Realm | 1 | 1 | 4882 Proxy-Info | 0+ | 0+ | 4883 Route-Record | 0+ | 0+ | 4884 Result-Code | 0 | 1 | 4885 Session-Id | 1 | 1 | 4886 ------------------------------|-----+-----+ 4888 11.0 IANA Considerations 4890 This document defines a number of assigned numbers to be maintained 4891 by the IANA. This section explains the criteria to be used by the 4892 IANA to assign additional numbers in each of these lists. The 4893 following subsections describe the assignment policy for the 4894 namespaces defined elsewhere in this document. 4896 11.1 AVP 4898 As defined in section 4.0, the AVP header contains two fields that 4899 requires IANA namespace management; the AVP Code and Flags field. 4901 11.1.1 AVP Code 4903 the AVP Code namespace is used to identify attributes. When the 4904 Vendor ID value is set to zero (0), IANA will maintain a registry of 4905 assigned AVP codes, and in some cases also their values. AVP Codes 4906 0-254 are managed separately as RADIUS Attribute Types [46], while 4907 the remaining namespace is available for assignment via Specification 4908 Required [12]. 4910 Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP 4911 header is set to a non-zero value, is for Private Use. 4913 This document defines the AVP Codes 257-286, 291-297, 480, 482 and 4914 485-486. See section 4.6 for the assignment of the namespace in this 4915 specification. 4917 11.1.2 AVP Flags 4919 There are 8 bits in the AVP Flags field of the AVP header, defined in 4920 section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7 4921 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only 4922 be assigned via a Standards Action [12]. 4924 11.2 Diameter Header 4926 As defined in section 3.0, the Diameter header contains two fields 4927 that require IANA namespace management; Command Code and Command 4928 Flags. 4930 11.2.1 Command Codes 4932 The Command Code namespace is used to identify Diameter commands. 4933 The values 0-255 are reserved for RADIUS backward compatibility, and 4934 are defined as "RADIUS Packet Type Codes" in [46]. The remaining 4935 values are available via Standards Action [12]. 4937 Vendor-Specific Command Codes, where the Vendor-Id field in the 4938 Diameter header is set to a non-zero value, is for Private Use. 4940 This document defines the Command Codes 257, 258, 271, 274-275, 280 4941 and 282. See section 3.1 for the assignment of the namespace in this 4942 specification. 4944 11.2.2 Command Flags 4946 There are eight bits in the Command Flags field of the Diameter 4947 header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and 4948 bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a 4949 Standards Action [12]. 4951 11.3 Application Identifiers 4953 As defined in section 2.5, the Application Identifier is used to 4954 identify a specific Diameter Application. All values, other than zero 4955 (0) are available for assignment via Standards Action [12]. 4957 Vendor-Specific Application Identifiers, encoded in the Vendor- 4958 Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to 4959 the vendor's enterprise number, is for Private Use. 4961 Note that the Diameter protocol is not intended to be extended for 4962 any purpose. Any applications defined MUST ensure that they fit 4963 within the existing framework, and that no changes to the base 4964 protocol are required. 4966 11.4 Result-Code AVP Values 4968 As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines 4969 the values 1001, 2001-2002, 3001-3011, 4001-4003 and 5001-5017. 4971 All remaining values are available for assignment via IETF Consensus 4972 [12]. 4974 11.5 Accounting-Record-Type AVP Values 4976 As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 4977 480) defines the values 1-4. All remaining values are available for 4978 assignment via IETF Consensus [12]. 4980 11.6 Termination-Cause AVP Values 4982 As defined in Section 8.14, the Termination-Cause AVP (AVP Code 295) 4983 defines the values 1-5. All remaining values are available for 4984 assignment via IETF Consensus [12]. 4986 11.7 Redirect-Host-Usage AVP Values 4988 As defined in Section 6.13, the Redirect-Host-Usage AVP (AVP Code 4989 261) defines the values 0-5. All remaining values are available for 4990 assignment via IETF Consensus [12]. 4992 11.8 Session-Server-Failover AVP Values 4994 As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 4995 271) defines the values 0-3. All remaining values are available for 4996 assignment via IETF Consensus [12]. 4998 11.9 Session-Binding AVP Values 5000 As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) 5001 defines the bits 1-4. All remaining bits are available for assignment 5002 via IETF Consensus [12]. 5004 11.10 Diameter TCP/SCTP Port Numbers 5006 An IANA request has been placed for TCP and SCTP port numbers. The 5007 IANA has informed the authors that "TBD" should be used in section 5008 2.1 this document, and will be updated by the RFC editor during the 5009 RFC publication process. 5011 IANA should also replace "TBD" in sections 4.4 and 5.2 with the port 5012 number assigned in section 2.1. 5014 11.11 Disconnect-Cause AVP Values 5016 As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) 5017 defines the values 0-2. All remaining values are available for 5018 assignment via IETF Consensus [12]. 5020 11.12 Auth-Request-Type AVP Values 5022 As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) 5023 defines the values 1-3. All remaining values are available for 5024 assignment via IETF Consensus [27]. 5026 11.13 Auth-Session-State AVP Values 5028 As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) 5029 defines the values 0-1. All remaining values are available for 5030 assignment via IETF Consensus [27]. 5032 11.14 Re-Auth-Request-Type AVP Values 5033 As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 5034 285) defines the values 0-1. All remaining values are available for 5035 assignment via IETF Consensus [27]. 5037 12.0 Diameter protocol related configurable parameters 5039 This section contains the configurable parameters that are found 5040 throughout this document: 5042 Diameter Peer 5043 A Diameter entity MAY communicate with peers that are 5044 statically configured. A statically configured Diameter peer 5045 would require that either the IP address or the fully qualified 5046 domain name (FQDN) be supplied, which would then be used to 5047 resolve through DNS. 5049 Realm Routing Table 5050 A Diameter Proxy server routes messages based on the realm 5051 portion of a Network Access Identifier (NAI). The server MUST 5052 have a table of Realms Names, and the address of the peer to 5053 which the message must be forwarded to. The routing table MAY 5054 also include a "default route", which is typically used for all 5055 messages that cannot be locally processed. 5057 Tc timer 5058 The Tc timer controls the frequency that transport connection 5059 attempts are done to a peer with whom no active transport 5060 connection exists. The recommended value is 30 seconds. 5062 Td timer 5063 The Td timer controls the termination of connections with peer 5064 in the SUSPECT state. The recommended value is 5 seconds. 5066 Ti timer 5067 The Ti timer controls the frequency the watchdog messages are 5068 to be sent to idle peers. The recommended value is 30 seconds. 5070 Tr timer 5071 The Tr timer controls the frequency the watchdog messages are 5072 to be sent to peers when there are pending requests, but not 5073 messages have been received from the peer. The recommended 5074 value is 10 seconds. 5076 Tw timer 5077 The Tw timer controls the changing of a peer to the SUSPECT 5078 state when no answer is received to a watchdog request. The 5079 recommended value is 5 seconds. 5081 13.0 Security Considerations 5083 The Diameter base protocol assumes that messages are secured by using 5084 either IP Security, or TLS. This security model is acceptable in 5085 environments where there are no untrusted third party relay, proxy, 5086 or redirect servers. 5088 When third party brokers or redirect servers are used, strong 5089 application level security SHOULD be required, such as non- 5090 repudiation. When the communicating peers do require this level of 5091 security either for legal or business purposes, the Diameter 5092 application defined in [11] MAY be used. This security model provides 5093 AVP-level authentication, and the encryption mechanism is designed 5094 such that only the target host has the keying information required to 5095 decrypt the information. 5097 14.0 References 5099 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 5100 cation Dial In User Service (RADIUS)", RFC 2865, June 2000. 5102 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 5104 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 5106 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 5107 1992. 5109 [5] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 5110 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 5111 13-061466-1. 5113 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 5114 Authentication", RFC 2104, January 1997. 5116 [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 5117 Application", draft-ietf-aaa-diameter-nasreq-07.txt, IETF work 5118 in progress, July 2001. 5120 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 5121 ary 1999. 5123 [10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 5124 draft-ietf-aaa-diameter-mobileip-07.txt, IETF work in progress, 5125 July 2001. 5127 [11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security appli- 5128 cation", draft-ietf-aaa-diameter-cms-sec-01.txt (work in pro- 5129 gress), July 2001. 5131 [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 5132 tions Section in RFCs", BCP 26, RFC 2434, October 1998 5134 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 5135 Levels", BCP 14, RFC 2119, March 1997. 5137 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 5138 Key Infrastructure Online Certificate Status Protocol (OCSP)", 5139 RFC 2560, June 1999. 5141 [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 5142 2409, November 1998. 5144 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 5145 2373, July 1998. 5147 [17] ISI, "Internet Protocol", RFC 791, September 1981. 5149 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 5150 IPv6 and OSI, RFC 2030, October 1996. 5152 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 5153 tructure Certificate and CRL Profile", RFC 2459, January 1999. 5155 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 5156 RFC 2477, January 1999. 5158 [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 5159 Server Protocols", draft-ietf-nasreq-criteria-06.txt, IETF work 5160 in progress, June 2001. 5162 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 5163 RFC 3141, June 2001. 5165 [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 5166 Authorization, and Accounting Requirements". RFC 2977. October 5167 2000. 5169 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 5170 2279, January 1998. 5172 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 5173 Protocol (EAP)." RFC 2284, March 1998. 5175 [26] R. Stewart et al., "Stream Control Transmission Protocol". RFC 5176 2960. October 2000. 5178 [27] Postel, J. "Transmission Control Protocol", RFC 793, January 5179 1981. 5181 [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location 5182 Protocol, Version 2", RFC 2165, June 1999. 5184 [29] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform 5185 Resource Identifiers (URI): Generic Syntax". RFC 2396, August 5186 1998. 5188 [30] Institute of Electrical and Electronics Engineers, "IEEE Stan- 5189 dard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 5190 754-1985, August 1985. 5192 [31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica- 5193 tions: ABNF", RFC 2234, November 1997. 5195 [32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Ser- 5196 vice: Schemes", RFC 2609, June 1999. 5198 [33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying 5199 the location of services (DNS SRV)", RFC 2782, February 2000. 5201 [34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, 5202 March 1999. 5204 [35] D. Eastlake, "DNS Security Operational Considerations", RFC 5205 2541, March 1999. 5207 [36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s 5208 )", RFC 2931, September 2000. 5210 [37] S. Kent, R. Atkinson, "Security Architecture for the Internet 5211 Protocol", RFC 2401, November 1998. 5213 [38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 5214 January 1999. 5216 [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. 5217 677-680. 5219 [40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 5220 Management", RFC 2975, October 2000. 5222 [41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 5223 Compression Protocol (IPComp)", RFC 2393, December 1998. 5225 [42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 5226 51, July 1994. 5228 [43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming 5229 Implementations", RFC 2194, September 1997. 5231 [44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementa- 5232 tion in Roaming", RFC 2607, June 1999. 5234 [45] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 5235 1996. 5237 [46] IANA, "RADIUS Types", http://www.isi.edu/in- 5238 notes/iana/assignments/radius-types 5240 [47] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specify- 5241 ing the location of services (DNS SRV)," RFC 2782, February 5242 2000. 5244 [48] P. V. Mockapetris, "Domain names - implementation and specifica- 5245 tion," RFC 1035, November 1987. 5247 [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 5248 Differentiated Services Field (DS Field) in the IPv4 and IPv6 5249 Headers," RFC 2474, December 1998. 5251 [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured For- 5252 warding PHB Group," RFC 2597, June 1999. 5254 [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 5255 PHB", RFC 2598, June 1999. 5257 15.0 Acknowledgements 5259 The authors would like to thank Nenad Trifunovic, Tony Johansson and 5260 Pankaj Patel for their participation in the pre-IETF Document Reading 5261 Party. Allison Mankin's, Jonathan Wood and Bernard Aboba's assistance 5262 was invaluable in working out transport issues, and similarly with 5263 Steven Bellovin's help in the security area. 5265 Paul Funk and David Mitton were instrumental in getting the Peer 5266 State Machine correct, and our deep thanks go to them for their time. 5267 Text in this document was also provided by Paul Funk, Mark Eklund, 5268 Mark Jones and Dave Spence. Jacques Caron provided many great com- 5269 ments as a result of a thorough review of the spec. 5271 The authors would also like to acknowledge the following people for 5272 their contribution in the development of the Diameter protocol: 5274 William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol 5275 Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johans- 5276 son, Mark Jones, Martin Julien, Paul Krumviede, Fergal Ladley, Ryan 5277 Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, 5278 John R. Vollbrecht and Jeff Weisberg 5280 16.0 Authors' Addresses 5282 Questions about this memo can be directed to: 5284 Pat R. Calhoun 5285 Network and Security Research Center, Sun Laboratories 5286 Sun Microsystems, Inc. 5287 15 Network Circle 5288 Menlo Park, California, 94025 5289 USA 5291 Phone: +1 650-786-7733 5292 Fax: +1 650-786-6445 5293 E-mail: pcalhoun@eng.sun.com 5295 Haseeb Akhtar 5296 Wireless Technology Labs 5297 Nortel Networks 5298 2221 Lakeside Blvd. 5299 Richardson, TX 75082-4399 5300 USA 5302 Phone: +1 972-684-8850 5303 E-Mail: haseeb@nortelnetworks.com 5305 Jari Arkko 5306 Oy LM Ericsson Ab 5307 02420 Jorvas 5308 Finland 5310 Phone: +358 40 5079256 5311 E-Mail: Jari.Arkko@ericsson.com 5312 Erik Guttman 5313 Solaris Advanced Development 5314 Sun Microsystems, Inc. 5315 Eichhoelzelstr. 7 5316 74915 Waibstadt 5317 Germany 5319 Phone: +49-7263-911-701 5320 E-mail: erik.guttman@germany.sun.com 5322 Allan C. Rubens 5323 Tut Systems, Inc. 5324 220 E. Huron, Suite 260 5325 Ann Arbor, MI 48104 5326 USA 5328 Phone: +1 734-995-1697 5329 E-Mail: arubens@tutsys.com 5331 Glen Zorn 5332 Cisco Systems, Inc. 5333 500 108th Avenue N.E., Suite 500 5334 Bellevue, WA 98004 5335 USA 5337 Phone: +1 425 438 8218 5339 17.0 Full Copyright Statement 5341 Copyright (C) The Internet Society (2001). All Rights Reserved. 5343 This document and translations of it may be copied and furnished to 5344 others, and derivative works that comment on or otherwise explain it 5345 or assist in its implementation may be prepared, copied, published 5346 and distributed, in whole or in part, without restriction of any 5347 kind, provided that the above copyright notice and this paragraph are 5348 included on all such copies and derivative works. However, this docu- 5349 ment itself may not be modified in any way, such as by removing the 5350 copyright notice or references to the Internet Society or other 5351 Internet organizations, except as needed for the purpose of develop- 5352 ing Internet standards in which case the procedures for copyrights 5353 defined in the Internet Standards process must be followed, or as 5354 required to translate it into languages other than English. The lim- 5355 ited permissions granted above are perpetual and will not be revoked 5356 by the Internet Society or its successors or assigns. This document 5357 and the information contained herein is provided on an "AS IS" basis 5358 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 5359 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 5360 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 5361 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 5362 FITNESS FOR A PARTICULAR PURPOSE. 5364 18.0 Expiration Date 5366 This memo is filed as and expires in 5367 January 2002. 5369 Appendix A. Diameter Service Template 5371 The following service template describes the attributes used by Diam- 5372 eter servers to advertise themselves. This simplifies the process of 5373 selecting an appropriate server to communicate with. A Diameter 5374 client can request specific Diameter servers based on characteristics 5375 of the Diameter service desired (for example, an AAA server to use 5376 for accounting.) 5378 Name of submitter: "Erik Guttman" 5379 Language of service template: en 5381 Security Considerations: 5382 Diameter clients and servers use various cryptographic mechanisms 5383 to protect communication integrity, confidentiality as well as 5384 perform end-point authentication. It would thus be difficult if 5385 not impossible for an attacker to advertise itself using SLPv2 and 5386 pose as a legitimate Diameter peer without proper preconfigured 5387 secrets or cryptographic keys. Still, as Diameter services are 5388 vital for network operation it is important to use SLPv2 authenti- 5389 cation to prevent an attacker from modifying or eliminating ser- 5390 vice advertisements for legitimate Diameter servers. 5392 Template text: 5393 -------------------------template begins here----------------------- 5394 template-type=service:diameter 5396 template-version=0.0 5398 template-description= 5399 The Diameter protocol is defined by draft-ietf-aaa-diameter-07.txt 5401 template-url-syntax= 5402 url-path= ; The diameter URL format is described in section 4.4. 5403 ; Example: 'diameter://aaa.example.com:1812;transport=tcp 5405 supported-auth-applications= string L M 5406 # This attribute lists the Diameter applications supported by the 5407 # AAA implementation. The applications currently defined are: 5408 # Application Name Defined by 5409 # ---------------- ----------------------------------- 5410 # NASREQ draft-ietf-aaa-diameter-nasreq-07.txt 5411 # MobileIP draft-ietf-aaa-diameter-mobileip-07.txt 5412 # CMS Security draft-ietf-aaa-diameter-cms-sec-02.txt 5413 # 5414 # Notes: 5415 # . Diameter implementations support one or more applications. 5416 # . Additional applications may be defined in the future. 5417 # An updated service template will be created at that time. 5418 # 5419 NASREQ,MobileIP,CMS Security 5421 supported-acct-applications= string L M 5422 # This attribute lists the Diameter applications supported by the 5423 # AAA implementation. The applications currently defined are: 5424 # Application Name Defined by 5425 # ---------------- ----------------------------------- 5426 # NASREQ draft-ietf-aaa-diameter-nasreq-07.txt 5427 # MobileIP draft-ietf-aaa-diameter-mobileip-07.txt 5428 # CMS Security draft-ietf-aaa-diameter-cms-sec-02.txt 5429 # 5430 # Notes: 5431 # . Diameter implementations support one or more applications. 5432 # . Additional applications may be defined in the future. 5433 # An updated service template will be created at that time. 5434 # 5435 NASREQ,MobileIP,CMS Security 5437 supported-transports= string L M 5438 SCTP 5439 # This attribute lists the supported transports that the Diameter 5440 # implementation accepts. Note that a compliant Diameter 5441 # implementation MUST support SCTP, though it MAY support other 5442 # transports, too. 5443 SCTP,TCP 5445 -------------------------template ends here-----------------------