idnits 2.17.1 draft-ietf-aaa-diameter-01.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 63 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 64 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 are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 5 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 2874 has weird spacing: '...agement draft...' == 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. == 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 table presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2001) is 8443 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: '3' is defined on line 2616, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2618, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2621, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2669, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 2731, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 2734, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** 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-01 ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-01 == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-06 -- 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) -- Possible downref: Normative reference to a draft: ref. '15' ** 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') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '21') ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '23') ** Obsolete normative reference: RFC 2279 (ref. '24') (Obsoleted by RFC 3629) -- Possible downref: Normative reference to a draft: ref. '25' ** Obsolete normative reference: RFC 2960 (ref. '26') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 793 (ref. '27') (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '29' -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' Summary: 27 errors (**), 0 flaws (~~), 19 warnings (==), 13 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 Allan C. Rubens 5 Tut Systems, Inc. 6 Haseeb Akhtar 7 Nortel Networks 8 Erik Guttman 9 Sun Microsystems, Inc. 10 March 2001 12 Diameter Base Protocol 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Distribution of this memo is unlimited. 37 Copyright (C) The Internet Society 2001. All Rights Reserved. 39 Abstract 41 The Diameter base protocol is intended to provide a AAA framework for 42 Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message 43 format, transport, error reporting and security services to be used 44 by all Diameter extensions and MUST be supported by all Diameter 45 implementations. 47 Table of Contents 49 1.0 Introduction 50 1.1 Requirements language 51 1.2 Terminology 52 2.0 Protocol Overview 53 2.1 Transport 54 2.2 Securing Diameter Messages 55 2.3 Diameter Server Discovery 56 2.4 Mandatory Accounting Support 57 3.0 Diameter Header 58 3.1 Command Code Definitions 59 4.0 Diameter AVPs 60 4.1 AVP Header 61 4.2 Optional Header Elements 62 4.3 AVP Data Formats 63 4.4 Grouped AVP Values 64 4.4.1 Example AVP with a Grouped Data type 65 4.5 Diameter Base Protocol AVPs 66 5.0 Message Forwarding 67 5.1 Origin-FQDN AVP 68 5.2 Origin-Realm AVP 69 5.3 Destination-FQDN AVP 70 6.0 Capabilities Negotiation 71 6.1 Device-Reboot-Ind (DRI) Command 72 6.1.1 Vendor-Id AVP 73 6.1.2 Firmware-Revision AVP 74 6.1.3 Extension-Id AVP 75 6.1.4 Host-IP-Address AVP 76 7.0 Transport Failure Detection 77 7.1 Device-Watchdog-Request 78 7.2 Device-Watchdog-Answer 79 7.3 Failover/Failback Procedures 80 8.0 Peer State Machine 81 9.0 Per-Hop Error Signaling 82 9.1 Device-Status-Ind 83 9.1.1 Device-Error AVP 84 9.1.1.1 Informational Events 85 9.1.1.2 Redirect Event 86 9.1.1.3 Transient Failure Events 87 9.1.1.4 Permanent Failure Events 88 10.0 End-to-End Error Signaling 89 10.1 Message-Reject-Ind (MRI) Command 90 10.1.1 Failed-AVP AVP 91 10.1.2 Failed-Command-Code 92 10.2 Result-Code AVP 93 10.2.1 Informational 94 10.2.2 Success 95 10.2.3 Redirect Notification 96 10.2.4 Transient Failures 97 10.2.5 Permanent Failures 98 10.3 Error-Message AVP 99 10.4 Error-Reporting-FQDN AVP 100 11.0 "User" Sessions 101 11.1 Session State Machine 102 11.2 Session-Id AVP 103 11.3 Authorization-Lifetime AVP 104 11.4 Session-Timeout AVP 105 11.5 User-Name AVP 106 11.6 Max-Wait-Time AVP 107 11.7 Session Termination 108 11.7.1 Session-Termination-Ind 109 11.7.2 Session-Termination-Request 110 11.7.3 Session-Termination-Answer 111 12.0 Message Routing 112 12.1 Realm-Based Message Routing 113 12.1.1 Realm-Based Routing Table 114 12.2 Proxy and Redirect Server handling of requests 115 12.2.1 Proxy and Redirect Server handling of requests 116 12.3 Redirect Server 117 12.3.1 Redirect-Host AVP 118 12.3.2 Redirect-Host-Address AVP 119 12.3.3 Redirect-Host-Port AVP 120 12.4 Proxy Server 121 12.4.1 Proxying Requests 122 12.4.2 Proxying Responses 123 12.4.3 Route-Record AVP 124 12.4.4 Proxy-State AVP 125 12.4.5 Proxy-Address AVP 126 12.4.6 Proxy-Info AVP 127 12.4.7 Destination-Realm AVP 128 12.5 Applying Local Policies 129 12.6 Hiding Network Topology 130 12.7 Loop Detection 131 13.0 Diameter Message Security 132 13.1 Hop-by-Hop Security 133 13.1.1 Integrity-Check-Value AVP 134 13.1.1.1 Authentication-Transform-Id AVP 135 13.1.1.2 Digest AVP 136 13.1.2 Encrypted-Payload AVP 137 13.1.2.1 Encryption-Transform-Id AVP 138 13.1.2.1.1 MD5 Payload Hiding 139 13.1.2.2 Plaintext-Data-Length AVP 140 13.1.2.3 Encrypted-Data AVP 141 13.2 Nonce AVP 142 13.3 Timestamp AVP 143 13.4 Key-Id AVP 144 14.0 AVP Table 145 15.0 IANA Considerations 146 15.1 AVP Attributes 147 15.2 Command Code AVP Values 148 15.3 Extension Identifier Values 149 15.4 Result-Code AVP Values 150 15.5 Integrity-Check-Value AVP Transform Values 151 15.6 Encryption-Transform-Id AVP Values 152 15.7 Message Header Bits 153 15.8 AVP Header Bits 154 15.9 DSI-Event AVP Values 155 16.0 Open Issues 156 17.0 Diameter protocol related configurable parameters 157 18.0 Security Considerations 158 19.0 References 159 20.0 Acknowledgements 160 21.0 Authors' Addresses 161 22.0 Full Copyright Statement 162 Appendix A. Diameter Service Template 164 1.0 Introduction 166 The Diameter protocol allows peers to exchange a variety of messages. 167 The base protocol provides the following facilities: 169 - Delivery of AVPs (attribute value pairs) 170 - Capabilities negotiation, as required in [20] 171 - Error notification 172 - Extensibility, through addition of new commands and AVPs, as 173 required in [21] 175 All data delivered by the protocol is in the form of an AVP. Some of 176 these AVP values are used by the Diameter protocol itself, while 177 others deliver data associated with particular applications which 178 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 179 so long as the required AVPs are included and AVPs which are 180 explicitly excluded are not included. AVPs are used by base Diameter 181 protocol to support the following required features: 183 - Transporting of user authentication information, for the 184 purposes of enabling the Diameter server to authenticate the 185 user. 186 - Transporting of service specific authorization information, 187 between client and servers, allowing the peers to decide whether 188 a user's access request should be granted. 189 - Exchanging resource usage information, which MAY be used for 190 accounting purposes, capacity planning, etc. 191 - Proxying and Re-directing of Diameter messages through a server 192 hierarchy. 193 - Providing application-level security, through the use of the 194 Integrity-Check-Value (ICV) and Encrypted-Payload AVPs. 196 The Diameter base protocol provides the minimum requirements needed 197 for an AAA transport protocol, as required by NASREQ [21], Mobile IP 198 [22, 23], and ROAMOPS [20]. The base protocol is not intended to be 199 used by itself, and must be used with an application-specific 200 extension, such as Mobile IP [10]. The Diameter protocol was heavily 201 inspired and builds upon the tradition of the RADIUS [1] protocol. 203 Any node can initiate a request. In that sense, Diameter is a peer to 204 peer protocol. In this document, a Diameter client is the device that 205 normally initiates a request for authentication and/or authorization 206 of a user. A Diameter server is the device that either forwards the 207 request to another Diameter server (known as a proxy), or one that 208 performs the actual authentication and/or authorization of the user 209 based on some profile. Given that the server MAY send unsolicited 210 messages to clients, it is possible for the server to initiate such 211 messages. An example of an unsolicited message would be for a request 212 that the client issue an accounting update. 214 Diameter services require sequenced in-order reliable delivery of 215 data, with congestion control (receiver windowing). Timely detection 216 of failed or unresponsive peers is also required, allowing for robust 217 operation. TCP is insufficient for this second requirement. 218 Diameter SHOULD be transported over SCTP [26]. 220 1.1 Requirements language 222 In this document, the key words "MAY", "MUST", "MUST NOT", 223 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 224 interpreted as described in [13]. 226 1.2 Terminology 228 Refer to [9] for terminology used in this document. 230 2.0 Protocol Overview 232 The base Diameter protocol is never used on its own. It is always 233 extended for a particular application. Four extensions to Diameter 234 are defined by companion documents: NASREQ [7], Mobile IP [10], 235 Accounting Extension [15], Strong Security [11]. These options are 236 introduced in this document but specified elsewhere. Additional 237 extensions to Diameter may be defined in the future (see Section 238 15.3). 240 The base Diameter protocol concerns itself with capabilities 241 negotiation, and how messages are sent and how peers may eventually 242 be abandoned. The base protocol also defines certain rules which 243 apply to all exchanges of messages between Diameter peers. It is 244 important to note that the base protocol provides optional 245 application-level security AVPs (Integrity-Check-Value) which MAY be 246 used in absence of an underlying security protocol (e.g. IP 247 Security). 249 Communication between Diameter peers begins with one peer sending a 250 message to another Diameter peer. The set of AVPs included in the 251 message is determined by a particular application of or extension to 252 Diameter. We will refer to this as the Diameter extension. One AVP 253 that is included to reference a user's session is the Session-Id. 255 The initial request for authentication and/or authorization of a user 256 would include the Session-Id. The Session-Id is then used in all 257 subsequent messages to identify the user's session (see section 11.0 258 for more information). The communicating party may accept the 259 request, or reject it by returning a response with Result-Code AVP 260 set to indicate an error occurred. The specific behavior of the 261 diameter server or client receiving a request depends on the Diameter 262 extension employed. 264 Session state (associated with a Session-Id) MUST be freed upon 265 receipt of the Session-Termination-Request, Session-Termination- 266 Answer, expiration of authorized service time in the Session-Timeout 267 AVP, and according to rules established in a particular 268 extension/application of Diameter. 270 Exchanges of messages are either request/reply oriented, or in some 271 special cases, do not require replies. All such messages that do not 272 require replies have names ending with '-Ind' (short for Indication). 274 The Diameter base protocol provides the Authorization-Lifetime AVP, 275 which MAY be used by extensions to specify the duration of a specific 276 authorized session. 278 2.1 Transport 280 The base Diameter protocol is run on port TBD of both TCP [27] and 281 SCTP [26] transport protocols (for interoperability test purposes 282 port 1812 will be used until April 2001). Diameter clients [9] MUST 283 support TCP, but are warned that future versions of this 284 specification may mandate SCTP support. Diameter servers MUST support 285 both TCP and SCTP. 287 A Diameter node MAY sent packets from any source port, but MUST be 288 prepared to receive packets on port TBD. When a request is received, 289 the source and destionation ports in the reply are reversed. Note 290 that the source and destination addresses used in request and replies 291 MAY any of a peer's valid IP addresses. 293 A given Diameter process SHOULD use the same port number to send all 294 messages to aid in identifying which process sent a given message. 295 More than one Diameter process MAY exist within a single host, so the 296 sender's port number is needed to discriminate them. 298 When no transport connection exists with a peer, an attempt to 299 connect SHOULD be periodically attempted. The recommended connection 300 interval is 30 seconds. 302 2.2 Securing Diameter Messages 303 All Diameter messages MUST be secured between peers, and both SSL 304 [28] and IP Security [37] are supported. Network Access Servers 305 (NASes) and Foreign Agents, commonly referred to as clients, MUST 306 support IP Security, while servers MUST support both SSL and IP 307 Security. The communication between a client and server MUST use IP 308 Security, while communication between servers MUST use SSL. 310 All hosts running the Diameter protocol MUST have the necessary 311 security policies to ensure that unauthenticated Diameter packets are 312 not processed. 314 2.3 Diameter Server Discovery 316 Allowing for dynamic Diameter server discovery will make it possible 317 for simpler and more robust deployment of AAA services. In order to 318 promote interoperable implementations of Diameter server discovery, 319 the following mechanisms are described. These are based on existing 320 IETF standards. 322 There are two cases where Diameter server discovery may be performed. 323 The first is when a Diameter client needs to discover a first-hop 324 Diameter server. The second case is when a Diameter server needs to 325 discover another server - for further handling of a Diameter 326 operation. In both cases, the following 'search order' is 327 recommended: 329 1. The Diameter implementation consults its list of static 330 (manual) configured Diameter server locations. These will be 331 used if they exist and respond. 333 2. The Diameter implementation uses SLPv2 [28] to discover 334 Diameter services. The Diameter service template [32] is 335 included in Appendix A. It is recommended that SLPv2 security 336 be deployed (this requires distributing keys to SLPv2 agents.) 337 This is discussed further in Appendix A. 339 SLPv2 will allow Diameter implementations to discover the 340 location of Diameter servers in the local site, as well as 341 their characteristics. Diameter servers with specific 342 capabilities (say support for the Accounting extension) can be 343 requested, and only those will be discovered. 345 3. The Diameter implementation uses DNS to request the SRV RR [33] 346 for the '_diameter._sctp' and/or '_diameter._tcp' server in a 347 particular domain. The Diameter implementation has to know in 348 advance which domain to look for an Diameter server in. This 349 could be deduced, for example, from the 'realm' in a NAI that 350 an Diameter implementation needed to perform an Diameter 351 operation on. 353 Diameter allows AAA peers to protect the integrity and privacy 354 of communication as well as to perform end-point 355 authentication. Still, it is prudent to employ DNS Security as 356 a precaution when using DNS SRV RRs to look up the location of 357 a Diameter server. [34, 35, 36] 359 2.4 Mandatory Accounting Support 361 All Diameter implementations MUST support the Diameter Accounting 362 Extension [15]. An implementation that does not support [15] does NOT 363 comply with the Diameter base protocol. 365 3.0 Diameter Header 367 A summary of the Diameter header format is shown below. The fields 368 are transmitted in network byte order. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |r r r r r r r r r r E I R| Ver | Message Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Hop-by-Hop Identifier | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | End-to-End Identifier | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Command-Code | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Vendor-ID | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | AVPs ... 384 +-+-+-+-+-+-+-+-+-+-+-+-+- 386 Flags 387 The Message Flags field is thirteen bits. The following bits are 388 assigned: 390 r(eserved) MUST be zero - this flag bit is reserved for 391 future use. 392 E(xpected Reply) - The message solicits a response. 393 I(nterrogation) - The message is a Query or a Reply. 394 R(esponse) - The message is a response to another message. 396 These flags are set depending on the command code used in a 397 Diameter message. This enables the type of message to be 398 interpreted, even if the specific command code is not recognized. 400 Command Type Flags Set 401 Indication - - - 402 Request E - - 403 Answer - - R 404 Query E I - 405 Reply - I R 407 A Diameter node MUST NOT set these flags in any other combination. 408 A Diameter node receiving a message in which these flags are not 409 set appropriately SHOULD NOT reject the message for this reason, 410 but MAY log the event for diagnosis. 412 Version 413 This Version field MUST be set to 1 to indicate Diameter Version 414 1. 416 Message Length 417 The Message Length field is two octets and indicates the length of 418 the Diameter message including the header fields. 420 Hop-by-Hop Identifier 421 The Identifier field is four octets, and aids in matching requests 422 and replies. The sender MUST ensure that the identifier in a 423 request (*-Request or *-Query) or indication (*-Ind) message is 424 locally unique (to the sender) at any given time, and MAY attempt 425 to ensure that the number is unique across reboots. The sender of 426 a response (*-Answer or *-Response) MUST ensure that the 427 Identifier field contains the same Identifier value that was found 428 in the corresponding request. For The identifier is normally a 429 monotonically increasing number, whose start value was randomly 430 generated. Diameter servers should consider a message to be unique 431 by examining the source address, source port, Session-Id and 432 Identifier field of the message. 434 End-to-End Identifier 435 Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is 436 used by servers to detect duplicate messages, and proxies MUST NOT 437 modify this field. The sender of a request, query, indication, 438 answer or response message MUST insert a locally unique value in 439 this field. The combination of the Session-Id AVP and this field 440 is used to detect duplicates. 442 Command-Code 443 The Command-Code field is four octets, and is used in order to 444 communicate the command associated with the message. The 32-bit 445 address space is managed by IANA (see section 15.2). 447 Vendor-ID 448 In the event that the Command-Code field contains a vendor 449 specific command, the four octet Vendor-ID field contains the IANA 450 assigned "SMI Network Management Private Enterprise Codes" [2] 451 value. If the Command-Code field contains an IETF standard 452 Command, the Vendor-ID field MUST be set to zero (0). 454 AVPs 455 AVPs are a method of encapsulating information relevant to the 456 Diameter message. See section 4. for more information on AVPs. 458 3.1 Command Codes 460 Every Diameter message MUST contain a value in its header's Command- 461 Code field, which is used to determine the action that is to be taken 462 for a particular message. The following Command Codes are defined in 463 the Diameter base protocol: 465 Command-Name Abbrev. Code Reference 466 -------------------------------------------------------- 467 Device-Reboot-Ind DRI 257 6.1 468 Device-Status-Ind DSI 282 9.1 469 Device-Watchdog-Req DWR 280 7.1 470 Device-Watchdog-Answer DWA 281 7.2 471 Message-Reject-Ind MRI 259 10.1 472 Session-Termination-Ind STI 274 11.7.1 473 Session-Termination- STR 275 11.7.2 474 Request 475 Session-Termination- STA 276 11.7.3 476 Answer 478 Every Command Code defined MUST include a corresponding ABNF 479 specification, which is used to define the AVPs that MUST, MAY and 480 MUST NOT be present. The following format is used in the definition: 482 command-def = command-name "::=" diameter-message 484 diameter-name = ALPHA *(ALPHA / DIGIT / "-") 486 command-name = diameter-name 487 ; The command-name has to be Command name, 488 ; defined in the base or extended Diameter 489 ; specifications. 491 diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] 493 header = "" 495 fixed = [qual] "<" avp-spec ">" 497 required = [qual] "{" avp-spec "}" 499 optional = [qual] "[" avp-name "]" 500 ; The avp-name in the 'optional' rule cannot 501 ; evaluate to any AVP Name which is included 502 ; in a fixed or required rule. 504 qual = [min] "*" [max] 505 ; See ABNF conventions, RFC 2234 section 6.6. 506 ; The absence of any qualifiers implies that one 507 ; and only one such AVP MUST be present. 508 ; 509 ; NOTE: "[" and "]" have a different meaning 510 ; than in ABNF (see the optional rule, above). 511 ; These braces cannot be used to express an 512 ; optional fixed rules (such as an optional 513 ; ICV at the end.) To do this, the convention 514 ; is '0*1fixed'. 516 min = 1*DIGIT 517 ; The minimum number of times the element may 518 ; be present. 520 max = 1*DIGIT 521 ; The maximum number of times the element may 522 ; be present. 524 avp-spec = diameter-name 525 ; The avp-spec has to be an AVP Name, defined 526 ; in the base or extended Diameter 527 ; specifications. 529 avp-name = avp-spec | "AVP" 530 ; The string "AVP" stands for *any* arbitrary 531 ; AVP Name, which does not conflict with the 532 ; required or fixed position AVPs defined in 533 ; the command code definition. 535 The following is a definition of a fictitious command code: 537 Example-Command ::= < Diameter-Header: 9999999 > 538 { User-Name } 540 * { Origin-FQDN } 541 * [ AVP ] 542 0*1< Integrity-Check-Vector > 544 4.0 Diameter AVPs 546 Diameter AVPs carry specific authentication, accounting and 547 authorization information, security information as well as 548 configuration details for the request and reply. 550 Some AVPs MAY be listed more than once. The effect of such an AVP is 551 specific, and is specified in each case by the AVP description. 553 Each AVP of type OctetString MUST be padded to align on a 32 bit 554 boundary, while other AVP types align naturally. NULL bytes are added 555 to the end of the AVP Data field till a word boundary is reached. The 556 length of the padding is not reflected in the AVP Length field. 558 4.1 AVP Header 560 The fields in the AVP header MUST be sent in network byte order. The 561 format of the header is: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | AVP Code | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | AVP Length | Reserved |P|r|V|r|M| 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Vendor-ID (opt) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Data ... 573 +-+-+-+-+-+-+-+-+ 575 AVP Code 576 The AVP Code identifies the attribute uniquely. The first 256 AVP 577 numbers are reserved for backward compatibility with RADIUS and 578 are to be interpreted as per NASREQ [7]. AVP numbers 256 and above 579 are used for Diameter, which are allocated by IANA (see section 580 15.1). 582 AVP Length 583 The AVP Length field is two octets, and indicates the length of 584 this AVP including the AVP Code, AVP Length, AVP Flags, Reserved, 585 the Vendor-ID field (if present) and the AVP data. If a message is 586 received with an invalid attribute length, the message SHOULD be 587 rejected. 589 AVP Flags 590 The AVP Flags field informs the Diameter host how each attribute 591 must be handled. Note that subsequent Diameter extensions MAY 592 define bits to be used within the AVP Header, and an unrecognized 593 bit should be considered an error. The 'r' and the reserved bits 594 are unused and should be set to 0 and ignored on receipt, while 595 the 'P' bit is defined in [11]. 597 The 'M' Bit, known as the Mandatory bit, indicates whether support 598 of the AVP is required. If an AVP is received by a Home server or 599 NAS with the 'M' bit enabled and the receiver does not support 600 the AVP, the message MUST be rejected. If such an AVP is received 601 by a Proxy or Redirect Server, the message MUST be forwarded to 602 its logical destination, and MUST NOT be rejected. It is the 603 responsibility of the originator of a message that is rejected for 604 this purpose to correct the error. AVPs without the 'M' bit 605 enabled are informational only and a receiver that receives a 606 message with such an AVP that is not supported MAY simply ignore 607 the AVP. 609 The 'V' bit, known as the Vendor-Specific bit, indicates whether 610 the optional Vendor-ID field is present in the AVP header. When 611 set the AVP Code belongs to the specific vendor code address 612 space. 614 Unless otherwise noted, AVPs will have the following default AVP 615 Flags field settings: 616 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 618 4.2 Optional Header Elements 620 The AVP Header contains one optional field. This field is only 621 present if the respective bit-flag is enabled. 623 Vendor-ID 624 The Vendor-ID field is present if the 'V' bit is set in the AVP 625 Flags field. The optional four octet Vendor-ID field contains the 626 IANA assigned "SMI Network Management Private Enterprise Codes" 627 [2] value, encoded in network byte order. Any vendor wishing to 628 implement a Diameter extension MUST use their own Vendor-ID along 629 with their privately managed AVP address space, guaranteeing that 630 they will not collide with any other vendor's extensions, nor with 631 future IETF extensions. 633 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 634 values, as managed by the IANA. Since the absence of the vendor ID 635 field implies that the AVP in question is not vendor specific, 636 implementations SHOULD not use the zero (0) vendor ID. 638 4.3 AVP Data Formats 640 The Data field is zero or more octets and contains information 641 specific to the Attribute. The format and length of the Data field is 642 determined by the AVP Code and AVP Length fields. The format of the 643 Data field MAY be one of the following data types. 645 The interpretation of the values depends on the specification of the 646 AVP. For example, an OctetString may be used to transmit human 647 readable string data and Unsigned32 may be used to transmit a time 648 value. Conventions for these common interpretations are described 649 below. 651 OctetString 652 The data contains arbitrary data of variable length. Unless 653 otherwise noted, the AVP Length field MUST be set to at least 9 654 (13 if the 'V' bit is enabled). Data used to transmit (human 655 readable) character string data uses the UTF-8 [24] character 656 set and is NOT NULL-terminated. The minimum Length field MUST 657 be 9, but can be set to any value up to 65527 bytes. AVP Values 658 of this type that do not align on a 32-bit boundary MUST have 659 the necessary padding. 661 Address 662 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 663 significant octet first. The format of the address (IPv4 or 664 IPv6) is determined by the length. If the attribute value is an 665 IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is 666 enabled), otherwise the AVP Length field MUST be set to 24 (28 667 if the 'V' bit is enabled) for IPv6 addresses. 669 Integer32 670 32 bit signed value, in network byte order. The AVP Length 671 field MUST be set to 12 (16 if the 'V' bit is enabled). 673 Integer64 674 64 bit signed value, in network byte order. The AVP Length 675 field MUST be set to 16 (20 if the 'V' bit is enabled). 677 Unsigned32 678 32 bit unsigned value, in network byte order. The AVP Length 679 field MUST be set to 12 (16 if the 'V' bit is enabled). 681 Unsigned32 values used to transmit time data contains the four 682 most significant octets returned from NTP [18], in network byte 683 order. 685 Unsigned64 686 32 bit unsigned value, in network byte order. The AVP Length 687 field MUST be set to 16 (20 if the 'V' bit is enabled). 689 Float32 690 This represents floating point values of single precision as 691 described by [30]. The 32 bit value is transmitted in network 692 byte order. The AVP Length field MUST be set to 12 (16 if the 693 'V' bit is enabled). 695 Float64 696 This represents floating point values of double precision as 697 described by [30]. The 64 bit value is transmitted in network 698 byte order. The AVP Length field MUST be set to 16 (20 if the 699 'V' bit is enabled). 701 Float128 702 This represents floating point values of quadruple precision as 703 described by [30]. The 128 bit value is transmitted in network 704 byte order. The AVP Length field MUST be set to 24 (28 if the 705 'V' bit is enabled). 707 Grouped 708 The Data field is specified as a sequence of AVPs. Each of 709 these AVPs follows - in the order in which they are specified - 710 including their headers and padding. The AVP Length field is 711 set to 8 (12 if the 'V' bit is enabled) plus the total length 712 of all included AVPs, including their headers. 714 4.4 Grouped AVP Values 716 The Diameter protocol allows AVP values of type 'Grouped.' This 717 implies that the Data field is actually a well defined sequence of 718 AVPs. It is possible to include an AVP with a Grouped type within a 719 Grouped type, that is, to nest them. AVPs within an AVP of type 720 Grouped have the same padding requirements as non-Grouped AVPs, as 721 defined in section 4.0. 723 Grouped type AVP specifications include an ABNF grammar [31] 724 specifying the required sequence of AVPs. Grouped AVP values MUST be 725 in the specified sequence and MUST NOT include other AVP values 726 besides those specified by the Grouped AVP grammar. 728 4.4.1 Example AVP with a Grouped Data type 730 The Example AVP (AVP Code 999999) is of type Grouped and is used to 731 clarify how Grouped AVP values work. The Grouped Data field has the 732 following ABNF grammar: 734 example-avp-val = Origin-FQDN Host-IP-Address 735 Origin-FQDN = ; See Section 5.1 736 Host-IP-Address = ; See Section 6.1.4 738 An Example AVP with the Grouped Data Origin-FQDN = "example.com", 739 Host-IP-Address = "10.10.10.10" would be encoded as follows: 741 0 1 2 3 4 5 6 7 742 +-------+-------+-------+-------+-------+-------+-------+-------+ 743 0 | Example AVP Header (AVP Code = 999999), Length = 40 | 744 +-------+-------+-------+-------+-------+-------+-------+-------+ 745 8 | Origin-FQDN AVP Header (AVP Code = 265), Length = 19 | 746 +-------+-------+-------+-------+-------+-------+-------+-------+ 747 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 748 +-------+-------+-------+-------+-------+-------+-------+-------+ 749 24 | 'c' | 'o' | 'm' |Padding| Host-IP-Addr AVP Header | 750 +-------+-------+-------+-------+-------+-------+-------+-------+ 751 32 | (AVP Code = 257), Length = 12 | 0x0a | 0x0a | 0x0a | 0x0a | 752 +-------+-------+-------+-------+-------+-------+-------+-------+ 754 4.5 Diameter Base Protocol AVPs 756 The following table describes the Diameter AVPs defined in the base 757 protocol, their AVP Code values, types, possible flag values and 758 whether the AVP MAY be encrypted. 760 +---------------------+ 761 | AVP Flag rules | 762 |----+-----+----+-----|----+ 763 AVP Section | | |SHLD| MUST|MAY | 764 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 765 -----------------------------------------|----+-----+----+-----|----| 766 Authentication- 285 13.1.1.1 Unsigned32 | | | | | N | 767 Transform-Id | | | | | | 768 Authorization- 291 11.3 Unsigned32 | | | | | N | 769 Lifetime | | | | | | 770 Destination-FQDN 293 5.3 OctetString| | | | | Y | 771 Digest 287 13.1.1.2 OctetString| | | | | N | 772 DSI-Event 297 9.1.1 Unsigned32 | M | | | | N | 773 -----------------------------------------|----+-----+----+-----|----| 774 +---------------------+ 775 | AVP Flag rules | 776 |----+-----+----+-----|----+ 777 AVP Section | | |SHLD| MUST|MAY | 778 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 779 -----------------------------------------|----+-----+----+-----|----| 780 Encrypted-Data 290 13.1.2.3 OctetString| | | | | N | 781 Encrypted- 260 13.1.2 Grouped | M | | | | N | 782 Payload | | | | | | 783 Encryption- 288 13.1.2.1 Unsigned32 | | | | | N | 784 Transform-Id | | | | | | 785 Error-Message 281 10.3 OctetString| | | | | N | 786 Error-Reporting- 294 10.4 OctetString| | | | | Y | 787 FQDN | | | | | | 788 Extension-Id 258 6.1.3 Integer32 | M | | | | Y | 789 Failed-AVP 279 10.1.1 OctetString| | | | | Y | 790 Failed-Command- 270 10.1.2 Unsigned32 | | | | | Y | 791 Code | | | | | | 792 Firmware 267 6.1.2 Unsigned32 | | | | V,M | Y | 793 -Revision | | | | | | 794 Host-IP-Address 257 6.1.4 Address | M | | | V | N | 795 Origin-FQDN 264 5.1 OctetString| M | | | V | N | 796 Integrity-Check 259 13.1.1 Grouped | M | | | | N | 797 -Value | | | | | | 798 Key-Id 286 13.4 Unsigned32 | | | | | N | 799 Max-Wait-Time 295 11.6 Unsigned32 | M | | | V | N | 800 Nonce 261 13.2 OctetString| | | | | N | 801 Origin-Realm 296 5.2 OctetString| M | | | V | N | 802 Plaintext-Data- 289 13.1.2.2 Unsigned32 | | | | | N | 803 Length | | | | | | 804 Proxy-Address 280 12.4.5 Address | M | | | V | N | 805 Proxy-Info 284 12.4.6 OctetString| M | | | V | N | 806 Proxy-State 33 12.4.4 Grouped | M | | | V | N | 807 Redirect-Host 292 12.3.1 Grouped | | | | | Y | 808 Redirect-Host- 278 12.3.2 Address | | | | | Y | 809 Address | | | | | | 810 Redirect-Host- 277 12.3.3 Unsigned32 | | | | | Y | 811 Port | | | | | | 812 Result-Code 268 10.2 Unsigned32 | M | | | | N | 813 Route-Record 282 12.4.3 OctetString| M | | | V | N | 814 Destination- 283 12.4.7 OctetString| M | | | V | N | 815 Realm | | | | | | 816 Session-Id 263 11.2 OctetString| M | | | | Y | 817 Session-Timeout 27 11.4 Unsigned32 | | | | | Y | 818 Timestamp 262 13.3 Unsigned32 | | | | | N | 819 User-Name 1 11.5 OctetString| | | | | Y | 820 Vendor-Id 266 6.1.1 Unsigned32 | | | | V,M | Y | 821 -----------------------------------------|----+-----+----+-----|----| 823 5.0 Message Forwarding 825 All Diameter messages MUST include the Origin-FQDN and Origin-Realm 826 AVPs. These AVPs are used to identify the source of the message. 827 When responding to a request or query message, the Origin-FQDN and 828 Origin-Realm AVPs are replaced with the local node's information. 830 When a Diameter entity receives a Diameter message of type Request, 831 Query or Indication that includes a Destination-FQDN AVP, and the 832 host specified in the AVP can be contacted directly, the message MUST 833 be forwarded to the host in question. 835 The Destination-FQDN AVP is used when the destination of the message 836 is fixed, such as: 838 - Authentication requests that span multiple round trips 839 - A Diameter message that uses a security mechanism that makes use 840 of a pre-established session key shared between the source and 841 the final destination of the message. 842 - Server initiated messages that MUST be received by a specific 843 Diameter client (e.g. NAS), such as the Session-Termination-Ind 844 message, which is used to request that a particular user's 845 session be terminated. 847 Proxies receiving messages that contain the Destination-FQDN AVP MUST 848 verify whether they are able to forward Diameter messages to the host 849 specified in the AVP, and if so, MUST forward the message to the host 850 in question. Otherwise, the message routing procedures described in 851 section 12.0 MUST be followed. 853 This section defines the Diameter AVPs that MUST be added in all 854 messages originated by a Diameter node (including nodes creating 855 Response and Answer messages). 857 5.1 Origin-FQDN AVP 859 The Origin-FQDN AVP (AVP Code 264) is of type OctetString, encoded in 860 the UTF-8 [24] format. This AVP identifies the endpoint which 861 originated the Diameter message, i.e. the NAS, home server, or 862 broker. Proxy servers do not modify this AVP. All Diameter messages 863 MUST include the Origin-FQDN AVP, which contains the host name of the 864 originator of the Diameter message and MUST follow the NAI [8] naming 865 conventions. 867 Note that the Origin-FQDN AVP may resolve to more than one address as 868 the Diameter peer may support more than one address. 870 5.2 Origin-Realm AVP 872 The Origin-Realm AVP (AVP Code 296) is of type OctetString, encoded 873 in the UTF-8 [24] format. This AVP contains the Realm of the 874 originator of any Diameter message. 876 5.3 Destination-FQDN AVP 878 The Destination-FQDN AVP (AVP Code 293) is of type OctetString, 879 encoded in the UTF-8 [24] format, and contains the Fully Qualified 880 Domain Name (FQDN) of the intended recipient of the message. This AVP 881 MUST be present in all unsolicited server initiated messages. The 882 value of the Destination-FQDN AVP is set to the value of the Origin- 883 FQDN AVP found in a message from the intended target host. 885 6.0 Capabilities Exchange 887 When two Diameter peers establish a transport connection, they MUST 888 send the Device-Reboot-Ind message. This message has two purposes. 889 First it allows a peer's identity to be discovered, and allows for 890 capabilities exchange, such as the supported protocol version number, 891 and the locally supported extensions. 893 The receiver uses the extensions advertised in order to determine 894 whether it SHOULD send certain application-specific Diameter 895 commands. A Diameter node MUST retain the supported extensions in 896 order to ensure that unrecognized commands and/or AVPs are not sent 897 to a peer. 899 The Device-Reboot-Ind message MUST NOT be proxied, or redirected. 901 Since the DRI cannot be proxied, it is still possible that a upstream 902 proxy receives a message for which it has no available peers to 903 handle the extension that corresponds to the Command-Code. In such 904 instances, the Device-Status-Ind message is used (see Section 9.1) to 905 inform the downstream to take action. 907 With the exception of the Device-Reboot-Ind message, a message of 908 type Request, Query or Indication that includes the Extension-Id AVP 909 MAY only be forwarded to a host that has explicitely advertised 910 support for the extension (or has advertised the Wildcard Extension). 912 6.1 Device-Reboot-Ind (DRI) Command 914 The Device-Reboot-Ind (DRI), indicated by the Command-Code set to 915 257, is sent to inform a peer that a reboot has, or will, occur. 917 When Diameter is run over SCTP [26], which allows for connections to 918 span multiple interfaces, hence multiple IP addresses, the Device- 919 Reboot-Ind message MUST contain one Host-IP-Address AVP for each 920 potential IP address that MAY be locally used when transmitting 921 Diameter messages. 923 If a Diameter node receives a DRI message that results in an error, a 924 Message-Reject-Ind message MUST be returned. 926 Message Format 928 ::= < Diameter Header: 257 > 929 { Origin-FQDN } 930 { Origin-Realm } 931 1* { Host-IP-Address } 932 { Vendor-Id } 933 * { Extension-Id } 934 [ Firmware-Revision ] 935 * [ AVP ] 936 0*1< Integrity-Check-Value > 938 6.1.1 Vendor-Id AVP 940 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 941 the IANA assigned "SMI Network Management Private Enterprise Codes" 942 [2] value of the Diameter device. 944 This MAY be used in order to know which vendor specific attributes 945 may be sent to the peer. It is also envisioned that the combination 946 of the Vendor-Name and the Firmware-Revision (section 6.1.2) AVPs MAY 947 provide very useful debugging information. 949 6.1.2 Firmware-Revision AVP 951 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 952 used to inform a Diameter peer of the firmware revision of the 953 issuing device. 955 For devices that do not have a firmware revision (general purpose 956 computers running Diameter software modules, for instance), the 957 revision of the Diameter software module may be reported instead. 959 6.1.3 Extension-Id AVP 960 The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used 961 in order to identify a specific Diameter extension. This AVP is used 962 in the Device-Reboot-Ind message in order to inform the peer what 963 extensions are locally supported. The Extension-Id MUST also be 964 present in all messages that are defined in a separate Diameter 965 specification and have an Extension ID assigned. 967 Each Diameter extension draft MUST have an IANA assigned extension 968 Identifier (see section 15.3). The base protocol does not require an 969 Extension-Id since its support is mandatory. 971 There MAY be more than one Extension-Id AVP within a Diameter 972 Device-Reboot-Ind message. The following values are recognized: 974 NASREQ 1 [7] 975 Strong Security 2 [11] 976 Resource Management 3 [29] 977 Mobile-IP 4 [10] 978 Accounting 5 [15] 979 Wildcard Extension 0xffffffff 981 Servers acting as Redirect or Proxy servers (see Section 12.0) MAY 982 wish to either advertise all supported extensions, or the wildcard 983 extension. The receiver of a wildcard extension MUST assume that the 984 sender supports all extensions. 986 Proxy servers are responsible for finding a downstream server that 987 supports the extension of a particular message. If none can be found, 988 a DSI message is returned with the DSI-Event AVP set to 989 DIAMETER_UNABLE_TO_DELIVER. 991 6.1.4 Host-IP-Address AVP 993 The Host-IP-Address AVP (AVP Code 257) is of type Address and is used 994 to inform a Diameter peer of the sender's IP address. All source 995 addresses that a Diameter node expects to use with SCTP [26] MUST be 996 advertised in the Device-Reboot-Ind message by including a Host-IP- 997 Address AVP for each address. This AVP MUST ONLY be used in the 998 Device-Reboot-Ind message. 1000 7.0 Transport Failure Detection 1002 Given the nature of the Diameter protocol, it is recommended that 1003 transport failures be detected as soon as possible. Detecting such 1004 failures will minimize the occurrence of messages sent to unavailable 1005 servers, resulting in unnecessary delays, and will provide better 1006 failover performance. 1008 In order to pro-actively detect such failures, the Diameter protocol 1009 defines the Device-Watchdog-Request message, which is sent to an 1010 inactive peer. A peer is considered inactive if no messages were sent 1011 or received from the peer within the current watchdog interval period 1012 (see Section 17.0), and no request or query messages are pending with 1013 the peer. 1015 For implementations that have access to the Retransmission Time-Out 1016 (RTO) value of the underlying transport connection, a DWR SHOULD be 1017 sent once per RTO of that connection, plus the watchdog interval 1018 period, with a jiterring of +/- 50%. 1020 If the DWR is unanswered, the time until the next DWR is sent MUST be 1021 recalculated after exponentially backing off the RTO portion. When 1022 the value of the DWR's current watchdog interval period reaches the 1023 maximum watchdog interval (Secton 17.0), backoff is not continued, 1024 and the peer is marked as failed. DWR messages continue to be sent 1025 (jittered) at the final interval for detection for failover. The 1026 current watchdog interval is returned to its starting point when a 1027 DWA is received or the peer resumes activity. 1029 Implementations that do not have access to the RTO SHOULD perform an 1030 Round Trip Time (RTT) measurement for a given peer when a Device- 1031 Watchdog-Answer message is received for a non-backed off DWR. The 1032 fixed RTO base should be replaced by RTT-Multiplier (Section 17.0) 1033 times the measured RTT. 1035 An example of the backoff sequence, excluding jitter, would be: 1036 30+RTO , 30+2*RTO , 30+4*RTO , 30+8*RTO, 60, 60, 60 1038 Note that exponential backoff MUST be performed before the maximum is 1039 reached. 1041 7.1 Device-Watchdog-Request 1043 The Device-Watchdog-Request (DWR), indicated by the Command-Code set 1044 to 280, is sent to a peer when no traffic has been exchanged between 1045 two peers as defined in Section 7.0, and no requests are pending with 1046 the peer. 1048 Message Format 1049 ::= < Diameter Header: 280 > 1050 { Origin-FQDN } 1051 { Origin-Realm } 1052 0*1< Integrity-Check-Value > 1054 7.2 Device-Watchdog-Answer 1056 The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 1057 to 281, is sent as a response to the Device-Watchdog-Request message. 1058 A receiver of the DWA SHOULD perform RTT calculation in the event 1059 that the transport RTO information is not available. 1061 Message Format 1063 ::= < Diameter Header: 281 > 1064 { Result-Code } 1065 { Origin-FQDN } 1066 { Origin-Realm } 1067 0*1< Integrity-Check-Value > 1069 7.3 Failover/Failback Procedures 1071 In the event that a transport failure is detected with a peer, it is 1072 necessary for all pending request, query and indication messages to 1073 be forwarded to an alternate server, if possible. This is commonly 1074 referred to as failover. 1076 In order for a Diameter node to perform failover procedures, it is 1077 necessary for the node to maintain a pending message queue for a 1078 given peer. When a response is received, the message is removed from 1079 the queue. The Hop-by-Hop Identifier field MAY be used to match the 1080 corresponding response with the queued response. 1082 When a transport failure is detected, all messages in the queue are 1083 sent to an alternate server, if possible. An example of a case where 1084 it is not possible for forward the message to an alternate server is 1085 when the message has a fixed destination, and the unavailable peer is 1086 the message's final destination (see Destination-FQDN AVP). Such an 1087 error requires that the server return an DSI with the DSI-Event AVP 1088 set to DIAMETER_UNABLE_TO_DELIVER. 1090 As described in section 2.1, a connection request should be 1091 periodically attempted with the failed peer in order to re-establish 1092 the transport connection. Once a connection has been successfully 1093 established, messages can once again be forwarded to the peer. This 1094 is commonly referred to as failback. 1096 8.0 Peer State Machine 1098 This section contains a finite state machine, that MUST be observed 1099 by all Diameter implementations. Each Diameter node MUST follow the 1100 state machine described below when communicating with each peer. 1102 State Event Action New State 1103 ----- ----- ------ --------- 1104 Initial Local request to establish SCTP/TCP Idle 1105 communication with a Diameter Connect 1106 peer with which there is no 1107 existing transport level 1108 connection established. 1110 Initial Receive transport level Send DRI Wait-DRI 1111 connection request from a 1112 Diameter peer. 1114 Idle Connection Established Send DRI Wait-DRI 1116 Idle Receive DRI Send DRI + Open 1117 Reset Watchdog 1118 Timer 1120 Wait-DRI Receive DRI Reset Watchdog Open 1121 Timer 1123 Open Receive other messages Process Open 1124 Message + 1125 Reset Watchdog 1126 Timer 1128 Open Idle link, and no pending Send DWR Open 1129 requests 1131 Open Receive DWR Send DWA Open 1133 Open Receive DWA Calculate RTT Open 1135 Open Receive DRI Cleanup Closed 1137 Open Transport level failure Cleanup Closed 1139 Closed Diameter Entity shutdown or Close Initial 1140 close connection with peer connection 1142 The Initial and Idle states MAY be merged if the local SCTP 1143 implementation is able to implement the piggyback of data during the 1144 connection phase. 1146 When the Cleanup action is invoked, the failover procedures are 1147 executed (see Section 7.3 for more information). 1149 9.0 Per-Hop Error Signaling 1151 There are many instances where error conditions occur on a Diameter 1152 node, that needs to be signalled to the downstream server, and not 1153 necessarily to the Diameter client. Examples of such error conditions 1154 are invalid time synchronization, inability to forward a message to a 1155 particular domain, etc. In these cases, returning the error back to 1156 the Diameter client will only cause delay, and perhaps confusion in 1157 roaming networks. 1159 Therefore, when such errors occur, it is necessary for the error to 1160 be handled by the downstream next hop, and some local action be taken 1161 to rectify the problem, such as forwarding to a different next hop. 1163 Request +--------+ Link Broken 1164 +-------------------------->|Diameter|----///----+ 1165 | +---------------------| | v 1166 +-----+---+ | DSI | Server | +--------+ 1167 |Diameter |<-+ (Unable to Forward) +--------+ |Diameter| 1168 |Client or| | | 1169 | Server |--+ +--------+ | Server | 1170 +---------+ | Request |Diameter| +--------+ 1171 +-------------------->| | ^ 1172 | Server |-----------+ 1173 +--------+ 1174 Figure 1 - Example of Per-Hop Error Condition 1176 9.1 Device-Status-Ind 1178 The Device-Status-Ind (DSI), indicated by the Command-Code set to 1179 282, is sent to inform a peer that an event has occurred. 1181 When a Diameter node issues a DSI message downstream, the target peer 1182 MUST attempt to rectify the problem, or issue a similar message 1183 downstream. The Device-Status-Ind message MUST NOT be proxied, but 1184 MAY be forwarded, as long as the Origin-FQDN AVP is replaced to 1185 include the local node's identity. 1187 Message Format 1188 ::= < Diameter Header: 282 > 1189 { Origin-FQDN } 1190 { Origin-Realm } 1191 [ DSI-Event ] 1192 * [ AVP ] 1193 0*1< Integrity-Check-Value > 1195 9.1.1 DSI-Event AVP 1197 The Result-Code AVP (AVP Code 297) is of type Unsigned32 and 1198 indicates that an event occurred which requires attention from a 1199 Diameter peer. The DSI-Event contains an IANA-managed 32-bit address 1200 space representing events (see section 15.9). Diameter provides four 1201 different classes of event notification, all identified by the 1202 thousands digit: 1203 - 1xxx (Informational Events) 1204 - 3xxx (Redirect Notification) 1205 - 4xxx (Transient Failure Events) 1206 - 5xxx (Permanent Failure Events) 1208 A non-recognize class (one whose first digit is not defined in this 1209 section) MUST be handled as a permanent failure. 1211 9.1.1.1 Informational Events 1213 Events that fall within the Informational category are used to inform 1214 a peer that a request cannot be immediately satisfied, and a further 1215 response will be issued in the near future. 1217 DIAMETER_STILL_WORKING 1001 1218 A request's Max-Wait-Time has expired, and the request is still 1219 being serviced. This event MAY be sent prior to the Max-Wait- 1220 Time expiration, to inform the peer that the request is not 1221 expected to be serviced in the alloted time, but the request is 1222 not being abandoned. 1224 9.1.1.2 Redirect Event 1226 Errors that fall within the Redirect Notification category are used 1227 to inform a peer that the request cannot be satisfied locally and 1228 should instead be forwarded to another server. 1230 DIAMETER_REDIRECT_INDICATION 3001 1231 A proxy or redirect server has determined that the request 1232 could not be satisfied locally and the initiator of the request 1233 should direct the request directly to the server, whose contact 1234 information has been added to the response. 1236 9.1.1.3 Transient Failure Events 1238 Errors that fall within the transient failures category are used to 1239 inform a peer that the request could not be satisfied at the time it 1240 was received, but MAY be able to satisfy the request is the error is 1241 corrected. 1243 DIAMETER_TIME_INVALID 4001 1244 The originator of the Device-Status-Ind message detected a time 1245 synchronization error, and a request for time synchronization 1246 is being requested. 1248 DIAMETER_UNSUPPORTED_TRANSFORM 4002 1249 A message was received that included an Integrity-Check-Value 1250 or CMS-Data AVP [11] that made use of an unsupported transform. 1252 DIAMETER_INVALID_ICV 4003 1253 The Request did not contain a valid Integrity-Check-Value AVP. 1255 9.1.1.4 Permanent Failure Events 1257 Errors that fall within the permanent failures category are used to 1258 inform the peer that the request failed, and cannot be satified by 1259 the originator of the Device-Status-Ind. The receiver of a DSI 1260 message with the DSI-Event set to a value that falls within this 1261 event class SHOULD forward the message to an alternate peer, if one 1262 is available. 1264 DIAMETER_INVALID_RECORD_ROUTE 5001 1265 The last Record-Route AVP in the message is not set to the 1266 identity of the sender of the message. See Section 12.0 for 1267 more information. 1269 DIAMETER_COMMAND_UNSUPPORTED 5002 1270 The Request contained a Command-Code that the receiver did not 1271 recognize or support. The Device-Status-Ind message MUST also 1272 contain an Failed-Command-Code AVP containing the unrecognized 1273 Command-Code. 1275 DIAMETER_UNABLE_TO_DELIVER 5003 1276 The request could not be delivered to a host that handles the 1277 realm, and extension, requested at this time. 1279 DIAMETER_REALM_NOT_SERVED 5004 1280 The originator of the DSI message could not deliver the message 1281 since the realm requested is unknown. 1283 DIAMETER_ERROR_TOO_BUSY 5005 1284 When returned, a Diameter node SHOULD attempt to sent the 1285 message to an alternate peer. 1287 DIAMETER_CANNOT_PROCESS_IN_TIME 5006 1288 The time limit in a request's Max-Wait-Time AVP has expired, 1289 and no response is available. This value MAY also be used to 1290 inform a peer that the request is not expected to be processed 1291 within the Max-Wait-Time value. 1293 10.0 End-to-End Error Signaling 1295 There are five different types of error conditions that can occur 1296 within Diameter. 1298 The first occurs when a Diameter message is poorly formatted, and 1299 unrecognizable, indicated in the figure below as "Bad Message". This 1300 error condition applies if a received message is less than the length 1301 of the Diameter header. Messages that generate such an error are 1302 ignored. 1304 A second case occurs when a Command-Code field is set to an 1305 unsupported value, which is shown as "Unknown Command" in the figure. 1306 Such errors generate a Device-Status-Ind message, and require per-hop 1307 behavior. 1309 A third case occurs when an AVP is received, marked as Mandatory ('M' 1310 bit is set), and is unknown by the receiver. This error condition is 1311 labelled as "Unknown AVP" in the figure below, and causes a Message- 1312 Reject-Ind message to be sent. 1314 The fourth case occurs when a message is received that contains an 1315 AVP with either an unknown or illegal value. This is labelled as "Bad 1316 AVP Value", and requires that a Message-Reject-Ind message be sent. 1318 The last two cases require that a Message-Reject-Ind message be 1319 generated to ensure that such errors are identified in both request 1320 and response messages. 1322 The last error condition occurs when an extension specific error is 1323 identified in a request or response message. In a message of type 1324 request or query, the natural corresponding answer or response 1325 message MUST be used. However, if an error occurs while processing an 1326 indication, answer or response message, a Message-Reject-Ind is used 1327 to inform the peer that an error occurred while processing the 1328 message. 1330 Error Type Ignore Send Send Send 1331 Message MRI DSI Response 1332 Bad Message X 1333 Unknown Command X 1334 Unknown AVP X 1335 Bad AVP Value X 1336 Request,Query Error X 1337 Answer,Response,Ind Error X 1339 "Ignore Message" indicates that the message is simply dropped. "Send 1340 MRI" means that a Message-Reject-Ind message is sent to report the 1341 error condition, while "Send DSI" requires that a Device-Status-Ind 1342 message is sent (see Section 9.1). "Send Response" means that the 1343 response message for a request or query message is returned. 1345 10.1 Message-Reject-Ind (MRI) Command 1347 The Message-Reject-Ind (MRI), indicated by the Command-Code set to 1348 259, provides a generic means of completing transactions by 1349 indicating errors in the messages that initiated them. The Message- 1350 Reject-Ind command is sent in response: 1352 1. An error is found in a message of type Ind, Answer and Response 1353 2. A Unknown AVP, marked as Mandatory, is received 1354 3. An AVP was received with an unknown, or illegal, value. 1356 The Message-Reject-Ind message MUST contain the same Hop-by-Hop 1357 Identifier value in the header as the message that caused the error 1358 condition. If the Session-Id AVP was present in the original message, 1359 the same AVP MUST be present in the MRI. 1361 Message Format 1362 ::= < Diameter Header: 259 > 1363 [ Session-Id ] 1364 { Result-Code } 1365 { Origin-FQDN } 1366 { Origin-Realm } 1367 { Error-Reporting-FQDN } 1368 [ Failed-Command-Code ] 1369 [ Failed-AVP ] 1370 * [ AVP ] 1371 * [ Proxy-State ] 1372 * [ Route-Record ] 1373 * [ Destination-Realm ] 1374 0*1< Integrity-Check-Value > 1376 where the Result-Code AVP indicate the nature of the error causing 1377 rejection, and the Failed-AVP AVP provides some minimal debugging 1378 data by indicating a specific AVP type which caused the problem. 1379 See the description of the Result-Code AVP for indication of when 1380 the Failed-AVP AVP MUST be present in the message. See [25] for 1381 more information. 1383 10.1.1 Failed-AVP AVP 1385 The Failed-AVP AVP (AVP Code 279) is of type OctetString and provides 1386 debugging information in cases where a request is rejected or not 1387 fully processed due to erroneous information in a specific AVP. The 1388 value of the Result-Code AVP will provide information on the reason 1389 for the Failed-AVP AVP. 1391 A Diameter message MAY contain one or more Failed-AVP AVPs, each 1392 containing a complete AVP that could not be processed successfully. 1393 The possible reasons for this AVP are the presence of an improperly 1394 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 1395 value; or the omission of a required AVP. 1397 10.1.2 Failed-Command-Code 1399 The Failed-Command-Code AVP (AVP Code 270) is of type Unsigned32 and 1400 contains the offending Command-Code that resulted in sending the 1401 Message-Reject-Ind message. 1403 10.2 Result-Code AVP 1405 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 1406 indicates whether a particular request was completed successfully or 1407 whether an error occurred. All Diameter messages of type *-Response 1408 or *-Answer MUST include one Result-Code AVP, while messages of type 1409 -Ind MAY include the Result-Code AVP. A non-successful Result-Code 1410 AVP (one containing a non 2001 value) MUST include the Error- 1411 Reporting-FQDN AVP. 1413 The Result-Code data field contains an IANA-managed 32-bit address 1414 space representing errors (see section 15.4). Diameter provides four 1415 different classes of errors, all identified by the thousands digit: 1416 - 1xxx (Informational) 1417 - 2xxx (Success) 1418 - 4xxx (Transient Failures) 1419 - 5xxx (Permanent Failure) 1421 A non-recognize class (one whose first digit is not defined in this 1422 section) MUST be handled as a permanent failure. 1424 10.2.1 Informational 1426 Errors that fall within the Informational category are used to inform 1427 a requester that the request cannot be immediately satisfied and a 1428 further response will be issued in the near future. There are 1429 currently no errors that fall within this class. 1431 10.2.2 Success 1433 Errors that fall within the Success category are used to inform a 1434 peer that a request has been successfully completed. 1436 DIAMETER_SUCCESS 2001 1437 The Request was successfully completed. 1439 10.2.4 Transient Failures 1441 Errors that fall within the transient failures category are used to 1442 inform a peer that the request could not be satisfied at the time it 1443 was received, but MAY be able to satisfy the request in the future. 1445 DIAMETER_AUTHENTICATION_REJECTED 4001 1446 The authentication process for the user failed, most likely due 1447 to an invalid password used by the user. Further attempts MUST 1448 only be tried after prompting the user for a new password. 1450 DIAMETER_NO_END_2_END_SECURITY 4002 1451 A proxy has detected that end-to-end security has been applied 1452 to portions of the Diameter message, and the proxy does not 1453 allow this security mode since it needs to alter the message by 1454 applying some local policies. 1456 10.2.5 Permanent Failures 1458 Errors that fall within the permanent failures category are used to 1459 inform the peer that the request failed, and should not be attempted 1460 again. 1462 DIAMETER_USER_UNKNOWN 5001 1463 A request was received for a user that is unknown, therefore 1464 authentication and/or authorization failed. 1466 DIAMETER_AVP_UNSUPPORTED 5002 1467 The peer received a message that contained an AVP that is not 1468 recognized or supported and was marked with the Mandatory bit. 1469 A Diameter message with this error MUST contain one or more 1470 Failed-AVP AVP containing the AVPs that caused the failure. 1472 DIAMETER_UNKNOWN_SESSION_ID 5003 1473 The request or response contained an unknown Session-Id. 1475 DIAMETER_AUTHORIZATION_REJECTED 5004 1476 A request was received for which the user could not be 1477 authorized. This error could occur if the service requested is 1478 not permitted to the user. 1480 DIAMETER_INVALID_AVP_VALUE 5005 1481 The request contained an AVP with an invalid value in its data 1482 portion. A Diameter message indicating this error MUST include 1483 the offending AVPs within a Failed-AVP AVP. 1485 DIAMETER_MISSING_AVP 5006 1486 The request did not contain an AVP that is required by the 1487 Command Code definition. If this value is sent in the Result- 1488 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 1489 The data portion of the Failed-AVP MUST only contain the AVP 1490 Code of the missing AVP. 1492 DIAMETER_INVALID_CMS_DATA 5007 1493 The Request did not contain a valid CMS-Data [11] AVP. 1495 DIAMETER_LOOP_DETECTED 5008 1496 A Proxy or Redirect server detected a loop while trying to get 1497 the message to the Home Diameter server. Further attempts 1498 should not be attempted until the loop has been fixed. 1500 DIAMETER_AUTHORIZATION_FAILED 5009 1501 A request was received for which the user could not be 1502 authorized at this time. This error could occur when the user 1503 has already expended allowed resources, or is only permitted to 1504 access services within a time period. 1506 DIAMETER_CONTRADICTING_AVPS 5010 1507 The Home Diameter server has detected AVPs in the request that 1508 contradicted each other, and is not willing to provide service 1509 to the user. One or more Failed-AVP AVPs MUST be present, 1510 containing the AVPs that contradicted each other. 1512 10.3 Error-Message AVP 1514 The Error-Message AVP (AVP Code 281) is of type OctetString. It is a 1515 human readable UTF-8 character encoded string. It MAY accompany a 1516 Result-Code AVP as a human readable error message. The Error-Message 1517 AVP is not intended to be useful in real-time, and SHOULD NOT be 1518 expected to be parsed by network entities. 1520 10.4 Error-Reporting-FQDN AVP 1522 The Error-Reporting-FQDN AVP (AVP Code 294) is of type OctetString, 1523 encoded in the UTF-8 [24] format. This AVP contains the Network 1524 Access Identifier of the Diameter host that set the Result-Code AVP 1525 to a value other than 2001 (Success). This AVP is intended to be used 1526 for troubleshooting purposes, and MUST be set when the Result-Code 1527 AVP indicates a failure. 1529 11.0 "User" Sessions 1531 When a user requests access to the network, a Diameter client issues 1532 an authentication and authorization request to its local server. The 1533 request contains a Session-Id AVP, which is used in subsequent 1534 messages (e.g. subsequent authorization, accounting, etc) relating to 1535 the user's session. The Session-Id AVP is a means for the client and 1536 servers to correlate a Diameter message with a user session. 1538 When a Diameter server authorizes a user to use network resources, it 1539 SHOULD add the Authorization-Lifetime AVP to the response. The 1540 Authorization-Lifetime AVP defines the maximum amount of time a user 1541 MAY make use of the resources before another authorization request is 1542 to be transmitted to the server. If the server does not receive 1543 another authorization request before the timeout occurs, it SHOULD 1544 release any state information related to the user's session. Note 1545 that the Authorization-Lifetime AVP implies how long the Diameter 1546 server is willing to pay for the services rendered, therefore a 1547 Diameter client SHOULD NOT expect payment for services rendered past 1548 the session expiration time. 1550 The base protocol does not include any authorization request 1551 messages, since these are largely application-specific and are 1552 defined in a Diameter protocol extension document. However, the base 1553 protocol does define a set of messages that are used to terminate 1554 user sessions. These are used to allow servers that maintain state 1555 information to free resources. 1557 11.1 Session State Machine 1559 This section contains a finite state machine, representing the life 1560 cycle of Diameter sessions, and MUST be observed by all Diameter 1561 implementations. The term Service-Specific below refers to a message 1562 defined in a Diameter extension (e.g. Mobile IP, NASREQ). 1564 State Event Action New State 1565 ----- ----- ------ --------- 1566 Idle Client or Device Requests send serv. Pending 1567 access specific 1568 auth req 1570 Idle Service-Specific authorization send serv. Open 1571 request received, and specific 1572 successfully processed response 1574 Pending Successful Service-Specific Grant Open 1575 Authorization response Access 1576 received 1578 Open Authorization-Lifetime expires send serv. Open 1579 specific 1580 auth req 1582 Open Successful Service-Specific Extend Open 1583 Authorization response Access 1584 received 1586 Open Failed Service-Specific Discon. Closed 1587 Authorization response user/device 1588 received. 1590 Open Session-Timeout Expires on send STR Discon 1591 NAS 1593 Open STI Received send STR Discon 1595 Open Session-Timeout Expires on send STI Discon 1596 home AAA server 1598 Discon STI Received ignore Discon 1600 Discon STR Received Discon. Closed 1601 user/device 1603 Discon STA Received Discon. Closed 1604 user/device 1606 Closed Transition to state Cleanup 1608 When the Cleanup action is invoked, the Diameter node MAY attempt to 1609 release all resources for the particular session. Any event not 1610 listed above MUST be considered as an error condition, and a 1611 response, if applicable, MUST be returned to the originator of the 1612 message. 1614 11.2 Session-Id AVP 1616 The Session-Id AVP (AVP Code 263) is of type OctetString and is used 1617 to identify a specific session (see section 11.0). The Session-Id 1618 data uses the UTF-8 [24] character set. All messages pertaining to a 1619 specific session MUST include only one Session-Id AVP and the same 1620 value MUST be used throughout the life of a session. When present, 1621 the Session-Id SHOULD appear immediately following the Diameter 1622 Header (see section 3.0). 1624 For messages that do not pertain to a specific session, multiple 1625 Session-Id AVPs MAY be present as long as they are encapsulated 1626 within an AVP of type Grouped. 1628 The Session-Id MUST be globally unique at any given time since it is 1629 used by the server to identify the session (or flow). The format of 1630 the session identifier SHOULD be as follows: 1632 1635 The monotonically increasing 32 bit value SHOULD NOT start at zero 1636 upon reboot, but rather start at a random value. This will minimize 1637 the possibility of overlapping Session-Ids after a reboot. 1638 Alternatively, an implementation MAY keep track of the increasing 1639 value in non-volatile memory. The optional value is implementation 1640 specific but may include a modem's device Id, a layer 2 address, 1641 timestamp, etc. 1643 The session Id is created by the Diameter device initiating the 1644 session, which in most cases is done by the client. Note that a 1645 Session-Id MAY be used by more than one extension (e.g. 1646 authentication for a specific service and accounting, both of which 1647 have separate extensions). 1649 11.3 Authorization-Lifetime AVP 1651 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 1652 and contains the maximum number of seconds of service to be provided 1653 to the user before the user is to be re-authenticated and/or re- 1654 authorized. Great care should be taken when the Authorization- 1655 Lifetime value is determined, since a low value could create 1656 significant Diameter traffic, which could congest both the network 1657 and the servers. 1659 This AVP MAY be provided by the client as a hint of the maximum 1660 duration that it is willing to accept. However, the server DOES NOT 1661 have to observe the hint, and MAY return a value that is smaller than 1662 the hint. A value of zero means that no re-authorization is required. 1664 11.4 Session-Timeout AVP 1666 The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and 1667 contains the maximum number of seconds of service to be provided to 1668 the user before termination of the session. A value of zero means 1669 that this session has an unlimited number of seconds before 1670 termination. 1672 This AVP MAY be provided by the client as a hint of the maximum 1673 duration that it is willing to accept. However, the server DOES NOT 1674 have to observe the hint, and MAY return a value that is smaller than 1675 the hint. 1677 11.5 User-Name AVP 1679 The User-Name AVP (AVP Code 1) [1] is of type OctetString, which 1680 contains the User-Name. The value is represented as a UTF-8 1681 character encoded string in a format consistent with the NAI 1682 specification [8]. 1684 11.6 Max-Wait-Time AVP 1686 The Max-Wait-Time AVP (AVP Code 295) is of type Unsigned32, and 1687 contains the maximum amount of time the downstream server is willing 1688 to wait for a response. A server that determines that it cannot 1689 satisfy a request within the requested time MUST issue a DSI message 1690 with the DSI-Event set to DIAMETER_STILL_WORKING or 1691 DIAMETER_CANNOT_PROCESS_IN_TIME. 1693 11.7 Session Termination 1695 The Diameter Base Protocol provides a set of messages that MUST be 1696 used by any peer to explicitly request that a previously 1697 authenticated and/or authorized session be terminated. Since the 1698 Session-Id is typically tied to a particular service (i.e. Mobile IP, 1699 NASREQ, etc), the session termination messages are used to request 1700 that the service tied to the Session Id be terminated. 1702 11.7.1 Session-Termination-Ind 1704 The Session-Termination-Ind (STI), indicated by the Command-Code set 1705 to 274, MAY be sent by any Diameter entity to the access device to 1706 request that a particular session be terminated. This message MAY be 1707 used when a server detects that a session MUST be terminated, which 1708 is typically done as a policy decision (e.g. local resources have 1709 been expended, etc). The Destination-FQDN AVP MUST be present, and 1710 contain the NAI of the access device that initiated the session (see 1711 section 11.0). 1713 Upon receipt of the STI message, the access device SHOULD issue a 1714 Session-Terminate-Request message. 1716 Message Format 1718 ::= < Diameter Header: 274 > 1719 < Session-Id > 1720 { Origin-FQDN } 1721 { Origin-Realm } 1722 { User-Name } 1723 { Destination-Realm } 1724 { Destination-FQDN } 1725 * [ AVP ] 1726 * [ Proxy-State ] 1727 0*1< Integrity-Check-Value > 1729 11.7.2 Session-Termination-Request 1731 The Session-Termination-Request (STR), indicated by the Command-Code 1732 set to 275, is sent by the access device to inform the Diameter 1733 Server that an authenticated and/or authorized session is being 1734 terminated. 1736 Message Format 1738 ::= < Diameter Header: 275 > 1739 < Session-Id > 1740 { Origin-FQDN } 1741 { Origin-Realm } 1742 { User-Name } 1743 { Destination-Realm } 1744 * [ AVP ] 1745 * [ Proxy-State ] 1746 * [ Route-Record ] 1747 0*1< Integrity-Check-Value > 1749 11.7.3 Session-Termination-Answer 1751 The Session-Termination-Answer (STA), indicated by the Command-Code 1752 set to 276, is sent by the Diameter Server to acknowledge that the 1753 session has been terminated. The Result-Code AVP MUST be present, and 1754 MAY contain an indication that an error occurred while servicing the 1755 STR. 1757 Upon sending or receipt of the STA, the Diameter Server MUST release 1758 all resources for the session indicated by the Session-Id AVP. Any 1759 intermediate server in the Proxy-Chain MAY also release any 1760 resources, if necessary. 1762 Message Format 1764 ::= < Diameter Header: 276 > 1765 < Session-Id > 1766 { Result-Code } 1767 { Origin-FQDN } 1768 { Origin-Realm } 1769 { Destination-FQDN } 1770 { User-Name } 1771 { Destination-Realm } 1772 * [ AVP ] 1773 * [ Proxy-State ] 1774 * [ Route-Record ] 1775 0*1< Integrity-Check-Value > 1777 12.0 Message Routing 1779 This section describes the expected behavior of a Diameter server 1780 acting as a proxy or redirect server. 1782 12.1 Realm-Based Message Routing 1784 Diameter request, query and indication message routing is done 1785 through the use of the realm portion of the Network Access Identifier 1786 (NAI), and an associated realm routing table (see section 12.1.1). 1787 The NAI has a format of user@realm, and Diameter servers have a list 1788 of locally supported realms, and MAY have a list of externally 1789 supported realms. When a request, query or indication message is 1790 received that includes a realm that is not locally supported, the 1791 message is proxied to the Diameter entity configured in the "route" 1792 table. 1794 Figure 2 depicts an example where DIA1 receives a request to 1795 authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local 1796 realm route table and determines that the message must be proxied to 1797 DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 1798 checks its realm route table, and determines that the realm is 1799 locally supported, and processes the authentication request, and 1800 returns the response. How the response actually makes it back to the 1801 sender of the original request is described in the next section. 1803 (Origin-FQDN=dia1.mno.net) (Origin-FQDN=dia1.mno.net) 1804 (Origin-Realm=mno.net) (Origin-Realm=mno.net) 1805 (Destination-Realm=abc.com) (Destination-Realm=abc.com) 1806 (Record-Route=dia2.xyz.com) 1807 +------+ ------> +------+ ------> +------+ 1808 | | (Request) | | (Request) | | 1809 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1810 | | | | | | 1811 +------+ <------ +------+ <------ +------+ 1812 mno.net (Response) xyz.com (Response) abc.com 1813 (Destination-Realm=mno.net) (Destination-Realm=abc.net) 1814 (Origin-Realm=abc.com) (Origin-Realm=abc.com) 1815 (Destination-FQDN=dia1.mno.net) (Destination-FQDN=dia1.mno.net) 1816 (Record-Route=dia2.xyz.com) 1817 Figure 2: Realm-Based Routing 1819 Note the processing rules contained in this section are intended to 1820 be used as general guidelines to Diameter developers. Certain 1821 implementations MAY use different methods than the ones described 1822 here, and still be in compliance with the protocol specification. 1824 12.1.1 Realm-Based Routing Table 1826 All Realm-Based routing lookups are performed against what is 1827 commonly known as the Domain Routing Table (see section 17.0). A 1828 Domain Routing Table Entry contains the following fields: 1829 - Domain Name. The Domain Name is analogous to the realm portion 1830 of the NAI. This is the field that is typically used as a 1831 primary key in the routing table lookups. Note that some 1832 implementations perform their lookups based on longest-match- 1833 from-the-right on the realm rather than requiring an exact 1834 match. 1835 - Extension Id. It is possible for a routing entry to have a 1836 different destination based on the extension identifier of the 1837 message. This field is typically used as a secondary key field 1838 in routing table lookups. 1839 - Local Action. The Local Action field is used to identify how a 1840 message should be treated. The following actions are supported: 1841 1. LOCAL - Diameter messages that resolve to a routing entry 1842 with the Local Action set to Local can be satisfied 1843 locally, and do not need to be forwarded to another 1844 server. 1845 2. PROXY - All Diameter messages that fall within this 1846 category MUST be forwarded to a next hop server. The local 1847 server MAY apply its local policies to the message by 1848 including new AVPs to the message prior to forwarding. 1849 See section 12.4 for more information. 1850 3. REDIRECT - Diameter messages that fall within this 1851 category MUST have the identity of the home Diameter 1852 server(s) appended, and returned to the sender of the 1853 message. See section 12.3 for more information. 1854 - Server Identifier - One or more servers the message is to be 1855 forwarded to. When the Local Action is set to PROXY, this field 1856 contains the identities of the server(s) the message must be 1857 forwarded to. When the Local Action field is set to REDIRECT, 1858 this field contains the Home Diameter server(s) for the realm. 1860 It is important to note that Diameter servers MUST support at least 1861 one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do 1862 not need to support all modes of operation in order to conform with 1863 the protocol specification. Servers MUST NOT reorder AVPs with the 1864 same AVP Code. 1866 When a message is being proxied, the servers in a given domain 1867 routing entry MUST have advertised the Extension Identifier (see 1868 section 6.1.3) for the given message, or have advertised the Wildcard 1869 Extension. 1871 12.2 Proxy and Redirect Server handling of requests 1873 When a message of type request, query or indication is received by a 1874 proxy or redirect server, and it is determined that the request 1875 cannot be locally handled, the next hop for the request is determined 1876 in the following order: 1877 1. If the Destination-FQDN AVP is present, and the host specified 1878 in the AVP can be directly contacted, the message is forwarded 1879 to the host (see section 8.1 for more information), or 1880 2. If the Destination-Realm AVP is present, a routing table lookup 1881 is performed using the domain specific in the AVP. 1883 A message that does not contain any of the above AVPs MUST NOT be 1884 routed. If the message in question cannot be handled locally, a 1885 Message-Reject-Ind is sent with the Result-Code AVP set to an 1886 appropriate error condition. 1888 12.3 Redirect Server 1890 A Redirect Server is one that provides NAI Realm to Diameter Home 1891 Server address resolution. When a message is received by a peer, the 1892 Destination-Realm is extracted from the message, and is used to 1893 perform a lookup in the domain routing table. Implementations MAY 1894 also use the Extension Id as a secondary key in the domain routing 1895 table lookup. 1897 Successful routing table lookups will return one or more home 1898 Diameter servers that could satisfy the message. The home servers are 1899 encoded in one or more Redirect-Host AVPs, and the Command-Code field 1900 is set to Device-Status-Ind. 1902 +------------------+ 1903 | Diameter | 1904 | Redirect Server | 1905 +------------------+ 1906 ^ | 1907 Request | | DSI + 1908 joe@xyz.com | | DSI-Event = Redirect + 1909 | | Redirect-Host AVP(s) 1910 | v 1911 +----------+ Request +----------+ 1912 | abc.net |------------->| xyz.net | 1913 | Diameter | | Diameter | 1914 | Server |<-------------| Server | 1915 +----------+ Response +----------+ 1916 Figure 3: Diameter Redirect Server 1918 Lastly, the DSI-Event AVP is added with the Data field of the AVP set 1919 to DIAMETER_REDIRECT_INDICATION, and the message is returned to the 1920 sender of the request. Redirect servers MAY also include the 1921 certificate of the Home server(s). These certificates are 1922 encapsulated in a CMS-Data AVP [11]. When this occurs, the server 1923 forwarding the request directly to the Home Diameter server SHOULD 1924 include its own certificate in the message. 1926 12.3.1 Redirect-Host AVP 1928 The Redirect-Host AVP (AVP Code 292) is of type Grouped and is found 1929 in Device-Status-Ind messages that include the DSI-Event AVP set to 1930 DIAMETER_REDIRECT_REQUEST. This AVP only needs to be used if the host 1931 the message is to be redirected to is not listening on the standard 1932 Diameter port. Its Data field has the following ABNF grammar: 1934 Redirect-Host = Redirect-Host-Address Redirect-Host-Port 1935 Redirect-Host-Address = ; See Section 12.3.2 1936 Redirect-Host-Port = ; See Section 12.3.3 1938 The Redirect-Host-Address AVP Data field contains the IP Address of 1939 the Diameter host to which the request MUST be redirected. The 1940 Redirect-Host-Port contains the port number to which the request 1941 should be sent. Upon receipt of such a event, and this AVP, the 1942 receiving host SHOULD send the request directly to the host 1943 identified by the Redirect-Host-Address AVP. 1945 +---------------------------------------------------------------+ 1946 | AVP Header (AVP Code = 292) | 1947 +---------------------------------------------------------------+ 1948 | Redirect-Host-Address AVP | 1949 +---------------------------------------------------------------+ 1950 | Redirect-Host-Port AVP | 1951 +---------------------------------------------------------------+ 1953 12.3.2 Redirect-Host-Address AVP 1955 The Redirect-Host-Address AVP (AVP Code 278) is of type Address. Its 1956 use is described in Section 12.3.1. 1958 12.3.3 Redirect-Host-Port AVP 1960 The Redirect-Host-Port AVP (AVP Code 277) is of type Unsigned32. Its 1961 use is described in Section 12.3.1. 1963 12.4 Proxy Server 1965 This section outlines the processing rules for Diameter proxy 1966 servers. A proxy server can either be stateful or stateless. A Proxy 1967 server MAY act in a stateful manner for some requests, and be 1968 stateless for others. There are two types of states that servers MAY 1969 wish to maintain; transaction and session. 1971 Maintaining transaction state implies that a server keeps a copy of a 1972 request, which is then used when the corresponding response is 1973 received. This could be done to apply local policies to the message, 1974 or simply for auditing purposes. Maintaining session state implies 1975 that a server keeps track of all "active" users. An active user is 1976 one that has been authorized for a particular service, and the server 1977 has not received any indication that the user has relinquished 1978 access. 1980 A stateless proxy is one that does not maintain transaction, nor 1981 session state. It frees the messages sent once acknowledgements are 1982 received by the transport layer. 1984 A stateful proxy can be viewed as a Diameter Server upon receiving a 1985 request, and as a Client when forwarding the message. For all intents 1986 and purposes, stateful servers terminate an upstream "session", and 1987 initiates a downstream "session" (see Figure 4), and MAY provide the 1988 following features: 1989 - Protocol translation (e.g. RADIUS <-> Diameter) 1990 - Limiting resources authorized to a particular user 1991 - Per user or transaction auditing 1993 +--------+ +-----------------+ +--------+ 1994 | Client | --------> | Server | Client | -------> | Server | 1995 +--------+ +-----------------+ +--------+ 1996 Figure 4 - Example of Stateful Proxy 1998 A stateful proxy that maintains transaction state SHOULD release 1999 transaction information after a request's corresponding response has 2000 been forwarded towards the recipient, and has been acknowledged by 2001 the underlying transport. 2003 A stateful proxy that maintains session state SHOULD release the 2004 session state once it is informed that a user and/or device has 2005 relinquished access. 2007 Home servers processing requests that include the Route-Record and/or 2008 the Proxy-State AVPs MUST return these AVPs in the same order in the 2009 corresponding response. 2011 12.4.1 Proxying Requests 2013 In addition to the rules defined in section 12.2, the following 2014 procedures MUST be handled by proxy servers handling messages of type 2015 request, query or indication. 2017 A proxy server MUST check for forwarding loops before proxying a 2018 message of type Request, Query or Indication. Such as message has 2019 been looped if the server finds its own address in a Route-Record 2020 AVP. 2022 A Diameter server that proxies a message or type Request, Query or 2023 Indication MUST append a Route-Record AVP, which includes its 2024 identity. Diameter Servers that receive messages MUST validate the 2025 last Route-Record AVP in the message and ensure that the host 2026 identified in the AVP is the same as the sender of the message. 2028 A Proxy Server MAY also include the Proxy-State AVP in a message of 2029 type Request or Query, which is used to encode local state 2030 information. The Proxy-State AVP is guaranteed to be present in the 2031 corresponding response. 2033 The message is then forwarded to the downstream Diameter server, as 2034 identified in the Domain Routing Table. 2036 Proxy Server MUST save the Hop-by-Hop Identifier in request messages, 2037 if the value of the field is changed, with a locally unique value. 2038 The saved identifier MAY be encoded in the Proxy-State AVP, and will 2039 be required in the processing of the corresponding response. 2041 12.4.2 Proxying Responses 2043 A proxy server MUST only process messges of type Response or Answer 2044 whose last Route-Record AVP matches one of its addresses. Any 2045 responses that do not conform to this rule MUST be dropped. The last 2046 Route-Record AVP MUST be removed from the message before it is 2047 forwarded to the next hop, which is identified by the second to last 2048 Route-Record AVP. 2050 If the last Proxy-State AVP in the message is targeted to the local 2051 Diameter server, the AVP MUST be removed. 2053 If a proxy server receives a response with a Result-Code AVP 2054 indicating a failure, it MUST NOT modify the contents of the AVP. Any 2055 additional local errors detected SHOULD be logged, but not reflected 2056 in the Result-Code AVP. 2058 Prior to forwarding the response, proxy servers MUST restore the 2059 original value of the Diameter header's Hop-by-Hop Identifier field. 2061 12.4.3 Route-Record AVP 2063 The Route-Record AVP (AVP Code 282) is of type OctetString, encoded 2064 in the UTF-8 [24] format, and contains the Fully Qualified Domain 2065 Name of the Proxy appending this AVP to a Diameter message. 2067 12.4.4 Proxy-State AVP 2069 The Proxy-State AVP (AVP Code = 33) is of type Grouped. The Grouped 2070 Data field has the following ABNF grammar: 2072 Proxy-State = Proxy-Address Proxy-Info 2073 Proxy-Address = ; See Section 12.4.5 2074 Proxy-Info = ; See Section 12.4.6 2076 The Proxy-Address AVP Data field contains one of the IP addresses of 2077 the system that created the AVP. This assists hosts in determining 2078 whether a Proxy-State AVP is intended for the local host. The Proxy- 2079 Info AVP contains state information, and MUST be treated as opaque 2080 data. 2082 +---------------------------------------------------------------+ 2083 | AVP Header (AVP Code = 33) | 2084 +---------------------------------------------------------------+ 2085 | Proxy-Address AVP | 2086 +---------------------------------------------------------------+ 2087 | Proxy-Info AVP | 2088 +---------------------------------------------------------------+ 2090 12.4.5 Proxy-Address AVP 2092 The Proxy-Address AVP (AVP Code = 280) is of type Address. Its use 2093 is described in Section 12.4.4. 2095 12.4.6 Proxy-Info AVP 2097 The Proxy-Info AVP (AVP Code = 284) is of type OctetString. Its use 2098 is described in Section 12.4.4. 2100 12.4.7 Destination-Realm AVP 2101 The Destination-Realm AVP (AVP Code 283) is of type OctetString, 2102 encoded in the UTF-8 [24] format, and contains the realm the message 2103 is to be routed to. Diameter Clients insert the realm portion of the 2104 User-Name AVP, while home servers insert the value of the Origin- 2105 Realm AVP into this AVP. When present, the Destination-Realm AVP is 2106 used to perform message routing decisions. 2108 12.5 Applying Local Policies 2110 Proxies MAY apply local access policies to Diameter requests, or 2111 responses, by adding, changing or deleting AVPs in the messages. 2112 Proxies that apply local policies MUST NOT allow end-to-end security 2113 on any messages that traverse through it, unless security is 2114 terminated locally. 2116 A proxy wishing to modify a Diameter message to enforce some local 2117 policy that detects that end-to-end security has been applied to the 2118 message MUST return a response to the originator with the Result-Code 2119 set to DIAMETER_NO_END_2_END_SECURITY. The originator of the request 2120 MAY re-issue the request with no end-to-end security if it falls 2121 within its local policy. 2123 In the event that the Home Diameter server receives a request with 2124 contradictory information (possibly due to some proxy adding a local 2125 policy), it MAY accept the latest AVP, or MAY return the response 2126 with the Result-Code AVP set to DIAMETER_CONTRADICTING_AVPS. However, 2127 a NAS receiving a response that contains contradictory information 2128 SHOULD reject service to the user. 2130 12.6 Hiding Network Topology 2132 Stateful proxies forwarding requests to servers outside of their 2133 administrative domain MAY hide the internal network topology. Servers 2134 perform this by removing all Route-Record AVPs in the message, and 2135 maintains the Route-Record AVPs to add to the corresponding response. 2136 Such stateful servers MUST still add their own Route-Record AVP to 2137 the request prior to forwarding. 2139 12.7 Loop Detection 2141 When a Diameter Proxy or Redirect server receives a message of type 2142 Request, Query or Indication, it MUST examine all Route-Record AVPs 2143 in the message to determine whether such an AVP already exists with 2144 the local server's identity. If an AVP with the local host's identity 2145 is found in the request, it is an indication that the message is 2146 being looped through the same set of proxies. When such an event 2147 occurs, the Diameter server that detects the loop returns a response 2148 with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 2150 13.0 Diameter Message Security 2152 The Diameter Base protocol MAY be secured in one of three ways. The 2153 first method does not involve any security mechanisms in the Diameter 2154 protocol, but relies on an underlying security mechanism, such as IP 2155 Security. The second method is hop-by-hop security, which SHOULD be 2156 supported by all Diameter implementations. The third method is 2157 optional and requires a Public Key Infrastructure [14], and is 2158 documented in [11]. 2160 13.1 Hop-by-Hop Security 2162 Diameter Hop-by-Hop security provides message integrity and per AVP 2163 encryption, and requires that the communicating entities have a pre- 2164 configured shared secret. Hop-by-Hop security is very difficult to 2165 deploy and administer in large scale networks and involves symmetric 2166 trust, unlike security based on a public key infrastructure (PKI). 2167 PKI is used for Diameter End-to-End security, and is defined in [11]. 2168 Hop-by-Hop security may be desirable in environments where symmetric 2169 cryptography is sufficient or when a PKI is not available. 2171 Figure 5 below provides an example of hop-by-hop security in a proxy 2172 chain. Assuming that the packet was received by DIA2 from DIA1, and 2173 was to be proxied to DIA3, the following steps would be taken: 2175 1. Validating the message's integrity using the shared secret with 2176 DIA1, and removing the authenticated security AVPs. 2178 2. Decrypting any encrypted AVPs using the secret shared with DIA1. 2180 3. Re-encrypting AVPs using the secret shared with DIA3. 2182 4. Computing the message hash using the secret shared with DIA3, 2183 and adding it to the ICV AVP in the Diameter message. 2185 (Shared-Secret-1) (Shared-Secret-2) 2186 +------+ -----> +------+ ------> +------+ 2187 | | |1 3| | | 2188 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 2189 | | |2 4| | | 2190 +------+ +------+ +------+ 2191 Figure 5: Hop-by-Hop Security in Proxy Environments 2193 The above steps that each proxy MUST perform in a proxy chain clearly 2194 describes the security issues associated with hop-by-hop security in 2195 a proxy environment. Since the message integrity is re-computed at 2196 each node in the chain, it is not possible to detect if a proxy 2197 modified information in the message (e.g. session time). Furthermore, 2198 any sensitive information would be known to all proxies in the chain, 2199 since each node must decrypt AVPs. Therefore, Any AVPs that contain 2200 data that MUST NOT be seen by intermediate Diameter nodes MUST be 2201 protected via the mechanism described in the strong security 2202 extension [11]. 2204 It is highly recommended that the size of the shared secrets used be 2205 sufficiently long (e.g. 128 bits), and that different shared secrets 2206 be used for both authentication and encryption. 2208 13.1.1 Integrity-Check-Value AVP 2210 The Integrity-Check-Value AVP (AVP Code 259) is of type Grouped and 2211 is used for hop-by-hop message authentication and integrity. 2213 The Diameter header as well as all AVPs (including padding) up to the 2214 Digest AVP is protected by the Integrity-Check-Value AVP. Note that 2215 the Message Length field in the Diameter header MUST be set to zero 2216 (0) prior to the ICV calculation. The Timestamp AVP provides replay 2217 protection and the Nonce AVP provides randomness. If present, any 2218 AVPs in a message that is not succeeded by the Integrity-Check-Value 2219 AVP MUST be ignored. 2221 All Diameter implementations SHOULD support this AVP. 2223 The Integrity-Check-Value AVP (AVP Code = 259) is of type Grouped. 2224 The grammar for the grouped Data field is defined is: 2226 Integrity-Check-Value = Nonce Time Auth-Trans-Id Key-ID Digest 2227 Nonce = ; Nonce, See Section 13.2 2228 Timestamp = ; Timestamp, See Section 13.3 2229 Auth-Trans-Id = ; Authentication-Transform-Id, / 2230 ; See Section 13.1.1.1 2231 Key-ID = ; Key-ID, See Section 13.4 2232 Digest = ; Digest, See Section 13.1.1.2 2234 +---------------------------------------------------------------+ 2235 | AVP Header (AVP Code = 259) | 2236 +---------------------------------------------------------------+ 2237 | Nonce AVP | 2238 +---------------------------------------------------------------+ 2239 | Timestamp AVP | 2240 +---------------------------------------------------------------+ 2241 | Authentication-Transform-Id AVP | 2242 +---------------------------------------------------------------+ 2243 | Key-ID AVP | 2244 +---------------------------------------------------------------+ 2245 | Digest AVP | 2246 +---------------------------------------------------------------+ 2248 13.1.1.1 Authentication-Transform-Id AVP 2250 The Transform-Id AVP (AVP Code = 285) is of type Unsigned32. This 2251 value identifies the transform that was used to compute the ICV. The 2252 following values are defined in this document: 2254 HMAC-MD5-96[6] 1 2255 The ICV is computed using the HMAC-MD5 algorithm, and the first 2256 12 bytes of the hash output is included in the Digest AVP. All 2257 Diameter implementations supporting this AVP MUST support this 2258 transform. Using the example code provided in [6], the 2259 following call would be used to generate the Digest AVP: 2261 hmac_md5(DiameterMessage, MessageLength, Secret, 2262 Secretlength, Output) 2264 where the DiameterMessage is the complete message up to the 2265 Digest AVP. 2267 13.1.1.2 Digest AVP 2269 The Digest AVP (AVP Code = 287) is of type OctetString. This value 2270 contains the output from the hashing algorithm, covering all AVPs in 2271 the message, including all AVPs in the Integrity-Check-Value AVP up 2272 to, but not including, the Digest AVP. 2274 13.1.2 Encrypted-Payload AVP 2276 The Encrypted-Payload AVP (AVP Code 260) is of type Grouped and is 2277 used to encapsulate encrypted AVPs for privacy during transmission. 2279 Hop-by-Hop confidentiality is achieved by encapsulating all AVPs 2280 which are to be encrypted into an Encrypted-Payload AVP. This 2281 feature SHOULD be supported by Diameter implementations. 2283 The grammar for the grouped Data field is defined is: 2285 Encrypted-Payload = Enc-Trans-Id Key-ID ptextlen data 2286 Enc-Trans-Id = ; Encryption-Transform-Id, / 2287 ; See Section 13.1.2.1 2288 Key-ID = ; See Section 13.4 2289 ptextlen = ; Plaintext-Data-Length, See Section 13.1.2.2 2290 data = ; Encrypted-Data, See Section 13.1.2.3 2292 +---------------------------------------------------------------+ 2293 | AVP Header (AVP Code = 260) | 2294 +---------------------------------------------------------------+ 2295 | Encryption-Transform-Id AVP | 2296 +---------------------------------------------------------------+ 2297 | Key-ID AVP | 2298 +---------------------------------------------------------------+ 2299 | Plaintext-Data-Length AVP | 2300 +---------------------------------------------------------------+ 2301 | Encrypted-Data AVP | 2302 +---------------------------------------------------------------+ 2304 13.1.2.1 Encryption-Transform-Id AVP 2306 The Encryption-Transform-Id AVP (AVP Code = 288) is of type 2307 Unsigned32. This AVP identifies the transform that was used to 2308 encrypt the data contained in the Encrypted-Data AVP. The following 2309 values are defined in this document: 2311 MD5 1 2312 See section 13.1.2.1.1 for more information. 2314 13.1.2.1.1 MD5 Payload Hiding 2316 The plain text (which is a buffer containing one or more AVPs) is 2317 first padded to a sixteen (16) byte boundary with 0 bytes. Since the 2318 encapsulated AVPs have length fields, it is possible to detect their 2319 boundaries, whether or not padding has been done. 2321 One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 2322 hash is performed on the: 2324 - last Nonce AVP which precedes the Encrypted-Payload AVP 2325 - the shared authentication secret 2327 This MD5 hash value is then XORed with the first 16 octet segment of 2328 the buffer to encrypt. The resulting 16 octet result is saved as the 2329 first 16 octets of the encrypted buffer. The result is also used to 2330 calculate a new value using MD5: 2332 - the shared authentication secret 2333 - the 16 byte result of the previous XOR 2335 This value is then XORed with the next 16 bytes. This is done for 2336 each 16 bytes successively in the buffer to encrypt, producing an 2337 equal sized encrypted buffer. 2339 The receiver of a Diameter message with an Encrypted-Payload AVP MUST 2340 first check the integrity of the message, either through the ICV, or 2341 the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP. Then 2342 the Encrypted-Payload AVP is decrypted, by reversing the above 2343 procedure, which applied to the buffer will reproduce the plain text 2344 version. The decapsulated AVPs are then used to process the Diameter 2345 message in the normal manner. 2347 13.1.2.2 Plaintext-Data-Length AVP 2349 The Plaintext-Data-Length AVP (AVP Code = 289) is of type Unsigned32, 2350 and contains the length of the plaintext data. This AVP is necessary 2351 in order to not treat any possible padded data, added as part of the 2352 encryption transform, as part of the plaintext. 2354 13.1.2.3 Encrypted-Data AVP 2356 The Encrypted-Data AVP (AVP Code = 290) is of type OctetString. This 2357 AVP contains the encrypted AVPs. 2359 13.2 Nonce AVP 2361 The Nonce AVP (AVP Code 261) is of type OctetString and is present in 2362 the Integrity-Check-Value AVP and is used to ensure randomness within 2363 a message. The content of this AVP MUST be a random value of at least 2364 128 bits. 2366 13.3 Timestamp AVP 2368 The Timestamp AVP (AVP Code 262) is of type Unsigned32 and is used to 2369 add replay protection to the Diameter protocol. The Data field of 2370 this AVP is the most significant four octets returned from an NTP 2371 [18] server that indicates the number of seconds expired since Jan. 2372 1, 1900. 2374 Messages that are older than a configurable maximum age SHOULD be 2375 rejected (see section 17.0) and a response SHOULD be returned with 2376 the Result-Code AVP Data field set to DIAMETER_TIMEOUT. Note that the 2377 larger the configurable value, the more susceptible one is to a 2378 replay attack. However, one does have to take into account the 2379 possibility for clock drift, and the latency involved in the 2380 transmission of the message over the network. The timestamp AVP 2381 SHOULD be updated prior to retransmission. 2383 A Diameter node that receives a message with the Result-Code AVP set 2384 to DIAMETER-TIMEOUT MAY use the time found in the Timestamp AVP 2385 within the reply in order to synchronize its clock with its peer. 2386 When time synchronization is done, the sender MUST NOT change its 2387 local time, but SHOULD adjust the time delta for all outgoing 2388 messages to the peer, and require that its local time be used in 2389 received messages. 2391 Implementations must be prepared to wrap at the epochal 2038 where 2392 Time values are used, and 0,1,... MUST be considered greater than 2393 2^32-1 at that time. 2395 13.4 Key-Id AVP 2397 The Key-Id AVP (AVP Code = 286) is of type Unsigned32. This value 2398 contains a key identifier, which is used to identify the keying 2399 information used to generate the Digest AVP or the Encrypted-Data 2400 AVP. 2402 14.0 AVP Table 2404 The following table presents the AVPs defined in this document, and 2405 specifies in which Diameter messages they MAY, or MAY NOT be present. 2406 Note that AVPs that can only be present within a Grouped AVP are not 2407 represented in this table. 2409 The table uses the following symbols: 2410 0 The AVP MUST NOT be present in the message. 2411 0+ Zero or more instances of the AVP MAY be present in the 2412 message. 2413 0-1 Zero or one instance of the AVP MAY be present in the 2414 message. 2416 1 One instance of the AVP MUST be present in the message. 2418 +-------------------------------+ 2419 | Command-Code | 2420 |---+---+---+---+---+---+---+---+ 2421 Attribute Name |DRI|DSI|DWR|DWA|MRI|STI|STR|STA| 2422 ------------------------------|---+---+---+---+---+---+---+---| 2423 Authorization-Lifetime |0 |0 |0 |0 |0 |0 |0 |0 | 2424 Destination-FQDN |0 |0 |0 |1 |0+ |1 |0+ |1 | 2425 Destination-Realm |1 |1 |1 |1 |1 |1 |1 |1 | 2426 DSI-Event |0 |1 |0 |0 |0 |0 |0 |0 | 2427 Encrypted-Payload |0 |0 |0 |0 |0 |0 |0 |0 | 2428 Error-Message |0 |0 |0 |0 |0 |0 |0 |0 | 2429 Error-Reporting-FQDN |0 |0 |0 |0 |1 |0 |0 |0 | 2430 Extension-Id |1+ |0 |0 |0 |0 |0 |0 |0 | 2431 Failed-AVP |0 |0 |0 |0 |0-1|0 |0 |0 | 2432 Failed-Command-Code |0 |0 |0 |0 |0-1|0 |0 |0 | 2433 Firmware-Revision |0-1|0 |0 |0 |0 |0 |0 |0 | 2434 Host-IP-Address |1+ |0 |0 |0 |0 |0 |0 |0 | 2435 Integrity-Check-Value |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1| 2436 Max-Time-Wait |0 |0 |0 |0 |0 |0 |0 |0 | 2437 Origin-FQDN |1 |1 |1 |1 |1 |1 |1 |1 | 2438 Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 | 2439 Proxy-State |0 |0 |0 |0 |0+ |0+ |0+ |0+ | 2440 Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0 | 2441 Result-Code |0 |0 |0 |1 |1 |0 |0 |1 | 2442 Route-Record |0 |0 |0 |0 |0+ |0+ |0+ |0+ | 2443 Session-Id |0 |0 |0 |0 |0-1|1 |1 |1 | 2444 Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 | 2445 Timestamp |0 |0 |0 |0 |0 |0 |0 |0 | 2446 User-Name |0 |0 |0 |0 |0 |1 |1 |1 | 2447 Vendor-Id |1 |0 |0 |0 |0 |0 |0 |0 | 2448 ------------------------------|---+---+---+---+---+---+---+---| 2450 15.0 IANA Considerations 2452 This document defines a number of assigned numbers to be maintained 2453 by the IANA. This section explains the criteria to be used by the 2454 IANA to assign additional numbers in each of these lists. The 2455 following subsections describe the assignment policy for the 2456 namespaces defined elsewhere in this document. 2458 15.1 AVP Attributes 2460 As defined in section 4.0, AVPs contain vendor ID, attribute and Data 2461 fields. For vendor ID value of 0, IANA will maintain a registry of 2462 assigned AVP codes and in some case also values. Attribute 0-254 are 2463 assigned from the RADIUS protocol [1], whose attributes are also 2464 maintained through IANA. AVP Codes 256-280 are assigned within this 2465 document. The remaining values are available for assignment through 2466 Designated Expert [12]. 2468 15.2 Command Code Values 2470 As defined in section 3.0, the Command Code field has an associated 2471 value maintained by IANA. Values 0-255 are reserved for backward 2472 RADIUS compatibility, and values 257, 259, 274, 275 and 276 are 2473 defined in this specification. The remaining values are available for 2474 assignment via Designated Expert [12]. 2476 15.3 Extension Identifier Values 2478 As defined in section 6.1.3, the Extension Identifier is used to 2479 identify a specific Diameter Extension. All values, other than zero 2480 (0) are available for assignment via Standards Action [12]. 2482 Note that the Diameter protocol is not inteded to be extended for any 2483 purpose. Any extensions added to the protocol MUST ensure that they 2484 fit within the existing framework, and that no changes to the base 2485 protocol are required. 2487 15.4 Result-Code AVP Values 2489 As defined in Section 10.2, the Result-Code AVP (AVP Code 268) 2490 defines the values 2001, 4001-4002 and 5001-5010. All remaining 2491 values are available for assignment via IETF Consensus [12]. 2493 15.5 Authentication-Transform-Id AVP Values 2495 Section 13.1.1.1 defines the Authentication-Transform-Id AVP (AVP 2496 Code 285) which is used to identify the authentication algorithm used 2497 to generate the contents of the Digest AVP. This document reserves 2498 the value 1. All remaining values are available for assignment via 2499 Designated Expert [12]. 2501 15.6 Encryption-Transform-Id AVP Values 2503 Section 13.1.2.1 defines the Encryption-Transform-Id AVP (AVP Code 2504 288) which is used to identify the encryption algorithm used to 2505 generate the contents of the Encrypted-Data AVP. This document 2506 reserves the value 1. All remaining values are available for 2507 assignment via Designated Expert [12]. 2509 15.7 Message Header Bits 2511 There are thirteen bits in the Flags field of the Diameter header. 2512 This document assigns bit 1 ('R'esponse), bit 2 ('I'nterrogation) and 2513 bit 3 ('E'xpected Reply). Bits 4 through 13 should only be assigned 2514 via a Standards Action [12]. 2516 15.8 AVP Header Bits 2518 There are 16 bits in the Flags field of the AVP Header, defined in 2519 section 4.0. This document assigns bit 1 ('M'andatory), bit 3 2520 ('V'endor Specific) and bit 5 ('P'rotected). The remaining bits 2521 should only be assigned via a Standards Action [12]. 2523 15.9 DSI-Event AVP Values 2525 As defined in Section 9.1.1, the DSI-Event AVP (AVP Code 297) defines 2526 the values 1001, 3001, 4001-4003 and 5001-5006. All remaining values 2527 are available for assignment via IETF Consensus [12]. 2529 16.0 Open Issues 2531 The following are the open issues that SHOULD be addressed in future 2532 versions of the Diameter protocol: 2534 - AVPs with time values are represented by Unsigned32 type data. 2535 This value is a timestamp consistent with NTP [18]. This field 2536 is expected to expire sometime in 2038. Future investigation 2537 SHOULD be done to determine if a 64 bit time format could be 2538 used. 2540 - The fact that the Sender's IP Address is used in the 2541 construction of the Session-Id means that the introduction of 2542 Network Address Translation MAY cause two hosts to represent the 2543 same Session Identifier. This area needs to be investigated 2544 further to be able to support Diameter hosts on a private 2545 network. 2547 17.0 Diameter protocol related configurable parameters 2548 This section contains the configurable parameters that are found 2549 throughout this document: 2551 Diameter Peer 2552 A Diameter entity MAY communicate with peers that are 2553 statically configured. A statically configured Diameter peer 2554 would require that either the IP address or the fully qualified 2555 domain name (FQDN) be supplied, which would then be used to 2556 resolve through DNS. 2558 Realm Routing Table 2559 A Diameter Proxy server routes messages based on the realm 2560 portion of a Network Access Identifier (NAI). The server MUST 2561 have a table of Realms Names, and the address of the peer to 2562 which the message must be forwarded to. The routing table MAY 2563 also include a "default route", which is typically used for all 2564 messages that cannot be locally processed. 2566 Maximum Age of an outstanding message 2567 Messages older than the maximum age SHOULD be rejected, as 2568 described in section 13.3. The recommended value is 4 seconds. 2570 RTT-Multiplier 2571 The Round Trip Time Multiplier is used to determine when a DWR 2572 message is to be sent to an inactive peer. The recommended 2573 valus is 4. 2575 Shared Secret 2576 The shared secret is a value that is known by two communicating 2577 peers, and is used to generate the Integrity-Check-Value and 2578 the Encryption-Payload AVP. There is no default. 2580 Watchdog Interval Period 2581 The Watchdog Interval Period is the frequency at which DWR 2582 messages are sent to inactive peers. The recommended value is 2583 30 seconds. 2585 18.0 Security Considerations 2587 The Diameter base protocol requires that two communicating peers 2588 exchange messages in a secure fashion. This document describes two 2589 security methods that can be used. The first requires no security at 2590 the application layer, but rather relies on an underlying security 2591 mechanism, such as IP Security. 2593 When IP Security is not available, or desirable, the Diameter 2594 protocol MAY use hop-by-hop security, which requires communicating 2595 peers to negotiate a symmetric key through some out of band 2596 mechanism. Hop-by-Hop security provides replay protection by 2597 requiring that the communicating peers share a time source, such as 2598 an NTP server. Information of a sensitive nature, which MUST NOT be 2599 seen by any intermediate Diameter node MUST NOT be encrypted using 2600 hop-by-hop encryption. 2602 When the Diameter protocol is used in an inter-domain network, strong 2603 application level security MAY be required, such as non-repudiation. 2604 When the communicating peers do require this level of security either 2605 for legal or business purposes, the extension defined in [11] MAY be 2606 used. This security model provides AVP-level authentication, and the 2607 encryption mechanism is designed such that only the target host has 2608 the keying information required to decrypt the information. 2610 19.0 References 2612 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997. 2614 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 2616 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 2618 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 2619 1992. 2621 [5] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 2622 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 2623 13-061466-1. 2625 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 2626 Authentication", RFC 2104, January 1997. 2628 [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 2629 Extension", draft-ietf-aaa-diameter-nasreq-01.txt, IETF work in 2630 progress, March 2001. 2632 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 2633 ary 1999. 2635 [9] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-ietf- 2636 aaa-diameter-framework-01.txt, IETF work in progress, March 2637 2001. 2639 [10] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2640 ietf-aaa-diameter-mobileip-01.txt, IETF work in progress, March 2641 2001. 2643 [11] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 2644 Extension", draft-calhoun-diameter-strong-crypto-06.txt (work in 2645 progress), February 2001. 2647 [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 2648 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2650 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2651 Levels", BCP 14, RFC 2119, March 1997. 2653 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 2654 Key Infrastructure Online Certificate Status Protocol (OCSP)", 2655 RFC 2560, June 1999. 2657 [15] Arkko, Calhoun, Patel, Zorn, "Diameter Accounting Extension", 2658 draft-ietf-aaa-diameter-accounting-01.txt, IETF work in pro- 2659 gress, March 2001. 2661 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2662 2373, July 1998. 2664 [17] ISI, "Internet Protocol", RFC 791, September 1981. 2666 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 2667 IPv6 and OSI, RFC 2030, October 1996. 2669 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 2670 tructure Certificate and CRL Profile", RFC 2459, January 1999. 2672 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 2673 RFC 2477, January 1999. 2675 [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2676 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2677 in progress, June 2000. 2679 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 2680 draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep- 2681 tember 2000. 2683 [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 2684 Authorization, and Accounting Requirements". RFC 2977. October 2685 2000. 2687 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2688 2279, January 1998. 2690 [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 2691 Haag, "Diameter Implementation Guidelines", draft-ietf-aaa- 2692 diameter-impl-guide-00.txt, IETF work in progress, June 2000. 2694 [26] R. Stewart et al., "Stream Control Transmission Protocol". RFC 2695 2960. October 2000. 2697 [27] Postel, J. "Transmission Control Protocol", RFC 793, January 2698 1981. 2700 [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location 2701 Protocol, Version 2", RFC 2165, June 1999. 2703 [29] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2704 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 2706 [30] Institute of Electrical and Electronics Engineers, "IEEE Stan- 2707 dard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 2708 754-1985, August 1985. 2710 [31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica- 2711 tions: ABNF", RFC 2234, November 1997. 2713 [32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Ser- 2714 vice: Schemes", RFC 2609, June 1999. 2716 [33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying 2717 the location of services (DNS SRV)", RFC 2782, February 2000. 2719 [34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, 2720 March 1999. 2722 [35] D. Eastlake, "DNS Security Operational Considerations", RFC 2723 2541, March 1999. 2725 [36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s 2726 )", RFC 2931, September 2000. 2728 [37] S. Kent, R. Atkinson, "Security Architecture for the Internet 2729 Protocol", RFC 2401, November 1998. 2731 [38] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 2732 Netscape Communications Corp., Nov 18, 1996. 2734 [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. 2735 677-680. 2737 20.0 Acknowledgements 2739 The authors would like to thank Nenad Trifunovic, Tony Johansson and 2740 Pankaj Patel for their participation in the Document Reading Party. 2741 Allison Mankin's assistance was invaluable in working out transport 2742 issues, and similarly with Steven Bellovin's help in the security 2743 area. 2745 The authors would also like to acknowledge the following people for 2746 their contribution in the development of the Diameter protocol: 2748 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2749 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 2750 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen Farrell, 2751 Sumit Vakil, John R. Vollbrecht, Jeff Weisberg, Jon Wood and Glen 2752 Zorn 2754 21.0 Authors' Addresses 2756 Questions about this memo can be directed to: 2758 Pat R. Calhoun 2759 Network and Security Research Center, Sun Laboratories 2760 Sun Microsystems, Inc. 2761 15 Network Circle 2762 Menlo Park, California, 94025 2763 USA 2765 Phone: +1 650-786-7733 2766 Fax: +1 650-786-6445 2767 E-mail: pcalhoun@eng.sun.com 2769 Allan C. Rubens 2770 Tut Systems, Inc. 2771 220 E. Huron, Suite 260 2772 Ann Arbor, MI 48104 2773 USA 2775 Phone: +1 734-995-1697 2776 E-Mail: arubens@tutsys.com 2778 Haseeb Akhtar 2779 Wireless Technology Labs 2780 Nortel Networks 2781 2221 Lakeside Blvd. 2783 Richardson, TX 75082-4399 2784 USA 2786 Phone: +1 972-684-8850 2787 E-Mail: haseeb@nortelnetworks.com 2789 Erik Guttman 2790 Solaris Advanced Development 2791 Sun Microsystems, Inc. 2792 Eichhoelzelstr. 7 2793 74915 Waibstadt 2794 Germany 2796 Phone: +49-7263-911-701 2797 E-mail: erik.guttman@germany.sun.com 2799 22.0 Full Copyright Statement 2801 Copyright (C) The Internet Society (2001). All Rights Reserved. 2803 This document and translations of it may be copied and furnished to 2804 others, and derivative works that comment on or otherwise explain it 2805 or assist in its implementation may be prepared, copied, published 2806 and distributed, in whole or in part, without restriction of any 2807 kind, provided that the above copyright notice and this paragraph are 2808 included on all such copies and derivative works. However, this docu- 2809 ment itself may not be modified in any way, such as by removing the 2810 copyright notice or references to the Internet Society or other 2811 Internet organizations, except as needed for the purpose of develop- 2812 ing Internet standards in which case the procedures for copyrights 2813 defined in the Internet Standards process must be followed, or as 2814 required to translate it into languages other than English. The lim- 2815 ited permissions granted above are perpetual and will not be revoked 2816 by the Internet Society or its successors or assigns. This document 2817 and the information contained herein is provided on an "AS IS" basis 2818 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2819 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2820 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2821 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2822 FITNESS FOR A PARTICULAR PURPOSE. 2824 23.0 Expiration Date 2826 This memo is filed as and expires in 2827 August 2001. 2829 Appendix A. Diameter Service Template 2831 The following service template describes the attributes used by Diam- 2832 eter servers to advertise themselves. This simplifies the process of 2833 selecting an appropriate server to communicate with. A Diameter 2834 client can request specific Diameter servers based on characteristics 2835 of the Diameter service desired (for example, an AAA server to use 2836 for accounting.) 2838 Name of submitter: "Erik Guttman" 2839 Language of service template: en 2841 Security Considerations: 2842 Diameter clients and servers use various cryptographic mechanisms 2843 to protect communication integrity, confidentiality as well as 2844 perform end-point authentication. It would thus be difficult if 2845 not impossible for an attacker to advertise itself using SLPv2 and 2846 pose as a legitimate Diameter peer without proper preconfigured 2847 secrets or cryptographic keys. Still, as Diameter services are 2848 vital for network operation it is important to use SLPv2 authenti- 2849 cation to prevent an attacker from modifying or eliminating ser- 2850 vice advertisements for legitimate Diameter servers. 2852 Template text: 2853 -------------------------template begins here----------------------- 2854 template-type=service:diameter 2856 template-version=0.0 2858 template-description= 2859 The Diameter protocol is defined by draft-ietf-aaa-diameter-00.txt 2861 template-url-syntax= 2862 url-path= ; The standard service URL syntax is used. 2863 ; For example: 'service:diameter://aaa.example.com:1812 2865 supported-extensions= string L M 2866 # This attribute lists the Diameter extensions supported by the 2867 # AAA implementation. The extensions currently defined are: 2868 # Extension Name Defined by 2869 # --------------- ----------------------------------- 2870 # NASREQ draft-ietf-aaa-diameter-nasreq-00.txt 2871 # MobileIP draft-ietf-aaa-diameter-mobileip-00.txt 2872 # Accounting draft-ietf-aaa-diameter-accounting-00.txt 2873 # Strong Security draft-calhoun-diameter-strong-crypto-05.txt 2874 # Resource Management draft-calhoun-diameter-res-mgmt-06.txt 2875 # 2876 # Notes: 2877 # . Diameter implementations support one or more extensions. 2878 # . Additional extensions may be defined in the future. 2879 # An updated service template will be created at that time. 2880 # 2881 NASREQ,MobileIP,Accounting,Strong Security,Resource Management 2883 supported-transports= string L M 2884 SCTP 2885 # This attribute lists the supported transports that the Diameter 2886 # implementation accepts. Note that a compliant Diameter 2887 # implementation MUST support SCTP, though it MAY support other 2888 # transports, too. 2889 SCTP,TCP 2891 -------------------------template ends here-----------------------