idnits 2.17.1 draft-calhoun-diameter-17.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 44 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 45 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 17 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 640 has weird spacing: '...th peer conne...' == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1820, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1822, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1873, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-05 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-08 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-11 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 -- 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) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-08 -- 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 draft: draft-ietf-mobileip-aaa-reqs (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-03 -- Possible downref: Normative reference to a draft: ref. '25' ** Obsolete normative reference: RFC 793 (ref. '27') (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-05 -- Possible downref: Normative reference to a draft: ref. '29' Summary: 22 errors (**), 0 flaws (~~), 18 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-17.txt Allan C. Rubens 5 Date: September 2000 Tut Systems, Inc. 6 Haseeb Akhtar 7 Nortel Networks 8 Erik Guttman 9 Sun Microsystems, Inc. 11 DIAMETER Base Protocol 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 This document is an individual contribution for consideration by the 35 AAA Working Group of the Internet Engineering Task Force. Comments 36 should be submitted to the diameter@diameter.org mailing list. 38 Distribution of this memo is unlimited. 40 Copyright (C) The Internet Society 1999. All Rights Reserved. 42 Abstract 44 The DIAMETER base protocol is intended to provide a AAA framework for 45 Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message 46 format, transport, error reporting and security services to be used 47 by all DIAMETER extensions and MUST be supported by all DIAMETER 48 implementations. 50 Table of Contents 52 1.0 Introduction 53 1.1 Requirements language 54 1.2 Terminology 55 2.0 Protocol Overview 56 2.1 Header Format 57 2.2 AVP Format 58 2.2.1 AVP Header 59 2.2.2 Optional Header Elements 60 2.2.3 AVP Value Formats 61 2.2.4 DIAMETER Base Protocol AVPs 62 2.3 Mandatory AVPs 63 2.3.1 Host-Name AVP 64 2.4 Grouping of AVPs 65 2.5 State Machine 66 2.6 Device-Reboot-Ind (DRI) Command 67 2.6.1 Vendor-Name AVP 68 2.6.2 Firmware-Revision AVP 69 2.6.3 Extension-Id AVP 70 2.6.4 Host-IP-Address AVP 71 3.0 "User" Sessions 72 3.1 Session-Id AVP 73 3.2 Session-Timeout AVP 74 3.3 User-Name AVP 75 3.4 Session Termination 76 3.4.1 Session-Termination-Ind 77 3.4.2 Session-Termination-Request 78 3.4.3 Session-Termination-Answer 79 4.0 Reliable Transport 80 5.0 Error Reporting 81 5.1 Message-Reject-Ind (MRI) Command 82 5.1.1 Failed-AVP AVP 83 5.1.2 Unrecognized-Command-Code 84 5.2 Result-Code AVP 85 6.0 DIAMETER Message Routing 86 6.1 NAI-Based Message Routing 87 6.2 Message Proxying 88 6.2.1 Proxy-State AVP 89 6.2.2 Destination-NAI AVP 90 6.3 Message Redirection 91 6.3.1 Redirected-Host AVP 92 6.3.2 Redirect-Host-Port AVP 93 7.0 DIAMETER Message Security 94 7.1 Hop-by-Hop Security 95 7.1.1 Integrity-Check-Value AVP 96 7.1.2 Encrypted-Payload AVP 97 7.1.2.1 MD5 Payload Hiding 98 7.2 Nonce AVP 99 7.3 Timestamp AVP 100 8.0 IANA Considerations 101 8.1 AVP Attributes 102 8.2 Command Code AVP Values 103 8.3 Extension Identifier Values 104 8.4 Result-Code AVP Values 105 8.5 Integrity-Check-Value AVP Transform Values 106 8.6 AVP Header Bits 107 9.0 Open Issues 108 10.0 DIAMETER protocol related configurable parameters 109 11.0 Security Considerations 110 12.0 References 111 13.0 Acknowledgements 112 14.0 Authors' Addresses 113 15.0 Full Copyright Statement 115 1.0 Introduction 117 The DIAMETER protocol allows peers to exchange a variety of messages. 118 The base protocol provides the following facilities: 120 - Delivery of AVPs (attribute value pairs) 121 - Capabilities negotiation, as required in [20] 122 - Error notification 123 - Extensibility, through addition of new commands and AVPs, as 124 required in [21] 126 All data delivered by the protocol is in the form of an AVP. Some of 127 these AVP values are used by the DIAMETER protocol itself, while 128 others deliver data associated with particular applications which 129 employ DIAMETER. AVPs may be added arbitrarily to DIAMETER messages, 130 so long as the required AVPs are included and AVPs which are 131 explicitly excluded are not included. AVPs are used by base DIAMETER 132 protocol to support the following required features: 134 - If application-level security is required, all messages MUST 135 include an Integrity Check Vector (ICV). If the ICV is present, 136 the message MUST also carry a timestamp and a nonce to aid in 137 providing replay protection. 138 - To carry user authentication information, for the purposes of 139 enabling the DIAMETER server to authenticate the user. 140 - To allow authorization information to be exchanged for a 141 particular user's session between a DIAMETER client and server. 142 - To exchange resource usage information, which MAY be used for 143 accounting purposes, capacity planning, etc. 145 The DIAMETER base protocol provides the minimum requirements needed 146 for an AAA transport protocol, as required by NASREQ [21], Mobile IP 147 [22, 23], and ROAMOPS [20]. The base protocol is not intended to be 148 used by itself, and must be used with an application-specific 149 extension, such as Mobile IP [10]. The DIAMETER protocol was heavily 150 inspired and builds upon the tradition of the RADIUS [1] protocol. 152 Any node can initiate a request. In that sense, DIAMETER is a peer to 153 peer protocol. In this document, a DIAMETER client is the device that 154 normally initiates a request for authentication and/or authorization 155 of a user. A DIAMETER server is the device that either forwards the 156 request to another DIAMETER server (known as a proxy), or one that 157 performs the actual authentication and/or authorization of the user 158 based on some profile. Given that the server MAY send unsocilited 159 messages to clients, it is possible for the server to also issue 160 authentication requests. However, these are typically in the form of 161 an indication that the user must be re-authenticated and/or re- 162 authorized. Another example of an unsolicited message would be for a 163 request that the client issue an accounting update. 165 DIAMETER services require sequenced in-order reliable delivery of 166 data, with congestion control (receiver windowing). Timely detection 167 of failed or unresponsive peers is also required, allowing for robust 168 operation. TCP is insufficient for this second requirement. 169 DIAMETER SHOULD be transported over SCTP [26]. 171 1.1 Requirements language 173 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 174 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 175 described in [13]. 177 1.2 Terminology 179 Refer to [9] for terminology used in this document. 181 2.0 Protocol Overview 183 The base DIAMETER protocol is never used on its own. It is always 184 extended for a particular application. Four extensions to DIAMETER 185 are defined by companion documents: NASREQ [7], Mobile IP [10], 186 Accounting Extension [15], Strong Security [11]. These options are 187 introduced in this document but specified elsewhere. Additional 188 extensions to DIAMETER may be defined in the future (see Section 189 8.3). 191 The base DIAMETER protocol concerns itself with capabilities 192 negotiation, and how messages are sent and how peers may eventually 193 be abandoned. The base protocol also defines certain rules which 194 apply to all exchanges of messages between DIAMETER peers. It is 195 important to note that the base protocol provides optional 196 application-level security AVPs (Integrity-Check-Value) which MAY be 197 used in absence of an underlying security protocol (e.g. IP 198 Security). 200 Communication between DIAMETER peers begins with one peer sending a 201 message to another DIAMETER peer. The set of AVPs included in the 202 message is determined by a particular application of or extension to 203 DIAMETER. We will refer to this as the DIAMETER extension. One AVP 204 that is included to reference a user's session is the Session-Id. 206 The initial request for authentication and/or authorization of a user 207 would include the Session-Id. The Session-Id is then used in all 208 subsequent messages to identify the user's session (see section 3.0 209 for more information). The communicating party may accept the 210 request, or reject it by returning a response with Result-Code AVP 211 set to indicate an error occured. The specific behavior of the 212 diameter server or client receiving a request depends on the DIAMETER 213 extension employed. 215 Session state (associated with a Session-Id) MUST be freed upon 216 receipt of the Session-Termination-Request, Session-Termination- 217 Answer and according to rules established in a particular 218 extension/application of DIAMETER. 220 Exchanges of messages are either request/reply oriented, or in some 221 special cases, do not require replies. All such messages that do not 222 require replies have names ending with '-Ind' (short for Indication). 224 The DIAMETER base protocol provides the Session-Timeout AVP, which 225 MAY be used by extensions to specify the duration of a specific 226 authorized session. 228 2.1 Header Format 230 The base DIAMETER protocol is run over SCTP [26] port 1812. 231 Implementations MAY send packets from any source port, but MUST be 232 prepared to receive packets on port 1812. When a request is received, 233 in order to send a reply, the source and destination ports in the 234 reply are reversed. Note that the source and destination addresses 235 used in request and replies MAY be any of the peer's valid IP 236 addresses. 238 A given DIAMETER process SHOULD use the same port number to send all 239 messages to aid in identifying which process sent a given message. 240 More than one DIAMETER process MAY exist within a single host, so the 241 sender's port number is needed to discriminate them. 243 A summary of the DIAMETER data format is shown below. The fields are 244 transmitted in network byte order. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |RADIUS PCC=254 | Flags | Ver | Message Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Identifier | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Command-Code | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Vendor-ID | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | AVPs ... 258 +-+-+-+-+-+-+-+-+-+-+-+-+- 260 RADIUS PCC 261 The RADIUS Packet Compatibility Code (PCC) field is a one octet 262 field which is used for backward compatibility with RADIUS and 263 MUST be set to 254. In order to easily distinguish DIAMETER 264 messages from RADIUS, the value of 254 has been reserved and 265 allows implementations to support both protocols by using the 266 first octet in the header. 268 Flags 269 The Message Flags field is five bits, and is currently unused. 270 This field MUST be initialized to zero. 272 Version 273 This Version field MUST be set to 1 to indicate DIAMETER Version 274 1. 276 Message Length 277 The Message Length field is two octets and indicates the length of 278 the DIAMETER message including the header fields. 280 Identifier 281 The Identifier field is four octets, and aids in matching requests 282 and replies. The sender MUST ensure that the identifier in a 283 message is locally unique (to the sender) at any given time, and 284 MAY attempt to ensure that the number is unique across reboots. 285 The identifier is normally a monotonically increasing number, 286 whose start value was randomly generated. DIAMETER servers should 287 consider a message to be unique by examining the source address, 288 source port and Identifier field of the message. 290 Command-Code 291 The Command-Code field is four octets, and is used in order to 292 communicate the command associated with the message. The 32-bit 293 address space is managed by IANA (see section 8.2). The following 294 Command Codes are currently defined in the DIAMETER base protocol 295 and extensions: 297 Command-Name Abbrev. Code Reference 298 -------------------------------------------------------- 299 Device-Reboot-Ind DRI 257 2.6 300 Message-Reject-Ind MRI 259 5.1 301 Session-Termination-Ind STI 274 3.4.1 302 Session-Termination- STR 275 3.4.2 303 Request 304 Session-Termination- STA 276 3.4.3 305 Answer 306 AA-Mobile-Node-Request AMR 260 [10] 307 AA-Mobile-Node-Answer AMA 261 [10] 308 Home-Agent-MIP-Request HAR 262 [10] 309 Home-Agent-MIP-Answer HAA 263 [10] 310 AA-Request AAR 265 [7] 311 AA-Answer AAA 266 [7] 312 AA-Challenge-Ind ACI 267 [7] 313 DIAMETER-EAP-Request DER 268 [7] 314 DIAMETER-EAP-Answer DEA 269 [7] 315 DIAMETER-EAP-Ind DEI 270 [7] 316 Accounting-Request ACR 271 [15] 317 Accounting-Answer ACA 272 [15] 318 Accounting-Poll-Ind ACP 273 [15] 319 Accounting-Status-Ind ASI 279 [15] 320 Session-Resource-Query SRQ 277 [29] 321 Session-Resource-Reply SRR 278 [29] 322 Home-Agent-Allocated-Ind HAI 279 [10] 324 Vendor-ID 325 In the event that the Command-Code field contains a vendor 326 specific command, the four octet Vendor-ID field contains the IANA 327 assigned "SMI Network Management Private Enterprise Codes" [2] 328 value. If the Command-Code field contains an IETF standard 329 Command, the Vendor-ID field MUST be set to zero (0). 331 AVPs 332 AVPs is a method of encapsulating information relevant to the 333 DIAMETER message. See section 2.2 for more information on AVPs. 335 2.2 AVP Format 337 DIAMETER AVPs carry specific authentication, accounting and 338 authorization information, security information as well as 339 configuration details for the request and reply. 341 Some AVPs MAY be listed more than once. The effect of this AVP is 342 specific, and is specified in each case by the AVP description. 344 Each AVP of type 'string' and 'data' MUST be padded to align on a 32 345 bit boundary, while other AVP types align naturally. NULL bytes are 346 added to the end of the AVP value till a word boundary is reached. 347 The length of the padding is not reflected in the AVP Length field. 349 2.2.1 AVP Header 351 The AVP format is shown below and MUST be sent in network byte order. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | AVP Code | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | AVP Length | Reserved |P|R|V|R|M| 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Vendor-ID (opt) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Data ... 363 +-+-+-+-+-+-+-+-+ 365 AVP Code 366 The AVP Code identifies the attribute uniquely. The first 256 AVP 367 numbers are reserved for backward compatibility with RADIUS and 368 are to be interpreted as per NASREQ [7]. AVP numbers 256 and above 369 are used for DIAMETER, which are allocated by IANA (see section 370 8.1). 372 AVP Length 373 The AVP Length field is two octets, and indicates the length of 374 this Attribute including the AVP Code, AVP Length, AVP Flags, 375 Reserved, the Vendor-ID field if present and the AVP data. If a 376 message is received with an Invalid attribute length, the message 377 SHOULD be rejected. 379 AVP Flags 380 The AVP Flags field informs the DIAMETER host how each attribute 381 must be handled. Note that subsequent DIAMETER extensions MAY 382 define bits to be used within the AVP Header, and an unrecognized 383 bit should be considered an error. The 'R' and the reserved bits 384 are unused and should be set to 0 and ignored on receipt, while 385 the 'P' bit is defined in [11]. 387 The 'M' Bit, known as the Mandatory bit, indicates whether support 388 of the AVP is required. If an AVP is received with the 'M' bit 389 enabled and the receiver does not support the AVP, the message 390 MUST be rejected. AVPs without the 'M' bit enabled are 391 informational only and a receiver that receives a message with 392 such an AVP that is not supported MAY simply ignore the AVP. 394 The 'V' bit, known as the Vendor-Specific bit, indicates whether 395 the optional Vendor-ID field is present in the AVP header. When 396 set the AVP Code belongs to the specific vendor code address 397 space. 399 Unless otherwise noted, AVPs will have the following default AVP 400 Flags field settings: 401 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. 403 2.2.2 Optional Header Elements 405 The AVP Header consists of several optional fields. These fields are 406 only present if their respective bit-flags are enabled. 408 Vendor-ID 409 The Vendor-ID field is present in the 'V' bit is set in the AVP 410 Flags field. The optional four octet Vendor-ID field contains the 411 IANA assigned "SMI Network Management Private Enterprise Codes" 412 [2] value, encoded in network byte order. Any vendor wishing to 413 implement a DIAMETER extensions MUST use their own Vendor-ID along 414 with their privately managed AVP address space, guaranteeing that 415 they will not collide with any other vendor's extensions, nor with 416 future IETF extensions. 418 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 419 values, as managed by the IANA. Since the absence of the vendor ID 420 field implies that the AVP in question is not vendor specific, 421 implementations SHOULD not use the zero (0) vendor ID. 423 2.2.3 AVP Value Formats 425 The Data field is zero or more octets and contains information 426 specific to the Attribute. The format and length of the Data field is 427 determined by the AVP Code and AVP Length fields. The format of the 428 value field MAY be one of seven data types. 430 Data 431 The data contains a variable length of arbitrary data. Unless 432 otherwise noted, the AVP Length field MUST be set to at least 433 9. 435 String 436 The data contains a non-NULL terminated variable length string 437 using the UTF-8 [24] character set. Unless otherwise noted, 438 the AVP Length field MUST be set to at least 9. 440 Address 441 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 442 significant octet first. The format of the address (IPv4 or 443 IPv6) is determined by the length. If the attribute value is an 444 IPv4 address, the AVP Length field MUST be 12, otherwise the 445 AVP Length field MUST be set to 24 for IPv6 addresses. 447 Integer32 448 32 bit value, in network byte order. The AVP Length field MUST 449 be set to 12. 451 Integer64 452 64 bit value, in network byte order. The AVP Length field MUST 453 be set to 16. 455 Time 456 32 bit unsigned value contains the four most significant octets 457 returned from NTP [18], in network byte order. The AVP Length 458 field MUST be set to 12. 460 Complex 461 The complex data type is reserved for AVPs that includes 462 multiple information fields, and therefore do not fit within 463 any of the AVP types defined above. Complex AVPs MUST provide 464 the data format, and the expected length of the AVP. 466 2.2.4 DIAMETER Base Protocol AVPs 468 The following table describes the DIAMETER AVPs defined in the base 469 protocol, their AVP Code values, types, possible flag values and 470 whether the AVP MAY be encrypted. 472 +---------------------+ 473 | AVP Flag rules | 474 |----+-----+----+-----|----+ 475 AVP Section Value | | |SHLD| MUST|MAY | 476 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 477 -----------------------------------------|----+-----+----+-----|----| 478 User-Name 1 3.3 String | | | | | Y | 479 Session-Timeout 27 3.2 Integer32| | | | | Y | 480 Proxy-State 33 6.2.1 Complex | M | | | V | N | 481 Host-IP-Address 257 2.6.4 Address | M | | | V | N | 482 Extension-Id 258 2.6.3 Integer32| | | | | Y | 483 Integrity-Check 259 7.1.1 Complex | | | | | N | 484 -Value | | | | | | 485 Encrypted- 260 7.1.2 Complex | | | | | N | 486 Payload | | | | | | 487 Nonce 261 7.2 Data | | | | | N | 488 Timestamp 262 7.3 Time | | | | | N | 489 Session-Id 263 3.3 Data | | | | | Y | 490 Host-Name 264 2.3.2 String | M | | | V | N | 491 Vendor-Name 266 2.6.1 String | | | | V,M | Y | 492 Firmware 267 2.6.2 Integer32| | | | V,M | Y | 493 -Revision | | | | | | 494 Result-Code 268 5.2 Complex | | | | | N | 495 Destination-NAI 269 6.2.2 String | | | | | Y | 496 Unknown-Command- 270 5.1.2 Integer32| | | | | Y | 497 Code | | | | | | 498 Failed-AVP 279 5.1.1 Data | | | | | Y | 499 Redirect-Host 278 6.3.1 Address | | | | | Y | 500 Redirect-Host- 277 6.3.2 Integer32| | | | | Y | 501 Port | | | | | | 502 Grouped-AVP 280 2.4.1 Data | M | | | V | Y | 504 2.2.5 Standard DIAMETER Extension AVPs 506 The following AVPs are defined in standard DIAMETER extensions. 508 AVP Name Code Ref AVP Name Code Ref AVP Name Code Ref 509 ------------- ---- --- ------------ ---- --- ------------ ---- ---- 510 User-Password 2 [7] Framed- 38 [7] MN-FA- 322 [10] 511 CHAP-Password 3 [7] Appletalk- Challenge- 512 NAS-IP-Address 4 [7] Network Length 513 NAS-Port 5 [7] Framed- 39 [7] MN-FA-Response 323 [10] 514 Service-Type 6 [7] Appletalk- Mobile-Node- 333 [10] 515 Framed-Protocol 7 [7] Zone Address 516 Framed-IP- 8 [7] CHAP-Challenge 60 [7] Home-Agent- 334 [10] 517 Address NAS-Port-Type 61 [7] Address 518 Framed-IP- 9 [7] Port-Limit 62 [7] Previous-FA- 335 [10] 519 Netmask Login-LAT-Port 63 [7] NAI 520 Framed-Routing 10 [7] Tunnel-Type 64 [7] MN-AAA-SPI 336 [10] 521 Filter-Id 11 [7] Tunnel-Medium- 65 [7] Foreign-Home- 337 [10] 522 Framed-MTU 12 [7] Type Agent- 523 Framed- 13 [7] Tunnel-Client- 66 [7] Available 524 Compression Endpoint Filter-Rule 400 [7] 525 Login-IP-Host 14 [7] Tunnel-Server- 67 [7] Request-Type 401 [7] 526 Login-Service 15 [7] Endpoint EAP-Payload 402 [7] 527 Login-TCP-Port 16 [7] Tunnel-Password 69 [7] Accounting- 480 [15] 528 Reply-Message 18 [7] Tunnel-Private- 81 [7] Record-Type 529 Callback-Number 19 [7] Group-ID ADIF-Record 481 [15] 530 Callback-Id 20 [7] Tunnel- 82 [7] Accounting- 482 [15] 531 Framed-IP-Route 22 [7] Assignment-ID Interim- 532 Framed-IPX- 23 [7] Tunnel- 83 [7] Interval 533 Route Preference Accounting- 483 [15] 534 Idle-Timeout 28 [7] Tunnel-Client- 90 [7] Delivery- 535 Called-Station- 30 [7] Auth-ID Interval 536 Id Tunnel-Server- 91 [7] Accounting- 484 [15] 537 Calling- 31 [7] Auth-ID Delivery- 538 Station-Id CMS-Data 310 [11] Max-Delay 539 NAS-Identifier 32 [7] MIP- 320 [10] Accounting- 485 [15] 540 Login-LAT- 34 [7] Registration- Record- 541 Service Request Number 542 Login-LAT-Node 35 [7] MIP- 321 [10] Accounting- 543 Login-LAT-Group 36 [7] Registration- State 486 [15] 544 Framed- 37 [7] Reply Query-Index 500 [29] 545 Appletalk- Resource-Token 501 [29] 546 Link 548 2.3 Mandatory AVPs 550 This section defines the DIAMETER AVPs that MUST be present in all 551 DIAMETER messages. 553 2.3.1 Host-Name AVP 554 The Host-Name AVP (AVP Code 264) [1] is of type String, and is used 555 to inform a DIAMETER peer of the sender's identity. All DIAMETER 556 messages MUST include the Host-Name AVP, which contains the host name 557 of the originator of the DIAMETER message that MUST follow the NAI 558 [8] naming conventions. 560 Note that the Host-Name AVP may resolve to more than one address as 561 the DIAMETER peer may support more than one address. 563 2.4 Grouping of AVPs 565 The DIAMETER protocol allows AVPs to be "grouped" into a set, 566 allowing for complex data representation. The Grouped-AVP AVP 567 encapsulates more than one AVP to form an AVP set. Multiple layers of 568 encapsulation MAY be used by including a child Grouped-AVP AVP inside 569 a parent Grouped-AVP AVP. 571 An example of the use of the Grouped-AVP AVP is the Redirect-Host AVP 572 (see section 6.3.1), which is used by brokers to request that a 573 DIAMETER message be redirected to another DIAMETER node. Since it is 574 possible for a DIAMETER node to listen for incoming messages other 575 than on the default (standard) port, the Redirect-Host-Port AVP 576 (section 6.3.2) allows the port number to be communicated as well. 577 The Grouped-AVP MAY be used to create a logical set of the Host and 578 the port number, thereby allowing the broker to return more than one 579 set of hosts which the message could be redirected to. The following 580 is the BNF representation of the above example: 582 ::= 583 585 586 }> 587 589 590 }> 592 2.4.1 Grouped-AVP AVP 594 The Grouped-AVP AVP (AVP Code 280) is of type complex and is used to 595 encapsulate multiple AVPs creating an AVP set. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 AVP Header (AVP Code = 280) 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | AVPs... 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 AVPs 606 The AVPs field contains the encapsulated AVPs. 608 2.5 State Machine 610 This section contains a finite state machine, that MUST be observed 611 by all DIAMETER implementations. Each DIAMETER node MUST follow the 612 state machine described below when communicating with each peer. 614 State Event Action New State 615 ----- ----- ------ --------- 616 Initial Local request to establish SCTP Idle 617 communication with a DIAMETER Connect 618 peer with which there is no 619 existing transport level 620 connection established. 622 Initial Receive transport level Send DRI Open 623 connection request from a 624 DIAMETER peer. 626 Idle Connection Established Send DRI Wait-DRI 628 Idle Receive DRI Send DRI Open 630 Wait-DRI Receive DRI None Open 632 Open Receive other messages Process Open 633 Message 635 Open Receive DRI Cleanup Closed 637 Open Transport level failure Cleanup Closed 639 Closed DIAMETER Entity shutdown Close Initial 640 or close connection with peer connection 642 The Initial and Idle states MAY be merged if the local SCTP 643 implementation is able to implement the piggyback of data during the 644 connection phase. 646 When the Cleanup action is invoked, the DIAMETER node SHOULD attempt 647 to forward all pending requests and replies, which haven't been 648 acknowledged, to an alternate server (when possible). If the final 649 destination for a specific message is the host that is no longer 650 accessible, the message in question SHOULD be responded with the 651 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 653 2.6 Device-Reboot-Ind (DRI) Command 655 A DIAMETER device sends the Device-Reboot-Ind message, by setting the 656 Command-Code field with a value of 257, to inform a peer that a 657 reboot has just occured. Since SCTP [26] allows for connections to 658 span multiple interfaces, hence multiple IP addresses, the Device- 659 Reboot-Ind message MUST contain one Host-IP-Address AVP for each 660 potential IP address that MAY be locally used when transmitting 661 DIAMETER messages. 663 The DRI message is also used for capabilities negotiation, such as 664 the supported protocol version number, and the locally supported 665 extensions. The receiver uses the extensions advertised in order to 666 determine whether it SHOULD send certain application-specific 667 DIAMETER commands. A DIAMETER node MUST retain the supported 668 extensions in order to ensure that unrecognized commands and/or AVPs 669 are not sent to a peer. Note that in a proxy environment, it is still 670 possible that a downstream proxy has no available peer that have 671 advertised the extension that corresponds to the Command-Code, and 672 therefore the request cannot be forwarded any further. The DIAMETER 673 base protocol provides this error reporting, via the Result-Code AVP. 675 Once the transport layer connection has been established, a DIAMETER 676 entity MUST issue a DRI message, regardless of whether the peer was 677 statically configured, or dynamically discovered. Dynamic discovery 678 of DIAMETER peers MAY be done by using Service Location Protocol 679 (SLP) [28], or through some other discovery mechanism. 681 If a peer is no longer reachable, a DIAMETER device SHOULD 682 periodically attempt to establish a transport level connection with 683 the peer and send a DRI message. This message does not require a 684 reply. If a DIAMETER node receives a DRI message that results in an 685 error, a Message-Reject-Ind message MUST be returned. 687 Message Format 688 ::= 689 690 691 692 693 [] 694 [ 695 696 ] 698 2.6.1 Vendor-Name AVP 700 The Vendor-Name AVP (AVP Code 266) is of type String and is used to 701 inform a DIAMETER peer of the Vendor Name of the DIAMETER device. 702 This MAY be used in order to know which vendor specific attributes 703 may be sent to the peer. It is also envisioned that the combination 704 of the Vendor-Name and the Firmware-Revision (section 2.6.2) AVPs MAY 705 provide very useful debugging information. 707 2.6.2 Firmware-Revision AVP 709 The Firmware-Revision AVP (AVP Code 267) is of type Integer32 and is 710 used to inform a DIAMETER peer of the firmware revision of the 711 issuing device. 713 For devices that do not have a firmware revision (general purpose 714 computers running DIAMETER software modules, for instance), the 715 revision of the DIAMETER software module may be reported instead. 717 2.6.3 Extension-Id AVP 719 The Extension-Id AVP (AVP Code 258) is of type Integer32 and is used 720 in order to identify a specific DIAMETER extension. This AVP is used 721 in the Device-Reboot-Ind message in order to inform the peer what 722 extensions are locally supported. 724 Each DIAMETER extension draft MUST have an IANA assigned extension 725 Idenfier (see section 8.3). The base protocol does not require an 726 Extension-Id since its support is mandatory. 728 There MAY be more than one Extension-Id AVP within a DIAMETER 729 Device-Reboot-Ind message. The following values are recognized: 731 NASREQ 1 [7] 732 Strong Security 2 [11] 733 Resource Management 3 [29] 734 Mobile-IP 4 [10] 735 Accounting 5 [15] 737 2.6.4 Host-IP-Address AVP 739 The Host-IP-Address AVP (AVP Code 4) [1] is of type Address and is 740 used to inform a DIAMETER peer of the sender's IP addresses. All 741 source addresses that a DIAMETER node expects to use with SCTP [26] 742 MUST be advertised in the Device-Reboot-Ind message by including a 743 Host-IP-Address AVP for each address. This AVP MUST ONLY be used in 744 the Device-Reboot-Ind message. 746 3.0 "User" Sessions 748 When a user requests access to the network, a DIAMETER client issues 749 an authentication and authorization request to its local server. The 750 request contains a Session-Id AVP, which is used in subsequent 751 messages (e.g. subsequent authorization, accounting, etc) relating to 752 the user's session. The Session-Id AVP is a means for the client and 753 servers to correlate a DIAMETER message with a user session. 755 When a DIAMETER server authorizes a user to use network resources, it 756 SHOULD add the Session-Timeout AVP to the response. The Session- 757 Timeout AVP defines the maximum amount of time a user MAY make use of 758 the resources before another authorization request is to be 759 transmitted to the server. If the server does not receive another 760 authorization request before the timeout occurs, it SHOULD release 761 any state information related to the user's session. Note that the 762 Session-Timeout AVP implies how long the DIAMETER server is willing 763 to pay for the services rendered, therefore a DIAMETER client SHOULD 764 NOT expect payment for services rendered past the session expiration 765 time. 767 The base protocol does not include any authorization request 768 messages, since these are largely application-specific and are 769 defined in a DIAMETER protocol extension document. However, the base 770 protocol does define a set of messages that are used to terminate 771 user sessions. These are used to allow servers that maintain state 772 information to free resources. 774 3.1 Session-Id AVP 776 The Session-Id AVP (AVP Code 263) is of type Data and is used to 777 identify a specific session (see section 3.0). All messages 778 pertaining to a specific session MUST include only one Session-Id AVP 779 and the same value MUST be used throughout the life of a session. 780 When present, the Session-Id SHOULD appear immediately following the 781 DIAMETER Header (see section 2.1). 783 For messages that do not pertain to a specific session, multiple 784 Session-Id AVPs MAY be present as long as they are encapsulated 785 within different Grouped-AVP AVPs. 787 The Session-Id MUST be globally unique at any given time since it is 788 used by the server to identify the session (or flow). The format of 789 the session identifier SHOULD be as follows: 791 794 The monotonically increasing 32 bit value SHOULD NOT start at zero 795 upon reboot, but rather start at a random value. This will minimize 796 the possibility of overlapping Session-Ids after a reboot. 797 Alternatively, an implementation MAY keep track of the increasing 798 value in non-volatile memory. The optional value is implementation 799 specific but may include a modem's device Id, a layer 2 address, 800 timestamp, etc. 802 The session Id is created by the DIAMETER device initiating the 803 session, which in most cases is done by the client. Note that a 804 Session-Id MAY be used by more than one extension (e.g. 805 authentication for a specific service and accounting, both of which 806 have separate extensions). 808 3.2 Session-Timeout AVP 810 The Session-Timeout AVP (AVP Code 27) [1] is of type Integer32 and 811 contains the maximum number of seconds of service to be provided to 812 the user before termination of the session. A value of zero means 813 that this session has an unlimited number of seconds before 814 termination. 816 This AVP MAY be provided by the client as a hint of the maximum 817 duration that it is willing to accept. However, the server DOES NOT 818 have to observe the hint, and MAY return a value that is smaller than 819 the hint. A value of zero provided by a client DOES NOT imply that 820 service is being terminated. 822 3.3 User-Name AVP 823 The User-Name AVP (AVP Code 1) [1] is of type String and contains the 824 User-Name in a format consistent with the NAI specification [8]. All 825 DIAMETER systems SHOULD support usernames of at least 72 octets in 826 length. 828 3.4 Session Termination 830 The DIAMETER Base Protocol provides a set of messages that MAY be 831 used by any peer to explicitely request that a previously 832 authenticated and/or authorized session be terminated. Since the 833 Session-Id is typically tied to a particular service (i.e. Mobile IP, 834 NASREQ, etc), the session termination messages are used to request 835 that the service tied to the Session Id be terminated. 837 3.4.1 Session-Termination-Ind 839 The Session-Termination-Ind (STI), indicated by the Command-Code set 840 to 274, MAY be sent by any DIAMETER entity to the access device to 841 request that a particular session be terminated. This message MAY be 842 used when a server detects that a session MUST be terminated, which 843 is typically done as a policy decision (e.g. local resources have 844 been expended, etc). The Destination-NAI AVP MUST be present, and 845 contain the NAI of the access device that initiated the session (see 846 section 3.0). 848 Upon receipt of the STI message, the access device SHOULD issue a 849 Session-Terminate-Request message. 851 Message Format 853 ::= 855 856 857 858 859 [] 860 [ 861 862 ] 864 3.4.2 Session-Termination-Request 866 The Session-Termination-Request (STR), indicated by the Command-Code 867 set to 275, is sent by the access device to inform the Home AAA that 868 an authenticated and/or authorized session is being terminated. The 869 Destination-NAI AVP MUST be present, and set to the value that was 870 found in the Host-Name AVP of the authentication and/or authorization 871 response that corresponds with the session in question (e.g. AAA, 872 HAR, AMA in section 2.1). 874 Upon receipt of the STR, the Home DIAMETER Server SHOULD release all 875 resources for the session indicated by the Session-Id AVP. Any 876 intermediate server in the Proxy-Chain MAY also release any 877 resources, if necessary. 879 Message Format 881 ::= 883 884 885 886 887 [] 888 [ 889 890 ] 892 3.4.3 Session-Termination-Answer 894 The Session-Termination-Answer (STA), indicated by the Command-Code 895 set to 276, is sent by the Home DIAMETER Server to acknowledge that 896 the session has been terminated. The Result-Code AVP MUST be present, 897 and MAY contain an indication that an error occured while servicing 898 the STR. 900 Message Format 902 ::= 904 905 906 907 908 909 [] 910 [ 911 912 ] 914 4.0 Reliable Transport 915 In order to provide rapid discovery of the failure of a communicating 916 peer, aggressive retransmission and rapid transactions, DIAMETER 917 peers MUST be able to send and receive messages over SCTP [26]. A 918 DIAMETER peer MAY use TCP [27], as TCP does provide reliable 919 transport, though it does not have the properties listed above. 921 5.0 Error Reporting 923 There are five different types of errors within DIAMETER. The first 924 being where a DIAMETER message is poorly formatted and 925 unrecognizable, indicated below by "Bad Message". This error 926 condition applies if a received message creates a fatal error (e.g. 927 fails transport level authentication, cannot be parsed, etc). 929 The second case involves receiving a Command-Code that is not 930 supported, which is shown below by "Unknown Command". The third case 931 is where an AVP is received, marked mandatory and is unknown by the 932 receiver, which is labeled below as "Unknown AVP". 934 This fourth case involves receiving a message with a known AVP, yet 935 the value is either unknown or illegal, which is shown below as "Bad 936 Value". The last case occurs when an error occurs while processing a 937 specific extension command, which is not related to the message 938 format and is labeled "Extension Error" below. 940 Error Type Ignore Message Send Extension 941 Message-Reject-Ind Response + 942 Result-Code 943 Bad Message X 944 Unknown Command X 945 Unknown AVP X 946 Bad Value X 947 Extension Error X 949 "Ignore Message" indicates that the message is simply dropped. The 950 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 951 be sent to the peer as described in the appropriate section. The 952 "Extension Response + Result-Code" indicates that the appropriate 953 Response to the message MUST be sent with the Result-Code AVP set to 954 a value that enables the peer to understand the nature of the 955 problem. 957 5.1 Message-Reject-Ind (MRI) Command 959 The Message-Reject-Ind (MRI), indicated by the Command-Code set to 960 259, provides a generic means of completing transactions by 961 indicating errors in the messages that initiated them. The Message- 962 Reject-Ind command is sent in response: 964 1. An error is found in a Device-Reboot-Ind message. 965 2. An error is found in a message for which there is no 966 appropriate response. 967 3. A message was received that cannot pass the base protocol error 968 checking. 969 4. A message was received whose extension is not locally 970 supported. 972 In the event that a request is received that causes an error defined 973 in a DIAMETER extension, the appropriate response with the Result- 974 Code AVP SHOULD be sent. 976 The Message-Reject-Ind message MUST contain the same identification 977 in the header and include the Session-Id if it was present in the 978 original message that it is responding to, even if the identification 979 is erroneous. 981 Message Format 983 The structure of the Message-Reject-Ind message is defined as 984 follows: 986 ::= 988 989 [] 990 991 992 [ 993 994 ] 996 where the Identifier value in the message header and optionally 997 the Session-Id AVP are copied from the message being rejected. The 998 Result-Code AVP indicate the nature of the error causing 999 rejection, and the Failed-AVP AVP provides some minimal debugging 1000 data by indicating a specific AVP type which caused the problem. 1001 See the description of the Result-Code AVP for indication of when 1002 the Failed-AVP AVP MUST be present in the message. See [25] for 1003 more information. 1005 5.1.1 Failed-AVP AVP 1007 The Failed-AVP AVP (AVP Code 279) is of type Data and provides 1008 debugging information in cases where a request is rejected or not 1009 fully processed due to erroneous information in a specific AVP. The 1010 value of the Result-Code AVP will provide information on the reason 1011 for the Failed-AVP AVP. 1013 A DIAMETER message MAY contain one or more Failed-AVP, each 1014 containing a complete AVP that could not be processed successfully. 1015 The possible reasons for this AVP are the presence of an improperly 1016 constructed AVP, an unsupported or unrecognized AVP or an invalid AVP 1017 value. 1019 5.1.2 Unrecognized-Command-Code 1021 The Unrecognized-Command-Code AVP (AVP Code 270) is of type Integer32 1022 and contains the offending Command-Code that resulted in sending the 1023 Message-Reject-Ind message. 1025 5.2 Result-Code AVP 1027 The Result-Code AVP (AVP Code 268) is of type Complex and indicates 1028 whether a particular request was completed successfully or whether an 1029 error occurred. All DIAMETER messages of type *-Response or *-Answer 1030 MUST include one Result-Code AVP. 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 AVP Header (AVP Code = 268) 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Result Code | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | String ... 1040 +-+-+-+-+-+-+-+-+ 1042 The Result Code field contains an IANA-managed 32-bit address space 1043 representing errors (see section 8.4). The String field contains an 1044 OPTIONAL string field containing a human readable error message. The 1045 base protocol defines the following error codes, and others MAY be 1046 defined in separate DIAMETER extensions: 1048 DIAMETER_SUCCESS 0 1049 The Request was successfully completed. 1051 DIAMETER_FAILURE 1 1052 The Request was not successfully completed for an unspecified 1053 reason. A DIAMETER Message-Reject-Ind message returning this 1054 result SHOULD whenever possible also contain one or more 1055 Failed-AVP AVPs indicating the AVPs that caused the failure. 1057 DIAMETER_POOR_REQUEST 2 1058 The Request was poorly constructed. 1060 DIAMETER_INVALID_AUTH 3 1061 The Request did not contain a valid Integrity-Check-Value or 1062 CMS-Data [11] AVP. 1064 DIAMETER_UNKNOWN_SESSION_ID 4 1065 The request or response contained an unknown Session-Id. 1067 DIAMETER_USER_UNKNOWN 5 1068 A request was received for a user that is unknown, therefore 1069 authentication failed. This error is sent only due to 1070 conditions that arise due to command messages in DIAMETER 1071 extensions, the base protocol does not include command codes 1072 that require the User-Name AVP. 1074 DIAMETER_COMMAND_UNSUPPORTED 6 1075 The Request contained a Command-Code that the receiver did not 1076 recognize or support. The Message-Reject-Ind message MUST also 1077 contain a Unknown-Command-Code AVP containing the unrecognized 1078 Command-Code. 1080 DIAMETER_TIMEOUT 7 1081 This error MAY be returned if a request has been received that 1082 has a Timestamp AVP that is older than the maximum age that the 1083 communicating peer is willing to accept. 1085 DIAMETER_AVP_UNSUPPORTED 8 1086 The peer received a message that contained an AVP that is not 1087 recognized or supported and was marked with the Mandatory bit. 1088 A DIAMETER message with this error MUST contain one or more 1089 Failed-AVP AVP containing the AVPs that caused the failure. 1091 DIAMETER_REDIRECT_INDICATION 9 1092 A proxy or broker has determined that the request could not be 1093 satisfied locally and the initiator of the request should 1094 direct the request directly to the server, whose contact 1095 information has been added to the response. This error code 1096 MUST NOT be sent in a Message-Reject-Ind message. 1098 DIAMETER_REALM_NOT_SERVED 10 1099 A proxy or broker has determined that it is unable to forward 1100 the request or provide redirect information since the realm 1101 portion of the NAI requested is unknown. 1103 DIAMETER_UNSUPPORTED_TRANSFORM 11 1104 A message was received that included an Integrity-Check-Value 1105 or CMS-Data AVP [11] that made use of an unsupported transform. 1107 DIAMETER_AUTHENTICATION_REJECTED 12 1108 The authentication process for the user failed, most likely due 1109 to an invalid password used by the user. 1111 DIAMETER_AUTHORIZATION_REJECTED 13 1112 A request was received for which the user could not be 1113 authorized. This error could occur when the user has already 1114 expended allowed resources, or if the service requested is not 1115 permitted to the user. 1117 DIAMETER_INVALID_AVP_VALUE 14 1118 The request contained an AVP with an invalid value in its data 1119 portion. A DIAMETER message with this result code MUST include 1120 the offending AVPs within a Failed-AVP AVP. 1122 DIAMETER_MISSING_AVP 15 1123 The request did not contain an AVP that is considered mandatory 1124 by the Command Code definition. If this value is sent in the 1125 Result-Code AVP, a Failed-AVP AVP SHOULD be included in the 1126 message. The data portion of the Failed-AVP MUST have its AVP 1127 Code set to the value of the missing AVP. 1129 DIAMETER_UNABLE_TO_DELIVER 16 1130 The request could not be delivered to the host specified in the 1131 Destination-NAI AVP, or no host is available for that 1132 particular realm to handle the request. 1134 5.2.1 Additional Error Codes 1136 The following additional result codes are defined by standard 1137 extensions to the DIAMETER protocol. 1139 DIAMETER_ERROR_BAD_KEY 16 [10] 1140 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 [10] 1141 DIAMETER_ERROR_TOO_BUSY 18 [10] 1142 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 [10] 1143 DIAMETER_INVALID_CMS_DATA 20 [11] 1145 6.0 DIAMETER Message Routing 1146 The DIAMETER base protocol supports two basic message routing 1147 methods; proxying and brokering. A DIAMETER proxy is a server that 1148 simply forwards the request based on the user's identity, or through 1149 some other means. A DIAMETER broker is a server that provides 1150 redirect services, allowing all servers in a roaming consortium to 1151 interact directly. This section describes how DIAMETER message 1152 routing is performed. 1154 6.1 NAI-Based Message Routing 1156 DIAMETER Message routing is done through the use of the Network 1157 Access Identifier (NAI), and an associated realm routing table (see 1158 section 10.0). The NAI has a format of user@realm, and DIAMETER 1159 servers have a list of locally supported realms, and MAY have a list 1160 of externally supported realms. When a message is received that 1161 includes a realm that is not locally supported, the message is 1162 proxied to the DIAMETER entity configured in the "route" table. 1164 Figure 1 depicts an example where DIA1 receives a request to 1165 authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local 1166 realm route table and determines that the message must be proxied to 1167 DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 1168 checks its realm route table, and determines that the realm is 1169 locally supported, and processes the authentication request, and 1170 returns the response. How the response actually makes it back to the 1171 sender of the original request is described in the next section. 1173 (Request) (Request) 1174 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1175 +------+ ------> +------+ ------> +------+ 1176 | | | | | | 1177 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1178 | | | | | | 1179 +------+ <------ +------+ <------ +------+ 1180 (Response) (Response) 1181 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1183 mno.net xyz.com abc.com 1184 Figure 1: NAI Based Routing 1186 6.2 Message Proxying 1188 A DIAMETER proxy is a server that provides message forwarding 1189 functions to other DIAMETER Servers. Proxies are typically used when 1190 a hierarchical DIAMETER network is deployed, where some DIAMETER 1191 servers can authenticate and authorize a set of users. Such an 1192 example is a roaming consortium, where each ISP has a user base, 1193 which they can authenticate and authorize. It is important to note 1194 that proxy servers MUST NOT attempt to re-order AVPs in a DIAMETER 1195 message. 1197 There are two different methods of routing DIAMETER messages through 1198 proxies; Proxy-State and Destination-NAI. The Proxy-State AVP is used 1199 to encode local state information in a request. The corresponding 1200 response is guaranteed to include the same Proxy-State AVP, allowing 1201 the node to recover the state information. The use of the Proxy-State 1202 AVP requires that the corresponding response traverse through the 1203 same set of proxies (in reverse order), which introduces some 1204 reliability problems. If a single DIAMETER node in the proxy chain 1205 fails, all responses that must traverse through it would be lost. The 1206 Proxy-State AVP is used by proxy servers that MUST maintain state 1207 information, such as protocol translation gateways [25]. 1209 The Destination-NAI is a more flexible scheme, and is used by 1210 DIAMETER proxies that do not need to maintain any state information 1211 when acting as a simple message routing agent. This allows the 1212 DIAMETER network to be much more reliable, since responses can be 1213 sent through an alternate path should a proxy server fail. 1215 6.2.1 Proxy-State AVP 1217 The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when 1218 forwarding requests and contains opaque data that is used by the 1219 proxy to further process the response. Such data may include AVPs 1220 that are to be added to the response, information about the 1221 downstream peer, etc. 1223 It is important to note that the use of the Proxy-State AVP requires 1224 that the corresponding response traverse through the DIAMETER node 1225 that added the AVP. The requirement that responses return on the 1226 reverse path of a request is only adequate in certain networks. It 1227 does not allow for resilient operation, since alternative servers 1228 MUST NOT be used. Therefore a DIAMETER node SHOULD only use the 1229 Proxy-State AVP when performing protocol bridging [25]. 1231 A DIAMETER node that adds a Proxy-State AVP to a request expects the 1232 SAME AVP to be present in the corresponding response. Furthermore, 1233 more than one Proxy-State AVP MUST NOT be present in a single 1234 DIAMETER message. See [25] for more information on AVP handling. 1236 (Request) (Request) 1237 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1238 (Proxy-State=DIA1,x) (Proxy-State=DIA2,y) 1239 +------+ ------> +------+ ------> +------+ 1240 | | | | | | 1241 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1242 | | | | | | 1243 +------+ <------ +------+ <------ +------+ 1244 (Response) (Response) 1245 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1246 (Proxy-State=DIA1,x) (Proxy-State=DIA2,y) 1248 mno.net xyz.com abc.com 1249 Figure 2: Use of the Proxy-State AVP 1251 When a DIAMETER node receives a message that includes the Proxy-State 1252 AVP, and the address within the AVP is a peer that it is able to 1253 exchange DIAMETER messages with, the message MUST be forwarded to the 1254 peer in question. When the Proxy-State AVP's address indicates that 1255 the AVP was locally added, the Proxy-State AVP MUST be removed, and 1256 the original Proxy-State AVP must be restored (if one was present in 1257 the corresponding request). When DIA2 receives the response from DIA3 1258 (in figure 2), it examines the Proxy-State and finds that it was 1259 created by DIA1. Since DIA2 is able to communicate with DIA1, it 1260 forwards the message to DIA1. 1262 The Proxy-State AVP's Address field is 128-bits in length contains 1263 one of the IP addresses of the system that created the AVP, and used 1264 to assist hosts in determining whether a Proxy-State AVP is intended 1265 for the local host. If the host creating the AVP has an IPv4 address, 1266 and is IPv6 capable, the leading 96 bits MUST be set to zero (0). If 1267 the AVP has an IPv4 address, and the host is not IPv6 capable, the 1268 leading 64 bites MUST be set to zero (0), and the following 32 bits 1269 MUST be set to all ones [16]. 1271 0 1 2 3 1272 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 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 AVP Header (AVP Code = 33) 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | 128-bit Address... 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Data ... 1279 +-+-+-+-+-+-+-+-+ 1281 6.2.2 Destination-NAI AVP 1282 The Destination-NAI AVP (AVP Code 269) is of type String, MAY be 1283 included in a request, and SHOULD be included in a response message. 1284 The Destination-NAI MUST be in a format consistent with the NAI 1285 specification. When found in a response, the AVP SHOULD contain the 1286 value of the Host-Name AVP that was found in the request. 1288 Since the Destination-NAI AVP allows for a more resilient DIAMETER 1289 network, by allowing a DIAMETER node to send to one of many peers 1290 that can handle a particular realm, implementations SHOULD use it as 1291 opposed to the Proxy-State AVP. 1293 Request messages in transactions that span multiple round trips (e.g. 1294 EAP [7]), the Destination-NAI AVP SHOULD be copied from the previous 1295 response that caused the new request. This will ensure that all 1296 requests forming the transaction will be forwarded to the same target 1297 DIAMETER server. 1299 (Request) (Request) 1300 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1301 (Host-Name=DIA1@nmo.net) (Host-Name=DIA1@nmo.net) 1302 +------+ +------+ +------+ 1303 | | | | | | 1304 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 1305 | | | | | | 1306 +------+ +------+ +------+ 1307 ^ | 1308 | +------+ | 1309 | | | | 1310 +-----------------------| DIA4 |<----------------------+ 1311 | | 1312 +------+ 1313 (Response) (Response) 1314 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1315 (Dest-NAI=DIA1@mno.net) (Dest-NAI=DIA1@mno.net) 1317 mno.net mno.com abc.com 1318 Figure 3: Use of Destination-NAI 1320 When DIA3 (in figure 3) creates the response, it adds the 1321 Destination-NAI AVP with the value that was found in the request's 1322 Host-Name AVP. DIA3 is not able to communicate directly with DIA1, 1323 but it is able to communicate with peers within the mno.com network. 1324 Therefore, it issues the response to any peer in the mno.com network. 1325 When DIA4 receives the response, it examines the Destination-NAI AVP, 1326 and determines that it is able to communicate directly with DIA1, and 1327 forwards the response to it. 1329 6.3 Message Redirection 1331 There are cases where a DIAMETER proxy, known as a broker, may wish 1332 to request that a server contact another directly instead of 1333 forwarding the message (figure 2). This is typically done when the 1334 broker provides simple NAI to Home DIAMETER Server address resolution 1335 services. 1337 In the example provided in figure 4, abc.net's DIAMETER server issues 1338 a request to its broker, which in turn returns a response that 1339 includes the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION (see 1340 section 5.2). When a response is received with the Result-Code set 1341 to this value, the message MUST also include one or more Redirect- 1342 Host AVPs, and optionally the Redirect-Host-Port AVP. The Redirect- 1343 Host AVP contains the IP address to which the request SHOULD be 1344 forwarded to directly. When more than one un-grouped Redirect-Host- 1345 Port AVPs are found, they contain more than one server that could 1346 service the request. When more than one Redirect-Host AVP is present 1347 in a Grouped-AVP, they contain the various IP addresses of the SAME 1348 host, any of which MAY be used to directly contact the peer. 1350 The above requires that the broker be contacted for all messages in 1351 order to identify the Home DIAMETER server to use for a particular 1352 realm. Since contacting the broker does introduce additional latency, 1353 an implementation MAY cache the information received by the broker, 1354 eliminating the need to contact the broker for multiple messages to 1355 the same realm. The broker MAY include the the Session-Timeout AVP in 1356 the redirect response as a hint to its peer as to how long the cache 1357 entry SHOULD be valid. The peer is not obligated to respect the hint 1358 from the broker. 1360 In the event that the Redirect-Host AVP is grouped, the broker MAY 1361 also include the Session-Timeout AVP to the same Grouped-AVP in order 1362 to specify the cache timeout for the particular host. 1364 +------------------+ +---------+ 1365 | DIAMETER | | CRL DB/ | 1366 | Broker | | OCSP | 1367 +------------------+ +---------+ 1368 ^ 1369 Request | Response + 1370 | Result Code = 1371 | Redirect 1372 v 1373 +----------+ +----------+ 1374 | abc.net | | xyz.net | 1375 | DIAMETER |<------------>| DIAMETER | 1376 | Server | | Server | 1377 +----------+ Direct +----------+ 1378 Communication 1379 Figure 4: DIAMETER Broker Returning Redirect Indication 1381 When returning the response with the Result-Code set to 1382 DIAMETER_REDIRECT_INDICATION, the broker MAY also include the 1383 certificates of both the requesting server, and the target server. 1384 These certificates are encapsulated in a CMS-Data AVP [11]. The 1385 requesting server SHOULD forward the certificate that belongs to it 1386 in the subsequent request to the home DIAMETER server. 1388 Figure 5 below provides a more complex network, where the request 1389 must be forwarded to a second broker (Inter-Broker Communication), 1390 and there are a number of proxies between the NAS and the "edge" 1391 DIAMETER Server that communicates with the broker. When Broker A 1392 receives the response that includes the redirect information from 1393 Broker B, it is passed down to abc's DIAMETER server, which in turn 1394 communicates directly with xyz's server. 1396 +------------+ Request +------------+ 1397 | DIAMETER | | DIAMETER | 1398 | Broker A |<--------->| Broker B | 1399 +------------+ Redirect +------------+ 1400 ^ Response 1401 Request |Redirect 1402 |Response 1403 | 1404 v 1405 +----------+ +----------+ 1406 +-----+ +-| abc.net | | xyz.net | 1407 | | +-| | DIAMETER |<------------>| DIAMETER | 1408 | NAS |<->| | | Server(s)| | Server | 1409 | | | | +----------+ Direct +----------+ 1410 +-----+ | +----------+ Communication 1411 +----------+ 1412 Figure 5: Inter-Broker redirect in a proxied network 1414 6.3.1 Redirect-Host AVP 1416 The Redirect-Host AVP (AVP Code 278) is of type Address and is 1417 returned in a response that has the Result-Code AVP set to 1418 DIAMETER_REDIRECT_REQUEST. This AVP includes the IP address of the 1419 DIAMETER host to which the request MUST be redirected. The presence 1420 of multiple Redirect-Host AVPs within the same Grouped-AVP, implies 1421 that all of the addresses MAY be used to contact the same host. When 1422 multiple AVPs are found that are un-grouped, or grouped with 1423 different Grouped-AVPs, they represent separate hosts. Upon receipt 1424 of such a Result-Code, and this AVP, a DIAMETER host SHOULD send the 1425 request directly to one of the hosts. 1427 The broker MAY wish to return the certificate associated with a given 1428 Redirect-Host AVP. This can be returned in a CMS-Data AVP, as defined 1429 in [11]. 1431 6.3.2 Redirect-Host-Port AVP 1433 The Redirect-Host-Port AVP (AVP Code 277) is of type Integer32 and 1434 MAY be present when the Redirect-Host AVP is present. The absence of 1435 this AVP implies that the reserved port MUST be used. 1437 7.0 DIAMETER Message Security 1439 The DIAMETER Base protocol MAY be secured in one of three ways. The 1440 first method does not involve any security mechanisms in the DIAMETER 1441 protocol, but relies on an underlying security mechanism, such as IP 1442 Security. The second method is hop-by-hop security, which SHOULD be 1443 supported by all DIAMETER implementations. The third method is 1444 optional and requires a Public Key Infrastructure [14], and is 1445 documented in [11]. 1447 7.1 Hop-by-Hop Security 1449 DIAMETER Hop-by-Hop security provides message integrity and per AVP 1450 encryption, and requires that the communicating entities have a pre- 1451 configured shared secret, similar to the method employed by the 1452 RADIUS protocol. Hop-by-Hop security is very difficult to deploy and 1453 administer in large scale networks and involves symmetric trust, 1454 unlike security based on a public key infrastructure (PKI). PKI is 1455 used for DIAMETER End-to-End security, and is defined in [11]. Hop- 1456 by-Hop security may be desirable in environments where symmetric 1457 cryptography is sufficient or when a PKI is not available. 1459 Figure 6 below provides an example of hop-by-hop security in a proxy 1460 chain. Assuming that the packet was received by DIA2 from DIA1, and 1461 was to be proxied to DIA3, the following steps would be taken: 1463 1. Validating the message's integrity using the shared secret with 1464 DIA1, and removing the authenticated security AVPs. 1466 2. Decrypting any encrypted AVPs using the secret shared with DIA1. 1468 3. Re-encrypting AVPs using the secret shared with DIA3. 1470 4. Computing the message hash using the secret shared with DIA3, 1471 and adding it to the ICV AVP in the DIAMETER message. 1473 (Shared-Secret-1) (Shared-Secret-2) 1474 +------+ -----> +------+ ------> +------+ 1475 | | |1 3| | | 1476 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 1477 | | |2 4| | | 1478 +------+ +------+ +------+ 1479 Figure 6: Hop-by-Hop Security in Proxy Environments 1481 The above steps that each proxy MUST perform in a proxy chain clearly 1482 describes the security issues associated with hop-by-hop security in 1483 a proxy environment. Since the message integrity is re-computed at 1484 each node in the chain, it is not possible to detect if a proxy 1485 modified information in the message (e.g. session time). Furthermore, 1486 any sensitive information would be known to all proxies in the chain, 1487 since each node must decrypt AVPs. Therefore, Any AVPs that contain 1488 data that MUST NOT be seen by intermediate DIAMETER nodes MUST be 1489 protected via the mechanism described in the strong security 1490 extension [11]. 1492 It is highly recommended that the size of the shared secrets used be 1493 sufficiently long (e.g. 128 bits), and that different shared secrets 1494 be used for both authentication and encryption. 1496 7.1.1 Integrity-Check-Value AVP 1498 The Integrity-Check-Value AVP (AVP Code 259) is of type complex and 1499 is used for hop-by-hop message authentication and integrity. 1501 The DIAMETER header as well as all AVPs (including padding) up to 1502 this AVP is protected by the Integrity-Check-Value. Note that the 1503 Message Length field in the DIAMETER header MUST be set to zero (0) 1504 prior to the ICV calculation. The Timestamp and Nonce AVPs MUST be 1505 present in the message PRIOR to the Integrity-Check-Value AVP. The 1506 Timestamp AVP provides replay protection and the Nonce AVP provides 1507 randomness. Any AVPs in a message that is not succeeded by the 1508 Integrity-Check-Value AVP MUST be ignored. 1510 The following is an example of a message that include hop-by-hop 1511 security: 1513 ::= 1514 1515 [] 1516 1517 1519 All DIAMETER implementations SHOULD support this AVP. 1521 0 1 2 3 1522 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 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 AVP Header (AVP Code = 259) 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Transform ID | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Key ID | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Data ... 1531 +-+-+-+-+-+-+-+-+ 1533 AVP Length 1534 The length of this attribute MUST be at least 13. 1536 Transform ID 1537 The Transform ID field contains a value that identifies the 1538 transform that was used to compute the ICV. The following 1539 values are defined in this document: 1541 HMAC-MD5-96[6] 1 1542 The ICV is computed using the HMAC-MD5 algorithm, and the 1543 first 12 bytes of the hash output is included in the data 1544 portion of the ICV AVP. All DIAMETER implementations 1545 supporting this AVP MUST support this transform. Using the 1546 example code provided in [6], the following call would be 1547 used to generate the Integrity-Check-Value: 1549 hmac_md5(DiameterMessage, MessageLength, Secret, 1550 Secretlength, Output) 1552 Key ID 1553 The Key ID field contains a key identifier, which is used to 1554 identify the keying information used to generate the AVP's data 1555 field. 1557 Data 1558 The data field contains the output from the hashing algorithm. 1560 7.1.2 Encrypted-Payload AVP 1562 The Encrypted-Payload AVP (AVP Code 260) is of type complex and is 1563 used to encapsulate encrypted AVPs for privacy during transmission. 1565 Hop-by-Hop confidentiality is achieved by encapsulating all AVPs 1566 which are to be encrypted into an Encrypted-Payload AVP. This 1567 feature SHOULD be supported by DIAMETER implementations. 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 AVP Header (AVP Code = 260) 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Transform ID | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Key ID | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Decrypted Data Length | Data ... 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 AVP Length 1582 The length of this attribute MUST be at least 13. 1584 Transform ID 1585 The Transform ID field contains a value that identifies the 1586 transform that was used to compute the ICV. The following 1587 values are defined in this document: 1589 MD5 1 1590 See section 7.1.2.1 for more information. 1592 Key ID 1593 The Key ID field contains a key identifier, which is used to 1594 identify the keying information used to generate the AVP's data 1595 field. 1597 Decrypted Data Length 1598 The encrypted data length field contains the actual length of 1599 the decrypted data. This field is necessary in order to not 1600 treat the padded data as part of the plaintext. 1602 Data 1603 The data field contains the encrypted payload. 1605 7.1.2.1 MD5 Payload Hiding 1606 MD5 Payload Hiding is supported by DIAMETER for backward 1607 compatibility with existing RADIUS infrastructure. 1609 The plain text (which is a buffer containing one or more AVPs) is 1610 first padded to a sixteen (16) byte boundary with 0 bytes. Since the 1611 encapsulated AVPs have length fields, it is possible to detect their 1612 boundaries, whether or not padding has been done. 1614 One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 1615 hash is performed on the: 1617 - last Nonce AVP which precedes the Encrypted-Payload AVP 1618 - the shared authentication secret 1620 This MD5 hash value is then XORed with the first 16 octet segment of 1621 the buffer to encrypt. The resulting 16 octet result is saved as the 1622 first 16 octets of the encrypted buffer. The result is also used to 1623 calculate a new value using MD5: 1625 - the shared authentication secret 1626 - the 16 byte result of the previous XOR 1628 This value is then XORed with the next 16 bytes. This is done for 1629 each 16 bytes successively in the buffer to encrypt, producing an 1630 equal sized encrypted buffer. 1632 The receiver of a DIAMETER message with an Encrypted-Payload AVP MUST 1633 first check the integrity of the message, either through the ICV, or 1634 the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP. Then 1635 the Encrypted-Payload AVP is decrypted, by reversing the above 1636 procedure, which applied to the buffer will reproduce the plain text 1637 version. The decapsulated AVPs are then used to process the DIAMETER 1638 message in the normal manner. 1640 7.2 Nonce AVP 1642 The Nonce AVP (AVP Code 261) is of type Data and MUST be present 1643 prior to the Integrity-Check-Value AVPs within a message and is used 1644 to ensure randomness within a message. The content of this AVP MUST 1645 be a random value of at least 128 bits. Some crypto algorithms are 1646 known to have weaknesses if a random value is not found early within 1647 the plaintext, therefore it is recommended that the Nonce AVP be 1648 added early in a message if possible. 1650 7.3 Timestamp AVP 1651 The Timestamp AVP (AVP Code 262) is of type Time and is used to add 1652 replay protection to the DIAMETER protocol. This AVP MUST appear 1653 prior to the Integrity-Check-Value AVP or any other message integrity 1654 AVP defined in separate extensions. The value of this AVP is the most 1655 significant four octets returned from an NTP [18] server that 1656 indicates the number of seconds expired since Jan. 1, 1900. 1658 Messages that are older than a configurable maximum age SHOULD be 1659 rejected (see section 10.0) and a response SHOULD be returned with 1660 the Result-Code AVP value set to DIAMETER_TIMEOUT. Note that the 1661 larger the configurable value, the more susceptible one is to a 1662 replay attack. However, one does have to take into account the 1663 possibility for clock drift, and the latency involved in the 1664 transmission of the message over the network. The timestamp AVP 1665 SHOULD be updated prior to retransmission. 1667 A DIAMETER node that receives a message with the Result-Code AVP set 1668 to DIAMETER-TIMEOUT MAY use the time found in the Timestamp AVP 1669 within the reply in order to synchronize its clock with its peer. 1670 When time synchronization is done, the sender MUST NOT change its 1671 local time, but SHOULD adjust the time delta for all outgoing 1672 messages to the peer, and require that its local time be used in 1673 received messages. 1675 Implementations must be prepared to wrap at the epochal 2038 where 1676 Time values are used, and 0,1,... MUST be considered greater than 1677 2^32-1 at that time. 1679 8.0 IANA Considerations 1681 This document defines a number of assigned numbers to be maintained 1682 by the IANA. This section explains the criteria to be used by the 1683 IANA to assign additional numbers in each of these lists. The 1684 following subsections describe the assignment policy for the 1685 namespaces defined elsewhere in this document. 1687 8.1 AVP Attributes 1689 As defined in section 2.2, AVPs contain vendor ID, attribute and 1690 value fields. For vendor ID value of 0, IANA will maintain a registry 1691 of assigned AVP codes and in some case also values. Attribute 0-254 1692 are assigned from the RADIUS protocol [1], whose attributes are also 1693 maintained through IANA. AVP Codes 256-280 are assigned within this 1694 document. The remaining values are available for assignment through 1695 Designated Expert [12]. 1697 8.2 Command Code Values 1699 As defined in section 2.1, the Command Code field has an associated 1700 value maintained by IANA. Values 0-255 are reserved for backward 1701 RADIUS compatibility, and values 256-258 are defined in this 1702 specification. The remaining values are available for assignment via 1703 Designated Expert [12]. 1705 8.3 Extension Identifier Values 1707 As defined in section 2.6.5, the Extension Identifier is used to 1708 identify a specific DIAMETER Extension. All values, other than zero 1709 (0) are available for assignment via Standards Action [12]. 1711 Note that the DIAMETER protocol is not inteded to be extended for any 1712 purpose. Any extensions added to the protocol MUST ensure that they 1713 fit within the existing framework, and that no changes to the base 1714 protocol are required. 1716 8.4 Result-Code AVP Values 1718 As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines 1719 the values 0-8. All remaining values are available for assignment via 1720 IETF Consensus [12]. 1722 8.5 Integrity-Check-Value AVP Transform Values 1724 Section 7.1.1 defines the Integrity-Check-Value AVP (AVP Code 259) 1725 which contains a field called the Transform. This document reserves 1726 the value 1. All remaining values are available for assignment via 1727 Designated Expert [12]. 1729 8.6 AVP Header Bits 1731 There are six remaining reserved bits in the AVP header. Additional 1732 bits should only be assigned via a Standards Action [12]. 1734 9.0 Open Issues 1736 The following are the open issues that SHOULD be addressed in future 1737 versions of the DIAMETER protocol: 1739 - AVPs of type 'Time" are 32 bits in size and contain the a 1740 timestamp consistent with NTP [18]. This field is expected to 1741 expire sometime in 2038. Future investigation SHOULD be done to 1742 determine if a 64 bit time format could be used. 1744 - The fact that the Sender's IP Address is used in the 1745 construction of the Session-Id means that the introduction of 1746 Network Address Translation MAY cause two hosts to represent the 1747 same Session Identifier. This area needs to be investigated 1748 further to be able to support DIAMETER hosts on a private 1749 network. 1751 - When additional hashing transforms are supporting by the 1752 DIAMETER base protocol, there SHOULD be a method to negotiate 1753 the transform to be used. This negotiation MUST NOT be prone to 1754 a bidding down attack to the lowest secure transform. 1756 - This specification defines the use of SCTP port 1812. This port 1757 has not been assigned to the DIAMETER protocol, and cannot be 1758 requested until SCTP becomes an RFC. 1760 10.0 DIAMETER protocol related configurable parameters 1762 This section contains the configurable parameters that are found 1763 throughout this document: 1765 DIAMETER Peer 1766 A DIAMETER entity MAY communicate with peers that are 1767 statically configured. A statically configured DIAMETER peer 1768 would require that either the IP address or the fully qualified 1769 domain name (FQDN) be supplied, which would then be used to 1770 resolve through DNS. 1772 Realm Routing Table 1773 A DIAMETER Proxy server routes messages based on the realm 1774 portion of a Network Access Identifier (NAI). The server MUST 1775 have a table of Realms Names, and the address of the peer to 1776 which the message must be forwarded to. The routing table MAY 1777 also include a "default route", which is typically used for all 1778 messages that cannot be locally processed. 1780 Maximum Age of an outstanding message 1781 Messages older than the maximum age SHOULD be rejected, as 1782 described in section 7.3. The recommended value is 4 seconds. 1784 Shared Secret 1785 The shared secret is a value that is known by two communicating 1786 peers, and is used to generate the Integrity-Check-Value AVP. 1788 There is no default. 1790 11.0 Security Considerations 1792 The DIAMETER base protocol requires that two communicating peers 1793 exchange messages in a secure fashion. This document describes two 1794 security methods that can be used. The first requires no security at 1795 the application layer, but rather relies on an underlying security 1796 mechanism, such as IP Security. 1798 When IP Security is not available, or desirable, the DIAMETER 1799 protocol MAY use hop-by-hop security, which requires communicating 1800 peers to share a long-lived secret. Hop-by-Hop security provides 1801 replay protection by requiring that the communicating peers share a 1802 time source, such as an NTP server. Information of a sensitive 1803 nature, which MUST NOT be seen by any intermediate DIAMETER node MUST 1804 NOT be encrypted using hop-by-hop encryption. 1806 When the DIAMETER protocol is used in an inter-domain network, strong 1807 application level security MAY be required, such as non-repudiation. 1808 When the communicating peers do require this level of security either 1809 for legal or business purposes, the extension defined in [11] MAY be 1810 used. This security model provides AVP-level authentication, and the 1811 encryption mechanism is designed such that only the target host has 1812 the keying information required to decrypt the information. 1814 12.0 References 1816 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1818 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 1820 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1822 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1823 1992. 1825 [5] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 1826 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 1827 13-061466-1. 1829 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1830 Authentication", RFC 2104, January 1997. 1832 [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 1833 Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in 1834 progress, September 2000. 1836 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 1837 ary 1999. 1839 [9] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1840 calhoun-diameter-framework-08.txt, IETF work in progress, June 1841 2000. 1843 [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1844 calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- 1845 tember 2000. 1847 [11] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1848 Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in 1849 progress), September 2000. 1851 [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 1852 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1854 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1855 Levels", BCP 14, RFC 2119, March 1997. 1857 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1858 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1859 RFC 2560, June 1999. 1861 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 1862 draft-calhoun-diameter-accounting-08.txt, IETF work in progress, 1863 September 2000. 1865 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 1866 2373, July 1998. 1868 [17] ISI, "Internet Protocol", RFC 791, September 1981. 1870 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 1871 IPv6 and OSI, RFC 2030, October 1996. 1873 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 1874 tructure Certificate and CRL Profile", RFC 2459, January 1999. 1876 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1877 RFC 2477, January 1999. 1879 [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 1880 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 1881 in progress, June 2000. 1883 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1884 draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep- 1885 tember 2000. 1887 [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1888 Authorization, and Accounting Requirements", draft-ietf- 1889 mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000. 1891 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1892 2279, January 1998. 1894 [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1895 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1896 diameter-impl-guide-03.txt, IETF work in progress, June 2000. 1898 [26] R. Stewart et al., "Simple Control Transmission Protocol", 1899 draft-ietf-sigtran-sctp-13.txt, IETF Work in Progress, July 1900 2000. 1902 [27] Postel, J. "Transmission Control Protocol", RFC 793, January 1903 1981. 1905 [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location 1906 Protocol, Version 2", RFC 2165, June 1999. 1908 [29] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1909 calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep- 1910 tember 2000. 1912 13.0 Acknowledgements 1914 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1915 Pankaj Patel for their participation in the Document Reading Party. 1917 The authors would also like to acknowledge the following people for 1918 their contribution in the development of the DIAMETER protocol: 1920 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1921 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1922 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen Farrell, 1923 Sumit Vakil, John R. Vollbrecht, Jeff Weisberg, Jon Wood and Glen 1924 Zorn 1926 14.0 Authors' Addresses 1927 Questions about this memo can be directed to: 1929 Pat R. Calhoun 1930 Network and Security Research Center, Sun Laboratories 1931 Sun Microsystems, Inc. 1932 15 Network Circle 1933 Menlo Park, California, 94025 1934 USA 1936 Phone: +1 650-786-7733 1937 Fax: +1 650-786-6445 1938 E-mail: pcalhoun@eng.sun.com 1940 Allan C. Rubens 1941 Tut Systems, Inc. 1942 220 E. Huron, Suite 260 1943 Ann Arbor, MI 48104 1944 USA 1946 Phone: +1 734-995-1697 1947 E-Mail: arubens@tutsys.com 1949 Haseeb Akhtar 1950 Wireless Technology Labs 1951 Nortel Networks 1952 2221 Lakeside Blvd. 1953 Richardson, TX 75082-4399 1954 USA 1956 Phone: +1 972-684-8850 1957 E-Mail: haseeb@nortelnetworks.com 1959 Erik Guttman 1960 Network and Security Research Center, Sun Laboratories 1961 Sun Microsystems, Inc. 1962 Eichhoelzelstr. 7 1963 74915 Waibstadt 1964 Germany 1966 Phone: +49-7263-911-701 1967 E-mail: erik.guttman@germany.sun.com 1969 15.0 Full Copyright Statement 1970 Copyright (C) The Internet Society (1999). All Rights Reserved. 1972 This document and translations of it may be copied and furnished to 1973 others, and derivative works that comment on or otherwise explain it 1974 or assist in its implementation may be prepared, copied, published 1975 and distributed, in whole or in part, without restriction of any 1976 kind, provided that the above copyright notice and this paragraph are 1977 included on all such copies and derivative works. However, this docu- 1978 ment itself may not be modified in any way, such as by removing the 1979 copyright notice or references to the Internet Society or other 1980 Internet organizations, except as needed for the purpose of develop- 1981 ing Internet standards in which case the procedures for copyrights 1982 defined in the Internet Standards process must be followed, or as 1983 required to translate it into languages other than English. The lim- 1984 ited permissions granted above are perpetual and will not be revoked 1985 by the Internet Society or its successors or assigns. This document 1986 and the information contained herein is provided on an "AS IS" basis 1987 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1988 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1989 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1990 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1991 FITNESS FOR A PARTICULAR PURPOSE.