idnits 2.17.1 draft-calhoun-diameter-18.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 56 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 57 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 5 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 759 has weird spacing: '...th peer conne...' == Line 2481 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). == 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 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 (February 2001) is 8471 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 2237, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2239, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2242, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2290, 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') -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' == 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) == Outdated reference: A later version (-05) exists of draft-calhoun-diameter-impl-guide-04 -- 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) Summary: 26 errors (**), 0 flaws (~~), 16 warnings (==), 12 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 February 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 Header Format 54 2.2 Command Code Definitions 55 2.3 AVP Format 56 2.3.1 AVP Header 57 2.3.2 Optional Header Elements 58 2.3.3 AVP Data Formats 59 2.3.4 Grouped AVP Values 60 2.3.4.1 Example AVP with a Grouped Data type 61 2.3.5 Diameter Base Protocol AVPs 62 2.4 Mandatory AVPs 63 2.4.1 Host-Name AVP 64 2.5 State Machine 65 2.6 Device-Reboot-Ind (DRI) Command 66 2.6.1 Vendor-Id AVP 67 2.6.2 Firmware-Revision AVP 68 2.6.3 Extension-Id AVP 69 2.6.4 Host-IP-Address AVP 70 2.6 Diameter Server Discovery 71 3.0 "User" Sessions 72 3.1 State Machine 73 3.2 Session-Id AVP 74 3.3 Authorization-Lifetime AVP 75 3.4 Session-Timeout AVP 76 3.5 User-Name AVP 77 3.6 Session Termination 78 3.6.1 Session-Termination-Ind 79 3.6.2 Session-Termination-Request 80 3.6.3 Session-Termination-Answer 81 4.0 Reliable Transport 82 5.0 Error Reporting 83 5.1 Message-Reject-Ind (MRI) Command 84 5.1.1 Failed-AVP AVP 85 5.1.2 Failed-Command-Code 87 5.2 Result-Code AVP 88 5.2.1 Informational 89 5.2.2 Success 90 5.2.3 Redirect Notification 91 5.2.4 Transient Failures 92 5.2.5 Permanent Failures 93 5.2.6 Hop-by-Hop Failures 94 5.3 Error-Message AVP 95 5.4 Error-Reporting-NAI AVP 96 6.0 Message Routing 97 6.1 Realm-Based Message Routing 98 6.2 Behavior of Proxy and Redirect Servers 99 6.2.1 Proxy and Redirect Server handling of requests 100 6.3 Redirect Server 101 6.3.1 Redirect-Host AVP 102 6.3.2 Redirect-Host-Address AVP 103 6.3.3 Redirect-Host-Port AVP 104 6.4 Proxy Server 105 6.4.1 Proxying Requests 106 6.4.2 Proxying Responses 107 6.4.3 Route-Record AVP 108 6.4.4 Proxy-State AVP 109 6.4.5 Proxy-Address AVP 110 6.4.6 Proxy-Info AVP 111 6.4.7 Routing-Realm AVP 112 6.5 Applying Local Policies 113 6.6 Hiding Network Topology 114 6.7 Loop Detection 115 6.8 Finding a Target NAS within a Domain 116 6.8.1 Destination-NAI AVP 117 7.0 Diameter Message Security 118 7.1 Hop-by-Hop Security 119 7.1.1 Integrity-Check-Value AVP 120 7.1.1.1 Authentication-Transform-Id AVP 121 7.1.1.2 Digest AVP 122 7.1.2 Encrypted-Payload AVP 123 7.1.2.1 Encryption-Transform-Id AVP 124 7.1.2.1.1 MD5 Payload Hiding 125 7.1.2.2 Plaintext-Data-Length AVP 126 7.1.2.3 Encrypted-Data AVP 127 7.2 Nonce AVP 128 7.3 Timestamp AVP 129 7.4 Key-Id AVP 130 8.0 IANA Considerations 131 8.1 AVP Attributes 132 8.2 Command Code AVP Values 133 8.3 Extension Identifier Values 134 8.4 Result-Code AVP Values 135 8.5 Integrity-Check-Value AVP Transform Values 136 8.6 Encryption-Transform-Id AVP Values 137 8.7 Message Header Bits 138 8.8 AVP Header Bits 139 9.0 Open Issues 140 10.0 Diameter protocol related configurable parameters 141 11.0 Security Considerations 142 12.0 References 143 13.0 Acknowledgements 144 14.0 Authors' Addresses 145 15.0 Full Copyright Statement 146 Appendix A. Diameter Service Template 148 1.0 Introduction 150 The Diameter protocol allows peers to exchange a variety of messages. 151 The base protocol provides the following facilities: 153 - Delivery of AVPs (attribute value pairs) 154 - Capabilities negotiation, as required in [20] 155 - Error notification 156 - Extensibility, through addition of new commands and AVPs, as 157 required in [21] 159 All data delivered by the protocol is in the form of an AVP. Some of 160 these AVP values are used by the Diameter protocol itself, while 161 others deliver data associated with particular applications which 162 employ Diameter. AVPs may be added arbitrarily to Diameter messages, 163 so long as the required AVPs are included and AVPs which are 164 explicitly excluded are not included. AVPs are used by base Diameter 165 protocol to support the following required features: 167 - Transporting of user authentication information, for the 168 purposes of enabling the Diameter server to authenticate the 169 user. 170 - Transporting of service specific authorization information, 171 between client and servers, allowing the peers to decide whether 172 a user's access request should be granted. 173 - Exchanging resource usage information, which MAY be used for 174 accounting purposes, capacity planning, etc. 175 - Proxying and Re-directing of Diameter messages through a server 176 hierarchy. 177 - Providing application-level security, through the use of the 178 Integrity-Check-Value (ICV) and Encrypted-Payload AVPs. 180 The Diameter base protocol provides the minimum requirements needed 181 for an AAA transport protocol, as required by NASREQ [21], Mobile IP 182 [22, 23], and ROAMOPS [20]. The base protocol is not intended to be 183 used by itself, and must be used with an application-specific 184 extension, such as Mobile IP [10]. The Diameter protocol was heavily 185 inspired and builds upon the tradition of the RADIUS [1] protocol. 187 Any node can initiate a request. In that sense, Diameter is a peer to 188 peer protocol. In this document, a Diameter client is the device that 189 normally initiates a request for authentication and/or authorization 190 of a user. A Diameter server is the device that either forwards the 191 request to another Diameter server (known as a proxy), or one that 192 performs the actual authentication and/or authorization of the user 193 based on some profile. Given that the server MAY send unsolicited 194 messages to clients, it is possible for the server to initiate such 195 messages. An example of an unsolicited message would be for a request 196 that the client issue an accounting update. 198 Diameter services require sequenced in-order reliable delivery of 199 data, with congestion control (receiver windowing). Timely detection 200 of failed or unresponsive peers is also required, allowing for robust 201 operation. TCP is insufficient for this second requirement. 202 Diameter SHOULD be transported over SCTP [26]. 204 1.1 Requirements language 206 In this document, the key words "MAY", "MUST", "MUST NOT", 207 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 208 interpreted as described in [13]. 210 1.2 Terminology 212 Refer to [9] for terminology used in this document. 214 2.0 Protocol Overview 216 The base Diameter protocol is never used on its own. It is always 217 extended for a particular application. Four extensions to Diameter 218 are defined by companion documents: NASREQ [7], Mobile IP [10], 219 Accounting Extension [15], Strong Security [11]. These options are 220 introduced in this document but specified elsewhere. Additional 221 extensions to Diameter may be defined in the future (see Section 222 8.3). 224 The base Diameter protocol concerns itself with capabilities 225 negotiation, and how messages are sent and how peers may eventually 226 be abandoned. The base protocol also defines certain rules which 227 apply to all exchanges of messages between Diameter peers. It is 228 important to note that the base protocol provides optional 229 application-level security AVPs (Integrity-Check-Value) which MAY be 230 used in absence of an underlying security protocol (e.g. IP 231 Security). 233 Communication between Diameter peers begins with one peer sending a 234 message to another Diameter peer. The set of AVPs included in the 235 message is determined by a particular application of or extension to 236 Diameter. We will refer to this as the Diameter extension. One AVP 237 that is included to reference a user's session is the Session-Id. 239 The initial request for authentication and/or authorization of a user 240 would include the Session-Id. The Session-Id is then used in all 241 subsequent messages to identify the user's session (see section 3.0 242 for more information). The communicating party may accept the 243 request, or reject it by returning a response with Result-Code AVP 244 set to indicate an error occurred. The specific behavior of the 245 diameter server or client receiving a request depends on the Diameter 246 extension employed. 248 Session state (associated with a Session-Id) MUST be freed upon 249 receipt of the Session-Termination-Request, Session-Termination- 250 Answer, expiration of authorized service time in the Session-Timeout 251 AVP, and according to rules established in a particular 252 extension/application of Diameter. 254 Exchanges of messages are either request/reply oriented, or in some 255 special cases, do not require replies. All such messages that do not 256 require replies have names ending with '-Ind' (short for Indication). 258 The Diameter base protocol provides the Authorization-Lifetime AVP, 259 which MAY be used by extensions to specify the duration of a specific 260 authorized session. 262 2.1 Header Format 264 The base Diameter protocol is run over SCTP [26] port TBD (for 265 interoperability test purposes we will support 1812 until April 266 2001). Implementations MAY send packets from any source port, but 267 MUST be prepared to receive packets on port TBD. When a request is 268 received, in order to send a reply, the source and destination ports 269 in the reply are reversed. Note that the source and destination 270 addresses used in request and replies MAY be any of the peer's valid 271 IP addresses. 273 A given Diameter process SHOULD use the same port number to send all 274 messages to aid in identifying which process sent a given message. 275 More than one Diameter process MAY exist within a single host, so the 276 sender's port number is needed to discriminate them. 278 A summary of the Diameter data format is shown below. The fields are 279 transmitted in network byte order. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |r r r r r r r r r r E I R| Ver | Message Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Identifier | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Command-Code | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Vendor-ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | AVPs ... 293 +-+-+-+-+-+-+-+-+-+-+-+-+- 295 Flags 296 The Message Flags field is thirteen bits. The following bits are 297 assigned: 299 r(eserved) MUST be zero - this flag bit is reserved for 300 future use. 301 E(xpected Reply) - The message solicits a response. 302 I(nterrogation) - The message is a Query or a Reply. 303 R(esponse) - The message is a response to another message. 305 These flags are set depending on the command code used in a 306 Diameter message. This enables the type of message to be 307 interpreted, even if the specific command code is not recognized. 309 Command Type Flags Set 310 Indication - - - 311 Request E - - 312 Answer - - R 313 Query E I - 314 Reply - I R 316 A Diameter node MUST NOT set these flags in any other combination. 317 A Diameter node receiving a message in which these flags are not 318 set appropriately SHOULD NOT reject the message for this reason, 319 but MAY log the event for diagnosis. 321 Version 322 This Version field MUST be set to 1 to indicate Diameter Version 323 1. 325 Message Length 326 The Message Length field is two octets and indicates the length of 327 the Diameter message including the header fields. 329 Identifier 330 The Identifier field is four octets, and aids in matching requests 331 and replies. The sender MUST ensure that the identifier in a 332 request (*-Request or *-Query) or indication (*-Ind) message is 333 locally unique (to the sender) at any given time, and MAY attempt 334 to ensure that the number is unique across reboots. The sender of 335 a response (*-Answer or *-Response) MUST ensure that the 336 Identifier field contains the same Identifier value that was found 337 in the corresponding request. For The identifier is normally a 338 monotonically increasing number, whose start value was randomly 339 generated. Diameter servers should consider a message to be unique 340 by examining the source address, source port, Session-Id and 341 Identifier field of the message. 343 Command-Code 344 The Command-Code field is four octets, and is used in order to 345 communicate the command associated with the message. The 32-bit 346 address space is managed by IANA (see section 8.2). The following 347 Command Codes are currently defined in the Diameter base protocol: 349 Command-Name Abbrev. Code Reference 350 -------------------------------------------------------- 351 Device-Reboot-Ind DRI 257 2.6 352 Message-Reject-Ind MRI 259 5.1 353 Session-Termination-Ind STI 274 3.6.1 354 Session-Termination- STR 275 3.6.2 355 Request 356 Session-Termination- STA 276 3.6.3 357 Answer 359 Vendor-ID 360 In the event that the Command-Code field contains a vendor 361 specific command, the four octet Vendor-ID field contains the IANA 362 assigned "SMI Network Management Private Enterprise Codes" [2] 363 value. If the Command-Code field contains an IETF standard 364 Command, the Vendor-ID field MUST be set to zero (0). 366 AVPs 367 AVPs are a method of encapsulating information relevant to the 368 Diameter message. See section 2.3 for more information on AVPs. 370 2.2 Command Code Message Definitions 372 All Diameter Command Code MUST include a corresponding ABNF 373 specification, which is used to define the AVPs that MUST, MAY and 374 MUST NOT be present. The following format is used in the definition: 376 command-def = command-name "::=" diameter-message 378 diameter-name = ALPHA *(ALPHA / DIGIT / "-") 380 command-name = diameter-name 381 ; The command-name has to be Command name, 382 ; defined in the base or extended Diameter 383 ; specifications. 385 diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] 387 header = "" 389 fixed = [qual] "<" avp-spec ">" 391 required = [qual] "{" avp-spec "}" 393 optional = [qual] "[" avp-name "]" 394 ; The avp-name in the 'optional' rule cannot 395 ; evaluate to any AVP Name which is included 396 ; in a fixed or required rule. 398 qual = [min] "*" [max] 399 ; See ABNF conventions, RFC 2234 section 3.6. 400 ; The absence of any qualifiers implies that one 401 ; and only one such AVP MUST be present. 402 ; 403 ; NOTE: "[" and "]" have a different meaning 404 ; than in ABNF (see the optional rule, above). 405 ; These braces cannot be used to express an 406 ; optional fixed rules (such as an optional 407 ; ICV at the end.) To do this, the convention 408 ; is '0*1fixed'. 410 min = 1*DIGIT 411 ; The minimum number of times the element may 412 ; be present. 414 max = 1*DIGIT 415 ; The maximum number of times the element may 416 ; be present. 418 avp-spec = diameter-name 419 ; The avp-spec has to be an AVP Name, defined 420 ; in the base or extended Diameter 421 ; specifications. 423 avp-name = avp-spec | "AVP" 424 ; The string "AVP" stands for *any* arbitrary 425 ; AVP Name, which does not conflict with the 426 ; required or fixed position AVPs defined in 427 ; the command code definition. 429 The following is a definition of a fictitious command code: 431 Example-Command ::= < Diameter-Header: 9999999 > 432 { User-Name } 433 * { Host-Name } 434 * [ AVP ] 435 0*1< Integrity-Check-Vector > 437 2.3 AVP Format 439 Diameter AVPs carry specific authentication, accounting and 440 authorization information, security information as well as 441 configuration details for the request and reply. 443 Some AVPs MAY be listed more than once. The effect of such an AVP is 444 specific, and is specified in each case by the AVP description. 446 Each AVP of type OctetString MUST be padded to align on a 32 bit 447 boundary, while other AVP types align naturally. NULL bytes are added 448 to the end of the AVP Data field till a word boundary is reached. The 449 length of the padding is not reflected in the AVP Length field. 451 2.3.1 AVP Header 453 The fields in the AVP header MUST be sent in network byte order. The 454 format of the header is: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | AVP Code | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | AVP Length | Reserved |P|R|V|R|M| 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Vendor-ID (opt) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Data ... 466 +-+-+-+-+-+-+-+-+ 468 AVP Code 469 The AVP Code identifies the attribute uniquely. The first 256 AVP 470 numbers are reserved for backward compatibility with RADIUS and 471 are to be interpreted as per NASREQ [7]. AVP numbers 256 and above 472 are used for Diameter, which are allocated by IANA (see section 473 8.1). 475 AVP Length 476 The AVP Length field is two octets, and indicates the length of 477 this AVP including the AVP Code, AVP Length, AVP Flags, Reserved, 478 the Vendor-ID field (if present) and the AVP data. If a message is 479 received with an invalid attribute length, the message SHOULD be 480 rejected. 482 AVP Flags 483 The AVP Flags field informs the Diameter host how each attribute 484 must be handled. Note that subsequent Diameter extensions MAY 485 define bits to be used within the AVP Header, and an unrecognized 486 bit should be considered an error. The 'R' and the reserved bits 487 are unused and should be set to 0 and ignored on receipt, while 488 the 'P' bit is defined in [11]. 490 The 'M' Bit, known as the Mandatory bit, indicates whether support 491 of the AVP is required. If an AVP is received by a Home server or 492 NAS with the 'M' bit enabled and the receiver does not support 493 the AVP, the message MUST be rejected. If such an AVP is received 494 by a Proxy or Redirect Server, the message MUST be forwarded to 495 its logical destination, and MUST NOT be rejected. It is the 496 responsibility of the originator of a message that is rejected for 497 this purpose to correct the error. AVPs without the 'M' bit 498 enabled are informational only and a receiver that receives a 499 message with such an AVP that is not supported MAY simply ignore 500 the AVP. 502 The 'V' bit, known as the Vendor-Specific bit, indicates whether 503 the optional Vendor-ID field is present in the AVP header. When 504 set the AVP Code belongs to the specific vendor code address 505 space. 507 Unless otherwise noted, AVPs will have the following default AVP 508 Flags field settings: 509 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 511 2.3.2 Optional Header Elements 513 The AVP Header contains one optional field. This field is only 514 present if the respective bit-flag is enabled. 516 Vendor-ID 517 The Vendor-ID field is present if the 'V' bit is set in the AVP 518 Flags field. The optional four octet Vendor-ID field contains the 519 IANA assigned "SMI Network Management Private Enterprise Codes" 520 [2] value, encoded in network byte order. Any vendor wishing to 521 implement a Diameter extension MUST use their own Vendor-ID along 522 with their privately managed AVP address space, guaranteeing that 523 they will not collide with any other vendor's extensions, nor with 524 future IETF extensions. 526 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 527 values, as managed by the IANA. Since the absence of the vendor ID 528 field implies that the AVP in question is not vendor specific, 529 implementations SHOULD not use the zero (0) vendor ID. 531 2.3.3 AVP Data Formats 533 The Data field is zero or more octets and contains information 534 specific to the Attribute. The format and length of the Data field is 535 determined by the AVP Code and AVP Length fields. The format of the 536 Data field MAY be one of the following data types. 538 The interpretation of the values depends on the specification of the 539 AVP. For example, an OctetString may be used to transmit human 540 readable string data and Unsigned32 may be used to transmit a time 541 value. Conventions for these common interpretations are described 542 below. 544 OctetString 545 The data contains arbitrary data of variable length. Unless 546 otherwise noted, the AVP Length field MUST be set to at least 9 547 (13 if the 'V' bit is enabled). Data used to transmit (human 548 readable) character string data uses the UTF-8 [24] character 549 set and is NOT NULL-terminated. The minimum Length field MUST 550 be 9, but can be set to any value up to 65527 bytes. AVP Values 551 of this type that do not align on a 32-bit boundary MUST adding 552 necessary padding. 554 Address 555 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 556 significant octet first. The format of the address (IPv4 or 557 IPv6) is determined by the length. If the attribute value is an 558 IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is 559 enabled), otherwise the AVP Length field MUST be set to 24 (28 560 if the 'V' bit is enabled) for IPv6 addresses. 562 Integer32 563 32 bit signed value, in network byte order. The AVP Length 564 field MUST be set to 12 (16 if the 'V' bit is enabled). 566 Integer64 567 64 bit signed value, in network byte order. The AVP Length 568 field MUST be set to 16 (20 if the 'V' bit is enabled). 570 Unsigned32 571 32 bit unsigned value, in network byte order. The AVP Length 572 field MUST be set to 12 (16 if the 'V' bit is enabled). 573 Unsigned32 values used to transmit time data contains the four 574 most significant octets returned from NTP [18], in network byte 575 order. 577 Unsigned64 578 32 bit unsigned value, in network byte order. The AVP Length 579 field MUST be set to 16 (20 if the 'V' bit is enabled). 581 Float32 582 This represents floating point values of single precision as 583 described by [30]. The 32 bit value is transmitted in network 584 byte order. The AVP Length field MUST be set to 12 (16 if the 585 'V' bit is enabled). 587 Float64 588 This represents floating point values of double precision as 589 described by [30]. The 64 bit value is transmitted in network 590 byte order. The AVP Length field MUST be set to 16 (20 if the 591 'V' bit is enabled). 593 Float128 594 This represents floating point values of quadruple precision as 595 described by [30]. The 128 bit value is transmitted in network 596 byte order. The AVP Length field MUST be set to 24 (28 if the 597 'V' bit is enabled). 599 Grouped 600 The Data field is specified as a sequence of AVPs. Each of 601 these AVPs follows - in the order in which they are specified - 602 including their headers and padding. The AVP Length field is 603 set to 8 (12 if the 'V' bit is enabled) plus the total length 604 of all included AVPs, including their headers. 606 2.3.4 Grouped AVP Values 608 The Diameter protocol allows AVP values of type 'Grouped.' This 609 implies that the Data field is actually a well defined sequence of 610 AVPs. It is possible to include an AVP with a Grouped type within a 611 Grouped type, that is, to nest them. AVPs within an AVP of type 612 Grouped have the same padding requirements as non-Grouped AVPs, as 613 defined in section 2.3. 615 Grouped type AVP specifications include an ABNF grammar [31] 616 specifying the required sequence of AVPs. Grouped AVP values MUST be 617 in the specified sequence and MUST NOT include other AVP values 618 besides those specified by the Grouped AVP grammar. 620 2.3.4.1 Example AVP with a Grouped Data type 622 The Example AVP (AVP Code 999999) is of type Grouped and is used to 623 clarify how Grouped AVP values work. The Grouped Data field has the 624 following ABNF grammar: 626 example-avp-val = Host-Name Host-IP-Address 627 Host-Name = ; See Section 2.4.1 628 Host-IP-Address = ; See Section 2.6.4 630 An Example AVP with the Grouped Data Host-Name = "example.com", 631 Host-IP-Address = "10.10.10.10" would be encoded as follows: 633 0 1 2 3 4 5 6 7 634 +-------+-------+-------+-------+-------+-------+-------+-------+ 635 0 | Example AVP Header (AVP Code = 999999), Length = 40 | 636 +-------+-------+-------+-------+-------+-------+-------+-------+ 637 8 | Host-Name AVP Header (AVP Code = 265), Length = 19 | 638 +-------+-------+-------+-------+-------+-------+-------+-------+ 639 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 640 +-------+-------+-------+-------+-------+-------+-------+-------+ 641 24 | 'c' | 'o' | 'm' |Padding| Host-IP-Addr AVP Header | 642 +-------+-------+-------+-------+-------+-------+-------+-------+ 643 32 | (AVP Code = 257), Length = 12 | 0x0a | 0x0a | 0x0a | 0x0a | 644 +-------+-------+-------+-------+-------+-------+-------+-------+ 646 2.3.5 Diameter Base Protocol AVPs 648 The following table describes the Diameter AVPs defined in the base 649 protocol, their AVP Code values, types, possible flag values and 650 whether the AVP MAY be encrypted. 652 +---------------------+ 653 | AVP Flag rules | 654 |----+-----+----+-----|----+ 655 AVP Section | | |SHLD| MUST|MAY | 656 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 657 -----------------------------------------|----+-----+----+-----|----| 658 Authentication- 285 7.1.1.1 Unsigned32 | | | | | N | 659 Transform-Id | | | | | | 660 Authorization- 291 3.3 Unsigned32 | | | | | N | 661 Lifetime | | | | | | 662 Destination-NAI 293 6.8 OctetString| | | | | Y | 663 Digest 287 7.1.1.2 OctetString| | | | | N | 664 Encrypted-Data 290 7.1.2.3 OctetString| | | | | N | 665 Encrypted- 260 7.1.2 Grouped | M | | | | N | 666 Payload | | | | | | 667 Encryption- 288 7.1.2.1 Unsigned32 | | | | | N | 668 Transform-Id | | | | | | 669 Error-Message 281 5.3 OctetString| | | | | N | 670 Error-Reporting- 294 5.3 OctetString| | | | | Y | 671 NAI | | | | | | 672 Extension-Id 258 2.6.3 Integer32 | M | | | | Y | 673 Failed-AVP 279 5.1.1 OctetString| | | | | Y | 674 Failed-Command- 270 5.1.2 Unsigned32 | | | | | Y | 675 Code | | | | | | 676 Firmware 267 2.6.2 Unsigned32 | | | | V,M | Y | 677 -Revision | | | | | | 678 Host-IP-Address 257 2.6.4 Address | M | | | V | N | 679 Host-Name 264 2.4.1 OctetString| M | | | V | N | 680 Integrity-Check 259 7.1.1 Grouped | M | | | | N | 681 -Value | | | | | | 682 Key-Id 286 7.4 Unsigned32 | | | | | N | 683 Nonce 261 7.2 OctetString| | | | | N | 684 Plaintext-Data- 289 7.1.2.2 Unsigned32 | | | | | N | 685 Length | | | | | | 686 Proxy-Address 280 6.4.5 Address | M | | | V | N | 687 Proxy-Info 284 6.4.6 OctetString| M | | | V | N | 688 Proxy-State 33 6.4.4 Grouped | M | | | V | N | 689 Redirect-Host 292 6.3.1 Grouped | | | | | Y | 690 Redirect-Host 278 6.3.2 Address | | | | | Y | 691 Address | | | | | | 692 Redirect-Host- 277 6.3.3 Unsigned32 | | | | | Y | 693 Port | | | | | | 694 Result-Code 268 5.2 Unsigned32 | M | | | | N | 695 Route-Record 282 6.4.3 OctetString| M | | | V | N | 696 Routing-Realm 283 6.4.7 OctetString| M | | | V | N | 697 Session-Id 263 3.2 OctetString| | | | | Y | 698 Session-Timeout 27 3.6 Unsigned32 | | | | | Y | 699 +---------------------+ 700 | AVP Flag rules | 701 |----+-----+----+-----|----+ 702 AVP Section | | |SHLD| MUST|MAY | 703 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 704 -----------------------------------------|----+-----+----+-----|----| 705 Timestamp 262 7.3 Unsigned32 | | | | | N | 706 User-Name 1 3.5 OctetString| | | | | Y | 707 Vendor-Id 266 2.6.1 Unsigned32 | | | | V,M | Y | 708 -----------------------------------------|----+-----+----+-----|----| 710 2.4 Mandatory AVPs 712 This section defines the Diameter AVPs that MUST be present in all 713 Diameter messages. 715 2.4.1 Host-Name AVP 717 The Host-Name AVP (AVP Code 264) [1] is of type OctetString. This AVP 718 identifies the endpoint which originated the Diameter message, i.e. the 719 NAS, home server, or broker. Proxy servers do not modify this AVP. 720 All Diameter messages MUST include the Host-Name AVP, which contains the 721 host name of the originator of the Diameter message and MUST follow 722 the NAI [8] naming conventions. 724 Note that the Host-Name AVP may resolve to more than one address 725 as the Diameter peer may support more than one address. 727 2.5 State Machine 729 This section contains a finite state machine, that MUST be observed 730 by all Diameter implementations. Each Diameter node MUST follow the 731 state machine described below when communicating with each peer. 733 State Event Action New State 734 ----- ----- ------ --------- 735 Initial Local request to establish SCTP Idle 736 communication with a Diameter Connect 737 peer with which there is no 738 existing transport level 739 connection established. 741 Initial Receive transport level Send DRI Wait-DRI 742 connection request from a 743 Diameter peer. 745 Idle Connection Established Send DRI Wait-DRI 747 Idle Receive DRI Send DRI Open 749 Wait-DRI Receive DRI None Open 751 Open Receive other messages Process Open 752 Message 754 Open Receive DRI Cleanup Closed 756 Open Transport level failure Cleanup Closed 758 Closed Diameter Entity shutdown Close Initial 759 or close connection with peer connection 761 The Initial and Idle states MAY be merged if the local SCTP 762 implementation is able to implement the piggyback of data during the 763 connection phase. 765 When the Cleanup action is invoked, the Diameter node SHOULD attempt 766 to forward all pending requests and replies, which haven't been 767 acknowledged, to an alternate server (when possible). If the final 768 destination for a specific message is the host that is no longer 769 accessible, the message in question SHOULD be responded with the 770 Result-Code AVP set to Diameter_UNABLE_TO_DELIVER. 772 2.6 Device-Reboot-Ind (DRI) Command 774 A Diameter device sends the Device-Reboot-Ind message, by setting the 775 Command-Code field with a value of 257, to inform a peer that a 776 reboot has just occurred. Since SCTP [26] allows for connections to 777 span multiple interfaces, hence multiple IP addresses, the Device- 778 Reboot-Ind message MUST contain one Host-IP-Address AVP for each 779 potential IP address that MAY be locally used when transmitting 780 Diameter messages. 782 The DRI message is also used for capabilities negotiation, such as 783 the supported protocol version number, and the locally supported 784 extensions. The receiver uses the extensions advertised in order to 785 determine whether it SHOULD send certain application-specific 786 Diameter commands. A Diameter node MUST retain the supported 787 extensions in order to ensure that unrecognized commands and/or AVPs 788 are not sent to a peer. Note that in a proxy environment, it is still 789 possible that a downstream proxy has no available peer that have 790 advertised the extension that corresponds to the Command-Code, and 791 therefore the request cannot be forwarded any further. The Diameter 792 base protocol provides this error reporting, via the Result-Code AVP. 794 Once the transport layer connection has been established, a Diameter 795 entity MUST issue a DRI message, regardless of whether the peer was 796 statically configured, or dynamically discovered (see Section 2.6 for 797 more information). 799 If a peer is no longer reachable, a Diameter device SHOULD 800 periodically attempt to establish a transport level connection with 801 the peer and send a DRI message. This message does not require a 802 reply. If a Diameter node receives a DRI message that results in an 803 error, a Message-Reject-Ind message MUST be returned. 805 Message Format 807 ::= < Diameter Header: 257 > 808 { Host-Name } 809 1* { Host-IP-Address } 810 { Vendor-Id } 811 * { Extension-Id } 812 [ Firmware-Revision ] 813 * [ AVP ] 814 0*1< Integrity-Check-Value > 816 2.6.1 Vendor-Id AVP 818 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains 819 the IANA assigned "SMI Network Management Private Enterprise Codes" 820 [2] value of the Diameter device. 822 This MAY be used in order to know which vendor specific attributes 823 may be sent to the peer. It is also envisioned that the combination 824 of the Vendor-Name and the Firmware-Revision (section 2.6.2) AVPs MAY 825 provide very useful debugging information. 827 2.6.2 Firmware-Revision AVP 829 The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is 830 used to inform a Diameter peer of the firmware revision of the 831 issuing device. 833 For devices that do not have a firmware revision (general purpose 834 computers running Diameter software modules, for instance), the 835 revision of the Diameter software module may be reported instead. 837 2.6.3 Extension-Id AVP 839 The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used 840 in order to identify a specific Diameter extension. This AVP is used 841 in the Device-Reboot-Ind message in order to inform the peer what 842 extensions are locally supported. The Extension-Id MUST also be 843 present in all messages that are defined in a separate Diameter 844 specification and have an Extension ID assigned. 846 Each Diameter extension draft MUST have an IANA assigned extension 847 Identifier (see section 8.3). The base protocol does not require an 848 Extension-Id since its support is mandatory. 850 There MAY be more than one Extension-Id AVP within a Diameter 851 Device-Reboot-Ind message. The following values are recognized: 853 NASREQ 1 [7] 854 Strong Security 2 [11] 855 Resource Management 3 [29] 856 Mobile-IP 4 [10] 857 Accounting 5 [15] 859 Furthermore, servers acting as Redirect or Proxy servers (see Section 860 6.0) MAY wish to advertise support for ALL possible extensions. Such 861 servers are then responsible for finding a downstream server that 862 supports the extension of a particular message. This is done by 863 including the Extension-Id AVP with a value of zero (0). 865 2.6.4 Host-IP-Address AVP 867 The Host-IP-Address AVP (AVP Code 257) [1] is of type Address and is 868 used to inform a Diameter peer of the sender's IP address. All 869 source addresses that a Diameter node expects to use with SCTP [26] 870 MUST be advertised in the Device-Reboot-Ind message by including a 871 Host-IP-Address AVP for each address. This AVP MUST ONLY be used in 872 the Device-Reboot-Ind message. 874 2.6 Diameter Server Discovery 876 Allowing for dynamic Diameter server discovery will make it possible 877 for simpler and more robust deployment of AAA services. In order to 878 promote interoperable implementations of Diameter server discovery, 879 the following mechanisms are described. These are based on existing 880 IETF standards. 882 There are two cases where Diameter server discovery may be performed. 884 The first is when a Diameter client needs to discover a first-hop 885 Diameter server. The second case is when a Diameter server needs to 886 discover another server - for further handling of a Diameter 887 operation. In both cases, the following 'search order' is 888 recommended: 890 1. The Diameter implementation consults its list of static 891 (manual) configured Diameter server locations. These will be 892 used if they exist and respond. 894 2. The Diameter implementation uses SLPv2 [28] to discover 895 Diameter services. The Diameter service template [32] is 896 included in Appendix A. It is recommended that SLPv2 security 897 be deployed (this requires distributing keys to SLPv2 agents.) 898 This is discussed further in Appendix A. 900 SLPv2 will allow Diameter implementations to discover the 901 location of Diameter servers in the local site, as well as 902 their characteristics. Diameter servers with specific 903 capabilities (say support for the Accounting extension) can be 904 requested, and only those will be discovered. 906 3. The Diameter implementation uses DNS to request the SRV RR [33] 907 for the '_diameter._sctp' server in a particular domain. The 908 Diameter implementation has to know in advance which domain to 909 look for an Diameter server in. This could be deduced, for 910 example, from the 'realm' in a NAI that an Diameter 911 implementation needed to perform an Diameter operation on. 913 Diameter allows AAA peers to protect the integrity and privacy 914 of communication as well as to perform end-point 915 authentication. Still, it is prudent to employ DNS Security as 916 a precaution when using DNS SRV RRs to look up the location of 917 a Diameter server. [34, 35, 36] 919 3.0 "User" Sessions 921 When a user requests access to the network, a Diameter client issues 922 an authentication and authorization request to its local server. The 923 request contains a Session-Id AVP, which is used in subsequent 924 messages (e.g. subsequent authorization, accounting, etc) relating to 925 the user's session. The Session-Id AVP is a means for the client and 926 servers to correlate a Diameter message with a user session. 928 When a Diameter server authorizes a user to use network resources, it 929 SHOULD add the Authorization-Lifetime AVP to the response. The 930 Authorization-Lifetime AVP defines the maximum amount of time a user 931 MAY make use of the resources before another authorization request is 932 to be transmitted to the server. If the server does not receive 933 another authorization request before the timeout occurs, it SHOULD 934 release any state information related to the user's session. Note 935 that the Authorization-Lifetime AVP implies how long the Diameter 936 server is willing to pay for the services rendered, therefore a 937 Diameter client SHOULD NOT expect payment for services rendered past 938 the session expiration time. 940 The base protocol does not include any authorization request 941 messages, since these are largely application-specific and are 942 defined in a Diameter protocol extension document. However, the base 943 protocol does define a set of messages that are used to terminate 944 user sessions. These are used to allow servers that maintain state 945 information to free resources. 947 3.1 State Machine 949 This section contains a finite state machine, representing the life 950 cycle of Diameter sessions, and MUST be observed by all Diameter 951 implementations. The term Service-Specific below refers to a message 952 defined in a Diameter extension (e.g. Mobile IP, NASREQ). 954 State Event Action New State 955 ----- ----- ------ --------- 956 Idle Client or Device Requests send serv. Pending 957 access specific 958 auth req 960 Idle Service-Specific authorization send serv. Open 961 request received, and specific 962 successfully processed response 964 Pending Successful Service-Specific Grant Open 965 Authorization response Access 966 received 968 Open Authorization-Lifetime expires send serv. Open 969 specific 970 auth req 972 Open Successful Service-Specific Extend Open 973 Authorization response Access 974 received 976 Open Failed Service-Specific Discon. Closed 977 Authorization response user/device 978 received. 980 Open Session-Timeout Expires on send STR Discon 981 NAS 983 Open STI Received send STR Discon 985 Open Session-Timeout Expires on send STI Discon 986 home AAA server 988 Discon STI Received ignore Discon 990 Discon STR Received Discon. Closed 991 user/device 993 Discon STA Received Discon. Closed 994 user/device 996 Closed Transition to state Cleanup 998 When the Cleanup action is invoked, the Diameter node MAY attempt to 999 release all resources for the particular session. Any event not 1000 listed above MUST be considered as an error condition, and a 1001 response, if applicable, MUST be returned to the originator of the 1002 message. 1004 3.2 Session-Id AVP 1006 The Session-Id AVP (AVP Code 263) is of type OctetString and is used 1007 to identify a specific session (see section 3.0). The Session-Id data 1008 uses the UTF-8 [24] character set. All messages pertaining to a 1009 specific session MUST include only one Session-Id AVP and the same 1010 value MUST be used throughout the life of a session. When present, 1011 the Session-Id SHOULD appear immediately following the Diameter 1012 Header (see section 2.1). 1014 For messages that do not pertain to a specific session, multiple 1015 Session-Id AVPs MAY be present as long as they are encapsulated 1016 within an AVP of type Grouped. 1018 The Session-Id MUST be globally unique at any given time since it is 1019 used by the server to identify the session (or flow). The format of 1020 the session identifier SHOULD be as follows: 1022 1024 The monotonically increasing 32 bit value SHOULD NOT start at zero 1025 upon reboot, but rather start at a random value. This will minimize 1026 the possibility of overlapping Session-Ids after a reboot. 1027 Alternatively, an implementation MAY keep track of the increasing 1028 value in non-volatile memory. The optional value is implementation 1029 specific but may include a modem's device Id, a layer 2 address, 1030 timestamp, etc. 1032 The session Id is created by the Diameter device initiating the 1033 session, which in most cases is done by the client. Note that a 1034 Session-Id MAY be used by more than one extension (e.g. 1035 authentication for a specific service and accounting, both of which 1036 have separate extensions). 1038 3.3 Authorization-Lifetime AVP 1040 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 1041 and contains the maximum number of seconds of service to be provided 1042 to the user before the user is to be re-authenticated and/or re- 1043 authorized. Great care should be taken when the Authorization- 1044 Lifetime value is determined, since a low value could create 1045 significant Diameter traffic, which could congest both the network 1046 and the servers. 1048 This AVP MAY be provided by the client as a hint of the maximum 1049 duration that it is willing to accept. However, the server DOES NOT 1050 have to observe the hint, and MAY return a value that is smaller than 1051 the hint. A value of zero means that no re-authorization is required. 1053 3.4 Session-Timeout AVP 1055 The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and 1056 contains the maximum number of seconds of service to be provided to 1057 the user before termination of the session. A value of zero means 1058 that this session has an unlimited number of seconds before 1059 termination. 1061 This AVP MAY be provided by the client as a hint of the maximum 1062 duration that it is willing to accept. However, the server DOES NOT 1063 have to observe the hint, and MAY return a value that is smaller than 1064 the hint. 1066 3.5 User-Name AVP 1068 The User-Name AVP (AVP Code 1) [1] is of type OctetString, which 1069 contains the User-Name. The value is represented as a UTF-8 1070 character encoded string in a format consistent with the NAI 1071 specification [8]. 1073 3.6 Session Termination 1075 The Diameter Base Protocol provides a set of messages that MAY be 1076 used by any peer to explicitly request that a previously 1077 authenticated and/or authorized session be terminated. Since the 1078 Session-Id is typically tied to a particular service (i.e. Mobile IP, 1079 NASREQ, etc), the session termination messages are used to request 1080 that the service tied to the Session Id be terminated. 1082 3.6.1 Session-Termination-Ind 1084 The Session-Termination-Ind (STI), indicated by the Command-Code set 1085 to 274, MAY be sent by any Diameter entity to the access device to 1086 request that a particular session be terminated. This message MAY be 1087 used when a server detects that a session MUST be terminated, which 1088 is typically done as a policy decision (e.g. local resources have 1089 been expended, etc). The Destination-NAI AVP MUST be present, and 1090 contain the NAI of the access device that initiated the session (see 1091 section 3.0). 1093 Upon receipt of the STI message, the access device SHOULD issue a 1094 Session-Terminate-Request message. 1096 Message Format 1098 ::= < Diameter Header: 274 > 1099 { Session-Id } 1100 { Host-Name } 1101 { User-Name } 1102 { Destination-NAI } 1103 * [ AVP ] 1104 * [ Proxy-State ] 1105 * [ Route-Record ] 1106 * [ Routing-Realm ] 1107 0*1< Integrity-Check-Value > 1109 3.6.2 Session-Termination-Request 1111 The Session-Termination-Request (STR), indicated by the Command-Code 1112 set to 275, is sent by the access device to inform the Home AAA that 1113 an authenticated and/or authorized session is being terminated. 1115 Upon receipt of the STR, the Home Diameter Server SHOULD release all 1116 resources for the session indicated by the Session-Id AVP. Any 1117 intermediate server in the Proxy-Chain MAY also release any 1118 resources, if necessary. 1120 Message Format 1122 ::= < Diameter Header: 275 > 1123 { Session-Id } 1124 { Host-Name } 1125 { User-Name } 1126 * [ AVP ] 1127 * [ Proxy-State ] 1128 * [ Route-Record ] 1129 * [ Routing-Realm ] 1130 0*1< Integrity-Check-Value > 1132 3.6.3 Session-Termination-Answer 1134 The Session-Termination-Answer (STA), indicated by the Command-Code 1135 set to 276, is sent by the Home Diameter Server to acknowledge that 1136 the session has been terminated. The Result-Code AVP MUST be present, 1137 and MAY contain an indication that an error occurred while servicing 1138 the STR. 1140 Message Format 1142 ::= < Diameter Header: 276 > 1143 { Session-Id } 1144 { Result-Code } 1145 { Host-Name } 1146 { User-Name } 1147 * [ AVP ] 1148 * [ Proxy-State ] 1149 * [ Route-Record ] 1150 * [ Routing-Realm ] 1151 0*1< Integrity-Check-Value > 1153 4.0 Reliable Transport 1155 In order to provide rapid discovery of the failure of a communicating 1156 peer, aggressive retransmission and rapid transactions, Diameter 1157 peers MUST be able to send and receive messages over SCTP [26]. A 1158 Diameter peer MAY use TCP [27], as TCP does provide reliable 1159 transport, though it does not have the properties listed above. 1161 5.0 Error Reporting 1163 There are five different types of errors within Diameter. The first 1164 being where a Diameter message is poorly formatted and 1165 unrecognizable, indicated below by "Bad Message". This error 1166 condition applies if a received message creates a fatal error (e.g. 1167 fails transport level authentication, cannot be parsed, etc). 1169 The second case involves receiving a Command-Code that is not 1170 supported, which is shown below by "Unknown Command". The third case 1171 is where an AVP is received, marked mandatory and is unknown by the 1172 receiver, which is labeled below as "Unknown AVP". 1174 This fourth case involves receiving a message with a known AVP, yet 1175 the value is either unknown or illegal, which is shown below as "Bad 1176 AVP Value". The last case occurs when an error occurs while 1177 processing a specific extension command, which is not related to the 1178 message format and is labeled "Extension Error" below. 1180 Error Type Ignore Message Send Extension 1181 Message-Reject-Ind Response + 1182 Result-Code 1183 Bad Message X 1184 Unknown Command X 1185 Unknown AVP X 1186 Bad AVP Value X 1187 Extension Error X 1189 "Ignore Message" indicates that the message is simply dropped. The 1190 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 1191 be sent to the peer as described in the appropriate section. The 1192 "Extension Response + Result-Code" error has an extension-specific 1193 command code, and indicates that the appropriate Response to the 1194 message MUST be sent with the Result-Code AVP set to a value that 1195 enables the peer to understand the nature of the problem. 1197 5.1 Message-Reject-Ind (MRI) Command 1199 The Message-Reject-Ind (MRI), indicated by the Command-Code set to 1200 259, provides a generic means of completing transactions by 1201 indicating errors in the messages that initiated them. The Message- 1202 Reject-Ind command is sent in response: 1204 1. An error is found in a message of type Ind, Answer and Response 1205 2. A message that contains an unrecognized command code 1206 3. A message was received that cannot pass the base protocol error 1207 checking. 1209 In the event that a request is received that causes an error defined 1210 in a Diameter extension, the appropriate response with the Result- 1211 Code AVP SHOULD be sent. 1213 The Message-Reject-Ind message MUST contain the same identification 1214 in the header and include the Session-Id if it was present in the 1215 original message that it is responding to, even if the identification 1216 is erroneous. 1218 Message Format 1220 The structure of the Message-Reject-Ind message is defined as 1221 follows: 1223 ::= < Diameter Header: 259 > 1224 { Result-Code } 1225 { Host-Name } 1226 { Error-Reporting-NAI } 1227 [ Session-Id ] 1228 [ Failed-Command-Code ] 1229 [ Failed-AVP ] 1230 * [ AVP ] 1231 * [ Proxy-State ] 1232 * [ Route-Record ] 1233 * [ Routing-Realm ] 1234 0*1< Integrity-Check-Value > 1236 where the Identifier value in the message header and optionally 1237 the Session-Id AVP are copied from the message being rejected. The 1238 Result-Code AVP indicate the nature of the error causing 1239 rejection, and the Failed-AVP AVP provides some minimal debugging 1240 data by indicating a specific AVP type which caused the problem. 1241 See the description of the Result-Code AVP for indication of when 1242 the Failed-AVP AVP MUST be present in the message. See [25] for 1243 more information. 1245 5.1.1 Failed-AVP AVP 1247 The Failed-AVP AVP (AVP Code 279) is of type OctetString and provides 1248 debugging information in cases where a request is rejected or not 1249 fully processed due to erroneous information in a specific AVP. The 1250 value of the Result-Code AVP will provide information on the reason 1251 for the Failed-AVP AVP. 1253 A Diameter message MAY contain one or more Failed-AVP AVPs, each 1254 containing a complete AVP that could not be processed successfully. 1255 The possible reasons for this AVP are the presence of an improperly 1256 constructed AVP, an unsupported or unrecognized AVP, an invalid AVP 1257 value; or the omission of a required AVP. 1259 5.1.2 Failed-Command-Code 1261 The Failed-Command-Code AVP (AVP Code 270) is of type Unsigned32 and 1262 contains the offending Command-Code that resulted in sending the 1263 Message-Reject-Ind message. 1265 5.2 Result-Code AVP 1267 The Result-Code AVP (AVP Code 268) is of type Unsigned32 and 1268 indicates whether a particular request was completed successfully or 1269 whether an error occurred. All Diameter messages of type *-Response 1270 or *-Answer MUST include one Result-Code AVP, while messages of type 1271 -Ind MAY include the Result-Code AVP. A non-successful Result-Code 1272 AVP (one containing a non 2001 value) MUST include the Error- 1273 Reporting-NAI AVP. 1275 The Result Code field contains an IANA-managed 32-bit address space 1276 representing errors (see section 8.4). Diameter provides five 1277 different classes of errors, all identified by the thousands digit: 1278 - 1xxx (Informational) 1279 - 2xxx (Success) 1280 - 3xxx (Redirect Notification) 1281 - 4xxx (Transient Failures) 1282 - 5xxx (Permanent Failure) 1283 - 6xxx (Hop-by-Hop Failure) 1285 A non-recognize class (one whose first digit is not defined in this 1286 section) MUST be handled as a permanent failure. 1288 5.2.1 Informational 1290 Errors that fall within the Informational category are used to inform 1291 a requester that the request cannot be immediately satisfied and a 1292 further response will be issued in the near future. 1294 DIAMETER_BE_PATIENT 1001 1295 The Diameter server responsible for authentication and/or 1296 authorizing the user cannot satisfy the request at the moment, 1297 and will respond within the next 3 seconds. 1299 5.2.2 Success 1300 Errors that fall within the Success category are used to inform a 1301 peer that a request has been successfully completed. 1303 DIAMETER_SUCCESS 2001 1304 The Request was successfully completed. 1306 5.2.3 Redirect Notification 1308 Errors that fall within the Redirect Notification category are used 1309 to inform a peer that the request cannot be satisfied locally and 1310 should instead be forwarded to another server. 1312 DIAMETER_REDIRECT_INDICATION 3001 1313 A proxy or redirect server has determined that the request 1314 could not be satisfied locally and the initiator of the request 1315 should direct the request directly to the server, whose contact 1316 information has been added to the response. This error code 1317 MUST NOT be sent in a Message-Reject-Ind message. 1319 5.2.4 Transient Failures 1321 Errors that fall within the transient failures category are used to 1322 inform a peer that the request could not be satisfied at the time it 1323 was received, but MAY be able to satisfy the request in the future. 1325 DIAMETER_AUTHENTICATION_REJECTED 4001 1326 The authentication process for the user failed, most likely due 1327 to an invalid password used by the user. Further attempts MUST 1328 only be tried after prompting the user for a new password. 1330 DIAMETER_NO_END_2_END_SECURITY 4002 1331 A proxy has detected that end-to-end security has been applied 1332 to portions of the Diameter message, and the proxy does not 1333 allow this security mode since it needs to alter the message by 1334 applying some local policies. 1336 5.2.5 Permanent Failures 1338 Errors that fall within the permanent failures category are used to 1339 inform the peer that the request failed, and should not be attempted 1340 again. 1342 DIAMETER_USER_UNKNOWN 5001 1343 A request was received for a user that is unknown, therefore 1344 authentication and/or authorization failed. 1346 DIAMETER_AVP_UNSUPPORTED 5002 1347 The peer received a message that contained an AVP that is not 1348 recognized or supported and was marked with the Mandatory bit. 1349 A Diameter message with this error MUST contain one or more 1350 Failed-AVP AVP containing the AVPs that caused the failure. 1352 DIAMETER_UNKNOWN_SESSION_ID 5003 1353 The request or response contained an unknown Session-Id. 1355 DIAMETER_AUTHORIZATION_REJECTED 5004 1356 A request was received for which the user could not be 1357 authorized. This error could occur if the service requested is 1358 not permitted to the user. 1360 DIAMETER_INVALID_AVP_VALUE 5005 1361 The request contained an AVP with an invalid value in its data 1362 portion. A Diameter message with this result code MUST include 1363 the offending AVPs within a Failed-AVP AVP. 1365 DIAMETER_MISSING_AVP 5006 1366 The request did not contain an AVP that is required by the 1367 Command Code definition. If this value is sent in the Result- 1368 Code AVP, a Failed-AVP AVP SHOULD be included in the message. 1369 The data portion of the Failed-AVP MUST have its AVP Code set 1370 to the Data field of the missing AVP. 1372 DIAMETER_INVALID_CMS_DATA 5007 1373 The Request did not contain a valid CMS-Data [11] AVP. 1375 DIAMETER_LOOP_DETECTED 5008 1376 A Proxy or Redirect server detected a loop while trying to get 1377 the message to the Home Diameter server. Further attempts 1378 should not be attempted until the loop has been fixed. 1380 DIAMETER_AUTHORIZATION_FAILED 5009 1381 A request was received for which the user could not be 1382 authorized at this time. This error could occur when the user 1383 has already expended allowed resources, or is only permitted to 1384 access services within a time period. 1386 DIAMETER_CONTRADICTING_AVPS 5010 1387 The Home Diameter server has detected AVPs in the request that 1388 contradicted each other, and is not willing to provide service 1389 to the user. One or more Failed-AVP AVPs MUST be present, 1390 containing the AVPs that contradicted each other. 1392 5.2.6 Hop-by-Hop Failures 1393 Proxies receiving messages with the Result-Code AVP set to an error 1394 within the Hop-by-Hop failure category SHOULD attempt to take some 1395 local action to correct the error. If no local action can be taken to 1396 correct the problem, the error MUST be forwarded towards the 1397 originator of the message. 1399 DIAMETER_INVALID_RECORD_ROUTE 6001 1400 The last Record-Route AVP in the message is not set to the 1401 identity of the sender of the message. See Section 6.0 for more 1402 information. 1404 DIAMETER_COMMAND_UNSUPPORTED 6002 1405 The Request contained a Command-Code that the receiver did not 1406 recognize or support. The Message-Reject-Ind message MUST also 1407 contain an Failed-Command-Code AVP containing the unrecognized 1408 Command-Code. 1410 DIAMETER_TIME_INVALID 6003 1411 This Result-Code value is return to inform a peer that the 1412 message received contained an invalid timestamp value (in 1413 Timestamp AVP). 1415 DIAMETER_UNABLE_TO_DELIVER 6004 1416 The request could not be delivered to a host that handles the 1417 realm requested at this time. 1419 DIAMETER_REALM_NOT_SERVED 6005 1420 A proxy or redirect server has determined that it is unable to 1421 forward the request or provide redirect information since the 1422 realm portion of the NAI requested is unknown. 1424 DIAMETER_UNSUPPORTED_TRANSFORM 6006 1425 A message was received that included an Integrity-Check-Value 1426 or CMS-Data AVP [11] that made use of an unsupported transform. 1428 DIAMETER_INVALID_ICV 6007 1429 The Request did not contain a valid Integrity-Check-Value AVP. 1431 5.3 Error-Message AVP 1433 The Error-Message AVP (AVP Code 281) is of type OctetString. It is a 1434 human readable UTF-8 character encoded string. It MAY accompany a 1435 Result-Code AVP as a human readable error message. The Error-Message 1436 AVP is not intended to be useful in real-time, and SHOULD NOT be 1437 expected to be parsed by network entities. 1439 5.4 Error-Reporting-NAI AVP 1441 The Error-Reporting-NAI AVP (AVP Code 294) is of type OctetString. 1442 This AVP contains the Network Access Identifier of the Diameter host 1443 that set the Result-Code AVP to a value other than 2001 (Success). 1444 This AVP is intended to be used for troubleshooting purposes, and 1445 MUST be set when the Result-Code AVP indicates a failure. 1447 6.0 Message Routing 1449 This section describes the expected behavior of a Diameter server 1450 acting as a proxy or redirect server. 1452 6.1 Realm-Based Message Routing 1454 Diameter Message routing is done through the use of the realm portion 1455 of the Network Access Identifier (NAI), and an associated realm 1456 routing table (see section 10.0). The NAI has a format of user@realm, 1457 and Diameter servers have a list of locally supported realms, and MAY 1458 have a list of externally supported realms. When a message is 1459 received that includes a realm that is not locally supported, the 1460 message is proxied to the Diameter entity configured in the "route" 1461 table. 1463 There are instances where the User-Name AVP is not present in 1464 authorization requests. This is typically true in networks where a 1465 request is sent to the network before the call was even answered. 1466 However, such requests MAY need to be proxied. In such cases, the 1467 first hop Diameter proxy MAY append the Routing-Realm AVP to the 1468 Diameter message, by using a DNIS or ANI to Routing-Realm association 1469 table, if it is known. If the message is forwarded to a downstream 1470 proxy, the proxy MAY add the missing Routing-Realm AVP (or replace an 1471 existing Routing-Realm AVP), if the realm associated with the DNIS or 1472 ANI is known. 1474 Figure 1 depicts an example where DIA1 receives a request to 1475 authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local 1476 realm route table and determines that the message must be proxied to 1477 DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 1478 checks its realm route table, and determines that the realm is 1479 locally supported, and processes the authentication request, and 1480 returns the response. How the response actually makes it back to the 1481 sender of the original request is described in the next section. 1483 (Request) (Request) 1484 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1485 +------+ ------> +------+ ------> +------+ 1486 | | | | | | 1487 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1488 | | | | | | 1489 +------+ <------ +------+ <------ +------+ 1490 (Response) (Response) 1491 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1493 mno.net xyz.com abc.com 1494 Figure 1: Realm-Based Routing 1496 6.2 Behavior of Proxy and Redirect Servers 1498 This section describes the behavior of Diameter proxy and redirect 1499 servers in detail. In both cases, determining the next hop for a 1500 Diameter message is done via the Routing-Realm or the User-Name AVP 1501 [1], whose syntax must comply with the Network Access Identifier 1502 (NAI) [12] specification. When present, the Routing-Realm takes 1503 precedence over the User-Name AVP for routing decisions. The 1504 Routing-Realm AVP, or the realm portion of the User-Name AVP is used 1505 to identify the next hop server the message must be forwarded to. 1507 Note the processing rules contained in this section are intended to 1508 be used as general guidelines to Diameter developers. Certain 1509 implementations MAY use different methods than the ones described 1510 here, and still be in compliance with the protocol specification. 1512 6.2.1 Proxy and Redirect Server handling of requests 1514 Any request received by a Diameter server MUST perform a next hop 1515 lookup. Lookups are performed against what is commonly known as the 1516 Domain Routing Table (see section 10.0). A Domain Routing Table Entry 1517 contains the following fields: 1518 - Domain Name. The Domain Name is analogous to the realm portion 1519 of the NAI. This is the field that is typically used as a 1520 primary key in the routing table lookups. Note that some 1521 implementations perform their lookups based on longest-match- 1522 from-the-right on the realm rather than requiring an exact 1523 match. 1524 - Extension Id. It is possible for a routing entry to have a 1525 different destination based on the extension identifier of the 1526 message. This field is typically used as a secondary key field 1527 in routing table lookups. 1528 - Local Action. The Local Action field is used to identify how a 1529 message should be treated. The following actions are supported: 1530 1. LOCAL - Diameter messages that resolve to a routing entry 1531 with the Local Action set to Local can be satisfied 1532 locally, and do not need to be forwarded to another 1533 server. 1534 2. PROXY - All Diameter messages that fall within this 1535 category MUST be forwarded to a next hop server. The local 1536 server MAY apply its local policies to the message by 1537 including new AVPs to the message prior to forwarding. 1538 See section 6.4 for more information. 1539 3. REDIRECT - Diameter messages that fall within this 1540 category MUST have the identity of the home Diameter 1541 server(s) appended, and returned to the sender of the 1542 message. See section 6.3 for more information. 1543 - Server Identifier - One or more servers the message is to be 1544 forwarded to. When the Local Action is set to PROXY, this field 1545 contains the identities of the server(s) the message must be 1546 forwarded to. When the Local Action field is set to REDIRECT, 1547 this field contains the Home Diameter server(s) for the realm. 1549 It is important to note that Diameter servers MUST support at least 1550 one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do 1551 not need to support all modes of operation in order to conform with 1552 the protocol specification. Servers MUST NOT reorder AVPs with the 1553 same AVP Code. 1555 6.3 Redirect Server 1557 A Redirect Server is one that provides NAI Realm to Diameter Home 1558 Server address resolution. When a message is received by a peer, the 1559 Routing-Realm or the realm portion of the User-Name AVP is extracted 1560 from the message, and the realm portion is used to perform a lookup 1561 in the domain routing table. Implementations MAY also use the 1562 Extension Id as a secondary key in the domain routing table lookup. 1564 Successful routing table lookups will return one or more home 1565 Diameter servers that could satisfy the message. The home servers are 1566 encoded in one or more Redirect-Host-Address AVPs. If the Redirect- 1567 Host-Port is to be included (meaning that the host is not listening 1568 on the standard Diameter port), it MUST be encapsulated within the 1569 Redirect-Host AVP along with its corresponding Redirect-Host-Address 1570 AVP. 1572 +------------------+ 1573 | Diameter | 1574 | Redirect Server | 1575 +------------------+ 1576 ^ | 1577 Request | | Response + 1578 joe@xyz.com | | Result Code = 1579 | | Redirect 1580 | v 1581 +----------+ Request +----------+ 1582 | abc.net |------------->| xyz.net | 1583 | Diameter | | Diameter | 1584 | Server |<-------------| Server | 1585 +----------+ Response +----------+ 1586 Figure 2: Diameter Redirect Server 1588 Lastly, the Result-Code AVP is added with the Data field of the AVP 1589 set to Diameter_REDIRECT_INDICATION [1], and the message is returned 1590 to the sender of the request. Redirect servers MAY also include the 1591 certificate of the Home server(s). These certificates are 1592 encapsulated in a CMS-Data AVP [11]. When this occurs, the server 1593 forwarding the request directly to the Home Diameter server SHOULD 1594 include its own certificate in the message. 1596 6.3.1 Redirect-Host AVP 1598 The Redirect-Host AVP (AVP Code 292) is of type Grouped and is found 1599 in responses that include the Result-Code AVP set to 1600 Diameter_REDIRECT_REQUEST. This AVP only needs to be used if the host 1601 the message is to be redirected to is not listening on the standard 1602 Diameter port. Its Data field has the following ABNF grammar: 1604 Redirect-Host = Redirect-Host-Address Redirect-Host-Port 1605 Redirect-Host-Address = ; See Section 6.3.2 1606 Redirect-Host-Port = ; See Section 6.3.3 1608 The Redirect-Host-Address AVP Data field contains the IP Address of 1609 the Diameter host to which the request MUST be redirected. The 1610 Redirect-Host-Port contains the port number to which the request 1611 should be sent. Upon receipt of such a Result Code, and this AVP, the 1612 receiving host SHOULD send the request directly to the host 1613 identified by the Redirect-Host-Address AVP. 1615 +---------------------------------------------------------------+ 1616 | AVP Header (AVP Code = 292) | 1617 +---------------------------------------------------------------+ 1618 | Redirect-Host-Address AVP | 1619 +---------------------------------------------------------------+ 1620 | Redirect-Host-Port AVP | 1621 +---------------------------------------------------------------+ 1623 6.3.2 Redirect-Host-Address AVP 1625 The Redirect-Host-Address AVP (AVP Code 278) is of type Address. Its 1626 use is described in Section 6.3.1. 1628 6.3.3 Redirect-Host-Port AVP 1630 The Redirect-Host-Port AVP (AVP Code 277) is of type Unsigned32. Its 1631 use is described in Section 6.3.1. 1633 6.4 Proxy Server 1635 This section outlines the processing rules for Diameter proxy 1636 servers. A proxy server can either be stateful or stateless. A Proxy 1637 server MAY act in a stateful manner for some requests, and be 1638 stateless for others. There are two types of states that servers MAY 1639 wish to maintain; transaction and session. 1641 Maintaining transaction state implies that a server keeps a copy of a 1642 request, which is then used when the corresponding response is 1643 received. This could be done to apply local policies to the message, 1644 or simply for auditing purposes. Maintaining session state implies 1645 that a server keeps track of all "active" users. An active user is 1646 one that has been authorized for a particular service, and the server 1647 has not received any indication that the user has relinquished 1648 access. 1650 A stateless proxy is one that does not maintain transaction, nor 1651 session state. It frees the messages sent once acknowledgements are 1652 received by the transport layer. 1654 A stateful proxy can be viewed as a Diameter Server upon receiving a 1655 request, and as a Client when forwarding the message. For all intents 1656 and purposes, stateful servers terminate an upstream "session", and 1657 initiates a downstream "session" (see Figure 3), and MAY provide the 1658 following features: 1659 - Protocol translation (e.g. RADIUS <-> Diameter) 1660 - Limiting resources authorized to a particular user 1661 - Per user or transaction auditing 1663 +--------+ +-----------------+ +--------+ 1664 | Client | --------> | Server | Client | -------> | Server | 1665 +--------+ +-----------------+ +--------+ 1666 Figure 3 - Example of Stateful Proxy 1668 A stateful proxy that maintains transaction state SHOULD release 1669 transaction information after a request's corresponding response has 1670 been forwarded towards the recipient, and has been acknowledged by 1671 the underlying transport. 1673 A stateful proxy that maintains session state SHOULD release the 1674 session state once it is informed that a user and/or device has 1675 relinquished access. 1677 Home servers processing requests that include the Route-Record and/or 1678 the Proxy-State AVPs MUST return these AVPs in the same order in the 1679 corresponding response. 1681 6.4.1 Proxying Requests 1683 A proxy server MUST check for forwarding loops before proxying a 1684 message of type Request, Query or Indication. Such as message has 1685 been looped if the server finds its own address in a Route-Record 1686 AVP. 1688 A Diameter server that proxies a message or type Request, Query or 1689 Indication MUST append a Route-Record AVP, which includes its 1690 identity. Diameter Servers that receive messages MUST validate the 1691 last Route-Record AVP in the message and ensure that the host 1692 identified in the AVP is the same as the sender of the message. 1694 A Proxy Server MAY also include the Proxy-State AVP in a message of 1695 type Request or Query, which is used to encode local state 1696 information. The Proxy-State AVP is guaranteed to be present in the 1697 corresponding response. 1699 The message is then forwarded to the downstream Diameter server, as 1700 identified in the Domain Routing Table. 1702 Proxy Server MUST save the Identifier in request messages, and update 1703 the header field with a locally unique value. The saved identifier 1704 MAY be encoded in the Proxy-State AVP, and will be required in the 1705 processing of the corresponding response. 1707 6.4.2 Proxying Responses 1709 A proxy server MUST only process messges of type Response or Answer 1710 whose last Route-Record AVP matches one of its addresses. Any 1711 responses that do not conform to this rule MUST be dropped. The last 1712 Route-Record AVP MUST be removed from the message before it is 1713 forwarded to the next hop, which is identified by the second to last 1714 Route-Record AVP. 1716 If the last Proxy-State AVP in the message is targeted to the local 1717 Diameter server, the AVP MUST be removed. 1719 If a proxy server receives a response with a Result-Code AVP 1720 indicating a failure, it MUST NOT modify the contents of the AVP. Any 1721 additional local errors detected SHOULD be logged, but not reflected 1722 in the Result-Code AVP. 1724 Prior to forwarding the response, proxy servers MUST restore the 1725 original value of the Diameter header's Identifier field. 1727 6.4.3 Route-Record AVP 1729 The Route-Record AVP (AVP Code 282) is of type OctetString, and 1730 contains the Fully Qualified Domain Name of the Proxy appending this 1731 AVP to a Diameter message. 1733 6.4.4 Proxy-State AVP 1735 The Proxy-State AVP (AVP Code = 33) is of type Grouped. The Grouped 1736 Data field has the following ABNF grammar: 1738 Proxy-State = Proxy-Address Proxy-Info 1739 Proxy-Address = ; See Section 6.4.5 1740 Proxy-Info = ; See Section 6.4.6 1742 The Proxy-Address AVP Data field contains one of the IP addresses of 1743 the system that created the AVP. This assists hosts in determining 1744 whether a Proxy-State AVP is intended for the local host. The Proxy- 1745 Info AVP contains state information, and MUST be treated as opaque 1746 data. 1748 +---------------------------------------------------------------+ 1749 | AVP Header (AVP Code = 33) | 1750 +---------------------------------------------------------------+ 1751 | Proxy-Address AVP | 1752 +---------------------------------------------------------------+ 1753 | Proxy-Info AVP | 1754 +---------------------------------------------------------------+ 1756 6.4.5 Proxy-Address AVP 1758 The Proxy-Address AVP (AVP Code = 280) is of type Address. Its use 1759 is described in Section 6.4.4. 1761 6.4.6 Proxy-Info AVP 1763 The Proxy-Info AVP (AVP Code = 284) is of type OctetString. Its use 1764 is described in Section 6.4.4. 1766 6.4.7 Routing-Realm AVP 1768 The Routing-Realm AVP (AVP Code 283) is of type OctetString and 1769 contains the realm portion of the Network Access Identifier. When 1770 present, the Routing-Realm AVP MAY be used to perform any message 1771 routing decisions. 1773 6.5 Applying Local Policies 1775 Proxies MAY apply local access policies to Diameter requests, or 1776 responses, by adding, changing or deleting AVPs in the messages. 1777 Proxies that apply local policies MUST NOT allow end-to-end security 1778 on any messages that traverse through it, unless security is 1779 terminated locally. 1781 A proxy wishing to modify a Diameter message to enforce some local 1782 policy that detects that end-to-end security has been applied to the 1783 message MUST return a response to the originator with the Result-Code 1784 set to Diameter_NO_END_2_END_SECURITY. The originator of the request 1785 MAY re-issue the request with no end-to-end security if it falls 1786 within its local policy. 1788 In the event that the Home Diameter server receives a request with 1789 contradictory information (possibly due to some proxy adding a local 1790 policy), it MAY accept the latest AVP, or MAY return the response 1791 with the Result Code AVP set to Diameter_CONTRADICTING_AVPS. However, 1792 a NAS receiving a response that contains contradictory information 1793 SHOULD reject service to the user. 1795 6.6 Hiding Network Topology 1797 Stateful proxies forwarding requests to servers outside of their 1798 administrative domain MAY hide the internal network topology. Servers 1799 perform this by removing all Route-Record AVPs in the message, and 1800 maintains the Route-Record AVPs to add to the corresponding response. 1801 Such stateful servers MUST still add their own Route-Record AVP to 1802 the request prior to forwarding. 1804 6.7 Loop Detection 1806 When a Diameter Proxy or Redirect server receives a message of type 1807 Request, Query or Indication, it MUST examine all Route-Record AVPs 1808 in the message to determine whether such an AVP already exists with 1809 the local server's identity. If an AVP with the local host's identity 1810 is found in the request, it is an indication that the message is 1811 being looped through the same set of proxies. When such an event 1812 occurs, the Diameter server that detects the loop returns a response 1813 with the Result-Code AVP set to Diameter_LOOP_DETECTED. 1815 6.8 Finding a Target NAS within a Domain 1817 The Diameter protocol supports unsolicited server initiated messages. 1818 However, when such messages are transmitted, they have a specific 1819 target Network Access Server (NAS) in mind. Unsolicited server 1820 initiated messages are unique in that they contain the Destination- 1821 NAI AVP. Routing of such messages follow the same set of guidelines 1822 described in section 6.0, with one exception. When a proxy server has 1823 determined that a message, which includes the Destination-NAI AVP, 1824 has reached its target realm, the Destination-NAI AVP is used to 1825 identify the actual NAS the message should be forwarded to. 1827 6.8.1 Destination-NAI AVP 1829 The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString, 1830 and contains the NAI [8] of the intended recipient of the message. 1831 This AVP MUST be present in all unsolicited server initiated 1832 messages. 1834 7.0 Diameter Message Security 1835 The Diameter Base protocol MAY be secured in one of three ways. The 1836 first method does not involve any security mechanisms in the Diameter 1837 protocol, but relies on an underlying security mechanism, such as IP 1838 Security. The second method is hop-by-hop security, which SHOULD be 1839 supported by all Diameter implementations. The third method is 1840 optional and requires a Public Key Infrastructure [14], and is 1841 documented in [11]. 1843 7.1 Hop-by-Hop Security 1845 Diameter Hop-by-Hop security provides message integrity and per AVP 1846 encryption, and requires that the communicating entities have a pre- 1847 configured shared secret. Hop-by-Hop security is very difficult to 1848 deploy and administer in large scale networks and involves symmetric 1849 trust, unlike security based on a public key infrastructure (PKI). 1850 PKI is used for Diameter End-to-End security, and is defined in [11]. 1851 Hop-by-Hop security may be desirable in environments where symmetric 1852 cryptography is sufficient or when a PKI is not available. 1854 Figure 4 below provides an example of hop-by-hop security in a proxy 1855 chain. Assuming that the packet was received by DIA2 from DIA1, and 1856 was to be proxied to DIA3, the following steps would be taken: 1858 1. Validating the message's integrity using the shared secret with 1859 DIA1, and removing the authenticated security AVPs. 1861 2. Decrypting any encrypted AVPs using the secret shared with DIA1. 1863 3. Re-encrypting AVPs using the secret shared with DIA3. 1865 4. Computing the message hash using the secret shared with DIA3, 1866 and adding it to the ICV AVP in the Diameter message. 1868 (Shared-Secret-1) (Shared-Secret-2) 1869 +------+ -----> +------+ ------> +------+ 1870 | | |1 3| | | 1871 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 1872 | | |2 4| | | 1873 +------+ +------+ +------+ 1874 Figure 4: Hop-by-Hop Security in Proxy Environments 1876 The above steps that each proxy MUST perform in a proxy chain clearly 1877 describes the security issues associated with hop-by-hop security in 1878 a proxy environment. Since the message integrity is re-computed at 1879 each node in the chain, it is not possible to detect if a proxy 1880 modified information in the message (e.g. session time). Furthermore, 1881 any sensitive information would be known to all proxies in the chain, 1882 since each node must decrypt AVPs. Therefore, Any AVPs that contain 1883 data that MUST NOT be seen by intermediate Diameter nodes MUST be 1884 protected via the mechanism described in the strong security 1885 extension [11]. 1887 It is highly recommended that the size of the shared secrets used be 1888 sufficiently long (e.g. 128 bits), and that different shared secrets 1889 be used for both authentication and encryption. 1891 7.1.1 Integrity-Check-Value AVP 1893 The Integrity-Check-Value AVP (AVP Code 259) is of type Grouped and 1894 is used for hop-by-hop message authentication and integrity. 1896 The Diameter header as well as all AVPs (including padding) up to the 1897 Digest AVP is protected by the Integrity-Check-Value AVP. Note that 1898 the Message Length field in the Diameter header MUST be set to zero 1899 (0) prior to the ICV calculation. The Timestamp AVP provides replay 1900 protection and the Nonce AVP provides randomness. If present, any 1901 AVPs in a message that is not succeeded by the Integrity-Check-Value 1902 AVP MUST be ignored. 1904 All Diameter implementations SHOULD support this AVP. 1906 The Integrity-Check-Value AVP (AVP Code = 259) is of type Grouped. 1907 The grammar for the grouped Data field is defined is: 1909 Integrity-Check-Value = Nonce Time Auth-Trans-Id Key-ID Digest 1910 Nonce = ; Nonce, See Section 7.2 1911 Timestamp = ; Timestamp, See Section 7.3 1912 Auth-Trans-Id = ; Authentication-Transform-Id, / 1913 ; See Section 7.1.1.1 1914 Key-ID = ; Key-ID, See Section 7.4 1915 Digest = ; Digest, See Section 7.1.1.2 1917 +---------------------------------------------------------------+ 1918 | AVP Header (AVP Code = 259) | 1919 +---------------------------------------------------------------+ 1920 | Nonce AVP | 1921 +---------------------------------------------------------------+ 1922 | Timestamp AVP | 1923 +---------------------------------------------------------------+ 1924 | Authentication-Transform-Id AVP | 1925 +---------------------------------------------------------------+ 1926 | Key-ID AVP | 1927 +---------------------------------------------------------------+ 1928 | Digest AVP | 1929 +---------------------------------------------------------------+ 1931 7.1.1.1 Authentication-Transform-Id AVP 1933 The Transform-Id AVP (AVP Code = 285) is of type Unsigned32. This 1934 value identifies the transform that was used to compute the ICV. The 1935 following values are defined in this document: 1937 HMAC-MD5-96[6] 1 1938 The ICV is computed using the HMAC-MD5 algorithm, and the first 1939 12 bytes of the hash output is included in the Digest AVP. All 1940 Diameter implementations supporting this AVP MUST support this 1941 transform. Using the example code provided in [6], the 1942 following call would be used to generate the Digest AVP: 1944 hmac_md5(DiameterMessage, MessageLength, Secret, 1945 Secretlength, Output) 1947 where the DiameterMessage is the complete message up to the 1948 Digest AVP. 1950 7.1.1.2 Digest AVP 1952 The Digest AVP (AVP Code = 287) is of type OctetString. This value 1953 contains the output from the hashing algorithm, covering all AVPs in 1954 the message, including all AVPs in the Integrity-Check-Value AVP up 1955 to, but not including, the Digest AVP. 1957 7.1.2 Encrypted-Payload AVP 1959 The Encrypted-Payload AVP (AVP Code 260) is of type Grouped and is 1960 used to encapsulate encrypted AVPs for privacy during transmission. 1962 Hop-by-Hop confidentiality is achieved by encapsulating all AVPs 1963 which are to be encrypted into an Encrypted-Payload AVP. This 1964 feature SHOULD be supported by Diameter implementations. 1966 The grammar for the grouped Data field is defined is: 1968 Encrypted-Payload = Enc-Trans-Id Key-ID ptextlen data 1969 Enc-Trans-Id = ; Encryption-Transform-Id, / 1970 ; See Section 7.1.2.1 1971 Key-ID = ; See Section 7.4 1972 ptextlen = ; Plaintext-Data-Length, See Section 7.1.2.2 1973 data = ; Encrypted-Data, See Section 7.1.2.3 1975 +---------------------------------------------------------------+ 1976 | AVP Header (AVP Code = 260) | 1977 +---------------------------------------------------------------+ 1978 | Encryption-Transform-Id AVP | 1979 +---------------------------------------------------------------+ 1980 | Key-ID AVP | 1981 +---------------------------------------------------------------+ 1982 | Plaintext-Data-Length AVP | 1983 +---------------------------------------------------------------+ 1984 | Encrypted-Data AVP | 1985 +---------------------------------------------------------------+ 1987 7.1.2.1 Encryption-Transform-Id AVP 1989 The Encryption-Transform-Id AVP (AVP Code = 288) is of type 1990 Unsigned32. This AVP identifies the transform that was used to 1991 encrypt the data contained in the Encrypted-Data AVP. The following 1992 values are defined in this document: 1994 MD5 1 1995 See section 7.1.2.4 for more information. 1997 7.1.2.1.1 MD5 Payload Hiding 1999 The plain text (which is a buffer containing one or more AVPs) is 2000 first padded to a sixteen (16) byte boundary with 0 bytes. Since the 2001 encapsulated AVPs have length fields, it is possible to detect their 2002 boundaries, whether or not padding has been done. 2004 One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 2005 hash is performed on the: 2007 - last Nonce AVP which precedes the Encrypted-Payload AVP 2008 - the shared authentication secret 2010 This MD5 hash value is then XORed with the first 16 octet segment of 2011 the buffer to encrypt. The resulting 16 octet result is saved as the 2012 first 16 octets of the encrypted buffer. The result is also used to 2013 calculate a new value using MD5: 2015 - the shared authentication secret 2016 - the 16 byte result of the previous XOR 2018 This value is then XORed with the next 16 bytes. This is done for 2019 each 16 bytes successively in the buffer to encrypt, producing an 2020 equal sized encrypted buffer. 2022 The receiver of a Diameter message with an Encrypted-Payload AVP MUST 2023 first check the integrity of the message, either through the ICV, or 2024 the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP. Then 2025 the Encrypted-Payload AVP is decrypted, by reversing the above 2026 procedure, which applied to the buffer will reproduce the plain text 2027 version. The decapsulated AVPs are then used to process the Diameter 2028 message in the normal manner. 2030 7.1.2.2 Plaintext-Data-Length AVP 2032 The Plaintext-Data-Length AVP (AVP Code = 289) is of type Unsigned32, 2033 and contains the length of the plaintext data. This AVP is necessary 2034 in order to not treat any possible padded data, added as part of the 2035 encryption transform, as part of the plaintext. 2037 7.1.2.3 Encrypted-Data AVP 2039 The Encrypted-Data AVP (AVP Code = 290) is of type OctetString. This 2040 AVP contains the encrypted AVPs. 2042 7.2 Nonce AVP 2044 The Nonce AVP (AVP Code 261) is of type OctetString and is present in 2045 the Integrity-Check-Value AVP and is used to ensure randomness within 2046 a message. The content of this AVP MUST be a random value of at least 2047 128 bits. 2049 7.3 Timestamp AVP 2051 The Timestamp AVP (AVP Code 262) is of type Unsigned32 and is used to 2052 add replay protection to the Diameter protocol. The Data field of 2053 this AVP is the most significant four octets returned from an NTP 2054 [18] server that indicates the number of seconds expired since Jan. 2055 1, 1900. 2057 Messages that are older than a configurable maximum age SHOULD be 2058 rejected (see section 10.0) and a response SHOULD be returned with 2059 the Result-Code AVP Data field set to Diameter_TIMEOUT. Note that the 2060 larger the configurable value, the more susceptible one is to a 2061 replay attack. However, one does have to take into account the 2062 possibility for clock drift, and the latency involved in the 2063 transmission of the message over the network. The timestamp AVP 2064 SHOULD be updated prior to retransmission. 2066 A Diameter node that receives a message with the Result-Code AVP set 2067 to Diameter-TIMEOUT MAY use the time found in the Timestamp AVP 2068 within the reply in order to synchronize its clock with its peer. 2069 When time synchronization is done, the sender MUST NOT change its 2070 local time, but SHOULD adjust the time delta for all outgoing 2071 messages to the peer, and require that its local time be used in 2072 received messages. 2074 Implementations must be prepared to wrap at the epochal 2038 where 2075 Time values are used, and 0,1,... MUST be considered greater than 2076 2^32-1 at that time. 2078 7.4 Key-Id AVP 2080 The Key-Id AVP (AVP Code = 286) is of type Unsigned32. This value 2081 contains a key identifier, which is used to identify the keying 2082 information used to generate the Digest AVP or the Encrypted-Data 2083 AVP. 2085 8.0 IANA Considerations 2087 This document defines a number of assigned numbers to be maintained 2088 by the IANA. This section explains the criteria to be used by the 2089 IANA to assign additional numbers in each of these lists. The 2090 following subsections describe the assignment policy for the 2091 namespaces defined elsewhere in this document. 2093 8.1 AVP Attributes 2095 As defined in section 2.3, AVPs contain vendor ID, attribute and Data 2096 fields. For vendor ID value of 0, IANA will maintain a registry of 2097 assigned AVP codes and in some case also values. Attribute 0-254 are 2098 assigned from the RADIUS protocol [1], whose attributes are also 2099 maintained through IANA. AVP Codes 256-280 are assigned within this 2100 document. The remaining values are available for assignment through 2101 Designated Expert [12]. 2103 8.2 Command Code Values 2105 As defined in section 2.1, the Command Code field has an associated 2106 value maintained by IANA. Values 0-255 are reserved for backward 2107 RADIUS compatibility, and values 257, 259, 274, 275 and 276 are 2108 defined in this specification. The remaining values are available for 2109 assignment via Designated Expert [12]. 2111 8.3 Extension Identifier Values 2113 As defined in section 2.6.5, the Extension Identifier is used to 2114 identify a specific Diameter Extension. All values, other than zero 2115 (0) are available for assignment via Standards Action [12]. 2117 Note that the Diameter protocol is not inteded to be extended for any 2118 purpose. Any extensions added to the protocol MUST ensure that they 2119 fit within the existing framework, and that no changes to the base 2120 protocol are required. 2122 8.4 Result-Code AVP Values 2124 As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines 2125 the values 1001, 2001, 3001, 4001-4002, 5001-5010 and 6001-6007. All 2126 remaining values are available for assignment via IETF Consensus 2127 [12]. 2129 8.5 Authentication-Transform-Id AVP Values 2131 Section 7.1.1.1 defines the Authentication-Transform-Id AVP (AVP Code 2132 285) which is used to identify the authentication algorithm used to 2133 generate the contents of the Digest AVP. This document reserves the 2134 value 1. All remaining values are available for assignment via 2135 Designated Expert [12]. 2137 8.6 Encryption-Transform-Id AVP Values 2139 Section 7.1.2.1 defines the Encryption-Transform-Id AVP (AVP Code 2140 288) which is used to identify the encryption algorithm used to 2141 generate the contents of the Encrypted-Data AVP. This document 2142 reserves the value 1. All remaining values are available for 2143 assignment via Designated Expert [12]. 2145 8.7 Message Header Bits 2147 There are thirteen bits in the Flags field of the Diameter header. 2148 This document assigns bit 1 ('R'esponse), bit 2 ('I'nterrogation) and 2149 bit 3 ('E'xpected Reply). Bits 4 through 13 should only be assigned 2150 via a Standards Action [12]. 2152 8.8 AVP Header Bits 2154 There are 16 bits in the Flags field of the AVP Header. This document 2155 assigns bit 1 ('M'andatory), bit 3 ('V'endor Specific) and bit 5 2156 ('P'rotected). The remaining bits should only be assigned via a 2157 Standards Action [12]. 2159 9.0 Open Issues 2161 The following are the open issues that SHOULD be addressed in future 2162 versions of the Diameter protocol: 2164 - AVPs with time values are represented by Unsigned32 type data. 2165 This value is a timestamp consistent with NTP [18]. This field 2166 is expected to expire sometime in 2038. Future investigation 2167 SHOULD be done to determine if a 64 bit time format could be 2168 used. 2170 - The fact that the Sender's IP Address is used in the 2171 construction of the Session-Id means that the introduction of 2172 Network Address Translation MAY cause two hosts to represent the 2173 same Session Identifier. This area needs to be investigated 2174 further to be able to support Diameter hosts on a private 2175 network. 2177 10.0 Diameter protocol related configurable parameters 2179 This section contains the configurable parameters that are found 2180 throughout this document: 2182 Diameter Peer 2183 A Diameter entity MAY communicate with peers that are 2184 statically configured. A statically configured Diameter peer 2185 would require that either the IP address or the fully qualified 2186 domain name (FQDN) be supplied, which would then be used to 2187 resolve through DNS. 2189 Realm Routing Table 2190 A Diameter Proxy server routes messages based on the realm 2191 portion of a Network Access Identifier (NAI). The server MUST 2192 have a table of Realms Names, and the address of the peer to 2193 which the message must be forwarded to. The routing table MAY 2194 also include a "default route", which is typically used for all 2195 messages that cannot be locally processed. 2197 Maximum Age of an outstanding message 2198 Messages older than the maximum age SHOULD be rejected, as 2199 described in section 7.3. The recommended value is 4 seconds. 2201 Shared Secret 2202 The shared secret is a value that is known by two communicating 2203 peers, and is used to generate the Integrity-Check-Value and 2204 the Encryption-Payload AVP. There is no default. 2206 11.0 Security Considerations 2208 The Diameter base protocol requires that two communicating peers 2209 exchange messages in a secure fashion. This document describes two 2210 security methods that can be used. The first requires no security at 2211 the application layer, but rather relies on an underlying security 2212 mechanism, such as IP Security. 2214 When IP Security is not available, or desirable, the Diameter 2215 protocol MAY use hop-by-hop security, which requires communicating 2216 peers to negotiate a symmetric key through some out of band 2217 mechanism. Hop-by-Hop security provides replay protection by 2218 requiring that the communicating peers share a time source, such as 2219 an NTP server. Information of a sensitive nature, which MUST NOT be 2220 seen by any intermediate Diameter node MUST NOT be encrypted using 2221 hop-by-hop encryption. 2223 When the Diameter protocol is used in an inter-domain network, strong 2224 application level security MAY be required, such as non-repudiation. 2225 When the communicating peers do require this level of security either 2226 for legal or business purposes, the extension defined in [11] MAY be 2227 used. This security model provides AVP-level authentication, and the 2228 encryption mechanism is designed such that only the target host has 2229 the keying information required to decrypt the information. 2231 12.0 References 2233 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 2235 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 2237 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 2239 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 2240 1992. 2242 [5] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 2243 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 2244 13-061466-1. 2246 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 2247 Authentication", RFC 2104, January 1997. 2249 [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 2250 Extension", draft-calhoun-diameter-nasreq-06.txt, IETF work in 2251 progress, January 2001. 2253 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 2254 ary 1999. 2256 [9] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft- 2257 calhoun-diameter-framework-09.txt, IETF work in progress, Janu- 2258 ary 2001. 2260 [10] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2261 calhoun-diameter-mobileip-12.txt, IETF work in progress, January 2262 2001. 2264 [11] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 2265 Extension", draft-calhoun-diameter-strong-crypto-06.txt (work in 2266 progress), January 2001. 2268 [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 2269 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2271 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2272 Levels", BCP 14, RFC 2119, March 1997. 2274 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 2275 Key Infrastructure Online Certificate Status Protocol (OCSP)", 2276 RFC 2560, June 1999. 2278 [15] Arkko, Calhoun, Patel, Zorn, "Diameter Accounting Extension", 2279 draft-calhoun-diameter-accounting-09.txt, IETF work in progress, 2280 January 2001. 2282 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2283 2373, July 1998. 2285 [17] ISI, "Internet Protocol", RFC 791, September 1981. 2287 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 2288 IPv6 and OSI, RFC 2030, October 1996. 2290 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 2291 tructure Certificate and CRL Profile", RFC 2459, January 1999. 2293 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 2294 RFC 2477, January 1999. 2296 [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2297 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2298 in progress, June 2000. 2300 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 2301 draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep- 2302 tember 2000. 2304 [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 2305 Authorization, and Accounting Requirements". RFC 2977. October 2306 2000. 2308 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2309 2279, January 1998. 2311 [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 2312 Haag, "Diameter Implementation Guidelines", draft-calhoun- 2313 diameter-impl-guide-04.txt, IETF work in progress, June 2000. 2315 [26] R. Stewart et al., "Simple Control Transmission Protocol". RFC 2316 2960. October 2000. 2318 [27] Postel, J. "Transmission Control Protocol", RFC 793, January 2319 1981. 2321 [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location 2322 Protocol, Version 2", RFC 2165, June 1999. 2324 [29] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2325 diameter-res-mgmt-06.txt, IETF Work in Progress, January 2001. 2327 [30] Institute of Electrical and Electronics Engineers, "IEEE Stan- 2328 dard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 2329 754-1985, August 1985. 2331 [31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica- 2332 tions: ABNF", RFC 2234, November 1997. 2334 [32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Ser- 2335 vice: Schemes", RFC 2609, June 1999. 2337 [33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying 2338 the location of services (DNS SRV)", RFC 2782, February 2000. 2340 [34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, 2341 March 1999. 2343 [35] D. Eastlake, "DNS Security Operational Considerations", RFC 2344 2541, March 1999. 2346 [36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s 2347 )", RFC 2931, September 2000. 2349 13.0 Acknowledgements 2351 The authors would like to thank Nenad Trifunovic, Tony Johansson and 2352 Pankaj Patel for their participation in the Document Reading Party. 2354 The authors would also like to acknowledge the following people for 2355 their contribution in the development of the Diameter protocol: 2357 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2358 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 2359 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen Farrell, 2360 Sumit Vakil, John R. Vollbrecht, Jeff Weisberg, Jon Wood and Glen 2361 Zorn 2363 14.0 Authors' Addresses 2365 Questions about this memo can be directed to: 2367 Pat R. Calhoun 2368 Network and Security Research Center, Sun Laboratories 2369 Sun Microsystems, Inc. 2370 15 Network Circle 2371 Menlo Park, California, 94025 2372 USA 2373 Phone: +1 650-786-7733 2374 Fax: +1 650-786-6445 2375 E-mail: pcalhoun@eng.sun.com 2377 Allan C. Rubens 2378 Tut Systems, Inc. 2379 220 E. Huron, Suite 260 2380 Ann Arbor, MI 48104 2381 USA 2383 Phone: +1 734-995-1697 2384 E-Mail: arubens@tutsys.com 2386 Haseeb Akhtar 2387 Wireless Technology Labs 2388 Nortel Networks 2389 2221 Lakeside Blvd. 2390 Richardson, TX 75082-4399 2391 USA 2393 Phone: +1 972-684-8850 2394 E-Mail: haseeb@nortelnetworks.com 2396 Erik Guttman 2397 Solaris Advanced Development 2398 Sun Microsystems, Inc. 2399 Eichhoelzelstr. 7 2400 74915 Waibstadt 2401 Germany 2403 Phone: +49-7263-911-701 2404 E-mail: , 2406 15.0 Full Copyright Statement 2408 Copyright (C) The Internet Society (2001). All Rights Reserved. 2410 This document and translations of it may be copied and furnished to 2411 others, and derivative works that comment on or otherwise explain it 2412 or assist in its implementation may be prepared, copied, published 2413 and distributed, in whole or in part, without restriction of any 2414 kind, provided that the above copyright notice and this paragraph are 2415 included on all such copies and derivative works. However, this docu- 2416 ment itself may not be modified in any way, such as by removing the 2417 copyright notice or references to the Internet Society or other 2418 Internet organizations, except as needed for the purpose of develop- 2419 ing Internet standards in which case the procedures for copyrights 2420 defined in the Internet Standards process must be followed, or as 2421 required to translate it into languages other than English. The lim- 2422 ited permissions granted above are perpetual and will not be revoked 2423 by the Internet Society or its successors or assigns. This document 2424 and the information contained herein is provided on an "AS IS" basis 2425 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2426 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2427 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2428 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2429 FITNESS FOR A PARTICULAR PURPOSE. 2431 16.0 Expiration Date 2433 This memo is filed as and expires in 2434 July 2001. 2436 Appendix A. Diameter Service Template 2438 The following service template describes the attributes used by Diam- 2439 eter servers to advertise themselves. This simplifies the process of 2440 selecting an appropriate server to communicate with. A Diameter 2441 client can request specific Diameter servers based on characteristics 2442 of the Diameter service desired (for example, an AAA server to use 2443 for accounting.) 2445 Name of submitter: "Erik Guttman" 2446 Language of service template: en 2448 Security Considerations: 2449 Diameter clients and servers use various cryptographic mechanisms 2450 to protect communication integrity, confidentiality as well as 2451 perform end-point authentication. It would thus be difficult if 2452 not impossible for an attacker to advertise itself using SLPv2 and 2453 pose as a legitimate Diameter peer without proper preconfigured 2454 secrets or cryptographic keys. Still, as Diameter services are 2455 vital for network operation it is important to use SLPv2 authenti- 2456 cation to prevent an attacker from modifying or eliminating ser- 2457 vice advertisements for legitimate Diameter servers. 2459 Template text: 2460 -------------------------template begins here----------------------- 2461 template-type=service:diameter 2463 template-version=0.0 2465 template-description= 2466 The Diameter protocol is defined by draft-calhoun-diameter-18.txt 2468 template-url-syntax= 2469 url-path= ; The standard service URL syntax is used. 2470 ; For example: 'service:diameter://aaa.example.com:1812 2472 supported-extensions= string L M 2473 # This attribute lists the Diameter extensions supported by the 2474 # AAA implementation. The extensions currently defined are: 2475 # Extension Name Defined by 2476 # --------------- ----------------------------------- 2477 # NASREQ draft-calhoun-diameter-nasreq-05.txt 2478 # MobileIP draft-calhoun-diameter-mobileip-11.txt 2479 # Accounting draft-calhoun-diameter-accounting-08.txt 2480 # Strong Security draft-calhoun-diameter-strong-crypto-05.txt 2481 # Resource Management draft-calhoun-diameter-res-mgmt-06.txt 2482 # 2483 # Notes: 2484 # . Diameter implementations support one or more extensions. 2485 # . Additional extensions may be defined in the future. 2486 # An updated service template will be created at that time. 2487 # 2488 NASREQ,MobileIP,Accounting,Strong Security,Resource Management 2490 supported-transports= string L M 2491 SCTP 2492 # This attribute lists the supported transports that the Diameter 2493 # implementation accepts. Note that a compliant Diameter 2494 # implementation MUST support SCTP, though it MAY support other 2495 # transports, too. 2496 SCTP,TCP 2498 -------------------------template ends here-----------------------